Всем привет!

Задумка следующая.
Планируется БД, описывающая большое число сущностей.
У всех них есть определённые свойства. Но формализировать эти свойства на этапе проектирования БД невозможно.

Т.е. имеем что-то навроде

Сущность1- свойство1-true, свойство2-"агрессия"
Сущность2- свойство1-true, свойство3-135
Сущность3- свойство4-"параллелепипед"
Сущность3- свойство2-"гипноз", свойство5-0,425

т.е. записи в БД обладают каждая своим набором характеристик. Только вот какие будут эти наборы, какие будут характеристики- неизвестно. В то же время параметры будут неуникальными, и одним и тем же параметром будут обладать много записей.

Думаю пока вот что:

Для каждого свойства в процессе работы БД создавать свою таблицу:
ID: integer
MotherTable: VarChar
RecordInMotherTable: integer
Value: - по обстоятельствам.


Во время запроса необходимо обращаться к этим таблицам. А вот как...
У кого какие варианты? Использовать rdb$relations.rdb$relation_name (для firebird, например)?

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

Но у меня стойкое ощущение, что я изобретаю велосипед... :)

Вот так?:

Select (подзапрос) from (подзапрос) where и т.д. с подзапросами?
Кажется, как-то громоздко...

P.S. В БД необходимо осуществить объединение логически не связанных объектов и свойств. Скажем, круглый вишневый стол, гроза над Мурманском и цитаты из книг Кастанеды smile Причем свойства объектов и их количество, равно как и количество объектов на этапе проектирования неизвестны и объективно не могут быть получены.

P.P.S. Расписал всё с тайной мыслью- вдруг кто делал то же, и есть какие-то другие идеи?

Спасибо за ответы.

>Вы собираетесь связывать их случайным образом или все-таки есть какие-то критерии? ;)

Так в том то и вся штука, что критерии связи появятся уже при эксплуатации... :-)
По задумке в БД будет собираться вообще весь возможный максимум информации по формируемым темам, а потом искаться их взаимосвязи. Что-то похожее на DataMining, но не совсем то... с одной стороны- проще, с другой- сложнее... Поиск по организации хранения информации в таких системах дал мало полезного. Везде изначально предметная область предполагается известной. А в нашем случае- она неизвестна, и представление о ней достраивается в ходе работы в т.ч. на основе уже имеющихся данных. Скажем, выяснилось, что для более полного описания нужно ещё несколько сущностей с такими-то взамосвязями.... :-) Да, лопнувшего сервера не боимся. На начальных этапах работы БД пользователей, использующих выборки, будет только 2-3. А то и вообще 1.

>Скорее, самокат с костылями. ;)
Ну-у-у-у... Да! "Именно это я и хотел сказать" (фильм "Трест, который лопнул") :-) :-)

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

Модель данных выбрать нельзя. Она вообще неизвестна пока:)
По поводу фреймворка... То есть, библиотеку, реализующую наращивание метаданных?

>таблица с неопределенным числом столбцов неизвестных типов т.е. nested tables

Ещё раз спасибо. Буду копать по nested tables, как я слышал, такая штука есть в Oracle?

Wiki? Надо подумать... и посмотреть, как она работает внутри. Спасибо.

>Думаю, не сильно ошибусь, если предположу возможность связей на основе какой-то из
>семантических моделей.

Я тоже думал в этом направлении... Но здесь для меня непаханое поле, т.к. с семантическими сетями/моделями я нормально не работал... Ну хоть знать, куда двигаться :-)

>Где и как искали?

Да по-разному. Вот здесь, например:
http://www.books.ru/shop/books/486818

Ну и по поисковикам...

ROLAP ("снежинка" в реляционной модели) соответствует моим прикидкам в самом первом сообщении (только там, скорее, "звезда", ну да всё поправимо)...

>Я и говорю, может, есть смысл смотреть на альтернативные варианты?

Я так подсел на реляционную модель, что, читая про другие, тут же пытаюсь представить их в "реляционном виде"... Вот она- инертность мышления... :-)

Вобщем, велика вероятность, что придется писать фреймворк.... :-)

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

Вобщем, на ближайшие сутки, как минимум, мне есть над чем серьёзно подумать... :)

P.S. Перечитал первое сообщение. Нашёл его довольно запутанным и сложным. Спасибо за отклик, внимание и помощь. :)

Решение 1... Возможно, и будет частично по-Тенцеру... (та "нереляционная" часть тезауруса, о которой писал guest_20040621). Но не совсем. Мысли пока не оформились настолько, чтобы выдать их емко и относительно кратко, убрав попутный бред (отделив зерна от плевел). Пока склоняюсь к полу-Тенцеру + некоторый фреймворк (идея ув. guest_20040621 о тезаурусе из двух частей)... В пользу, точнее, не во вред этому, является совсем небольшое число пользователей-исследователей и относительно небольшое число записей- в пределах нескольких сотен тысяч (2-3 максимум), причем запросы на всю глубину дат будут очень редки... Относительно дублирующих сущностей- круг пользователей будет достаточно ограниченным, а добавлять новые сущности (не записи) будет вообще только один человек.

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

Решение 3- данная работа, к сожалению, не предполагает достаточно сильных постоянных заработков... Да и к тому же... мой интерес к исследуемым темам... А сопровождать, приглядывать за этой штуковиной и так и так придется...

Спасибо за интерес к теме.



А при чем здесь lookup поля? Да и про Дельфи я ничего не говорил :)
Это Вы, наверное, с каким-то другим сообщением перепутали... :)