Шаг 106 - Oracle - Модели взаимосвязей объектов и проектирование

Думаю любой администратор БД (среди вас есть такие? :) ), не раз за свою практику сталкивался, с моделированием взаимосвязей между объектами. Этот вопрос достаточно широкий и сложный, но интересный! Как правило, первым шагом в проектировании БД является логическое проектирование. Как показывает опыт, недостаточно продуманное логическое проектирование выполненное в спешке приводит к плачевным результатам. В большинстве случаев приходится реконструировать уже работающую систему, что-то в ней изменяя или перестраивая. Но, как правило, полностью избавиться от недостатков не удается! По этому самое разумное, что следует сделать на стадии проектирования вашей БД - это ОЧЕНЬ ХОРОШО продумать ЛОГИЧЕСКУЮ(!) структуру основных компонентов вашей БД, а уже после этого переходить непосредственно к физическому и программному оформлению БД. Логическое проектирование играет решающую роль в обеспечении целостности данных. Как правило, производительность системы может определяться на стадии физического проектирования. А вот целостность данных практически полностью определяется принципами организации структуры системы, сформированными на стадии логического проектирования! К слову сказать, именно при процессе логического проектирования можно при достаточном продумывании заложить возможность известной свободы в выборе средств физической реализации системы, что позволит в дальнейшем совершенствовать ее в процессе эксплуатации.

В основе при начале логического проектирования лежит - объект (entity) - представляющий собой некоторый элемент (сущность). Применительно к конкретной предметной области. Например, это может быть - "товар", если рассматривать самую популярную область применения БД такую как создание складского учета. И теперь термин объект - это некоторое понятие определяющее, например, количество банок пива "Старый мельник" - на складе. Одна банка - это "объект" складского учета и он представлен в базе данных. Взаимосвязь (отношение - relationship) между объектами БД - это ассоциативная связь между объектами. Например поставщик А - такого-то числа отгрузил 100 кг. муки или покупатель Б - купил оптом сто ящиков пива "Старый мельник". Здесь возможно построить связь. Атрибуты (atributes) - это характеристики объекта. Например, атрибутом объекта банка пива может служить срок хранения, температура хранения, объем, стоимость и т.д. Обычно говорится, что атрибут принимает некоторое конкретное значение из домена (domen) атрибута, множества допустимых значений. Вот именно значения этих атрибутов и будут использоваться в дальнейшем в реляционной модели. Эти определения как бы абстрагированы от конкретной предметной области. Вот именно здесь мы подходим к моделированию взаимосвязей БД, которую в 76-х была предложена П.П. Ченом (P.P. Chen). Это так называемая методика диаграмм взаимосвязей между объектами (Entity - Relationship - Diagram ERD). Так же она известна под названием семантическая модель данных (semantic data model), так как она учитывает семантику (смысл) данных по отношению к той предметной области, в которой будет использоваться проектируемая система. По большому счету методика ERD предшествует реляционному моделированию. Так, например после построения диаграмм ERD результаты могут быть непосредственно преобразованы в реляционную модель, а последняя в физическую модель.

Диаграмма ERD представляет объекты в виде прямоугольников. Наименования атрибутов объекта приведены внутри прямоугольника, а наименование объекта снаружи. Между прямоугольниками проведены стрелки, которые представляют тип взаимосвязи между объектами. Вот наконец и самое интересное! Существует три основных типа взаимосвязи между объектами:

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

106_1.gif (5590 b)

Ярким примером такой связи может быть муж и жена. Мужу соответствует одна жена, а жене то же один муж. (Варианты полигамии, полиандрии и групповых браков мы не будем рассматривать, в следствии того, что участники таких "семей" - как правило сами не в состоянии определить кто к кому и как относится :))) ) Есть еще один вариант представления взаимосвязи один к одному, такой например, как взаимосвязь подтипов (subtype). Такого рода соотношения объектов являются одним из фундаментальных понятий в объектно ориентированном (ОО) анализе и проектировании или моделировании. Вот вам и ООП, по сути дела, это построение иерархии классов или объектов или экземпляров класса-объекта. Кому как больше нравится. Нифига себе до чего добрались, так недалеко и до фундаментальных основ ООП дотопать! А, по чему бы и нет! :) Хватит отвлекаться, смотрим следующий рисунок:

106_2.gif (6633 b)

В данном конкретном случае квадрат является частным случаем семейства прямоугольных! Направление стрелки на линии связи указывает путь наследования (inheritance). Немаловажным моментом при использовании связей один-к-одному являются вот такие вопросы:

Вот если два раза нет и один раз нет, тогда все нормально, а если что-то не совпало, то оно того не стоит! :)

Следующим рассмотрим наиболее часто встречающийся тип взаимосвязи один-ко-многим! Смотрим рисунок:

106_3.gif (5672 b)

Объект "Страна" - связан со множеством объектов "Город". Хотя в некоторых, странах имена городов совпадают, это решаемо при построении таблицы с составными первичными ключами или специальными идентификаторами городов. Хотя это уже мелочи.

И, наконец, давайте рассмотрим взаимосвязь, многие-ко-многим. Смотрим рисунок:

106_4.gif (8820 b)

Вообще я бы настоятельно рекомендовал Вам при проектировании БД по возможности стараться не применять такой тип связи. И вот почему! Реляционная модель не в состоянии непосредственно реализовать взаимосвязь "многие-ко-многим"! Задумайтесь над этим! Вследствии этого для обеспечения атомарности данных взаимосвязи типа многие-ко-многим следует заменять несколькими взаимосвязями один-ко-многим. Да, количество объектов БД увеличивается, но правила Кодда соблюдаются! Вот так всегда приходится выбирать из двух зол меньшее и еще не известно, что было лучше! Далее диаграммы ERD преобразуются в реляционную модель с помощью так называемых CASE систем (Computer Assisted Software Engineering) или системы автоматизированного проектирования программного обеспечения. Примером такого ПО может служить Disigner/2000 от фирмы Oracle. Вот собственно кратко, что касается БД и ее проектирования! Но это очень, ОЧЕНЬ, важный момент!!!


Предыдущий Шаг | Следующий Шаг | Оглавление
Автор Летучий Сергей.