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

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

Начинаем проектировать. Ага, сущностей-то — всего ничего: дело, персона, улика, да прочий материал.

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

В общем мораль такая: что-то не очень у меня выходит нарисовать строго типизированную модель.

А главное — не факт, что это надо!
С точки зрения п.2, фиксация любой структуры — это
а) наличие нуднейшей формы, в которой большинство полей не заполняются никогда
б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.

Таким образом, возникает острое желание заменить это моделью, в которой с любым объектом можно проассоциировать любые именованные атрибуты. Атрибут соответственно может быть либо скаляром, либо вектором. При этом скаляр может быть значением, а может быть и ссылкой.
В общем, чистый джаваскрипт.

Однако смущает меня три вопроса:
1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?
2. Как насчет пункта 3?
В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
а) похожих людей (сходство по любому атрибуту)
б) похожие места (в смысле адреса)
в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
3. Как быть с пунктом 4? Статистика вроде хорошо ездит по структурированным данным, а как быть со слабоструктурированными — я что-то даже не соображу.


0. Ну и, конечно, как забабахать пристойнй гуй к такой системе, где мы не очень-то чего можем сказать об ее элементах.


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

Hello, Sinclair!

УСХ (универсальная структура хранения) тормозить будет нещадно. Пробовали. Но на оракле.
К тому же тут придется делать или эмулировать кросс-таб запросы (не всегда ведь клиента устроит таблица из 2-х столбцов — нужно и группировать). А это уже гораздо хуже статического джойна.
Как я понимаю, заковыка в том, что на этапе проектирования системы все сущности не известны. Т.о. пользователь должен уметь вводить и/или расширять сущности, на основе которых генерируются обычные таблицы. Дальше можно накручивать наследование и т.п.
Для каждого поля нужно определить пользовательский тип (типа домена, но с большей информацией). По полям одного типа и собирается статистика, независимо от того, в какой сущности они находятся. Т.е. при сборе статистики сначала ищутся сущности, которые подходят под описание, потом уже в тих сущностях ищутся объекты.

Это все как вариант.

Тут еще ведь специфика в том, что запросы наверное производятся гораздо чаще, чем модификации, так что одна таблица вряд ли покатит.

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

S>И тут как начал я встревать со страшной силой... Во-первых, любая персона (ну кроме следователя) может быть как физическим лицом так и юридическим. Ладно, полиморфизм в БД мы уже проходили.

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

S> Во-вторых, всяких атрибутов у ней может быть превеликое множество. А может и вовсе не быть.

Стандартное решение — подчиненная табличка с двумя полями — свойство и значение.

S>С уликами и того хуже. Ну вот например приобщили мы к делу скан поддельного чека. Ну так это банально картинка, про которую ничего хорошего сказать не получается. По уму надо бы сохранить номер чека, название банка, ну и т.д. что там на чеке написано.

А смысл все это хранить?

S> А закавыка-то в том, что таких типов улик — множество превеликое, кое и перечислить-то никакой силы нет.

Текстовый файл, xml-файл, вордовый файл.

S>Однако смущает меня три вопроса:
S>1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?

Будет. Индексов то ты практически никаких построить не сможешь. Плюс будут постоянные локи на индексе objectID.

Думаю тебе пригодится опыт, накопленный ИИ (если более узко, то ЭС).
Там это типичный случай, когда данные неполны, а то и противоречивы.

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

ST>Hello, Sinclair!

ST>УСХ (универсальная структура хранения) тормозить будет нещадно. Пробовали. Но на оракле.
И насколько тормозило? И что именно — навигация, статистика, или модификация?
ST>К тому же тут придется делать или эмулировать кросс-таб запросы (не всегда ведь клиента устроит таблица из 2-х столбцов — нужно и группировать). А это уже гораздо хуже статического джойна.
Да вроде как везде — банальная навигация. Типа "Покажи все кейзы, на которые я назначен". Точнее, "сгруппировав отдельно открытые и закрытые".
А кросстабы начинаются исключительно в отчетах. (Hope ).
ST>Как я понимаю, заковыка в том, что на этапе проектирования системы все сущности не известны. Т.о. пользователь должен уметь вводить и/или расширять сущности, на основе которых генерируются обычные таблицы. Дальше можно накручивать наследование и т.п.
ST>Для каждого поля нужно определить пользовательский тип (типа домена, но с большей информацией). По полям одного типа и собирается статистика, независимо от того, в какой сущности они находятся. Т.е. при сборе статистики сначала ищутся сущности, которые подходят под описание, потом уже в тих сущностях ищутся объекты.
Интересная идея. Похоже, должно покатить.
ST>Это все как вариант.

ST>Тут еще ведь специфика в том, что запросы наверное производятся гораздо чаще, чем модификации, так что одна таблица вряд ли покатит.
Ага. Навскидку — примерно этак один к десяти. Похоже, сделаем так, чтобы часть данных была вынесена в статику, а часть — в полуструктурку.

Здравствуйте, AndrewVK, Вы писали:
AVK>Обычно с полиморфизмом тут не мудрят, а просто вводят новую сущность, которая ссылается либо на одно, либо на другое.
Ну я про это и говорю. Хотя подобных referential constraints реляционной моделью не предусмотрено.
S>> Во-вторых, всяких атрибутов у ней может быть превеликое множество. А может и вовсе не быть.
AVK>Стандартное решение — подчиненная табличка с двумя полями — свойство и значение.
Я на эту тему уже и подумал. Вот только возникает трабл — если вносить туда всё, то пользователь устанет кажный раз указывать список полей и значений. Ну и перформанс опять же. А если не всё, то что?
S>>С уликами и того хуже. Ну вот например приобщили мы к делу скан поддельного чека. Ну так это банально картинка, про которую ничего хорошего сказать не получается. По уму надо бы сохранить номер чека, название банка, ну и т.д. что там на чеке написано.

AVK>А смысл все это хранить?
Я же объяснял — поиск. Ну типа того, что вот обнаружили поддельную банкноту. Пока это картинка, цена ей — нуль. А как только мы в систему номер купюры вбили, появляется шанс найти случаи предъявления таких же купюр. (Афаик, поддельные деньги разнообразием номеров не отличаются).
Прикол в том, чтобы как-то добиться приемлемой релевантности.
Я боюсь, что если дать вводить произвольные атрибуты, то мы никаких сопоставлений сделать не сможем. Типа у одного подозреваемого GivenName/Surname, а у другого — FirstName/LastName.
S>> А закавыка-то в том, что таких типов улик — множество превеликое, кое и перечислить-то никакой силы нет.
AVK>Текстовый файл, xml-файл, вордовый файл.
Не вижу решения. Я-то могу писать в чем угодно из перечисленного. А как насчет а) поиска по всему этому б) усёр интерфейса для сержантов ГИБДД в) отчетов и статистики?
S>>1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?
AVK>Будет. Индексов то ты практически никаких построить не сможешь. Плюс будут постоянные локи на индексе objectID.
От именно. И как же мне тут быть?

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

B>Думаю тебе пригодится опыт, накопленный ИИ (если более узко, то ЭС).
B>Там это типичный случай, когда данные неполны, а то и противоречивы.
Вот боюсь что экспертная система мне тут никак не пригодится. По крайней мере, с глубин своего невежества я не вижу способов пристегнуть сюда такую систему.

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

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

S>Таким образом, возникает острое желание заменить это моделью, в которой с любым объектом можно проассоциировать любые именованные атрибуты. Атрибут соответственно может быть либо скаляром, либо вектором. При этом скаляр может быть значением, а может быть и ссылкой.

Ну, собственно, примерно так это и выглядит.
Если в лоб, то есть таблица атрибутов, есть таблица описания сущности по этим атрибутам.
При заведении новой сущности, атрибуты создаются с описанием первого экземпляра, для последующих экземпляров атрибуты уже есть. А поиск идет по одинаковым атрибутам.
Можно ввести группы сущностей и привязывать атрибуты к группам, таким образом, что все сущности из одной группы обладают одним и тем же набором атрибутов.

Здравствуйте, Sinclair!

Мне думается, что стоит рассмотреть вариант обработки и хранения простого текста. Возможно, стоит выделить еще несколько сущностей (физическое лицо, юридическое лицо, документ, адрес). Остальную информацию хранить в виде текста. В GUI следует предусмотреть возможность пользователю выделять фрагменты текста — ключевые понятия. Кроме того, дать возможность классифицировать весь текст по категориям, задаваемым пользователем. Это даст возможность, как полнотекстового поиска, так и быстрого поиска по ключевым словам.
Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте. В качестве поисковой машины следует использовать что-то вроде Яндекса. После ввода текста его можно опционально классифицировать по категориям. Для упрощения работы с ключевыми понятиями можно в редакторе текста предусмотреть шаблоны, в которых можно сделать специальные подсказки, на что следует обратить внимание при составлении документа. Из разметки шаблона можно вытащить атрибуты сущностей адрес, документ и пр. Кроме того, если Ваш клиент милиция (прокуратура, таможня…) или выходцы из нее, то Вы столкнетесь еще и с ужасающей безграмотностью. Поэтому в качестве основного инструмента предлагаю использовать уже знакомый им Word со встроенной проверкой грамотности.

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

