|
Страница 6 из 8
Теперь наше отношение выглядит несколько корректнее. Однако даже беглый взгляд на него говорит о том, что оно пока еще далеко от совершенства. Очевидно, что повторяющиеся значения, которых немало в предыдущей таблице, являются потенциальным источником проблем.
Во-первых, при вводе их значений легко ошибиться. Например, достаточно изменить всего одну букву в графе "Адрес", и формально это будет уже совершенно другой адрес, не имеющий ничего общего с первым. Найти подобные опечатки в объемной таблице - задача не из простых.
Во-вторых, название улицы может измениться, хоть это происходит и не так часто (тем не менее пренебрегать такой возможностью не стоит). Может измениться и адрес веб-сайта предприятия, что гораздо вероятнее. Тогда придется опять же шерстить всю таблицу и изменять соответствующие значения.
В-третьих, нельзя пренебрегать и эффективностью хранения информации. Из нашей таблицы можно как минимум дважды узнать адрес поршневого завода, хотя нам хватило бы и одного раза. В данном примере это мелочи, но на практике встречаются базы пообъемнее. Например, лично мне приходится иметь дело с таблицами, которые за месяц подрастают до нескольких сотен миллионов записей. Как нетрудно прикинуть, лишнее поле размером всего-навсего в 10 байт раздует объем файла, в котором физически размещена таблица, на несколько гигабайт. Помимо того, что эти гигабайты нужно хранить на диске, при операциях с базой их приходится прокачивать из дисковой памяти в оперативную, а порой и в локальную сеть.
Таким образом, борьба с избыточностью данных выгодна со всех сторон - как со стороны повышения удобства пользования данными и поддержания их в целостном виде, так и со стороны эффективности обработки и хранения данных аппаратными средствами сервера баз данных. Именно на устранение этой избыточности и направлена дальнейшая нормализация отношений.
Однако перед тем, как дать определение 2НФ, нам необходимо познакомиться с понятием полной и частичной функциональной зависимостей. По традиции сначала - формальное определение.
Пусть F - множество функциональных зависимостей, при этом ФЗ X->Y F+. Множество Y называется частично зависимым от X относительно F, если ФЗ X->Y не является редуцированной слева (т.е. существует собственное подмножество X множества X, такое, что ФЗ X'->Y F+. Если же ФЗ X->Y является редуцированной слева, то множество Y называется полностью зависимым от X относительно F.
Схема отношения R находится во 2НФ относительно множества функциональных зависимостей F, если она находится в 1НФ и каждый неключевой атрибут полностью зависит от каждого ключа для R.
Теперь для тех, кто предпочитает неформальные определения, попытаюсь дать интуитивно понятный аналог вышесказанного. Другими словами, отношение находится во 2НФ, если оно находится в 1НФ, и при этом все неключевые атрибуты зависят только от ключа целиком, а не от какой-то его части.
Вернемся к нашей табл. 4, которая представляет пример нашего отношения, приведенного к 1НФ. Предположим, что при постановке задачи заказчик сообщил нам, что в пределах каждого города наименование предприятия является уникальным, но в разных городах названия могут совпадать. Таким образом, предприятие характеризуется составным ключом "Наим+Город". Посмотрим на наше отношение с точки зрения того, что мы только что узнали про 2НФ.
Очевидно, что телефонный код города зависит исключительно от самого города и никак не связан с названием предприятия. Отсюда и один из источников избыточных данных - сколько раз в таблице встречается строка, содержащая сведения о контактном лице какого-либо предприятия, находящегося в данном городе, столько раз и повторяется информация о коде города.
Чтобы устранить эту избыточность, нам придется разбить наше отношение на несколько (в данном случае - 2, хотя для более сложных отношений их может быть и гораздо больше):
Табл. 5а
| Наим. | Город | Адрес | Эл. почта | WWW | Вид | Должность | Ф.И.О. | Тел. | | Поршневой з-д | Владимир | Ул. 2-я Кольцевая, 17 |
Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script
| www.plunger.ru | Поставщик | зам. дир. | Иванов И.И. | 76-15-95 | | Поршневой з-д | Владимир | Ул. 2-я Кольцевая, 17 |
Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script
| www.plunger.ru | Поставщик | нач. отд. сбыта | Петров П.П., | 76-15-35 | | ООО Вымпел | Курск | Ул. Гоголя, 25 |
Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script
| | Клиент | директор | Сидоров С.С. | 66-65-38 | | ИЧП Альфа | Владимир | Ул. Пушкинская, 37, оф. 565 |
Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script
| | Клиент | директор | Васильев В.В. | 74-57-45 |
Табл. 5б
| Город | Код города | | Владимир | 3254 | | Курск | 7634 |
Итак, мы избавились от частичной зависимости атрибута "Код-города" от составного ключа, переместив коды городов в отдельное отношение с ключом "Город". Таким образом, теперь мы получили два отношения, каждое из которых находится во 2НФ.
Следует обратить внимание на факт, который далеко не всегда явно отражен в литературе по базам данных. Поскольку в данном случае речь идет о частичной зависимости атрибутов от ключа, то все вышесказанное относится исключительно к отношениям с составным ключом. Отношение с простым, или атомарным, ключом (состоящим из единственного атрибута), приведенное к 1НФ, находится во 2НФ по определению и в данном этапе нормализации не нуждается.
Несмотря на предпринятые усилия, таблица 5а определенно все еще содержит изрядную избыточность - достаточно взглянуть на повторяющиеся значения в столбцах "Адрес", "Эл.почта" и "WWW". Значит, процесс нормализации еще не завершен, и пора переходить к его следующей стадии.
|