Разработка инфологической модели и создание структуры реляционной базы данных

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

Предметная область нашей будущей базы: деятельность автосалона. В базе должны храниться сведения о том, кто и когда приобрел автомобиль, кто занимался работой с клиентами, информация о поставках машин на склад. В таблицах 1 и 2 изображены примерные данные, которые должны отражаться в системе.

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

Свойства реляционной модели:

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя;

2. Строки таблицы отличаются друг от друга хотя бы одним значением, что позволит однозначно идентифицировать каждую из них;

3. Столбцы таблицы имеют уникальное имя, и в каждом из них размещаются однородные значения данных;

4. Порядок следования столбцов и строк не имеет значения;

5. На пересечении строки и столбца таблицы всегда имеется строго одно значение (или NULL- пустое значение);

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

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

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

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

Обозначим ключевые поля в таблицах.

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

Таблица 3. «Продажи». Ни одно из предложенных в ней полей не может рассматриваться в качестве простого ключа- все поля содержат повторяющиеся значения: покупатель может неоднократно совершить покупку; каждый консультант работает с несколькими клиентами; одну и ту же марку машин могут приобрести несколько покупателей; в один и тот же день может быть совершено несколько сделок. Выявим части составного ключа. Ими могут быть, например, поля «Дата продажи» и «ФИО покупателя»- зная два этих значения, мы узнаем и данные о покупателе, и сведения о машине, которую он приобрел, и кто из консультантов работал с данным клиентом (при допущении, что клиент приобретает не более одного авто в день) В таблице ключевые поля выделены двойной рамкой.

Таблица 4. «Поставки». В один день мы можем принять поставку от нескольких поставщиков; один поставщик неоднократно доставляет авто в салон, машины одной марки могут быть приняты от разных поставщиков – обойтись одним простым ключом не получится. Определим составной ключ. Его части составят поля «Дата поставки», «Название поставщика» и «Марка авто». Зная эти данные, однозначно определим значения и всех остальных полей одной из записей (сколько авто этой марки мы получили, по какой цене и пр.)

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

Что бы перейти от первой нормальной формы ко второй, необходимо:

1. Определить, какие из неключевых атрибутов зависят от всех частей составного ключа и оставить их в таблице;

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

Рассмотрим таблицу 3. От всех частей ключа (и от значения поля «ФИО покупателя», и от «Даты продажи») зависят поля «Марка авто», «Техн. характеристики», «Рис», «Цвет», «Цена», «ФИО консультанта», «Стаж работы», «Адрес консультанта», «Тел», «Дата рождения», «Дети». Эти поля оставляем в исходной таблице. Поля же «Адрес покупателя» и «Телефон покупателя» зависят только от одной части ключа – от поля «ФИО покупателя». Выносим их в отдельную таблицу «Покупатели». Соединяем обе таблицы линией связи (см. рис 1).

Рассмотрим таблицу 4. От всех частей ключа (от значения поля «Дата поставки», «Название поставщика» и «Марка авто») зависят только поля «Количество» и «Цена». Поля «Адрес поставщика» и «Телефон поставщика» зависят от части ключа «Название поставщика». Поля «Техн. характеристики авто» и «Рисунок» зависят от части «Марка авто». В итоге таблица разделится на 3 составляющие (см. рис 2). Назовем таблицы «Поставки», «Поставщики» и «Автомобили».

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

Функциональная зависимость атрибутов Х и Y называется транзитивной, если существует такой атрибут Z, что имеется функциональная зависимость X ->Z и Z->Y.

Что бы перейти от второй нормальной формы к третьей, необходимо:

1. Выявить поля, от которых зависят другие неключевые поля;

2. Создать новую таблицу для каждого такого поля и группы зависящих от него полей;

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

Рассмотрим рис 1. Поля «Техн. характеристика» и «Рисунок» зависят от ключа не на прямую, а через неключевой атрибут «Марка авто». Выносим эти поля в отдельную таблицу «Автомобили». Связываем разделившиеся части по полю «Марка авто». Поля «Стаж работы», «Адрес консультанта», «Тел», «Дата рождения», «Дети» зависят от неключевого поля «ФИО консультанта». Так же выносим их в отдельную таблицу «Консультанты». Получим набор таблиц с рис 3.

Рассмотрим рис 2. Здесь не наблюдается ни одной цепочки транзитивных зависимостей, поэтому вторая нормальная форма отношений является одновременно и третьей нормальной формой (рис 4)

Таблица 1. Продажи

Таблица 2. Поставки

Таблица 3. Продажи. 1НФ

Таблица 4. Поставки. 1НФ