S>>> Во-вторых, всяких атрибутов у ней может быть превеликое множество. А может и вовсе не быть.
AVK>>Стандартное решение — подчиненная табличка с двумя полями — свойство и значение.
S>Я на эту тему уже и подумал. Вот только возникает трабл — если вносить туда всё, то пользователь устанет кажный раз указывать список полей и значений.

Зависит от GUI. Удобство пользовательского ввода это не вопрос структуры БД.

S> Ну и перформанс опять же.

По крайней мере он будет лучше чем в том варианте, что предложил ты.

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

Ну тогда точно нужно что то на базе XML, иначе сложность анализатора будет запредельной и врать он будет как сивый мерин. Структура XML? Ну это отдельная песня. Тут все же надо попытаться найти среди всех улик что то общее.

S>Я боюсь, что если дать вводить произвольные атрибуты, то мы никаких сопоставлений сделать не сможем. Типа у одного подозреваемого GivenName/Surname, а у другого — FirstName/LastName.

Это решается набором справочников. Справочник свойств, справочник семантических признаков свойств и т.п.

AVK>>Текстовый файл, xml-файл, вордовый файл.
S>Не вижу решения. Я-то могу писать в чем угодно из перечисленного. А как насчет а) поиска по всему этому

Придется видимо писать свой индексатор, вряд ли что то готовое подойдет под предъявляемые тобой требования.

S>б) усёр интерфейса для сержантов ГИБДД в) отчетов и статистики?

"Зависит от GUI. Удобство пользовательского ввода это не вопрос структуры БД." (С)я.

AVK>>Будет. Индексов то ты практически никаких построить не сможешь. Плюс будут постоянные локи на индексе objectID.
S>От именно. И как же мне тут быть?

Урезать осетра

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

S>Вот боюсь что экспертная система мне тут никак не пригодится. По крайней мере, с глубин своего невежества я не вижу способов пристегнуть сюда такую систему.

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

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

AVK>>Текстовый файл, xml-файл, вордовый файл.
S>Не вижу решения. Я-то могу писать в чем угодно из перечисленного. А как насчет а) поиска по всему этому б) усёр интерфейса для сержантов ГИБДД в) отчетов и статистики?

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

Hello, Sinclair!
You wrote on Thu, 07 Oct 2004 13:37:09 GMT:

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

ST>> Hello, Sinclair!

ST>> УСХ (универсальная структура хранения) тормозить будет нещадно.
ST>> Пробовали. Но на оракле.
S> И насколько тормозило? И что именно — навигация, статистика, или
S> модификация?

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


ST>> Тут еще ведь специфика в том, что запросы наверное производятся
ST>> гораздо чаще, чем модификации, так что одна таблица вряд ли покатит.
S> Ага. Навскидку — примерно этак один к десяти. Похоже, сделаем так, чтобы
S> часть данных была вынесена в статику, а часть — в полуструктурку.

И так тоже можно. В итоге все равно и у нас получился гибрид. Но эти самые полуструктурки получились уже в конце. Костяк — структурные данные. Главное, чтобы не получилось, что большАя (уж не говоря про бОльшую) часть информации (по объему) хранилась в одной таблице.

Hello, Sinclair!

AVK>> Будет. Индексов то ты практически никаких построить не сможешь. Плюс
AVK>> будут постоянные локи на индексе objectID.
S> От именно. И как же мне тут быть?

Блокировочник ?

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

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

B>>Думаю тебе пригодится опыт, накопленный ИИ (если более узко, то ЭС).
B>>Там это типичный случай, когда данные неполны, а то и противоречивы.
S>Вот боюсь что экспертная система мне тут никак не пригодится.

Речь не о самой ЭС, а о том, как в них могут быть представлены знания и данные.
Это как раз тебе и могло бы пригодится.
Проблемы с представлением и использованием
противоречивых и неполных данных — это классика в ЭС.

Hello, bkat!

b> Речь не о самой ЭС, а о том, как в них могут быть представлены знания и
b> данные. Это как раз тебе и могло бы пригодится.
b> Проблемы с представлением и использованием
b> противоречивых и неполных данных — это классика в ЭС.

Кстати, накидай плиз ссылок на это.

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

ST>Hello, bkat!

b>> Речь не о самой ЭС, а о том, как в них могут быть представлены знания и
b>> данные. Это как раз тебе и могло бы пригодится.
b>> Проблемы с представлением и использованием
b>> противоречивых и неполных данных — это классика в ЭС.

ST>Кстати, накидай плиз ссылок на это.

На это надо время...
Это все в основном научные статьи, за которыми я уже не наблюдаю.
Но все крутится вокруг метамоделей.
Каждый конретный случай, который надо отслеживать
Sinclair'у — это экземпляр этой метамодели ситуаций.
Экземпляр может быть недоопределен и уточняться по ходу.

В общем задачи примерно следующие:
1) Описать метамодель. Гиперграфы — один из способов.
2) Описать, как порождать экземпляр метамодели (это уже будет некий взвешенный граф)
3) Научиться сравнивать два экземпляра метамодели.
Такое сравнение можно проводить только постоянно имея ввиду метамодель.

В общем задача хоть и классическая для ИИ, но все равно очень сложная и нетривиальная.
Обсуждать ее в деталях на форуме довольно проблематично.
Но подходы вполне можно обсудить
То, что делают в ЭС — это один из подходов, но конечно же не единственный.

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

ST>УСХ (универсальная структура хранения) тормозить будет нещадно. Пробовали. Но на оракле.
Работаю с полицейскими системами с 97 года, другие подходы кроме усниверсального не работают.
Каждый месяц могут требоватся новые атрибуты.
Как правильно сказал господин Merle, и как было сказано в исходном посте,
нужна метабаза и аттрибуты (деталировка).
При правильной реализации ничего не тормозит. На Оракле. Пробовали
Пример сущности лицо:
таблица установочный данных: ид, фио, дата, место рождения, пол;
таблица деталировки: ид лица, тип атрибута, занчение атрибута (несколько типов).
Преимущество в том что атрибуты можно добавлять в рантайме,
на скорости поиска это не сказывается. Кроме того можно задавать
множественные атрибуты и почти все что можно придумать туда ложится.

Всего хорошего.
Виктор.

Ксати, у вас в Новосибирске спецов по таким вещам должно быть много...

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

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

Вот что пришло в голову. С одной стороны хочется строгой типизации — и чтобы запросы по человечески строить и индексы и чтобы проверку значений можно было при вводе производить ( ну скажем номера тех же паспортов должны удовлетворять определенным правилам по количеству символов, может быть что-то ещё более сложное). A с другой стороны как уже упоминалось есть большая вероятность того что будут добавляться новые атрибуты и изменяться существующие. Это очень похоже на реализацию службы каталогов. Давайте посмотрим скажем на Active Directory — в ней введено понятие схемы, то есть более или менее объектно-ориентированного описания сущностей и атрибутов этих сущностей в системе. Для каждого атрибута, в частности записывается является ли этот атрибут Indexed, описывается его SYNTAX( строка, число или что-то ещё). При этом придается средство (впрочем конкретно для самой AD не очень удобное) изменения стандартной схемы — добавления новых атрибутов и изменения существующих.
Ну вот собственно ...

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

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

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

А>Вот что пришло в голову.
Это был я, а не Аноним

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

S>1. Отслеживать ход расследования. Ну типа дело начато тем-то, ответственным назначен такой-то, передано тому-то в связи с тем-то и т.п. Типичный workflow processing.
Кстати какой workflow? Потому-что если он явно "продвинутый" тогда он может упереться в слабоструктурированные данные ...

S>3. Могучая поисковая енжина. С таким интеллектом, чтобы пользоваться ей мог даже сержант ГИБДД. Ну типа повводили мы данных, а система нам и говорит "ага, мои любезные, хочу вам подсказать, что аналогичный случай имел место в городе Одесса. В связи с чем рекомендую обратить внимание на...". Причем не только не требуя от пользователя нудного указания условий поиска, а лучше и вообще безо всякой инициативы.
По каким принципам выявляются совпадения? Наверное имеет смысл составить табличку соответсвий при подобном поиске!
Идея сводиться к тому чтобы попытаться выйти на какой-то обозримый набор структурированной информации, через предметную область ....

S>4. Отслеживать статистику по расследованиям — ну там типа среднее время закрытия дела, средний процент возврата ущерба, общая сумма ущерба по сравнению с аналогичным периодом прошлого года и т.п.
Итак, список структурированных сущностей и аттрибув всё растёт и растёт

S>Начинаем проектировать. Ага, сущностей-то — всего ничего: дело, персона, улика, да прочий материал.
А как-же те самые улики о которых речь ниже ... вот их-то как-раз немерено

S>В общем мораль такая: что-то не очень у меня выходит нарисовать строго типизированную модель.

S>А главное — не факт, что это надо!
S>С точки зрения п.2, фиксация любой структуры — это
S>а) наличие нуднейшей формы, в которой большинство полей не заполняются никогда
S>б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.
И ещё проблема на основе какой информации формировать форму? или при добавлении аттрибута к какому-то типу улики делать очередной релиз

