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

Реляционная модель ( 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}

База данных может определять произвольные булевы выражения как ограничения . Если все ограничения оцениваются как истинные , база данных является согласованной ; в противном случае она является несогласованной . Если изменение relvars базы данных оставит базу данных в несогласованном состоянии, это изменение является незаконным и не должно быть успешным. ^{[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 .
2. Существует сотрудник с именем Боб и идентификатором 1 .
3. Не существует нескольких сотрудников с одинаковым идентификатором.

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

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

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

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

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

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

Если мы попытаемся вставить нового клиента с ID 123 , это нарушит конструкцию relvar, поскольку Customer ID является первичным ключом , а у нас уже есть клиент 123 . СУБД должна отклонить такую ​​транзакцию , которая сделает базу данных несогласованной из-за нарушения ограничения целостности . Однако можно вставить другого клиента по имени Алиса , если у этого нового клиента есть уникальный 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 ( Идентификатор заказа , Идентификатор счета )

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

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

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

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

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

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

В этом разделе не указаны источники . Помогите улучшить этот раздел , добавив ссылки на надежные источники . Материалы без ссылок могут быть оспорены и удалены . ( Декабрь 2023 г. ) ( Узнайте, как и когда удалять это сообщение )

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

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

Кортеж

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

Заголовок

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

Проекция

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

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

Связь

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

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

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

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

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

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

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

Суперключ

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

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

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

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

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

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

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

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

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

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

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

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

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

• ${\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}$

Закрытие

Аксиомы Армстронга : Замыкание множества ФД под заголовком , записанное как , является наименьшим надмножеством, таким что:${\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^{+}}$(увеличение)

Теорема: Аксиомы Армстронга являются обоснованными и полными; при заданном заголовке и наборе ФД, содержащих только подмножества , тогда и только тогда выполняется во всех вселенных отношений над , в которых выполняются все ФД .${\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 } // суперключи, содержащие потенциальные ключи 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 без введения каких-либо новых логических связок или операторов.

• Дейт, Кристофер Дж .; Дарвен, Хью (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 года.
• Дарвен, Хью, Третий Манифест (ТТМ).
• «Реляционная модель», C2.
• Бинарные отношения и кортежи в сравнении с семантической паутиной ( журнал World Wide Web ), Sun.