- •Содержание
- •1 Анализ предметной области
- •Функциональная структура
- •1.2 Диаграмма потоков данных
- •1.3 Выделение информационных объектов и их атрибутов
- •2 Концептуальная модель
- •3 Логическое моделирование
- •3.1 Построение логической модели
- •3.2. Нормализация отношений.
- •3.3 Целостность данных
- •3.3.1 Целостность объекта
- •3.3.2 Целостность приложения
- •3.3.3 Ссылочная целостность
- •4 Выбор субд
- •5. Физическая модель
- •6 Проектирование и реализация информационной системы
- •6.1 Описание средств, использованных при реализации
- •6.2 Тексты sql-запросов и результаты их выполнения
- •Многотабличные запросы
- •Подзапросы (запрос внутри запроса)
- •Exists и not exists (существует и не существует)
- •Встроенные функции
- •Group by и having
- •Встроенные функции и подзапросы
- •7 Заключение
- •8 Список литературы
- •9. Приложение a. Макетные данные.
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 Концептуальная модель после нормализации