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

Модель базы данных

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

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

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

История

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

Расширения

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

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

Базовые концепты

Отношение с 5 атрибутами (его степенью) и 4 кортежами (его мощностью) можно представить в виде таблицы с 5 столбцами и 4 строками. Однако, в отличие от строк и столбцов таблицы, атрибуты и кортежи отношения неупорядочены.

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

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

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

Ограничения

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

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

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

Ключи

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

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

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

Внешний ключ — это подмножество атрибутов {A} в отношении R1 , которое соответствует ключу другого отношения R2 _, ​​обладающее тем свойством, что проекция R1 на { _A } _{является} подмножеством проекции R2 _на {А} . Другими словами, если кортеж в _R1 содержит значения для внешнего ключа, должен существовать соответствующий кортеж в R2 _, содержащий те же значения для соответствующего ключа. ^{[5] : 34}

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

Примеры

База данных

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

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

В этом проекте у нас есть три значения: Клиент, Заказ и Счет. Атрибуты, выделенные жирным шрифтом и подчеркнутые, являются кандидатами на ключи . Атрибуты, не выделенные жирным шрифтом и подчеркнутые, являются внешними ключами .

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

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

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

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

Внешние ключи — это ограничения целостности , гарантирующие, что значение набора атрибутов извлекается из ключа-кандидата в другом отношении . Например, в отношении «Заказ» атрибут «Идентификатор клиента» является внешним ключом. Соединение— это операция , которая извлекает информацию из нескольких отношений одновременно. Объединив relvars из приведенного выше примера, мы могли бы запросить в базе данных всех клиентов, заказы и счета. Если бы нам нужны были кортежи только для конкретного клиента, мы бы указали это с помощью условия ограничения. Если бы мы хотели получить все заказы для клиента 123 , мы могли бы запросить базу данных, чтобы она вернула каждую строку в таблице заказов с идентификатором клиента 123 .

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

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

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

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

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

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

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

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

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

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

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

Основными понятиями реляционной модели являются имена отношений и имена атрибутов . Мы будем представлять их в виде строк, таких как «Человек» и «имя», и обычно будем использовать переменные и перемещаться по ним. Другое базовое понятие — это набор атомарных значений , который содержит такие значения, как числа и строки. ${\displaystyle r,s,t,\ldots }$ ${\displaystyle a,b,c}$

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

Кортеж

Кортеж — это частичная функция от имен атрибутов до атомарных значений.

Заголовок

Заголовок — это конечный набор имен атрибутов.

Проекция

Проекция кортежа на конечный набор атрибутов равна . ${\displaystyle t}$ ${\displaystyle A}$ ${\displaystyle t[A]=\{(a,v):(a,v)\in t,a\in A\}}$

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

Связь

Отношение — это кортеж с заголовком и телом, набором кортежей, каждый из которых имеет домен . ${\displaystyle (H,B)}$ ${\displaystyle H}$ ${\displaystyle B}$ ${\displaystyle H}$

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

Вселенная отношений

Вселенная отношений над заголовком — это непустой набор отношений с заголовком . ${\displaystyle U}$ ${\displaystyle H}$ ${\displaystyle H}$

Схема отношений

Схема отношения состоит из заголовка и предиката , который определен для всех отношений с заголовком . Отношение удовлетворяет схеме отношения , если оно имеет заголовок и удовлетворяет требованиям . ${\displaystyle (H,C)}$ ${\displaystyle H}$ ${\displaystyle C(R)}$ ${\displaystyle R}$ ${\displaystyle H}$ ${\displaystyle (H,C)}$ ${\displaystyle H}$ ${\displaystyle C}$

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

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

Суперключ

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

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

Суперключ сохраняется в отношении, если: ${\displaystyle K}$ ${\displaystyle (H,B)}$

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

Суперключ действует в юниверсе отношений , если он действует во всех отношениях в . ${\displaystyle U}$ ${\displaystyle U}$

Теорема: Суперключ имеет место во вселенной отношений тогда и только тогда, когда и выполняется в . ${\displaystyle K}$ ${\displaystyle U}$ ${\displaystyle H}$ ${\displaystyle K\subseteq H}$ ${\displaystyle K\rightarrow H}$ ${\displaystyle U}$

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

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

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

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

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

Функциональная зависимость (сокращенно FD) записывается как для конечных наборов имен атрибутов. ${\displaystyle X\rightarrow Y}$ ${\displaystyle X,Y}$

Функциональная зависимость имеет место в отношении, если: ${\displaystyle X\rightarrow Y}$ ${\displaystyle (H,B)}$

• ${\displaystyle X,Y\subseteq H}$и
• ${\displaystyle \forall }$кортежи , ${\displaystyle t_{1},t_{2}\in B}$ ${\displaystyle t_{1}[X]=t_{2}[X]~\Rightarrow ~t_{1}[Y]=t_{2}[Y]}$