S>Таким образом, возникает острое желание заменить это моделью, в которой с любым объектом можно проассоциировать любые именованные атрибуты. Атрибут соответственно может быть либо скаляром, либо вектором. При этом скаляр может быть значением, а может быть и ссылкой.
вот мы и подобрались к самому интересному
S>В общем, чистый джаваскрипт.
не совсем понял причём здесь JavaScript но у фиг с ним ...

S>Однако смущает меня три вопроса:
S>1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?
ни в коем случае ... ужас какой-то !!!
S>2. Как насчет пункта 3?
S>В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
S>а) похожих людей (сходство по любому атрибуту)
S>б) похожие места (в смысле адреса)
S>в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
S>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
ага, уже занялись структурированием ...


S>Так что вот остановился я и призадумался. Может, ну ее — эту строгую типизацию?
Какой-то странный вывод? Ну допустим выкинули мы строгую типизацию ... и чё дальше?

Ладно поумничал , теперь попробую изложить свою точку зрения.

Факты:
1. Есть некоторый набор элементов которые не подвержены изменению структуры
2. Есть наоборот которые очень часто изменяются
3. Нужен поиск, более детально это конструктор поисковых запросов, а в идеале аналитическая система или что-то в этом роде
4. И с этим нужно как-то работать

Если попробовать создать метоописание для данных объектов?
Тоесть в реляционке имеется табличка "Элементы" (ID, Имя, Описание, ...)
Имеется табличка "Аттрибуты" (ID, ID Элемента, Имя, Описание, Тип значения, Размерность, Индексированно, Уникально, и т.д. ...)

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

Добавление новой записи в таблицу Аттрибутов влечёт за собой добавление столбца в соответсвующую таблицу БД
При добавление записи в Таблицу Элементы создаётся новая таблица в БД ...

Тем самым у тебя имеется как сама метамодель данных, так и её структурированное представление в реляционной модели ...
Естественно под всё это нужен дизайнер (или конструктор в зависимости от семантических наклонностей , это так лирическое отступление)

Прикручивать аналитическую систему к структурированным данных оно гораздо приятнее !!!

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

ST>Блокировочник ?
Угу. MS SQL 2000 с перспективой перейти на 2005.

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

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

Л>Кстати какой workflow? Потому-что если он явно "продвинутый" тогда он может упереться в слабоструктурированные данные ...
А вот хрен его знает. С одной стороны, вроде бы описали простой, но в описании упомянуто "настраиваемый". В жизни не поверю, что они захотят что-то там настраивать. Так что скорее всего речь идет именно о передаче дела из одних рук в другие. Статусов пока известно всего два — дело открыто и дело закрыто.

Л>По каким принципам выявляются совпадения?
Хороший вопрос. Вот именно это нам и предстоит изобрести. Ясна проблема — информация, доступная в настоящее время, разрознена. Это замедляет расследования. Поэтому надо самим придумать способ поиска похожих сущностей.
Л>Наверное имеет смысл составить табличку соответсвий при подобном поиске!
Это я не очень понял. Ты имеешь в виду сохранение результатов поиска вместе с делом?
Л>Идея сводиться к тому чтобы попытаться выйти на какой-то обозримый набор структурированной информации, через предметную область ....
Так вот пакость-то в том, что основную часть структуры я уже выписал. А все остальное — прикладной материал.
Л>Итак, список структурированных сущностей и аттрибув всё растёт и растёт
Ага.
Л>А как-же те самые улики о которых речь ниже ... вот их-то как-раз немерено
Вот как только мы переходим от абстрактной улики к ее конкретным типам возникает та самая немерянность.
S>>б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.
Л>И ещё проблема на основе какой информации формировать форму? или при добавлении аттрибута к какому-то типу улики делать очередной релиз
Ага. Тоже трабл.
Л>не совсем понял причём здесь JavaScript но у фиг с ним ...
А там классов нет. Есть только прототипы. И к любому объекту можно приклеить любой атрибут. При этом есть некоторые прототипы, выданные сразу при запуске.
S>>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
Л>ага, уже занялись структурированием ...
Это ты full-text назщываешь структурированием?

Л>Факты:
Л>1. Есть некоторый набор элементов которые не подвержены изменению структуры
Да.
Л>2. Есть наоборот которые очень часто изменяются
Да.
Л>3. Нужен поиск, более детально это конструктор поисковых запросов, а в идеале аналитическая система или что-то в этом роде
Ну, я не знаю насчет конструктора. Конструктор тут ребята уже сделали. Я бы их уволил. Этим конструктором и человек с высшим образованием-то пользоваться не сможет. Если это не MS in CS.
Л>Если попробовать создать метоописание для данных объектов?
Элемент у тебя — класс или объект?
Л>Тоесть в реляционке имеется табличка "Элементы" (ID, Имя, Описание, ...)

Л>Имеется табличка "Аттрибуты" (ID, ID Элемента, Имя, Описание, Тип значения, Размерность, Индексированно, Уникально, и т.д. ...)

Л>Соответсвенно для каждого "Элемента" (в твоём случае это в основном улика, насколько я понимаю) есть некоторый набор аттрибутов ...
Л>Какждый Элемент имеет физическое отражение в БД в виде таблицы, соответственно Аттрибуты имеют отражение в БД как столбцы соответствующей таблицы ...
Ага, значит, все-таки класс.
Л>Добавление новой записи в таблицу Аттрибутов влечёт за собой добавление столбца в соответсвующую таблицу БД
Л>При добавление записи в Таблицу Элементы создаётся новая таблица в БД ...
Не, тогда эти две таблицы нафиг не уперлись. В СУБД такие уже есть.
Л>Тем самым у тебя имеется как сама метамодель данных, так и её структурированное представление в реляционной модели ...
Л>Естественно под всё это нужен дизайнер (или конструктор в зависимости от семантических наклонностей , это так лирическое отступление)
Ну так вот проблема, как я предчувствую, будет именно в том, что пользователь этого конструктора должен хорошо себе представлять, что он делает.
Далее проблема будет в том, что разные типы улик будут лежать в разных таблицах. Потому, что образ памяти конфискованного PDA — это одно, а скан фальшивого чека — это другое. Да еще и ездить взад-вперед. В связи с обнаружением новых деталей в ходе расследования. И нам придется как-то их собирать.
Тут же у нас встанет проблема наследования. Т.к. поиск имени, например, нам желательно вести везде, где можно. А из самой простой бытовой практики известно, что оно может встречаться на самых разных документах.

Л>Прикручивать аналитическую систему к структурированным данных оно гораздо приятнее !!!
Это да. Но вот ты фактически предложил перевалить структурирование данных на пользователей. Знаешь, я человек скромный, но если сейчас я не могу провести это структурирование, то и пользователи потом точно не смогут.

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

L>Это был я, а не Аноним
Спасибо за ответ. Но я так понял, что Active Directory — строгоструктурированная схема. И основное ее отличие от SQL в том, что она иерархическая.

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

__>Мне думается, что стоит рассмотреть вариант обработки и хранения простого текста. Возможно, стоит выделить еще несколько сущностей (физическое лицо, юридическое лицо, документ, адрес). Остальную информацию хранить в виде текста. В GUI следует предусмотреть возможность пользователю выделять фрагменты текста — ключевые понятия.
Идея классная. Мне нравится.
__>Кроме того, дать возможность классифицировать весь текст по категориям, задаваемым пользователем. Это даст возможность, как полнотекстового поиска, так и быстрого поиска по ключевым словам.
Хм, ты не мог бы пояснить, что ты понимаешь под классификацией по категориям?
__>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.
__>В качестве поисковой машины следует использовать что-то вроде Яндекса.
Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
__>После ввода текста его можно опционально классифицировать по категориям. Для упрощения работы с ключевыми понятиями можно в редакторе текста предусмотреть шаблоны, в которых можно сделать специальные подсказки, на что следует обратить внимание при составлении документа. Из разметки шаблона можно вытащить атрибуты сущностей адрес, документ и пр.
__>Кроме того, если Ваш клиент милиция (прокуратура, таможня…) или выходцы из нее, то Вы столкнетесь еще и с ужасающей безграмотностью. Поэтому в качестве основного инструмента предлагаю использовать уже знакомый им Word со встроенной проверкой грамотности.
Вот это ты в самую точку угадал! Spellchecker был отдельной строкой потребован в ТЗ с самого начала!

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

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

ST>>УСХ (универсальная структура хранения) тормозить будет нещадно. Пробовали. Но на оракле.
VR>Работаю с полицейскими системами с 97 года, другие подходы кроме усниверсального не работают.
VR>Каждый месяц могут требоватся новые атрибуты.
VR>Как правильно сказал господин Merle, и как было сказано в исходном посте,
VR>нужна метабаза и аттрибуты (деталировка).
VR>При правильной реализации ничего не тормозит. На Оракле. Пробовали
VR>Пример сущности лицо:
VR>таблица установочный данных: ид, фио, дата, место рождения, пол;
VR>таблица деталировки: ид лица, тип атрибута, занчение атрибута (несколько типов).
VR>Преимущество в том что атрибуты можно добавлять в рантайме,
VR>на скорости поиска это не сказывается. Кроме того можно задавать
VR>множественные атрибуты и почти все что можно придумать туда ложится.
О, вот это очень похоже на то, как я себе это представляю. Особенно про множественность — там почти все может быть множественным. Адреса, имена, телефоны...
А классификацию вы как-то вводили? Т.е. возможность одним взмахом руки добавить целый набор взаимосвязанных атрибутов в сущность?

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

