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

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

Пока что речь шла только о первичных и внешних ключах. Но помимо них есть еще несколько типов ключей.

Суперключ- это совокупность атрибутов, уникальным образом идентифицирующих каждую запись. Например, в табл. 5.2 в качестве суперключа можно использовать объединение всех атрибутов или же, к примеру, столбцов Фамилия и Дата рождения . А вот сочетание столбцов Фамилия и Команда не подойдет, так как в команде Oakland Athletics есть два игрока-однофамильца.

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

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

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

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

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

Отношения 63

Отношения

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

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

В идеально спроектированной реляционной базе данных отношение один к одному (1:1) не нужно. Если каждой строке одной таблицы соответствует одна строка другой таблицы, то это обычно свидетельствует о том, что обе таблицы нужно объединить в единое целое. Исключение из правила- необычный случай, когда число столбцов таблицы превышает предел, установленный в СУБД. В MySQL этот предел равен 3000, так что маловероятно, чтобы кому-то пришло в голову его превысить. Есть СУБД, где предельное число столбцов гораздо меньше, например 250, но даже этого числа вполне достаточно для большинства приложений. В будущих версиях MySQL жесткий предел будет вообще снят, и создавать столбцы можно будет до тех пор, пока не закончится место на диске.

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

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

Выход из положения заключается в декомпозиции, т.е. разбивке отношения M:N на два отношения 1:N. Этоозначает, что ссылки между двумя таблицами будут вынесены в третью таблицу, содержащую всего два столбца. В них будут сопоставляться первичные ключи основных таблиц.

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

Отношение 1:N, соединяющее столбцы одной и той же таблицы, называется самообъединением. Оно используется для отображения иерархических структур. Подразумевается, что внешний ключ ссылается на родительскую строку собственной таблицы.

Рис. 5.1. Формирование отношения M:N посредством промежуточной таблицы

Реляционные операции

Как уже упоминалось, реляционная модель основана на реляционной алгебре доктора Кодда. В свою очередь, за реляционной алгеброй стоит теория множеств, в которой определен целый ряд операций над множествами. Как писал сам доктор Кодд, для реляционной модели представляют интерес только те операции, результатом которых являются множества. Отсюда имеем восемь простейших операций: выборка, проекция, пересечение, сложение, вычитание, умножение, деление и переименование. На их основе строятся более сложные операции, называемые объединениями. В языке SQL большинство перечисленных операций реализуется с помощью инструкции SELECT.

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

Операция выборки выполняется над одной таблицей. Результирующая таблица будет содержать все исходные столбцы, но, возможно, не все строки. С ло гической точки зрения это фильтрация строк. Предположим, нам нужно получить список бейсболистов, родившихся до 1-го января 1975 г. Результат подобной выборки показан в табл. 5.4.

Фамилия

Giambi

Seanz

Bonds

Giambi

Snow

Дата рождения

1971-01-08 1970-10-08 1964-07-24

1974-09-30

1968-02-26

Позиция Команда

Первая база 1

Лучший отбивающий 1

Внешнее поле 2

Внешнее поле 1

Первая база 2