РУКОВОДСТВО РАЗРАБОТЧИКА ИНФОРМАЦИОННЫХ СИСТЕМ СУБД ORACLE

       

Поцесс нормализации


Нормализация -

процесс приведения реляционных таблиц к стандартному виду. В базе данных могут присутствовать такие проблемы как:

  • Избыточность данных.Повторение данных в базе данных.
  • Аномалия обновления. Противоречивость данных, вызванная их избыточностью и частичным обновлением.
  • Аномалия удаления. Непреднамеренная потеря данных, вызванная удалением других данных.
  • Аномалия ввода. Невозможность ввести данные в таблицу, вызванная отсутствием других данных.

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

Первая нормальная форма

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

Вторая нормальная форма.

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

Функциональная зависимость.Значение атрибута в кортеже однозначно определяет значение другого атрибута в кортеже.

Более формально можно определить функциональную зависимость следующим образом: если А и В - атрибуты в таблице В, то запись ФЗ (функциональную зависимость): А - " В обозначает, что если два кортежа в таблице В имеют одно и то же значение атрибута А, то они имеют одно и то же значение атрибута В. Это определение такжеприменимо,если А и В - множества столбцов, а не просто отдельные столбцы.

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

Процесс разбиения на две 2НФ-таблицы состоит из следующих шагов:


  1. Создается новая таблица, атрибутами которой будут атрибуты исходной таблицы, входящие в противоречащую правилу ФЗ. Детерминант ФЗ становится ключом новой таблицы.
  2. Атрибут, стоящий в правой части ФЗ, исключается из исходной таблицы.
  3. Если более одной ФЗ нарушают 2НФ, то шаги 1 и 2 повторяются для каждой такой ФЗ.
  4. Если один и тот же детерминант входит в несколько ФЗ, то все функционально зависящие от него атрибуты помещаются в качестве неключевых атрибутов в таблицу, ключом которой будет детерминант.

Третья нормальная форма
Реляционная таблица имеет третью нормальную форму (ЗНФ), если для любой ФЗ: Х - У Х является ключом. Заметим, что любая таблица, удовлетворяющая ЗНФ, также удовлетворяет и 2НФ. Однако обратное неверно.
Критерийнормальной формы Бойса-Кодда (НФБК) утверждает, что таблица удовлетворяет ЗНФ, если в ней нет транзитивных зависимостей. Транзитивная зависимость возникает, если неключевой атрибут функционально зависит от одного или более неключевых атрибутов. То есть этот критерий учитывает следующие два случая:

  1. Неключевой атрибут зависит от ключевого атрибута, входящего в составной ключ (критерий нарушения 2НФ).
  2. Ключевой атрибут, входящий в составной ключ, зависит от неключевого атрибута.

Таким образом, если таблица удовлетворяет НФБК, то она также удовлетворяет ЗНФ в смысле транзитивных зависимостей и 2НФ.
Четвертая нормальная форма
Таблица имеет четвертую нормальную форму (4НФ), если она имеет ЗНФ и не содержит многозначных зависимостей. Поскольку проблема многозначных зависимостей возникает в связи с многозначными атрибутами, то мы можем решить проблему, поместив каждый многозначный атрибут в свою собственную таблицу вместе с ключом, от которого атрибут зависит.
Пятая нормальная форма.
Пятая нормальная форма (5НФ) была предложена для того, чтобы исключить аномалии, связанные с особым типом ограничительных условий, называемых совместными зависимостями. Эти зависимости имеют в основном теоретический интерес и сомнительную практическую ценность. Следовательно, пятая нормальная форма в действительности не имеет практического применения.
Нормальная форма область/ключ.


