Здравствуйте, cvoronin, Вы писали:

Л>>Смотря какой поиск ты имеешь ввиду?
Л>>Мне известны два рабочих варианта:
Л>>1. Сканируешь образы документов (Aidis, Fine Reader, Kofax и др.), ну а затем заливаешь это всё в CM — это тот самый полнотекстовый
Л>>2. В Эрмитаже на CM смогли навесить поиск изображений по палитре красок ...

C>А как-раз полнотекстовой. Но, насколько я понял, работает он с отсканированными и с распознанными документами?
C>Сможет ли он, например, среди отсканированных авиабилетов найти"все билеты, выданные на имя Саддам Хуссейн". И неужели он (СМ, не Хуссейн) и по-русски искать сможет? Да со словоформами с разными...
Сможет ... аналогично как в Oracle есть контекстный картридж ...
Мы его на казахском учили разговаривать .... ничё, сопротивлялся , а потом залапотал как будто с детства знал ...

C>Кстати, знаете новую неполиткорректную сказку? "Старик Хоттабыч". Как-там у него полное имя? Хассан Абурахман ибн Хаттаб

Здравствуйте, Sinclair, Вы писали:

S>Возник тут у нас достаточно специфический заказ на разработку.

Нда, заказ ещё тот. Похоже, что как это обычно у нас бывает, сверху вниз ничего дать не получается, поэтому на местах начали городить свои БД. В надежде пойти снизу вверх. Ну или как-то объединить "монстра", если будет что объединять.

У нас знакомые ребята тоже чего-то пишут, называется устроиться программистом в соответствующие органы.

По моему, тут заранее нужно готовится к нескольким циклам движения по спирали, потому что по мере внедрения системы и обкатки её на конечных пользователях будет много фидбека и желания систему доработать и доработать. Отсекать эти желания никак не получится, лучше уж совсем не браться за работу. Лучше сразу заложить это дело, с соответствующими финансовыми механизмами.

Знаешь, я тут вот подумал, что самое сложное в такой системе будет вовсе не её проектирование и написание, а скорее внедрение и поддержка. Потому что народ хорошо осваивает Ворд, Броузер и Электронную почту.

Ворд штука интересная, как тут уже писали, замечательно проверяет орфографию, что полезно и похвально. Но Ворд — это только один из способов представления только одной из сущностей — хорошо оформленного текста. Например, в документ можно вставлять картинки и даже распознавать текст на ней штатными средствами imaging. Но в то же время, сколько документов за один присест сжуёт Ворд с человеком по эту сторну монитора? Один-два-три сжуёт замечательно. Дальше компьютер подавится. Не говоря о человеке. Т.е. что хочу подчеркнуть — Ворд удобен для рассмотрения одного дела (скаляра), не для совокупности дел, коих может быть легион.

Броузер тут козырная штука — чему пример поисковик. Тут тебе и картинки, и тексты. Вообще, броузер изобретение замечательное. С помощью избранного можно сварганить свою иерархию материалов. Опять же поиск. Опять же киношные "набрал два слова" и тут же нашёл. Орфографию, правда, не проверяет, это недостаток. Но главное (на мой взгляд) — это online режим работы. Вот его главный недостаток. Он же достоинство, если посмотреть под другим углом.

Если вспомнить, что сети наши самые разные, хоть и стоят компьютеры у "сержантов ГИБДД", но к сети подключиться проблема великая (не говоря уже о Сети), то online режим броузера никак не канает. Конечно, сужу по своей области, может в столицах сетевые кабели что дождь за окном.

Но у нас есть ещё электронная почта. Оч. удобная штука. И пользователи просекают её юзать, правда делают это иногда спецефически, видимо наследие броузерных ящиков сказывается.

Давай посмотрим на электронную почту не так, как мы это привыкли ежедневно делать, а как на модель.