Л>>По каким принципам выявляются совпадения?
S>Хороший вопрос. Вот именно это нам и предстоит изобрести. Ясна проблема — информация, доступная в настоящее время, разрознена. Это замедляет расследования. Поэтому надо самим придумать способ поиска похожих сущностей.
А если управлять связями? Выделять их в группы, накладывать на них общие правила? И искать уже на оснолве этой информации?

Л>>Наверное имеет смысл составить табличку соответсвий при подобном поиске!
S>Это я не очень понял. Ты имеешь в виду сохранение результатов поиска вместе с делом?
Нет. Это ис предыдушего абзаца, имелось ввиду: выявить по какому принципу (набору аттрибутов) идёт соответсвие при поиске. Тоесть Номер клеше, соотноситься с диапазоном номеров денежных купюр, номером корр счёта, куда были ушли деньги и т.п. (пример абстрактный)

Л>>А как-же те самые улики о которых речь ниже ... вот их-то как-раз немерено
S>Вот как только мы переходим от абстрактной улики к ее конкретным типам возникает та самая немерянность.

Л>>не совсем понял причём здесь JavaScript но у фиг с ним ...
S>А там классов нет. Есть только прототипы. И к любому объекту можно приклеить любой атрибут. При этом есть некоторые прототипы, выданные сразу при запуске.
Всё, теперь понял!

Л>>ага, уже занялись структурированием ...
S>Это ты full-text назщываешь структурированием?
Нет!


S>Ну, я не знаю насчет конструктора. Конструктор тут ребята уже сделали. Я бы их уволил. Этим конструктором и человек с высшим образованием-то пользоваться не сможет. Если это не MS in CS.
Л>>Если попробовать создать метоописание для данных объектов?
S>Элемент у тебя — класс или объект?

Л>>Добавление новой записи в таблицу Аттрибутов влечёт за собой добавление столбца в соответсвующую таблицу БД
Л>>При добавление записи в Таблицу Элементы создаётся новая таблица в БД ...
S>Не, тогда эти две таблицы нафиг не уперлись. В СУБД такие уже есть.
Не совсем, СУБД хранит только нужную для её работы информацию, я же предполагал хранить в этих таблицах свою метаинформацию.

Л>>Тем самым у тебя имеется как сама метамодель данных, так и её структурированное представление в реляционной модели ...
Л>>Естественно под всё это нужен дизайнер (или конструктор в зависимости от семантических наклонностей , это так лирическое отступление)
S>Ну так вот проблема, как я предчувствую, будет именно в том, что пользователь этого конструктора должен хорошо себе представлять, что он делает.
S>Далее проблема будет в том, что разные типы улик будут лежать в разных таблицах. Потому, что образ памяти конфискованного PDA — это одно, а скан фальшивого чека — это другое. Да еще и ездить взад-вперед. В связи с обнаружением новых деталей в ходе расследования. И нам придется как-то их собирать.
S>Тут же у нас встанет проблема наследования. Т.к. поиск имени, например, нам желательно вести везде, где можно. А из самой простой бытовой практики известно, что оно может встречаться на самых разных документах.
Если пользователи не хотят тратить время на поддержание системы, тогда вопрос: а она им нужна? или просто будет полезна?
Вот MS Word обычно нужен, а калькулятор бывает полезен.

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

Если взять за правила, что вся входящая информация от пользователей, должна вводиться по регламенту, я понимаю что это в большинстве случаев не так, хотя имеет смысл, особенно с гос. служащими, которые и так работают по регламентам и инструкциям.
Тогда этот процесс можно построить. Тоесть все просьбы на добавление/изменение структуры стекаются например одному аналитику в организации (может быть и нескольким, каждый отвечает за какой-то свой набор "УЛИК"), который уже и принимает решение о добавлении нового аттрибута. Возможен сценарий когда пользователи непосредственно сами меняют структуру.


Л>>Прикручивать аналитическую систему к структурированным данных оно гораздо приятнее !!!
S>Это да. Но вот ты фактически предложил перевалить структурирование данных на пользователей. Знаешь, я человек скромный, но если сейчас я не могу провести это структурирование, то и пользователи потом точно не смогут.

По собственному опыту могу сказать, пользователей очень трудно заставить делать что-то чего они не понимают, но ЭТО ВОЗМОЖНО ...
Обычный человек просто не видит взаимосвязи между тем что ему нужно сделать и тем что ему для этого нужно сделать ...

А насколько пользователь будет ориентироваться в системе уже зависит от того какой доступный будет интерфейс!

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

Здравствуйте, Леон, Вы писали:
Л>А если управлять связями? Выделять их в группы, накладывать на них общие правила? И искать уже на оснолве этой информации?
Нельзя ли подробнее?
Л>Нет. Это ис предыдушего абзаца, имелось ввиду: выявить по какому принципу (набору аттрибутов) идёт соответсвие при поиске. Тоесть Номер клеше, соотноситься с диапазоном номеров денежных купюр, номером корр счёта, куда были ушли деньги и т.п. (пример абстрактный)
Идея, конечно, интересная. Вот только это невозможно сделать раз и навсегда. Как я уже говорил, у нас могут появиться любые вещдоки. Любое требование от пользователей предоставить какую-либо метаинформацию можно сразу забыть. Им некогда этим заниматься, и нет нужной квалификации. Система должна сама догадываться, что с чем можно сопоставить.

S>>Не, тогда эти две таблицы нафиг не уперлись. В СУБД такие уже есть.
Л>Не совсем, СУБД хранит только нужную для её работы информацию, я же предполагал хранить в этих таблицах свою метаинформацию.
Это, конечно, вопрос исключительно технический и сейчас его обсуждать смысла нет, но я тебе намекну что практически все современные DBMS позволяют хранить свою метаинформацию. Хоть и ограниченную.
Л>Если пользователи не хотят тратить время на поддержание системы, тогда вопрос: а она им нужна? или просто будет полезна?
Ну как тебе сказать. Конечно, им не нужна эта система. Я тебе открою тайну — большинство существующих сегодня видов человеческой деятельности могут жить безо всякой автоматизации. Причина ее внедрения — повышение производительности труда. Никто не будет пользоваться системой, которая экономит полчаса времени в день, и требует еще часа на обслуживание.

Л>Попробуй проследить кто является инициатором изменения структуры? Как я понял это инициирует именно пользователь, естественно с команды своего начальника, хотя возможно и по собственному усмотрению.
Там нет никакого изменения структуры. Вот наш следователь пытается приобщить к делу документ. Ему не надо для этого никакой команды начальника. У него уже есть команда — найти и вернуть как можно больше из причиненного ущерба. Предположим, что этот документ — доверенность на право управления автомобилем. В системе раньше никогда не было таких документов. Если речь идет о каком-то изменении структуры, тем более с команды начальника, то скорее всего эта доверенность так и останется тифф-файлом. А следователь банально сядет на телефон и начнет искать в старом стиле.
Нужна возможность добавить к этой доверенности метаатрибуты — имя доверителя, имя доверяющего, данные на автомобиль. Безо всякого изменения структуры чего-либо. И система должна сама рассказать о том, что
— доверитель проходил однажды свидетелем по делу о подделке документов
— данный автомобиль служил залогом под выдачу кредита
— доверенное лицо имеет задолженность перед банком

Л>Если взять за правила, что вся входящая информация от пользователей, должна вводиться по регламенту, я понимаю что это в большинстве случаев не так, хотя имеет смысл, особенно с гос. служащими, которые и так работают по регламентам и инструкциям.
Это не госслужащие. Это коммерческая структура. И спрятаться за регламентами не удастся. Наоборот, есть масса всяких требований о взаимодействии с государственными структурами, до которых мы пока еще не добрались. То есть там будет какая-то бизнес логика по формированию выходных и анализу входных документов.
Л>Тогда этот процесс можно построить. Тоесть все просьбы на добавление/изменение структуры стекаются например одному аналитику в организации (может быть и нескольким, каждый отвечает за какой-то свой набор "УЛИК"), который уже и принимает решение о добавлении нового аттрибута. Возможен сценарий когда пользователи непосредственно сами меняют структуру.
Нереально. Этим мы создадим узкое место в системе, а также потребуем у заказчика изменения штатной структуры.

Л>По собственному опыту могу сказать, пользователей очень трудно заставить делать что-то чего они не понимают, но ЭТО ВОЗМОЖНО ...
Л>Обычный человек просто не видит взаимосвязи между тем что ему нужно сделать и тем что ему для этого нужно сделать ...
Вот лично я по своему опыту могу сказать, что если пользователя приходится заставлять сделать что-то, что ему неинтересно, то эффективность такой системы будет стремиться к нулю. Наша задаче не в том, чтобы навязать беззащинтым пользователям наши гири на шею. А в том, чтобы сделать систему, в которой им комфортно работать. По идее, система должна помочь людям с более низкой квалификацией выполнять свою работу. А не потребовать от них дополнительного обучения.
Л>А насколько пользователь будет ориентироваться в системе уже зависит от того какой доступный будет интерфейс!
Интерфейс — всего лишь отражение бизнес-процессов. Сколь бы ни был он красив и удобен, наличие дополнительного звена в цепочке как минимум на порядок сократит частоту использования данной возможности, а также как минимум на сутки задержит выполнение атомарного действия.
Л>Можно воспользоваться такими сценариями как "Запрос на добавление аттрибута", когда пользователь просто опишет тот аттрибут который ему ещё необходим, а уже продвинутый пользователь, который не просто чайник, изменит структуру класса ...
Я тебе как краевед скажу — не бывает продвинутых пользователей. Все пользователи — одинаковые. Надо сделать так, чтобы самый задвинутый пользователь мог успешно пользоваться системой. Без посторонней помощи. Я тебя уверяю — у них и по регламенту хватает головняка с согласованиями и запросами. А если мы еще и свою бюрократию им предложим — все, труба.

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

