Реляционные модели базы данных
некоторая таблица задавала отношение,
необходимо, чтобы таблица имела простую структуру (содержала бы только строки и
столбцы, причем, в каждой строке было бы одинаковое количество полей), в
таблице не должно быть одинаковых строк, любой столбец таблицы должен содержать
данные только одного типа, все используемые типы данных должны быть простыми.
Каждое отношение можно считать классом эквивалентности
таблиц, для которых выполняются следующие условия:
Таблицы имеют одинаковое количество столбцов.
Таблицы содержат столбцы с одинаковыми наименованиями.
Столбцы с одинаковыми наименованиями содержат данные
из одних и тех же доменов.
Таблицы имеют одинаковые строки с учетом того, что
порядок столбцов может различаться.
Все такие таблицы есть различные изображения одного и
того же отношения.
Труднее всего дать определение вещей, которые всем
понятны. Если давать не строгое, описательное определение, то всегда остается
возможность неправильной его трактовки. Если дать строгое формальное
определение, то оно, как правило, или тривиально, или слишком громоздко. Именно
такая ситуация с определением отношения в Первой Нормальной Форме (1НФ). Дать определение
1НФ сложно ввиду его тривиальности. Поэтому, приведем несколько объяснений.
1. Говорят, что отношение 
находится в
1НФ, если оно удовлетворяет определению 2.
Это, собственно, тавтология, ведь из определения 2
следует, что других отношений не бывает. Действительно, определение 2
описывает, что является отношением, а что - нет, следовательно, отношений в
непервой нормальной форме просто нет.
2. Говорят, что отношение находится в
1НФ, если его атрибуты содержат только скалярные (атомарные) значения.
Опять же, второе определение опирается на понятие
домена, а домены определены на простых типах данных.
Не первую нормальную форму можно получить, если
допустить, что атрибуты отношения могут быть определены на сложных типах данных
- массивах, структурах, или даже на других отношениях. Легко себе представить
таблицу, у которой в некоторых ячейках содержатся массивы, в других ячейках -
определенные пользователями сложные структуры, а в третьих ячейках - целые
реляционные таблицы, которые в свою очередь могут содержать такие же сложные
объекты. Именно такие возможности предоставляются некоторыми современными
пост-реляционными и объектными СУБД.
Требование, что отношения должны содержать только
данные простых типов, объясняет, почему отношения иногда называют плоскими
таблицами (plain table). Действительно, таблицы, задающие отношения двумерны.
Одно измерение задается списком столбцов, второе измерение задается списком
строк. Пара координат (Номер строки, Номер столбца) однозначно идентифицирует
ячейку таблицы и содержащееся в ней значение. Если же допустить, что в ячейке
таблицы могут содержаться данные сложных типов (массивы, структуры, другие
таблицы), то такая таблица будет уже не плоской. Например, если в ячейке
таблицы содержится массив, то для обращения к элементу массива нужно знать три
параметра (Номер строки, Номер столбца, номер элемента в массиве). Таким
образом появляется третье объяснение Первой Нормальной Формы: Отношение находится в
1НФ, если оно является плоской таблицей[7]
.
В данной главе была рассмотрена только классическая
реляционная теория, в которой все отношения имеют только атомарные атрибуты и
заведомо находятся в 1НФ.
2. Целостность
реляционных данных
Во второй части реляционной модели данных определяются
два ограничения, которые должны выполняться в любой реляционной базе данных.
Это:
Целостность сущностей.
Целостность внешних ключей.
Прежде, чем описывать целостность сущностей,
необходимо описать использование null-значений в реляционных базах данных.
2.1 Null-значения
Основное назначение баз данных состоит в том, чтобы
хранить и предоставлять информацию о реальном мире. Для представления этой
информации в базе данных используются привычные для программистов типы данных -
строковые, численные, логические и т.п. Однако в реальном мире часто
встречается ситуация, когда данные неизвестны или не полны. Например, место
жительства или дата рождения человека могут быть неизвестны (база данных
разыскиваемых преступников). Если вместо неизвестного адреса уместно было бы
вводить пустую строку, то что вводить вместо неизвестной даты? Ответ - пустую
дату - не вполне удовлетворителен, т.к. простейший запрос "выдать список
людей в порядке возрастания дат рождения" даст заведомо неправильных
ответ.
Для того чтобы обойти проблему неполных или
неизвестных данных, в базах данных могут использоваться типы данных, пополненные
так называемым null-значением. Null-значение - это, собственно, не значение, а
некий маркер, показывающий, что значение неизвестно.
Таким образом, в ситуации, когда возможно появление
неизвестных или неполных данных, разработчик имеет на выбор два варианта.
Первый вариант состоит в том, чтобы ограничиться
использованием обычных типов данных и не использовать null-значения, а вместо
неизвестных данных вводить либо нулевые значения, либо значения специального
вида - например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть
те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на
пользователя (или на разработчика) ложится ответственность на правильную
трактовку таких данных. В частности, может потребоваться написание специального
программного кода, который в нужных случаях "вылавливал" бы такие
данные. Проблемы, возникающие при этом очевидны - не все данные становятся
равноправны, требуется дополнительный программный код,
"отслеживающий" эту неравноправность, в результате чего усложняется
разработка и сопровождение приложений.
Второй вариант состоит в использовании null-значений
вместо неизвестных данных. За кажущейся естественностью такого подхода
скрываются менее очевидные и более глубокие проблемы. Наиболее бросающейся в глаза
проблемой является необходимость использования трехзначной логики при
оперировании с данными, которые могут содержать null-значения. В этом случае
при неаккуратном формулировании запросов, даже самые естественные запросы могут
давать неправильные ответы. Есть более фундаментальные проблемы, связанные с
теоретическим обоснованием корректности введения null-значений, например,
непонятно вообще, входят ли null-значения в домены или нет.
Вопрос о проблемах использования null-значений в
теории реляционных баз данных окончательно не решен. Основоположник
реляционного подхода Кодд считал null-значения неотъемлемой частью реляционной
модели, хотя К. Дейт выступает против null-значений[8]
.
2.2 Потенциальные ключи
и целостность сущностей
По определению, тело отношения есть множество
кортежей, поэтому отношения не могут содержать одинаковые кортежи. Это значит,
что каждый кортеж должен обладать свойством уникальности. На самом деле,
свойством уникальности в пределах отношения могут обладать отдельные атрибуты
кортежей или группы атрибутов. Такие уникальные атрибуты удобно использовать
для идентификации кортежей.
Пусть дано отношение . Подмножество
атрибутов 
отношения будем называть
потенциальным ключом, если обладает
следующими свойствами:
Свойством уникальности - в отношении не может быть
двух различных кортежей, с одинаковым значением .
Свойством неизбыточности - никакое подмножество в не обладает
свойством уникальности.
Любое отношение имеет по крайней мере один
потенциальный ключ. Действительно, если никакой атрибут или группа атрибутов не
являются потенциальным ключом, то, в силу уникальности кортежей, все атрибуты
вместе образуют потенциальный ключ. Потенциальный ключ, состоящий из одного
атрибута, называется простым. Потенциальный ключ, состоящий из нескольких
атрибутов, называется составным. Отношение может иметь несколько потенциальных
ключей. Традиционно, один из потенциальных ключей объявляется первичным, а остальные
- альтернативными. Различия между первичным и альтернативными ключами могут
быть важны в конкретной реализации реляционной СУБД, но с точки зрения
реляционной модели данных, нет оснований выделять таким образом один из
потенциальных ключей. Понятие потенциального ключа является семантическим
понятием и отражает некоторый смысл (трактовку) понятий из конкретной
предметной области. Для того чтобы проиллюстрировать этот факт, рассмотрим
отношение "Сотрудники" (Приложение 1).
При первом взгляде на таблицу, изображающую это
отношение, может показаться, что в таблице имеется три потенциальных ключа - в
каждой колонке таблицы содержатся уникальные данные. Однако среди сотрудников
могут быть однофамильцы и сотрудники с одинаковой зарплатой. Табельный же номер
по сути свой уникален для каждого сотрудника. Какие же соображения привели нас
к пониманию того, что в данном отношении только один потенциальный ключ -
"Табельный номер"? Именно понимание смысла данных, содержащихся в
отношении.
Попробуем представить это отношение в другом виде,
изменив наименования атрибутов:
| A |
B |
C |
| 1 |
Иванов |
1000 |
| 2 |
Петров |
2000 |
| 3 |
Сидоров |
3000 |
Предъявим кому-нибудь эту таблицу и не сообщим смысл
наименований атрибутов. Очевидно, что невозможно судить, не понимая смысла
данных, может или не может в этом отношении появиться, например, кортеж (1,
Петров, 3000). Если бы, кстати, такой кортеж появился (что, на первый взгляд,
вполне возможно, т.к. не нарушается уникальность кортежей), то мы точно смогли
бы сказать, что не является альтернативным ключом - ни один из атрибутов по
отдельности. Но мы не сможем сказать, что же является первичным ключом[9]
.
Потенциальные ключи служат средством идентификации
объектов предметной области, данные о которых хранятся в отношении. Объекты
предметной области должны быть различимы.
Потенциальные ключи служат единственным средством
адресации на уровне кортежей в отношении. Точно указать какой-нибудь кортеж
можно только зная значение его потенциального ключа.
Т.к. потенциальные ключи фактически служат
идентификаторами объектов предметной области (т.е. предназначены для различения
объектов), то значения этих идентификаторов не могут содержать неизвестные
значения. Действительно, если бы идентификаторы могли содержать null-значения,
то мы не могли бы дать ответ "да" или "нет" на вопрос,
совпадают или нет два идентификатора.
Это определяет следующее правило целостности
сущностей:
Атрибуты, входящие в состав некоторого потенциального
ключа не могут принимать null-значений.
2.3 Внешние ключи и их
целостность
Различные объекты предметной области, информация о
которых хранится в базе данных, всегда взаимосвязаны друг с другом. Например,
накладная на поставку товара содержит список товаров с количествами и ценами,
сотрудник предприятия имеет детей, числится в подразделении и т.д. Термины
"содержит", "имеет", "числится" отражают взаимосвязи
между понятиями "накладная" и "список товаров",
"сотрудник" и "дети", "сотрудник" и
"подразделение". Такие взаимосвязи отражаются в реляционных базах
данных при помощи внешних ключей, связывающих несколько отношений.
Рассмотрим пример с поставщиками и поставками деталей.
Предположим, что нам требуется хранить информацию о наименовании поставщиков,
наименовании и количестве поставляемых ими деталей, причем каждый поставщик
может поставлять несколько деталей и каждая деталь может поставляться несколькими
поставщиками. Можно предложить хранить данные в следующем отношение (
Приложение 2).
Потенциальным ключом этого отношения может выступать
пара атрибутов {"Номер поставщика", "Номер детали"} - в
таблице они выделены курсивом.
Приведенный способ хранения данных обладает рядом
недостатков.
Что произойдет, если изменилось наименование
поставщика? Т.к. наименование поставщика повторяется во многих кортежах
отношения, то это наименование нужно одновременно изменить во всех кортежах,
где оно встречается, иначе данные станут противоречивыми. То же самое с
наименованиями деталей. Значит, данные хранятся в нашем отношении с большой
избыточностью.
Далее, как отразить факт, что некоторый поставщик,
например Петров, временно прекратил поставки деталей? Если мы удалим все
кортежи, в которых хранится информация о поставках этого поставщика, то мы
потеряем данные о самом Петрове как потенциальном поставщике. Выйти из этого
положения, оставив в отношении кортеж типа (2, Петров, NULL, NULL, NULL) мы не
можем, т.к. атрибут "Номер детали" входит в состав потенциального
ключа и не может содержать null-значений. То же самое произойдет, если
некоторая деталь временно не поставляется никаким поставщиком. Получается, что
мы не можем хранить информацию о том, что есть некий поставщик, если он не
поставляет хотя бы одну деталь, и не можем хранить информацию о том, что есть
некоторая деталь, если она никем не поставляется.
Подобные проблемы возникают потому, что мы смешали в
одном отношении различные объекты предметной области - и данные о поставщиках,
и данные о деталях, и данные о поставках деталей. Говорят, что это отношение
плохо нормализовано (просто нормализованным оно является хотя бы потому, что
оно есть отношение и, следовательно, автоматически находится в 1НФ).
О том, как правильно нормализовать отношения, будет
сказано в следующих главах, сейчас же предложим разнести данные по трем
отношениям - "Поставщики", "Детали", "Поставки".
Для нас важно выяснить, каким образом данные, хранящиеся в этих отношениях
взаимосвязаны друг с другом. Эта связь определяется семантикой предметной
области и описывается фразами: "Поставщики выполняют Поставки",
"Детали поставляются через Поставки". Эти две взаимосвязи косвенно
определяют новую взаимосвязь между "Поставщиками" и
"Деталями": "Детали поставляются Поставщиками".
Эти фразы отражают различные типы взаимосвязей. Чтобы
более точно отразить предметную область, можно иначе переформулировать фразы:
"Один Поставщик может выполнять несколько Поставок", "Одна
Деталь может поставляться несколькими Поставками". Это пример взаимосвязи
типа "один-ко-многим". Взаимосвязь между "Поставщиками" и
"Деталями" можно переформулировать так: "Несколько Деталей может
поставляться несколькими Поставщиками". Это пример взаимосвязи типа
"много-ко-многим".
В реляционных базах данных основными являются
взаимосвязи типа "один-ко-многим". Взаимосвязи типа
"много-ко-многим" реализуются использованием нескольких взаимосвязей
типа "один-ко-многим". Отношение, входящее в связь со стороны
"один" (например, "Поставщики"), называют родительским
отношением. Отношение, входящее в связь со стороны "много" (например,
"Поставки"), называется дочернем отношением.
Механизм реализации взаимосвязи
"один-ко-многим" состоит в том, что в дочернее отношение добавляются
атрибуты, являющиеся ссылками на ключевые атрибуты родительского отношения. Эти
атрибуты и являются внешними ключами, определяющими, с какими кортежами
родительского отношения связаны кортежи дочернего отношения. Такие атрибуты еще
называют мигрирующими из родительского отношения.
Таким образом, наш пример с поставщиками и
поставляемыми деталями должен выглядеть следующим образом:
Таблица 2 Отношение "Поставщики"
| Номер поставщика |
Наименование поставщика |
| 1 |
Иванов |
| 2 |
Петров |
| 3 |
Сидоров |
Таблица 3 Отношение "Детали"
| Номер детали |
Наименование детали |
| 1 |
Болт |
| 2 |
Гайка |
| 3 |
Винт |
Таблица 4 Отношение "Поставки"
| Номер поставщика |
Номер детали |
Поставляемое количество |
| 1 |
1 |
100 |
| 1 |
2 |
200 |