2.4. Проектирование бд

Проектирование БД – это «докомпьютерный» этап работы. На практике таблицы и система связей между ними могут быть достаточно сложными. Возможные варианты БД проще разобрать сначала на бумаге. Два последующих подраздела касаются этого этапа работы.

Проектирование таблиц и связей

Сначала укажем на недостаток приведенных выше таблиц «Жители» и «Машины». Предположим, пользователь хочет найти данные по человеку, относительно которого известна лишь фамилия. Однако указанные таблицы не позволяют создать запрос на отбор данных по условию вида «Значение «Фамилия» равно «Кулев»». Итак, общее правило: в качестве атрибутов объектов лучше выбирать неделимые далее (элементарные) атрибуты. То есть в указанных таблицах вместо поля «ФИО» лучше было использовать три «элементарных» поля «Имя», Фамилия», «Отчество». В учебных целях оставим таблицу «Жители» в прежнем виде.

Проектирование связей это, в первую очередь, выбор ключей таблиц. Так в таблице «Жители» (рисунок 1) могут повторяться ФИО жителей города, поэтому за ключ лучше взять первые два поля «Ф.И.О.» плюс, например, поле «адрес».

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

Все три приведенных выше таблицы «Жители», «Машины» и «Опрос» можно было бы свести в одну. Ключом у нее по-прежнему было бы поле «ФИО». С такой БД тоже можно было бы работать. Однако выполнение даже простых операций (то есть выполнение соответствующих запросов) при этом усложняется. Например, удаление данных только по машинам выполнить проще, если есть отдельная таблица «Машины». Обобщая, можно сказать, что подходящее разбиение таблиц упрощает создание эффективной СУБД. При этом ускоряется выполнение запросов, то есть увеличивается быстродействие СУБД. Другая причина разбиения таблиц – устранение избыточного дублирования информации [4]. Например, в «сводной» таблице «Жители» + «Машины» одно и то же значение «ФИО» может встречаться не один раз, так как один человек может иметь больше одной машины. В результате дублирования (повторения) данных неэкономно используется память компьютера. Это существенно, так на практике таблицы БД могут иметь тысячи или десятки тысяч записей.

Избыточное дублирование информации и его устранение разберем подробнее на примере таблицы «Сотрудники», изображенной на рисунке 7. В комнате может находиться несколько сотрудников, следовательно, в таблице будут повторяющиеся пары значений «комната-телефон». Эти значения можно представить с помощью отдельной таблицы. То же в общем случае: избыточное дублирование данных это такое дублирование данных, от которого можно избавиться разбиением таблицы на две или более таблиц. При этом, кроме экономии памяти, устраняется возможность некоторых ошибочных операций с данными (см. в [4] об ошибках (аномалиях) в БД, называемых аномалиями ввода, удаления и обновления).

фам.	имя	отчество	отдел	комната	телефон	разряд	оклад
Ива..	Фе..	Григо…	АХЧ	16	33-23-16	14	2300
Кам..	Ев..	Петро..	АХЧ	16	33-23-16	15	3000
……	….	…….	……	…	………..	….	…….

Рис. 7. Таблица «Сотрудники»

Для устранения избыточного дублирования данных и предотвращения аномалий таблицы БД приводятся к определенному виду – к так называемой третьей нормальной форме. Процедура приведения таблицы к такой форме называется нормализацией и состоит в разбиении таблицы на две и более. Сформулируем алгоритм нормализации таблицы 5. Он имеет три шага:

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

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

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

а) Для таблицы выполняется условие пункта 1, то есть она в 1-й НФ;

б) Будем различать ключевые поля (входящие в ключ) и не ключевые (не входящие в ключ). Должно выполняться условие: значение не ключевого поля зависит от всего ключа, а не от его части. Пусть в таблице «Сотрудники» за ключ взяты поля «фамилия», «имя», «отчество» и поле «комната». Тогда сформулированное условие не выполняется: номер телефона определяется номером комнаты (считаем, что в комнате один телефон). Таблица должна быть разбита на две. А именно, зависимые поля нужно вынести в отдельную таблицу (назовем ее «Комнаты»):

фамилия	имя	отчество	отдел	комн	разряд	оклад		комн	телефон
			АХЧ	1	14	2300		1	33-23-16
			АХЧ	1	15	3000		2	33-23-00
…	…	………	……	…	15	3000		…	………

Рис. 8. Таблицы «Сотрудники» и «Комнаты»

В таблице «Комнаты» поле «комната» ключевое. Поэтому связь между получившимися таблицами нужно задавать по полю «комната». Таблица «Комнаты» будет главной. Обоснуем это примером. Если комнаты 1 и 2 объединили и устроили там столовую, то нужно:

– Удалить первые две строки из «Комнаты».

– Из таблицы «Сотрудники» нужно удалить все строки, касающиеся комнат 1 и 2. Добавить записи, в которых будут указаны другие комнаты для сотрудников, находившихся в 1-й и 2-й.

Однако обратное неверно: удаление записи из «Сотрудники» (например, сотрудник уволился или переселился в другую комнату) не сопровождае6тся удалением записи из «Комнаты».

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