Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Базы данных
Посмотреть оригинал

Проектирование реляционных баз данных с использованием нормализации

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

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

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

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

  • • первая нормальная форма 1NF;
  • • вторая нормальная форма 2NF,
  • • третья нормальная форма 3NF;
  • • нормальная форма Бойса — Кодда BCNF;
  • • четвертая нормальная форма 4NF,
  • • пятая нормальная форма 5NF или нормальная форма проекции- соединения PJ/NF.

INF, 2NF, 3NF ограничивают зависимость непервичных атрибутов от ключей, BCNF ограничивает зависимость первичных атрибутов, 4NF формулирует ограничения на виды многозначных зависимостей, 5NFвводит другие типы зависимостей — зависимости соединения.

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

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

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

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

  • • в отношении нет одинаковых кортежей;
  • • кортежи не упорядочены;
  • • атрибуты не упорядочены и различаются по наименованиям;
  • • все значения атрибутов атомарные.

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

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

Первая нормальная форма допускает хранение в одном отношении разнородной информации, избыточность данных, что приводит к неадекватности логической модели данных предметной области. Таким образом, первой нормальной формы недостаточно для правильного моделирования данных. Например, отношение СТУДЕНТ (Номер студ. билета, ФИО, Дата рождения, Группа) находится в первой нормальной форме.

Вторая и третья нормальные формы возникли в результате стремления избежать аномалий обновления данных при работе с базой данных и избавиться от информационной избыточности в отношениях. Вторая нормальная форма применяется к отношениям с составным ключом, т.е. к таким отношениям, первичный ключ которых состоит из двух или более атрибутов. Вторая нормальная форма требует, чтобы неключевые атрибуты зависели от первичного ключа в целом, но не от его части. Если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного атрибута, то она автоматически находится и во второй нормальной форме. Например, отношение СТУДЕНТ (Номер студ. билета, ФИО, Дата рождения, Группа) находится в первой и во второй нормальных формах одновременно, так как описательные атрибуты однозначно определены и функционально зависят от ключа Номер.

Вот пример таблицы, нарушающей вторую нормальную форму:

Товар (ключ)

Склад (ключ)

Количество

Адрес склада

Т001

Склад 1

15

Вольная ул., д.З

Т002

Склад 2

45

Лесная ул., д. 4

ТООЗ

Склад 2

34

Лесная ул., д. 4

Здесь ключ таблицы состоит из двух полей — Товар, Склад, при этом значение поля Адрес склада зависит, очевидно, только от значения поля Склад. В результате применения такой модели может возникнуть рассогласованность данных: у одного и того же склада могут появиться различные адреса, а если склад опустеет, то его адрес вообще будет забыт. Разумно эту таблицу разбить на две — в одной хранить количество товаров на складе, в другой — адреса и прочие данные о складе.

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

Пример таблицы, не отвечающей критерию третьей нормальной формы:

Табельный № (ключ)

Имя

Фамилия

Отдел

Название отдела

1001

Василий

Попов

Н-11

Продажи

1002

Павел

Морозов

Н-23

Маркетинг

1003

Иван

Федин

Н-11

Продажи

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

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

В определении Кодда для третьей нормальной формы есть допущение — отношение имеет только один потенциальный ключ, который и является первичным ключом. Однако не все отношения могут быть уложены в рамки данного ограничения. Обобщающими являются случаи со следующими условиями:

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

На практике комбинация трех этих условий встречается редко, и для отношения, в котором она не наблюдается, 3NF и BCNF эквивалентны.

Нормальная форма БойсаКодда BCNF требует, чтобы в таблице был только один потенциальный первичный ключ. Если обнаружился второй столбец, позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса — Кодда такие данные надо вынести в отдельную таблицу.

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

Пример таблицы, не отвечающей критерию четвертой нормальной формы:

Код проекта (ключ)

Название проекта

Код сотрудника

Код задания

1001

Бухгалтерия

129

0012

1002

Библиотека

023

0023

1003

Колледж

012

0056

Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания. Каждый кортеж отношения связывает некоторый проект с сотрудником, участвующим в этом проекте, и заданием, который сотрудник выполняет в рамках данного проекта. По причине сформулированных выше условий единственным возможным ключом отношения является составной атрибут Код проекта, Код сотрудника, Код задания. Следовательно, отношение ПРОЕКТЫ находится в BCNF. Но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено. Для того чтобы отношение удовлетворяло ограничениям 4NF, необходима декомпозиция отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ - СОТРУДНИКИ и ПРОЕКТЫ - ЗАДАНИЯ.

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

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

Рассмотрим, например, отношение СОТРУДНИКИ — ОТДЕЛЫ — ПРОЕКТЫ (Номер сотрудника, Номер отдела, Номер проекта). Предположим, что один и тот же сотрудник может числиться в нескольких отделах и работать в каждом отделе над несколькими проектами. Первичным ключом этого отношения является полная совокупность его атрибутов, отсутствуют функциональные и многозначные зависимости. На примерах легко показать, что при вставках и удалениях кортежей могут возникнуть проблемы. Их можно устранить путем декомпозиции исходного отношения в три новых отношения: СОТРУДНИКИ - ОТДЕЛЫ, СОТРУДНИКИ - ПРОЕКТЫ, ОТДЕЛЫ - ПРОЕКТЫ.

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

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

 
Посмотреть оригинал
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 

Популярные страницы