Глава 15. Методология логического проектирования реляционной бд

На этой стадии выполняются следующие этапы.

1. Исключение особенностей, не совместимых с реляционной моделью данных (необязательный этап).

2. Формирование набора отношений на основе логической модели данных.

3. Проверка отношений с использованием средств нормализации.

4. Определение ограничений целостности.

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

Назначение рассматриваемого этапа состоит в преобразовании следующих элементов концептуальной модели данных:

• двухсторонние связи типа *:*;

• сложные связи;

• многозначные атрибуты.

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

Для примера рассмотрим связь Client Views PropertyForRent(Клиент осматривает Объект недвижимости), которая принадлежит типу *:*. В результате декомпозиции связиViewsопределена сущностьViewing(Осмотр) и для нее введены две новые связи:

• Client Requests Viewing(Клиент требует проведения осмотра);

• PropertyForRent Takes Viewing(Объект недвижимости подвергается Осмотру).

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

Преобразование сложных связей.Необходимо выполнить декомпозицию такой связи. В результате выявляется промежуточная сущность, а сложная связь заменяется необходимым количеством двухсторонних связей 1:* с этой новой сущностью.

Например, после декомпозиции трехсторонне связи Registersпоявляется новая (слабая) сущностьRegistration. Эта сущность связывается с первоначальными сущностями с помощью следующих двухсторонних связей:

• Branch Registers Registration(в отделении проводится регистрация);

• Staff Processes Registration(сотрудник проводит регистрацию);

• Client Agrees Registration(клиент соглашается на регистрацию).

Преобразование многозначных атрибутов.Вместо такого атрибута вводится новая сущность. Например, многозначный атрибутtelNoдля сущностиBranchзаменяется новой сущностьюTelephoneс простым однозначным атрибутомtelNo, который становится первичным ключом. СвязьHasмежду сущностямиBranchиTelephoneотносится к типу 1:3.

Формирование набора отношений в составе логической модели данных.Для каждой сущности создается таблица, включающая все простые атрибуты этой сущности. В случае составного атрибута (например,name) в таблицу включаются только составляющие его простые атрибуты (такие какfNameиlName). Связи между разными таблицами реализуются с помощью механизма «первичный ключ/внешний ключ», т.е. родительская сущность передает копию своего первичного ключа в дочернюю сущность для его использования в качестве внешнего ключа.

Для описания структуры создаваемых отношений будет использоваться язык DDL (DataDefinitionLanguage). Описание таблицы на этом языке начинается с указания имени таблицы. Затем в круглых скобках приводится список простых атрибутов. В следующих строках указывается первичный ключ таблицы, а также все альтернативные и внешние ключи. Рядом с каждым внешним ключом необходимо указать первичный ключ, на который он ссылается. Каждый производный атрибут объявляется вместе с теми атрибутами, с помощью которого вычисляется его значение. Ниже приведен пример описания структуры отношенияStaff.

Staff(staffNo, fName, lName, position, sex)

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

Для каждой двухсторонней связи 1:*сущность, находящаяся на стороне «один», объявляется как родительская, а сущность на стороне «многие» — как дочерняя. Например, для связиStaff Registers Client(Сотрудник компании регистрирует клиента) сущностьStaffявляется родительской, а сущностьClient— дочерней. Схема взаимодействия отношенийStaffиClientвыглядит следующим образом:

Если связь 1:* имеет свои атрибуты, то они должны следовать за вставкой первичного ключа в дочернее отношение. Например, если связь Staff Registers Clientимеет атрибутdateRegistration, содержащий дату проведения регистрации клиента, то этот атрибут также должен быть вставлен в отношениеClient.

При создании отношений, участвующих в связи типа 1:1, необходимо выбрать один из следующих вариантов:

• объединение всех сущностей, участвующих в связи, в одно отношение;

• создание двух отношений и передача копии первичного ключа из одного отношения в другое.

Критерием выбора конкретного варианта является степень участия.

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

2. При обязательном участии одной стороны в связи типа 1:1 сущность, которая характеризуется необязательным участием, обозначается как родительская, а сущность с обязательным участием в связи становится дочерней.

Пусть, например, связь ClientStates Preference (клиент выражает свои пожелания) характеризуется частичным участием со стороны сущностиClient(т.е. не каждый клиент высказывает свой пожелания). Тогда сущностьClientдолжна быть определена как родительская, а сущностьPreference— как дочерняя.

3. При необязательном участии обеих сторон в связи типа 1:1 одна из них произвольно назначается родительской, а другая — дочерней. В качестве дочерней рекомендуется назначать сущность, которая характеризуется более полным участием в связи.

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

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

1. На этапе логического проектирования не стоит задача получения окончательного проекта. Цель этого этапа — достижение проектировщиком более углубленного понимания природы и назначения данных, используемых в организации. Если к приложению предъявляются особые требования с точки зрения производительности, то они должны учитываться на последующем этапе физического проектирования. В этом случае одним из подходов является денормализация некоторых нормализованных таблиц. Однако это не означает, что время на их нормализацию потрачено впустую. Ведь для правильного выполнения нормализации проектировщик должен глубоко изучить семантику и особенности использования данных, полностью понять назначение каждого атрибута в составе создаваемой БД.

2. Нормализованный проект является надежным и не допускает аномалий при работе с данными.

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

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

№ п/п	Содержание этапа	Достигаемый результат
1	Приведение к первой нормальной форме (1НФ)	Удаление повторяющихся групп атрибутов
2	Приведение ко второй нормальной форме (2НФ)	Устранение частичной зависимости атрибутов от первичного ключа
3	Приведение к третьей нормальной форме (3НФ)	Устранение транзитивной зависимости атрибутов от первичного ключа
4	Приведение к нормальной форме Бойса-Кодда (НФБК)	Удаление из функциональных зависимостей оставшихся аномалий