S>Я боюсь, что если дать вводить произвольные атрибуты, то мы никаких сопоставлений сделать не сможем. Типа у одного подозреваемого GivenName/Surname, а у другого — FirstName/LastName.
Как раз это -- не очень страшная проблема. Ведь наверняка есть справочник атрибутов, из которого выбирают, и в который вводят новые, если не смогли найти нужные существующие. Делаем имя атрибута из справочника ссылкой на "настоящий" атрибут. Если дать возможность "объединять" атрибуты, т.е. исправлять ошибки дублирования атрибутов в справочнике, то сразу жизнь станет легче. При объединении оба имени остаются, но значение "настоящего" атрибута переписывается для одного из них, чтобы оба имени ссылались на один "настоящий". Это потребует некоторых дополнительных усилий в начале наполнения базы, зато потом уже не будет разницы: GivenName или FirstName. Кто как хочет, тот так и называет, а внутри это одно и то же.

Вот попалось на глаза — по-моему, близко к теме
http://www.osp.ru/os/2004/08/028_print.htm

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

А какие тогда ключевые слова для поиска ?
Поиск по "создание экспертных систем" дает только ссылки на существующие системы.
Или м.б. есть сайты какие профильные ?
Просто, мне, возможно, придется заняться этим вопросом в недалеком будущем. Хочу уже сейчас хоть какой-то фундамент заложить.

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

VR>При правильной реализации ничего не тормозит. На Оракле. Пробовали

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

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

Л>>Нет. Это ис предыдушего абзаца, имелось ввиду: выявить по какому принципу (набору аттрибутов) идёт соответсвие при поиске. Тоесть Номер клеше, соотноситься с диапазоном номеров денежных купюр, номером корр счёта, куда были ушли деньги и т.п. (пример абстрактный)
S>Идея, конечно, интересная. Вот только это невозможно сделать раз и навсегда. Как я уже говорил, у нас могут появиться любые вещдоки. Любое требование от пользователей предоставить какую-либо метаинформацию можно сразу забыть. Им некогда этим заниматься, и нет нужной квалификации. Система должна сама догадываться, что с чем можно сопоставить.
Тогдла какой-то парадокс: Всё изменяется, а изменять при этом ничего не хочется! Если ситема должна догадываться это уже искуственный интелект


Л>>Если пользователи не хотят тратить время на поддержание системы, тогда вопрос: а она им нужна? или просто будет полезна?
S>Ну как тебе сказать. Конечно, им не нужна эта система. Я тебе открою тайну — большинство существующих сегодня видов человеческой деятельности могут жить безо всякой автоматизации. Причина ее внедрения — повышение производительности труда. Никто не будет пользоваться системой, которая экономит полчаса времени в день, и требует еще часа на обслуживание.
ХА! Удивил! Так задача же в том чтобы найти эту самую золотую середину ... (моё мнение)

Л>>Попробуй проследить кто является инициатором изменения структуры? Как я понял это инициирует именно пользователь, естественно с команды своего начальника, хотя возможно и по собственному усмотрению.
S>Там нет никакого изменения структуры. Вот наш следователь пытается приобщить к делу документ. Ему не надо для этого никакой команды начальника. У него уже есть команда — найти и вернуть как можно больше из причиненного ущерба. Предположим, что этот документ — доверенность на право управления автомобилем. В системе раньше никогда не было таких документов. Если речь идет о каком-то изменении структуры, тем более с команды начальника, то скорее всего эта доверенность так и останется тифф-файлом. А следователь банально сядет на телефон и начнет искать в старом стиле.
S>Нужна возможность добавить к этой доверенности метаатрибуты — имя доверителя, имя доверяющего, данные на автомобиль. Безо всякого изменения структуры чего-либо. И система должна сама рассказать о том, что
Так система же сама не догадается что это доверенность и что у неё есть эти аттрибуты, значит кто-то когда-то должен эту информацию ввести ...

S>- доверитель проходил однажды свидетелем по делу о подделке документов
S>- данный автомобиль служил залогом под выдачу кредита
S>- доверенное лицо имеет задолженность перед банком
Это как-раз те самые возможные взаимосвязи между аттрибутами классов ... их естественно нужно описывать ...

Л>>Если взять за правила, что вся входящая информация от пользователей, должна вводиться по регламенту, я понимаю что это в большинстве случаев не так, хотя имеет смысл, особенно с гос. служащими, которые и так работают по регламентам и инструкциям.
S>Это не госслужащие. Это коммерческая структура. И спрятаться за регламентами не удастся. Наоборот, есть масса всяких требований о взаимодействии с государственными структурами, до которых мы пока еще не добрались. То есть там будет какая-то бизнес логика по формированию выходных и анализу входных документов.
Л>>Тогда этот процесс можно построить. Тоесть все просьбы на добавление/изменение структуры стекаются например одному аналитику в организации (может быть и нескольким, каждый отвечает за какой-то свой набор "УЛИК"), который уже и принимает решение о добавлении нового аттрибута. Возможен сценарий когда пользователи непосредственно сами меняют структуру.
S>Нереально. Этим мы создадим узкое место в системе, а также потребуем у заказчика изменения штатной структуры.
По моему, не факт, что нужно будет изменять штатную структуру. Относительно узкого места, ничего сказать не могу, это субъективный фактор конкретного заказчика.

Л>>По собственному опыту могу сказать, пользователей очень трудно заставить делать что-то чего они не понимают, но ЭТО ВОЗМОЖНО ...
Л>>Обычный человек просто не видит взаимосвязи между тем что ему нужно сделать и тем что ему для этого нужно сделать ...
S>Вот лично я по своему опыту могу сказать, что если пользователя приходится заставлять сделать что-то, что ему неинтересно, то эффективность такой системы будет стремиться к нулю. Наша задаче не в том, чтобы навязать беззащинтым пользователям наши гири на шею. А в том, чтобы сделать систему, в которой им комфортно работать. По идее, система должна помочь людям с более низкой квалификацией выполнять свою работу. А не потребовать от них дополнительного обучения.
Так если процитировать твой же ответ что: "Система им не нужна", то получается ты ломаешь голову над тем чтобы придумать систему, которая заведома не интересна пользователю ...
Это скорее не твоя проблема, а тех кто её заказывал ...

S>Я тебе как краевед скажу — не бывает продвинутых пользователей. Все пользователи — одинаковые. Надо сделать так, чтобы самый задвинутый пользователь мог успешно пользоваться системой. Без посторонней помощи. Я тебя уверяю — у них и по регламенту хватает головняка с согласованиями и запросами. А если мы еще и свою бюрократию им предложим — все, труба.

Тогда получается что любая система где есть workflow — это бюрократия По сути, наверное, так оно и есть ...

Просто резюмирую получаем:

1. Систему заказали
2. Предъявили требования из разряда "Система ДОЛЖНА додумывать всё сама"
3. В идеале, хотят ввести одну цифру и получиь результат анализа этой цифры по каким-то правилам
3.1 При этом правила вводить никто не хочет
4. Пользователи спокойно могут обойтись без автоматизации, тоесть не видят явных плюсов в её внедрении

Соответсвенно проект кажется утопичным, потому что помоему это из разряда: "ХОЧУ ВСЁ! И НИЧЕГО ПРИ ЭТОМ НЕ ДЕЛАТЬ!"

А кстати кто-нибудь оценивал проект с точки зрения рисков? не просто програмерский взгляд на задачу, а мнение именно эксперта по оценке проектов?
Если нет то наверное стоит это сделать

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

C>Вот попалось на глаза — по-моему, близко к теме
C>http://www.osp.ru/os/2004/08/028_print.htm
Да, очень близко. К сожалению, иначе как рекламой IBM Content Manager эту статью не назовешь.

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

Л>Тогдла какой-то парадокс: Всё изменяется, а изменять при этом ничего не хочется! Если ситема должна догадываться это уже искуственный интелект
Неверно. Не хочется выполнять лишних действий.

