Часто обсуждаемый вопрос о хранение сущностей с наперед не известным набором свойств, или, шире - наперед неизвестный набор сущностей (даже - "Знаний - в "Базе Знаний") обычно утопает в соображениях, что все это велосипеды, и для разумно очерченной предметной области вполне можно построить специализированную структуру, быстрее работающую в силу своей большей приспособленности к SQL и т.п...

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

Если возможно - хотелось бы кратко видеть следующее - структура хранилища на уровне идей + структура (ядро) на уровне реализации БД - CREATE TABLE-ы (упрощенно). Реализация интерфейса юзера мне в этом контексте не интересна (хотелось бы оставить ее за скобками, или как дополнительное обоснование к выбору структуры).

Alexey Rovdo
1. Идет ли речь о том, что сущности и свойства наперед неизвестны разработчику и по мере их возникновения (уточнения) он должен модифицировать (вводить эти сущности) приложение и/или БД? Или же эти сущности и свойства наперед неизвестны даже самому приложению, т.е. имеют динамический характер и могут создаваться и видоизменяться прямо в процессе работы пользователя (приложения) с БД?
не известны не сущности и св-ва, а даже их типы, т.е не возможен полный перечень объектов, учитываемых в системе. система должна хранить все, что пользователь пожелает сохранить о введенной сущности, причем если его взгляд на ее св-ва (и их структуру, если св-во не скаляр, а так же некая сущность) поменяется, то система должна позволять разместить это новое пониманое в той же (реляционной) структуре. Хотя в каждой частной задаче некоторые наиболее часто втречающиеся сущности можно охватить, но их св-ва предполагаются сколь угодно уточняемыми.

Alexey Rovdo
2. Вы хотите рассмотреть возможные варианты построения только реляционных структур или как один из способов решения проблемы допускаете использование объектных технологий (объектные СУБД, инструментарий для объектно-реляционного отображения, объектные расширения классических СУБД) ?
Меня интересуют только варианты реляционных структур. На самом деле вопрос - в каких абстракциях, допускающих реализацию в реляционных структурах, наиболее полно описываются такие хранилища (возможно, и даже наиболее вероятно - с учетом особенностей неких областей приложения - т.е. с некими ограничениями на тип хранимых сущностей и связей). Я хочу концентрировать те конструктивные мысли (подходы), которые разбросаны во множестве в разных топиках.

Спасибо.

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

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

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

- или возможно хранить ссылки (в т.ч. всех сылочных типов) в том же натуральном поле? (при соответсвующем базовом типе это будет означать ссылку на требуемую таблицу сущностей)??

mv
Заведи справочник бизнес - типов:

Название
Базовый тип

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

Достаточно ли этого? Как в случае базового типа "ссылка" получить с одной стороны (текущую) структуру ссылочного типа - будучи в справочнике бизнес_типов, а с другой - будучи в хранилище сущностей - набор конкретных экземпляров (реализаций этой структуры) - для выбора "значения" одного из св-в заданного типа ? Добавить поле "ссылка" на некое описание структур?
Или все-таки справочник бизнес_типов должен быть встроен в общее хранилище описаний (струтур) сущностей?


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

mv
Документы (n)- Значения - (1) Бизнес - типы

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

Документы - это то, что мы называли ранее сущностями? (только теперь это более узкое понятие?). Как в вашей модели организовано (предполагается быть организованным) хранение ЭТИХ САМЫХ "документов"? Считаете ли вы, что это описатели "типов" сущностей? Как они (описатели) организованы?

Значения - что это такое? Это отдельное от "Документы" понятие? Т.е. некоторые конкретные "значения" - это записи некоторой отдельной от "Документы" таблички, имеющие с одной стороны тип "ДокументХХХ", а с другой - набор некоторых свойств?

Или значения - это значения самих СВОЙСТВ "документа" - т.е. таблица "св-ва", связанная с таблицей "Документ", и осуществляющая привязку к документу как типа св-ва, так и его значения?

mv
Чтобы разгрузить систему, для справочника Значения введи Null - значение и, если значение равно null, просто не создавай эту запись.
Что такое справочник "Значения"? Это еще одна таблица? И каждое значение (float8) я должен хранить и в нем??? . Или "просто" имеется в виду в _интерфейсе_ заполнения значений свойств, при выборе значений _ссылочных_ типов добавлять к набору еще и значение Null? И при вводе пользователем Null в поле соответствующего базового типа удалять заполняемую/изменяемую запись???

Хотелось бы понять, из какого набора абстракций ("Документ"/"Свойство"/"Значение"/"Тип"/"Базовый тип") состоит ваша модель. И где (в какой из абстракций) в ней описана/хранится структура (модифицируемая!) "документов", а где - сами(?) "документы" (или они называются иначе?). Или не предполагается отдельного хранения "структур"?



Жаль, что гуру, съевшие всех собак в данной области не горят желанием поучавствоать. Или для их участия необходимо позиционировать тему как "... велосипеды с квадратными/треугольными колесами" (т.е. вещь ненужную и вредную)?

skorohod /topic/134831&pg=14

Спасибо, смотрел.
skorohod
Наверно эта ветвь форума не совсем соответствует Вашему вопросу.
Вот если-бы ввести отдельную тему в ветви "Сравнение СУБД" (напр. "Сравнение реализаций ОР СУБД") - можно было-бы вести обсуждение Вашего вопроса там.

Меня интересуют не сравнения СУБД, а "типовые" решения хранилищ "плохоструктурированных данных" (вернее данных, описание которых вводятся/модифицируются вместе с вводом/модификацией самих данных). Т.е. именно "_конструктивные_особенности_" схем данных, позволяющих таковое размещение без переконструирования структуры.
- "Объектные" надстройки, выполняющие "криэйт таблы" на каждую вносимую сущность меня мало интересуют, ибо проблема не в том, что я хочу размещать модное слово "объект", а в том, что то, что я хочу размещать, будеть подвижно, и должно быть описано в таких терминах, которые будут достаточны для покрытия всего, что только сможет быть размещено, причем "покрытие" должно осуществляться как со стороны помещения так и со стороны интерпретации данных (т.е., в известном смысле - интерфейса - т.к., сдается мне, если набор абстракций, воплощенных в некую схему БД, позволяет интерпретировать сохраненную в ней информацию {на основе сохраненной в ней-же информации "об интерпретации"}, то стало быть и позволяет [понятную юзеру] визуализацию этой интерпретации - сиречь интермордс).


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

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

А далее, сдается таки мне, существует уже (в природе) некое количество реализаций таковых построений, т.е. такого "анализа" нашей "предметной области". И у этих реализаций есть и свои особенности, и свои плюсы и минусы. И свои принципы, порождающие и то и другое. И именно как у архитектур конкретных, "обычных реляционных БД" (а отнюдь не их {ОООООРРРРРРР}СУБД). Вот и хотелось все это и оборзеть, сведя в какую-то систему.


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


________________________
ЗЫ: skorohod
А так, есть только тема
http://www.sql.ru/forum/actualthread.aspx?tid=9021
которая тянется уже третий год, и охватывает и объектно-ориентированные и реляционные и объектно-реляционные СУБД, и большая часть постов в ней типа "сам дурак", хотя есть и полезные...
в этих темах есть все: - и "сам дурак", и "надстройки-построители конформных баз" (обзовем их так) и реализации в упомянутом выше смысле (в смысле отображения анализа предметной области на "стандартную" структуру БД, но с выделенными нами панацейными сущностями и связями). Вот и хотел эти последние выделить в отдельном месте. И именно как структур даных.

Alexey RovdoВ соседних ветках это уже отмечалось, но выскажусь еще раз.
Мне кажется, что попытка втиснуть в реляционные структуры динамически изменяющуюся модель (причем без использования CREATE TABLE и пр.) обречена на провал. Реляционные СУБД просто не приспособлены для такого обращения. Разумеется, можно построить некие абстракции высокого уровня и впихнуть в них все необходимые данные, но ценой станет отказ от множества функций, предоставляемых именно реляционной СУБД. Т.е. по сути прийдется строить объектную СУБД поверх реляционной, что ИМХО просто лишено смысла. Зачем так надрываться, если есть собственно объектные СУБД, причем ориентированные именно на использование с динамически изменяющимися структурами данных?

Вы невнимательны:
авторсдается мне, что таковые построения существуют, и применительны к весьма неширокому кругу (кругам?) задач (назовем их "секретарскими"?),
Повторю, я не хочу хранить "объекты" в смысле ООП. Я хочу понять, каковы мои возможности в построении реляционной БД для хранения разнообразных до/переопределяемых сущностей. (нигде у меня не сказано про "наследование" и еще черт знает что). Более того, дергать криэйттаблы только затем, что у меня подвижная структура сущностей (и больше ничего) - это ли не надрыв? А вот я возьму и выйду за любые рамки по количеству таблиц/полей. И что тогда?

От чего и где отказываемся - это вопрос конкретной реализации "абстракции высокого уровня ", которые и хочется рассмотреть (и поковырять хотя бы виртуально пальцем), а, думается мне, не вопрос ИМХО-в.

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



А преимущества объектных БД в деле размещения динамически изменяемых структур данных можно рассмотреть и в другом месте - там где уже не один год меряются ИМХа-ми.

Alexey RovdoТак ведь тут вовсе не промежуточный случай предлагается разобрать, а самый что ни есть крайний. Да и в промежуточном случае (т.е. если в задаче есть и статические, и динамические структуры данных) строить объектную базу поверх реляционной на мой взгляд нерационально.
ну чё вы словами-тта кидаетесь? Хде сказано за объедки? За сущности базар идет. И токо за них. Не путайте красное с кислым. (встречается и сладкое и полусладкое).

Alexey Rovdo Имеет смысл просто использовать две базы и соответствующий инструментарий (в т.ч. и входящий в состав самих СУБД) для их связывания. Обычно именно так и поступают.

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


Еще раз! Просьба не базарить за объедкные БД. Не наследуем мы код. Не наследуем и не перекрываем и задач таких не ставим.
Мы узкую задачу посмотреть хочем.
Меж прочим.


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

Alexey Rovdo А вот ниже уже выясняется, что и крейт-таблы все-таки допустимы и статические данные все-таки какие-то есть.
Еще раз огромная просьба, свои домыслы и вымыслы обсуждать в в более приспособленном для этого месте. Тут сделана, признаюсь неудачная, попытка обсудить сугубо узкий вопрос - об отражении задачи о сохранении наперед не определенного набора сущностей с наперед не определенными атрибутами на жестко предопределенную структуру данных. Построить т.с. абстрактную модель именно этой, с позволенья сказать, "предметной области". И по возможности просмотреть, а в идеале - _систематизировать_ варианты (буде такие будут предложены). Но варианты именно такого отображения.

DogenP.S. По большому счету это все фигня, РСУБД внутри РСУБД. Имхо, может быть нужно только для построения перечней объектов с наперед неизвестным набором атрибутов.

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

Dogen "по наличию атрибута" у меня реализовано путем введения сущности "тип документа", а ей уже соответствует определенный набор атрибутов.
Набирать заранее неизвестный набор атрибутов для каждого документа мне нет нужды (ну если приперло создать уникальный документ - создайте для него новый тип, сиречь набор атрибутов). Это дисциплинирует.
Продолжаем колоться
Вот уже прорезалась табличка "тип документа" (или даже "тип сущности"?) + табличка "атрибуты сущности" - т.е. это описатели структуры (уже "юзерской") сущности. По ним, я так понимаю, вы интермордс вырисовываете для заполнения экземляра "документа" заданного вида. Так глядишь и раскрутим на более подробное раскрытие.

Сразу вопрос. "Тип документа" (сущности) у вас имеет какие либо иерархические причандалы? (Скажем просто - в качестве организации просмотра типов по дереву типов, а не для какого-нть наследия).


И (только тихо! не к ночи помянуто): забирались вы в реализацию "наследования" структур одним "типом документа" (в вашей терминоЛогии) от другого или нет? (не в смысле выкопирования описателя, от одного id к другому, а в смысле именно "наследования". Тилько шопотом (боюсь опять выскочат объектщики, тьфу на них). И нужно ли оно в таких вещах? - Понятно, что запросы, если описатель собирается просмотром по "дереву", усложнятся (вернее могут - "ит депендс"), а обычная для БД реализация "наследия" в смыле выкопирования атрибутов от одного "типа сущности" к другому пусть и не съекономит места в описателях (и не даст жесткости, т.е. даст свободу не иметь "потомку" ненужного добра), но не заставит заморачиваться просмотром всех "предков"). Или "наследование" структур тоже вполне реализуемо?

Dogen
Типы документов я наследовать один от другого не собираюсь, поскольку в нашем случае это будет полезно, но трудозатраты вряд ли окупятся. В будущем - может быть.
Разумный скепсис, но, с другой стороны, отсутствие опыта [попыток реализации] - это отсутствие опыта. Т.е. оценка трудозатрат не подкреплена реальными шишками от реальных грабель. - Я как раз на развилке в принятии решения. С одной стороны - казалось бы упрощается обновление наследуемых атрибутов при их редактировании в предке. Но только тех, которые не поимели конкретных значений в потомках (тут возникает проблема разруливания по логике - какие-то атрибуты должны иметь возможность перекрывать в потомке тип, заданный в предке, какие-то нет. Какие-то действия пользователя по настройке классификации типов _должны_ а) однозначно пытаться сменить тип атрибута и во всех потомках сущности ("CASCADE"), б) - какие-то только в тех, которые еще "не перекрыты явно" (не поимели своих строк в описателе) или не поимели _значений_ унаследованного типа (в этом случае - нужно будет "перекрывать" ("теневым образом" - разве что сообщив об этом) атрибуты потомков в процессе редактирования атрибута предка, в) какие-то должны иметь влияние только на текущий уровень классификации (т.е. все потомки не должны наследовать этого атрибута). Все то же самое, как легко заметить, можно и сделать с помощью выкопирования описателя объекта в его детей (и поиметь те же вопросы "теоретического" характера при переопределении атрибутного состава предка).

