В конечном итоге появилась реляционная модель данных, созданная Эдгаром Коддом.
Введем следующие термины:
Отношение - двумерная таблица, содержащая данные
Столбец отношения - атрибут, некое свойство, характеризующее сущность
Строка отношения - кортеж, описывающий экземпляр сущности
Причем, не каждое отношение является сущностью - например: у нас есть производители (vendor) и продукты, которые они производят (product), так как разные производители могут производить одни и те же продукты, то необходимо отдельное отношение с парами vendor-product
И к тому же, не каждая сущность является отношением - например: паспорт - не сущность, но может быть выделен в отдельное отношение
Степень отношения - количество атрибутов
Кардинальность отношения - количество кортежей в отношении
Домен - множество допустимых значений атрибута
Эдгар Кодд сформулировал, что отношение - кортеж атрибутов, значений которых принадлежат некоторому домену
И в отличие от иерархической и сетевой моделей, где хранятся связи (указатели на поля родителей), в реляционной связи связи прямым способом не хранятся
Схема отношений - заголовки отношений
В конечном итоге во время своей работы в IBM Эдгар Кодд сформулировал, что отношение R будет являться отношением тогда, когда выполняются 6 свойств:
Каждое поле содержит только одно неделимое значение
Здесь же появляется вопрос, что считать неделимым значение? Например, в SQL существуют строки, которые можно разделить на символы. Помимо этого строки в SQL можно сравнивать при помощи ключевого слова LIKE
Каждый кортеж уникален
На первый взгляд это свойство выглядит разумно, но при применении инструкции SELECT
в SQL может создаться временная таблица, в которой могут существовать неуникальные кортежи. Это может быть решено при помощи ключевого слова DISTINCT
, но дубликаты кортежей могут быть полезны для подсчета сущностей
Уникальность имени отношения в реляционной схеме
Тоже разумное свойство, но представим пример: поглощение СПбГУНиПТ университетом ИТМО в 2011 году, в те времена у обоих университетов были базы данных с таблицей Student
, и казалось бы возникла проблема с объединением этих баз данных
Уникальность имени атрибута в пределах отношения
Еще одно очевидное свойство, но при операции JOIN
(объединения таблиц) в SQL может создаться отношение с одинаковыми атрибутами
Значения атрибута берутся из одного и того же домена
Порядок следования атрибутов и порядок следования кортежей не имеют значения
И от этого свойства сразу же отказались, использовать ORDER BY
с указанием номера столбца (что означало бы, что атрибуты имеют порядок) было очень удобно
И как можно заметить, одновременно эти все свойства на практике реализовать нельзя было, да и к тому же было бы супер неудобно для пользователей
Теперь рассмотрим определения ключей:
Суперключ - атрибут или множество атрибутов, единственным образом идентифицирующий кортеж
ИСУ | ФИО | N группы | Серия паспорта | Номер паспорта |
---|---|---|---|---|
В этом случае, номер ИСУ - суперключ. Также очевидно, что в таблице с уникальными кортежами сам кортеж будет являться суперключом
Потенциальный ключ - суперключ, который не содержит подмножества, также являющегося суперключом данного отношения
В примере выше номер ИСУ - потенциальный суперключ, также, как и комбинация из серии и номера паспорта. Поэтому потенциальный ключ может не являться суперключом из таблицы, состоящим из минимального числа атрибутов
Потенциальный ключ из одного атрибута называют простыми, а из более одного - составным
Первичный ключ (Primary key) - потенциальный ключ, который выбран для уникальной идентификации кортежа в отношении
Внешний ключ (Foreign key) - атрибут или множество атрибутов, которые соответствуют потенциальному ключу некоторого (может быть того же самого) отношения
В случае со студентами, номер группы у студента - внешний ключ
Внешний ключ, в том числе, может соответствовать ключу в том же отношении:
ИСУ сотрудника PK |
ФИО | ИСУ руководителя FK |
---|---|---|
При этом связи One-to-One и One-to-Many означают, что первичные ключи отношения являются внешними ключами в другом, например, номер ИСУ в таблице с паспортами студентов - внешний ключ; номер группы в таблице студентов - внешний ключ, который соотносится с первичным в таблице групп
А связь Many-to-Many требует уже таблицу-связку, как в примере выше про производителя и продукты (vendor-product)
Тут же выделяем два вида целостности:
Теперь необходимо от этой реляционной модели данных перейти к языку SQL. Но перед этим нужно ввести реляционную алгебру.