2.2 Перечень атрибутов

       Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности.

       Атрибуты  сущности Груз:

       - шифр_груза;

       - наименование_груза;

       - количество;

       - стоимость.

       Атрибуты  сущности Грузоотправители:

       - шифр_грузоотправителя;

       - имя_грузоотправителя;

       - адрес;

       - рассчетный_счет.

       Атрибуты  сущности Грузополучатели:

       - шифр_грузополучателя;

       - имя_грузополучателя;

       - адрес;

       - рассчетный_счет.

       Атрибуты  сущности Квитанции

       - номер_квитанции,

       Атрибуты  сущности Квитанции:

       - шифр_груза;

       - транспорт;

       - дата_погрузки;

       - дата_разгрузки;

       - шифр_оправителя;

       - шифр_получателя;

       - статус. 

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

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

       Выходная информация:

На печать:

1. ведомость законченных перевозок за период;
2. ведомость о должниках.

        На экран:

1. информация о перевозках от данного грузоотправителя;
2. информация о перевозках к данному грузополучателю;
3. информация о незаконченных перевозках за период;
4. информация о законченных перевозках за период.

       Выходная  информация предоставлена для составления запросов и отчетов к разработанной базе данных.

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

       Этот  метод является классическим методом  проектирования реляционной базы данных. Он основан на понятии зависимости  между атрибутами отношений.

 

       3  Инфологическое проектирование

 

       Инфологическая  модель применяется на втором этапе  проектирования БД, то есть после словесного описания предметной области.

       Инфологическое  проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области. Ранние теоретико-графовые модели в большей степени отображали семантику предметной области. Они в явном виде определяли иерархические связи между объектами предметной области.

       3.1 Модель «сущность-связь»

       Проблема  представления семантики давно  интересовала разработчиков, и в  семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность—связь", или "Entity Relationship" (ER-модель), стала фактическим стандартом при инфологическом моделировании баз данных.

       В основе ER-модели лежат следующие  базовые понятия:

       Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности.

       Объект, которому соответствует понятие  сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.

       Между сущностями могут быть установлены  связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.[3]

 

        3.2 Классификация связей

       Связи делятся на три типа по множественности:

1. Один-к-одному (1:1).

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

2. Один-ко-многим (1:М).

       Связывает одну строку какой-либо таблицы с  двумя или несколькими строками другой. Связь устанавливается между первичным ключом основной таблицы и соответственным внешним ключом связной или подчиненной таблицы. Такие связи наиболее распространены между таблицами реляционной БД.

3. Многие-ко-многим (М:М).

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

 

       4 Реляционная модель  БД

 

       Реляционной называется база данных, в которой  все данные, доступные пользователю, организованны в виде таблиц, а  все операции над данными сводятся к операциям над этими таблицами.

       Рассмотрим  правила преобразования ER-модели в реляционную.

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

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

       Первичный ключ сущности становится PRIMARY KEY соответствующего отношения.

       В каждое отношение, соответствующее  подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).

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

       При втором способе для каждого подтипа  и для супертипа создаются  свои отдельные отношения. Недостатком  такого способа представления является то, что создается много отношений, однако достоинств у такого способа больше, так как вы работаете только со значимыми атрибутами подтипа. Кроме того, для возможности переходов к подтипам от супертипа необходимо в супертип включить идентификатор связи.[6]

       4.1 Функциональные зависимости между атрибутами

       Функциональные  зависимости определяют не текущее состояние БД, а все возможные ее состояния, то есть они отражают те связи между атрибутами, которые присущи реальному объекту, моделируемые в БД.

       Атрибут Y некоторого отношения функционально  зависит от X (атрибуты могут быть составными), если в любой момент времени каждому значению X соответствует одно значение Y. Функциональная зависимость обозначается X →Y.

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

       Полная  функциональная зависимость. Неключевой атрибут функционально полно зависит от составного ключа если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов.

       Транзитивная  функциональная зависимость. Пусть X, Y, Z - три атрибута некоторого отношения. При этом X → Y и Y → Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.

       Многозначная зависимость. Пусть X. Y, Z - три атрибута отношения R. В отношении R существует многозначная зависимость R.X -» R.Y только в том случае, если множество значений Y. соответствующее паре значений X и Z. зависит только от X и не зависит от Z.[2] 

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

 

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