Название_филиала, Адрес, Номер_счета, Баланс, Тип,

означающий, что каждая строка этого отношения уникальна.

Как уже отмечалось, такой ключ не имеет особого смысла. Его можно сократить, например, так:

Название_филиала, Адрес, Номер_счета, Баланс,

поскольку каждой комбинации атрибутов левой части соответствует одно и только одно значение Тип.

Можно продолжить сокращение:

Название_филиала, Адрес, Номер_счета

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

Название_филиала, Адрес,

т.е. комбинация Название_филиала, Адрес не может быть первичным ключом данного отношения. Все первичные ключи — подмножества потенциального ключа, поэтому ни Название_филиала, ни Адрес не может быть первичным ключом. Однако можно сократить Название_филиала, Адрес, Номер_счета по-другому:

Название_филиала, Номер_счета и далее:

Номер_счета.

Больше сокращать нечего; это означает, что Номер_счета — первичный ключ отношения Филиал.

При поиске потенциального ключа отношения Клиент мы начнем с потенциального ключа

Номер_клиента; Имя_клиента; Адрес; Статус; Номер_счета.

Так сокращать можно:	Так сокращать нельзя:
Номер_клиента; Статус; Номер_счета  Номер_клиента; Номер_счета	Номер_клиента; Имя_клиента; Адрес; Статус (так как один клиент может иметь несколько счетов в одном филиале)

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

Итак, первичный ключ — это потенциальный ключ, который невозможно сократить (т.е. минимальный). Все атрибуты первичного ключа называются ключевыми атрибутами. Атрибуты, не являющиеся частью первичного ключа, называются неключевыми. В отношении Филиал можно выделить такие неключевые атрибуты, как Название_филиала, Адрес, Номер_менеджера, Баланс и Тип, а в отношении Клиент — атрибуты Имя, Адрес и Статус.

7.2. Процедура нормализации отношений.

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

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

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

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

Отношение Студенты
Номер_студента	Имя_студента	Номер_курса	Название_курса	Преподаватель
1	Смирнов	1264	Французский ч 1	Батулев
2	Абдулов	1564	Испанский ч 3	Крупкина
7	Петров	1264	Французский ч 1	Батулев
11	Иванов	1265	Французский ч 2
13	Иванов	1265	Французский ч 2
16	Сидоров	1264	Французский ч 1	Батулев
18	Никитин	1265	Французский ч 2

Таблица 1. Неэффективная реляционная база данных

Это может привести к следующим аномалиям:

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

б) Аномалии вставки. Перед тем, как ввести студента в базу данных, необходимо убедиться, что информация о посещаемом курсе представлена так же, как для других студентов, посещающих этот курс. Отношение в табл. 3 не исключает возможности того, что два студента будут посещать разные занятия, проводимые разными преподавателями с одним и тем же номер_курса.

2. Минимальное использование null-значений. Существует множество корректных представлений базы данных, но в некоторых из них может оказаться много кортежей, содержащих неопределенные значения (null). В табл. 3 три кортежа имеют неопределенное значение атрибута Преподаватель, так как для одного из курсов (Французский ч 2) еще не назначен преподаватель. Наряду с избыточностью, неопределенные значения — источник проблем в реляционных базах данных, поскольку невозможно точно определить, что они означают. Означает ли неопределенное значение атрибута Преподаватель в нашем примере, что для данного курса нет преподавателя, или имя его не было введено, а может быть этот курс нужно изучать самостоятельно и преподавателя не должно быть вовсе, поэтому указанный атрибут не применим к данным кортежам? Из-за сложности интерпретации null -значений их использование желательно свести к минимуму.

3. Предотвращение потери информации. Один из основных недостатков представления в табл. 3 — отсутствие информации о курсах, не посещаемых студентами. Более того, если студент Абдулов решит в дальнейшем не посещать курс испанского языка, это приведет к потере всей информации о курсе Испанский ч 3. Такая аномалия называется аномалией удаления.

С учетом вышесказанного, представление базы данных в табл. 2 более удачно.

Отношение Студент
Номер_студента	Имя_студента	Номер_курса
1	Смирнов	1264
2	Абдулов	1564
7	Петров	1264
11	Иванов	1265
13	Иванов	1265
16	Сидоров	1264
18	Никитин	1265

Отношение Курс
Номер_курса	Название_курса	Преподаватель
1264	Французский ч 1	Батулев
1265	Французский ч 2
1266	Французский ч 3	Симонов
1562	Испанский ч 1	Лопес
1563	Испанский ч 2	Лопес
1564	Испанский ч 3	Крупкина

Таблица 2. Более удачное представление базы данных

Возможность дублирования и сопутствующих ей аномалий (табл. 2.) устранена. Произведена декомпозиция исходного отношения на два отношения; внешний ключ Номер_курса связывает каждого студента с информацией о посещаемом курсе. Таким образом, все студенты одинаковым номером курса будут автоматически связаны с одним и тем же множеством данных о курсе. В случае изменения информации о курсе нужно изменить только соответствующий ему кортеж в отношении Курс. Если студент меняет посещаемый курс, необходимо изменить только номер курса; изменять информацию о курсе не нужно. При включении в базу данных нового студента нет необходимости вводить данные о посещаемом курсе, достаточно указать номер курса. Если все студенты, посещающие курс, удаляются базы данных, информация об этом курсе по-прежнему остается в базе данных в отношении Курс, т.е. теперь появилась возможность хранить информацию о курсах, у которых в настоящее время нет слушателей. Использование неопределенных значений также сократилось.

К такому представлению, как в табл. 2, можно прийти с помощью нормализации.