Доклад "Проектирование баз данных, его этапы и задачи"

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПРАВОСУДИЯ»

РЕФЕРАТ

по дисциплине       Информационные технологии в деятельности суда

«Проектирование баз данных, его этапы и задачи»

Москва, 2021

СОДЕРЖАНИЕ

ВВЕДЕНИЕ .................................................................................................................3

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

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

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

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

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

ЗАКЛЮЧЕНИЕ .........................................................................................................12

СПИСОК ЛИТЕРАТУРЫ.........................................................................................13

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

Проектирование баз данных под конкретную вычислительную среду или информационную технологию (архитектура «клиент-сервер», параллельные архитектуры, распределённая вычислительная среда).

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.2

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

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

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

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

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

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

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

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

Рис. 3.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принять решение о способе поддержки ссылочной целостности в базе данных. Эта задача решается в четыре этапа:

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

Если необходимо, построить представления внешней схемы базы данных.

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Корнеев В.В., Гараев А.Ф., Васютин С.И., Райх В.В. Базы данных. Интеллектуальная обработка информации – М.: Нолидж, 2000
2. Туманов В.Е. Основы проектирования реляционных баз данных. – БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007