Но сначала вот о чём: мне так представляется, что пользователи у системы самые разные — есть сержанты (исполнители), которые вводят исходную информацию, есть аналитики, которые чего анализируют и обобщают, есть руководители, которым давай статистику, красочную и нужную. "Сержанты" дают пищу для работы всем, аналитики могут затребовать у "сержанта" сделать чего-нить дополнительно, "сержанты" сами неоднородные, например, осмотр места проишествия может привести к лабораторному анализу улик и появлению материалов анализа от экспертов суть которых тоже "сержант"-исполнитель. Получается поступление первички, формирование заданий в зависимоти от установленного порядка работы, контроль их выполнения, анализ и поиск аналогий, статистика всей работы или её части.

А теперь голословно заявлю, что электронная почта предоставляет для этого замечательный механизм. А если её (почту) обработать напильником, подключить к ней постоянную БД всех сообщений, а не только их передачу между адресатами — получим в первом приближении то, что надо.

Система получается иерархическая, в три уровня, если исходить, что третий уровень общегосударственный, его мы имеем ввиду, но делаем систему для своего региона. Второй уровень — центральный региональный архив. Это действующий узел, хранящий БД системы, её материалы, позволяющий вести аналитику, выдающий статистику работ. И конечно первый уровень — уровень "сержантов" системы.

Иметь национальный уровень нужно хотя бы потому, что если на местном уровне система "покатит", то и другим захочется внедрить такое "чудо" у себя, а это только на руку разработчику. И лучше об этом помечтать заранее и заложить в проект возможность стыковки.

Региональный уровень — основной. Очевидно, что централизованное хранилище удобно для контроля и анализа. Оно же должно быть доступно круглосуточно и всегда готово к работе. С этим уровнем в сеансах связи взаимодействует "сержантский" пользовательский уровень. Сеансы с поддержкой Интернет, свой собственный пул (у многих есть и работает), собственные выделенные сети на оптоволокне/радиоэзернет/витой паре — это отдельный разговор. TCP/IP поднять сейчас не большая проблема. Не верите? А мы вас Клиент-Банком помянем.

Вот сказал, что основной — второй уровень, а на самом деле исполнители — важное звено в системе. Чем быстрее они её освоят, и чем проще она будет — тем лучше.

Вот для них и делается подобие клиента email, только кроме собственно email этот клиент позволит "запростить" дело из центрального архива, завести дело, добавить туда чего, выдать и проконтролировать выполнение задания, организовать поиск онлайн или запросить материалы в сеансе связи на свой компьютер. Чем качественнее канал связи, тем больше и быстрее можно получить. Но при необходимости и dial-up тянет.

В клиенте предусмотреть формализованные формы, по заполнении которой, например, формируется "письмо-приказ" на заведение дела в центральном архиве. По мере внедрения будут новые доработки — новые формы, уточнения. Так же как и с email, клиент позволяет локально хранить материалы, прошедшие через пользователя. При необходимости, он их может потереть. Или снять из центрального архива заново. Само собой, в пределах своих прав.

Весь документооборот принудительно дублировать через клиент, полгода на освоение...

Здравствуйте, Sinclair, Вы писали:

S>Всем привет.
S>Возник тут у нас достаточно специфический заказ на разработку. Так вот нету у меня уверенности в том, какой дорогой последовать. В связи с чем хотелось бы выслушать мнение многоопытных коллег.

Платформу Lotus Domino не рассматривали?
ИМХО как раз его случай.

Здравствуйте, Sinclair, Вы писали:

S>Так что вот остановился я и призадумался. Может, ну ее — эту строгую типизацию?

Как насчет комбинации RDBMS с XML документами? Там где будет выигрыш от реляционной модели (сильно структурированную часть схемы, с частыми выборками по полям) — нормализуешь, остальное (слабоструктурированные данные) хранишь в текстовых полях в XML. А?

