Раздел 5. Проектирование логической структуры базы данных.

5.1. Этапы проектирования схем реляционных баз данных. (вопрос 43)

При проектировании схемы реляционной базы данных придерживаются следующей последовательности этапов:

1. определение перечня объектов (таблиц) и связей между этими объектами;

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

3. определение и установление индексов для полей в таблицах, с целью ускорения выполнения запросов;

4. разработка списков (словарей) для полей с перечислительным характером значений данных;

5. установление ограничений целостности по полям таблиц и связям;

6. нормализация таблиц, доработка перечня таблиц и их связей.

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

5.2. Проектирование и создание схем таблиц. (вопросы 44-49)

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

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

Традиционные СУБД поддерживают ограниченный набор простых типов полей (Таблица 5.1).

Современные СУБД оперируют и с более сложными типами полей, такими как массивы, «вложенные» таблицы и т.п.

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

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

Таблица 5.1. Наиболее часто встречающиеся типы полей.

Правильность определения ключа проверяется эмпирически по возможным ситуациям совпадения у различных строк - кортежей значений ключа.

Например, какое поле выбрать ключевым для таблицы «Студенты». Если в качестве ключевых выбрать поля Ф.И.О., то существует вероятность их совпадения. Если добавить год рождения, то эта вероятность уменьшится, но и только. Альтернативным вариантом может быть использование поля № паспорта. На практике распространенным приёмом является введение в качестве ключа аналога табельного номера, номер зачётной книжки – внутреннего номера экземпляра записи соответствующего объекта.

В некоторых СУБД для создания полей с уникальным идентификационными номерами записей введен дополнительный тип поля, называемый «счетчиком», полем типа «AUTOINC». В отличие от обычных числовых (или порядкового типа) полей, значения счётчика генерируются СУБД автоматически при образовании новой записи и только в возрастающем порядке, считая все ранее созданные, в том числе и удаленные записи.

5.2.1. ER - диаграммы с типом связи между таблицами «Один -к- одному». (вопрос 44)

Реляционная модель организации данных по признаку множественности обеспечивает лишь два типа связей отношений между таблицами «Один -ко- многим» и «Один -к- одному». Реляционная модель не может непосредственно отражать связи типа «Многие-ко-многим», что объективно снижает её возможности при отражении сложных предметных областей. Однако это не является непреодолимой проблемой.

Общие правила генерации таблиц из ER-диаграмм можно получить, опираясь на такие понятия как класс принадлежности сущности и степень отношения (связи).

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

Рассмотрим эти понятия на примере данных рис. 5.1.

Пример диаграммы ER-экземпляров.

Рис. 5.1. ER - диаграмма, соответствующая диаграмме ER - экземпляров.

На рис. 5.2 представлены возможные классы принадлежностей для степени связи 1:1, на рис. 5.3 – ER - диаграммы, соответствующие диаграммам ER - экземпляров рис. 5.2.

а) Степень связи 1:1.

(сущность Автор, сущность Книга).

Класс принадлежности обеих сущностей не является обязательным.

б) Степень связи 1:1.

Класс принадлежности сущности Автор является обязательным.

в) Степень связи 1:1.

Класс принадлежности сущности Книга является обязательным.

г) Степень связи 1:1.

Класс принадлежности является обязательным для обеих сущностей.

Рис. 5.2. Возможные классы принадлежностей для степени связи 1:1.

а) Не требуется участия в связи всех экземпляров обеих сущностей

б) Экземпляры сущности Автор обязательно должны участвовать в связи, а сущности Книга – не обязательно

в) Требуется участие в связи всех экземпляров сущности книга и неучастие некоторых экземпляров сущности Автор

г) Обязательное участие в связи всех экземпляров обеих сущностей

НА-номер автора, НК – номер книги – ключи сущностей ER – диаграммы.

Рис. 5.3. ER- диаграммы соответствующие диаграммам ER-экземпляров с рис. 5.2.

Единицы в обеих частях связей рис.5.3. свидетельствуют о степени связи 1:1. В диаграммах ER-типа под блоком сущности выписан ключ этой сущности: НА (номер автора) для сущности автор и НК (номер книги) для сущности книга. Многоточие означает другие атрибуты сущности не входящие в ключи.