35 Даталогическое проектирование базы данных.

Дисциплина «Базы данных»

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

В общем случае процесс проектирования на данном этапе состоит из двух шагов:

выбор подхода к моделированию данных;

проектирование логической схемы БД.

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

простота понимания и использования. Формализованное представление должно быть настолько простым, насколько это возможно.

должно иметь серьезную теоретическую основу;

эффективность реализации.

С точки зрения выполнения этих требований наиболее подходящим является реляционный подход. Реляционный подход является классическим в настоящее время.

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

Проектирование логической структуры РБД (реляционная база данных) предполагает:

разбиение всей информации по отношениям (таблицам);

определение состава полей (атрибутов) каждого отношения;

определение ключа каждого отношения;

определение связей и обеспечение целостности по связям.

Задача проектирования заключается в построении схем отношений. При формировании схем отношений учитываются такие характеристики атрибутов, как единичные или множественные, обязательность или необязательность данного атрибута (при генерации Null-значений), а также тип связи 1:1, 1:M, N:M , ее обязательность или необязательность. Общие правила получения реляционной схемы из ER-схемы.

Каждой простой сущности ставится в соответствие отношение (таблица). Имя сущности становится именем таблицы.

Каждый атрибут сущности становится атрибутом (столбцом) соответствующего отношения. Возможно переименование атрибутов. Для каждого атрибута задается допустимый тип и обязательность или необязательность атрибута.

Идентификатор сущности становится первичным ключом отношения. Первичный ключ всегда имеет свойство Not Null.

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

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

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

Разрешение связей «многие ко многим». Такие связи допустимы в модели «Сущность-связь» (ER), но большинство СУБД поддерживает только связи 1:M. Разрешение связей выполняется введением специального дополнительного «связующего» отношения. Атрибутами этого отношения являются первичные ключи связываемых отношений, и оно связано с каждым из исходных связью 1:M.