Таблица имеет нормальную форму область/ключ (НФОК), если любое ограничительное условие в таблице является следствием определений областей и ключей. Однако не был дан общий метод приведения таблицы к НФОК.
В качестве примера, рассмотрим структуру реляционной базы данных, описывающей "отношения" пациентов и докторов в произвольной клинике (область приложения примера выбрана из-за того, что в сертификационных тестах Oracle аналогичные примеры встречаются очень часто). Пусть существует некая клиника, основные характеристики которой описываются в таблице CLINICS, в данной клинике работают доктора, основные характеристики которых описывает таблица DOCTORS. Данные пациентов клиники хранятся в таблице PATIENTS. Взаимосвязи между таблицами представлены на рис.10. (Для упрощения предполагается, что у доктора может быть несколько пациентов, которые не являются пациентами других докторов, для реализации реальной картины, когда один пациент может относиться к нескольким разным докторам, между таблицами DOCTORS и PATIENTS необходимо включить дополнительную связывающую таблицу).



Рис.10. Диаграмма, иллюстрирующая отношения таблиц АИС.

Наименование столбца Описание
Таблица CLINICS
1 CS_NNN Индекс
2 CS_REG_NUMBER Регистрационный номер
3 CS_CITY_NNN Ссылка на справочник городов и регионов
4 CS_NAME Наименование клиники
5 CS_ADDRESS Адрес клиники
6 CS_PHONE_NUMBER Номер телефона
7 CS_TYPE Профиль клиники
Таблица DOCTORS
1 DC_NNN Индекс
2 DC_NAME Ф.И.О. доктора
3 DC_CS_NNN Ссылка на таблицу CLINICS
4 DC_DIPLOM_NUMBER Номер диплома
5 DC_SPECIALTY_NNN Ссылка на справочник специальностей
6 DC_SHTAT_NNN Ссылка на штатное расписание
7 DC_CALENDAR_NNN Ссылка на расписание приема
Таблица PATIENTS
1 PT_NNN Индекс
2 PT_REG_NUMBER Регистрационный номер
3 PT_NAME Ф.И.О. пациента
4 PT_ADDRESS Адрес пациента
5 PT_POLIS_NUMBER Номер полиса
6 PT_PHONE_NUMBER Номер телефона
7 PT_BIRTHDATE Дата рождения
8 PT_FIRST_VISIT Дата первого визита
9 PT_LAST_VISIT Дата последнего визита
10 PL_PT_NNN Ссылка на таблицу платежей
Таблица PAYMENTS
PL_NNN Индекс
  PL_ACCOUNT_NUMBER Номер расчетного счета
  PL_PAY_NNN Ссылка на таблицу расчетов
<


Представленная структура, конечно, не обладает функциональной полнотой с точки зрения проектирования АИС клиники, с ее помощью мы лишь рассмотрим различные типы отношений в реляционных СУБД.
Перед тем, как перейти к рассмотрению вопросов стандартизации и целостности данных в РСУБД несколько рекомендаций по выбору наименований таблиц и полей. Внимательно взглянув на описание таблиц можно заметить, что генерация наименований таблиц и столбцов подчиняется некоторой синтаксической конструкции, которая в общем виде может быть представлена следующим образом:
Для таблиц: <Псевдоним АИС>_<Псевдоним модуля АИС>_:_<Псевдоним подмодуля>_<Имя таблицы>
Например, если бы мы разрабатывали АИС клиники c сокращенным названием CSL, то все таблицы входящие в данную систему было бы целесообразно называть CSL_<имя модуля>_<имя таблицы>.
Для столбцов: <Псевдоним таблицы>_<имя столбца>.
Например, как показано на рис.10. Регистрационный номер пациента храниться в поле PT_REG_NUMBER, таблицы PATIENTS, имеющий псевдоним PT.
Конечно, использование этих не хитрых правил не является обязательным, но позволяет значительно облегчить читаемость разработанной информационной структуру. Предположите, как было бы все, если бы поля таблиц назывались P111, P112 и т.п., а ведь такие вещи встречаются практически очень часто, например в FoxPro 2.6.
Перейдем к рассмотрению вопросов стандартизации и обеспечения ссылочной целостности реляционных таблиц.

Содержание раздела