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

Как реализовать БД?

Таблицы БД – с ними проблем нет – реализуются файлами записей (file of record).

Проблема: как реализовать отношения?

Кажется, совершенно естественно реализовать отношения программно, снабдив СУБД механизмом навигации – внутренними алгоритмами прохода по связи. Например, от родителей к детям. Именно такой навигационный подход использовался в ранних иерархических БД (название происходит от топологии (вида) отношений). В иерархических БД реализуются древовидные отношения, в них каждый потомок имеет одного предка. В сетевой топологии разрешены произвольные отношения, но не разрешены отношения «многие ко многим», но разрешено множественное наследование. Преимуществом навигационного подхода является высокая скорость при выполнении запроса, недостатком – узкий круг разрешённых запросов.

Очевидно, что кроме выделенных, БД всегда содержат информацию о множестве других отношений.

Пример: отношение однофамильцев или быть старше в примере с жителями.

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

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

Что может быть проще равенства?

<r₁,r₂>ÎR E(r₁)=E(r₂)

Пусть PK – некоторое выражение над полями таблицы PT. Назовём это выражение первичным ключом (primary key), если оно различает каждую пару записей PT.

"r₁,r₂ÎPT PK(r₁)¹PK(r₂) (r₁¹r₂)

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

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

Пусть FK – также некоторое выражение над другой таблицей CT. Говорят, что FK – внешний ключ (foreign key), если все его значения присутствуют среди значений PK.

В случае, когда FK(r₂)=PK(r₁), r₂ÎCT, r₁ÎPT, говорят, что запись r₂ ссылается на запись r₁.

Итак, для реализации отношения «один ко многим» достаточно найти PK и FK такие, что PK(r₁)=FK(r₂).

Откуда берутся ключевые выражения?

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

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

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