Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

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

Читайте также:
  1. ОКОНЧАТЕЛЬНАЯ НОРМАЛИЗАЦИЯ ЭНЕРГЕТИКИ ТЕЛА. ТЕОРИЯ
  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, а к созданию новых экземпляров ассоциативного класса АССОЦИАЦИЯ ОТНОШЕНИЕ-АТРИБУТ.


Дата добавления: 2015-08-03; просмотров: 153 | Нарушение авторских прав


Читайте в этой же книге: А.2.1.4. Реализация на уровне функциональной модели | А.2.2.1. Определение требований на уровне организационной модели | А.2.2.3.1. Топология сети | А.2.2.4. Реализация на уровне организационной модели | А.2.3.1. Определение требований на уровне модели данных | А.2.3.1.1. Макроописание | А.2.3.1.2.1. Простая модель ERM | А.2.3.1.2.2. Расширенная модель ERM | А.2.3.2. Конфигурирование данных | А.2.3.3. Спецификация проекта в рамках модели данных |
<== предыдущая страница | следующая страница ==>
А.2.3.3.1. Создание отношений| А.2.3.3.3. Условия целостности

mybiblioteka.su - 2015-2024 год. (0.008 сек.)