Ограничительные условия, поддерживающие целостность базы данных
Как следует из определения ссылочной целостности при наличии в ссылочных полях двух таблиц различного представления данных происходит нарушение ссылочной целостности, такое нарушение делает информацию в базе данных недостоверной. Чтобы предотвратить потерю ссылочной целостности, используется механизм каскадных изменений (который чаще врего реализуется специальными объектами СУБД - триггерами). Данный механизм состоит в следующей последовательсности действий:
- при изменении поля связи в записи родительской таблицы следует синхронно изменить значения полей связи в соответствующих записях дочерней таблицы;
- при удалении записи в родительской таблицы следует удалить соответствующие записи и в доцерней таблице.
Нормализация - процесс приведения реляционных таблиц к стандартному виду. В базе данных могут присутствовать такие проблемы как:
- Избыточность данных. Повторение данных в базе данных.
- Аномалия обновления. Противоречивость данных, вызванная их избыточностью и частичным обновлением.
- Аномалия удаления. Непреднамеренная потеря данных, вызванная удалением других данных.
- Аномалия ввода. Невозможность ввести данные в таблицу, вызванная отсутствием других данных.
Для решения этих проблем применяют р азбиение таблиц - разделение таблицы на несколько таблиц. Для того чтобы это сделать пользуются нормальными формами или правилами структурирования таблиц.
|
|
Первая нормальная форма
Реляционная таблица находится в первой нормальной форме (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 | ||
CS_NNN | Индекс | |
CS_REG_NUMBER | Регистрационный номер | |
CS_CITY_NNN | Ссылка на справочник городов и регионов | |
CS_NAME | Наименование клиники | |
CS_ADDRESS | Адрес клиники | |
CS_PHONE_NUMBER | Номер телефона | |
CS_TYPE | Профиль клиники | |
Таблица DOCTORS | ||
DC_NNN | Индекс | |
DC_NAME | Ф.И.О. доктора | |
DC_CS_NNN | Ссылка на таблицу CLINICS | |
DC_DIPLOM_NUMBER | Номер диплома | |
DC_SPECIALTY_NNN | Ссылка на справочник специальностей | |
DC_SHTAT_NNN | Ссылка на штатное расписание | |
DC_CALENDAR_NNN | Ссылка на расписание приема | |
Таблица PATIENTS | ||
PT_NNN | Индекс | |
PT_REG_NUMBER | Регистрационный номер | |
PT_NAME | Ф.И.О. пациента | |
PT_ADDRESS | Адрес пациента | |
PT_POLIS_NUMBER | Номер полиса | |
PT_PHONE_NUMBER | Номер телефона | |
PT_BIRTHDATE | Дата рождения | |
PT_FIRST_VISIT | Дата первого визита | |
PT_LAST_VISIT | Дата последнего визита | |
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.
Перейдем к рассмотрению вопросов стандартизации и обеспечения ссылочной целостности реляционных таблиц.