Нормализация полученных отношений. НФ. Для приведения таблиц к 1НФ требуется составить прямоугольные таблицы (один атрибут – один столбец) и разбить сложные атрибуты на простые, а многозначные атрибуты вынести в отдельные отношения.
Примечание.
В реальных БД сложные атрибуты разбиваются на простые, если: а) этого требует внешнее представление данных; б) в запросах поиск может осуществляться по отдельной части атрибута.
Разделим атрибут ФИО на два атрибута Фамилия и Имя, отчество.
Многозадачный атрибут Телефоны клиентов следует выделить в отдельное отношение ТЕЛЕФОНЫ. 2НФ. В нашем случае составные первичные ключи имеют отношение ВЗЯТЬ НА ПРОКАТ и ОЧЕРЕДЬ. Неключевые атрибуты этих отношений функционально полно зависят от первичных ключей. 3НФ. В отношении ВЗЯТЬ НА ПРОКАТ атрибут Скидка зависит от атрибутов Дата выдачи прав, Стоимость ущерба про предыдущим выдачам и от количества выдач, а не от первичного ключа, поэтому Скидку следует вынести в отдельное отношение. Но если мы выделим в отдельное отношение, то получившиеся связи будут иметь тип 1:1. Следовательно, декомпозиция нецелесообразна.
В отношении АВТОМОБИЛИ атрибуты Марка и Вместимость зависят от атрибута Модель, а не от первичного ключа, поэтому выносим в отдельную таблицу.
Содержание поля Имя поля Тип, длина Примечания Модель A_model C(30) первичный ключ Марка A_brand C(20) обязательное поле Вместимость A_capacity N(1) обязательное поле 4НФ. Отношения данного примера не нарушают 4НФ, т.к. не содержат нетривиальных многозначных зависимостей.
В реальных базах данных после нормализации может проводиться денормализация.
Она проводится с одной целью – повышение производительности БД. Запрос на получение списка телефонов клиентов потребует в нормализованной БД соединения отношений.
Пользователю безразлична форма представления этого списка: номера телефонов через запятую или в столбец. Поэтому мы откажемся от создания отдельных отношений с номерами телефонов, и вернёмся к варианту с многозначными полями. После проведённых преобразований схема БД выглядит так: Окончательные схемы отношений базы данных с указанием ключей и других ограничений целостности приведены в таблицах: Таблица 5.Схема отношения АВТОМОБИЛИ(auto) Содержание поля Имя поля Тип, длина Примечания Идентификатор автомобиля A_id N(4) суррогатный первичный ключ Модель A_model C(30) внешний ключ (к models) Цвет A_color C(20) обязательное поле Год выпуска A_year C(4) обязательное поле Пробег A_mileage N(8) обязательное поле Стоимость проката A_price N(4) обязательное поле Таблица 6.Схема отношения КЛИЕНТЫ(clients) Содержание поля Имя поля Тип, длина Примечания Идентификатор клиента C_id N(4) суррогатный первичный ключ Фамилия C_fname C(20) обязательное поле Имя, отчество C_lname C(30) обязательное поле Адрес C_address C(50) Номер телефона C_phone C(30) многозначное поле Дата выдачи прав C_experience D Обязательное поле Таблица 7.Схема отношения ВЗЯТЬ НА ПРОКАТ(rent) Содержание поля Имя поля Тип, длина Примечания Идентификатор автомобиля A_id N(4) внешний ключ (к auto); составной первичный ключ Идентификатор клиента C_id N(4) внешний ключ (к clients); составной первичный ключ Дата выдачи R_date D составной первичный ключ Срок выдачи R_term N(3) обязательное поле Стоимость R_price N(6,2) обязательное поле; стоимость с учетом всех скидок Дата возвращения R_rdate D дата фактического возвращения автомобиля клиентом Состояние автомобиля A_state C(200) состояние автомобиля после возвращения Возмещение ущерба R_crash N(8) стоимость поломки Скидка R_skidk N(2) вычисляемое поле; скидка в процентах Таблица 8.Схема отношения ОЧЕРЕДЬ(turn) Содержание поля Имя поля Тип, длина Примечания Идентификатор автомобиля A_id N(4) внешний ключ (к auto); составной первичный ключ Идентификатор клиента C_id N(4) внешний ключ (к clients); составной первичный ключ Дата постановки в очередь T_date D составной первичный ключ Таблица 9.Схема отношения МОДЕЛИ(models) Содержание поля Имя поля Тип, длина Примечания Модель A_model C(30) первичный ключ Марка A_brand C(20) обязательное поле Вместимость A_capacity N(1) обязательное поле