Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Фундаментальные свойства отношений).pdf

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

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

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

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

Рисунок 5. Пример ненормализованного отношения

Пример нормализованного отношения приведен на рисунке 6.

Рисунок 6. Нормализованный вариант отношения

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

2.3 Реляционная модель данных

Наиболее распространенное определение реляционной модели данных принадлежит Дейту. Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода [16]:

структурной части;
манипуляционной части;
целостной части.

В структурной части говорится, что в реляционных БД единственной структурой является нормализованное n-арное отношение.

Ранее мы как раз рассматривали понятия и свойства структурной части реляционной модели.

В целостной части говорится о двух базовых требований целостности реляционной СУБД:

требование целостности сущностей. Любой кортеж отношения отличим от любого другого кортежа этого отношения, или по другому любое отношение должно обладать первичным ключом [16].
требование целостности по ссылкам. Данное требование является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности представляются в виде нескольких кортежей отношений [16].

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

Атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута О_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения задают значения первичного ключа.

Требование внешнего ключа состоит в том, что для каждого значения внешнего ключа должен найтись кортеж с таким же значением первичного ключа, либо это значение должно быть неопределенным [14]. Другими словами если для сотрудника указан номер отдела, то этот отдел должен существовать.

Для поддержания целостности по ссылкам используют три подхода:

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

2.4 Понятие нормализации

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

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

В теории реляционных баз данных выделяют следующие нормальные формы [9]:

первая нормальная форма;
вторая нормальная форма;
третья нормальная форма;
нормальная форма Бойса-Кодда;
четвертая нормальная форма;
пятая нормальная форма, или нормальная форма проекции-соединения.

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

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

Рассмотрим понятие второй нормальной формы на следующем примере схемы отношения:

СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ

(НОМЕР_СОТР, ЗАРП_СОТР, О_НОМЕР, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Первичный ключ:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР -> ЗАРП_СОТР

НОМЕР_СОТР -> О_НОМЕР

О_НОМЕР -> ЗАРП_СОТР

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> СОТР_ЗАДАН

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

Путем нормализации можно избавиться от такой ситуации.

Вторая нормальная форма. Отношение R находится во второй нормальной форме в том и только в том случае, когда находится в первой нормальной форме, и каждый неключевой атрибут полностью зависит от первичного ключа [8].

Проведем следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:

СОТРУДНИКИ-ОТДЕЛЫ (НОМЕР_СОТР, ЗАРП_СОТР, О_НОМЕР)

Первичный ключ:

НОМЕР_СОТР

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

НОМЕР_СОТР -> ЗАРП_СОТР

НОМЕР_СОТР -> О_НОМЕР

О_НОМЕР -> ЗАРП_СОТР

СОТРУДНИКИ-ПРОЕКТЫ (НОМЕР_СОТР, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Первичный ключ:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

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

Раскроем понятие третьей нормальной формы, воспользовавшись тем же отношением СОТРУДНИКИ-ОТДЕЛЫ, находящимся уже во второй нормальной форме. Заметим, что функциональная зависимость НОМЕР_СОТР -> ЗАРП_СОТР является транзитивной; она является следствием функциональных зависимостей НОМЕР_СОТР -> О_НОМЕР и О_НОМЕР -> ЗАРП_СОТР. Другими словами, заработная плата сотрудника характеризует не сотрудника, а отдел, в котором он работает.

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

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

Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:

СОТРУДНИКИ (НОМЕР_СОТР, О_НОМЕР)

Первичный ключ:

НОМЕР_СОТР

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

НОМЕР_СОТР -> О_НОМЕР

ОТДЕЛЫ (О_НОМЕР, ЗАРП_СОТР)

Первичный ключ:

О_НОМЕР

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

О_НОМЕР -> ЗАРП_СОТР

Каждое из этих двух отношений находится в третьей нормальной форме.

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

Дальнейшее рассмотрение примера схемы отношения:

СОТРУДНИКИ-ПРОЕКТЫ (НОМЕР_СОТР, СОТР_ИМЯ, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Возможные ключи:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

СОТР_ИМЯ, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР -> CОТР_ИМЯ

НОМЕР_СОТР -> НОМЕР_ПРОЕКТА

СОТР_ИМЯ -> CОТР_НОМЕР

СОТР_ИМЯ -> НОМЕР_ПРОЕКТА

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

СОТР_ИМЯ, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

Здесь предполагаем, что сотрудник полностью определяется своим номером и именем.

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

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

И тогда отношение R находится в нормальной форме Бойса-Кодда в том и только в том случае, если каждый детерминант является возможным ключом [8].

Данное требование не выполняется для отношения СОТРУДНИКИ-ПРОЕКТЫ. Разложим его на следующие отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:

СОТРУДНИКИ (НОМЕР_СОТР, СОТР_ИМЯ)

Возможные ключи:

НОМЕР_СОТР

СОТР_ИМЯ

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

НОМЕР_СОТР -> CОТР_ИМЯ

СОТР_ИМЯ -> НОМЕР_СОТР

СОТРУДНИКИ-ПРОЕКТЫ (НОМЕР_СОТР, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Возможный ключ:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

Продолжим нашу нормализацию и рассмотрим пример следующей схемы отношения:

ПРОЕКТЫ (НОМЕР_ПРОЕКТА, СОТР_ПРОЕКТА, ЗАДАН_ПРОЕКТА)

Отношение ПРОЕКТЫ содержит номера проектов, список сотрудников для выполнения каждого проекта, и список заданий проектов. Сотрудники могут выполнять несколько проектов, при этом задания могут быть одинаковыми для разных проектов.

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

Определим понятие многозначной зависимости, которая существует в отношении R (A, B, C) и имеет вид R.A -> -> R.B при этом это возможно лишь в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.

В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:

НОМЕР_ПРОЕКТА -> -> СОТР_ПРОЕКТА

НОМЕР_ПРОЕКТА -> -> ЗАДАН_ПРОЕКТА