3.4 Логическое проектирование

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

На данном этапе выполняются следующие действия:

Замена всех связей на бинарные связи типа 1:n.
Анализ связей со степенью 1:1 и в случае, если их необходимость не найдет подтверждения, объединить соответствующие сущности в одну.
Анализ всех сущностей, чтобы исключить синонимы.
Анализ связей типа “суперкласс/подкласс”.
Анализ всех атрибутов в проекте; все неключевые атрибуты должны присутствовать не более чем в одной сущности.
Отслеживание уникальности связей.

Пример замены множественной связи, путём введения слабой сущности:

В концептуальной модели присутствует множественная связь:

исключаем множественную связь путём введения новой сущности «Мебель в комнате»:

Аналогично заменяются все связи m:n на связи1:n.

3.5 Генерация отношений

Следующим этапом проектирования модели базы данных является генерирование отношений, которое производится на основании построенной логической модели (см. Приложение 2).

Выделим, исходя из полученных сущностей, следующие отношения:

R₁ (Комната) = {Номер комнаты, Номер общежития, Дата ревизии, Жилая площадь, Количество койко-мест}

R₂ (Общежитие) = {Номер общежития, Адрес общежития, Количество жилых комнат}

R₃ (Студент) = {Код студента, № комнаты, № общежития, ФИО, Пол, Группа, Домашний адрес, Текущий статус обучения, Форма обучения, Статус проживания}

R₄ (Документы) = {Код документа, Название документа}

R₅ (Твердый инвентарь) = {Инвентарный номер мебели, Наименование единицы мебели, Дата покупки}

R₆ (Мягкий инвентарь) = {Инвентарный номер белья, Наименование единицы белья}

R₇ (Мягкий инвентарь студента) = {Инвентарный номер белья, Код студента, Дата выдачи}

R₈ (Мебель в комнате) = {Инвентарный номер мебели, Номер комнаты, Номер общежития, Дата установки}

R₉ (Перечень документов) = {Код документа, Код студента}

R₁₀ (Ревизия) = {Дата ревизии, ФИО ревизора}

3.6 Нормализация отношений

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

Отношение находится в НФБК, если оно находится в первой нормальной форме (1НФ) и каждый детерминант является возможным ключом или ключом является вся схема отношения.

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

Декомпозиция до НФБК осуществляется на минимальном покрытии.

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

В исходном отношении выявляются множества возможных ключей и детерминантов.

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

Если выделенные множества ключей и детерминантов не эквивалентны, то в отдельное отношение выделяется крайняя ФЗ; если после этого множества ключей и детерминантов оказываются эквивалентными, то декомпозиция завершается, иначе декомпозиция продолжается.

R₁ (Комната) = {Номер комнаты, Номер общежития, Дата ревизии, Жилая площадь, Количество койко-мест}

F_min = {Номер комнаты, Номер общежитияДата ревизии,Жилая площадь, Количество койко-мест}