Моделирование бизнес-процессов (стр. 14 )

А.2.3.3.2. Нормализация — денормализация

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

структур данных, а также применяться к другим моделям данных. В этой книге каждая ступень нормализации дается лишь в виде определения. Более подробная информация содержится в работах: Schlageter,Stucky. Datenbanksysteme 1983. с. 183; Wedekind. Datenbanksysteme I. 1991, с. 200; Vossen. Datenbank-Management-Systeme. 1995, c. 249-270.

Кроме того, мы рассмотрим только нормальные формы 1-3 (так называемые нормальные формы Бойса-Кодда). Форм 4 и выше ввиду их крайне редкого применения касаться не будем. Возьмем следующий пример (Schlageter, Stucky. Datenbanksysteme. 1983, с. 162), относящийся к организации проекта:

1-я НОРМАЛЬНАЯ ФОРМА (1 НФ):

(1.1) R_EMPLOYEE (EMP_NO, NAME,

ADDRESS,

PROFESSION,

DEPT_NO)

(1.2) R_PROJECT (P_NO, P_NAME,

P_DESCR, P_MGR)

(1.3) R_EMP_PROJ (P_NO, EMP_NO,

PH_NO,

PERCENT_WORK_ HOURS)

(1.4) R_DEPT_NO (DEPT_NO,

DEPTJVTCR,

BUILDG_NO, JANITOR)

2-я НОРМАЛЬНАЯ ФОРМА (2 НФ): (2,1) R_EMPLOYEE* (EMP_NO, NAME,

ADDRESS, PROFESSION,

DEPT_NO)

(2,3) R_EMP_PROJ* (P_NO, EMP_NO,

PH_NO,

PERCENT_WORK_ HOURS)

3-я НОРМАЛЬНАЯ ФОРМА (З НФ):

(3,4) R_BUILDG (BUILDG_NO,

JANITOR)

(3,5) R_DEPT* (DEPT_NO,

DEPT_MGR, BUILDG_NO)

Определения:

• Отношение R соответствует 1 - и нормальной форме (1 НФ), когда значение каждого атрибута является элементарным.

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

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

Теперь рассмотрим на примере аномалии, возникающие в 1 НФ, которые нужно удалить посредством нормализации.

• Аномалия вставки возникает, например, в том случае, когда в базу данных вводится новый сотрудник, еще не связанный с каким-либо проектом. Из-за отсутствия такой связи ему нельзя присвоить номер телефона (PH_NO), поскольку этот атрибут присутствует только в отношении сотрудник-проект (R_EMP_PROJ).

• Когда проект завершен и отношение (1,3) нужно удалить, возникает аномалия удаления. Она выражается в том, что номер телефон сотрудника также удаляется, даже если он по-прежнему действителен.

• Аномалия обновления возникает при изменении номера телефона сотрудника, когда требуется разыскать все кортежи отношения (R_EMP_PROJ). При этом придется обновить каждый номер телефона данного сотрудника, который может участвовать в нескольких проектах, хотя изначально обновлен лишь один-единственный элемент данных.

Эти аномалии исчезают при преобразовании отношений (1,1) и (1,3) во 2-ю нормальную форму. Поскольку номер телефона (PH_NO) идентифицируется только по ключу EMP_NO отношения (1,1), он вводится здесь как атрибут. В отношении

(1.3) номер телефона удаляется. Отношения же (1,2) и (1,4) соответствуют 2 НФ.

При принятии на работу смотрителя необходимо обновить отношения отдела

(1.4) применительно к зданиям, где он будет работать. Таким образом, смотритель непосредственно связан не с отделом (DEPT), а со зданием (BUILDG). В 3-й нормальной форме разбиение отношения (1,4) на два отношения устраняет транзитивную зависимость, порождающую кортежи. В данном примере отношения (2,1), (1,2) и (2,3) уже соответствуют 3-й нормальной форме.

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

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

Разбиение класса ОТНОШЕНИЕ посредством нормализации означает выведение дополнительных отношений на основе адаптированных предварительных отношений. Поскольку один информационный объект может порождать множество отношений, мощность класса ОТНОШЕНИЕ принимает значение (0..*), как показано в скобках рядом с соответствующим ребром на рис. 70.

На происхождение отношения из другого отношения, существующего на предыдущем уровне нормализации, указывает связь НОРМАЛИЗАЦИЯ, благодаря чему становится очевидным, из какого отношения лежащего ниже уровня нормализации выведено данное отношение рассматриваемого (лежащего выше) уровня.

