itmo_conspects

Лекция 4. Отношение

В конечном итоге появилась реляционная модель данных, созданная Эдгаром Коддом.

Введем следующие термины:

Отношение - двумерная таблица, содержащая данные

Столбец отношения - атрибут, некое свойство, характеризующее сущность

Строка отношения - кортеж, описывающий экземпляр сущности

Причем, не каждое отношение является сущностью - например: у нас есть производители (vendor) и продукты, которые они производят (product), так как разные производители могут производить одни и те же продукты, то необходимо отдельное отношение с парами vendor-product

И к тому же, не каждая сущность является отношением - например: паспорт - не сущность, но может быть выделен в отдельное отношение

Степень отношения - количество атрибутов

Кардинальность отношения - количество кортежей в отношении

Домен - множество допустимых значений атрибута

Эдгар Кодд сформулировал, что отношение - кортеж атрибутов, значений которых принадлежат некоторому домену

image1

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

Схема отношений - заголовки отношений

В конечном итоге во время своей работы в IBM Эдгар Кодд сформулировал, что отношение R будет являться отношением тогда, когда выполняются 6 свойств:

  1. Каждое поле содержит только одно неделимое значение

    Здесь же появляется вопрос, что считать неделимым значение? Например, в SQL существуют строки, которые можно разделить на символы. Помимо этого строки в SQL можно сравнивать при помощи ключевого слова LIKE

  2. Каждый кортеж уникален

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

  3. Уникальность имени отношения в реляционной схеме

    Тоже разумное свойство, но представим пример: поглощение СПбГУНиПТ университетом ИТМО в 2011 году, в те времена у обоих университетов были базы данных с таблицей Student, и казалось бы возникла проблема с объединением этих баз данных

  4. Уникальность имени атрибута в пределах отношения

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

  5. Значения атрибута берутся из одного и того же домена

  6. Порядок следования атрибутов и порядок следования кортежей не имеют значения

    И от этого свойства сразу же отказались, использовать ORDER BY с указанием номера столбца (что означало бы, что атрибуты имеют порядок) было очень удобно

И как можно заметить, одновременно эти все свойства на практике реализовать нельзя было, да и к тому же было бы супер неудобно для пользователей

Теперь рассмотрим определения ключей:

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

ИСУ ФИО N группы Серия паспорта Номер паспорта
         

В этом случае, номер ИСУ - суперключ. Также очевидно, что в таблице с уникальными кортежами сам кортеж будет являться суперключом

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

В примере выше номер ИСУ - потенциальный суперключ, также, как и комбинация из серии и номера паспорта. Поэтому потенциальный ключ может не являться суперключом из таблицы, состоящим из минимального числа атрибутов

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

Первичный ключ (Primary key) - потенциальный ключ, который выбран для уникальной идентификации кортежа в отношении

Внешний ключ (Foreign key) - атрибут или множество атрибутов, которые соответствуют потенциальному ключу некоторого (может быть того же самого) отношения

В случае со студентами, номер группы у студента - внешний ключ

Внешний ключ, в том числе, может соответствовать ключу в том же отношении:

ИСУ сотрудника PK ФИО ИСУ руководителя FK
     

При этом связи One-to-One и One-to-Many означают, что первичные ключи отношения являются внешними ключами в другом, например, номер ИСУ в таблице с паспортами студентов - внешний ключ; номер группы в таблице студентов - внешний ключ, который соотносится с первичным в таблице групп

А связь Many-to-Many требует уже таблицу-связку, как в примере выше про производителя и продукты (vendor-product)

Тут же выделяем два вида целостности:

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