Классификация бинарных отношений

RXY

!) R – отношение «один ко многим», если

xX, y,y^| R (<x,y>R, <x,y^|>R  y=y^|)

В этом случае таблица y называется родительской, а x – дочерней.

2) R – отношение «один ко многим», если оно отношение «один ко многим», но наоборот: для каждого y существует не более одного соответствующего ему x.

yY, x,x^|R (<x,y>R, <x^|,y>R  x=x^| )

Все оставшиеся отношения называются «многие ко многим». Наиболее популярным видом отношений СУБД является «один к одному».

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

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

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

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

Таблицы БД – с ними проблем нет – реализуются файлами записей (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, сиротой не считается.