Логическое проектирование базы данных

При проектуванні логічної структури реляційної бази даних визначається оптимальний склад таблиць для зберігання вихідної інформації. Для кожної таблиці вказується її назва, перелік полів і первинний ключ. Ідентифікуються зв'язку між таблицями. В рамках логічного проектування БД можуть формулюватися обмеження цілісності, прийматимуться рішення про створення індексів і т. д.

Найбільш часто для вирішення перерахованих завдань використовується перехід до логічної моделі бази даних від концептуальної моделі, представленої у вигляді ER-діаграми [3, 4]. Існують методи однозначного перетворення ER-моделі в логічну модель реляційної бази даних. Ці методи покладені в основу роботи багатьох CASE-систем - інструментальних засобів автоматизованого проектування баз даних (див. п. 7.5).

Розглянемо основні правила перетворення ER-моделі в логічну модель бази даних на прикладі діаграми, побудованої на рис. 15 (для ілюстрації деяких правил будуть залучатися додаткові сутності і зв'язки між ними). Для наочності отриманих результатів заповнимо таблиці даними.

Для суті, має лише прості атрибути (наприклад, Магазин), може бути створені одна таблиця. Кожен атрибут сутності стає полем таблиці, ключові атрибути сутності - первинним ключем таблиці. Для кожного поля визначається допустимий тип даних та інші обмеження цілісності. Назви сутності і таблиці, атрибутів і полів можуть збігатися, якщо використовувана СУБД не накладає на них жодних обмежень (табл. 7.1):Таблица 7.1 Магазины

Название	Адрес	Специализация
Светлый	Мира, 14	Хозяйственные товары
Восток	Запарина, 2	Продовольственные товары
Факел	Фрунзе, 13	Хозяйственные товары

Якщо між двома сутностями є зв'язок «один до одного», а клас приналежності зв'язку для обох сутностей є обов'язковим, обидві сутності можна об'єднати в одну таблицю. Первинним ключем таблиці може бути первинний ключ будь сутності. Наприклад, є пов'язані суті Директор і Магазин. В кожному магазині є директор, і кожен директор керує тільки одним магазином. Таблиця, що включає атрибути сутностей Директор і Магазин, може виглядати наступним чином (табл. 7.2):

Таблица 7.2 Магазины

Название	Адрес	Специализация	Директор	ИНН
Светлый	Мира, 14	Хозяйственные товары	Деев О.И.	27213456
Восток	Запарина, 2	Промышленные товары	Стогов П.И.	27243212
Факел	Фрунзе, 13	Хозяйственные товары	Репина О.Г.	27231217

Коли між сутностями є зв'язок «один до одного», а клас приналежності зв'язку для однієї сутності є обов'язковим, а для іншої необов'язковим, для кожної сутності формується окрема таблиця. До таблиці, сутність якої має обов'язковий клас приналежності, додається в якості поля ключ таблиці з необов'язковим класом приналежності.

Розглянемо зв'язок між сутностями Магазин й Автомобіль. Припустимо, лише деяким магазинам («Світлий», «Схід») належить автомобіль (тільки один). У інших магазинів («Факел») автомобіля немає (клас приналежності зв'язку для сутності Магазин є необов'язковим). Кожен автомобіль є власністю деякого магазину (клас приналежності зв'язку для сутності Автомобіль є обов'язковим). Таблиця з інформацією про магазинах буде ідентична табл. 7.1, а таблиця з інформацією про автомобілі буде мати наступний вигляд (табл. 7.3):

Таблица 7.3 Автомобили

Номер	Марка	Водитель	Адрес магазина
Х 123 МН	ЗИЛ-130	Андреев Р.С.	Мира, 14
Х 234 РТ	ГАЗ-66	Реутов С.П.	Запарина, 2

При зв'язки між сутностями «один до багатьох» в процесі формування таблиць вирішальну роль грає клас приналежності сутності, яка знаходиться з боку «багато». Якщо він не є обов'язковим, слід створити три таблиці. Дві з них будуть відповідати кожної сутності, ключі сутностей стануть первинними ключами цих таблиць. Третя таблиця буде сполучною, в неї повинні входити первинні ключі пов'язуються таблиць.

У ситуації, коли клас приналежності сутності, яка знаходиться з боку «багато», обов'язковий, достатньо створити дві таблиці. Ключ таблиці, що знаходиться з боку «один», повинен бути доданий в таблицю, що знаходиться з боку «багато».

Розглянемо зв'язок «один до багатьох» між сутностями Магазин й Працівник (див. рис. 15). Клас приналежності зв'язку для сутності Працівник є обов'язковим. Таблиця з інформацією про магазинах буде мати вигляд, ідентичний табл. 7.1, таблиця з інформацією про працівників буде включати ключ таблиці Магазин (табл. 7.4):

Таблица 7.4 Работники

ИНН	ФИО	Должность	Адрес	Адрес магазина
27212367	Фомин Л.М.	продавец	Боровая, 16	Мира, 14
27233319	Цыпин Л.Е.	продавец	Мира, 33	Запарина, 2
27254322	Гейт Ф.П.	грузчик	Осиновая, 5	Фрунзе, 13
27265413	Ревва С.Р.	кассир	Мира, 67	Мира, 14

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

Рассмотрим связь «многие ко многим» между сущностями Продавец и Товар. Таблица Продавцы может иметь структуру, совпадающую со структурой таблицы Работники (см. табл. 7.4), таблица Товары будет иметь вид (табл. 7.5):

Таблица 7.5 Товары

Артикул	Название	Цена, руб.
100	Туфли	5 000
200	Сапоги	7 000
300	Костюм	10 000
400	Костюм	8 000

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

Таблица 7.6 Продажи

ИНН	Артикул
27212367	100
27212367	300
27233319	100
27233319	400

Рассмотренные правила преобразования ER-модели в логическую модель базы данных достаточно просты, наглядны и позволяют получить хорошие результаты. Более подробные сведения о данном процессе приводятся в книге [ 3 ].

Нормализация отношений

Нормализация отношений* обеспечивает эффективность структур данных в реляционной БД [ 12 ].

Этот процесс уменьшает избыточность данных (хранение одинаковых данных в нескольких местах). В результате более рационально используется внешняя память, уменьшается вероятность нарушения согласованности данных.

Нормализация представляет собой действия по последовательному преобразованию исходной (ненормализованной) таблицы в нормализованные отношения в первой нормальной форме (1НФ), 2НФ, 3НФ, нормальной форме Бойса-Кодда (НФБК), 4НФ, 5НФ [ 2 ].

Основные свойства нормальных форм:

1. каждая следующая нормальная форма улучшает свойства предыдущей нормальной формы;

2. при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

Первая нормальная форма (1НФ)

Рассмотрим таблицу, в которой содержится информация о поставках товаров торговому предприятию (табл. 7.7):

Таблица 7.7 Товары

Название товара	Артикул	Количество	Цена, руб.	Дата поставки	Поставщик	Способ доставки
Костюм	500	100	10 000	10.12.05	Янтарь	а/т
Сапоги	200	75	5 000		Факел	ж/д
Туфли	100	120	4 000	11.12.05	Янтарь	а/т
Костюм	500	100	10 000
	300	50	5 000	12.12.05
	400		4 000		Остон	ж/д
Туфли	100	100			Янтарь	а/т

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

Приведем исходную таблицу к виду (табл. 7.8):

Таблица 7.8 Товары

Название товара	Артикул	Количество	Цена, руб.	Дата поставки	Поставщик	Способ доставки
Костюм	500	100	10 000	10.12.05	Янтарь	а/т
Сапоги	200	75	5 000	10.12.05	Факел	ж/д
Туфли	100	120	4 000	11.12.05	Янтарь	а/т
Костюм	500	100	10 000	11.12.05	Янтарь	а/т
Костюм	300	50	5 000	12.12.05	Янтарь	а/т
Костюм	400	50	4 000	12.12.05	Остон	ж/д
Туфли	100	100	4 000	12.12.05	Янтарь	а/т

В результате будет получено отношение в первой нормальной форме.

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