Методология логического проектирования

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

1)проверка построения локальной логической модели данных для отдельного представления каждого юзера

2)создание и проверка глобальной логической модели данных

Первый этап включает в себя следующее:

•преобразование локальной концептуальной модели в локальную логическую модель

•определение номера отношений, исходя из структуры локальной логической модели

•проверка модели с помощью правил нормализации

•проверка модели в отношении транзакций юзера

•создание диаграммы «сущность — связь»

•определение требований поддержки данных

•обсуждение локально логической модели с конечными пользователями

Для (1) необходимо удалить связи N:M, затем удалить сложные связи, рекурсивные связи, связи с атрибутами, множественные связи, перепроверить отношения 1:1 и удалить избыточные связи.

Связь N:M заменяется на две связи типа 1:N, введением дополнительной сущности в модели данных.

Пример: Газета печатает объявления об объектах, сдающихся в аренду.

Чтобы исключить M:N, необходимо ввести новую слабую сущность «объявление».

Сложными связями называются связи, которые существуют между тремя и более сущностями. Сложные связи заменяют необходимым количеством бинарных связей 1:N, кот устанавливаются с вновь введенными сущностями. Пример тройной связи — связь сдача в аренду. Здесь устанавливается отношение между сущностями работник – комната, объект аренды, арендатор. Чтобы исключить тройную связь, необходимо ввести сущность соглашение.

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

В КМ присутствуют связи, которые имеют собственные атрибуты например имеется сущность «работник», сущность «отдел». Между ними существует связь «работает в». Она имеет атрибут «количество отработанных часов», устраняется введением новой сущности.

Важным является перепроверка связей 1:1. Могут быть созданы две сущности представляющие один и тот же объект. Их необходимо объединить в одну сущность.

Удаление избыточных связей – это связи, в которых одна и та же информация может быть получена с помощью других связей. Определение номера отношений для каждой сильной сущности в лок ЛМ создает отношение. Если в отношении необходимо включить составной атрибут, то их разбивают на простые атрибуты. Для каждой слабой сущности создаются отношения. В отношении включают атрибут, который является внешним ключом. Внешний ключ соответствует первичному ключу сущности владельца. Первичный ключ слабой сущности полностью или частично выводит из сущности владельца. Если сущность участвует в связи 1:1, то выбор родителя или дочерней сущности производится произвольно. Если сущности участвуют в других связях их лучше объединить в одно отношение. Обязательной является проверка модели с помощью правил нормализации. Нормализация отношений позволяет повысить устойчивость проекта и избавить от аномалий обновл. В процессе нормализации соблюдается компромисс между фрагментацией данных и быстродействием.

Процесс нормализации включает четыре этапа:

1)1 НФ: устранение повторяющихся атрибутов

2)2 НФ: устранение частично зависимых атрибутов от первичного ключа

3)3 НФ: устранение транзитивной зависимости от первичного ключа

4)НФБК: устранение частично зависимых атрибутов от потенциального ключа

Проверка моделей в отношении транзакций юзера, необходимо проверить ЛМ на возможность транзакций перечень которых определяется в соответствии со спецификацией. Используя ER- диаграмму, словарь данных связи между первичными и вторичными ключами необходимо выполнить операции доступа к данным вручную. При не выполнении транзакций не обходимо искать ошибки: пропуск сущностей, атрибутов связей.

Используют два подхода к проверке ЛМ:

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

2) нанесение на ER – диаграмму всех путей, прохожд. которых требуется для выполнения транзакций.

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

Если в модели существует область, кот. не используется для выполнения транзакций, то возникает вопрос о целесообразности предст. Этой информации в модели. Все предшествующие этапы по построению лог. Модели позволяют вводить новые сущности, связи, атрибуты либо исключать избыточную информацию. Следующим шагом явл. создание окончательного варианта ER-диаграммы. Это б. лок. логическое представление данных, исп-я отдельными пользователями. Треб-ся поддержка целостности данных. Необх. б. определить ограничения, которые предостав. польз-ми с целью сохр. Целостности данных. На этом этапе вопрос поддержки целостности данных конкретной СУБД рассм. не будет.

Ограничения целостности данных:

1)обязат. данные; 2) ограничения для доменов атрибутов; 3) целостность сущностей; 4) ссылочная целостность; 5) требования данного предприятия

(1)– некоторый атрибут должен содержать 1 из допустимых значений, т.е. атрибут не может иметь пустого значения. Эти сведенья должны заноситься в словарь данных.

(2) - каждый атрибут имеет домен, который представляет набор его допустимых значений. Пример: Пол(атр), домен состоит из двух символьных строк длиной в 1 символ.

(3)-Первичный ключ любой сущности не может содержать 0 значен. Это должно учитываться при определении первичного ключа каждой сущности.

(4)-Понятие ссылочной сущности означает: если внешний ключ содержит некоторое значение, то оно должно присутствовать в потенциальном ключе одной из строк родит. отношения. При создании ссылочной целостности следует проверять, допустимо ли использование пустого значения во внешнем ключе.

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

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

•Каждое хранилище данных должно представлять все множество сущностей

•Атрибуты, которые используются в потоке данных должны принадлежать сущности того или иного типа

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