Функциональная зависимость сохраняется в юниверсе отношений , если она сохраняется во всех отношениях в . ${\displaystyle X\rightarrow Y}$ ${\displaystyle U}$ ${\displaystyle U}$

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

Функциональная зависимость тривиальна в заголовке, если она сохраняется во всех вселенных отношений над . ${\displaystyle H}$ ${\displaystyle H}$

Теорема: FD тривиален под заголовком тогда и только тогда, когда . ${\displaystyle X\rightarrow Y}$ ${\displaystyle H}$ ${\displaystyle Y\subseteq X\subseteq H}$

Закрытие

Аксиомы Армстронга : Замыкание набора FD под заголовком , записанным как , является наименьшим надмножеством такого, что: ${\displaystyle S}$ ${\displaystyle H}$ ${\displaystyle S^{+}}$ ${\displaystyle S}$

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

Теорема: аксиомы Армстронга верны и полны; задан заголовок и набор FD, которые содержат только подмножества , тогда и только тогда, когда выполняется во всех вселенных отношений, в которых содержатся все FD . ${\displaystyle H}$ ${\displaystyle S}$ ${\displaystyle H}$ ${\displaystyle X\rightarrow Y\in S^{+}}$ ${\displaystyle X\rightarrow Y}$ ${\displaystyle H}$ ${\displaystyle S}$

Завершение

Завершение конечного набора атрибутов при конечном наборе FD , записанное как , является наименьшим надмножеством такого, что: ${\displaystyle X}$ ${\displaystyle S}$ ${\displaystyle X^{+}}$ ${\displaystyle X}$

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

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

Теорема: Для данного набора ФД тогда и только тогда, когда . ${\displaystyle S}$ ${\displaystyle X\rightarrow Y\in S^{+}}$ ${\displaystyle Y\subseteq X^{+}}$

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

Неприводимым накрытием множества ФД называется такой набор ФД, что: ${\displaystyle S}$ ${\displaystyle T}$

• ${\displaystyle S^{+}=T^{+}}$
• не существует такого, что ${\displaystyle U\subset T}$ ${\displaystyle S^{+}=U^{+}}$
• ${\displaystyle X\rightarrow Y\in T~\Rightarrow Y}$представляет собой одноэлементный набор и
• ${\displaystyle 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 } // суперключи, которые содержат ключи-кандидаты, в то время как  Q <> ∅ действительно пусть K будет некоторым элементом из Q  Q  := Q  – { K } минимальный  := true  для каждого  X ->Y  in  S  do  K' := ( K  – Y ) ∪ X // получаем новый суперключ, если  K' ⊂ K  , то  минимальный  := false  Q  := Q ∪ { K' } end if  end for  if  минимальный  и существует не является подмножеством K в C  , то удалите все надмножества K из C  C  := C ∪ { K } end if  end while

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

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

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

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

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

• Реляционное исчисление предметной области
• Список систем управления реляционными базами данных
• Язык запросов
  • Язык запросов к базе данных
  • Язык запросов поиска информации
• Связь
• Реляционная база данных
• Система управления реляционными базами данных
• Кортежное управление версиями

Примечания

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

Рекомендации

1. Кодд, Э.Ф. (1969), Выводимость, избыточность и согласованность отношений, хранящихся в больших банках данных , Отчет об исследовании, IBM.
2. Кодд, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации АКМ . Классика. 13 (6): 377–87. дои : 10.1145/362384.362685 . S2CID  207549016. Архивировано из оригинала 12 июня 2007 г.
3. Кодд, Э. Ф. (1990), Реляционная модель управления базами данных , Аддисон-Уэсли, стр. 371–388, ISBN 978-0-201-14192-4.
4. Дата, Кристофер Дж. (2006). «18. Почему не работает трех- и четырехзначная логика». Дата в базе данных: Сочинения 2000–2006 гг . Апресс. стр. 329–41. ISBN 978-1-59059-746-0.
5. Date, Крис Дж. (2013). Реляционная теория для компьютерных специалистов: что на самом деле представляют собой реляционные базы данных (1-е изд.). Севастополь, Калифорния: O'Reilly Media. ISBN 978-1-449-36943-9.
6. Дэвид М. Кроенке, Обработка баз данных: основы, проектирование и реализация (1997), Prentice-Hall, Inc., страницы 130–144.
7. Аткинсон М., Девитт Д., Майер Д., Банкилхон Ф., Диттрих К. и Здоник С., 1990. Манифест объектно-ориентированной системы баз данных. В книге «Дедуктивные и объектно-ориентированные базы данных» (стр. 223-240). Северная Голландия.
8. Майер Д., Текле К.Т., Кифер М. и Уоррен Д.С., 2018. Журнал данных: концепции, история и перспективы. В декларативном логическом программировании: теория, системы и приложения (стр. 3–100).
9. Ахо, А.В. и Ульман, JD, 1979, январь. Универсальность языков поиска данных. В материалах 6-го симпозиума ACM SIGACT-SIGPLAN по принципам языков программирования (стр. 110-119).

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

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

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

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