Концептуальное проектирование базы данных

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

Каждая локальная концептуальная модель данных состоит из следующих компонентов:

• типы сущностей;

• типы связей;

• атрибуты и домены атрибутов;

• первичные ключи;

• альтернативные ключи;

• ограничения целостности.

Определение типов сущностей

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

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

Определение типов связей

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

Установив связи, которые будут иметь место в создаваемой модели, необходимо определить кратность каждой из них. Если известны конкретные значения кратности или даже верхний или нижний предел этих значений, то данную информацию обязательно нужно зафиксировать в документации. После выявления необходимых связей требуется проверить, служит ли каждая связь в модели подлинным отображением зависимостей "реального мира". Кроме того, следует убедиться в том, нет ли в модели невыявленных дефектов типа "разветвление" и типа "разрыв". Как правило, в модели не должно быть сущностей, изолированных от всех прочих сущностей, поскольку в противном случае после привязки изолированной сущности к отношению на этапе 2.2 невозможно будет перейти к этому отношению с помощью средств доступа к базе данных. Известным исключением из этого правила является база данных с единственным отношением.

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

Определение атрибутов и связывание их с типами сущностей и связей

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

После выявления сущности (x) или связи (y) для получения необходимых сведений об атрибутах проще всего воспользоваться спецификацией требований и попытаться найти ответ на вопрос: "Какую информацию требуется хранить об x или y?" Ответ на этот вопрос необходимо также включить в текст спецификации. Важно отметить, что каждый атрибут может быть либо простым, либо составным. Составные атрибуты представляют собой набор простых атрибутов. Атрибуты могут подразделяться не только на простые или составные, но и рассматриваться как однозначные или многозначные. Чаще всего встречаются однозначные атрибуты, но при определенных обстоятельствах могут также встретиться и многозначные атрибуты; иными словами, атрибуты, которые включают несколько значений, соответствующих одному экземпляру сущности. Атрибуты, значения которых могут быть установлены с помощью значений других атрибутов, называются производными.

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

Каждому выявленному атрибуту следует присвоить осмысленное имя, понятное пользователям. О каждом атрибуте в документацию помещаются следующие сведения:

• имя атрибута и его описание;

• тип данных и размерность значения;

• все псевдонимы, под которыми упоминается атрибут;

• информация о том, является ли атрибут составным и, если это так, из каких простых атрибутов он состоит;

• информация о том, является ли атрибут многозначным;

• информация о том, является ли данный атрибут производным и, если это так, какой метод используется для вычисления его значения;

• значение, принимаемое для атрибута по умолчанию (если таковое имеется).

Определение доменов атрибутов

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

• набор допустимых значений для атрибута;

• сведения о размере и формате каждого из атрибутов.

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

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

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

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

При выборе первичного ключа среди нескольких потенциальных руководствуйтесь приведенными ниже рекомендациями:

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

• Используйте тот потенциальный ключ, вероятность изменения значений которого минимальна;

• Используйте потенциальный ключ, значения которого имеют минимальную длину (в случае текстовых атрибутов);

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

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

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

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

Обоснование необходимости использования понятий расширенного моделирования (необязательный этап)

На этом этапе предусмотрена возможность продолжить разработку ER-модели с помощью расширенных понятий моделирования, а именно уточнение/обобщение, агрегирование и композиция. Если будет решено провести уточнение, то в процессе разработки потребуется выявить различия между сущностями путем определения одного или нескольких подклассов суперкласса сущности. Подход, требующий обобщения, предусматривает необходимость выявить общие особенности разных сущностей для определения обобщающей сущности суперкласса. Агрегирование может применяться для обозначения связи "has-a" (включает) или "is-part-of" (входит в состав) между типами сущностей; в такой связи одна сущность представляет "целое", а другая — ее "часть". Композиция (особый тип агрегирования) может применяться для определения взаимосвязи между типами сущностей, которая обусловливает строгую принадлежность и совпадение срока существования между "целым" и "частью". Невозможно дать точные рекомендации в отношении того, должны ли применяться при разработке ER-модели расширенные понятия моделирования, поскольку такое решение часто является субъективным и зависит от конкретных особенностей моделирования предметной области. В качестве удобного эмпирического правила можно указать, что при рассмотрении необходимости использования таких понятий следует вначале попытаться представить важные сущности и их связи на ER-диаграмме с максимально возможной точностью.

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

Проверка модели на отсутствие избыточности

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

1. Повторное исследование связей "один к одному" (1:1)

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

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

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

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

Например, рассмотрим ситуацию, при которой моделируются связи между сущностями Man (Мужчина), Woman (Женщина) и Child (Ребенок), как показано на рисунке

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

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

• Отец и мать могут быть не женаты или отец может быть женат на ком-то другом, а не на матери (или мать может быть замужем за кем-то другим, кто не является отцом).

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

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

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

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

1. Описание транзакции

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

3. Проверка с применением путей выполнения транзакций

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

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

Прежде чем завершить первый этап разработки, необходимо обсудить созданные локальные концептуальные модели данных с конечными пользователями. Концептуальная модель данных должна быть представлена ER-диаграммой и сопроводительной документацией, содержащей описание разработанной модели данных. Если в предложенной модели будут обнаружены какие-либо несоответствия, следует внести в нее необходимые изменения (скорее всего, для этого потребуется повторно выполнить один или несколько предыдущих этапов разработки). Этот процесс должен продолжаться до тех пор, пока пользователь не подтвердит, что предложенная ему модель полностью соответствует рассматриваемой предметной области.