Подходы к проектированию баз данных

Этап 1.1. Определение  типов сущностей 

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

Этап 1.1.1. Выявление  типов сущностей

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

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

Этап 1.1.2. Документирование типов сущностей

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

Этап 1.2. Определение типов связей

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

Этап 1.2.1. Определение  связей

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

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

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

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

Этап 1.2.3. Документирование типов связей

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

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

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

Самым простой метод выделения  атрибутов — после идентификации  очередной сущности или связи  в некоторой спецификации задать себе следующий вопрос: "Какую  информацию требуется хранить о...". Ответ на этот вопрос надо искать в  тексте спецификации. В некоторых  случаях может оказаться полезным попросить пользователей уточнить их требования.

Этап 1.3.1. Выявление  простых и составных атрибутов

Выбор способа представления  составного атрибута в виде простого или составного атрибута определяется требованиями, предъявляемыми к приложению пользователем.

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

Этап 1.3.2. Выявление  производных атрибутов

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

Этап 1.3.3. Документирование атрибутов

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

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

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

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

Этап 1.4.1. Определение  доменов

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

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

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

Этап 1.4.2. Документирование доменов атрибутов

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

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

Этап 1.5.1. Определение  потенциальных ключей

Для некоторых сущностей  возможно наличие нескольких потенциальных  ключей.

Этап 1.5.2. Выбор  первичного ключа

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

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

Этап 1.5.3. Документирование первичных и альтернативных ключей

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

Этап 1.6. Специализация или генерализация  типов сущностей (необязательный этап)

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

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

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

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

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

 

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

 

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

Этап 2. Построение и проверка локальной  логической модели данных для отдельных  представлений каждого из типов  пользователей 

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

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

1. Удаление связей типа M:N.
2. Удаление сложных связей.
3. Удаление рекурсивных связей.
4. Удаление связей с атрибутами.
5. Удаление множественных атрибутов .
6. Перепроверка связей типа 1:1.
7. Удаление избыточных связей.

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

Связи, которые сущность имеет с другими типами сущностей, представляются с помощью механизма  первичных и внешних ключей. Для  принятия решения о том, откуда взять  и куда поместить значения атрибута(ов) внешнего ключа, предварительно следует установить, какая из участвующих в связи сущностей является родительской, а какая — дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее дочернюю сущность, где эти значения будут играть роль внешнего ключа. Операции пересылки внешних ключей проверяются для связей 1:1, 1:М, суперклассподкласс

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

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

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

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

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

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

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

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

Создание окончательного варианта диаграмм "сущность-связь" (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.

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

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

Этап 2.6.1. Обязательные данные