тивный документ, Дата начала и Дата окончания для сотрудника с табельным номером 15 имеют не по одному, а по два значения (например, атрибут Номер объекта для этого сотрудника имеет значения 2042 и 2140).

Таблица 1.1 – Данные для БД проектно-строительной организации

Следует также обратить внимание, что столбец Работа разделяется на два “подстолбца”, содержащих дату начала и окончания работы сотрудника над проектом.

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

1.3Первая нормальная форма

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

Для приведения к 1НФ строки и/или столбцы, содержащие неатомарные атрибуты, разбиваются на несколько строк и/или столбцов. Например, в таблице 1.1 данные о сотруднике с номером 15 следует представить в виде двух строк, каждая из которых будет соответствовать одному проекту, над которым работает данный сотрудник. Столбец Работа необходимо разделить на два столбца: Дата начала и Дата окончания. БД проектно-строительной организации, приведенная к 1НФ, показана в таблице 1.2.

Таблица 1.2 – БД проектно-строительной организации в первой нормальной форме

Ключ БД, приведенной в таблице 1.2, является составным и состоит из двух атрибутов: Табельный номер и Номер проекта, так как любая комбинация

8

табельного номера и номера проекта встречается в БД только один раз. Будем обозначать такой ключ как (Табельный номер, Номер проекта). В таблицах будем выделять атрибуты, составляющие ключ, подчеркиванием.

Очевидно, что атрибуты Табельный номер и Номер проекта по отдельно-

сти не могут использоваться в качестве ключевых, так как, например, одно и то же значение табельного номера может встречаться в БД несколько раз. Например, значение табельного номера 15 встречается в БД дважды, так как сотрудник Иванов работает на двух проектах. Атрибут Номер проекта также сам по себе не является ключевым, так как, например, номер проекта 2140 встречается в БД дважды (на этом проекте работают два сотрудника).

Примечание – Как отмечено выше, приведение к 1НФ необходимо, чтобы ввести данные в любую реляционную БД. Поэтому, строго говоря, баз данных, не приведенных к первой нормальной форме, не существует. При этом “степень” разбиения атрибутов на атомарные значения может быть различной в зависимости от того, какие запросы возможны для данной БД. Например, если станет известно, что может достаточно часто требоваться информация об объектах, располагающихся на определенной улице, то, возможно, потребуется разбить столбец Адрес на столбцы Улица и Дом.

Легко видеть, что БД, приведенная в таблице 1.2, имеет целый ряд существенных взаимосвязанных недостатков:

−большая избыточность данных: многие данные хранятся многократно. Например, данные о каждом сотруднике (табельный номер, фамилия, специальность, оклад) хранятся столько раз, сколько имеется проектов, над которыми работает данный сотрудник. Данные о каждом проекте (номер проекта, адрес, тип объекта, нормативный документ) хранятся столько раз, сколько имеется сотрудников, работающих над данным проектом. Информация о том, какой нормативный документ соответствует каждому типу объекта, также хранится несколько раз (столько, сколько имеется проектов с данным типом объекта);

−аномалия добавления (ввода): невозможность ввода данных о сотруднике, не назначенном ни на один проект (так как при этом одно из полей, составляющих ключ БД – номер проекта – оказывается пустым). Аналогичным образом невозможным оказывается ввод данных о проекте, пока на него не назначен ни один сотрудник;

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

−аномалия обновления: если изменяется какой-либо атрибут, то его приходится изменять во многих записях. Например, если у сотрудника изменится оклад, то изменение потребуется вносить столько раз, сколько имеется проектов, в которых работает данный сотрудник. Кроме того, при этом происходит нарушение целостности данных: например, в некоторый момент значения атрибута Оклад у одного и того же сотрудника оказываются разными.

9

Эти недостатки будут постепенно устраняться по мере приведения БД к последующим нормальным формам.

1.4Вторая нормальная форма

Прежде чем приступать к рассмотрению второй и последующих нормальных форм, приведем несколько необходимых определений.

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

Функциональная зависимость атрибута B от атрибута A обозначается следующим образом: A → B.

Влюбой БД все неключевые атрибуты находятся в функциональной зависимости от ключа. Так, в рассматриваемом примере все атрибуты находятся в функциональной зависимости от группы атрибутов (Табельный номер, Номер проекта). Легко видеть, что любой конкретной комбинации этих атрибутов всегда соответствует одно и только одно значение любого другого атрибута. Например, комбинации (15, 2140), где 15 – табельный номер, 2140 – номер проекта, соответствует одна фамилия (Иванов), одна специальность (инженерстроитель), один оклад (400), один адрес (ул. Лесная, 2), один тип объекта (жилой дом), один нормативный документ (СНиП 75), одна дата начала

(10.01.2007), одна дата окончания (1.03.2007).

Атрибут B находится в полной функциональной зависимости от группы атрибутов A, если он находится в функциональной зависимости от этой группы атрибутов, но не находится в функциональной зависимости ни от какой из частей этой группы (т.е. ни от каких из атрибутов, входящих в группу атрибутов A).

Атрибут B находится в неполной функциональной зависимости от группы атрибутов A, если он находится в функциональной зависимости от ка- ких-либо из частей этой группы (т.е. от некоторых из атрибутов, входящих в группу атрибутов A).

