Всем привет!

Есть необходимость сделать на нашем сайте классификацию документов. У нас есть backend система (Lotus Notes), в которой готовится и поддерживается классификатор.

Структура классификатора в backend такова: есть несколько справочников (Люди, Компании, События и т.п.), каждый из которых содержит различные элементы (например, информация о людях Путине, Ющенке, компаниях Microsoft, IBM и т.д.). При этом каждый справочник представляет собой отдельную базу со своим набором аттрибутов (для Людей - имя, фамилия, для Компаний - различные реквизиты, и т.д.) и с идентификацией в пределах этой базы (то-есть, разные элементы из разных баз могут иметь одинаковые идентификаторы).

Соответственно, этот классификатор нужно залить в базу данных сайта.

Поэтому концептуально схему базы данных я могу предоставить следующим образом (графическое отображение см. в аттачменте):
Создаем таблицу UnitType (Справочник). Идентификатор записи берем из backend системы. Создаем таблицу Unit (Элемент). Связываем их между собой зависимой связью (так как идентификатор элемента уникален только в пределах одного справочника; идентификатор берем из backend системы; получается что ключ из UnitType мигрирует в часть ключа Unit). Дальше, создаем таблицу Property (Аттрибут). Эта таблица будет содержать аттрибуты элементов справочника. Идентфикатор в этой таблице - суррогатный, так как аналога ему в backend-системе нет. Так как для разных справочников аттрибуты разные, мы для значения каждого аттрибута создаем запись, в которой есть имя аттрибута, и его значение. Связываем эту таблицу с таблицей Unit связью многие-к-одному.

Кроме того, каждый справочник может иметь только фиксированный набор аттрибутов у своих элементов. У каждого аттрибута есть его тип (картинка, дата, текст, reach-текст). В зависимости от типа, значение аттрибута на сайте должно отображаться по разному. Кроме того, на странице элемента справочника нужно выводить названия всех аттрибутов с их значениями напротив, внезависимости от того, заполнены ли для аттрибутов значения, или нет. Поэтому также возникает необходимость в таблице ПулАттрибутов (PropertyPool), которая описывает, какие есть аттрибуты у элементов различных справочников. Эту таблицу мне кажется очевидным связать и с таблицей UnitType, и с таблицей Property. Последняя связь нужна для того, чтобы понимать, как отображать значение аттрибута, и чтобы сделать left join с таблицей Property для отображения названий аттрибутов вне зависимости от наличия для них значений.

Дальше мы связываем элементы с конкретным документом связью многие-ко-многим.

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

Оцените, пожалуйста, насколько хороша модель данных!

Лично меня как-то настораживает, что в таблице Property имеются два поля, которые ссылаются на таблицу UnitType (untp_id мигрировало с таблицы Unit, а Pro_unit_id - с таблицы PropertyPool). Так как аттрибут может принадлежать пулу аттрибутов и элементу только одного UnitType, мне кажется логичным из этих двух полей сделать одно. Как вы считаете?

Спасибо!

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

Ноу проблем!

NewOne1900В чем вы строите концептуальную схему базы данных ?

Как называется это приложение?!

Очень хорошо выглядит и скорее всего удобно пользоваться....

Это приложение называется Sybase PowerDesigner 12. Для рисования моделей БД есть еще другое приложение - ERWin. Это два основных продукта на рынке. Мне больше нравится Power Designer.

NewOne1900Но при постановке вопроса вы не используете стандартные термины поэтому очень сложно оценить Ваше решение ... Приходиться вчитываться:
- где таблица, а где база данных;
- где поля, а что значит элементы;
+ Ваши решения довольно сложные но возможно что это для меня....
Спасибо большое!

Сейчас попробую переписать все с другими терминами, чтобы всем было понятней...

Исходя из пожеланий уважаемого NewOne1900 привожу глоссарий:
Классификация - документы на сайте могут относиться к разным объектом реального мира - разным людям, разным компаниям, разным событиям. Поэтому документы на сайте у нас должны привязываться к этим объектам реального мира. В дальнейшем можно показывать связанные между собой по общим категориям документы.
Справочник - содержит список узлов определенной категории. Например, Люди, Компании, События - это три разных справочника
Элемент - информация о неком объекте реального мира. например, информация о людях Путине, Ющенке, компаниях Microsoft, IBM и т.д.
Аттрибут - атомарная часть элемента справочника. Например, для Людей - имя, фамилия, для Компаний - различные реквизиты, и т.д.
Пул аттрибутов - набор аттрибутов, допустимых для конкретного справочника.

AlexTheRaven4 таблицы слева - это EAV. Если набор и структура справочников меняются реже раза в неделю и нет требования, что управлять структурой справочников нужно без изменения кода приложения - IMHO связываться с EAV не следует. В этом случае подойдёт обычный ROT подход, 1 справочник=1:n таблиц.
Как раз в данном случае у нас есть требование управлять структурой справочников без изменения кода приложения. Кроме того, работа со значениями всех справочников полностью идентична в приложении. Все эти классы в приложении не будут иметь методов - это чисто классы с данными. Поэтому именно в данном случае EAV подходит.

ModelRОдин атрибут, участвующий в двух FK, несомненно точнее.
Спасибо за совет! Тогда выкину, пожалуй, аттрибут Pro_untp_id из таблицы Property, и введу поле untp_id в внешний ключ fk2. Верно?

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

Или лучше было сделать в таблице Unit суррогатный ключ? Как вы считаете?

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

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

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

Скажите пожалуйста, как вы считатет, правильным ли было решение в таблице Unit для первичного ключа использовать два поля?

Полученная модель данных находится в приаттаченом файле.

А насколько плохо, что в таблице Property два поля содержат одно и то же значение (untp_id и Pro_untp_id)? И плохо ли это?

Другими словами, вопрос в том, как лучше - объединять эти два поля в одно, или оставить как есть?

Спасибо!