
- •Содержание
- •Введение
- •1 Анализ предметной области
- •2 Концептуальное проектирование
- •2.1 Перечень сущностей
- •2.2 Перечень атрибутов
- •3 Инфологическое проектирование
- •3.1 Модель «сущность-связь»
- •3.2 Классификация связей
- •4 Реляционная модель бд
- •4.1 Функциональные зависимости между атрибутами
- •4.2 Выбор ключей
- •4.3 Нормализация отношений
- •5 Даталогическое проектирование
- •5.1 Состав таблиц базы данных
- •6 Физическое проектирование
- •6.1 Создание проекта
- •6.2 Создание базы данных
- •6.3 Создание таблиц
- •6.4 Создание запросов к базе данных
- •6.5 Создание отчетов
- •Заключение
- •Список используемой литературы
- •Приложение а
- •Приложение б
- •Приложение в
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 – Функциональные зависимости между атрибутами сущности «Груз»
-
Наименование атрибута
Функциональные зависимости
Shifr_gr;
Name_gr;
Kol_vo;
stoimost;
Таблица 3 – Функциональные зависимости между атрибутами сущности «Грузоотправители»
-
Наименование атрибута
Функциональные зависимости
Shifr_otprav;
Name_otprav;
address;
schet_otprav;
Таблица 4 – Функциональные зависимости между атрибутами сущности «Грузополучатели»
-
Наименование атрибута
Функциональные зависимости
Shifr_pol;
Name_pol;
address;
schet_pol;
Таблица 5 – Функциональные зависимости между атрибутами сущности «Квитанции»
-
Наименование атрибута
Функциональные зависимости
Nom_kvit;
Gruz_sh;
transport;
data_pogr;
data_razgr;
otprav_sh;
pol_sh;
status;