Л>ХА! Удивил! Так задача же в том чтобы найти эту самую золотую середину ... (моё мнение)
Лучше найти серебряный край. Zero effort administration. Например, в соответствии с этой концепцией построен MS SQL. Да, там при желании есть за что покрутить. Но он, в отличие от многих других систем, способен функционировать годами без вмешательства DBA. И при этом вполне успешно справляться с нагрузкой.
Л>Так система же сама не догадается что это доверенность и что у неё есть эти аттрибуты, значит кто-то когда-то должен эту информацию ввести ...
Да, должен. Но мы должнгы дать эту возможность именно тому человеку, который держит в руках доверенность. Безо всяких служебных записок "Главному админу новой системы. Для выполнения следственных мероприятий по делу №... прошу обеспечить представление в системе данных о документах типа "доверенность", описание структуры документа в ISDEF прилагаю..."
Л>Это как-раз те самые возможные взаимосвязи между аттрибутами классов ... их естественно нужно описывать ...
Неа. Хочу решение, при котором их не надо описывать. Потому, что иначе мы будем иметь экспоненциальный взрыв возможного количества взаимосвязей, и никто просто не будет все это руками вводить.
S>>Нереально. Этим мы создадим узкое место в системе, а также потребуем у заказчика изменения штатной структуры.
Л>По моему, не факт, что нужно будет изменять штатную структуру. Относительно узкого места, ничего сказать не могу, это субъективный фактор конкретного заказчика.
Ничего субъективного тут нет. Как только мы вводим штатную единицу "продвинутого пользователя", то через него начинают проходить все запросы. И если он тормозит, то весь бизнес встал. Требовать от заказчика поднимать уровень рядовых пользователей — самоубийство. Наймут более компетентных девелоперов.
Л>Так если процитировать твой же ответ что: "Система им не нужна", то получается ты ломаешь голову над тем чтобы придумать систему, которая заведома не интересна пользователю ...
Л>Это скорее не твоя проблема, а тех кто её заказывал ...
Нет. Им не нужна система ради системы. У них до хрена своей работы есть, чтобы еще и техобслуживанием заниматься.
Л>Тогда получается что любая система где есть workflow — это бюрократия По сути, наверное, так оно и есть ...
Нет, просто есть "натуральный" workflow, а есть "искусственный". Вот получение менеджером отчета о прибылях для выступления на совете директоров — это натуральный воркфлов, а обращение к айти отделу за дотачиванием кода генератора отчета — это искусственный. Вот этого воркфлов быть вообше не должно.

Л>1. Систему заказали
Л>2. Предъявили требования из разряда "Система ДОЛЖНА додумывать всё сама"
Нет, не предъявили. Описали проблему.
Л>3. В идеале, хотят ввести одну цифру и получиь результат анализа этой цифры по каким-то правилам
Примерно так.
Л> 3.1 При этом правила вводить никто не хочет
Естественно! Потому что этих правил — больше чем цифр.
Л>4. Пользователи спокойно могут обойтись без автоматизации, тоесть не видят явных плюсов в её внедрении
Они не увидят плюсов во внедрении системы, которая потребует от них больше времени и усилий на выполнение той же работы.
Л>Соответсвенно проект кажется утопичным, потому что помоему это из разряда: "ХОЧУ ВСЁ! И НИЧЕГО ПРИ ЭТОМ НЕ ДЕЛАТЬ!"
Ну мне вот интуитивно кажется, что все должно получиться именно так.
Ну вот к примеру амазон предлагает посетителю к каждой книге еще и related и frequently bought together. Я тебя уверяю — если бы они потребовали от менеджеров руками указывать, какая книга к какой относится, и какие книги часто покупают вместе, то оба списка были бы пусты. Потому, что при жалкой тысяче наименований потенциальных пар "схожа с..." будет миллион. Предлагаю в качестве домашнего задания оценить трудозатраты на заполнение такой базы.
Л>А кстати кто-нибудь оценивал проект с точки зрения рисков? не просто програмерский взгляд на задачу, а мнение именно эксперта по оценке проектов?
Я не в курсе. Но до выяснения основных требований и предполагаемой архитектуры все разговоры о рисках — спекуляция.

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

Интересное решение ...
коментарии ниже ...

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

__>>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
S>Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.
Если базовой платформой ввода сделать MS Word, тогда имеет смысл покапать такую технологию на Smart Tags и Smart Documents ..
презентацию можно посмотреть здесь Новые средства разработки в Microsoft Office System 2003 для автоматизации бизнес-процессов. ...

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

C>Вот попалось на глаза — по-моему, близко к теме
C>http://www.osp.ru/os/2004/08/028_print.htm

Я внедрял IBM CM в гос. архиве, это чистой воды Content Management система с очень большим дополнительным функционалом, основной плюс которой это способность работать с терабайтами данных ...

