Реляционная модель

Реляционная модель ( RM ) — это подход к управлению данными с использованием структуры и языка, соответствующих логике предикатов первого порядка , впервые описанный в 1969 году английским ученым-компьютерщиком Эдгаром Ф. Коддом , ^[1]^[2] , где все данные представлены в виде кортежей , сгруппированных в отношения . База данных, организованная в терминах реляционной модели, называется реляционной базой данных .

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

Большинство реляционных баз данных используют определение данных SQL и язык запросов; эти системы реализуют то, что можно считать инженерным приближением к реляционной модели. Таблица в схеме базы данных SQL соответствует предикатной переменной; содержимое таблицы - отношению; ключевые ограничения, другие ограничения и запросы SQL соответствуют предикатам. Однако базы данных SQL во многих деталях отклоняются от реляционной модели, и Кодд яростно выступал против отклонений, которые ставят под угрозу исходные принципы. ^[3]

История

Реляционная модель была разработана Эдгаром Ф. Коддом как общая модель данных, и впоследствии продвигалась Крисом Дейтом и Хью Дарвеном среди других. В своем Третьем Манифесте 1995 года Дейт и Дарвен пытаются продемонстрировать, как реляционная модель может вместить определенные «желаемые» объектно-ориентированные функции. ^[4]

Расширения

Спустя несколько лет после публикации своей модели 1970 года Кодд предложил версию с трехзначной логикой (True, False, Missing/ NULL ) для работы с отсутствующей информацией, а в своей работе «Реляционная модель для управления базами данных» версии 2 (1990) он пошел на шаг дальше, предложив версию с четырехзначной логикой (True, False, Missing but Applicable, Missing but Inapplicable). ^[5]

Концептуализация

Основные понятия

Отношение состоит из заголовка и тела . Заголовок определяет набор атрибутов , каждый из которых имеет имя и тип данных (иногда называемый доменом ). Количество атрибутов в этом наборе является степенью или арностью отношения . Тело представляет собой набор кортежей . Кортеж представляет собой коллекцию из n значений , где n — степень отношения, а каждое значение в кортеже соответствует уникальному атрибуту. ^[6] Количество кортежей в этом наборе является кардинальностью отношения . ^[7]^{: 17–22}

Отношения представлены реляционными переменными или relvars , которые могут быть переназначены. ^[7]^{: 22–24} База данных представляет собой набор relvars. ^[7]^{: 112–113}

В этой модели базы данных следуют принципу информации : в любой момент времени вся информация в базе данных представлена исключительно значениями в кортежах, соответствующих атрибутам, в отношениях, идентифицированных relvars. ^[7]^{: 111}

Ограничения

База данных может определять произвольные булевы выражения как ограничения . Если все ограничения оцениваются как истинные , база данных согласована ; в противном случае она несогласованна . Если изменение relvar базы данных оставит базу данных в несогласованном состоянии, это изменение является незаконным и не должно быть успешным. ^[7]^{: 91}

В общем случае ограничения выражаются с помощью реляционных операторов сравнения, из которых теоретически достаточно только одного — «является подмножеством» (⊆). ^{[ необходима цитата ]}

Два особых случая ограничений выражаются как ключи и внешние ключи :

Ключи

Кандидатный ключ , или просто ключ , — это наименьшее подмножество атрибутов, гарантированно однозначно дифференцирующее каждый кортеж в отношении. Поскольку каждый кортеж в отношении должен быть уникальным, каждое отношение обязательно имеет ключ, который может быть его полным набором атрибутов. Отношение может иметь несколько ключей, поскольку может быть несколько способов однозначно дифференцировать каждый кортеж. ^[7]^{: 31–33}

Атрибут может быть уникальным среди кортежей, не будучи ключом. Например, отношение, описывающее сотрудников компании, может иметь два атрибута: ID и Name. Даже если в настоящее время ни один сотрудник не имеет одинакового имени, если в конечном итоге возможно нанять нового сотрудника с таким же именем, как у текущего сотрудника, подмножество атрибутов {Name} не является ключом. И наоборот, если подмножество {ID} является ключом, это означает не только то, что в настоящее время ни один сотрудник не имеет одинакового ID, но и то, что ни один сотрудник никогда не будет иметь одинакового ID. ^[7]^{: 31–33}

