Файл: Базы данных - уч. пособие.pdf

3.2 Свойства отношений

41

Рис. 3.3 – Ненормализованное отношение ГРУППЫ

Отношение СТУДЕНТЫ (рис. 3.4) является нормализованным вариантом отно-

шения ГРУППЫ. В этом отношении на пересечении столбца и строки находится
только одно значение.

Рис. 3.4 – Отношение СТУДЕНТЫ, находящееся в 1NF

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

речислимой информации типа «белый, синий, черный» остается на совести разра-
ботчика БД — либо принимается тезис о необходимости четкого описания объекта
предметной области для обеспечения возможности манипулирования информаци-
ей, представленной в этом поле, что влечет необходимость дальнейшей нормали-
зации; либо эта информация принимается как сопроводительная и имеет статус
примечания.

Однако в ряде случаев крайне необходимо избавиться от такой «неявной ненор-

мализованности» отношений. Рассмотрим следующий пример: пусть в БД хранит-
ся информация о книгах (таблица «Книги»). В поле «Автор» хранится информация
об авторах книги (рис. 3.5).

Рис. 3.5 – Фрагмент таблицы «Книги»

Легко заметить, что в том случае если одна книга написана несколькими авто-

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

42

Глава 3. Реляционная модель

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

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

образований. Во-первых, необходимо создать справочник-классификатор «Авто-
ры», где будет храниться информация обо всех авторах. Во-вторых, необходимо
создать промежуточную таблицу «Авторы_книг», которая позволит связать табли-
цы «Книги» и «Авторы», обеспечив возможность введения информации о том, что
«один автор может написать несколько книг, а одна книга может быть написана
несколькими авторами». В-третьих, осталось удалить поле «Автор» из таблицы
«Книги», как содержащее избыточную информацию (рис. 3.6, 3.7).

Рис. 3.6 – Схема данных БД после нормализации таблицы «Книги»

Рис. 3.7 – Фрагменты таблиц «Книги», «Авторы_книг» и «Авторы»

Кроме этого, как отмечалось выше, в современных реляционных СУБД допус-

кается хранение в полях таблиц сложных объектов (например, полей типа OLE),
что, однако, не противоречит принципу атомарности данных, поскольку в данных
полях содержится либо ссылка на внешний файл объекта, либо непосредственно
сам OLE-объект, являющийся неделимой информационной единицей.

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

В предыдущих главах, говоря о иерархической и сетевой моделях данных,

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

3.2 Свойства отношений

43

и основы построения реляционной модели остаются неизменными на протяжении
десятилетий. Основы проектирования реляционных моделей подробно изложены
в [7–10]. Так, Кристофер Дейт в своей книге [10] дает следующее определение:

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Единственной структурой данных, используемой в реляционных БД, является

нормализованное n-арное отношение — это характеристика структурной части.

Что касается целостной части реляционной модели данных, то для нее фик-

сируются четыре базовых требования, характерные для реляционных СУБД:

• первое требование, согласно которому отношение должно обладать пер-

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

• второе — требование целостности по ссылкам или ссылочная целостность;

• третье — требование целостности доменов;

• четвертое — требование целостности, определяемой пользователем.

В общем смысле целостность базы данных можно рассматривать как соответ-

ствие информации, хранящейся в базе данных, её структуре, внутренней логике,
всем правилам её формирования и требованиям предметной области. Каждое пра-
вило, которое налагает некоторое требование (ограничение) на возможное состоя-
ние базы данных, называется ограничением целостности (integrity constraint).

Одной из задач специалиста, занятого анализом предметной области (анали-

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

В манипуляционной части модели утверждаются два фундаментальных меха-

низма манипулирования реляционными БД — реляционная алгебра и реляционное
исчисление, на основе которых строятся все известные реляционные языки управ-
ления БД.

44

Глава 3. Реляционная модель

3.3 Целостная часть реляционной модели данных

3.3.1 Целостность сущности

Что касается целостности сущности, то это понятие напрямую связано со свой-

ством уникальности кортежей отношения (см. раздел 3.2.1) — каждый кортеж отно-
шения должен отличатся от любого другого кортежа этого отношения, т. е. любое
отношение должно обладать первичным ключом.

Здесь необходимо отметить главное требование к формированию значения пер-

вичного ключа — атрибуты, входящие в состав первичного ключа, не могут прини-
мать несуществующие (null)-значения.

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

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

3.3.2 Ссылочная целостность

Целостность по ссылкам, или ссылочная целостность, может рассматриваться

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

При описании объектов предметной области обойтись одним отношением, со-

блюдая принцип нормализации, бывает очень сложно, а зачастую и практически
невозможно. Таким образом, один объект может быть описан в нескольких от-
ношениях. Поясним смысл требования целостности по сущностям на примере из
раздела 3.2. В результате проектирования БД «ВУЗ» схема данных содержит три
отношения (таблицы) «Студент», «Дисциплины» и «Успеваемость» со схемами,
представленными на рисунке 3.8.

Рис. 3.8 – Фрагмент схемы данных БД «ВУЗ»

Атрибуты «№ зачетной книжки» и «Код дисциплины» появляются в отноше-

нии «Успеваемость» для обеспечения возможности восстановить полную инфор-
мацию об успеваемости студентов вуза. Значение атрибута «№ зачетной книжки»
отношения «Успеваемость» должно соответствовать значению атрибута «№ зачет-
ной книжки» в каком-либо кортеже отношения «Студент». Значение атрибута «Код
дисциплины» отношения «Успеваемость» должно соответствовать значению атри-
бута «Код дисциплины» в каком-либо кортеже отношения «Дисциплины».

Атрибуты «№ зачетной книжки» и «Код дисциплины» в отношении «Успевае-

мость» называются внешними ключами.

3.3 Целостная часть реляционной модели данных

45

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Таким образом, отношение, в котором на каком-либо атрибуте (может быть

составным) определен внешний ключ, ссылается на отношение, в котором соот-
ветствующий атрибут является первичным ключом. Говорят также, что отношения
связаны по некоторому ключу.

Требование целостности по ссылкам (требование внешнего ключа) состоит

в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся
отношении, должен найтись кортеж с таким же значением первичного ключа в от-
ношении, на которое ведет ссылка, либо значение внешнего ключа должно быть
неопределенным, т. е. ни на что не указывать [1].

Для нашего примера это означает, что если в успеваемости студента указан

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

Для обеспечения ограничения по ссылкам при добавлении и изменении дан-

ных ссылающегося отношения необходимо обеспечить проверку на ввод значений
внешнего ключа. При изменении значения первичного ключа в отношениях необ-
ходимо изменять соответствующие значения внешних ключей. В некоторых СУБД
эта процедура производится автоматически. Такой принцип получил название —
каскадное обновление данных.

При удалении кортежа из отношения, на которое ведет ссылка, существуют

три подхода, поддерживающих целостность по ссылкам [1].

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Можно говорить, что любая база данных обладает свойством ссылочной це-

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