На английском мы можем говорить об отношениях, скажем, между Бобом и Тимом. Возможно, они кузены. Термин «отношение» в этом контексте имеет смысл для меня.

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

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

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

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

Прежде всего, я настоятельно рекомендую научную статью, в которой д-р Эдгар Франк Кодд опубликовал реляционную структуру для широкой публики в 1970 году, а именно, Реляционную модель данных для больших общих банков данных . Там, в разделе 1.1 «Введение», доктор Кодд сам утверждает, что:

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

---

_{© Ассоциация вычислительной техники. Сообщения ACM , том 13, выпуск 6 (стр. 377-387), июнь 1970 г.}

Так что да, термины « отношение» и (следовательно) « реляционный» происходят из математического фона. Д-р Кодд, который, помимо своих академических и исследовательских полномочий, имел около 20 лет непосредственного опыта в области вычислительной техники и обработки информации, представил огромные преимущества применения этого отношения (абстрактной конструкции, естественно) в области управления данными ,

Я не математик, но, по сути, отношение - это ассоциация между наборами , а набор - это совокупность элементов ( этот внешний ресурс дает определение математического отношения, которое может помочь понять его с другой точки зрения). При работе с помощью системы управления базами данных SQL (для краткости СУБД) общеизвестным приближением отношения является таблица , в этом случае происходит связь между типами ее столбцов . Очевидно, что на платформах SQL, которые предлагают поддержку DOMAIN (например, Firebird и PostgreSQL ), связь междуфиксированные домены для столбцов рассматриваемой таблицы; см. разделы ниже для важных деталей.

В связи с этим я собираюсь еще раз процитировать доктора Кодда, который в разделе 1.3 «Реляционное представление данных» утверждает, что:

Термин отношение используется здесь в его принятом математическом смысле. Для заданных наборов S ₁ , S ₂ , ⋯, S _n (не обязательно различных) R является отношением к этим n наборам, если это набор из n- кортежей, каждый из которых имеет свой первый элемент из S ₁ , свой второй элемент из S ₂ и так далее. ¹ Мы будем называть S _J как J - й области из R . Как определено выше, говорят , что R имеет степень n, Отношения степени 1 часто называют одинарными , степени 2 двоичными , степени 3 троичными и степенью n n-арными .

_{¹ Более кратко, R является подмножеством декартового произведения S 1 × S 2 × S 3 ⋯ × S n} .

---

_{© Ассоциация вычислительной техники. Сообщения ACM , том 13, выпуск 6 (стр. 377-387), июнь 1970 г.}

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

Отношения и отношения

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

Представление сущности-отношения и реляционная модель

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

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

Ответы на каждый из ваших подвопросов

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

Подвопрос № 1

Почему, например, Персона считается «отношением»? В английском языке отношение - это существительное, которое описывает, как связаны две сущности. Это не относится к самим сущностям. В контексте реляционных баз данных «отношение» относится к самим сущностям. Зачем?

Концептуальный уровень

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

Кроме того, тип сущности Person может содержать определенные типы отношений (или ассоциаций или соединений ) с самим собой или с другими типами сущностей; Например, Person может быть связан с типом сущности с именем UserProfile , который, в свою очередь, может иметь свои собственные интересующие свойства, скажем, Имя пользователя и Пароль .

Но, (a) типы объектов, (b) их соответствующие свойства, (c) типы отношений между типами объектов и (d) отношения между самими свойствами являются понятиями, которые «принадлежат» конкретной бизнес-среде, в которой они находятся. считается значимым. Это устройства, используемые разработчиками баз данных, которые работают в тесном контакте с бизнес-экспертами для определения концептуальной схемы , зависящей от контекста , на этапе проектирования.

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

Логический уровень

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

Да, можно определить конкретное отношение Person при определении логического расположения базы данных, но это не превращает концепцию Person в реальный мир в отношение, к нему можно подходить как таковому из-за преимуществ, которые получают при управлении информацией. об этом, например, применяя к нему операции реляционной алгебры для получения новых отношений (и, следовательно, каждый получает «новую» информацию). Упомянутые преимущества становятся более очевидными, если принять во внимание тот факт, что объекты определенного типа составляют набор, а значения определенного свойства также составляют набор.

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

• Salary (PersonNumber, EffectiveDate, Amount)