Внешние ключи

Внешний ключ — это подмножество атрибутов {A} в отношении R ₁ , которое соответствует ключу другого отношения R ₂ , со свойством, что проекция R ₁ на {A} является подмножеством проекции R ₂ на {A} . Другими словами, если кортеж в R ₁ содержит значения для внешнего ключа, должен быть соответствующий кортеж в R _{2 ,} содержащий те же значения для соответствующего ключа. ^[7]^{: 34}

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

Пользователи (или программы) запрашивают данные из реляционной базы данных, отправляя ей запрос . В ответ на запрос база данных возвращает набор результатов.

Часто данные из нескольких таблиц объединяются в одну, выполняя join . Концептуально это делается путем взятия всех возможных комбинаций строк ( декартово произведение ), а затем отфильтровывания всего, кроме ответа.

Помимо join существует ряд реляционных операций. К ним относятся project (процесс исключения некоторых столбцов), restrict (процесс исключения некоторых строк), union (способ объединения двух таблиц с похожей структурой), difference (перечисляет строки в одной таблице, которых нет в другой), intersect (перечисляет строки, найденные в обеих таблицах) и product (упомянутый выше, который объединяет каждую строку одной таблицы с каждой строкой другой). В зависимости от того, к каким другим источникам вы обращаетесь, существует ряд других операторов, многие из которых можно определить в терминах перечисленных выше. К ним относятся semi-join, внешние операторы, такие как external join и external union, и различные формы деления. Затем идут операторы для переименования столбцов, а также операторы суммирования или агрегирования, и если вы разрешаете значения отношения как атрибуты (relation-valued attribute), то такие операторы, как group и ungroup.

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

Нормализация базы данных

Отношения классифицируются на основе типов аномалий, к которым они уязвимы. База данных, которая находится в первой нормальной форме, уязвима ко всем типам аномалий, в то время как база данных, которая находится в доменной/ключевой нормальной форме, не имеет аномалий модификации. Нормальные формы иерархичны по своей природе. То есть, самый низкий уровень — это первая нормальная форма, и база данных не может соответствовать требованиям для нормальных форм более высокого уровня, не выполнив сначала все требования меньших нормальных форм. ^[8]

Логическая интерпретация

Реляционная модель — это формальная система . Атрибуты отношения определяют набор логических предложений . Каждое предложение может быть выражено в виде кортежа. Тело отношения — это подмножество этих кортежей, представляющее, какие предложения истинны. Ограничения представляют собой дополнительные предложения, которые также должны быть истинными. Реляционная алгебра — это набор логических правил, которые могут обоснованно выводить заключения из этих предложений. ^[7]^{: 95–101}

Определение кортежа допускает уникальный пустой кортеж без значений, соответствующий пустому набору атрибутов. Если отношение имеет степень 0 (т. е. его заголовок не содержит атрибутов), оно может иметь либо кардинальность 0 (тело, не содержащее кортежей), либо кардинальность 1 (тело, содержащее единственный пустой кортеж). Эти отношения представляют булевы значения истинности . Отношение со степенью 0 и кардинальностью 0 является Ложным , тогда как отношение со степенью 0 и кардинальностью 1 является Истинным . ^[7]^{: 221–223}

Пример

Если отношение Employees содержит атрибуты {Name, ID} , то кортеж {Alice, 1} представляет предложение: "Существует сотрудник по имени Alice с ID 1 ". Это предложение может быть истинным или ложным. Если этот кортеж существует в теле отношения, предложение истинно (такой сотрудник есть). Если этого кортежа нет в теле отношения, предложение ложно (такой сотрудник отсутствует). ^[7]^{: 96–97}

Более того, если {ID} является ключом, то отношение, содержащее кортежи {Алиса, 1} и {Боб, 1}, будет представлять следующее противоречие :

