Переход к реляционной модели данных

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

Если выбор СУБД остановился на реляционной СУБД, а именно этот случай рассматривается в данном курсе лекций, то особенности реляционной модели данных достаточно жестко описывает стандарт языка SQL, поэтому переход к реляционной модели, в общем случае, можно свести к ряду последовательных преобразований. Для ER-модели существует алгоритм однозначного преобразования в реляционную модель данных, что позволило разработать множество инструментальных систем (САПР – система автоматизированного проектирования), поддерживающих процесс разработки информационных систем, базирующихся на технологии баз данных. И во всех этих системах существуют средства описания инфологической модели (в рамках реальных САПР она часто имеет название концептуальной модели) разрабатываемой БД с возможностью автоматической генерации той даталогической модели, на которой будет реализовываться проект в дальнейшем.

Алгоритм перехода от ER-модели к реляционной модели данных обычно сводится к следующим шагам:

1. Каждой сущности ставится в соответствие отношение РМД. Имена отношений могут быть ограничены требованиями конкретной СУБД, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов.

2. Каждый атрибут сущности становится атрибутом соответствующего отношения, на их имена также могут накладываться некоторые ограничения (например, многие СУБД не поддерживают кириллицу). Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута. На рисунке 11.1, упрощенно, показан процесс преобразования, с учетом выбранной СУБД (в правой части отношения указаны типы данных принятые в СУБД MS Access для соответствующих полей).

Рисунок 11.1 – Преобразование сущности «Книги» к отношению с учетом выбранной реляционной БД.

3. Первичный ключ сущности становится первичным ключом соответствующего отношения (на рисунке 11.1 первичный ключ выделен подчеркиванием и курсивом). Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности и уникальности.

4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов первичного ключа главной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (атрибут ISBN таблицы «Экземпляры» рисунок 11.2).

Рисунок 11.2 – Реализация связи между отношениями «Книги» и «Экземпляры»

5. Для необязательных типов связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений. При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений.

Рисунок 11.3 – Реляционная схема БД «Библиотека»

6. При реализации связи многие-ко-многим, допустимой в инфологической модели, производится ее преобразование к связям один-ко-многим, например, через промежуточное отношение (рисунок 11.3 – отношение «Связь»). Промежуточное отношение будет иметь первичный ключ, состоящий из первичных ключей связываемых отношений.

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

На данном этапе выполняется описание внешних моделей в терминах РСУБД. Под внешними моделями подразумевается совокупность моделей данных для каждого приложения, использующего БД. Например, для БД «Библиотека» можно выделить три основных внешних модели: для приложения библиотекаря, администрации и читателя. Каждое из этих приложений будет решать свои прикладные задачи, используя для этого не всю БД, а лишь требуемую ее часть.

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