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

Технология получения ДЛМ РБД на основе ER-диаграммы.

Терминология

*ИЛМ предметной области*	*ДЛМ РБД*
класс объектов	отношение, таблица
свойство	атрибут, поле, столбец
опциональность свойства	опциональность атрибута
уникальный идентификатор, первичный ключ	первичный, уникальный ключ
связь	внешний ключ - атрибут (ы), поле (я) – копии соответствующего первичного ключа родительского отнощения (таблицы)
опциональность связи	опциональность внешнего ключа

Виды документирования ДЛМ

Документировать процесс получения модели даталогической модели реляционной БД можно разными способами.
1 Формировать математическую запись получаемой схемы БД в виде совокупности описания схем реляционных отношений в виде Rm(Am,1, Am,2, …, Am,k). Такое представление удобно для дальнейшего анализа полученных схем отношений на соответствие требуемой нормальной форме.
2 Делать формализованное описание каждого реляционного отношения в виде таблицы (таблица 12).

Таблица 12 — Формализованное описание реляционного отношения «Название отношения»>

Название атрибута (поля)	Поле 1	…	Поле к
Ключ (ПК— первичный ключ, УК – уникальный ключ, ВК – внешний ключ)		…
Обязательность (опциональность) значения (Д.б.—должно быть, М.б. – может быть)		…
Примеры данных

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

3 Представлять схему реляционной БД графически – рисунок.

Рисунок — Графическое представление схемы реляционной БД

На рисунке название таблиц выделено. Помечены первичные (ПК) и внешние ключи (ВК). Если внешних ключей несколько, то они нумеруются – ВК1, ВК2. Связи прорисованы линями, идущими горизонтально и вертикально. Линии связи идут от первичного ключа к соответствующему внешнему ключу. Возле атрибута внешнего ключа (на стороне «много») линия связи заканчивается стрелкой. Графическое представление удобно для понимания логики структуры базы данных, отслеживания связей, моделирования SQL—запросов.

Формирование ДЛМ реляционной БД

