Моделирование систем баз данных

Связи классифицируются по степени  связи и по классу принадлежности. Степени связи бывают 1:1, 1:n и m:n. На диаграммах степень связи обозначается в виде знаков 1, n или m у соответствующей сущности.

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

 

Рисунок 15 - Диаграмма Г. Джексона со связью 1: n, необязательной с одной стороны и обязательной с другой 

 

IDEF1 - методология инфологического проектирования

IDEF1-методология  проектирования структур данных [15-18]. Процесс проектирования модели данных разбивается на пять стадий:

стадия 0 - начальные действия, которые включают определение проекта, план сбора  данных, авторские соглашения, стандарты  и т.п.;

стадия 1 - этап идентифицирования и определения сущностей;

стадия 2 - идентификация и определение  отношений;

стадия 3 - идентификация и определение  ключей;

стадия 4 - идентификация и определение неключевых атрибутов. Остановимся поподробнее на каждой стадии IDEF1 - методологии.

IDEF1 - модель данных должна быть описана и определена в терминах как ее ограничений, так и целей. На стадии 0 перед разработчиками ставится несколько целей:

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

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

На  стадии 1 определяются сущности. Большинство  сущностей могут быть определены на основе исходного материала, собранного на стадии  0. Если при моделировании расширяется или детализируется предшествующая модель данных, то соответствующие сущности должны быть выделены из прежней модели. К сожалению. IDEF-методология предлагает пользователю лишь отдельные продукты, не имеющие общего хранилища данных и сущности придется выбирать "вручную". В процессе IDEF1 -проектирования ведется глоссарий сущностей, который имеет "местное" значение. Нa стадии 1 глоссарий представляет набор определений сущностей, состящих из следующих компонентов:

- имя  сущности;

- определение  сущности;

- синонимы  сущности.

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

Если  сущность-родитель и сущность-потомок  представляют один и тот же объект реального мира, то родительская сущность является общей сущностью, а сущность-потомок является сущностью-категорией. Ассоциация между этими двумя сущностями называется отношением категоризации. IDEF1-модель допускает только отношения "родитель-потомок" и категоризации. Эти отношения называются специфическими. Отношения типа "многие-ко-многим", n-арные отношения моделью не поддерживаются и в дальнейшем подлежат разбиению на несколько специфических отношений.

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

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

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

Достоинством IDEF1-методологии проектирования данных является наличие CASE-средства (пакет IDEF1X), позволяющего строить модели уровней сущностей и вести глоссарии. Однако IDEF1X можно назвать скорее средством построения диаграмм (моделей), а не проектирования систем. Разработанные с помощью него модели и диаграммы могут быть несомненно использованы для принятия решений по структурам таблиц базы данных и программ, но само средство конкретных решений не предлагает (например, не формируются предложения SQL описания базы данных, таблиц, индексов и т.д.). Нет связи на уровне глоссариев между различными проектами. Это существенные недостатки при разработке больших автоматизированных информационных систем.

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

назад | содержание | далее

3.3. Алгоритмы проектирования БД  

Получение отношений  из ER-диаграмм П.Чена

Методология проектирования базы данных П.Чена содержит как правила построения ER-моделей. так и правила перехода от этих моделей к структурам данных [23, 24]. Для их иллюстрации предложены специальные диаграммы структур данных (data structure diagram). На этих диаграммах таблица изображается в виде прямоугольника, а связь - в виде стрелки между таблицами.

Алгоритм  был предложен для СУБД с моделями данных, разработанных но предложениям CODASYL. Он может использоваться и для проектирования реляционных баз данных, но результат проектирования будет не всегда эффективным. Изложим кратко правила перехода от ER-моделей П.Чепа к структурам данных.

В случае, когда связь определена на двух разных типах сущностей может быть два  решения;

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

 

 

 

Рисунок 16 - Диаграмма структур данных для двух сущностей,

связанных "один-к-одному" и "один-ко-многим" 

 

б) для связей "многие-ко-многим" заводится отдельная таблица как это показано на рисунке 17. На этом рисунке таблица С - вновь создаваемая, которая будет содержать ключевые атрибуты сущностей А и В. Если связь определена более чем на двух типах сущностей, то для нее заводится отдельная таблица вне зависимости от того, какие типы связей между этими сущностями. На рисунке 18 показан пример структуры данных которая была получена при "трансформации" ER-модели, состоящей из типов сущностей А, В и С, соединенных между собой одной связью. В этой диаграмме таблица D - вновь созданная, состоит из ключевых атрибутов сущностей А, В и С. 

 

 

 

 

 

