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

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

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

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

Обзор[править]

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

Альтернативы[править]

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

Реализация[править]

Было предпринято несколько попыток создать истинную реализацию модели реляционной базы данных , как она первоначально была определена Codd и объяснена Date, Darwen и другими, но до сих пор ни одна из них не была успешной. По состоянию на октябрь 2015 Rel является одной из последних попыток сделать это.

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

История[править]

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

Споры[править]

Кодди себя, через несколько лет после публикации его 1970 модель, предлагаемая в трех-значной логики (истинные, ложные, пропавших без вести/нуль) версии это дело, в котором отсутствует информация, а в реляционной модели для управления базами данных, Версия 2 (1990) он пошел дальше, с четырех-значной логики (истинные, ложные, не хватает, но это применимо, отсутствует, но неприменно) версия.[5] Но они никогда не были реализованы, предположительно из-за сложности посещения. Нулевая конструкция SQL должна была быть частью трехзначной логической системы, но не смогла этого сделать из-за логических ошибок в стандарте и в его реализациях.

Темы[править]

Фундаментальное предположение реляционной модели заключается в том , что все данные представлены в виде математических n - арных отношений, n-арное отношение является подмножеством декартова произведения n доменов. В математической модели рассуждения о таких данных выполняются в логике двузначных предикатов, что означает , что для каждого предложения возможны две оценки : либо истинная , либо ложная (и, в частности, нет третьего значения, такого как неизвестное или неприменимое, оба из которых часто связаны с понятием NULL ). Данные обрабатываются с помощью реляционного исчисления или реляционной алгебры, они эквивалентны по выразительной силе .

Реляционная модель данных позволяет разработчику баз данных создавать последовательное логическое представление информации . Согласованность достигается путем включения объявленных ограничений в структуру базы данных, которая обычно называется логической схемой . Теория включает в себя процесс нормализации базы данных, при котором из набора логически эквивалентных альтернатив может быть выбрана конструкция с определенными желательными свойствами. Планы доступа и другие детали реализации и операции обрабатываются СУБД движок, и не отражаются в логической модели. Это контрастирует с обычной практикой для СУБД SQL, в которой настройка производительности часто требует внесения изменений в логическую модель.

Основным реляционным строительным блоком является домен или тип данных, обычно сокращенный в настоящее время до type . Кортеж-это упорядоченный набор значений атрибутов . Атрибут-это упорядоченная пара имени атрибута и имени типа . Значение атрибута-это определенное допустимое значение для типа атрибута. Это может быть скалярное значение или более сложный тип.

Отношение состоит из заголовка и тела . Заголовок-это набор атрибутов. Тело (n-арного отношения)- это множество n-кортежей. Заголовок отношения также является заголовком каждого из его кортежей.

Отношение определяется как множество n-кортежей. Как в математике, так и в модели реляционной базы данных набор представляет собой неупорядоченную коллекцию уникальных, не дублирующихся элементов, хотя некоторые СУБД налагают порядок на свои данные. В математике Кортеж имеет порядок и допускает дублирование. E. F. Codd первоначально определил кортежи, используя это математическое определение.[2] позже это была одна из замечательных идей E. F. Codd о том, что использование имен атрибутов вместо упорядочения было бы намного удобнее (в целом) в компьютерном языке, основанном на отношениях [ нужная цитата]. Это понимание все еще используется сегодня. Хотя концепция изменилась, название "Кортеж" не изменилось. Непосредственным и важным следствием этой отличительной черты является то, что в реляционной модели декартово произведение становится коммутативным .

Таблица является принятым визуальным представлением отношения; Кортеж похож на понятие строки .

Relvar-это именованная переменная определенного типа отношения, которой всегда назначается некоторое отношение этого типа, хотя отношение может содержать ноль кортежей.

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

Согласованность реляционной базы данных обеспечивается не правилами, встроенными в приложения, которые ее используют , а ограничениями, объявленными как часть логической схемы и применяемыми СУБД для всех приложений. В общем случае ограничения выражаются с помощью операторов реляционного сравнения, из которых теоретически достаточно только одного" подмножества " ( ⊆ ) . На практике, как ожидается, будет доступно несколько полезных сокращений, из которых наиболее важными являются ключ-кандидат (на самом деле, суперкей ) и ограничения внешнего ключа.

Интерпретация[править]

Чтобы в полной мере оценить реляционную модель данных, необходимо понять предполагаемую интерпретацию отношения .

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

Существует взаимно однозначное соответствие между свободными переменными предиката и именами атрибутов заголовка отношения. Каждый кортеж тела отношения предоставляет значения атрибутов для создания экземпляра предиката путем замены каждой из его свободных переменных. Результатом является пропозиция, которая считается истинной из-за появления кортежа в теле отношения. Напротив, каждый кортеж, заголовок которого соответствует заголовку отношения, но который не появляется в теле, считается ложным. Это предположение известно как допущение закрытого мира: это часто нарушается в практических базах данных, где отсутствие кортежа может означать, что истинность соответствующего предложения неизвестна. Например, отсутствие кортежа ("John", "Spanish") в таблице языковых навыков не обязательно должно рассматриваться как свидетельство того, что Джон не говорит по-испански.

Формальное изложение этих идей см. В разделе теоретико-множественная формулировка ниже.

Применение к базам данных[править]

Тип данных, используемый в типичной реляционной базе данных, может быть набором целых чисел, набором символьных строк, набором дат или двумя логическими значениями true и false и т. д. Соответствующие имена типов для этих типов могут быть строками "int", "char", "date", "boolean" и т.д. Однако важно понимать, что реляционная теория не диктует, какие типы должны поддерживаться; действительно, в настоящее время ожидается, что положения будут доступны для пользовательских типов в дополнение к встроенным, предоставляемым системой.

Атрибут-это термин, используемый в теории для того, что обычно называют столбцом . Аналогично, table обычно используется вместо теоретического термина relation (хотя в SQL этот термин ни в коем случае не является синонимом relation). Структура данных таблицы задается как список определений столбцов, каждое из которых задает уникальное имя столбца и тип значений, разрешенных для этого столбца. Значение атрибута-это запись в определенном столбце и строке, например "John Doe" или "35".

Кортеж в основном то же самое , что и строка, за исключением СУБД SQL, где значения столбцов в строке упорядочены. (Кортежи не упорядочены; вместо этого каждое значение атрибута определяется только именем атрибута и никогда его порядковым номером в кортежах.) Имя атрибута может быть "имя"или " возраст".

Отношение - это определение структуры таблицы (набор определений столбцов) вместе с данными, появляющимися в этой структуре. Определение структуры-заголовок , а данные, появляющиеся в нем, - тело, набор строк. База данных relvar (relation variable) обычно называется базовой таблицей . Заголовок его назначенного значения в любое время, как указано в объявлении таблицы, а его тело является последним назначенным ему, вызывая некоторый оператор обновления (как правило, вставка, обновление или удаление). Заголовок и тело таблицы, полученные в результате вычисления некоторого запроса, определяются определениями операторов, используемых в выражении этого запроса. (Обратите внимание, что в SQL заголовок не всегда является набором определений столбцов, как описано выше, потому что столбец может не иметь имени, а также для двух или более столбцов с одинаковым именем. Кроме того, тело не всегда является набором строк, так как в SQL одна и та же строка может появляться несколько раз в одном теле.)

SQL и реляционная модель[править]

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

Были отмечены следующие отклонения от реляционной модели [ кто?] в SQL. Обратите внимание, что немногие серверы баз данных реализуют весь стандарт SQL и, в частности, не допускают некоторые из этих отклонений. В то время как NULL является повсеместным, например, разрешение повторяющихся имен столбцов в таблице или анонимных столбцах является необычным.

Повторяющиеся строки[править]

Одна и та же строка может появляться в таблице SQL несколько раз. Один и тот же кортеж не может появляться в отношении более одного раза .

Анонимные столбцы[править]

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

Дублирование имен столбцов[править]

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

Значение порядка столбцов[править]

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

Просмотры без опции CHECK[править]

Обновления представления, определенного без параметра CHECK, могут быть приняты, но результирующее обновление базы данных не обязательно оказывает выраженное влияние на ее целевой объект. Например, можно принять вызов INSERT, но не все вставленные строки могут отображаться в представлении, или вызов UPDATE может привести к исчезновению строк из представления. Реляционная модель требует обновления представления, чтобы иметь тот же эффект, как если бы представление было базовым relvar.

Таблицы без столбцов нераспознанные[править]

SQL требует, чтобы каждая таблица имела хотя бы один столбец, но есть два отношения нулевой степени (мощности один и ноль), и они необходимы для представления расширений предикатов, которые не содержат свободных переменных.

НОЛЬ[править]

   Эта специальная метка может появиться вместо значения везде, где значение может появиться в SQL, в частности, вместо значения столбца в некоторой строке. Отклонение от реляционной модели заключается в том, что реализация этой специальной концепции в SQL предполагает использование трехзначной логики, в соответствии с которым при сравнении null с себя нисколько не уступает истинно , но вместо этого дает третье истинностное значение, неизвестно; точно так же при сравнении null с чем-то, кроме себя, не дает ложной , но вместо этого дает неизвестно. Именно из-за такого поведения в сравнениях NULL описывается как знак, а не значение. Реляционная модель зависит от закона исключенной середины, согласно которому все, что не является истинным, является ложным, а все, что не является ложным, является истинным; она также требует, чтобы каждый Кортеж в теле отношения имел значение для каждого атрибута этого отношения. Это конкретное отклонение оспаривается некоторыми хотя бы потому, что E. Сам Ф. Кодд в конечном итоге выступал за использование специальных знаков и 4-значной логики, но это было основано на его наблюдении, что есть две различные причины, по которым можно было бы использовать специальный знак вместо значения, что привело противников использования такой логики, чтобы обнаружить более четкие причины и, по крайней мере, было отмечено 19, что потребовало бы 21-значной логики.[ требуется цитирование] SQL сам использует NULL для нескольких целей, отличных от представления "value unknown". Например, сумма пустого набора равна нулю, то есть нулю, среднее значение пустого набора равно нулю, то есть не определено, а значение NULL, появляющееся в результате левого соединения, может означать "нет значения, потому что нет совпадающей строки в правом операнде". Существуют способы разработки таблиц, чтобы избежать необходимости в NULL, как правило , то, что может рассматриваться или напоминать высокие степени нормализации базы данных, но многие находят такие непрактичные. Это может быть горячо обсуждаемая тема.

Реляционные операции[править]

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

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

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

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

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

Нормализация базы данных[править]

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

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

Примеры[править]

База данных[править]

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

Клиент (ИД клиента, ИД налога, Имя, Адрес, город, государство, застежка-молния, телефон, электронная почта, секс)
Заказ (заказ нет, идентификатор клиента, счет нет, дата размещения, дата обещания, условия, статус)
Строка Заказа ( Номер Заказа, Номер Строки Заказа, Код Продукта , Кол-Во)
Счет (номер счета, идентификатор клиента, номер заказа, дата, статус)
Строка Счета (Номер Счета, Номер Строки Счета, Код Продукта, Кол-Во Отгружено)
Продукт (Код Продукта, Описание Продукта)

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

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

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

Связь с клиентами[править]

Шахматка

идентификатор заказчика	идентификационный номер налогоплательщика	Имя	Адрес
1234567890	555-5512222	Рамеш Чандер	323 Южный Проспект Абая	2223344556	555-5523232	Наовуходунасор	Главная Улица Чингтзидов 1200
3334445563	555-5533323	Уася	871 Rani Jhansi Road
4232342432	555-5325523	Швета	123 Маулана Азад Назарбаева

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

Внешние ключи-это ограничения целостности, обеспечивающие получение значения набора атрибутов из ключа-кандидата в другом отношении . Например, в связи Order атрибут Customer ID является внешним ключом. Соединение-это операция, которая использует информацию из нескольких связей одновременно. Присоединившись к relvars из приведенного выше примера, мы можем запросить базу данных для всех клиентов, заказов и счетов-фактур. Если бы мы хотели использовать кортежи только для конкретного клиента, мы бы указали это, используя условие ограничения .

Если мы хотим получить все заказы для клиента 1234567890, мы можем запросить базу данных, чтобы вернуть каждую строку в таблице заказов с идентификатором клиента 1234567890 и присоединить таблицу заказов к таблице строк заказов на основе заказа№.

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

OrderInvoice ( Заказ Нет, Счет Нет)

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

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

Основными понятиями в реляционной модели являются имена отношений и имена атрибутов . Мы будем представлять их в виде строк, таких как "Person" и "name", и мы обычно будем использовать переменные r , s , t , … , b , c a, b, cдиапазон над ними. Другим базовым понятием является набор атомарных значений, который содержит такие значения, как числа и строки.

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

Кортеж[править]

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

Заголовок[править]

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

Проекция[править]

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

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

Отношение[править]

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

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

Вселенная отношений[править]

Юниверс отношений U Унад заголовком H Ч-Это непустой набор отношений с заголовком H Ч.

Схема связи[править]

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

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

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

Superkey[править]

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

Суперключ записывается как конечный набор имен атрибутов.
Суперклюз K {\displaystyle K} Тысячаудерживается в отношении ( H , B ) {\displaystyle (H,B)} (H, B), если:

K ⊆ H и
не существует двух различных кортежей t 1 , t 2 ∈ B t_1, t_, подобных этому t 1 [ K ] = t 2 [ K ] [K]=t_{2}[K]} t_1[K] = t_2[K].

Суперклюй имеет место во Вселенной отношений U У, если он имеет место во всех отношениях U У.
Теорема: суперкей K Тысячаудерживается во Вселенной U Уотношений H Чтогда и только тогда K ⊆ H K , когда и K → H Hудерживается U У.

Потенциальный ключ[править]

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

Суперключей является K Тысячаключом-кандидатом для Юниверса отношений, U Уесли он является суперключем Для U У, и нет надлежащего подмножества K Тысяча, которое также является суперключем для U У.

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

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

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

       X , Y ⊆ H  X,  и
       ∀  кортежи t 1 , t 2 ∈ B \in B} t_1, t_2 \in B, t 1 [ X ] = t 2 [ X ]   ⇒   t 1 [ Y ] = t 2 [ Y ] [X]=t_{2}[X]~ ~t_{1}[Y]=t_{2}[Y]} t_1[X] = t_2 _1[Y] = t_2[Y]

Функциональная зависимость X → Y имеет место во Вселенной отношений U У, если она имеет место во всех отношениях U У.

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

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

См.на ен википедии.

См. также[править]

Пруф[править]

.thethirdmanifesto.com/