… И предположим, что в рассматриваемой бизнес-среде кортеж, который (i) обозначает конкретную сущность , то есть экземпляр типа сущности из применимой концептуальной схемы, и (ii) чей аналог SQL является ряд -

• Salary (x, y, z)

... будет нести смысл

• «Заработная плата, выплачиваемая лицу, указанному PersonNumber xна дату вступления в силуy соответствуетz » .

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

Концептуальный уровня отношений и логический уровень отношения

Как было продемонстрировано, я сейчас имею дело с управлением базами данных на двух разных уровнях абстракции, а именно: концептуальный и логическом, и еще существует более низкий уровень, известный как физический , который в СУБД SQL обычно включает, например, индексы, страницы, экстенты, так далее.-.

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

И да, ассоциативные объекты, то есть экземпляры типов отношений с отношением кардинальности «многие ко многим» (M: N), могут передаваться посредством кортежей одного математического отношения - с соответствующими ограничениями, объявленными соответствующим образом, курс-.

Подвопрос № 2

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

Сетевые и иерархические СУБД предшествовали их формальной теоретической поддержке

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

Неполный по сравнению с реляционным каркасом

При этом, хотя существуют иерархические и сетевые СУБД, которые предшествуют реляционной модели, и даже когда д-р Кодд называл каждый из этих подходов «моделью», ни один из них не определяется так же, как и реляционная структура. Реляционная парадигма предоставляет научные конструкции для определения (i), (ii) ограничения и (iii) манипулирования данными, а иерархический и сетевой подходы не имеют полной теоретической поддержки, чтобы охватить все три вида конструкций, упомянутых ранее.

Сетевые и иерархические особенности

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

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

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

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

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

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

Подвопрос № 3

Что делать, если у нас есть отдельные сущности, которые не связаны друг с другом. Скажи, человек, дверь и дерево. Термин «отношение (а)» все еще применим?

Да, это вполне применимо, если кто-то (1) управляет информацией об этих типах сущностей с помощью адаптированных математических отношений и (2) выполняет соответствующие реляционные операции на логическом уровне в определенной базе данных, администрируемой с помощью данной реляционной СУБД ,

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

Интересная вещь, стоящая за «реляционной базой данных», заключается в том, что она (в основном) не относится к отношениям между таблицами, как вы могли бы ожидать, но она относится к отношению нескольких свойств (столбцов) в кортеже. Реляционная база данных хранит эти кортежи в виде строки в таблице.

Он основан на реляционной алгебре, определенной Альфредом Тарским в его работе 1941 (!) О исчислении отношений . Он суммировал историю термина и использования в символической логике, но определил операции, которые в итоге стали основой для SQL.

Кодд превратил это в определение для того, что может быть понято как реляционная база данных в его 12 заповедях .

Термин «реляционный» происходит из математики и не имеет ничего общего с отношениями между сущностями. Я не математик (тогда как у Кодда была докторская степень по математике) и поэтому не буду подробно останавливаться, но укажу вам на эту статью в Википедии . Крис Дэйт также много писал о RDM, а на его сайте « Третий манифест» есть раздел, в котором перечислены статьи и книги. Его книга « Реляционная теория для компьютерных профессионалов» - хорошее введение. Надеюсь, это поможет. бинарных отношениях . Запись в Википедии об отношениях (базы данных) дает дополнительную информацию о том, как Кодд адаптировал математические концепции для применения к управлению данными. Что касается того, почему эта математическая структура называется отношением, я думаю, что это связано с идеей о том, что существует «отношение» между доменами, которые составляют отношение. Лучший источник, который я знаю, чтобы лучше понять оригинальное мышление Кодда, - это « Практические основы базы данных Фабиана Паскаля и понимание реального RDM».

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

Relation: Employee
|--------+------------+--------|
| name   | job        | boss   |
|--------+------------+--------|
| Mark   | owner      | NULL   |
| Bob    | manager    | Mark   |
| Jane   | supervisor | Bob    |
| Claire | supervisor | Bob    |
| John   | cashier    | Jane   |
| Jesse  | cashier    | Jane   |
| Jason  | cashier    | Claire |
|--------+------------+--------|

• Имя сотрудника «Джейн» связано с заданием «руководитель».
• Имя сотрудника «Джон» связано с начальником «Джейн».
• Работа «кассир» связана с именами сотрудников «Джон», «Джесси» и «Джейсон».
• Работа «Кассир» связана с боссами «Джейн» и «Клэр».

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

Почему термин «реляционный».

Потому что таблица - это конкретный экземпляр математического объекта «отношение».

Давайте посмотрим, что говорит Википедия о термине «отношение» (в математике, а не в СУБД), а затем переведем его в базы данных:

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

Mathematics             | RDBMS
========================|===============
A relation is           | A table is
a set of                | a bunch of 
n-tuples                | rows
of equal degree.        | with the same cell (a.k.a. column) types and sizes.

Это продолжается теорией множеств. Помните, что это математика, гораздо более абстрактная, чем база данных. Таким образом, последнее предложение

отношение между двумя наборами является подмножеством их декартового произведения.

Это переводит в одну таблицу с двумя столбцами:

• Давайте назовем столбец «имя». Его математический набор A- это набор всех (человеческих) имен.
• Колонку БИ называют "город". Его математический набор B- это набор всех городов.
• Декартово произведение A x B(в математике) - это новый набор, который содержит все пары (aka, tupels), в (a, b)которых aон входит Aи bявляется членом B. Т.е. aэто имя и bгород. Примеры будут (Alice, New York)или (Bob, Hollywood). Но декартово произведение - это не только некоторые из них, но и все они. Отношение, чтобы добраться до сути, является подмножеством этого декартова произведения. Другими словами, отношение - это (определено быть) любое количество пар, (a, b)где aесть имя и bгород, даже нет вообще.

Теперь я надеюсь, что все начинает обретать смысл. В СУБД строки таблицы просто выбирают подмножество декартовых произведений всех возможных комбинаций в этих столбцах. Что, при использовании СУБД, совершенно тривиально и неактуально.

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

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

NB: в математике отношения не связаны с базами данных, а представляют собой нечто вроде функций, просто более общее (пожалуйста, все вы, математики, не начинайте придираться, мы находимся в dba.SE, а не в math.SE; я в курсе что это не так :)). Подобная функция f(x)=x+1также может быть выражена в виде набора кортежей (1, 2), (2, 3), ..., но она может иметь каждый номер только один раз, слева от кортежа. То есть, это не будет действительная функция: (1, 2), (1, 3), .... Но последнее будет действительным отношением; то есть вы можете иметь Боба в Нью-Йорке и Боба в Голливуде.

Реляционные базы данных основаны на реляционной модели EFCodd. Реляционная алгебра описывает методы , как для запроса данных. Отношение - это просто подмножество перекрестного продукта некоторых множеств (доменов).

пример

У нас есть следующие наборы:

DepIds = {1, 2, 3, ...}
EmpIds = {1, 2, 3, ...}
DepNames = {'Engineering', 'Finance', 'Sales', ...}
FirstNames = {'John', 'Walter', 'Mary', 'Roxane', ...}
LastNames = {'Smith', 'Bondy', 'Taylor', ...}
BirthDates = {..., 1950-01-01, 1950-01-02, ...}
Jobs = {'Accountant', 'Programmer', 'Database Administrator', ...}

Далее у нас есть наборы кортежей

departements = { 
    (1, 'Engineering'), 
    (2, 'Finance')}
employees = { 
    (1, 1, 'John', 'Taylor', 1985-03-22, 'Programmer'), 
    (2, 1, 'Walter', 'Bondy', 1997-09-11, 'Database Administrator'), 
    (3, 2, 'Roxane', 'Myers', 1987-12-19, 'Accountant')}

departements это подмножество

    DepIds x DepNames

и так это отношение.

employees это подмножество

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

и это тоже отношение.

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

Почему математики называют набор кортежей отношением?

Обычно такие свойства, как «2 меньше 3», «4 равно 4», «2 составляет от 1 до 3,4», «-1 является отрицательным», называются отношениями.

Отношение «меньше чем» на множестве A = {1, 2, 3} определяется подмножеством

{(1, 2), (1, 3), (2, 3) }

из

A x A = {1, 2, 3} x {1, 2, 3}=
{ (1, 1), (1, 2), (1, 3), 
  (2, 1), (2, 2), (2, 3), 
  (3, 1), (3, 2), (3, 3) } 

Аналогичным образом другие отношения можно рассматривать как подмножество перекрестного продукта. «x меньше, чем y», «x равно y» являются бинарными отношениями и поэтому определяются набором пар. «x между y и z» является троичным отношением »и поэтому определяется набором троек. «x отрицательно» является унарным отношением и поэтому определяется набором синглетонов.

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