Реляционная модель данных. Теория нормализации. Нормальные формы: первая, вторая, третья, Бойса-Кодда

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

К числу достоинств реляционного подхода можно отнести:

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

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

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

К недостаткам:

Сама реляционная модель ограничена в представлении данных:

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

· По определению в реляционной модели поля кортежа могут содержать лишь атомарные (неделимые) значения. Однако, в таких приложениях как САПР (системы автоматизироваанного проектирования), ГИС (геоинформационные системы), искусственный интеллект системы оперируют со сложно - структурированными объектами. Кроме того, даже в том случае, когда сложный объект удается "уложить" в реляционную базу данных, его данные распределяются, как правило, по многим таблицам. Соответственно, извлечение каждого такого объекта требует выполнения многих операций соединения (join), что значительно замедляет работу СУБД.

Обойти это и предыдущее ограничения можно было бы в том случае, если бы реляционная модель допускала

· возможность определения новых типов данных

· определение наборов операций, связанных с данными определенного типа

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

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение (арность отношения – его мощность или совокупность кортежей).

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

В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).

Ключ – поле, каждое значение которого однозначно определено соответствующей записью.

Составной ключ – совокупность полей, значение которых однозначно определено соответствующей записью.

Неключевой атрибут - любой атрибут отношения, не входящий в состав первичного ключа.

Функциональная зависимость. Если даны два атрибута X и Y некоторого отношения, то говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y. Функциональная зависимость в базе данных и в математическом отличается тем, что в БД нестатические, т.е. может изменяться значение ключа, а зависимость остается.

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

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

Транзитивная функциональная зависимость – функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z --> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)

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

Детерминант – любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.

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

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

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

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

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

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

1NF. Первая нормальная форма. Отношение, где все атрибуты (поля) простые и далее не делимы. Как правило исходная таблицу уже находиться в 1NF.

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

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

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

BCNF. Нормальная форма Бойса-Кодда. Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом.

Дата добавления: 2015-01-03