Проектирование базы данных

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

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

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

Процесс проектирования – есть процесс преобразования форм, т.е. процесс приведения произвольного отношения к эквивалентной совокупности отношений в четвертой нормальной форме (4НФ). Процесс проектирования можно разбить на несколько шагов.

1-й шаг.Произвольное отношение приводится к первой нормальной форме (1НФ).

2-й шаг. Отношение, находящееся в 1НФ, приводится к эквивалентной совокупности отношений, находящихся во второй нормальной форме (2НФ).

3-й шаг. Отношение, находящееся в 2НФ, приводится к эквивалентной совокупности отношений, находящихся в третьей нормальной форме (3НФ).

На практике процесс нормализации, как правило, на этом этапе заканчивается.

Введем ряд определений.

Определение 1. Отношение находится в 1НФ тогда и только тогда, когда все входящие в него элементы содержат только атомарные (неделимые) значения.

Это определение просто устанавливает, что любое нормализованное отношение находится в 1НФ.

Первостепенно важным понятием является понятие функциональной зависимости(внутри отношения).

Определение 2. Если задано отношение R, то атрибут Y отношения R функционально зависитот атрибута X отношения R тогда и только тогда, когда каждое значение X в R в каждый момент времени связано точно с одним значением Y.

Например, в отношении Товары нашей реляционной модели данных «Продажи» каждый из атрибутов Наименование, Марка, Цена функционально зависит от атрибута КодТовара. То есть для определенного значения КодТовара существует в точности одно соответствующее значение каждого из атрибутов Наименование, Марка, Цена.

Можно представить функциональную зависимость с помощью диаграммы:

В случае составного ключа вводится понятие функционально полной зависимости.

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

Атрибут Количество находится в полной функциональной зависимостиот составного ключа КодТовара и НомерСклада. Атрибуты Наименование, Марка, Цена не находятся в полной функциональной зависимостиот составного ключа КодТовара и НомерСклада, так как эти атрибуты функционально зависят от части составного ключа, а именно от атрибута КодТовара.

В таком случае при проектировании данное отношение разбивают на два:

Определение 4. Атрибут Y находится в транзитивной зависимостиот атрибута Х, если он находится в функциональной зависимости от атрибута Z, а атрибут Z – в функциональной зависимости от атрибута X.

Атрибут АдресФирмы находится в транзитивной зависимости от атрибута НомерСклада.

В таком случае при проектировании данное отношение разбивают на два:

Определение 5. Отношение R находится во 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от первичного ключа.

Определение 6. Отношение R находится в 3НФ, если оно находится во 2НФ и при этом любой неключевой атрибут зависит от ключа нетранзитивно.

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

4НФ заключает в себя очень простую и общедоступную идею. Понятие 4НФ можно на интуитивном уровне сформулировать так: «один факт хранится один раз».

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

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

Уточним шаги нормализации.

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

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

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

Процессу приведения отношения произвольной формы к 4НФ предшествует большая предварительная работа по созданию этого первичного или произвольного отношения. Это не менее важный момент в проектировании базы данных.

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

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

Поиск по сайту: