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

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

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

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

История

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

Расширения

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

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

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

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

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

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

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

Ограничения

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

Как правило, ограничения выражаются с помощью операторов реляционного сравнения, из которых теоретически достаточно только одного, «является подмножеством» (⊆).

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

Ключи

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

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

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

Основная статья: Внешний ключ

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

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

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

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

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

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

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

Основная статья: Нормализация базы данных

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

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

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

Определение кортежа позволяет создать уникальный пустой кортеж без значений, соответствующий пустому набору атрибутов. Если отношение имеет степень 0 (т. е. его заголовок не содержит атрибутов), оно может иметь либо мощность 0 (тело, не содержащее кортежей), либо мощность 1 (тело, содержащее один пустой кортеж). Эти отношения представляют собой логические значения истинности . Отношение со степенью 0 и мощностью 0 является ложным , а отношение со степенью 0 и мощностью 1 является истинным .

Пример

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

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

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

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

Примеры

База данных

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

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

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

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

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

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

Идентификатор клиента	Имя
123	Алиса
456	Боб
789	Кэрол

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

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

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

OrderInvoice (Order ID, Invoice ID)

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

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

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

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

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

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

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

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

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

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

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

Кортеж

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

Заголовок

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

Проекция

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

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

Связь

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

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

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

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

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

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

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

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

Superkey

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

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

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

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

Суперключ хранится во вселенной отношений. $U$ если оно справедливо во всех отношениях в $U$.

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

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

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

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

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

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

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

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

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

Функциональная зависимость $X\rightarrow Y$ содержится во вселенной отношений $U$ если оно справедливо во всех отношениях в $U$.

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

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

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

Закрытие

Аксиомы Армстронга : Замыкание множества ФД. $S$ под заголовком $H$, записанный как $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$ FD, которые содержат только подмножества $H$, $X\rightarrow Y\in S^{+}$ тогда и только тогда, когда $X\rightarrow Y$ сохраняется во всех вселенных отношений $H$ в котором все ФД в $S$ держать.

Завершение

Завершение конечного набора атрибутов $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^{+}$.

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

algorithm derive candidate keys from functional dependencies is
    input: a set S of FDs that contain only subsets of a header H
    output: the set C of superkeys that hold as candidate keys in
            all relation universes over H in which all FDs in S hold

    C := ∅         // found candidate keys
    Q := { H }      // superkeys that contain candidate keys
    while Q <> ∅ do
        let K be some element from Q
        Q := Q – { K }
        minimal := true
        for each X->Y in S do
            K' := (K – Y) ∪ X   // derive new superkey
            if K' ⊂ K then
                minimal := false
                Q := Q ∪ { K' }
            end if
        end for
        if minimal and there is not a subset of K in C then
            remove all supersets of K from C
            C := C ∪ { K }
        end if
    end while

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

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

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

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

См. также

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

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

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