Существует сотрудник с именем Алиса и идентификатором 1 .
Существует сотрудник с именем Боб и идентификатором 1 .
Не существует нескольких сотрудников с одинаковым идентификатором.

Согласно принципу взрыва , это противоречие позволило бы системе доказать, что любое произвольное предложение является истинным. База данных должна обеспечить соблюдение ограничения ключа, чтобы предотвратить это. ^[7]^{: 104}

Примеры

База данных

Идеализированный, очень простой пример описания некоторых relvars ( переменных отношений ) и их атрибутов:

Клиент ( Идентификатор клиента , Имя)
Заказ ( ID заказа , ID клиента , ID счета , дата)
Счет-фактура ( ID счета-фактуры , ID клиента , ID заказа , статус)

В этом дизайне у нас есть три relvar: Customer, Order и Invoice. Жирные, подчеркнутые атрибуты — это потенциальные ключи . Нежирные, подчеркнутые атрибуты — это внешние ключи .

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

Кандидатный ключ — это уникальный идентификатор, гарантирующий, что ни один кортеж не будет дублироваться; это превратило бы отношение во что-то другое, а именно в bag , нарушив базовое определение множества . Как внешние ключи, так и суперключи (включая кандидатные ключи) могут быть составными, то есть состоять из нескольких атрибутов. Ниже приведено табличное изображение отношения нашего примера Customer relvar; отношение можно рассматривать как значение, которое можно приписать relvar.

Отношение к клиентам

Если мы попытаемся вставить нового клиента с ID 123 , это нарушит конструкцию relvar, поскольку Customer ID является первичным ключом , а у нас уже есть клиент 123 . СУБД должна отклонить такую транзакцию , которая сделает базу данных несогласованной из-за нарушения ограничения целостности . Однако можно вставить другого клиента по имени Alice , если у этого нового клиента будет уникальный ID, поскольку поле Name не является частью первичного ключа.

Внешние ключи — это ограничения целостности, обеспечивающие, чтобы значение набора атрибутов извлекалось из потенциального ключа в другом отношении . Например, в отношении Order атрибут Customer ID является внешним ключом. Объединение — это операция , которая извлекает информацию из нескольких отношений одновременно. Объединяя relvar из примера выше, мы можем запросить базу данных для всех Customers, Orders и Invoices. Если бы нам нужны были только кортежи для определенного клиента, мы бы указали это с помощью условия ограничения. Если бы мы хотели получить все Orders для Customer 123 , мы могли бы запросить базу данных, чтобы вернуть каждую строку в таблице Order с Customer ID 123 .

В нашей вышеприведенной структуре базы данных есть изъян . Переменная отношения Invoice содержит атрибут Order ID. Таким образом, каждый кортеж в переменной отношения Invoice будет иметь один Order ID, что подразумевает, что для каждого счета-фактуры существует ровно один Order. Но в действительности счет-фактура может быть создана для многих заказов или даже для никакого конкретного заказа. Кроме того, переменная отношения Order содержит атрибут Invoice ID, что подразумевает, что у каждого Order есть соответствующий Invoice. Но опять же, это не всегда верно в реальном мире. Иногда заказ оплачивается несколькими счетами-фактурами, а иногда оплачивается без счета-фактуры. Другими словами, может быть много счетов-фактур на заказ и много заказов на счет-фактуру. Это отношение «многие ко многим» между Order и Invoice (также называемое неспецифическим отношением ). Для представления этого отношения в базе данных следует ввести новую переменную отношения, роль которой заключается в указании соответствия между Order и Invoice:

OrderInvoice ( Идентификатор заказа , Идентификатор счета )

Теперь переменная Order имеет отношение «один ко многим» к таблице OrderInvoice, как и переменная Invoice. Если мы хотим получить каждый счет-фактуру для определенного заказа, мы можем запросить все заказы, где идентификатор заказа в отношении Order равен идентификатору заказа в OrderInvoice, и где идентификатор счета-фактуры в OrderInvoice равен идентификатору счета-фактуры в Invoice.