Когда в процессе нормализации создаются новые отношения, описание требований и предварительные отношения, связанные с присвоением атрибутов, обновляются. Однако это ведет не к расширению диаграммы классов, показанной на рис. 70, а к созданию новых экземпляров ассоциативного класса АССОЦИАЦИЯ ОТНОШЕНИЕ-АТРИБУТ.

А.2.3.3.3. Условия целостности

Условия целостности обеспечивают, чадекватное моделирование реальности с помощью базы данных (Blaser, Jarke, Lehmann. Datenbanksprachen und Datenbankbenutzung. 1987, c. 586).

Поскольку таблицы в реляционных моделях не позволяют достаточно хорошо описывать семантические элементы, условия целостности описываются языком манипулирования данными. Можно задавать условия целостности и в рамках прикладной программы. Учитывая принцип локальности и преимущества централизованного управления целостностью данных, эти условия целесообразно включить в представление данных. Современные СУБД рассчитаны на хранение максимума функциональных модулей (которые раньше хранились в программах) в непосредственной близости от баз данных (Dittrich, Gatziu. Aktive Datenbanksysteme. 1996).

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

Условия непротиворечивости относятся к атрибутам, экземплярам отношений (кортежам) и отношениям, вытекающим из типов отношений (Blaser, Jarke, Lehmann. Datenbanksprachen und Datenbankbenutzung. 1987, c. 588), которые также известны как условия целостности на уровне ссылок.

Стандартным языком манипулирования данными в реляционных моделях является SQL. В языке SQL условия целостности задаются при помощи команд утверждения (ASSERT) и описания событий, которые должны активизировать выполнение действий.

Например, если при удалении номера сотрудника (EMP_NO) в отношении EMPLOYEE (СОТРУДНИК) должна удаляться и связь с квалификацией сотрудника в отношении OWNS (ОБЛАДАЕТ), связанном с отношением SKILLS (КВАЛИФИКАЦИЯ), то активизатор описывается следующим образом (Blaser, Jarke, Lehmann. Datenbanksprachen und Datenbankbenutzung. 1987, c. 592):

DEFINE TRIGGER Tl

ON DELETE OF EMPLOYEE (EMP_NO):

DELETE OWNS

WHERE OWNS. EMP_NO=EMPLOYEE. EMP_NO.

На рис. 71 приведено несколько примеров описания утверждений.

Пояснение 1) Условие относится к атрибуту. Пример: экземпляры ЕМР N0 должны иметь четыре разряда 2) Условие относится к множеству атрибутов экземпляр записи. Пример: сумма зарплаты (SALARY_SUM) по отделу должна быть меньше его годового бюджет (ANNUAL_BUDGET). 3) Условие относится к множеству экземпляров одного и того же типа записи (отношения). Пример: зарплата одного сотрудника не может превышать среднюю зарплату по отделу более чем на 20% 4) Условие относится к множеству экземпляров в различных отношениях. Пример: значение SALARY_SUM в отделе всегда должно равняться сумме полей SALARY его сотрудников.

Операторы SQL ASSERT IB1 ON EMPLOYEE: ЕМР NO BETWEEN 0001 AND ASSERT IB2 DEPARTMENT: SALARY SUM < ANNUAL BUDGET ASSERT IBS ON EMPLOYER X: SALARY = 1,2 J (SELECT AVG(SALARY) FROM EMPLOYEE WHERE DEPART = X. DEPART) ASSERT IB4 ON EMPLOYER X: SALARY SUM = (SELECT SUM(SALARY) FROM EMPLOYEE WHERE DEPART = X. DEPARTNO)

Рис. 71. Условия целостности (Reuter. Sicherheits und Integritatsbedingungen. 1987, c. 381, 385)

На рис. 72 показаны ключевые отношения, вытекающие из декомпозиции условий целостности. Отправной точкой для рассмотрения проблем целостности является левая часть рис. 72, содержащая классы ОТНОШЕНИЕ, АТРИБУТ и ДОМЕН. Класс ТИП ЦЕЛОСТНОСТИ описывает различные типы условий целостности (Reuter. Sicherheits-und Integritatsbedingungen. 1987, с. 380). Их можно дифференцировать по диапазону (тип и число объектов, которым адресовано условие целостности; см. примеры на рис. 71), по времени проверки (всегда ли проверяются условия целостности или только после выполнения определенного количества операций), по способу проверки (условия состояния или условия перехода) или по возможности активизации действий в зависимости от условия целостности.

На рис. 72 каждое конкретное условие целостности связано с одним типом целостности. Условие целостности может относиться к одному или нескольким отношениям и к ассоциации атрибутов одного или нескольких отношений. Пределы значения атрибута контролируются их связью с классом АССОЦИАЦИЯ С ДОМЕНОМ.