Здравствуйте, Gaperton, Вы писали:
G>Как насчет комбинации RDBMS с XML документами? Там где будет выигрыш от реляционной модели (сильно структурированную часть схемы, с частыми выборками по полям) — нормализуешь, остальное (слабоструктурированные данные) хранишь в текстовых полях в XML. А?
Думал уже. Ежели б только хранение и навигация, то я так и сделал бы — имел позитивный опыт. Но здесь еще и поиск нужон...

Здравствуйте, GarryIV, Вы писали:
GIV>Платформу Lotus Domino не рассматривали?
Re[2]: Мегапроблема архитектуры (полуструктурироваанные данн

Автор: Sinclair
Дата: 10.10.04

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:
G>>Как насчет комбинации RDBMS с XML документами? Там где будет выигрыш от реляционной модели (сильно структурированную часть схемы, с частыми выборками по полям) — нормализуешь, остальное (слабоструктурированные данные) хранишь в текстовых полях в XML. А?
S>Думал уже. Ежели б только хранение и навигация, то я так и сделал бы — имел позитивный опыт. Но здесь еще и поиск нужон...
Для поиска по XML можно попробовать следующее:
1) Полнотекстовый индекс.
2) Нечто вроде OLAP-звезд, по избранным полям XML. Если поле в документе присутствует — есть запись в таблице-индексе. Что-нибудь вроде такого.
3) Если позволяет сервак, пускать XPath по этим полям.

Второй вариант. Насколько я слышал, ООБД обладают выраженным преимуществом перед RDBMS как раз на слабоструктурированных данных. Не хочешь попробовать Gemstone? Я понимаю, что при отсутствии опыта с технологией делать на ней серьезный проект — это большой риск. Но если получится, можно выделить 2 человека и дать им делать в параллель прототип на Gemstone. Имеет смысл, ИМХО, т. к. возможно получится очень мягко и пушисто. Как еще опыт-то получить? А так — получите в long term конкурентное преимущество (эти два парня потом всех научат, если что).

Здравствуйте, Gaperton, Вы писали:
G>Для поиска по XML можно попробовать следующее:
G>1) Полнотекстовый индекс.
G>2) Нечто вроде OLAP-звезд, по избранным полям XML. Если поле в документе присутствует — есть запись в таблице-индексе. Что-нибудь вроде такого.
G>3) Если позволяет сервак, пускать XPath по этим полям.
В принципе можно. Хотя геморроя довольно много. Кроме того, не совсем ясно, как избавляться от нерелевантных ответов при full-text: как мне найти город Иваново, не найдя всех Иванов, Ивановых, и улицу Иванова? И наоборот.

G>Второй вариант. Насколько я слышал, ООБД обладают выраженным преимуществом перед RDBMS как раз на слабоструктурированных данных. Не хочешь попробовать Gemstone? Я понимаю, что при отсутствии опыта с технологией делать на ней серьезный проект — это большой риск. Но если получится, можно выделить 2 человека и дать им делать в параллель прототип на Gemstone. Имеет смысл, ИМХО, т. к. возможно получится очень мягко и пушисто. Как еще опыт-то получить? А так — получите в long term конкурентное преимущество (эти два парня потом всех научат, если что).
Жаль, но боюсь ничего не выйдет. Дело в том, что мы должны дать оценку стоимости до начала проекта, а оценивать неизвестную технологию я не возьмусь. Так бы — с удовольствием!

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:
G>>Для поиска по XML можно попробовать следующее:
G>>1) Полнотекстовый индекс.
G>>2) Нечто вроде OLAP-звезд, по избранным полям XML. Если поле в документе присутствует — есть запись в таблице-индексе. Что-нибудь вроде такого.
G>>3) Если позволяет сервак, пускать XPath по этим полям.
S>В принципе можно. Хотя геморроя довольно много. Кроме того, не совсем ясно, как избавляться от нерелевантных ответов при full-text: как мне найти город Иваново, не найдя всех Иванов, Ивановых, и улицу Иванова? И наоборот.

