Файл: Проектирование Баз Данных (Дисциплина «Базы данных»).pdf

Введение

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

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

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

Процесс проектирования базы данных охватывает несколько основных сфер.

Проектирование объектов базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных.

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

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

Известно, что база данных:

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

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

---

На выходе процесса проектирования базы данных формируются следующие результаты:

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

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

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

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

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

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

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

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

Сбор и анализ входных данных

Такими задачами являются:

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

---

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

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

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

• нормализация сущностей предметной области:
• получить список атрибутов сущности;
• определить функциональные зависимости (ФЗ) в сущности;
• определить детерминанты сущности;
• определить возможные ключи отношения, в частности, рассмотрев уникальный идентификатор сущности.
• выполнить нормализацию сущности (преобразовать сущность в отношение);
• для полученного отношения назначить первичные ключи;
• сформировать список кандидатов на внешние ключи, если необходимо;
• сформировать бизнес-правила поддержки целостности сущности, если необходимо;
• нормализация отношений логической модели базы данных:
• определить степень связи сущностей;
• определить класс принадлежности сущности к связи;
• нормализовать отношение (разрешить связи);
• назначить первичные ключи связывающих отношений, исходя из уникального идентификатора связи и процедуры миграции ключей при нормализации;
• определить атрибуты связывающих отношений, если необходимо;
• сформировать бизнес-правила поддержки целостности связей;
• проверка правильности логической модели реляционной базы данных:
• проверка отношений на соответствие нормальной форме Бойса-Кодда;
• проверка отношений на свойства соединения без потерь и сохранения функциональных зависимостей;
• предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;
• проверка на отсутствие незамкнутых связей;
• проверка на отсутствие одиночных отношений;
• формулировка части исходных данных для решения задачи управления ссылочной целостностью;
• документирование логической модели реляционной базы данных;
• принятие решения о реализуемости построенной логической модели реляционной базы данных;
• принятие решения о разработке физической модели реляционной базы данных.

---

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

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

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

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

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

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

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

---

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

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

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

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

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

На этом этапе проектирования физической модели реляционной базы данных проектировщик базы данных:

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

---