Применение к реляционным базам данных

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

Атрибуты обычно представлены как столбцы , кортежи как строки , а отношения как таблицы . Таблица указывается как список определений столбцов, каждое из которых указывает уникальное имя столбца и тип значений, разрешенных для этого столбца. Значение атрибута — это запись в определенном столбце и строке.

База данных relvar (переменная отношения) обычно известна как базовая таблица . Заголовок ее назначенного значения в любой момент времени соответствует указанному в объявлении таблицы, а ее тело — последнему назначенному ей оператору обновления (обычно INSERT, UPDATE или DELETE). Заголовок и тело таблицы, полученной в результате оценки запроса, определяются определениями операторов, используемых в этом запросе.

SQL и реляционная модель

SQL, изначально продвигаемый как стандартный язык для реляционных баз данных , отклоняется от реляционной модели в нескольких местах. Текущий стандарт ISO SQL не упоминает реляционную модель и не использует реляционные термины или концепции. ^{[ необходима цитата ]}

Согласно реляционной модели, атрибуты и кортежи Relation являются математическими наборами , то есть они неупорядочены и уникальны. В таблице SQL ни строки, ни столбцы не являются надлежащими наборами. Таблица может содержать как дублирующиеся строки, так и дублирующиеся столбцы, а столбцы таблицы явно упорядочены. SQL использует значение Null для указания отсутствующих данных, что не имеет аналога в реляционной модели. Поскольку строка может представлять неизвестную информацию, SQL не придерживается информационного принципа реляционной модели . ^[7]^{: 153–155, 162}

Теоретико-множественная формулировка

Базовыми понятиями в реляционной модели являются имена отношений и имена атрибутов . Мы представим их в виде строк, таких как «Person» и «name», и мы обычно будем использовать переменные и для их ранжирования. Другим базовым понятием является набор атомарных значений , содержащий такие значения, как числа и строки. $r,s,t,\ldots$ $а,б,в$

Наше первое определение касается понятия кортежа , которое формализует понятие строки или записи в таблице:

Кортеж: Кортеж — это частичная функция от имен атрибутов до атомарных значений.
Заголовок: Заголовок — это конечный набор имен атрибутов.
Проекция: Проекция кортежа на конечный набор атрибутов — это . $т$ $А$ $t[A]=\{(a,v):(a,v)\in t,a\in A\}$

Следующее определение определяет отношение , которое формализует содержимое таблицы, как оно определено в реляционной модели.

Связь: Отношение — это кортеж с заголовком и телом, набор кортежей, все из которых имеют домен . $(Н,В)$ $Н$ $Б$ $Н$

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

Вселенная отношений: Вселенная отношений над заголовком — это непустой набор отношений с заголовком . $U$ $Н$ $Н$
Схема отношений: Схема отношения состоит из заголовка и предиката , который определен для всех отношений с заголовком . Отношение удовлетворяет схеме отношения, если оно имеет заголовок и удовлетворяет . $(Н,С)$ $Н$ $C(R)$ $R$ $Н$ $(Н,С)$ $Н$ $С$

Ключевые ограничения и функциональные зависимости

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

Суперключ

Суперключ — это набор заголовков столбцов, для которых значения этих объединенных столбцов являются уникальными во всех строках. Формально:

Суперключ записывается как конечный набор имен атрибутов.

Суперключ сохраняется в отношении, если:

К

(Н,В)

$K\subseteq H$ и
не существует двух различных кортежей таких, что . $t_{1},t_{2}\in B$ $t_{1}[К]=t_{2}[К]$

Суперключ выполняется во вселенной отношений, если он выполняется во всех отношениях в .

U

U

Теорема: Суперключ выполняется в отношении вселенной тогда и только тогда, когда и выполняется в .

К

U

Н

K\subseteq H

K\rightarrow H

U

Кандидатный ключ

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

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

Функциональная зависимость — это свойство, согласно которому значение в кортеже может быть получено из другого значения в этом кортеже.

