Разработка СУБД "Японские автомобили"

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

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

     Модель  «сущность - связь» основана на использовании 3-х основных конструктивных элементах:

1. сущность
2. атрибут
3. связь

     Взаимосвязи между таблицами БД могут быть типизированы по следующим основным видам:

1. отношение “один к одному” (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;
2. отношение “один ко многим”  (1:М) возникает, когда одна запись взаимосвязана со многими другими;
3. отношение “многие к одному” означает, что многие записи связаны с одной (М:1);
4. отношение “многие ко многим” (M:N) возникает между двумя таблицами в тех случаях, когда:

• одна  запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

• одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

     Недостатком данной модели является то, что одни и те же элементы могут выступать одновременно и в качестве сущности, и в качестве атрибута, и в качестве связи. В данном случае, будем считать, что каждый объект может выступать только в качестве одного конструктивного элемента. Схема модели «сущность-связь» приведена на рис. 3.1

       
 

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

      
 
 
 
 
 

Таблица 3.1 «Классификация связей» 
 
 
 
 
 

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

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

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

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

     На  основе анализа функциональных зависимостей между атрибутами были получены результаты, описанные в таблицах 4.1.1. - 4.1.6.

  

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

        

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

        

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

     

Таблица 4.1.4. функциональные зависимости между атрибутами сущности «клиенты» 

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

     

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

2. Выбор ключей

     Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Одним из основных понятий баз данных, используемых при контроле целостности информации, является ключ. Разделяют первичные и внешние ключи. Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Ключ может быть составным (сложным), т.е. состоять из нескольких атрибутов. Внешние ключи - это поля таблицы, которые, как правило, соответствуют первичным ключам из других таблиц. Первичный ключ не может принимать неопределенные значения.

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

Таблица 4.1.6. «Ключи» 

     Опишем  ключи, составленные для имеющихся  сущностей:

1. Сущность «авто» имеет ключ «номер_двиг».
2. Сущность «клиенты» имеет ключ «код_кл»
3. Сущность «поставщики» имеет ключ «код_пост»
4. Сущность «журнал_реализ» имеет ключ «код_опер_р»
5. Сущность «журнал_постав» имеет ключ «код_опер_п»

 

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

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

     Реляционная база данных считается эффективной, если она обладает следующими характеристиками:

• Отсутствие избыточности
• Минимальное использование null – значений
• Предотвращение потери информации

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

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

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

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

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

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

1. Состав  таблиц БД

     Таблица 5.1.1 «авто»