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

Некоторые атрибуты не могут  иметь пустого значения.

Этап 2.6.2. Ограничения  для доменов атрибутов

Этап 2.6.3. Целостность  сущностей

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

Этап 2.6.4. Ссылочная  целостность 

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

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

Случай 2. Удаление строки из дочернего отношения. При удалении строки из дочернего отношения никаких нарушений ссылочной целостности не происходит.

Случай 3. Обновление внешнего ключа в строке дочернего отношения. Этот случай подобен случаю 1.

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

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

NO ACTION. Удаление строки из родительского отношения запрещается, если в дочернем отношении существует хотя бы одна ссылающаяся на нее строка.

CASCADE. При удалении строки из родительского отношения автоматически удаляются все ссылающиеся на нее строки дочернего отношения.

SET NOLL. При удалении строки из родительского отношения во всех ссылающихся на нее строках дочернего отношения в атрибут внешнего ключа записывается пустое значение.

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

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

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

Этап 2.6.5. Требования данного предприятия

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

Этап 2.6.6. Документирование всех ограничений целостности данных

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

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

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

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

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

Этап 3.1. Слияние локальных логических моделей  данных в единую глобальную модель данных

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

1. Анализ имен сущностей и их первичных ключей.
2. Анализ имен связей.
3. Слияние общих сущностей из отдельных локальных моделей.
4. Включение (без слияния) сущностей, уникальных для каждого локального представления.
5. Слияние общих связей из отдельных локальных моделей.
6. Включение (без слияния) связей, уникальных для каждого локального представления.
7. Проверка на наличие пропущенных сущностей и связей.
8. Проверка корректности внешних ключей.
9. Проверка соблюдения ограничений целостности.
10. Выполнение чертежа глобальной логической модели данных.
11. Обновление документации.

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

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

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

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

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

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

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

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

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

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

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

Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД

Этап 4.1. Проектирование таблиц базы данных в среде целевой  СУБД

Необходимо принять решение  о способе реализации таблиц базы данных. Это решение зависит от типа выбранной целевой СУБД. Таблицы  можно реализовывать с помощью  визуальных компонент СУБД или с  помощью SQL-запросов.

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

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

Этап 4.2. Реализация бизнес-правил предприятия в среде  целевой СУБД

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

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

Документирование  проекта реализации бизнес-правил

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

Этап 5. Проектирование физического представления базы данных

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

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

Понятие о системных ресурсах

Чтобы достичь высокой  производительности системы, разработчик  физического проекта базы данных должен решить, каким образом четыре основных компонента и оборудования (Оперативная память, Процессор, Дисковый ввод/вывод, Сеть) будут взаимодействовать между собой и как это повлияет на достигнутый уровень производительности.

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

Этап 5.1. Анализ транзакций

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

• Ожидаемая частота выполнения транзакций.
• Отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а также тип этого доступа (выборка, вставка, обновление или удаление). Для транзакций обновления необходимо установить атрибуты, значения которых будут обновляться, поскольку следует избегать использования этих атрибутов в структурах доступа (например, во вторичных индексах).
• Атрибуты, используемые хотя бы в одном из предикатов. Следует проанализировать, используются ли в предикатах шаблоны подстановки, поиск в пределах заданного диапазона или выборка по точному соответствию ключа. Все найденные атрибуты будут кандидатами на включение в структуры доступа.
• Атрибуты, которые при выполнении запросов будут использоваться для соединения двух или больше отношений. Эти атрибуты также являются кандидатами на включение в структуры доступа
• Ограничения, устанавливаемые на время выполнения транзакций.
• Атрибуты, используемые в любых предикатах критических по времени выполнения транзакций, имеют наивысший приоритет для включения в состав структур доступа

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

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

Этап 5.2. Выбор файловой структуры

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

• последовательные файлы (heap);
• хешированные файлы (hash);
• индексно-последовательные файлы (ISAM);
• двоичные деревья (В⁺-Тгее).