Фрагмент отношения успеваемость, связанного с отношением студенты

№ студенческого билета	Предмет	Оценка
23960282	Высшая математика	4
23960282	Философия	5
22991380	Высшая математика	3
22991380	Философия	4 NULL
22657879	Физика	5
24356783	Физика	4 NULL

Атрибут «№ студенческого билета» таблицы УСПЕВАЕМОСТЬ содержит иден­тификатор студента (в данном примере в качестве такого идентификатора ис­пользуется номер студенческого билета). Если нужно узнать имя студента, соот­ветствующее строкам в таблице УСПЕВАЕМОСТЬ, то следует поискать это же значение идентификатора студента в поле «№ студенческого билета» таблицы СТУДЕНТЫ и в найденной строке прочесть значение поля «Имя». Таким обра­зом, связь между таблицами СТУДЕНТЫ и УСПЕВАЕМОСТЬ устанавливается по атрибуту «№ студенческого билета».

При рассмотрении связанных таблиц важное значение имеет понятие внешнего ключа. Рассмотрим его более подробно.

Внешние ключи отношения

В базах данных одни и те же имена атрибутов часто используются в разных отно­шениях. В рассматриваемом примере атрибут «№ студенческого билета» отсутствует как в отношении СТУДЕНТЫ, так и в отношении УСПЕВАЕМОСТЬ. В этом примере атрибут «№ студенческого билета» иллюстрирует понятие внеш­него ключа (foreign key).

Внешний ключ – это атрибут (или множество атрибутов) одного отношения, явля­ющийся ключом другого (или того же самого) отношения.

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

Так же как и любые другие ключи, внешние ключи могут быть простыми либо составными.

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

Атрибуты внешнего ключа не обязательно должны иметь те же имена, что и атрибуты ключа, которым они соответствуют. Например, в нашем примере можно было дать атрибуту «№ студенческого билета» таблицы УСПЕВАЕМОСТЬ другое имя, например «Студенческий билет».

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

Условия целостности данных

Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворе­чивой, в реляционной модели устанавливаются некоторые ограничительные усло­вия. Ограничительные условия – это правила, определяющие возможные значе­ния данных. Они обеспечивают логическую основу для поддержания корректных значений данных в базе. Ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных. Важнейшими ограничениями целостности данных являются: О – категорийная целостность; G – ссылочная целостность.

Ограничение категорийной целостности заключается в следующем. Кортежи отно­шения представляют в базе данных элементы определенных объектов реального мира или, в соответствии с терминологией реляционных СУБД, категорий. Например, строка таблицы СТУДЕНТЫ представляет конкретного студента. Первичный ключ таблицы однозначно определяет каждый кортеж и, следовательно, каждый элемент категории. Таким образом, для извлечения данных, содержащихся в строке табли­цы, или для манипулирования этими данными необходимо знать значение ключа для этой строки. Поэтому строка не может быть занесена в базу данных до тех пор, пока не будут определены все атрибуты ее первичного ключа. Это правило называ­ется правилом категорийной целостности и кратко формулируется следующим об­разом: никакой атрибут первичного ключа строки не может быть пустым.

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

Если две таблицы связаны между собой, то внешний ключ таблицы должен содер­жать только те значения, которые уже имеются среди значений ключа, по которо­му осуществляется связь. Если корректность значений внешних ключей не конт­ролируется СУБД, то может нарушиться ссылочная целостность данных. Это можно пояснить на рассматриваемом примере следующим образом. Если удалить из таблицы СТУДЕНТЫ строку (например, при отчислении студента), имеющую хотя бы одну связанную с ней строку в таблице УСПЕВАЕМОСТЬ, то это приве­дет к тому, что в таблице УСПЕВАЕМОСТЬ останутся записи об успеваемости студента, который уже отчислен. Такая же ситуация будет наблюдаться и в том случае, если внешнему ключу таблицы УСПЕВАЕМОСТЬ ошибочно будет при­своено значение, отсутствующее в значениях ключа связанной таблицы.