Относительно неструктурированности: в CM есть понятие ItemType это фактически класс, прежде чем создавать экземпляры ты декларируешь структуру этого класса. После того как создан хотябы один экземпляр класса (ItemType'а) ты можешь только добавить новый атрибут и больше ничего ...
Вся метаинформация храниться в DB2 ...

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

b>> Речь не о самой ЭС, а о том, как в них могут быть представлены знания и
b>> данные. Это как раз тебе и могло бы пригодится.
b>> Проблемы с представлением и использованием
b>> противоречивых и неполных данных — это классика в ЭС.

ST>Кстати, накидай плиз ссылок на это.
Питер Джексон. Введение в экспертные системы. — М.: Издательский дом "Вильямс", 2001.
Есть в электронном виде здесь.

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

S>А классификацию вы как-то вводили? Т.е. возможность одним взмахом руки добавить целый набор взаимосвязанных атрибутов в сущность?

Не совсем понял про классификацию. Групповые аттрибуты поддерживаются. Для редактирования метаинформации сделан специальный пользовательский интерфейс.
Для всех связей используется таблица связей (опять же для возможности добавлять типы связей между сущностями в рантайм).
Еще делали спейциальный интрефейс для редактирования/просмотра сущностей и их связей в визуальном режиме — сущности как иконки, связи как стрелочки (наряду с умными запросами — очень мощное средство).
Проблему с ошибками в фамилиях и поиском лиц решали специальными алгоритмами.
Наиболее сложная часть системы — обработка метаинформации.
Вообще посмотри на какие-нибудь существующее системы (даже если они ужасны и написаны на фоксе, по крайней мере лучше можно понять
задачу и ее осбенности).
Слышал что неплохая есть в AviComp (http://www.avicomp.ru/rus/tais/projects.php).
Есть еще Сипол (к сожалению нашел только упоминание http://www.computerra.ru/offline/1997/182/382/?print).
Нашу могу показать если будешь в Киеве .

Всего хорошего.
Виктор.

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

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


__>>Кроме того, дать возможность классифицировать весь текст по категориям, задаваемым пользователем. Это даст возможность, как полнотекстового поиска, так и быстрого поиска по ключевым словам.
S>Хм, ты не мог бы пояснить, что ты понимаешь под классификацией по категориям?

Посмотри как сделано в Outlook. Любой объект там можно описать категориями (так прямо и называется "категория"). Можешь выбрать из списка, добавить в список или написать все руками. Категории выносишь в отдельную таблицу, вяжешь ее с текстами N:N и индексируешь по тексту. По категориям нужен поиск на точное совпадение для скорости работы. При такой организации можно сделать что-то вроде окошка Dynamic Help в VS. К стати, можно посмотреть как MS решает задачу мгновенного поиска в MSDN из VS по контексту.

__>>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
S>Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.

Не совсем. Выделил слово и сказал "добавить ключевое слово". Ключевые слова должны работать по тем же принципам, что категории. Разница в том, что категории нужны для построения отчетности, набора типовых операций, шаблонов текстов и пр. (для милиции категории "кражи", "банда", "группировка", "несовершеннолетние", "солнцевские"), а ключевые слова для поиска.


__>>В качестве поисковой машины следует использовать что-то вроде Яндекса.
S>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
так любой SQL зато отлично справится с поиском по индексированному текстовому полю символов в 100.

__>>Кроме того, если Ваш клиент милиция (прокуратура, таможня…) или выходцы из нее, то Вы столкнетесь еще и с ужасающей безграмотностью. Поэтому в качестве основного инструмента предлагаю использовать уже знакомый им Word со встроенной проверкой грамотности.
S>Вот это ты в самую точку угадал! Spellchecker был отдельной строкой потребован в ТЗ с самого начала!

А главное, что все уже есть в MS Word!

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

__>>Кроме того, дать возможность классифицировать весь текст по категориям, задаваемым пользователем. Это даст возможность, как полнотекстового поиска, так и быстрого поиска по ключевым словам.
S>Хм, ты не мог бы пояснить, что ты понимаешь под классификацией по категориям?

Как я понимаю: розовые штаны -> одежда, тел. 222222 -> номер телефона и т.п.

__>>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
S>Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.

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

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

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

ST>А какие тогда ключевые слова для поиска ?

Поищи по словам "metamodel ontology"

ST>Поиск по "создание экспертных систем" дает только ссылки на существующие системы.

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

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

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

...
__>>В качестве поисковой машины следует использовать что-то вроде Яндекса.
S>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".

Вот эта штука с ними будет работать прекрасно

...
__>>Кроме того, если Ваш клиент милиция (прокуратура, таможня…) или выходцы из нее, то Вы столкнетесь еще и с ужасающей безграмотностью. Поэтому в качестве основного инструмента предлагаю использовать уже знакомый им Word со встроенной проверкой грамотности.
S>Вот это ты в самую точку угадал! Spellchecker был отдельной строкой потребован в ТЗ с самого начала!

Я бы не стал связываться с Вордом из-за спеллчекера. Проще взять сторонний спеллчекер благо их полно, в том числе и бесплатных. Я напрмер в свое время брал вот это

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


EM>Я бы не стал связываться с Вордом из-за спеллчекера. Проще взять сторонний спеллчекер благо их полно, в том числе и бесплатных. Я напрмер в свое время брал вот это

с Вордом правильно связываться по еще нескольким причинам:
его знает каждый "сержант ГИБДД"
есть 1 млн. книжек, курсов и пр. возможностей на нем заработать
да и сам редактор хороший

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

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

S>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
Вообще существует целый класс программ называемых автоматический классификатор. Когда-то давно попадала одна из них ко мне, по моему сделанная на основе нейросети со всеми вытекающими последствиями, то есть жутко тормозная, и долгая процедура обучения. Поэтому тогда (года 3-4 назад) от него отказались. Тема не заглохла, сделал поиск в www.yandex.ru "автоматический классификатор", несколько выдал сразу. Возможно, они спасут отца демократии.
С уважением, Gleb

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

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

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

S>>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
GZ>Вообще существует целый класс программ называемых автоматический классификатор. Когда-то давно попадала одна из них ко мне, по моему сделанная на основе нейросети со всеми вытекающими последствиями, то есть жутко тормозная, и долгая процедура обучения. Поэтому тогда (года 3-4 назад) от него отказались. Тема не заглохла, сделал поиск в www.yandex.ru "автоматический классификатор", несколько выдал сразу. Возможно, они спасут отца демократии.
GZ>С уважением, Gleb


Я имел отношение к разработке такого классификатора и, помнится, основная проблема там не в тормозах и скорости обучения а том, что он плохо классифицирует короткие документы т.к. для них он не может составить достоверный семантический образ. Тоесть это хорошая штука для раскладывания резюме, но плохая для расладывания например почты.
Еще стоит добавить что "хороший" результат для автоматической классификации это ~ 60/70% попаданий, так что не думаю, что это хорошее решение для системы, о которой идет речь

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

S>[...]

Имхо, реальный положительный эффект от этой системы появится, в лучшем случае, только через несколько месяцев (скорее лет), после начала её внедрения. Чтобы заработал продвинутый поиск по ключевым позициям, сначала нужно набить то, по чему искать, хоть какую-то базу данных.
Представляю себя на месте среднего следователя. Какой смысл ему напрягаться, выделять в документах самые ценные поля, тыкать пальцем по клавиатуре, пытаясь ввести их в систему, и всё это в надежде, что потом, при соответствующем усердии остальных следователей города/области/страны, может быть получить какие-то полезные возможности по розыску...
Гораздо проще накопить все эти несчастные бумажки. В конце месяца отсканировать их и все скопом, не разбираясь, загнать в базу.
Результат понятен.

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

А потом, через N лет, когда всё заработает, можно будет и об ЭС подумать...

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

Первое, что я стараюсь делать сначала, это смотреть программы конкурентов.
Понравилась одна статья: здесь. Но дороговато получится.

S>Начинаем проектировать. Ага, сущностей-то — всего ничего: дело, персона, улика, да прочий материал.

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

S>В общем мораль такая: что-то не очень у меня выходит нарисовать строго типизированную модель.
Нормальная эволюция схемы. Ты по моему как то занимался OODBMS? Примерно, это и реализуется в некоторую метамодель. Способов до фигищи, делай не хочу. В результате, в каждый момент времени, получается строго типизированная модель.

S>А главное — не факт, что это надо!
S>С точки зрения п.2, фиксация любой структуры — это
S>а) наличие нуднейшей формы, в которой большинство полей не заполняются никогда
S>б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.
Генерация новых справочников на лету, ничего страшного. Будет несколько нелепый GUI (универсальные view никогда красивыми не бывают (или бывают только на тестовых данных)).
Например:
1. Пользователь ввел в поле "Улика" — нож
2. Пользователь открыл (ему стала виден) справочник аттрибутов улики типа нож
3. Пользователь ввел в поле Ручка — каменная
4. Пользователь добавил новое свойство лезвие
5. Пользователь нажал на кнопку открыть свойства от свойства лезвие
6. Сгенерировался новый тип "Лезвие"(создался справочник, произведены изменения в метамодели)
7. Пользователю открылся (ему стала виден) справочник свойства Лезвие
У тебя всегда остается нормальная древовидная метамодель.

S>Таким образом, возникает острое желание заменить это моделью, в которой с любым объектом можно проассоциировать любые именованные атрибуты. Атрибут соответственно может быть либо скаляром, либо вектором. При этом скаляр может быть значением, а может быть и ссылкой.
S>В общем, чистый джаваскрипт.

S>Однако смущает меня три вопроса:
S>1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?
Будет, лучше тип-таблица (или класс-набор таблиц, тогда снизишь границы поиска).
S>2. Как насчет пункта 3?
S>В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
S>а) похожих людей (сходство по любому атрибуту)
S>б) похожие места (в смысле адреса)
S>в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
S>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
Самый дешевый вариант. Все зависит от ресурсов.
S>3. Как быть с пунктом 4? Статистика вроде хорошо ездит по структурированным данным, а как быть со слабоструктурированными — я что-то даже не соображу.
В каждый момент времени, существует вполне понятная метамодель, которая изменяется только в сторону увеличения. Используем генератор отчетов.

Вообще это самая дешевая модель.

Ключевая проблема — поиск. В зависимости от того как ты ее решишь, будет вытекать остальные пункты.

S>Да, очень близко. К сожалению, иначе как рекламой IBM Content Manager эту статью не назовешь.
Ну реклама — и Бог с ней
Может действительно стоит посмотреть вокруг — вдруг есть что-то уже подобное, сделанное... Потриалить да и купить, если подойдет. В этом случае, конечно, меняется задача — не разрабокта, но внедрение... Ну а кто говорил, что будет легко?

Подобная задача была решена коллегами на Lotus Domino. Сделано было для страховой компании — что-то типа рабочей среды для экспертов при расследовании страховых случаев (компания страховала объекты недвижимости и строительство). Lotus Domino — масштабируемый, готовый полнотекстовый поиск, поиск-индексация аттачментов, синхронизация серверов и рабочих станций (у экспертов были ноутбуки). По-моему было сделано одним человеком за 1-2 месяца.

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

А>Подобная задача была решена коллегами на Lotus Domino. Сделано было для страховой компании — что-то типа рабочей среды для экспертов при расследовании страховых случаев (компания страховала объекты недвижимости и строительство). Lotus Domino — масштабируемый, готовый полнотекстовый поиск, поиск-индексация аттачментов, синхронизация серверов и рабочих станций (у экспертов были ноутбуки). По-моему было сделано одним человеком за 1-2 месяца.
Ага. У наших заказчиков, как я понял, уже стоит солюшн на базе Lotus Domino. Теперь они заказывают нам новое решение
Мотивация:

· Lack unified data services and customized workflow.
· There is no integration with either internal or external data sources, such as thirdpart
databases or internal databases like customer
database.
· Inferior Search Technology and lack of real time look-ups prevent efficient cross
case correlation of crucial evidence.
· Pre-set reports lack meaningful details and reports contain errors.
· Inability to store pertinent information and documents such as Check Images,
Security Video and Interviews.
· Poorly designed User Data Entry Areas lead to cumbersome and unnecessary,
time consuming activities.
· Simple, yet highly beneficial tools do not function (such as Spell Check).
· Personal Management Tools (Calendaring and Tasking) are non-existent or do
not integrate with existing PIM systems.
· Lack Real Time Management Reporting.
· No workflow efficiency.

S>· Lack unified data services and customized workflow.
S>· There is no integration with either internal or external data sources, such as thirdpart
S>databases or internal databases like customer
S>database.
S>· Inferior Search Technology and lack of real time look-ups prevent efficient cross
S>case correlation of crucial evidence.
S>· Pre-set reports lack meaningful details and reports contain errors.
S>· Inability to store pertinent information and documents such as Check Images,
S>Security Video and Interviews.
S>· Poorly designed User Data Entry Areas lead to cumbersome and unnecessary,
S>time consuming activities.
S>· Simple, yet highly beneficial tools do not function (such as Spell Check).
S>· Personal Management Tools (Calendaring and Tasking) are non-existent or do
S>not integrate with existing PIM systems.
S>· Lack Real Time Management Reporting.
S>· No workflow efficiency.

похоже на аудит любой криво сделанной на коленке стажером системы.

"There is no integration with either internal or external data sources" — очень странно, что IBM-овский продукт не имеет никаких возможностей, кроме того Lotus умеет работать с webservices, а любой современный продукт имеет webservices интерфейс.

всё остальное — свойства типичной кривой системы, сделанной консалтинговой компанией, и на данном проекте не было ни одного человека, прилично разбирающемся в задаче

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

M>похоже на аудит любой криво сделанной на коленке стажером системы.
Похоже.
M>"There is no integration with either internal or external data sources" — очень странно, что IBM-овский продукт не имеет никаких возможностей, кроме того Lotus умеет работать с webservices, а любой современный продукт имеет webservices интерфейс.
Я не думаю, что IBM хоть что-то знает про тот продукт, который используется у заказчика.
M>всё остальное — свойства типичной кривой системы, сделанной консалтинговой компанией, и на данном проекте не было ни одного человека, прилично разбирающемся в задаче
Ну, мне отсюда плохо видно, был ли у них человек, разбирающийся в задаче Но теперь разобраться во всем надо мне.

