Модели и проектирование баз данных

Характеристика процесса проектирования


. Процесс проектирования БД включает три основных этапа:

·

проектирование концептуальной модели (логического макета БД);

·  проектирование внутренней модели (физического макета);

·  проектирование внешних моделей (локальных представлений данных для различных конечных пользователей).

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

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

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

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

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

Требования конечных пользователей меняются со временем. Может возникнуть потребность в данных, хранение которых не предусмотрено. Может исчезнуть необходимость хранения каких-то данных. Могут измениться способы использования хранимых данных или правила бизнеса.
Все это приводит к необходимости изменения логического макета. Таким образом, процесс проектирования БД, условно изображенный на рис. 3.1, продолжается в течение всего периода жизни системы.



Рис. 3.1Этапы проектирования БД

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

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

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

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

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

Второй подход – семантический – изучим достаточно подробно. Его рекомендуется использовать для выполнения курсовых проектов.


Содержание раздела