Ограничения категорийной и ссылочной целостности должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсут­ствие в любом отношении кортежей с одним и тем же значением первичного клю­ча. Что же касается ссылочной целостности, то здесь обеспечение целостности выглядит несколько сложнее. При обновлении ссылающегося отношения (при вставке новых кортежей или модификации значения внешнего ключа в существу­ющих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. А вот при удалении кортежа из отношения, на которое ведет ссылка, возможно использовать один из трех подходов, каждый из которых поддерживает целостность по ссылкам:

– первый подход заключается в том, что запрещается производить удаление кор­тежа, на который существуют ссылки (то есть сначала нужно либо удалить ссы­лающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа);

– при втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически стано­вится неопределенным;

– третий подход (называемый также каскадным удалением) состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающего­ся отношения автоматически удаляются все ссылающиеся кортежи.

В развитых реляционных СУБД обычно можно выбрать способ поддержания ссы­лочной целостности для каждой отдельной ситуации определения внешнего клю­ча. Конечно, для принятия такого решения необходимо анализировать требова­ния конкретной прикладной области.

Хотя большинство современных СУБД обеспечивает ссылочную целостность дан­ных, все же следует помнить, что существуют реляционные СУБД, в которых не вы­полняются ограничения ссылочной целостности. Это, как правило, ранние разра­ботки локальных реляционных СУБД – FoxPro версии 2.6 и ниже, версии dBase для DOS.

Типы связей между таблицами

При установлении связи между двумя таблицами одна из них будет являться глав­ной (master), а вторая – подчиненной (detail). Различие между ними несколько уп­рощенно можно пояснить следующим образом. В главной таблице всегда доступны все содержащиеся в ней записи. В подчиненной же таблице доступны только те за­писи, у которых значение атрибутов внешнего ключа совпадает со значением соот­ветствующих атрибутов текущей записи главной таблицы. Причем изменение теку­щей записи главной таблицы приведет к изменению множества доступных записей подчиненной таблицы, а изменение текущей записи в подчиненной таблице не вы-, зовет никаких изменений ни в одной из таблиц.

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

Различают четыре типа связей между таблицами реляционной базы данных:

– один к одному – каждой записи одной таблицы соответствует только одна за­пись другой таблицы;

– один ко многим – одной записи главной таблицы могут соответствовать несколь­ко записей подчиненной таблицы;

– многие к одному – нескольким записям главной таблицы может соответство­вать одна и та же запись подчиненной таблицы;

– многие ко многим – одна запись главной таблицы связана с несколь­кими запи­сями подчиненной таблицы, а одна запись подчиненной таблицы связана с не­сколькими записями главной таблицы.

Различие между типами связей «один ко многим» и «многие к одному» зависит от того, какая из таблиц выбирается в качестве главной, а какая – в качестве подчиненной. Например, если из связанных таблиц СТУДЕНТЫ и УСПЕВАЕМОСТЬ в качестве глав­ной выбрать таблицу СТУДЕНТЫ, то получим тип связи «один ко многим». Если же выбрать в качестве главной таблицу УСПЕВАЕМОСТЬ, получится тип связи «многие к одному».

Основные свойства отношений

Рассмотрим теперь некоторые важнейшие свойства отношений реляционной мо­дели данных.

Отсутствие упорядоченности кортежей

В таблицах реляционной базы данных информация хранится в неупорядоченном виде. Упорядочивание в принципе не поддерживается СУБД, и такое понятие, как порядковый номер кортежа, не имеет никакого смысла. Свойство отсутствия упо­рядоченности кортежей отношения также является следствием определения от­ношения как множества кортежей. Отсутствие требования к поддержанию по­рядка на множестве кортежей отношения дает СУБД дополнительную гибкость при хранении баз данных во внешней памяти и при выполнении запросов к базе данных.

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

Отсутствие упорядоченности атрибутов

Атрибуты отношений также не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отно­шений не только путем добавления новых атрибутов, но и путем удаления суще­ствующих атрибутов. Однако в большинстве существующих систем такая возмож­ность не допускается, и хотя упорядоченность набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов используется их поря­док в линейной форме определения схемы отношения.

Атомарность значений атрибутов

Значения всех атрибутов являются атомарными. Это следует из определения до­мена как потенциального множества значений простого типа данных, то есть сре­ди значений домена не могут содержаться множества значений (отношения).

Реляционная система управления базами данных

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

Еще раз подчеркнем, что в реляционной базе данных таблицы связаны между со­бой; это позволяет с помощью единственного запроса найти все необходимые дан­ные (которые могут находиться в нескольких таблицах). Будучи связанной по­средством общих ключевых полей, информация в реляционной базе данных может объединяться из множества таблиц в единый результирующий набор.

Свойства таблиц реляционной базы данных

Так как таблицы в реляционной СУБД являются отношениями реляционной мо­дели данных, то и свойства этих таблиц являются свойствами отношений, кото­рые мы уже рассмотрели выше. Кратко сформулируем эти свойства еще раз:

• каждая таблица состоит из однотипных строк и имеет уникальное имя;

• строки имеют фиксированное число полей (столбцов) и значений (множествен­ные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой по­зиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или NULL;

• строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку;

• столбцам таблицы присваиваются уникальные имена, и в каждом из них разме­щаются однородные значения данных (даты, фамилии, целые числа или денеж­ные суммы);

• полное информационное содержание базы данных представляется в виде яв­ных значений данных, и такой метод представления является единственным. В частности, не существует каких-либо специальных «связей» или указателей, соединяющих одну таблицу с другой;

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

Индексы

Выше мы рассмотрели понятие ключей таблиц базы данных. В большинстве ре­ляционных СУБД ключи реализуются с помощью объектов, называемых индек­сами. Индекс представляет собой указатель на данные, размещенные в реляционной таб­лице. Можно провести аналогию индекса таблицы базы данных с указателем, обыч­но помещаемым в конце книги. Чтобы найти в книге страницы, относящиеся к некоторой теме, проще всего обратиться к указателю, в котором устанавливается соответствие между перечисленными в алфавитном порядке темами и номерами страниц, и сразу определить страницы, которые следует просмотреть. Чтобы без указателя найти все страницы, относящиеся к нужной теме, пришлось бы просмат­ривать всю книгу. Индекс базы данных предназначен для аналогичных целей – чтобы ускорить поиск информации в таблице базы данных. Индекс предоставляет информацию о точном физическом расположении данных в таблице.

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

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

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

Рассмотрим пример индекса. На рис. 4.1 показан фрагмент таблицы СТУДЕНТЫ и индекса, построенного по полю «Имя» данной таблицы. При выполнении поиска по имени студента, просматривая индекс, можно сразу определить порядковый Номер записи, содержащей необходимую информацию, и затем быстро найти в таблице сами данные. Если бы у таблицы отсутствовал индекс по полю «Имя», то выполнение поиска по имени студента потребовало бы просмотра всей таблицы.

Таким образом, использование индексов снижает время выборки данных.

Рисунок 4.1 – Поиск информации в таблице с помощью индекса

Различают несколько типов индексов. Наиболее часто выделяют три типа:

• простые;

• составные;

• уникальные.

Ускорение поиска информации при использовании индекса может показаться неоче­видным – ведь количество записей в индексе совпадает с количеством записей в таблице. Однако следует учитывать два обстоятельства:

• обращение к индексу выполняется быстрее, чем к таблице;

• в индексе записи хранятся в упорядоченном виде (в рассматриваемом примере – в алфавитном порядке) и поэтому при поиске информации в индексе нет необхо­димости просматривать все данные до конца индекса.

Простые индексы представляют собой простейший и вместе с тем наиболее рас­пространенный тип индекса. Простой индекс строится на основе только одного столбца реляционной таблицы (индекс, приведенный на рис. 4.1, является про­стым).

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

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

Можно назвать два условия оптимальности следования столбцов в составном ин­дексе:

– первым следует помещать столбец, содержащий наиболее ограни­чивающее значение (то есть, содержащий меньшее количество повторов);

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

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

Следует серьезно относиться к планированию индексов. Неправильное применение индексов может привести к снижению производительности системы. Мы уже говори­ли о том, что физическое местоположение записей может изменяться в процессе редактирования данных пользователями, а также в результате манипуляций с фай­лами базы данных, проводимых самой СУБД (таких как сжатие данных, сборка «му­сора» и др.). Обычно при этом происходят соответствующие изменения и в индексе, а это увеличивает время, требующееся СУБД для проведения таких операций. Поэто­му обычно не следует индексировать:

– столбцы, данные в которых подвержены частому изменению;

– столбцы, содержащие большое количество пустых значений;

– столбцы, содержащие небольшое количество уникальных значений;

– небольшие таблицы;

– поля большого размера.

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

Нормализация данных

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

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

Цели нормализации

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

может привести к нарушению целостно­сти данных (противоречивости информации) в базе данных. Обычно различают сле­дующие проблемы, возникаю­щие при использовании ненормализованных таблиц:

• избыточность данных;

• аномалии обновления;

• аномалии удаления;

• аномалии ввода.

Чтобы проиллюстрировать проблемы, возникающие при работе с ненормализо­ванными базами данных, рассмотрим в качестве примера таблицу СОТРУДНИКИ, содержащую информа­цию о сотрудниках некой организации. Структура этой таблицы приведена на рис. 4.2.

Избыточность данных

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

Аномалии обновления

Аномалии обновления тесно связаны с избыточностью данных. Предположим, что у сотрудника, работающего на нескольких должностях, изменился адрес. Чтобы информация, содержащаяся в таблице, была корректной, необходимо будет вне­сти изменения в несколько записей. Если же исправление будет внесено не во все записи, то возникнет несоответствие информации, которое и называется аномали­ей обновления.

Аномалии удаления

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

Аномалии ввода

Аномалии ввода возникают при добавлении в таблицу новых записей и обычно возникают, когда для некоторых полей таблицы заданы ограничения NOT NULL. В таблице, рассматриваемой в качестве примера, имеется поле «Рейтинг», в кото­ром содержится информация об уровне квалификации сотрудника, устанавливае­мом по результатам его работы. При приеме на работу нового сотрудника устано­вить уровень его квалификации невозможно, так как он еще не выполнял никаких работ в организации. Если для этого поля задать ограничение NOT NULL, то в таблицу нельзя будет ввести информацию о новом сотруднике. Это и называется аномали­ей ввода.

Вывод

Очевидно, что аномалии обновления, удаления и ввода крайне нежелательны. Что­бы свести к минимуму возможность появления такого рода аномалий, и использу­ется нормализация.

Нормальные формы

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

В теории реляционных баз данных обычно выделяется следующая последователь­ность нормальных форм:

• первая нормальная форма (1NF);

• вторая нормальная форма (2NF);

• третья нормальная форма (3NF);

• нормальная форма Бойса–Кодда (BCNF);

• четвертая нормальная форма (4NF);

• пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF). Основные свойства нормальных форм:

• каждая следующая нормальная форма в некотором смысле лучше предыду­щей;

• при переходе к следующей нормальной форме свойства предыдущих нормаль­ных свойств сохраняются.

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

Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение ко­торого однозначно определяется значением другого атрибута. Функционально за­висимые атрибуты обозначаются следующим образом: X –> Y. Эта запись означа­ет, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута Y. Атрибут, указываемый в левой части, называется детерминантом.

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

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

Ограничение первой нормальной формы – значения всех атрибутов отношения должны быть атомарными. Данное требование является базовым требованием классической реляционной модели данных, поэтому любая реляционная табли­ца (в том числе и таблица, структура которой изображена на рис. 4.2) по определе­нию уже находится в первой нормальной форме.

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

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

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

Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следу­ющие шаги:

1. Определить, на какие части можно разбить первичный ключ, так чтобы некото­рые из неключевых полей зависели от одной из этих частей (причем эти части могут содержать несколько атрибутов).

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

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

В нашем примере для приведения таблицы СОТРУДНИКИ ко второй нормаль­ной форме ее следует разделить на две таблицы. Первичный ключ исходной таб­лицы состоит из двух атрибутов – «Код сотрудника» и «Должность». Все же лич­ные данные о сотрудниках зависят только от атрибута «Код сотрудника». Атрибуты, соответствующие этим данным, мы и выделим в качестве одной из таблиц, кото­рую назовем ФИЗИЧЕСКИЕ ЛИЦА. Информацию же о должностях и их оплате вынесем в другую таблицу, которой присвоим имя СОТРУДНИКИ. Схема при­ведения таблицы ко второй нормальной форме приведена на рис. 4.3.

Рисунок 4.3 – Приведение таблицы ко второй нормальной форме

Полученные две таблицы связаны между собой по полю «Код физического лица», которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом для таблицы СОТРУДНИКИ. Данное поле отсутствовало в исход­ной таблице и было добавлено при проведении нормализации.

Третья нормальная форма

Рассмотрим таблицу СОТРУДНИКИ, полученную после приведения исходной таблицы ко второй нормальной форме. Для этой таблицы существует функцио­нальная связь между полями «Код сотрудника» и «Зарплата». Однако эта функ­циональная связь является транзитивной.

Функциональная зависимость атрибутов X и отношения Я называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости X  Z и Z  Y, но отсутствует функциональная зависимость Z  X.

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

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

Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следу­ющие таги:

1. Определить все поля (или группы полей), от которых зависят другие поля.

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

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

Обратите внимание, что мы опять добавили новый атрибут – «Код должности», который является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отно­шения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет полу­чить таблицы с простыми первичными ключами, что облегчает выполнение операции свя­зывания таблиц. Такие первичные ключи, как правило, являются искусственными. Приведем рассматриваемую в качестве примера базу данных к третьей нормаль­ной форме. Для этого разделим таблицу СОТРУДНИКИ на две – СОТРУДНИ­КИ и ДОЛЖНОСТИ (рис. 4.4).

Рисунок 4.4 – Приведение базы данных к третьей нормальной форме

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

Рисунок 4.5 – Структура базы данных, приведенной

к третьей нормальной форме

На рис. 4.5 приведена схема базы данных, рассматриваемой в качестве примера и приведенной к третьей нормальной форме.