Врассматриваемом примере атрибуты Фамилия, Специальность и Оклад находятся в неполной функциональной зависимости от ключа (Табельный номер, Номер проекта), так как находятся в функциональной зависимости от части этого ключа – атрибута Табельный номер. Из таблицы 1.2 видно, что любому конкретному значению табельного номера всегда соответствует только одна фамилия, одна специальность и один оклад. Например, табельному номеру 15 соответствует одна фамилия (Иванов), одна специальность (инженерстроитель), один оклад (400). В то же время атрибуты Адрес, Тип объекта,

Нормативный документ, Дата начала и Дата окончания не находятся в функ-

циональной зависимости от табельного номера. Например, табельному номеру 15 соответствуют два адреса (ул.Заводская, 8 и ул. Лесная, 2), два типа объектов (склад и жилой дом), два нормативных документа (СНиП 62 и СНиП 75),

10

две даты начала (5.01.2007 и 10.01.2007), две даты окончания (30.01.2007 и 1.03.2007).

Аналогично можно показать, что атрибуты Адрес, Тип объекта и Нормативный документ также находятся в неполной функциональной зависимости от ключа (Табельный номер, Номер проекта), так как находятся в функциональной зависимости от части этого ключа – атрибута Номер проекта.

Атрибуты Дата начала и Дата окончания не находятся в функциональной зависимости ни от одной из частей ключа (Табельный номер, Номер проекта). Выше показано, что эти атрибуты не находятся в функциональной зависимости от атрибута Табельный номер. Они не находятся в функциональной зависимости и от атрибута Номер проекта: например, номеру проекта 2140 соответствуют две даты начала (15.01.2007 и 10.01.2007) и две даты окончания (25.02.2007 и 1.03.2007), так как в проекте 2140 заняты два работника (и у каждого из них – своя дата начала и дата окончания работы в данном проекте). Таким образом, атрибуты Дата начала и Дата окончания находятся в полной функциональной зависимости от ключа (Табельный номер, Номер проекта).

Примечание – В таблице 1.2 имеется еще одна функциональная зависимость: Тип объекта → Нормативный документ. Здесь оба атрибута - неключевые. Эта функциональная зависимость будет учтена при приведении к третьей нормальной форме (см. подраздел 1.5).

Наличие неполных функциональных зависимостей – основная причина недостатков 1НФ, показанных в подразделе 1.3. Для их устранения таблицы приводятся ко второй нормальной форме (2НФ).

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

Примечание – Если таблица имеет простой (т.е. состоящий из одного атрибута) ключ, то она всегда находится в 2НФ (по определению 2НФ).

Таблица приводится к 2НФ в следующем порядке:

−выделяются все атрибуты, находящиеся в полной функциональной зави-

симости от ключа. Эти атрибуты, вместе с ключом, выделяются в отдельную таблицу;

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

Приведем к 2НФ таблицу 1.2. Как показано выше, атрибуты Дата начала и Дата окончания находятся в полной функциональной зависимости от ключа (Табельный номер, Номер проекта). Поэтому указанные атрибуты вместе с ключом выделяются в отдельную таблицу (таблица 1.3). Назовем эту таблицу, например, “Работа над проектами”.

Атрибуты Фамилия, Специальность и Оклад находятся в функциональной зависимости от части ключа – атрибута Табельный номер. Поэтому эти атрибу-

11

ты, вместе с атрибутом Табельный номер, выделяются в отдельную таблицу (таблица 1.4). Присвоим этой таблице имя “Сотрудники”.

Атрибуты Адрес, Тип объекта и Нормативный документ также находятся в функциональной зависимости от части ключа – атрибута Номер проекта. Эти атрибуты, вместе с атрибутом Номер проекта, также выделяются в отдельную таблицу (таблица 1.5). Назовем эту таблицу “Проекты”.

Таким образом, БД проектно-строительной организации, приведенная к 2НФ, состоит из трех таблиц (таблицы 1.3, 1.4, 1.5).

Таблица 1.3 – Работа над проектами

Таблица 1.4 – Сотрудники

Таблица 1.5 – Проекты

БД, приведенные к 2НФ, также могут иметь существенные недостатки. Так, в рассматриваемом примере таблица 1.5 имеет следующие недостатки:

−избыточность данных: некоторые данные хранятся многократно. Например, данные о том, какой нормативный документ соответствует каждому типу объекта, хранятся несколько раз (столько, сколько имеется проектов с данным типом объекта). Так, информация о том, что жилые дома проектируются согласно документу СНиП 75, приведена в таблице 1.5 дважды;

−аномалия добавления (ввода): невозможность ввода данных о нормативном документе, соответствующем некоторому типу объектов, если в данный момент в БД нет данных об объектах такого типа. Например, в таблицу 1.5 невозможно ввести данные о том, что объекты типа “производственный цех” проектируются, например, согласно СНиП 100 (так как в таблице нет данных об объектах типа “производственный цех”);

−аномалия удаления: при удалении данных о проекте могут быть потеряны данные о нормативном документе, по которому разрабатывался данный проект (если в БД нет данных о других проектах с тем же типом объекта). Например, если из таблицы 1.5 удалить данные об объекте 2042, то будет потеряна информация о том, что склады проектируются согласно СНиП 62;

12