Анализ методов проектирования БД.

Методы проектирования БД

Целью проектирования БД является адекватное отображение в базе данных сути предметной области, рассматриваемой с точки зрения решения задачи автоматизации.
В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни её архитектуры. Распространены два основных подхода к проектированию баз данных: "нисходящий" и "восходящий".
Известен также подход "смешанной стратегии" — сначала «восходящий» и «нисходящий» методы используются для разных частей модели, после чего все подготовленные фрагменты собираются в единое целое.

Рассмотрим на рисунке отличие этих методов

Метод восходящего проектирования БД

При «восходящем» подходе осуществляют структурное проектирование снизу—вверх. Этот процесс называют процессом синтеза, попыткой получения целого, адекватно отображающего описание предметной области, на основе описания составляющих его частей.
Этапы проектирования БД методом «восходящего» проектирования представлены на рисунке 2.
ДЛМ – даталогическая модель; НФ – нормальная форма; ИЛМ – информационно—логическая модель предметной области; МБД – модель БД.

Рисунок 2 — Этапы проектирования БД методом «восходящего» проектирования

Работа для реляционной БД начинается с определения свойств объектов (атрибутов сущностей) предметной области, которые на основе анализа существующих между ними связей группируются в реляционные отношения (таблицы), отображающие эти объекты (в том случае, если мы проектируем структуру реляционной БД).
Как правило, получают 2 — 3 реляционных отношения, связанных между собой.
Избыточность данных в ненормализованной схеме – повторение данных в БД.
Для того чтобы полученная структура БД (ДЛМ) не обладала различными аномалиями при добавлении, обновлении или удалении данных вследствие их избыточности, необходимо осуществить проверку каждой полученной схемы отношения, как минимум, на соответствие 3НФ. Если схемы отношений не соответствуют этому условию, а они, как правило, не соответствуют, необходимо проводить процесс нормализации.

Значительный объем мероприятий по нормализации схем реляционных отношений даже дал второе название методу «восходящего» проектирования. Этот метод часто называют методом «нормализации». Основы теории нормализации создал Э. Кодд.

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

Совокупность схем отношений называется схемой реляционной БД.
Нормализация исключает избыточность и аномалии в БД.

Пример
Схема1 (Код автора, ФИО автора, Код книги, Название книги, Код издательства, Название издательства, Дата издания)
Повторение данных об издательсве (назвнаие), ФИО автора, если у него несколько книг и другое

Аномалии в ненормализованной схеме отношения:
а) обновления – противоречивость данных, вызванная их избыточностью и частичным обновлением.

б) аномалия удаления – непреднамеренная потеря данных, вызванная удалением других данных

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

Этапы проектирования БД методом нормализации:

Выделяют следующие этапы:
1. Определение всех атрибутов, сведения о которых будут включены в БД - сбор сырых данных на предприятии.
2. Составление списка сырых данных в виде схем реляционных отношений. Полученная в итоге схема отношений находятся в нулевой нормальной форме (0НФ).
3. Приведение схемы отношения к 1НФ
Опр. 1НФ: Схема отношения находится в 1НФ тогда и только тогда, если все атрибуты схемы имеют атомарное значение и в схеме отношений отсутствуют повторяющиеся группы.
Опр.: повторяющаяся группа – один или более элементов данных, которые имеют более одного значения для одного значения части ключа. Рассматривается, если первичный ключ составной.
Разбиение схемы отношения на атомарные атрибуты.
Удаление повторяющихся групп.
4. Изучение смысла (семантики) данных и определение набора атрибутов – потенциального (уникального) ключа отношения. Может быть несколько уникальных ключей.
Уникальный (потенциальный) ключ – атрибут или набор атрибутов, который полностью и однозначно определяет значения других атрибутов.
5. Если отношение обладает несколькими потенциальными ключами, то нужно выбрать среди них кандидата в первичный ключ.
6. Выявление функциональных зависимостей между атрибутами нормализуемой схемы отношения.
Опр.: функциональной зависимостью атрибута В (набора атрибутов) отношения R от атрибута (набора атрибутов) А отношения R, обозначаемой
R.A -> R.B A->B
называется такая связь между атрибутами отношения, что в каждый момент времени каждому значению атрибута (набору атрибутов) В соответствует только одно значение атрибута (набора атрибутов) А.
Однако для заданного значения атрибута В может существовать несколько различных значений атрибута А.

Таким образом, если из семантики предметной области нам известно значение атрибута А, то мы в предметной области однозначно можем определить значение атрибута В.
ФЗ является смысловым свойством атрибутов отношения.
В отношении м.б. выявлено много функциональных зависимостей, т.е. в отношении м.б. выявлено много детерминантов.
Опр.: ключевой атрибут – атрибут, входящий в состав первичного ключа
Опр.: не ключевой атрибут – атрибут, не входящий в состав первичного ключа.
Опр.: частичная ФЗ – это зависимость не ключевого атрибута от части составного первичного ключа.
Опр.: полная ФЗ – это зависимость не ключевого атрибута от всего составного первичного ключа.
Имеет смысл рассматривать полную и частичную ФЗ в том случае, если ПК – составной.
7. Приведение схемы отношения к 2НФ
Технология приведения ко 2НФ:
1) В отдельную схему отношения выносится составной первичный ключ и те атрибуты, которые функционально полно зависят от него. Если таких атрибутов нет, то первичный ключ выносится один.
2) В отдельную схему выносится часть первичного ключа и те атрибуты, которые функционально полно зависят от этой части.
Сколько частей первичного ключа образовали частичные ФЗ, столько схем получаем
3) Исходная схема удаляется.

