4. Проектирование реляционных баз данных

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

1) Создание концептуальной модели бд.

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

2) Создание логической модели бд.

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

Для описания схемы базы данных на логическом уровне проектирования служит диаграмма “сущности-связи” (Entity-Relationship diagram или ER‑diagram). Существуют различные варианты диаграмм “сущности-связи”. Способы изображения элементов ER-диаграмм стали называть нотациями. На них одни и те же элементы графически изображаются по-разному. Известны нотация Мартина, нотация IDEF1X и др. Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. Все варианты диаграмм “сущность-связь” исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

3) Создание физической модели бд.

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

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

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

1) Создание концептуальной модели БД

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

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

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

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

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

2) Создание логической модели БД

Выделим основные информационные объекты, информацию о которых будет храниться в базе данных, атрибуты этих объектов и связи между объектами. Логическую модель представим в виде диаграммы «сущности-связи» в нотации IDEF1X (рис.1).

Рис. 1. Логическая модель БД

3) Создание физической модели БД

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

Рис. 2. Физическая модель БД