Типы моделей данных

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются способами представления взаимосвязей между объектами.

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

Иерархическая структура реализует отображение “один ко многим” между исходными и порожденными типами записей.

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

Для представления отображения “многие ко многим” требуется дублирование деревьев, если не известен наиболее часто используемый тип записи.

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

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

Реляционная модель. В реляционной модели объекты и их взаимосвязи представляются с помощью таблиц. Взаимосвязи также рассматриваются в качестве объектов. Например, в наше задачи объект ЗАКАЗ на самом деле представляет связь между объектами ФИРМА, ТОВАР, КЛИЕНТ. В реляционной модели каждая таблица должна иметь первичный ключ (ключевой элемент) - поле или комбинацию полей, которые единственным образом идентифицируют каждую запись в таблице. Благодаря своей простоте модель получила наибольшее распространение в СУБД для ПЭВМ.

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

Нормализация (декомпозиция) реляционной модели

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

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

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

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

Пример.

КЛИЕНТ (Код_Кл, Наим_Кл, ЗАКАЗ)

ЗАКАЗ (Код_Т,Наим_Т, Цена_Т, Гарантия, Кол_Т, Код_Ф, Наим_Ф )

Пусть имеются следующие данные о покупках клиента

Код_КЛ	Наим_КЛ	Заказ
1	Клиент_1	100	Товар_1	1000	1	5	10	Фирма_1
		200	Товар_2	2000	1,5	6	20	Фирма_2
2	Клиент_2	100	Товар_1	1000	1	8	10	Фирма_1
		300	Товар_3	3000	2	9	20	Фирма_2

Для преобразования этой ненормализованной таблицы в 1НФ необходимо в составном отношении КЛИЕНТ заменить составной атрибут ЗАКАЗ соответствующими простыми атрибутами

Код_Кл	Наим_Кл	Код_Т	Наим_Т	Цена	Гар	Кол	Код_Ф	Наим_Ф
1	Клиент_1	100	Товар_1	1000	1	5	10	Фирма_1
1	Клиент_1	200	Товар_2	2000	1,5	6	20	Фирма_2
2	Клиент_2	100	Товар_1	1000	1	8	10	Фирма_1
2	Клиент_2	300	Товар_3	3000	2	9	20	Фирма_2

Итак первый этап нормализации заключается в образовании двумерной таблицы, содержащей все необходимые атрибуты информационной модели, и в выделении ключевых атрибутов. Ключевым атрибутом этого отношения будет множество атрибутов А={Код_Кл, Код_Т, Код_Ф}. Очевидно, что полученная весьма внушительная таблица будет содержать очень разнородную информацию. В этом случае будут наблюдаться различные аномалии.

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

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

Аномалия удаления. При банкротстве некоторой фирмы удаляются данные, которые не имеют к этому никакого отношения, например, сведения о товарах, клиентах и т.д.

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

Неполная зависимость означает следующее: Пусть А={А1, …, Аn} - набор атрибутов, являющийся ключом некоторой таблицы, и B - неключевой атрибут этой же таблицы. Если найдется некоторое подмножество атрибутов, множества А, от которого зависит атрибут В, то говорят, что В зависит от ключа А неполно.

Для указанной таблицы наблюдаются такие неполные функциональные зависимости:

А={Код_Кл, Код_Т, Код_Ф};

1. А Наим_Т; Код_Т Наим_Т.

2. А Наим_Кл; Код_Кл Наим_Кл.

3. А Наим_Ф; Код_Ф Наим_Ф.

4. А Цена; {Код_Ф, Код_Т} Цена.

5. А Гар; {Код_Ф, Код_Т} Гар.

6. А Кол.

Полная зависимость наблюдается только для неключевого атрибута Кол.

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

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

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

КЛИЕНТ			ТОВАР			ФИРМА
Код_Кл	Наим_Кл		Код_Т	Наим_Т		Код_Ф	Наим_Ф
1	Клиент_1		100	Товар_1		10	Фирма_1
2	Клиент_2		200	Товар_2		20	Фирма_2
			300	Товар_3

ЗАКАЗ
Код_Кл	Код_Т	Код_Ф	Кол
1	100	10	5
1	200	20	6
2	100	10	8
2	300	20	9

СТОИМОСТЬ
Код_Т	Код_Ф	Цена	Гар
100	10	1000	1
200	20	2000	1,5
100	10	1000	1
300	20	3000	2

Следующий этап нормализации устраняет транзитивные зависимости неключевых атрибутов таблицы.

Если A, B, C - три атрибута некоторой таблицы и АВ, ВС (причем В не ключевой), то А С. Говорят, что С транзитивно зависит от А.

Заметим, что в последней таблице, если предположить, что гарантия зависит от цены товара, то будет наблюдаться транзитивная зависимость атрибута Гар от ключа {Код_Т, Код_Ф}.

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

Исключая транзитивную зависимость неключевого атрибута Гар., последняя таблица разбивается на две

СТОИМОСТЬ
Код_Т	Код_Ф	Цена
100	10	1000
200	20	2000
100	10	1000
300	20	3000

ГАРАНТИЯ
Цена	Гар
1000	1
2000	1,5
3000	2

В результате трех этапов нормализации мы пришли к следующей логической реляционной модели данных. Эта модель содержит такие объекты: ТОВАР(Код_Т, Наим_Т), ФИРМА(Код_Ф, Наим_Ф), КЛИЕНТ(Код_Кл, Наим_Кл ), ЗАКАЗ(Код_Т, Код_Ф, Код_Кл, Кол), СТОИМОСТЬ(Код_Т, Код_Ф, Цена) ГАРАНТИЯ(Цена, Гарантия). Ключевой атрибут таблиц выделен.

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

Основные правила при проектировании реляционной БД

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

• Если атрибут зависит только от части составного ключа, его следует перенести в отдельную таблицу.

• Если атрибут не зависит от ключа, этот атрибут следует перенести в отдельную таблицу.

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