DogenНо честно говоря, намного проще написать процедуру копирования набора атрибутов одной сущности в новый такой набор.
чего проще - всобачить триггер на заимствование аттрибутов при создании потомка (+- для полной логической завязки - триггер на редактирование предка, но тут - сразу вопросы к логике - т.е надо оперделиться "что мы хотим поиметь").

Кстати, в некоем смысле то, что привел Alexey Rovdo описывает (частично) то, о чем говорите и Вы? Т.е. приблизительно та же завязка между типами и экземплярами? Правда самих значений ("расширенных") атрибутов я у него на схеме не вижу. Кажется - только ссылки?



2Alexey Rovdo:
Смотрю я на вашу схемку, и возникают у меня вопросы:

1. За что отвечают поля IsChilde и IsReplicated? Какой в них физ смысл (что за абстракции или логические связки промеж оных в них порылись?)

2. За что отвечает поле d_DocumentExtendedData.DataObjectID (d_DocumentExtendedData.Type - это кааца Fk к ID из aDoc....DataType) ? (если это дубликат d_Document.Type - то это то, о чем я думаю? Т.е. денормализация с целью поиметь нужные индексы в d_DocumentExtendedData ?) Или это ссылка на реализацию атрибута в какой-нть табличке значений? (если вы его находите не через GlobalID)
2.1 (того же типа вопрос и по ObjectTypeID)