Позднее были введены нормальные формы более высокого порядка — четвертая (4НФ) и пятая (5НФ). Однако на практике они используются крайне редко.

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

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

Взаимосвязь между различными нормальными формами показана на рис. ХХ. Согласно этому рисунку, некоторые таблицы в форме 1НФ могут находиться также в форме 2НФ, отношения 2НФ — в форме 3НФ и т.д.

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

Проблемы, связанные с избыточностью данных, можно проследить на примере таблицы StaffBranch, которая описывается следующим образом:

StaffBranch(staffNo, sName, position, salary, branchNo, bAddress)

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

Аномалии вставки.

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

• Для вставки сведений о новом филиале, в котором еще не имеется собственных сотрудников, потребуется в соответствующей записи присвоит значение NULL всем атрибутам, предназначенным для описания персонала, включая и табельный номер сотрудника (staffNo). Однако в таблицеStaffBranchатрибутstaffNoявляется первичным ключом, поэтому такая попытка противоречит требованиям целостности данных и будет отклонена.

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

Аномалии удаления.При удалении из таблицыStaffBranchстроки с данными о последнем сотруднике некоторого филиала полностью исчезают из БД и сведения об этом филиале. Таким образом, аномалии удаления приводят к непреднамеренной потере данных при удалении других данных.

Аномалии коррекции (обновления).При попытке изменить значение одного из атрибутов (например, адрес) для некоторого филиала компании в таблицеStaffBranchпотребуется проделать эту операцию сразу для всех сотрудников рассматриваемого филиала. Если такая модификация затронет не все требуемые строки таблицы, то в БД возникают противоречия. Таким образом, аномалии коррекции создают предпосылки для противоречий, обусловленных избыточностью данных и их частичным обновлением.

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

Если в таблице R, содержащей атрибуты А и В, каждое значение атрибута А связано только с одним значением атрибута В, то атрибут В функционально зависит от атрибута А (это обозначается как АВ). Отметим, что каждый из символов А или В может обозначать целую группу атрибутов.

При наличии функциональной зависимости АВ атрибут (или группа атрибутов) А называетсядетерминантоматрибута (или группы атрибутов) В.

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

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

Для примера рассмотрим следующую таблицу с данными об объектах недвижимости, которые арендованы двумя клиентами.

clientNo

cName

propertyNo

pAddress

rentStart

rentFinish

rent

ownerNo

oName

Легко заметить, что у каждого клиента повторяются сведения об арендуемых объектах, т.е. повторяющаяся группа представляет собой следующий список атрибутов: (propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName). Из-за наличия этой повторяющейся группы в некоторых клетках таблицы содержится сразу несколько значений для отдельных атрибутов. Например, приclientNo=CR76атрибутуpropertyNoсоответствуют два значения —PG4иPG16.

Чтобы устранить это отклонение от требований 1НФ, в каждую строку с описанием объекта недвижимости добавляются соответствующие сведения о клиенте. В результате будет получена первая форма 1НФ для таблицы ClientRental. Эта таблица характеризуется значительной избыточностью данных, что порождает аномалии обновления. Например, изменение арендной платы для одного из объектов недвижимости потребует обновления нескольких строк.

Вторая нормальная форма (2НФ)основана на понятияхполной и частичной функциональной зависимости. Функциональная зависимость АВ являетсяполной, если удаление какой-либо части из составного атрибута А приводит к утрате этой зависимости. Если же в этом случае рассматриваемая функциональная зависимость будет сохранена, то она называетсячастичной.

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

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

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

Рассмотрим таблицу ClientRental, в которой первичный ключ состоит из атрибутов (clientNo, propertyNo). Нетрудно заметить, что в этой таблице присутствуют следующие частичные зависимости от атрибутов, входящих в состав первичного ключа:clientNo cNameиpropertyNo pAddress, rent, ownerNo, oName. В то же время, зависимость (clientNo, propertyNo)rentStart, rentFinishявляется функционально полной.

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

• Client (clientNo, cName);

• Rental (clientNo, propertyNo, rentStart, rentFinish);

• PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName).

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

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

Если в некоторой таблице для атрибутов А, В и С существуют зависимости АВ и ВС, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В.

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

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

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

В таблице PropertyOwnerприсутствуют следующие функциональные зависимости:

• Ф31: propertyNo  pAddress, rent, ownerNo, oName;

• Ф32: ownerNooName.

Зависимость Ф32 — типичный пример транзитивной зависимости. Для устранения этой зависимости необходимо создать две новые таблицы:

• PropertyForRent (propertyNo, pAddress, rent, ownerNo);

• Owner (ownerNo, oName).

Таким образом, исходная таблица ClientRental, которая находилась в форме 1НФ, преобразована в 4 таблицы, каждая из которых удовлетворяет требованиям 3НФ. Процесс преобразования можно представить в виде следующей схемы.

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

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

Форма НФБК основана на рассмотрении всех функциональных зависимостей, в которых участвуют потенциальные ключи. Требования НФБК заключаются в следующем: каждый детерминант таблицы должен быть потенциальным ключом.Следовательно, для проверки принадлежности таблицы к НФБК необходимо найти все ее детерминанты и убедиться, что они являются потенциальными ключами.

Нарушения требований НФБК происходят крайне редко, поскольку это может случиться только при следующих условиях:

• в таблице имеется не менее двух составных потенциальных ключей;

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

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

Решение о том, следует ли в процесс нормализации остановиться на форме 3НФ или перейти к форме НФБК, зависит от сопоставления следующих факторов:

• относительная избыточность данных, возникающая в случае 3НФ;

• важность утрачиваемой зависимости при переходе к НФБК.