Рассмотрим последовательно алгоритм формирования логической структуры реляционной базы данных на основе ER—диаграммы предметной области.
1 Преобразование простых классов объектов. Это классы объектов, информация о которых первой появляется в предметной области, они не имеют рекурсивных связей и не входят в супертипы, арки. Связи на стороне этих классов объектов имеют тип «один». Такие классы объектов называют родительскими или главными.
Алгоритм преобразования следующий: именем реляционного отношения становится имя класса объектов. Каждое свойство класса объектов становится атрибутом отношения, первичный ключ выделяется, уникальные (потенциальные) ключи помечаются. Все свойства, входящие в состав первичного ключа, должны быть обязательными. Большой составной первичный ключ может быть заменен суррогатным (техническим) первичным ключом. Атрибуты, входящие в состав уникальных ключей могут быть необязательными. Из состава уникальных ключей могут быть выбраны (помечены) ключи, альтернативные первичному ключу, для возможной реализации связи полученного реляционного отношения с другими отношениями.
2 Преобразование связи 1:М. Связь реализуется копированием первичного ключа из реляционного отношения на стороне «один» в реляционное отношение на стороне "много" – из главного отношения в подчиненное. Новому появившемуся атрибуту присваивается уникальное в пределах отношения имя. В имени хорошо использовать имя таблицы, откуда осуществляется копия. Этот вновь появившийся атрибут помечается как внешний ключ. Если на ER—диаграмме опциональность связи со стороны «много» была обязательной, то опциональность внешнего ключа также обязательная, либо наоборот. Если уникальность класса объектов со стороны "много" определялась из связи, то внешний ключ должен входить в состав первичного ключа, эта ситуация соответственно помечается.
3 Преобразование связи 1:1. В ER—диаграмме связь 1:1 может иметь разную опциональность. От этого зависит её отображение в схеме БД. Если связь "один к одному" обязательна с одной стороны, то поле с внешним ключом добавляется в отношение на обязательной стороне и это отношение становится подчиненным, опциональность внешнего ключа будет обязательной. Если связь 1:1 необязательная или обязательная (что очень редко) в обоих направлениях, необходимо выбрать в какую таблицу будет помещен внешний ключ. Решение принимается в зависимости от времени появления и объема данных:
— если строка в одном отношении создается обычно раньше, чем в другом (это определяется предметной областью), то это отношение назначается главным, а внешний ключ создается в подчиненном отношении;
— если в одном отношении будет меньше строк, чем в другом, то есть его размер будет изменяться менее динамично, тогда это отношение назначается главным, а внешний ключ создается в подчиненном. Внешний ключ создается копированием первичного ключа из главного отношения в подчиненное. Опциональность внешнего ключа определяется опциональностью связи. Замечание: внешний ключ, отображающий такую связь должен быть уникальным, это усиливает связь типа 1:1.
4 Преобразование рекурсивной связи. Поскольку рекурсивная связь – это связь между объектами одного класса объектов, то внешний ключ создается в том же отношении путем копирования первичного ключа в эту же схему. Дополнительные ограничения рекурсивной связи, такие, например как, объект не должен ссылаться сам на себя (нельзя быть женатым не себе самом, нельзя подчиняться себе самому) реализуются либо в логике приложений, либо в таких объектах БД, как хранимые процедуры, что более предпочтительно. Замечание: для рекурсивной связи 1:1 комбинация значений первичного и внешнего ключа не должна повторяться в кортежах отношения.
5 Реализация взаимоисключающих связей. Реализация арка в логической структуре может иметь несколько альтернатив. Имеется два способа преобразования арков во внешние ключи: явное проектирование арка и неявное проектирование арка.
При явном проектировании арка создается столбец внешних ключей для каждой связи, входящей в арк. Этот метод используется в том случае, если внешние ключи имеют разные форматы (тип, длину). При этом, если связи на ER—диаграмме обозначены как обязательные, то столбцы внешних ключей не могут определяться как обязательные, потому что для каждой строки реляционной таблицы имеет значение только один из внешних ключей - должна быть реализована ситуация взаимоисключаемости связей - «или—или». Проверка исключительности каждого внешнего ключа реализуется с помощью хранимых процедур или триггеров.
При неявном проектировании арка создается один столбец внешних ключей и один дополнительный столбец, используемый как индикатор типа. Так как связи взаимоисключают друг друга, для каждой строки таблицы должно существовать только одно значение какого-либо внешнего ключа. Опциональность внешнего ключа определяются опциональностью связи – если она необязательная, то и внешний ключ будет иметь необязательное значение. При неявном проектировании арка все внешние ключи должны быть одного формата.
Поскольку на ER— диаграмме связи входящие в арк имеют обязательное значение на стороне «много», то и внешний ключ при неявном проектировании арка тоже имеет опциональность «должен быть», в противном случае было бы наоборот.
6 Реализация взаимоисключающих классов объектов. Реляционные отношения, отображающие супертипы и подтипы могут быть смоделированы по—разному. Два наиболее используемых способа реализации: в виде одного отношения и в виде нескольких отношений (сколько подтипов – столько отношений).
При реализация подтипов в виде одного отношения все свойства каждого подтипа отображаются в едином отношении супертипа. При этом необходимо также добавить поле «тип» для обозначения того, к какому подтипу относится строка таблицы. Обязательность значений полей таблицы в этом случае должна поддерживаться дополнительно средствами СУБД (ограничениями check, триггерами). Реализация в виде одного отношения рекомендуется в случае, если у подтипов небольшое количество собственных, присущих только им, свойств и связей.
В таблице данные одного подтипа выделены курсивом, другого – жирным шрифтом. Опциональность всех полей таблицы, принадлежащих подтипам – «может быть».
В случае реализации подтипов в виде нескольких отношений, каждый подтип отображается в отдельном отношении (сколько подтипов – столько отношений). Атрибуты супертипа повторяются в каждом отношении подтипа. Такая реализация рекомендуется в случае, если имеется большое количество свойств или связей, присущих только отдельным подтипам.
В таблицах – представлена реализация супертипа в схеме БД в виде двух отношений (два подтипа).
7 Реализация связей М:М. Наличие в ER—диаграмме связей М:М – это не дообследование предметной области и в этом случае модель предметной области не совсем адекватна.
В случае если связь М:М все—таки осталась, то от неё в схеме реляционной БД необходимо избавиться. Реляционные СУБД такую связь не поддерживает.
Для того чтобы разорвать связь М:М, в схеме реляционной БД создается искусственное отношение, в которое включаются копии первичных ключей из отношений на сторонах связи. Эти копии становятся соответствующими внешними ключами. Первичный ключ такого отношения состоит из обеих копий первичных ключей. В такую суррогатную таблицу по желанию проектировщика могут быть перенесены некоторые атрибуты из отношений на сторонах связи М:М. В любом случае будет получена модель, отражающая предметную область неадекватно.