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

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

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

- Удаление связей типа M:N.

- Удаление сложных связей.

- Удаление рекурсивных связей.

- Удаление связей с атрибутами.

- Удаление множественных атрибутов.

- Перепроверка связей типа 1: 1.

- Удаление избыточных связей.

- Документирование отношений (например, при помощи DBDL, см. ниже).

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

- Проверка модели в отношении транзакций пользователей.

- Создание диаграмм "сущность-связь".

- Определение требований поддержки целостности данных.

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

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

- Проверка возможностей расширения модели в будущем.

- Создание окончательного варианта диаграммы «Сущность-связь».

Если в концептуальной модели присутствуют связи типа M:N ("многие ко многим"), то их следует устранить путем определения некоторой промежуточной сущности. Связь типа M:N заменяется двумя связями типа 1:М, устанавливаемыми со вновь созданной сущностью.

Сложной называется связь, существующая между тремя и больше типами сущностей, см. рисунок ниже.

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

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

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

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

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

Поэтому на данном этапе правильнее будет называть улучшенную локальную концептуальную модель локальной логической моделью данных.

Документирование состава отношений, созданных на базе каждой из логических моделей данных, осуществляется на языке DBDL (Database Definition Language), широко используемым в реляционных СУБД.

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

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

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

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

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

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

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

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

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

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

Ограничения для доменов и атрибутов – каждый атрибут имеет домен, представляющий собой набор его допустимых значений. Например, атрибут "пол" может содержать одно из двух допустимых значений - "М" или "Ж", поэтому его домен состоит из двух символьных строк длиной в один символ, содержащих указанные значения.

Целостность сущностей – первичный ключ любой сущности не может содержать пустого значения и должен быть уникальным.

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

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

Логическая модель данных отображает структуру сохраняемых данных предприятия. Диаграмма потоков данных (Data Flow Diagram - DFD) отображает перемещение данных в пределах предприятия и помещение их в хранилища информации. Все атрибуты, которые сохраняются на предприятии, должны быть объявлены в одном из типов сущностей и, вероятно, найти свое место в потоках данных, перемещающихся в пределах предприятия. Если обе эти технологии используются для моделирования требований пользователей, каждая из них может применяться для контроля согласованности и полноты другой.

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