Таблица 4 – Функциональные зависимости между атрибутами сущности «Грузополучатели»

 

       Таблица 5 – Функциональные зависимости между атрибутами сущности «Квитанции»

       4.2 Выбор ключей

       Ключами или ключевыми являются атрибуты, значения которых определяют значения других атрибутов. Значения ключевых атрибутов не зависят от значений никаких других атрибутов. Ключ может состоять из единственного атрибута или быть составлен из нескольких атрибутов. Эти атрибуты могут быть первичными ключами, составными первичными ключами и внешними ключами.

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

Значение гарантирует уникальность для каждого из экземпляров

1. Значение не имеет скрытого смысла;
2. Область определения значений будет оставаться постоянной с течением времени;
3. Значения существуют для каждого из экземпляров сущности.

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

       Для сущностей данной ИС были выбраны  следующие ключевые атрибуты: 
 
 

       Таблица 6 – Ключи сущностей

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

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

       Нормализация  – это формализованная процедура, в процессе выполнения которой  атрибуты данных (поля) группируются в таблицы, а таблицы в БД.

       Цель:

       -  исключить дублирования данных;

       - обеспечить целостность данных, таким образом, чтобы при изменении  одних объектов. Автоматически происходило  соответственные изменения связных с ним объектов.

       Первая  нормальная форма (1НФ). Для нее требуется, чтобы таблица была плоской и не содержала повторяющихся групп. У плоской таблицы есть только две характеристики - длина (количество записей или строк) и ширина (количество полей или столбцов). Такая таблица не должна содержать ячеек, включающих несколько значений.

       Никакую из систем управления базами данных не удовлетворяет только 1НФ, так как в этом случае необходимо определить большое число полей, многие из которых остаются в основном пустыми. Избыточные данные могут послужить причиной проблем целостности и снижение эффективности при внесении изменений, поэтому подобных решений при проектировании баз данных необходимо избегать.

       Вторая  нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен.

       В каждой таблице БД может существовать первичный ключ - поле или набор  полей, однозначно идентифицирующий запись.

       Значение  первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух и более записей с одинаковым значением первичного ключа.

       Те  поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц. 2НФ позволяет удалить большую часть повторяющихся данных, которые часто остаются после первого этапа нормализации.

       Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

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

       Если  в отношении имеется много  функциональных зависимостей, 4НФ не устраняет избыточность, то применяют пятую нормальную форму (5НФ).

       Разложение  отношений из 4НФ в 5НФ должно быть выполнено так, чтобы каждая проекция, полученная из 4НФ, содержала не менее одного возможного ключа и хотя бы один неключевой атрибут из исходного отношения. Для 5НФ требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита. Кроме того, необходимо, чтобы таблицы соответствовали ЗНФ, а при наличии отношений "многие-ко-многим" - 4НФ.

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

       На  следующей ER-диаграмме (рисунок 2) отображены связи и отношения между основными элементами выбранной предметной области компании X[3]

 

       Рисунок 2- ER-диаграмма 

       Проанализировав разработанную базу данных, можно  сделать вывод, что она нормализована  и соответствует третей нормальной форме, так как:

1. Все таблицы в базе данных соответствуют первой нормальной форме т.к. все атрибуты простые (атомарные);
2. Все таблицы находятся во второй нормальной форме, так как они находятся в первой нормальной форме и удовлетворяют дополнительному условию. Таблицы не имеют составного первичного ключа, поэтому они однозначно определены во второй нормальной форме;
3. Все таблицы находятся в третьей нормальной форме, так как они находятся во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа, что видно из выявленных функциональных зависимостей.

 

       5 Даталогическое проектирование

 

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

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

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

       Для реляционной базы данных проектирование логической структуры заключается в том, чтобы разбить всю информацию по файлам (отношениям), а также определить состав полей (атрибутов) для каждого из этих файлов. Поля могут в себе содержать различные типы информации: целый, вещественный, символьный, дата\время, поле мемо, числовой, логический и тому подобные.  В зависимости от выбранной СУБД их названия могут отличаться.[3]

       5.1 Состав таблиц  базы данных

       В этом разделе приводится состав таблиц базы данных «Грузоперевозки». Для каждого поля таблицы указан тип и описание, в котором указываются особенности использования.  

       Таблица 7 – Состав таблицы «Груз»

       Таблица 8 – Состав таблицы «Грузоотправители»