Ну например так. Запрос в две стадии пускаешь. Сначала полнотекстовым индексов находишь всех ивановых, включая города. Далее, среди результатов простой переборный поиск с честным разбором XML — фильтруешь лишнее. Если сервак позволяет писать логику на нормальных языках, типа Java etc, то должно получится вполне сносно. Тут прототип надо писать, на знаю насколько быстро получится.

Еще один (мне кажется, самый разумный) вариант — поискать продукты для управления XML документами — какие-нибудь Native XML Databases. http://www.rpbourret.com/xml/XMLDatabaseProds.htm Там проблемы с грамотным поиском должны быть решены, что хорошо — их самому решать не придется. На первый взгляд, это подошло бы лучше всего. Как думаешь?

Кстати, не хочешь написать здесь отчет, какой подход в конце концов выбрали? Интересно, задачка та еще.

Здравствуйте, s.ts, Вы писали:

ST>Hello, Sinclair!

ST>УСХ (универсальная структура хранения) тормозить будет нещадно. Пробовали. Но на оракле.
Можно отказаться от РСУБД. Воспользуйтесь гениальным новым изобретением велосипеда от www.prevayler.org ! Это вполне приемлемый подход для такой неортодоскальной задачи.

Л>А отчёты это уже дело техники!
Л>Lotus это Наследие mainframe'ов и тяжёлых машин

Какие жопу в mainframe. Lotus вырос из писюков...

Здравствуйте, <Аноним>, Вы писали:

Л>>А отчёты это уже дело техники!
Л>>Lotus это Наследие mainframe'ов и тяжёлых машин
А>Какие жопу в mainframe. Lotus вырос из писюков...

История Lotus Notes началась с одной из первых компьютерных программ, написанных в CERN (Computer-based Education Research Laboratory — Лаборатория по исследованию процессов обучения с примененем компьютеров), в университете Иллинойса (University of Illinois). В 1973 был выпущен продукт, получивший название PLATO Notes.

PLATO Group Notes были популярны в конце 70-х, начале 80-х, и только с изобретением IBM'ом персонального компьютера и появления MS-DOS от Microsoft в 1982 году привели к снижению эффективности использования main-frame приложений, каковым являлись и PLATO Group Notes.

Такая вот жопа с маинфреймами!

Здравствуйте, Victor Repetsky, Вы писали:

VR>Еще делали спейциальный интрефейс для редактирования/просмотра сущностей и их связей в визуальном режиме — сущности как иконки, связи как стрелочки (наряду с умными запросами — очень мощное средство).

Я сейчас занимаюсь подобной задачей.

Что представляли из себя "умные запросы" ? Генерация SQL/выражений для полнотекстового поиска на основе метаинформации о сущностях и связях ? Был разработан специальный язык запросов или запрос составлялся с помощью визарда (типа MSQuery) или графического визарда типа описанного выше интерфейса ?

Заранее спасибо

Здравствуйте, Sinclair, Вы писали:

S>Возник тут у нас достаточно специфический заказ на разработку.
http://www.framerd.org/

Здравствуйте, fuxx, Вы писали:
S>>Возник тут у нас достаточно специфический заказ на разработку.
F>http://www.framerd.org/
Интересная фигня... Настораживает, правда, написатость на ANSI C... А также непонятные утверждения о поддержке указателей "в отличие от других OODBMS"... Будем смотреть...

Здравствуйте, EM, Вы писали:

EM>Я имел отношение к разработке такого классификатора...

Интересно. И что лежало в вашей разработке во главе угла? По каким параметрам происходила классификация?

Здравствуйте, Sinclair, Вы писали:

S>Вот возник у нас неприятный случай. Злоумышленник причинил некоторый ущерб. Начинается расследование, которое должно этот ущерб вернуть. И тут есть три основных задачи:
S>1. Отслеживать ход расследования. Ну типа дело начато тем-то, ответственным назначен такой-то, передано тому-то в связи с тем-то и т.п. Типичный workflow processing.
S>2. Хранение разнообразных данных. Свидетели, улики, подозреваемые, адреса и т.п. Все в центральном сервере, так чтобы из региональных филиалов все стекалось и искалось.
S>3. Могучая поисковая енжина. С таким интеллектом, чтобы пользоваться ей мог даже сержант ГИБДД. Ну типа повводили мы данных, а система нам и говорит "ага, мои любезные, хочу вам подсказать, что аналогичный случай имел место в городе Одесса. В связи с чем рекомендую обратить внимание на...". Причем не только не требуя от пользователя нудного указания условий поиска, а лучше и вообще безо всякой инициативы.
S>4. Отслеживать статистику по расследованиям — ну там типа среднее время закрытия дела, средний процент возврата ущерба, общая сумма ущерба по сравнению с аналогичным периодом прошлого года и т.п.

Думаю, что необходимо выделить явные сущности и определить для них обязательные атрибуты. Для сущностей, которые имеют большое количество специфичных атрибутов, можно сделать сохранение некоего артифакта (фотография, отпечаток пальца и т.п.), а так же список специфичных атрибутов (можно и структурированный, если хранить в XML — это даже поможет движку поиска). Список специфичных атрибутов можно определять в соотвестствии с набором расширяемых шаблонов, которые позволят форматировать и вводить дополнительную информацию.
Более подробно можно покопать в направлении docflow, там часто возникают подобные задачи, так что найти решение будет проще.

Здравствуйте, stasukas, Вы писали:

S>Думаю, что необходимо выделить явные сущности и определить для них обязательные атрибуты. Для сущностей, которые имеют большое количество специфичных атрибутов, можно сделать сохранение некоего артифакта (фотография, отпечаток пальца и т.п.), а так же список специфичных атрибутов (можно и структурированный, если хранить в XML — это даже поможет движку поиска). Список специфичных атрибутов можно определять в соотвестствии с набором расширяемых шаблонов, которые позволят форматировать и вводить дополнительную информацию.
S>Более подробно можно покопать в направлении docflow, там часто возникают подобные задачи, так что найти решение будет проще.
Спасибо, примерно к такому мы и пришли.

Здравствуйте, Sinclair, Вы писали:

Для хранения разносторонних данных о предметной области можно использовать так называемые онтологии
(см. например систему управления базами знаний протеже http://protege.stanford.edu/),
а также всякого рода семантические сети.

Другие ключевые слова: DAML + OIL (http://www.ontoknowledge.org/oil/)
RDF (http://www.w3.org/RDF/)
knowledge representation

Здравствуйте, Sinclair, Вы писали:


AVK>>А смысл все это хранить?
S>Я же объяснял — поиск. Ну типа того, что вот обнаружили поддельную банкноту. Пока это картинка, цена ей — нуль. А как только мы в систему номер купюры вбили, появляется шанс найти случаи предъявления таких же купюр. (Афаик, поддельные деньги разнообразием номеров не отличаются).


На данный момент самая мощная и универсальная база данных-знаний это Google. Там бывает легче найти информацию, чем в MSDN,различных хелпах, специализированных программах-справочниках.


Вот одна из найденых ссылок по такому запросу: "номер фальшивой банкноты"

В настоящее время выявлены фалшивые банкноты номиналом 10 гривен со следующими номерами:
1750104051; 2151188067; 4215311880; 4215317785; 6539776529; 8506899032; 9438344911; 9662130061.

А хранятся ли в Google специальные атрибуты номера банкнот? Конечно нет.

Это к тому что может не о структуре SQL таблиц сначала думать а о концепции. Может задача почти не для реляционных БД. Маленькая часть реляционная, а остальное навороченые поисковые технологии (не имеющие отношения к SQL).