Функциональная зависимость (сокращенно FD) записывается для конечных наборов имен атрибутов.

X\rightarrow Y

X,Y

Функциональная зависимость имеет место в отношении, если:

X\rightarrow Y

(Н,В)

$X,Y\subseteq H$ и
$\forall$ кортежи , $t_{1},t_{2}\in B$ $t_{1}[X]=t_{2}[X]~\Стрелка вправо ~t_{1}[Y]=t_{2}[Y]$

Функциональная зависимость выполняется в отношении вселенной , если она выполняется во всех отношениях в .

X\rightarrow Y

U

U

Тривиальная функциональная зависимость

Функциональная зависимость тривиальна под заголовком , если она выполняется во всех вселенных отношений над .

Н

Н

Теорема: FD тривиален под заголовком тогда и только тогда, когда .

X\rightarrow Y

Н

Y\subseteq X\subseteq H

Закрытие

Аксиомы Армстронга : Замыкание множества ФД под заголовком , записанное как , является наименьшим надмножеством, таким что:

S

Н

S^{+}

S

$Y\subseteq X\subseteq H~\Rightarrow ~X\rightarrow Y\in S^{+}$ (рефлексивность)
$X\rightarrow Y\in S^{+}\land Y\rightarrow Z\in S^{+}~\Rightarrow ~X\rightarrow Z\in S^{+}$ (транзитивность) и
$X\rightarrow Y\in S^{+}\land Z\subseteq H~\Rightarrow ~(X\cup Z)\rightarrow (Y\cup Z)\in S^{+}$ (увеличение)

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

H

S

H

X\rightarrow Y\in S^{+}

X\rightarrow Y

H

S

Завершение

Завершение конечного набора атрибутов при конечном наборе FD , записанное как , является наименьшим надмножеством, таким что:

X

S

X^{+}

X

$Y\rightarrow Z\in S\land Y\subseteq X^{+}~\Rightarrow ~Z\subseteq X^{+}$

Завершение набора атрибутов можно использовать для вычисления того, находится ли определенная зависимость в замыкании набора FD.

Теорема: Для заданного набора ФД, тогда и только тогда, когда .

S

X\rightarrow Y\in S^{+}

Y\subseteq X^{+}

Неснижаемое покрытие

Неприводимое покрытие множества ФД — это множество ФД, такое что:

S

T

$S^{+}=T^{+}$
не существует такого, что $U\subset T$ $S^{+}=U^{+}$
$X\rightarrow Y\in T~\Rightarrow Y$ является одноэлементным множеством и
$X\rightarrow Y\in T\land Z\subset X~\Rightarrow ~Z\rightarrow Y\notin S^{+}$ .

Алгоритм получения потенциальных ключей из функциональных зависимостей

Алгоритм выводит потенциальные ключи из функциональных зависимостей : входные данные  : набор S FD, которые содержат только подмножества заголовка H,  выходные данные: набор C суперключей, которые содержат потенциальные ключи в все вселенные отношений над H, в которых все FD в S имеют место C  := ∅ // найденные потенциальные ключи Q  := { H } // суперключи, содержащие потенциальные ключи while  Q <> ∅ do let K будет некоторым элементом из Q  Q  := Q  – { K } minimum  := true  for each  X->Y  in  S  do  K' := ( K  – Y ) ∪ X // вывести новый суперключ if  K' ⊂ K  then  minimum  := false  Q  := Q ∪ { K' } end if  end for  if  minimum  and no subset of K in C  then remove all supersets of K from C  C  := C ∪ { K } end if  end while

Альтернативы

Другие модели включают иерархическую модель и сетевую модель . Некоторые системы , использующие эти старые архитектуры, все еще используются сегодня в центрах обработки данных с большими объемами данных или там, где существующие системы настолько сложны и абстрактны, что было бы невыгодно переходить на системы, использующие реляционную модель. Также следует отметить новые объектно-ориентированные базы данных . ^[9] и Datalog . ^[10]

