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

Итак, речь идет о системе сбора данных о, скажем так, расследованиях.
На пальцах — смысл прост:
Вот возник у нас неприятный случай. Злоумышленник причинил некоторый ущерб. Начинается расследование, которое должно этот ущерб вернуть. И тут есть три основных задачи:
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 не очень удобное) изменения стандартной схемы — добавления новых атрибутов и изменения существующих.
Ну вот собственно ...