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

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

Проектирование состоит из трёх основных этапов:

1. Концептуальное проектирование
2. Логическое проектирование
3. Физическое проектирование

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

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

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

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

Этот процесс состоит из следующих этапов:

1. Определение объектов, сведения о которых отображаются в базе данных.
2. Определение связей между объектами.
3. Определение атрибутов объектов.
4. Нормализация отношений.

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

Различают 3 типа связей между объектами таблицы:

1. Взаимосвязь «один к одному» () - каждому экземпляру одного типа объектов соответствует один и только один экземпляр другого объекта (такой тип встречается крайне редко).
2. Взаимосвязь «один ко многим» () - одному экземпляру родительского объекта соответствует несколько экземпляра второго (дочернего) объекта. Такой тип экземпляров является основным в реляционных моделях баз данных.

1. Взаимосвязь «многие ко многим» () - одному экземпляру одного объекта соответствует множество экземпляров второго объекта и наоборот. Такой тип взаимосвязи не допускается в реляционных базах данных и непосредственно реализуется путём введения дополнительного объекта.

Третий этап проектирования – определение атрибутов объекта. В состав атрибутов объекта должны быть включены:

1. Ключевые атрибуты, однозначно определяющие экземпляр объекта.
2. Ключи связанных объектов.
3. Не ключевые атрибуты, которые характеризуют объект.

Четвёртый этап проектирования БД – определение отношений и группировка атрибутов по отношению к базам данных – самый главный этап. Для этого используется нормализация отношений. Рассмотрим на примере. Пусть у нас имеются следующие отношения:

Ключом в данном отношении является совокупность атрибутов «Код преподавателя» и «Дисциплина».

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

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

Основными недостатками этой модели являются:

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

Причина указанных недостатков в том, что не все не ключевые атрибуты зависят от ключевых атрибутов. В этом примере атрибуты преподавателя «Фамилия», «Должность» не зависят от преподаваемой дисциплины и в таблице смешаны 2 типа информации: «Преподаватель» и «Дисциплина».

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

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

Однако и эта модель данных имеет ряд недостатков:

1. Невозможно добавить информацию о новой кафедре, пока в её штат не будет принят хотя бы один преподаватель.
2. При удалении сведений о преподавателе удаляются сведения о принадлежности кафедры к факультету. Т.е. удалив все сведения обо всех преподавателях, мы потеряем сведения о кафедре вообще.
3. При изменении зависимости «кафедра-факультет», т.е. преподаватель, например, перешёл работать на другой факультет, требуется просмотр всего отношения. А при переводя преподавателя на другую кафедру требуется обновить поле «Факультет».

Причина указанных недостатков в транзитивной зависимости атрибутов «Код преподавателя», «Кафедра» и «Факультет».

Если A, B, C – некоторые атрибуты отношения и A зависит от B, а B зависит от C? То говорят, что A транзитивно зависит от C.

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

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

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

Устранение избыточности сокращает объём базы данных и повышает эффективность работы системы, т.е. исключает не синхронный ввод данных.

Тема 3.

1. Дополнительные общие рекомендации по проектированию базы данных.

2. Разработка приложений в среде Microsoft Windows.