Файл: Проектирование баз данных, его этапы и задачи (Проектирование базы данных).pdf

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 05.07.2023

Просмотров: 57

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

1. Введение

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

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

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

В эксплуатации база данных и ее окружение должны удовлетворять набору требований по ряду укрупненных (интегрированных) параметров, таких как:

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

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

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

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

2. Проектирование базы данных

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

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


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

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

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

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

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

Типовая бизнес-модель процесса проектирования базы данных

Процесс проектирования базы данных может быть представлен в виде модели бизнес-процессов. Бизнес-модель процесса проектирования позволяет:

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

Рассмотрим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.

Контекстная диаграмма процесса проектирования базы данных

Как видно из рисунка, на вход процесса проектирования базы данных подаются:

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

Могут быть представлены и другие документы.

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


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

По требованию может быть разработана и другая документация.

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

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

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

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

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

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

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

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

3. Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных

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


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

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

В ходе контроля качества основными моментами деятельности являются контроль ER-диаграмм и контроль диаграмм функциональной

и состава команды проекта, объема проекта, проектных рисков и т.д.

4. Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных

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

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

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

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

Бизнес-модель процесса создания логической модели базы данных

. Бизнес-модель процесса нормализации сущности

Бизнес-модель процесса нормализации отношения

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

5. Бизнес-модель этапа проектирования - создание физической модели реляционной базы данных

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

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

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

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