Реляционные базы данных

Сторонники нормализации ввели собственную терминологию и на­зывают простые вещи специальными словами. Таблица такого вида, как на рис. 5.3, называется отношением. База данных, построенная с помощью отношений, называется реляционной базой данных. Таким образом, реляционная база данных строится из «плоских» (двумерных) наборов элементов данных.

Отношение, или таблица, - это набор кортежей. Если кортежи являются n-мерными, т. е. если таблица имеет n столбцов, отношение называется отношением степени п. Отношение степени 2 называется бинарным, отношение степени 3 - тернарным, а отношение степе­ни п - п - арным.

Набор значений элементов данных одного типа, т. е. один столбец таблицы, называется доменом. Столбец с номером j называется j - м доменом отношения.

В математике R определяется как отношение, заданное на n мно­жествах S1, S2, ..., Sn (не обязательно различных), если оно пред­ставляет собой набор кортежей, таких, что первый элемент каждого кортежа есть элемент из S1, второй - элемент из S2 и т. д.

Для сенсация таких отношений и операций над ними существуют точные математические обозначения, основанные на алгебре отноше­ний или исчисления отношений. Кодд [4] разработал специальный язык манипулирования денными для такой базы. В этом языке может быть выражен обычный диалог человека с машиной. Мы, однако, будем использовать нематематический язык для описания способов манипулирования кортежами.

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

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

Первые разработки

Несколько разработок реляционных баз данных уже известно. В работах [8-11] обсуждаются наиболее ранние из них (предшество­вавшие работе Кодда). Работы [12-18] относятся к более поздним исследованиям. В работах [8-10, 12] используются бинарные отно­шения, т. е. отношения только двух доменов. Известно, что бинарные отношения придают наибольшую гибкость базе. Однако в коммерче­ских задачах удобными являются отношения различных степеней. Большинство баз данных, использующих бинарные отношения, пред­ложено для работы с данными, которые по структуре гораздо проще, чем в обычных коммерческих системах.

Повторяющиеся группы

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

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

Рис. 13.1. Выделение повторяющейся группы в отдельную таблицу путем расщепления

Полученному таким образом новому файлу (таблице) присваивается собственное имя. Новый файл должен иметь ключи, по которым однозначно определяется любой кортеж. Элемент данных НОМЕР-ЗАКАЗА повторен в файле ПАРТИЯ-ТОВАРА и совместно с элементом данных НОМЕР-ИЗДЕЛИЯ образует одно­значный идентификатор кортежа.

Можно возразить, что при этом увеличивается избыточность: эле­мент данных НОМЕР-ЗАКАЗА фигурирует в базе дважды. Однако при нормализации вовсе не требуется, чтобы некоторый элемент дан­ных действительно появлялся более чем в одной записи в качестве идентификатора. Подобное дублирование вовсе не влечет дополнитель­ных расходов памяти, ибо нормализация связана с логическим пред­ставлением структур с точки зрения пользователя и не имеет отноше­ния к способу их физического представления в памяти.

Если при разработке базы не устранить подобным образом повто­ряющиеся группы, то не исключена возможность, что это потребуется сделать в процессе развития базы. Например, со временем могут по­явиться программы, в которых некоторый кортеж файла ПАРТИЯ - ТОВАРА (рис. 13.1) будет привязан к различным записям. База данных ЗАКАЗ-НА-ЗАКУПКУ может разрастись до базы, изображенной на рис. 6.9, в которой появляются связи между записями ПОСТАВ­ЩИК и ПАРТИЯ-ТОВАРА. В этом случае (рис. 6.9) целесообразно сделать так, чтобы запись ПАРТИЯ-ТОВАРА была отдельной записью, а не повторяющейся группой в записи файла ЗАКАЗ-НА-ЗАКУПКУ. Если возникнет необходимость в выделении повторяющейся группы после того, как программы уже написаны, то придется переписывать и отлаживать эти программы заново. Нормализация базы и независи­мость данных относительно прикладных программ позволяют избе­жать дополнительных расходов в процессе эксплуатации.

КЛЮЧИ

Каждый кортеж должен иметь ключ - идентификатор. Иногда кортеж может идентифицироваться значением одного атрибута. На рис. 13.1 атрибут НОМЕР-ЗАКАЗА однозначно определяет кортеж файла ЗАКАЗ-НА-ЗАКУПКУ. Но бывает и так, что для идентифика­ции кортежа необходимы значения нескольких атрибутов. Для опре­деления кортежа файла ПАРТИЯ-ТОВАРА на рис. 13.1 недостаточно одного атрибута, и ключ должен состоять из двух атрибутов: НОМЕР- ЗАКАЗА и НОМЕР-ИЗДЕЛИЯ. Ключ должен обладать двумя свойствами:

1. Однозначная идентификация кортежа, кортеж должен одно­значно определяться значением ключа.

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

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

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

ЗАКАЗ-НА-ЗАКУПКУ (НОМЕР-ЗАКАЗА, НОМЕР-ПОСТАВЩИ­КА, ДАТА-ЗАКАЗА, ДАТА-ПОСТАВКИ, ИТОГО)

ПАРТИЯ-ТОВАРА (НОМЕР-ЗАКАЗА, НОМЕР-ИЗДЕЛИЯ, ЦЕ­НА, КОЛИЧЕСТВО)

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