M>>"There is no integration with either internal or external data sources" — очень странно, что IBM-овский продукт не имеет никаких возможностей, кроме того Lotus умеет работать с webservices, а любой современный продукт имеет webservices интерфейс.
S>Я не думаю, что IBM хоть что-то знает про тот продукт, который используется у заказчика.

говоря об IBM я имел в виду Lotus www.ibm.com/lotus

Л>Относительно неструктурированности: в CM есть понятие ItemType это фактически класс, прежде чем создавать экземпляры ты декларируешь структуру этого класса. После того как создан хотябы один экземпляр класса (ItemType'а) ты можешь только добавить новый атрибут и больше ничего ...
Л>Вся метаинформация храниться в DB2 ...

А насколько хорошо сделан поиск по данным? Есть ли возможность поиска по картинкам?

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

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

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

А>>Подобная задача была решена коллегами на Lotus Domino. Сделано было для страховой компании — что-то типа рабочей среды для экспертов при расследовании страховых случаев (компания страховала объекты недвижимости и строительство). Lotus Domino — масштабируемый, готовый полнотекстовый поиск, поиск-индексация аттачментов, синхронизация серверов и рабочих станций (у экспертов были ноутбуки). По-моему было сделано одним человеком за 1-2 месяца.
S>Ага. У наших заказчиков, как я понял, уже стоит солюшн на базе Lotus Domino. Теперь они заказывают нам новое решение

S>· Lack unified data services and customized workflow.
В Lotus Notes есть соответсвующий продукт Lotus WorkFlow? Это если твой workflow достаточно "продвинутый"!
S>· There is no integration with either internal or external data sources, such as thirdpart
S>databases or internal databases like customer
В Lotus Notes есть две родные технологии (тулсы): Data Connections и DECS. Причём обе работают с ODBC и нативными библиотеками в случае не Win'дов!
S>database.
S>· Pre-set reports lack meaningful details and reports contain errors.
Ну это косяк програмеров, в Lotus'е само хранилище не реляционное? а скорее — документоориентированное. Тоесть некаких констраинов, primary/foreign ключей и т.п. Соответсвенно проектировать структуру данных нужно изходя из этого.
А отчёты это уже дело техники!
Lotus это Наследие mainframe'ов и тяжёлых машин
S>· Inability to store pertinent information and documents such as Check Images,
S>Security Video and Interviews.
Понятия составных документов, как таковых, нет! ... это факт!
S>· Simple, yet highly beneficial tools do not function (such as Spell Check).
Вот этого нет! Хотя я ещё не видел "изврашенцев" которые работали во встроеных редакторах Lotus, обычно тексты набираются в Word'е а уже затем прикрепляются к Lotus документам.
S>· Personal Management Tools (Calendaring and Tasking) are non-existent or do
S>not integrate with existing PIM systems.
В Lotus своя система PIM. Впринципе аналог MS Outlook.
S>· Lack Real Time Management Reporting.

S>· No workflow efficiency.
Это см. выше.

P.S. Я вообще не сторонник Lotus Notes, хотя и приходилось писать на нём приклад ... Я бы оценил платформу как — "специфическую".
P.S.S. Lotus, на МОЙ взгляд, не очень предназначен для задачи которую описывает Sinclair ...

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

Отвечу только по пункту 3...

S>3. Могучая поисковая енжина. С таким интеллектом, чтобы пользоваться ей мог даже сержант ГИБДД. Ну типа повводили мы данных, а система нам и говорит "ага, мои любезные, хочу вам подсказать, что аналогичный случай имел место в городе Одесса. В связи с чем рекомендую обратить внимание на...". Причем не только не требуя от пользователя нудного указания условий поиска, а лучше и вообще безо всякой инициативы.

S>2. Как насчет пункта 3?
S>В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
S>а) похожих людей (сходство по любому атрибуту)
S>б) похожие места (в смысле адреса)
S>в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
S>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)

Во-первых, ИМХО, стоит разделить ввод данных (поступление данных в систему) и использование данных (поиск и т.п.). Мало того, я бы предусмотрел между этими группами use-cases ещё слой подготовки и преобразования данных (т.е. перевод их из сырого состояние в агрегатное и подготовленное к поиску). Этот слой, возможно, решит часть проблем, поскольку отвяжет вас от необходимости на одних структурах данных решать несколько перпендикулярных задач.

Что касается поиска, то помимо поиска по параметрам, который обязательно должен быть (по номеру дела и т.п), можно добавить ещё несколько механизмов поиска:
— поиск по контексту, а-ля Яндекс (с учётом морфологии). Это достаточно стандартный механизм, но к нему надо будет предусмотреть подготовку данных;
— поиск по смыслу. Это отдельная тема, которую я и хочу упомянуть.

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

— вводишь фразу "Президент России посетил Украину"
— получаешь документ с текстом "В.В.Путин — деловая поездка по странам СНГ"

У таких систем, как правило, есть серверная часть (довольно простая в использовании) и API, позволяющее подключиться к серверу откуда угодно, что позволяет встраивать эту поисковую машину в любые GUI. Данные же в сервер (а точнее индексы со ссылками на источник, например, на базу данных и конкретную запись) могут попадать в автоматическом режиме через большое количество так называемых коннекторов, которые присасываются как к БД, так и к другим хранилищам документов, включая даже Интернет.

Сам я возился в своё время с продуктом компании Autonomy.

Штука не сложная, хотя достаточно дорогостоящая. Писал на основе Authonomy тесты (минипоисковую систему). В качестве источников брал как данные из разных баз данных, так и N-ое количество сайтов из Интернет. Причём по сути не важно, с каким языком эта система работает (мы, для теста, взяли тогда набор документов в транслите и искали по транслиту — работало). С русским, разумеется, тоже работало.

В общем работало.

Думаю, что аналогичные по принципу системы сейчас есть (IBM чего-то в этом направлении делало да и MS тоже)...

Так что если подготавливать в автоматическом режиме данные после их попадания в систему, то можно использовать как структурированный поиск, так и различные виды контекстно-смыслового...

Если интересно, могу ответить на вопросы подробнее (если будут )

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

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

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

Здравствуйте, 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).

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

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

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

S_>

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

Замечательно. Какой номер этой ссылки в запросе? Ничего, что первые три посвящены детекторам валюты?
S_> А хранятся ли в Google специальные атрибуты номера банкнот? Конечно нет.
Ну вот и искать в нем — это отдельная работа.
S_> Это к тому что может не о структуре SQL таблиц сначала думать а о концепции. Может задача почти не для реляционных БД. Маленькая часть реляционная, а остальное навороченые поисковые технологии (не имеющие отношения к SQL).
Может. Но тут больше похоже на поиск по образцу. Полнотекстовый поиск не может похвастаться релевантностью на структурированных данных.

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

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

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

<...>

Хотелось бы поинтересоваться какое решение было выбрано, и с какими проблемами столкнулись в реализации ...

ЗЫ. Возникла похожая задача (слабоструктурированные данные), в какую стророну рыть пока не совсем понятно

А вы не рассматривали как вариант хранилища нереляционную базу? Те-же MUMPS, помойму, создавались для похожих задач и дают на них очень неплохую производительность.

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

ssl>ЗЫ. Возникла похожая задача (слабоструктурированные данные), в какую стророну рыть пока не совсем понятно
Всю тему пока не осилил. Вы в сторону XML + RDF + OWL уже смотрели?

Who Killed the Virtual Case File?

Гм,есть, кроме перечисленных, еще одна техника, которой, например, я пользуюсь.
Если архитектура у тебя трехзвенка, то можно в БД использовать только для: хранения формализованных данных с всегда общим видом параметров и для всевозможных хитрых индексов. А все хитрое (например, улики) хранить в виде сериализованных (в XML, например) Java объектов (ну или С# объектов).

Как это работает:
ну, с просмотрами и выборками по истории дел все просто — общая табличка дел, из нее ссылки на объекты, полностью описывающие различные виды улик.
с поисками — все чуть хитрее. Пусть все улики реализовывают некий интерфейс "getDraftString" — в который выкидывается то, что можно назвать "характерной информацией" для улики. В базу при сохранении дела закидываешь эти draftString (по сути — атрибуты, но предназначенные не для отображения пользователю, а для поиска — например, не полное имя банка, а очищенное от всяких АО или вообще только вокализация и т.п.). И при поиске — ищешь только по этим индексам.
Это, во-первых, быстро, во-вторых отделяет систему "поиска данных" от "документооборота" — и можно делать одно, не сильно думая о другом.

Ну а уж как работать с сложными иерархиями или PropertyBag'ами на высоком уровне — всяко разберешься.
Главное — первую версию напишешь быстро.

Здравствуйте, <Аноним>, Вы писали:
А>Ну а уж как работать с сложными иерархиями или PropertyBag'ами на высоком уровне — всяко разберешься.
Спасибо за комментарии
А>Главное — первую версию напишешь быстро.
Ну, c учетом того, что с моего вопроса прошло два года, фактор скорости уже не очень важен.