2.2. нормализация файлов базы данных
2.2. нормализация файлов базы данных
Выше файлы рассматривались как своеобразные хранилища данных и связей между ними, причем было показано, что при соблюдении определенных правил эти файлы можно считать отношениями и применять к ним операции реляционной алгебры. Открытым пока остался вопрос о том, какие файлы хранить в БД и какие в них должны быть поля, чтобы иметь модель предметной области с определенными положительными свойствами.
2.2.1. Полная декомпозиция файла
Найдем две проекции ИФ:
ПФ1 = proj {ДЕЖУРСТВО, ОФИЦЕР] (ИФ);
ПФ2 = proj [ОФИЦЕР, ТЕЛЕФОН] (ИФ).
 |
Нетрудно убедиться, что соединение этих двух проекций образует исходный файл: ПФ1 ► 4 ПФ2 = ИФ.
Полной декомпозицией файла называется совокупность произвольного числа его проекций, соединение которых идентично исходному файлу.
Говоря о полной декомпозиции файла, следует иметь в виду два обстоятельства:
у одного и того же файла может быть несколько полных декомпозиций;
не всякая совокупность проекций файла образует его полную декомпозицию.
Для последнего примера найдем другую проекцию ИФ: ПФЗ = proj [ДЕЖУРСТВО, ТЕЛЕФОН] (ИФ).
В результате соединения ПФ2 и ПФЗ получим файл результата
ПФ2 ► Л ПФЗ = ФР Ф ИФ:
В ФР курсивом выделены записи, которых не было в исходном файле.
Методы анализа, позволяющие определить, образует ли данная совокупность проекций файла его полную декомпозицию, будут рассмотрены в п. 2.2.4.
Возможность нахождения полной декомпозиции файла ставит вопросы о том, в каколі виде хранить данные в БД? Дает ли декомпозиция файла какие-либо преимущества? В каких условиях эти преимущества проявляются и т. п.
2.2.2. Проблема дублирования информации
В некоторых случаях замена исходного файла его полной декомпозицией позволяет избежать дублирования информации.
Рассмотрим пример. Пусть в исходном файле (как и в примере в п. 2.2.1) хранятся данные о сотрудниках, дежуривших в составе оперативной группы управления предприятием (ДАТА — дата дежурства; ТЕЛЕФОН — рабочий телефон сотрудника).
ИФ
| ДАТА | СОТРУДНИК | ТЕЛЕФОН |
| 11.01 | Иванов | 3-12 |
| 15.01 | Сидоров | 4-21 |
| 24.01 | Сидоров | 4-21 |
| 30.01 | Сидоров | 4-21 |
| 1.02 | Иванов | 3-12 |
Рассмотрим две проекции файла:
ПФ1 = proj [ДАТА, СОТРУДНИК] (ИФ);
ПФ2 = proj [СОТРУДНИК, ТЕЛЕФОН] (ИФ).
Данные проекции образуют полную декомпозицию исходного файла. В ПФ2 номер рабочего телефона каждого сотрудника упоминается однократно, тогда как в ИФ — столько раз, сколько этот сотрудник заступал на дежурство. Очевидно, что для нашего примера разбиение ИФ на проекции позволяет избежать дублирования информации.
Устранение дублирования информации важно по двум причинам:
устранив дублирование, можно добиться существенной экономии памяти;
если некоторое значение поля повторяется несколько раз, то при корректировке данных необходимо менять содержимое всех этих полей, в противном случае нарушится целостность данных.
Для того чтобы найти критерий, позволяющий объективно судить о целесообразности использования полной декомпозиции файла с точки зрения исключения дублирования информации, воспользуемся понятием первичного ключа.
Напомним, что первичным ключом называют минимальный набор полей файла, по значениям которых можно однозначно идентифицировать запись. Если значение первичного ключа не определено, то запись не может быть помещена в файл БД.
Можно показать, что для нашего примера проекции
ПФ1 = proj [ДАТА, СОТРУДНИК] (ИФ);
ПФ2 = proj [ДАТА, ТЕЛЕФОН] (ИФ)
образуют полную декомпозицию ИФ, однако они не исключают дублирования информации.
Причина этого заключается в том, что обе приведенные проекции содержат первичный ключ исходного файла (таковым в рассмотренном примере является поле ДАТА, если, конечно, сотрудник не может одновременно находиться в двух и более оперативных группах).
Можно доказать, что дублирование информации неизбежно, если проекции, порождающие полную декомпозицию, содержат общий первичный ключ исходного файла.
Рассмотрим исходный файл:
ИФ
| FX | FY | FZ |
| X | У | z |
| х' | У | z |
две его проекции:
Для того чтобы вторая запись ИФ отличалась от первой (в противном случае имели бы в файле БД две одинаковые
ПФ1
| FX | FY |
| X | У |
| х' | У |
записи, что недопустимо), она формально должна быть представлена одним из семи вариантов:
(х у, z); (х, у', z); (х, у, z'); (х у', z); (х, y',z'); (х', у', z'); (х-, у, z').
Пусть FY — первичный ключ. Для того, чтобы дублирования информации не было, вторая запись ИФ должна быть или (х', у, z), или (х, у, z'), но это противоречит тому, что FY — первичный ключ. Следовательно, для того чтобы дублирования информации не было, необходимо исключить наличие первичного ключа исходного файла в проекциях, образующих его полную декомпозицию.
Другими словами, если существует такая полная композиция файла, которая образована проекциями, не имеющими первичного ключа исходного файла, то замена исходного файла этой декомпозицией исключает дублирование информации. Если же полная декомпозиция файла содержит проекции, имеющие общий первичный ключ исходного файла, то замена его полной декомпозицией не исключает дублирования информации.
2.2.3. Проблема присоединенных записей
Рассмотрим две проекции файла:
ПФ1 = proj [ДАТА, СОТРУДНИК] (ИФ);
ПФ2 = proj [СОТРУДНИК, ТЕЛЕФОН] (ИФ).
Рассмотрим уже использованный п. 2.2.2 пример. Пусть в исходном файле хранятся данные о сотрудниках, дежуривших в составе оперативной группы предприятия (ДАТА — дата дежурства; ТЕЛЕФОН — рабочий телефон офицера).
В ИФ поле ДАТА является ключом и не может быть пустым. Как поступить, если нужно запомнить фамилию и номер рабочего телефона нового сотрудника, который еще не дежурил (например, Смирнов с номером телефона 7-35)? Записать эти данные в ИФ.нельзя (первичный ключ не может быть пустым), но можно поместить эти сведения в проекцию ПФ2. При этом ПФ2 формально перестает быть проекцией ИФ, хотя соединение ПФ1 и ПФ2 дает исходный файл (без сведений о Смирнове).
Записи, вносимые в отдельные проекции исходного файла, называются присоединенными. Представление файла в виде его полной декомпозиции может позволить решить проблему присоединенных записей, но важно помнить, что соединение проекций ИФ может привести к их потере.
Целесообразность представления ИФ в виде полной декомпозиции с точки зрения решения проблемы присоединенных записей, как и проблемы дублирования информации, полностью определяется наличием или отсутствием в проекциях ИФ общего первичного ключа.
Пусть в ИФ БД хранятся данные о сотрудниках, исполняющих обязанности в дежурном расчете (НОМЕР_Р — номер в составе дежурного расчета; ТЕЛЕФОН — номер рабочего телефона).
Если считать, что один и тот же сотрудник не может исполнять обязанности нескольких номеров дежурного расчета, то в качестве первичного ключа можно использовать НОМЕРР. Полную декомпозицию исходного файла составляют проекции:
В качестве присоединенных записей можно рассматривать либо добавление нового номера дежурного расчета и фамилии сотрудника, либо нового номера расчета и телефона без указания фамилии сотрудника, однако эту информацию можно внести и в ИФ путем формирования записей типа
| НОМЕР Р | СОТРУДНИК | ТЕЛЕФОН |
| 4 | Семин |
|
| ИЛИ | ||
| НОМЕР_Р | СОТРУДНИК | ТЕЛЕФОН |
| 4 | Семин | 9-18 |
Таким образом, представление ИФ в виде проекций, содержащих общий первичный ключ исходного файла, не дает преимуществ с точки зрения решения проблемы присоединенных записей.
Обобщая сказанное, можно сформулировать общее требование к файлу, представление которого в виде полной декомпозиции не имеет смысла.
Говорят, что файл находится в пятой нормальной форме (5 НФ), если у него или нет ни одной полной декомпозиции, или нет ни одной полной декомпозиции, в которую входили бы проекции, не имеющие общего первичного ключа исходного файла.
Если файл не находится в 5 НФ, имеется возможность избежать дублирования информации и потерю присоединенных записей, переходя от исходного файла к такой его полной декомпозиции, которая образована проекциями, не содержащими первичный ключ. Если полученные таким образом файлы проекций не находятся в 5 НФ, то каждую из них можно заменить полной декомпозицией и т. д.
Процесс последовательного перехода к полным декомпозициям файлов БД называется нормализацией файлов БД, главная цель которой — исключение дублирования информации и потери присоединенных записей.
2.2.4. Функциональная зависимость полей файла
При обсуждении в предыдущих пунктах полной декомпозиции файла остался открытым вопрос о том, при каких же условиях некоторые проекции исходного файла образуют его полную декомпозицию. Естественно, существует возможность взять конкретный файл, заполненный данными, и непосредственно проверить, образуют ли те или иные его проекции при соединении исходный файл. Однако такой путь не является конструктивным, так как, во-первых, может оказаться достаточно много вариантов разбиения исходного файла, и, во-вторых, что более важно, нет гарантии, что при добавлении записей в исходный файл его проекции будут по-прежнему составлять полную декомпозицию.
Очевидно, необходимо сформулировать критерий, позволяющий даже для незаполненного файла, исходя из возможных значений его полей, судить о возможности получения полной декомпозиции файла из тех или иных его проекций. Такой критерий строится на понятии функциональной зависимости полей файла [34].
Пусть X uY — некоторые непересекающиеся совокупности полей файла. Говорят, что Y находится в функциональной зависимости от X тогда и только тогда, когда с каждым значением X связано не более одного значения Y.
Любые две записи файла, содержащие одинаковые значения X, должны содержать одинаковые значения Y, причем это ограничение действует не только на текущие значения записей файла, но и на все возможные значения, которые могут появиться в файле. Вместе с тем одинаковым значениям Y могут соответствовать различные значения X.
Рассмотрим уже знакомый пример. Пусть в ИФ имеются поля:
ДЕЖУРСТВО ДОЛЖНОСТЬ | ФАМИЛИЯ I ТЕЛЕФОН
Поле ТЕЛЕФОН находится в функциональной зависимости от полей ДОЛЖНОСТЬ и ФАМИЛИЯ (считаем, что в данном файле не будет храниться информация о сотрудниках-однофамильцах, имеющих одинаковые должности). Понятно, что один и тот же номер рабочего телефона могут иметь несколько сотрудников, т. е. по значению поля ТЕЛЕФОН нельзя однозначно определить должность и фамилию сотрудника.
Пусть X состоит из нескольких полей. Говорят, что Y находится в полной функциональной зависимости от X, если Y функционально зависит от X и функционально не зависит от любого подмножества X' не совпадающего с X (Х'сХ) [54].
В условиях предыдущего примера поле ТЕЛЕФОН находится в полной функциональной зависимости от совокупности полей ДОЛЖНОСТЬ и ФАМИЛИЯ, поскольку оно не зависит функционально ни от поля ДОЛЖНОСТЬ, ни от поля ФАМИЛИЯ по отдельности.
Теперь можно сформулировать критерий (правило), по которому следует исходный файл разбивать на проекции для получения его полной декомпозиции (это утверждение называют теоремой Хита).
Пусть имеются три непересекающиеся совокупности полей исходного файла: Н, J, К. Если К фунционалъно зависит от J, то проекции proj [Н, J] (ИФ) и proj [J, К] (ИФ) образуют полную декомпозицию исходного файла.
Докажем это утверждение. Введем вспомогательный файл
ИФ1 = proj [Н, J] (ИФ) ► < proj [J, К] (ИФ).
Покажем, что каждая запись ИФ присутствует в ИФ1, и наоборот.
А. Возьмем произвольную запись исходного файла: (h, j, к). Очевидно, что ее часть (h, j) принадлежит первой проекции, (j, к) — второй проекции ИФ. По определению операции соединения можно утверждать, что запись (h, j, к) должна присутствовать в файле ИФ1.
Б. Возьмем произвольную запись вспомогательного файла: (h', j', к'). Согласно определению файла ИФ1 можно записать: proj [Н, J] (ИФІ) = proj [Н, J] (ИФ). Следовательно, в файле ИФ должна находиться хотя бы одна запись типа (h', j', к'), где к' пока не определено. По аналогии можно записать: proj [J, К] (ИФ1) = proj [J, К] (ИФ). Следовательно, в файле ИФ должна находиться хотя бы одна запись типа (h", j', к'), где h" пока не определено.
Таким образом, в исходном файле ИФ должны содержаться записи (h', j', к") и (h", j', k'). Но поскольку К функционально зависит от J, можно заключить, что к" = к' и, следовательно, в ИФ имеется запись (h", j', к'), которую мы определили как произвольную запись ИФ1. Доказательство закончено.
Вернемся к примеру. Пусть в ИФ имеются поля:
ДЕЖУРСТВО | ДОЛЖНОСТЬ 1 ФАМИЛИЯ | ТЕЛЕФОН
Так как поле ТЕЛЕФОН находится в функциональной зависимости от полей ДОЛЖНОСТЬ и ФАМИЛИЯ, можно заключить, что полную декомпозицию ИФ следует искать в виде проекций:
ПФ1 = proj [ДЕЖУРСТВО, ДОЛЖНОСТЬ, ФАМИЛИЯ] (ИФ); ПФ2 = proj [ДОЛЖНОСТЬ, ФАМИЛИЯ, ТЕЛЕФОН] (ИФ).
Для этого примера можно обозначить:
Н = [ДЕЖУРСТВО];
J = [ДОЛЖНОСТЬ, ФАМИЛИЯ];
К = [ТЕЛЕФОН].
Таким образом, с помощью понятия функциональной зависимости полей файла можно получать его полные декомпозиции без анализа хранящихся в файле данных еще на этапе проектирования БД, что весьма важно на практике.
2.2.5. Нормальные формы файла
Как было показано в п. 2.2.3 и 2.2.4, при некоторых условиях замена файла его полной декомпозицией позволяет исключить дублирование информации и решить проблему присоединенных записей. Таким условием является отсутствие в проекциях, образующих полную декомпозицию файла, общего первичного ключа исходного файла. Теорема Хита создает основу для построения различных полных декомпозиций и поэтому может служить основным инструментом в процессе нормализации файлов БД.
При проведении нормализации на каждом шаге проверяется принадлежность файла некоторой нормальной форме. Если он принадлежит этой нормальной форме,' проверяется, находится ли он в следующей, и т. д. до 5 НФ. Принадлежность файла некоторой форме задает необходимые, но недостаточные условия для нахождения в следующей по старшинству форме.
Еще раз подчеркнем основное достоинство механизма нормализации файлов с помощью исследования функциональной зависимости полей файла: возможность проведения этой операции на этапе проектирования БД.
Перечислим основные нормальные формы файлов в соответствии с [54].
Первая нормальная форма (1 НФ)
Файл находится в 1 НФ, если каждое его поле является атомарным (т. е. не содержит более одного значения), и ни одно из ключевых полей не является пустым. По существу принадлежность файла 1 НФ означает, что он соответствует понятию отношения и его ключевые поля заполнены.
Пример. Принципиально существует возможность хранить информацию о профессорско-преподавательском составе кафедры в следующем виде:
| ДОЛЖНОСТЬ | ФАМИЛИЯ |
| Заведующий | Иванов |
| Профессор | Петров, Сидоров |
| Доцеит | Фомин |
| Преподаватель | Семин, Савин, Федоров |
Однако такой файл не находится в 1 НФ (так как поле ФАМИЛИЯ не является атомарным).
Вторая нормальная форма (2 НФ)
Файл находится во 2 НФ, если он находится в 1 НФ и все его поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Третья нормальная форма (3 НФ)
Файл находится в 3 НФ, если он находится во 2 НФ и ни одно из его неключевых полей не зависит функционально от любого другого неключевого поля.
Нормальная форма Бойса—Кодда (усиленная 3 НФ)
Файл находится в НФ Бойса—Кодда, если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от первичного ключа.
Можно показать [54], что рассмотренные НФ подчиняются правилу вложенности по возрастанию номеров, т. е. если файл находится в 4 НФ, он находится и в 3 НФ, 2 НФ, 1 НФ, и наоборот (см. рис. 2.2.1).
Помимо описанных выше нормальных форм используется четвертая НФ, основанная на понятии обобщенной функциональной зависимости [46]. На практике, приведя все файлы к нормальной форме Бойса—Кодда, можно с большой долей уверенности утверждать, что они находятся и в 5 НФ, т. е. что нормализация файлов БД завершена.
Файл в 1 НФ
Файл во 2 НФ
Файл в 3 НФ
Файл в усиленной 3 НФ
Файл в 5 НФ
Рис. 2.2.1. Соотношение нормальных форм файлов
Отметим, что существующие СУБД (например, широко распространенная СУБД Access из пакета MS Office) содержат средства для автоматического выполнения операций нормализации (подобные мастеру по анализу таблиц), хотя качество этого анализа зачастую требует последующего вмешательства разработчика БД [16, 59].
Необходимость нормализации файлов БД (кроме решения уже рассмотренных проблем исключения дублирования и потери присоединенных записей) определяется еще по крайней мере двумя обстоятельствами [43]: во-первых, разумным желанием группировать данные по их содержимому,
что позволяет упростить многие процедуры в БД — от организации разграничения доступа до повышения оперативности поиска данных; во-вторых, стремлением разработать БД в виде множества унифицированных блоков, что может облегчить модернизацию отдельных частей базы, а также использовать таблицы одной БД в других.
Важным направлением совершенствования СУБД является их интеллектуализация (см., например, 27), что подробнее будет рассмотрено в разд. 4 учебника.
Обсуждение Информационные системы в экономике
Комментарии, рецензии и отзывы