3. Ну и т.п.




__
2All:
не видно особых альтернатив к набору абстракций, покрывающих "предметную область" (и даже к реализации). Пока только такой набор (грубо):
1. Сущности
2. Их сотав (описатели)
3. Экземпляры сущностей
+- 4. (вероятно по вкусу) - дублирование всего набора на сущности "блатного" типа "атрибут".

Нешто никто не делал иначе?

Спасибо за ответы.
Посмотрю еще. А пока:
Alexey Rovdo IsChild
Определяет тип атрибута (не забываем, что атрибутом может быть любая сущность), с точки зрения его самостоятельности. Есть атрибуты зависимые и независимые. Зависимые атрибуты (сущности) имеют "хозяина" (d_Global.Owner_id). Зависимые атрибуты (сущности) удаляются вместе со своим "хозяином". Поле IsChild анализируется только в момент вставки нового атрибута. После того, как атрибут (сущность) уже оказался в базе, определение его зависимости/независимости уже происходит по значению d_Global.Owner_id.

Немного не допонял.
т.е. вы обрабатываете следующую ситуацию (для простоты считаем что речь идет исключительно о "документах"): "Документ" + "Приложение к нему". (Когда приложение - тоже документ, но не живущий без "хозяина", и удаляемый вместе с ним. Причем оно может входить не более чем в один документ (иначе как рулить удалением? считать ссылки?). Если же ссылочный(сущностный) атрибут (некоего "хозяина") может входить во что угодно (справочный - например контрагенты с их структурой) то он неЧайлд?

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

Alexey Rovdo
Замечание: все, что лежит в таблицах с именами a_... фактически имеет отношение к бизнес-логике, а не к самим данным.

В моем случае это "логика интерпретирования вообще". Т.е. имеет прямое отношение к хранению типов и ("хранению") их интерпретации.
Alexey Rovdo

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

С этим ясно. Что-то в этом смысле мыслилось. Правда в некоторых случаях есть "предельная емкость".
Alexey Rovdo
IsHeritable
В данной схеме нет, но в отдельных случаях тоже использовал.
Если объекты могут объединяться в иерархию (например, в таблице d_Document есть поле parent_id, указывающее на документ-родитель), то атрибуты родительского объекта могут считаться и атрибутами всех принадлежащих им сущностей-потомков, а могут и не являться. Поле IsInherited как раз и определяет этот факт. Разумеется есть две стратегии поведения, которые выше уже и были упомянуты. 1-я - это строить схемы и писать процедуры для того, чтобы вытягивать сами значения наследуемых атрибутов из сущностей-родителей. 2-я - при создании сущностей-детей копировать все наследуемые значения в соответствующие атрибуты именно этих сущностей. Второй способ на мой взгляд лучше с точки зрения быстродействия выборки и обработки запросов на чтение. Первый способ сокращает издержки при записи и изменении значений атрибутов.

Вопрос возникает при перемещении по иерархии. Какие вообще перемещения считать допустимыми? Зависит ли признаки допустимости перемещений от типов сущностей. Есть ли у кого опыт анализа ситуаций в этой области? Или все предпочитают не заморачиваться данным вопросом, запретив перемещение типов в классификаторе (при наличии "наследования" атрибутов, в любом из предложенных видов)
Alexey Rovdo
Поле d_DocumentExtendedData.DataObjectID указывает на сущность, которая является значением атрибута. А ObjectTypeID ограничивает возможный выбор таких сущностей только одним типом (бизнес-логика). Чтобы было чуть понятнее приведу еще один модуль этой базы (простейшие сущности - параметры).
Ну где-то так я и думал (т.е. даже для атрибута "простого" типа вы отсылаете его в требуемую глобальную таблицу(ы) значений, кстати, в силу зависимости таблиц от типов, запрашивание величин атрибутов (или их интерфейсов - для сущностных) происходит динамически - ищем таблицу (поле) по типу объекта + ищем интерфейс по тем же признакам? Имена втавляем в строки запросов и т.п...?).
Хотя было сомнение.



2Dogen
Странно таки что нет других абстрактных схем. Головы то разные. Или у всех испорчены реляционным взглядом на вещи? (проскакивали тут намеки на нечто иное в принципе - какая то даже предикативная арифметика, казалось бы. Ихде они авторы?)

Dogen 4321

2Dogen
Странно таки что нет других абстрактных схем. Головы то разные. Или у всех испорчены реляционным взглядом на вещи? (проскакивали тут намеки на нечто иное в принципе - какая то даже предикативная арифметика, казалось бы. Ихде они авторы?)

Бритва Оккама, знаете ли.
Думаю над бритвой, и что же вона поодхряпала.

Сделал запрос по паре [ОТНОШЕНИЕ ИНТЕРФЕЙС] на форуме. Нашел интересные ссылки (смотрел когда-то, но к переосмыслению - не вред) .
Итак, стандартное конструирование одна "сущность" - одна таблица (т.е. одно ОТНОШЕНИЕ и один, связанный с ней ИНТЕРФЕЙС). В том случае если атрибуты всех сущностей ничем не выделяются с т.зрения задачи и полностью характеризуются именем и значением, (т.е. - "типовой перечень", как в вашем случае), то требование отдельного интерфейса для каждой сущности избыточно - т.к. все отношения вырождаются в отношение "сущность-атрибут". И хранение таких "сущностей" в отдельных таблицах (в "специализированных отношениях") - избыточно. Т.е. как правило в наших "конструкторах" реализуются именно такие подслучаи. Нет?


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

По ссылкам нашел такой вариант:
Кроме _отношения_ сущность-атрибут для строго типизированных атрибутов , реализованного в наборе таблиц (по числу типов - как и предлагалось, правда ссылка интересна отдельной реализацией перечислений как _базового_типа_ , правда членами перечислений, судя по всему, имеют только строковое наименование и ничего более), вводится понятие "СВЯЗЬ" (т.е. исключительно "бинарное" _отношение_ сущность-сущность, но с заданным типом - т.е., на деле, - "тренарное отношение" сущность<->сущность<->тип_связи(специализированная сущность)). Как это обыгрывается (в т.ч. - в интерфейсе) т.е. характеризуется ли "тип_связи" чем-то кроме наименования- непонятно.



2 Dogen:
можно запихать. Можно не запихивать. Пока не пойму, как это связано с классом задач (т.е. как(какой) "минимализм" в предметной области делает оправданным тот или иной подход к построению схемы данных) - не отвечу на Ваш вопрос. А для понимания и хочется охватить набор возможных решений.