8. Определение транзитивных зависимостей в каждом нормализуемом отношении
Опр.: транзитивная зависимость – атрибут С отношения R транзитивно зависит от атрибута А отношения R, если для атрибутов А, В, С выполняется условие существования следующих ФЗ:
А -> B
B -> C
при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С.

9. Удаление транзитивных зависимостей путем декомпозиции схем отношений

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

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

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

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

Рассмотрим на рисунке схему процесса нормализации

Рисунок – Схема процесса нормализации

«Восходящее» проектирование – это достаточно сложная и устаревшая методика, которая подходит для проектирования только небольших баз данных.

Нисходящее проектирование БД

При «нисходящем» проектировании осуществляется структурное проектирование сверху—вниз («нисходящее» проектирование).
Такое проектирование называют анализом – происходит изучение целого (описания предметной области), затем разделение целого на составные части и затем следует последовательное изучение этих частей.
Этапы проектирования БД методом «нисходящего» проектирования представлены на рисунке.

Пр Обл. – предметная область; ИЛМ – информационно—логическая модель предметной области; ДЛМ – даталогическая модель; НФ – нормальная форма; ФМ – физическая модель БД.

Рисунок — Этапы проектирования БД методом «нисходящего» проектирования

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

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

На основе описания внешнего уровня строится концептуальная информационно—логическая модель предметной области (ИЛМ), затем на её основе получают даталогическую модель (ДЛМ) базы данных. ДЛМ является основой для следующего этапа проектирования БД – этапа формирования физической модели базы данных.

Такой подход к проектированию БД называют также концептуальным или концептуальным проектированием.

В концептуальном подходе к проектированию БД выделяют следующие три сферы:
— реальный мир или объектную систему;
— информационную сферу;
— даталогическую сферу.

1. Основными составляющими объектной системы являются: объект (экземпляр сущности), свойство (атрибут), отношение (связь) (предметная область определена, если известны существующие в ней объекты, их свойства и отношения между ними)
Объект в концептуальном подходе – это то, о чем в информационной системе должна накапливаться информация.

Объекты объединены в классы объектов (экземпляры сущностей в сущность, или ещё говорят – тип сущности). Класс объектов может состоять из одного или более объектов.
Например, класс объектов ФИЗИЧЕСКОЕ ЛИЦО, отдельные объекты – Иванов, Петров, Сидоров.

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

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

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

В основе концептуального подхода лежит идея установления последовательного соответствия между объектной системой, информационной и далее даталогической сферами.
Происходит последовательное преобразование понимания объектов предметной области и связей между ними в формализованное описание логики информации предметной области и дальнейшее преобразование логики информации предметной области в описание структуры базы данных в терминах выбранных структур данных – построение логики данных.
Такое последовательное преобразование позволяет понятным и простым образом осуществлять правильное отображение смысла реального мира в базе данных. Таким образом, концептуальное проектирование БД состоит из следующих последовательных этапов:
— анализ предметной области, выявление классов объектов и связей между ними (формирование внешнего уровня БД) – описание объектной сферы;
— концептуальное инфологическое проектирование. Строится концептуальная информационно—логическая модель (ИЛМ) предметной области, формально (в терминах выбранной методологии построения ИЛМ) описывающая классы объектов и связи между ними (формирование концептуального уровня БД) – описание информационной сферы;
— концептуальное даталогическое проектирование. На основе ИЛМ в терминах выбранной модели данных строится концептуальная даталогическая модель (ДЛМ) БД (формирование концептуального уровня БД) – описание даталогической сферы;
— преобразование ДЛМ в физическую модель БД, полученную на ЯОД выбранной СУБД (формирование внутреннего уровня БД).

Замечание: на втором этапе проектирования ИЛМ можно преобразовать в любую даталогичскую модель – иерархическую, сетевую, реляционную, традиционные файлы.

Метод «нисходящего» проектирования достаточно формализован и используется в CASE (Computer Aided System/Software Engineering — компьютерное проектирование программного обеспечения и систем) средствах.

Замечания по использованию CASE − средств:
- особенно эффективно их использование при создании крупных корпоративных АИС большим коллективом разработчиков;
- современные CASE − средства позволяют поддерживать как начальные этапы разработки АИС, так и проектирование, и генерацию баз данных и пользовательских интерфейсов;
- CASE − средства обеспечивают качество принимаемых технических решений и подготовку проектной документации;

Сравнение методов проектирования (приведено в таблице)
(для реляционной модели данных)

Таблица - Сравнение методов проектирования БД

Критерии	«Нисходящее» проектирование (Концептуальный подход)	«Восходящее» проектирование (Метод нормализации)
Степень описания семантики (смысла) предметной области	Высокая	Низкая (начальная модель – ДЛМ РБД, термины РМД не предусматривают возможность описания полного смысла предметной области.)
Вероятность появления ошибок в последующей работе АИС	Низкая (при условии качественного проектирования)	Высокая
Степень формализации процесса (возможность автоматизации процесса)	Высокая	Отсутствует
Объем трудозатрат при приведении ДЛМ БД к заданной НФ	Небольшой	Очень большой