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

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

Основные задачи проектирования баз данных

Основные задачи:

• Обеспечение хранения в БД всей необходимой информации.

• Обеспечение возможности получения данных по всем необходимым запросам.

• Сокращение избыточности и дублирования данных.

• Обеспечение целостности базы данных

Основные этапы проектирования баз данных

Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

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

Нормализация

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

Модели «сущность-связь»

Основная статья: ER-модель данных

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

Основные преимущества ER-моделей:

• наглядность;

• модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

• ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

• объекты (сущности);

• атрибуты объектов;

• связи между объектами.

Сущность — объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

• типом связи (1:1, 1:N, N:М);

• классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.

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

• Система управления базами данных (СУБД) — это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по модели данных.

• Требования к базам данных

• К современным базам данных, а следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования.

• 1. Высокое быстродействие (малое время отклика на запрос).

• Время отклика - промежуток времени от момента запроса к БД до фактического получения данных. Похожим является термин время доступа -промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их. Часто операции записи, удаления и модификации данных называют операцией обновления.

• 2. Простота обновления данных.

• 3. Независимость данных.

• 4. Совместное использование данных многими пользователями.

• 5. Безопасность данных - защита данных от преднамеренного или

• непреднамеренного нарушения секретности, искажения или разрушения.

• 6. Стандартизация построения и эксплуатации БД (фактически СУБД).

• 7. Адекватность отображения данных соответствующей предметной области.

• 8. Дружелюбный интерфейс пользователя.

• Жизненный цикл БД

• Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле бд является создание единой базы данных и программ, необходимых для ее работы. Жизненный цикл системы базы данных определяет и жизненный цикл всей информационной системы организации, поскольку база данных является фундаментальным компонентом информационной системы.

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

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

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

• На этапе физического проектирования решаются вопросы, связанные с производительностью системы, определяются структуры хранения данных и методы доступа

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

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

• Использование ненормализованных таблиц может привести к нарушению целостности данных (непротиворечивости информации) в базе данных.

• Рассмотрим проблемы, которые возникают при работе с ненормализованными данными. Рассмотрим таблицу СОТРУДНИКИ, которая имеет следующие атрибуты:

• ¡ Избыточность данных

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

• Нормальные формы

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

Код сотрудника	ФИО	Должность	Проекты
1	Иванов Иван Иванович	Программист	ID: 123; Название: Система управления паровым котлом; Дата сдачи: 30.09.2011 ID: 231; Название: ПС для контроля и оповещения о превышениях ПДК различных газов в помещении; Дата сдачи: 30.11.2011 ID: 321; Название: Модуль распознавания лиц для защитной системы; Дата сдачи: 01.12.2011

• Легко заметить, что не все атрибуты этого отношения атомарны (неделимы). В частности, атрибут «Проекты» можно разделить на три более простых атрибута: «Код проекта», «Название», «Дата сдачи», а значение

• ¡ Первая нормальная форма

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

• ¡ Вторая нормальная форма

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

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

• В нашем примере для приведения таблицы СОТРУДНИКИ ко второй нормально форме ее следует разделить на две таблицы. Первичный ключ исходной таблицы. состоит из двух атрибутов — Код сотрудника и Должность. Все же личные данные о сотрудниках зависят только от атрибута Код сотрудника. Атрибуты, соответствующие этим данным, выделим в качестве одной из таблиц, которую назовем ФИЗИЧЕСКИЕ ЛИЦА. Информацию о их должностях и зарплате вынесем в другу таблицу, которой присвоим имя СОТРУДНИКИ. Полученные две таблицы связаны между собой по полю Код физического лица, которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом

• для таблицы СОТРУДНИКИ. Данное поле отсутствовало в исходной таблице и было добавлено при проведении нормализации.

• ¡ Третья нормальная форма

• Рассмотрим таблицу СОТРУДНИКИ, полученную после приведения исходной таблицы ко-второй нормальной форме. Для этой таблицы существует функциональная зависимость между полями Код сотрудника и Зарплата. Однако эта функциональная связь является транзитивной.

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

• Приведем рассматриваемую в качестве примера базу данных к третьей нормальной форме. Для этого разделим таблицу СОТРУДНИКИ на две таблицы: СОТРУДНИКИ и ДОЛЖНОСТИ.

• Новый атрибут Код должности, который является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отношения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет получить таблицы с простыми первичными ключами, что облегчает выполнение операции связывания таблиц. Такие первичные ключи, как правило, являются искусственными.

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