Рисунок 17 - Диаграмма структур данных для двух сущностей, связанных "один-к-одному" и "один-ко-мноогим" 

 

 

 

Рисунок 18 - Диаграмма структур данных для более чем двух типов сущностей 

 

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

 

Рисунок 19 - Диаграмма структур данных П.Чена для связей,

определенных на однои типе сущностей 

 

Приведенные нами правила перехода от ER-модели к структурам данных немногочисленны  и очень просты. Именно простота этих правил и самой ER-модели П.Чена облегчает их изучение и использование при проектировании баз данных.

Однако  алгоритм перехода П.Чена от инфологической модели к физической реляционной дает не очень эффективные решения по структурам данных. Например, совсем не обязательно отводить две таблицы для сущностей, имеющих между собой отношение "один-к-одному". Для отношений, определенных на одном типе сущностей дополнительная таблица может понадобиться только в случае, когда это отношение вида "многие-ко-многим". В то же время иногда и для связей "один-ко-многим" и "один-к-одному" нужно заводить отдельную таблицу.

Перечисленные недостатки можно объяснить следующими причинами:

а) недостаточностью изобразительных свойств ER-модели П.Чена (на модели не указывается обязательность или необязательность связи, отсутствие связей "род-вид" и др.);

б) правила  перехода от ER-модели к структурам данных П.Чена были предложены первоначально не для реляционных моделей данных. Об этом необходимо всегда помнить и применять данный алгоритм очень аккуратно;

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

 

Получение отношений из ER-диаграмм Диго С.М.

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

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

Далее предлагаются рекомендации для построения даталогических моделей для двух сущностей, связанных между собой бинарными связями. Эти рекомендации для бинарных связей 1:1, 1:n и m:n в основном совпадают с правилами перехода от ER-моделн к реляционным отношениям Г.Джексона. Поэтому изложим лишь отличия.

В описываемой  методике проектирования обращается внимание на некоторые недостатки хранения в  одном файле информации о двух сущностях, связанных 1:1. В связи с этим, предлагается выделять для сущностей отдельные файлы. Вместе с тем. Диго С.М. указывает на возможность использования одного отношения, если связь реализована на одном множестве объектов.

Агрегированные  объекты представляются в даталогической модели так же, как и связи m:n. При этом есть возможность объединения информации о нескольких агрегированных объектах в один файл, если те простые объекты, с которым связан каждый из них, совпадают. С последней рекомендацией можно поспорить: возможность объединения информации о разных агрегированных объектах возможна при условии не только совпадения соединенных объектов, но и при полном совпадении свойств у соединяемых объектов.

На  рисунке 20 приведен пример, в котором  объекты СТУДЕНТ и ПРЕДМЕТ связаны с агрегированными объектами ЭКЗАМЕН и ПОСЕЩАЕМОСТЬ. Объединение этих двух агрегированных объектов нежелательно не только потому, что у них разный состав свойств, но и потому, что они описывают совершенно разные процессы предметной области и количество экземпляров каждого из них существенно различается. Таким образом, объединяться могут агрегированные объекты, связанные с одним и тем же множеством простых, имеющие одинаковые состав атрибутов и количество экземпляров.  

 

 

 

Рисунок 20 - Возможность объединения  агрегированных объектов 

 

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

Алгоритм  проектирования Диго С.М. имеет и некоторые недостатки. Один из них касается агрегированных объектов и он уже обсуждался. Другим недостатком можно считать неформализованный (рекомендательный) характер алгоритма, что ведет к сложностям в его автоматизации. 

 

Получение отношений из ER-диаграмм Г. Джексона

В работе [10] Г. Джексоном был предложен перечень правил, позволяющих получить из ER-моделей отношения реляционной базы данных. Так как данная работа рассчитана на проектировщиков, работающих в основном с персональными компьютерами, то физическая модель идеально подходит для dBASE-подобных СУБД, R-base и Paradox.

Переход от ER-модели к физической начинается с определения набора предварительных  отношений и указания первичного ключа каждого отношения. Изложим  кратко правила получения отношений  из ER-диаграмм Г. Джексона.

При степени бинарной связи 1:1 возможны следующие решения: