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

Реляционная алгебра

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

Таблицы, строки и столбцы

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

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

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

Доктор Кодд называл таблицы отношениями, поскольку каждая строка таблицы неявно связана со всеми остальными строками, разделяя с ними общую форму записи. Собственно запись называется кортежем, т.е. набором взаимосвязанных атрибутов. Рассмотрим таблицу, состоящую из четырех строк и трех столбцов (табл. 5.1). Все записи этой таблицы связаны друг с другом, так как они описывают бейсболистов.

У каждого столбца есть название и тип. Типы данных будутрассматриваться в главе 11, Типы столбцов и индексов , а пока лишь скажем, что базовыми типами считаются строковый, числовой и дата/время. В табл. 5.1 столбцы Фамилия и Позиция имеют строковый тип, а в столбце Дата рождения находятся значения даты.

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

Порядок строк в таблице произволен и не имеет никакого значения. По сути, он отражает очередность записи строк на диск и может быть разным. Как будет показано в главе 6, Язык SQL , есть способы указания порядка записей, возвращаемых в результате запроса.

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

В табл. 5.1 строки можно идентифицировать по столбцу Фамилия . Но что будет, если команда включит в свой состав игрока-однофамильца? Придется взять за первичный ключ комбинацию фамилии и даты рождения. О концепции ключей рассказывается в следующем разделе.

Ключи 61

Предположим, в команде появляется новый игрок, позиция которого на поле еще не определена. В этом случае в поле Позиция следует занести значение NULL. Это специальная константа, не равная пустой строке. Она означает отсутствие значения.

Ключи

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

Давайте расширим таблицу бейсболистов, добавив в нее столбец Команда (табл. 5.2). В этом столбце хранится идентификатор команды, а не ее название. Соответствия между идентификаторами и названиями находятся в другой таблице (табл. 5.3).

Таблица 5:2. Таблица бейсболистов j?..,. i v..

Столбец Идентификатор в табл. 5.3 является первичным ключом. Значение первичного ключа уникальным образом идентифицирует каждую строку. Только значения пер вичного ключа могут встречаться в столбце Команда табл. 5.2. Последний, в свою очередь, называется внешним ключом, так как его значенияберутся из внешней таблицы.

Идентификатор

Название

Oakland Athletics San Francisco Giants

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