3.2. Нормализация отношений.
Из построенных концептуальной и логической моделей отчётливо видны некоторые недостатки. Для удаления этих недостатков, необходимо выполнить нормализацию отношений:
Во многих отношениях ключевые поля не уникальны. Кроме того, они имеют достаточно большую длину. Например, поле «FIO» отношения «Klient», поле «Names» отношения «Hotels», поле «Names» отношения «TransportationCompany». Т.к. на эти поля ссылаются другие отношения (внешние ключи), то они будут повторяться в других отношениях. Таким образом, помимо неуникальности этих полей, использование их как первичных ключей непрактично ещё и потому, что это ведёт к избыточности данных и неэкономному использованию памяти. Для того, чтобы избавиться от этих недостатков, в каждом отношении, где это требуется, введём дополнительное числовое поле – уникальный идентификатор каждой записи. Теперь вместо длинных полей типа «Names» отношения
Рисунок 3.1 Логическая модель до нормализации
будут ссылаться друг на друга через эти идентификационные поля. Например, в таблице «Klient» теперь вместо «FIO» ключевым теперь будет поле «idKlient», и теперь отношение «DistributionPass» ,будет ссылаться не на «FIO»,а на «idKlient». Кроме того, для удобства и наглядности, ссылающиеся поля (внешние ключи) переназовём также как и первичные ключи. Для только что рассмотренного примера теперь поле «Klient» отношения «DistributionPass» будет называться также как и поле, на которое оно ссылается, т.е. «idKlient».
В отношении «Resorts» поле «Countries» может повторяться несколько раз, как и поле «Currency». Это объясняется тем, что может быть несколько курортов (населённых пунктов) в одной стране. Это приведёт к избыточности данных. Для решения проблемы, выделим страны в отдельную сущность «Countries», в ней будет 3 поля: «idCountries», «Names» - название страны, «idCurrency» - ссылка на отношение «Currency». Теперь в отношении «Resorts» повторяемости не будет, а соответственно и не будет избыточности данных.
Основные недостатки в базе данных ликвидированы и там, где это требовалось, она была приведена к 1-й нормальной форме.
Чтобы построить полноценную логическую модель, необходимо в каждом отношении выделить ключевые атрибуты (что, собственно уже сделано), т.е. привести отношения ко 2-й нормальной форме. Соответствующие изменения в базе данных были уже сделаны.
Выделим в каждом отношении ключевые атрибуты (первичные ключи):
В отношении «Currency» - поле «idCurrency»;
В отношении «Countries» - поле «idCountries»;
В отношении «Resorts» - поле «idResorts»;
В отношении «Hotels» - поле «idHotels»;
В отношении «WorkerPersonner» - поле «idWorkerPersonner»;
В отношении «Pass» - поле «idPass»;
В отношении «Klient» - поле «idKlient»;
В отношении «TransportationCompany» - поле «id TransportationCompany »;
В отношении «DistributionPass» - полe «idDistributionPass».
Таким образом, ключевые элементы выделены, т.е. все отношения нормализованы и приведены ко 2-й нормальной форме. Приведение к 3-й нормальной форме, т.е. исключение транзитивных зависимостей между атрибутами в данном случае не требуется.
Далее построим уже нормализованную логическую модель. Она изображена на (рис.3.2). Здесь база данных выглядит так, как она будет реализована далее физически в СУБД. Поля со «*» - ключевые.
После нормализации, концептуальная модель изменится довольно существенно. Концептуальная модель после нормализации приведена на (рис.3.3).
Рисунок 3.2 Логическая модель после нормализации
Рисунок
3.3 Концептуальная модель после нормализации