Datalog — это язык определения баз данных, который объединяет реляционное представление данных, как в реляционной модели, с логическим представлением, как в логическом программировании . В то время как реляционные базы данных используют реляционное исчисление или реляционную алгебру с реляционными операциями , такими как объединение , пересечение , разность множеств и декартово произведение, для указания запросов, Datalog использует логические связки, такие как if , or , and и not, для определения отношений как части самой базы данных.

В отличие от реляционной модели, которая не может выражать рекурсивные запросы без введения оператора с наименьшей фиксированной точкой, ^[11] рекурсивные отношения могут быть определены в Datalog без введения каких-либо новых логических связок или операторов.

Смотрите также

Примечания

Ссылки

^ Кодд, Э.Ф. (1969), Выводимость, избыточность и согласованность отношений, хранящихся в больших банках данных , Исследовательский отчет, IBM.
^ Кодд, Э. Ф. (1970). «Реляционная модель данных для больших общих банков данных». Communications of the ACM . Classics. 13 (6): 377–87. doi : 10.1145/362384.362685 . S2CID 207549016. Архивировано из оригинала 2007-06-12.
^ Кодд, Э. Ф. (1990), Реляционная модель управления базами данных , Addison-Wesley, стр. 371–388, ISBN 978-0-201-14192-4.
^ «Имел ли «Третий манифест» Дейта и Дарвена долгосрочное влияние?». Computer Science Stack Exchange . Получено 2024-08-03 .
^ Дата, Кристофер Дж. (2006). "18. Почему трех- и четырехзначная логика не работает". Дата в базе данных: Writings 2000–2006 . Apress. стр. 329–41. ISBN 978-1-59059-746-0.
^ "Кортеж в СУБД". GeeksforGeeks . 2023-02-12 . Получено 2024-08-03 .
^ abcdefghijklm Дейт, Крис Дж. (2013). Реляционная теория для компьютерных профессионалов: что такое реляционные базы данных на самом деле (1-е изд.). Севастополь, Калифорния: O'Reilly Media. ISBN 978-1-449-36943-9.
^ Дэвид М. Кронке, Обработка баз данных: основы, проектирование и реализация (1997), Prentice-Hall, Inc., страницы 130–144
^ Аткинсон, М., Девитт, Д., Майер, Д., Бансилон, Ф., Диттрих, К. и Здоник, С., 1990. Манифест объектно-ориентированной системы баз данных. В Дедуктивные и объектно-ориентированные базы данных (стр. 223-240). Северная Голландия.
^ Майер, Д., Текле, К. Т., Кифер, М. и Уоррен, Д. С., 2018. Datalog: концепции, история и перспективы. В Декларативном логическом программировании: теория, системы и приложения (стр. 3-100).
^ Ахо, А. В. и Ульман, Дж. Д., 1979, январь. Универсальность языков поиска данных. В трудах 6-го симпозиума ACM SIGACT-SIGPLAN по принципам языков программирования (стр. 110-119).

Дальнейшее чтение

Дейт, Кристофер Дж .; Дарвен, Хью (2000). Основы будущих систем баз данных: третий манифест; подробное исследование влияния теории типов на реляционную модель данных, включая всеобъемлющую модель наследования типов (2-е изд.). Рединг, Массачусетс : Addison-Wesley. ISBN 978-0-201-70928-5.
——— (2007). Введение в системы баз данных (8-е изд.). Бостон: Pearson Education. ISBN 978-0-321-19784-9.

Внешние ссылки

На Викискладе есть медиафайлы по теме «Реляционные модели» .

Чайлдс (1968), Возможность создания теоретико-множественной структуры данных: общая структура, основанная на реконструированном определении отношения (исследование), Handle, hdl :2027.42/4164цитируется в статье Кодда 1970 года.
Дарвен, Хью, Третий Манифест (ТТМ).
‹ Шаблон Curlie рассматривается для удаления .› Реляционные базы данных в Curlie
«Реляционная модель», C2.
Бинарные отношения и кортежи в сравнении с семантической паутиной ( журнал World Wide Web ), Sun.