Дата_изменения

Должность

Зарплата

Адрес

Таб_номер

Фамилия

Дата_изменения

Зарплата

Дата_изменения

Должность

Дата_найма

Текущая_зарплата

Адрес

Таб_номер

Фамилия

история_карьеры *

история_зарплаты *

На следующем шаге осуществляется упрощение схемы за счет устранения избыточности.

Действительно, «текущая_зарплата» всегда является последней записью в «история_зарплата», а «дата_найма»по сути дела всегда содержится в разделах «история_зарплаты» и «история_карьеры». Кроме того, несколько дат в последних разделах одни и те же, поэтому целесообразно создать на их основе единую структуру «история_зарплаты_карьеры» и вводить в нее данные при изменении должности и/или зарплаты. Результатом приведенного рассуждения может быть схема:

история_зарплаты_карьеры *

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

Для идентификации сущностей определим ключевые атрибуты. Для первой схемы ключевым атрибутом является «таб_номер», для второй – ключом является совокупность атрибутов «таб_номер» и «дата_изменения», т.к. для каждого сотрудника возможно несколько записей в разделе «история_зарплаты_карьеры». Таким образом, хранилище данных о персонале содержит две сущности (рис. 3.18), которые в общепринятом виде могут быть представлены следующим образом:

сотрудник (таб_номер, фамилия, адрес)

история_зарплаты_карьеры (таб_номер, дата_изменения, должность, зарплата)

Концепции и методы нормализации были разработаны Коддом (Codd), установившим существование трех типов нормализованных схем, названных в порядке уменьшения сложности первой, второй и третьей нормальной формой (соответственно, 1НФ, 2НФ и ЗНФ).Рассмотрим, как преобразовывать схемы к наиболее простой ЗНФ.

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

заказ_на книгу (имя_заказчика, дата_заказа, ISBN, название, автор, количество, цена, сумма_заказа)

Согласно Кодду, любая нормализованная схема (схема без повторяющихся элементов) автоматически находится в 1НФ независимо от того, насколько сложен ее ключ и какая взаимосвязь существует между ее элементами.

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

заказ_на_книгу (имя заказчика, дата заказа, ISBN, количество, сумма_заказа)

книга (ISBN, автор, название, цена)

Заметим, что возможно упростить ситуацию и дальше: атрибуты «количество» и «сумма_заказа» являются взаимно-зависимыми. По определению схема находится в ЗНФ если она находится в 2НФ и никакой из ее неключевых атрибутов не является зависимым ни от какого другого неключевого атрибута. Поскольку в нашем примере атрибут «сумма_заказа» фактически является избыточным то, для получения ЗНФ, его можно просто удалить.

Иногда для построения ЗНФ необходимо выразить зависимость между неключевыми атрибутами в виде отдельной схемы. Так для сотрудников, работающих по различным проектам, возможна следующая схема [20]:

сотрудник (таб_номер, телефон, почасовая_оплата, N_npoeктa, дата_окончания)

Очевидно, что данная схема находится в 2НФ. Однако «N_npoeктa» и «дата_окончания» являются зависимыми атрибутами. После расщепления схемы получим ЗНФ:

участник проекта (таб_номер, телефон, почасовая_оплата, N_пpoeктa)

проект (N_проекта, дата_окончания)

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

В завершении данного этапа зафиксируем алгоритм приведения ненормализованных схем в третью нормальную форму [20] (рис. 3.19).

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

Определение отношений включает выявление связей. Для этого отношение должно быть проверено в обоих направлениях следующим образом: выбирается экземпляр одной из сущностей и определяется, сколько различных экземпляров второй сущности может быть с ним связано, и наоборот. Для примера рассмотрим отношение между сущностями Сотрудник и История_зарплаты_карьеры. У отдельного сотрудника должность и/или зарплата может меняться ноль, один или много раз, порождая соответствующее число экземпляров сущности История_зарплаты_карьеры. Анализируя в другом направлении, видим, что каждый экземпляр сущности История_зарплаты_карьеры соответствует ровно одному конкретному сотруднику. Поэтому между этими двумя сущностями имеется отношение типа 1*n (один ко многим) со связью «один» на конце отношения у сущности Сотрудник и со связью «ноль, один или много» на конце у сущности История_зарплаты_карьеры, что и показано на рис. 3.18.

3-й этап построения ERD-диаграммы (модели данных) предназначен для разрешения неспецифических (многие ко многим) отношений. Для этого каждое неспецифическое отношение преобразуется в два специфических отношения с введением новых (а именно, ассоциативных) сущностей. Рассмотрим пример из работы [20], представленный на рисунке 3.20.

Неспецифическое отношение на рис 3.20 указывает, что Студент может изучать много Предметов, а Предмет может изучаться многими Студентами. Однако мы не можем определить, какой студент изучает какой предмет, пока не введем для разрешения этого неспецифического отношения третью (ассоциативную) сущность Изучение _ предмета. Каждый экземпляр введенной сущности связан с одним Студентом и с одним Предметом.

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

В заключении отметим, что нотация Баркера являются самой распространенной при построении ERD-диаграмм и используется в Сase-средстве Oracle Designer.

Дата добавления: 2014-12-27