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

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

В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни её архитектуры. Распространены два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий":

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

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

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

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

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

Для успешного проведения нормализации необходимо на основе анализа предметной области (анализа документов предметной области) для каждой схемы реляционного отношения:

— выявить потенциальные ключи;

— увидеть повторяющиеся группы и не атомарные атрибуты;

— привести схемы отношения к 1НФ;

— определить функциональные зависимости между не ключевыми атрибутами и первичным ключом;

— определить частичные функциональные зависимости;

— осуществить декомпозицию (деление) соответствующих схем отношений для удалений частичных функциональных зависимостей;

— увидеть транзитивные зависимости между не ключевыми атрибутами и первичным ключом;

— исключить транзитивные зависимости путем декомпозиции соответствующих схем отношений.

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

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

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

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

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

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

Метод «нисходящего» проектирования достаточно формализован и используется в CASE (Computer Aided System /Software Engineering — компьютерное проектирование программного обеспечения и систем) средствах. Проведение тщательного анализа предметной области, выявление всех присущих ей классов объектов и связей между ними, правильное их отображение в ИЛМ предметной области, ведет к получению высоко нормализованной схемы логической структуры реляционной БД.

Для того чтобы сравнить эти два метода, используемых для проектирования реляционных баз данных, необходимо понимать, что при использовании «восходящего» метода проектирования сразу формируется схема БД. Термины реляционной модели (схемы отношений) не предусматривают возможность описания полного смысла (семантики) предметной области. Неправильное отображение в даталогической модели БД сути предметной области приводит к ошибкам в последующей работе АИС. Установлено, что цена ошибки (стоимость исправления) быстро возрастает с увеличением интервала времени (технологического времени: числа выполненных операций между двумя событиями) между появлением погрешности и её обнаружением. В литературе по базам данных приводятся такие цифры: на интервале от выработки требований на программу до сдачи программного продукта заказчику стоимость расходов на исправление ошибки возрастает в среднем в 80 раз. Большая цена ошибки определяет необходимость тщательной проработки проекта.

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

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

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

— реальный мир или объектную систему;

— информационную сферу;

— даталогическую сферу.

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

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

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

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

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

— анализ предметной области, выявление классов объектов и связей между ними (формирование внешнего уровня БД);

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

— концептуальное даталогическое проектирование. На основе ИЛМ в терминах выбранной модели данных строится концептуальная даталогическая модель (ДЛМ) БД (формирование концептуального уровня БД);

— преобразование ДЛМ в физическую модель БД, полученную на ЯОД выбранной СУБД (формирование внутреннего уровня БД).

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

Помимо этих подходов, для проектирования БД могут применяться другие методы. Например, известен метод "изнутри наружу". Он похож на метод «восходящего» проектирования, но отличается от него начальной идентификацией набора основных классов объектов с последующим расширением круга рассматриваемых классов объектов, связей и свойств, которые взаимодействуют с первоначально определенными классами объектов. Известен также подход "смешанной стратегии" — сначала «восходящий» и «нисходящий» методы используются для разных частей модели, после чего все подготовленные фрагменты собираются в единое целое.

2.5 CASE − технологии

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

CASE —средства классифицируются по методологиям проектирования (структурно—ориентированные, объектно—ориентированные, комплексно—ориентированные), по графическим нотациям построения диаграмм, по степени интегрированности (отдельные локальные средства, набор интегрированных средств, охватывающих большинство этапов разработки АИС), по режиму коллективной разработки проекта (режим реального времени, режим объединения проектов) и ряду других. Современный рынок программных средств насчитывает около 300 различных CASE − средств, наиболее популярные приведены в таблице 2.

Таблица 2 – CASE − средства, используемые для проектирования БД.

Название CASE —средства	Фирма—производи—тель	URL
Erwin	Computer Associates	http://www.cai.com/products/alm/erwin.htm
Designer 2000/ Designer 6i	Oracle	http://www.oracle.com/tools/designer
Power Designer	Sybase	http://www.sybase.com/products/designtools/powerdesigner
ER/Studio	Embarcadero Technologies	http://www.embracadero.com/products/Design/erdatasheet.htm
Visio Enterprise	Microsoft	http://www.microsoft.com/office/visio

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

Дата добавления: 2014-11-29