Логическая модель данных. Понятие нормализации отношений

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

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

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

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

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

· в отношении нет одинаковых кортежей;

· кортежи не упорядочены;

· атрибуты не упорядочены и различаются по наименованиям;

· все значения атрибутов атомарные.

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

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

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

Пусть имеется отношение R. Множество атрибутов Y функционально зависимо от множества атрибутов X, если для любого состояния отношения R для любых кортежей r1,r2R из того, что r1X = r2X следует, что r1Y = r2Y, то есть во всех кортежах, имеющих одинаковые значения атрибутов X, значения атрибутов Y также совпадают в любом состоянии отношения R.

Множество атрибутов X называется детерминантом функциональной зависимости, а множество атрибутов Y называется зависимой частью.

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

Функциональная зависимость атрибутов отношения напоминает понятие зависимости в математике. Функциональная зависимость в математике это тройка объектов X, Y и f, где X – множество, представляющее область определения функции, Y – множество значений, а f – правило, согласно которому каждому элементу xX ставится в соответствие один и только один элемент yY. В противоположность этому в отношениях значение зависимого атрибута может принимать различные непредсказуемые значения в различных состояниях базы данных, соответствующих различным состояниям предметной области. Например, изменение сотрудником фамилии при вступлении в законный брак, приведет к тому, что при том же значении детерминанта, скажем, табельного номера, значение зависимого аргумента будет другим.

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

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

Из определения 2НФ следует, что если потенциальный ключ является простым, то отношение автоматически находится во второй нормальной форме.

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

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

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

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

Алгоритм разработки можно представить следующим образом:

1 этап – приведение к 1НФ. Определить и задать отношения, отображающие понятия предметной области. Все отношения автоматически находятся в 1НФ.

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

Исходное отношение – R(K1,K2,A1,A2,…,An,B1,B2,…,Bm).

Ключ {K1,K2} – сложный ключ.

Функциональные зависимости:

{K1,K2} {A1,A2,…,An,B1,B2,…,Bm} – зависимость всех атрибутов от ключа отношения.

{K1} {A1,A2,…,An} – зависимость некоторых атрибутов от части сложного ключа.

После декомпозиции отношения получаем:

R1(K1,K2,B1,B2,…,Bm) – оставшаяся часть исходного отношения.

R2(K1,A1,A2,…,An) – новое отношение.

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

Например, исходное отношение – R(K,A1,A2,….,An,B1,B2,…,Bm).

K – ключ.

Функциональные зависимости:

K {A1,A2,…,An,B1,B2,…,Bm}.

{A1,A2,…,An} {B1,B2,…,Bm}.

После декомпозиции отношения получаем:

R1(K,A1,A2,…,An) – остаток от исходного отношения с ключом К.

R2(A1,A2,…An,B1,B2,…,Bm) – новое отношение с детерминантом функциональной зависимости (A1,A2,…,An) в виде ключа.

На практике достаточно редко разработка логической модели базы данных производится по приведенному алгоритму. Чаще используются различные варианты ER-диаграмм, поддерживаемые соответствующими case-средствами. Основные понятия ER-диаграмм излагаются в стандартах IDEF1 и IDEF1X. Приведенный же алгоритм полезен как иллюстрация проблем, которые могут возникать при определении на первых этапах проектирования слабо нормализованных отношений. Понимание этих проблем особенно важно при проведении модификаций и доработок баз данных, когда вводятся новые сущности, появляются новые зависимости и тому подобное.