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

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

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

1. Концептуальное проектирование

2. Логическое проектирование

3. Физическое проектирование

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

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

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

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

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

1. Определение объектов, сведения о которых отображаются в базе данных.

2. Определение связей между объектами.

3. Определение атрибутов объектов.

4. Нормализация отношений.

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

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

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

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

Факультет

Кафедра

Преподаватель

Группа

Студент

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

Преподаватель

Студент

Преподаватель

Курсовая работа

Студент

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

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

2. Ключи связанных объектов.

3. Не ключевые атрибуты, которые характеризуют объект.

Объект	Атрибуты
Факультет	Код, наименование, ФИО декана, телефон…
Кафедра	Код, Код факультета, Наименование, ФИО зав. …
Преподаватель	Код, Код кафедры, ФИО, Должность …
Группа	Код, Код факультета, ФИО старосты, …
Студент	Код, Код группы, ФИО
Курсовая работа	Код преподавателя, код студента, тема

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

Нагрузка преподавателя по дисциплине
Код преподавателя	ФИО	Должность	Кафедра	Факультет	Дисциплина	Количество часов
001	Иванов	доцент	К1	Ф1	Д1	20
001	Иванов	доцент	К1	Ф1	Д2	10
002	Петров	профессор	К1	Ф1	Д3	30
003	Сидоров	доцент	К2	Ф2	Д4	22
004	Сидоров	доцент	К2	Ф2	Д5	24

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

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

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

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

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

2. При удалении информации о нагрузке, удаляется и вся информация из строки.

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

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

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

Преподаватель
Код преподавателя	Фио	Должность	Кафедра	Факультет
001	Иванов	доцент	К1	Ф1
002	Петров	профессор	К1	Ф1
003	Сидоров	доцент	К2	Ф2

Нагрузка по дисциплине
Код преподавателя	Дисциплина	Количество часов
001	Д1	20
001	Д2	10
002	Д3	30
003	Д4	22
004	Д5	24

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

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

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

2. При удалении сведений о преподавателе удаляются сведения о принадлежности кафедры к факультету. Т.е. удалив все сведения обо всех преподавателях, мы потеряем сведения о кафедре вообще.

3. При изменении зависимости «кафедра-факультет», т.е. преподаватель, например, перешёл работать на другой факультет, требуется просмотр всего отношения. А при переводя преподавателя на другую кафедру требуется обновить поле «Факультет».

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

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

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

Преподаватель
Код преподавателя	Фио	Должность	Кафедра
001	Иванов	доцент	К1
002	Петров	профессор	К1
003	Сидоров	доцент	К2

Кафедра
Кафедра	Факультет
К1	Ф1
К1	Ф1
К2	Ф2

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

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

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