Обзор процесса нормализации отношений.

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

1. Множество отношений должно обеспечивать минимальную избыточность данных,

2. Корректировка отношений не должна приводить к двусмысленности или потере данных,

3. Перестройка набора отношений при добавлении в базу данных новых полей должна быть минимальной.

Процесс преобразования отношений называется нормализацией. Методику нормализации отношений разработал А.Ф.Кодд. в 1970г. Он выделил три нормальные формы. Затем Бойсом и Коддом было сформулировано более строгое определение третьей нормальной формы, получившей название нормальной формы Бойса-Кодда. Позже стали выделять 4НФ и 5НФ. Однако на практике эти нормальные формы используются крайне редко.

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

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

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

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

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

1. Имеются два или более составных ключа,

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

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

Этапы проектирования базы данных.

Методология проектирования БД предусматривает разбиение всего процесса проектирования на несколько фаз, каждая из которых состоит из нескольких этапов.

Общепринятая методология проектирования БД разделяется на 3 основные фазы:

1. концептуальное проектирование

2. логическое проектирование

3. физическое проектирование

Концептуальное проектирование – это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации.

Логическое проектирование – это процесс конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической реализации.

Физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным.

В целом процедура проектирования БД будет включать следующие этапы:

1. Создание концептуальной модели данных, исходя из представлений о предметной области, каждого из пользователей. Шаги:

1.1 определение типов сущности;

1.2 определение типов связей;

1.3 определение атрибутов и связывание их с типами сущностей и связей;

1.4 определение доменов атрибутов;

1.5 определение атрибутов, являющихся потенциальными и первичными ключами;

1.6 создание диаграмм “сущность ­– связь”;

1.7 обсуждение локальной концептуальной модели с конечным пользователем.

2. Построение и проверка локальной логической модели данных на основе представления.

1.8 преобразование локальной концептуальной модели в локальную логическую модель;

1.9 определение наборов отношений, исходя из структур локальной логической модели данных;

1.10 проверка модели с помощью правил нормализации;

1.11 проверка модели в отношении транзакции пользователя;

1.12 создание диаграмм “сущность – связь”;

1.13 определение требований поддержки целостности данных;

1.14 обсуждение локальной логической модели с конечным пользователем;

3. Создание и проверка глобальной логической модели данных.

1.15 слияние локальных и логических моделей в единую модель;

1.16 проверка глобальной логической модели;

1.17 проверка возможности расширения проблемы в будущем;

1.18 создание окончательного варианта диаграммы “сущность – связь”;

1.19 обсуждение глобальной логической модели с конечным пользователем;

4. перенос глобальной логической модели данных в среду целевой СУБД.

1.20 создание основных таблиц в среде СУБД;

1.21 реализация бизнес-правил предприятия среди СУБД.

5. Проектирование физического представления БД

1.22 анализ транзакций;

1.23 выбор файловой структуры;

1.24 определение вторичных индексов;

1.25 контроль за избыточностью данных;

1.26 определение требований дисковой памяти.

6. Разработка механизмов защиты:

1.27 разработка пользовательских представлений;

1.28 определение прав доступа к данным;

Этапы 4, 5, 6 – это физическое проектирование данных и ориентировано на реляционные СУБД.