Модели баз данных на логическом и физическом уровнях

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

Одной из наиболее распространенных универсальных программ для проектирования БД является erwin Data Modeler (DM) [6]. С помощью erwin DM можно выполнить проектирование БД на логическом и физическом уровнях, а также создать ее на сервере.

Erwin DM поддерживает прямое подключение к наиболее распространенным СУБД, таким как DB2, MySQL, Oracle Database, MS SQL Server и др. С остальными СУБД, в частности Firebird, он работает через промежуточный драйвер ODBC (Open Database Connectivity, программный интерфейс доступа к БД).

На логическом уровне проектирование выполняется путем выделения сущностей (Entity), атрибутов сущностей (Attribute) и взаимосвязей между сущностями. Модель «сущность-связь» (Entity-Relationship Model, или ER-модель) была разработана П. Ченом в 1976 г. с целью упрощения задачи проектирования БД [4]. Логическая модель не зависима от особенностей физической реализации объекта. На рис. 1.4 представлены отношения между всеми сущностями учебной БД в виде модели на логическом уровне.

Рис. 1.4. Модель учебной БД на логическом уровне

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

При этом следует учесть, что если erwin DM работает с СУБД не напрямую, а через ODBC-драйвер, то при переходе с логического на физический уровень некоторые типы данных, генерируемые erwin DM, могут неточно соответствовать типам данных конкретной СУБД. Например, при моделировании учебной БД столбец Executed таблицы Request на логическом уровне имеет тип данных BOOLEAN (домена Number в erwin DM), но при переходе на физический уровень для столбца генерируется тип данных BIT (численный тип данных, принимающий значения 1 или 0), хотя в СУБД Firebird определен логический тип данных BOOLEAN.

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

Рис. 1.5. Модель учебной БД на физическом уровне

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

Опция NOT NULL, указанная при описании столбца, накладывает ограничение, согласно которому в данном столбце недопустимо хранение неопределенных (неизвестных) значений.

Указанное в определении столбца обозначение (FK) свидетельствует о том, что данный столбец является внешним ключом, т. е. ссылается на родительскую таблицу и может содержать только те значения, которые имеются в первичном ключе родительской таблицы.

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

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

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >