Легкость разработки и сопровождения базы данных

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

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

Нормализация и ее необходимость

Основной пример

Рассмотрим в качестве предметной области, как и ранее, «Университет». Модель предметной области опишем следующим неформальным текстом:

–Сотрудники университета читают дисциплины;

–Дисциплины состоят из нескольких видов занятий;

–Каждый сотрудник может читать одну или несколько дисциплин, или временно не читать (что бывает крайне редко);

–Каждую дисциплину может вести несколько сотрудников (разные виды занятий), или временно/на всегда дисциплину исключают из учебного плана, тогда ее не ведет никто из сотрудников.

–Каждое занятие ведет ровно один сотрудник;

–Каждый сотрудник принадлежит одной кафедре;

–Каждый сотрудник имеет телефон, находящийся на кафедре сотрудника.

В ходе дополнительного уточнения того, какие данные необходимо учитывать, можно выделить следующее:

–О каждом сотруднике необходимо хранить табельный номер и фамилию. Табельный номер является уникальным для каждого сотрудника.

–Каждая кафедра имеет уникальный номер;

–Каждая дисциплина имеет номер и наименование. Номер проекта дисциплины является уникальным;

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

Таблица 30

Первоначальная таблица отношения «Университет» (универсальная таблица)

Caf (pk)	Phone	Disp (pk)	Cat (pk)	FIO	Tab_N_S
ВТ		САПР	ЛК	Ланцов В.Н.
ВТ		САПР	ПР	Мамаев А.А
ВТ		АрхЭВМ	ЛК	Буланкин В.Б.
ВТ		АрхЭВМ	КП	Буланкин В.Б.
ИСИМ		ЗИ	ЛК	Алешкин А.А.
ИСИМ		ЗИ	ЛБ	Алешкин А.А.
ИЗИ		Инф-ка	ПР	Алешкин А.А.

 

Аномалии при работе с таблицами

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

Т.о. при работе с универсальными таблицами есть существенная проблема - Проблема избыточности данных. Т.е. данные практически всех столбцов многократно повторяются. Это видно;

Как следствие этой проблемы выделяется 3 аномалии

Аномалии вставки (INSERT)

В отношение «Университет » нельзя вставить данные о сотруднике, который пока не ведет ни одну дисциплину (занятие). Действительно, если, например, на кафедре «ИЗИ» появляется новый сотрудник, Пушкин, и он пока не читает ни одну дисциплину, то мы должны вставить в отношение кортеж <ИЗИ, 317442,, null, null, Пушкин>. Это сделать невозможно, т.к. атрибуты Caf, Disp, Cat входит в состав потенциального ключа, и, следовательно, не может содержать null-значений.

Точно также нельзя вставить данные о новой кафедре.

Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о дисциплинах, и о видах занятий).

Вывод - логическая модель данных неадекватна модели предметной области. БД, основанная на такой модели, будет работать некорректно.

Аномалии обновления (UPDATE)

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

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

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

Аномалии удаления (DELETE)

При удалении некоторых данных может произойти потеря другой информации. Например, если закрыть кафедру "ИСИМ" и удалить все строки, в которых она упоминается, то будут потеряны все данные о дисциплине «ЗИ» и частично о сотруднике «Алешкине» и т.п.

Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о дисциплинах, и о кафедрах).

Вывод - логическая модель данных неадекватна модели предметной области. БД, основанная на такой модели, будет работать неправильно.

Теория нормализации

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

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

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

Основа нормализации – аппарат нормализации отношений.

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

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

Формы нормализации:

• первая нормальная форма (First Normal Form – 1NF);
• вторая нормальная форма (Second Normal Form – 2NF);
• третья нормальная форма (Third Normal Form – 3NF);
• нормальная форма Бойса-Кодда (Boice-Codd Normal Form – BCNF);
• четвертая нормальная форма (Fourth Normal Form – 4NF);
• пятая нормальная форма или нормальная форма проекции-соединения (Fifth Normal Form – 5NF или PJ/NF);

Теория нормализации основывается на наличии той или иной зависимости между атрибутами отношения.

Виды зависимостей:

Функциональные зависимости

Для устранения указанных аномалий (а на самом деле для правильного проектирования модели данных!) применяется метод нормализации отношений. Нормализация основана на понятии функциональной зависимости атрибутов отношения^

1) Пусть R - отношение. Множество атрибутов Y функционально зависимо от множества атрибутов X (X функционально определяет Y) тогда и только тогда, когда для любого состояния отношения R для любых кортежей r1,r2Î R из того, что r1X=r2X следует что r1Y=r2Y (т.е. во всех кортежах, имеющих одинаковые значения атрибутов X, значения атрибутов Y также совпадают в любом состоянии отношения R). Символически функциональная зависимость записывается X ® Y.

Замечание. Если атрибуты X составляют потенциальный ключ отношения R, то любой атрибут отношения R функционально зависит от X.

Пример. В отношении Университет можно привести следующие примеры функциональных зависимостей:

{Caf} ® Phone

{ Disp } ® Cat

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

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

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