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

Базовые понятия

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

Реляционная модель данных описывает:

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

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

  • тип данных,
  • домен,
  • атрибут,
  • кортеж,
  • первичный ключ
  • и отношение.

Покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:

Тип данных

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

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

  1. Символьные данные (строки):

    • CHAR(n) — строка фиксированной длины (n символов).
    • VARCHAR(n) — строка переменной длины (до n символов).
    • TEXT — строка произвольной длины.

  2. Числовые данные:

    • INTEGER (или INT) — целое число.
    • SMALLINT — малое целое число.
    • BIGINT — большое целое число.
    • DECIMAL(p, s) или NUMERIC(p, s) — точные числа с фиксированной точностью (p — общее количество цифр, s — количество цифр после запятой).
    • FLOAT или REAL — числа с плавающей точкой.

  3. Специализированные числовые данные:

    • MONEY — тип для хранения денежных значений (обычно с фиксированной точностью).

  4. Темпоральные данные (временные):

    • DATE — дата (год, месяц, день).
    • TIME — время (часы, минуты, секунды).
    • TIMESTAMP — дата и время.
    • INTERVAL — временной интервал.

  5. Другие типы:

    • BOOLEAN — логический тип (TRUE/FALSE).
    • BLOB (Binary Large Object) — для хранения бинарных данных (например, изображений).
    • JSON или XML — для хранения структурированных данных в форматах JSON или XML.

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

  • В БД типы данных часто имеют более строгие ограничения (например, фиксированная длина строки CHAR(n)).
  • В БД типы данных могут быть оптимизированы для хранения и обработки больших объемов данных.
  • В БД поддерживаются специализированные типы (например, DATE, MONEY), которые редко встречаются в языках программирования в явном виде.

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

Домен

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

Домен — это множество допустимых значений для атрибута (столбца) таблицы, которое определяется на основе:

  1. Базового типа данных (например, целые числа, строки, даты).
  2. Ограничений (логических выражений), которые задают дополнительные правила для значений.

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

Например, домен «Имена» может быть определен следующим образом:

  • Базовый тип данных: VARCHAR(50) (строка символов длиной до 50 символов).
  • Ограничения:
    • Строка должна начинаться с заглавной буквы.
    • Строка не может начинаться с мягкого знака.
    • Строка может содержать только буквы и дефисы.

Таким образом, домен «Имена» не только определяет тип данных, но и задает правила, которые должны соблюдаться для всех значений этого домена.

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

Например,

  • Домен «Номера пропусков»:
    • Базовый тип: INTEGER.
    • Ограничения: значения должны быть положительными и уникальными.
  • Домен «Номера групп»:
    • Базовый тип: INTEGER.
    • Ограничения: значения должны быть в диапазоне от 1 до 100.

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

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

  • В языке Pascal можно определить тип TName = string[50], который ограничивает строки длиной 50 символов.
  • В языке Python можно использовать классы для создания пользовательских типов с дополнительными проверками.

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

Преимущества использования доменов:

  1. Семантическая ясность: домены делают данные более понятными, так как они отражают их смысл.
  2. Целостность данных: ограничения домена предотвращают попадание некорректных значений в базу данных.
  3. Упрощение проектирования: домены позволяют повторно использовать типы данных с одинаковыми ограничениями.
  4. Сравнимость данных: данные считаются сравнимыми только в пределах одного домена, что предотвращает логические ошибки.

Атрибут

Понятие атрибута в базах данных связано с полями записей и их характеристиками.

Атрибут — это свойство или характеристика сущности (объекта), которая описывается в таблице базы данных. В реляционной модели данных атрибут соответствует столбцу таблицы и характеризует:

  • Имя атрибута — уникальное название столбца (например, FirstName, Age, Salary).
  • Тип данных или домен — определяет, какие значения могут храниться в атрибуте (например, целые числа, строки, даты).

В нашем примере атрибутами являются:

  • СОТР_НОМЕР — тип данных: целое число.
  • СОТР_ИМЯ — тип данных: строка.
  • СОТР_ЗАРП — тип данных: число с плавающей точкой.
  • СОТР_ОТД_НОМЕР — тип данных: целое число.

Запись

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

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

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

  • Целые числа (INT).
  • Строки (VARCHAR, TEXT).
  • Даты (DATE).
  • Числа с плавающей точкой (DECIMAL, FLOAT).
  • Логические значения (BOOLEAN).

В нашем примере в отношениие СОТРУДНИКИ:

  • Каждая строка (например, 2934, "Иванов", 112.00 , 310) — это запись.
  • Поля записи:
    • СОТР_НОМЕР = 2934 (целое число).
    • СОТР_ИМЯ = "Иванов" (строка).
    • СОТР_ЗАРП = 112.00 (строка).
    • СОТР_ОТД_НОМЕР = 310 (целое число).

Каждая запись в таблице должна быть уникальной. Это обеспечивается с помощью первичного ключа (Primary Key), например, атрибута СОТР_НОМЕР. Поля в записи соответствуют порядку атрибутов в таблице.

Первичный ключ

Понятие ключа отношения (или просто ключа) в реляционных базах данных является фундаментальным для обеспечения уникальности и целостности данных.

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

Бывают ключи двух типов.

  1. Простой ключ:

    • Состоит из одного атрибута.
    • Пример: В отношении СОТРУДНИКИ атрибут СОТР_НОМЕР может быть простым ключом, если каждый сотрудник имеет уникальный (например, табельный) номер.

  2. Составной ключ:

    • Состоит из нескольких атрибутов.
    • Пример: Номер паспорта может состоять из атрибутов СЕРИЯ и НОМЕР.

Отношение

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

Отношение — это двумерная таблица, которая состоит из:

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

Отношение является основным способом представления данных в реляционной модели.

Реляционная алгебра

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

  • Выборка (SELECT) — извлечение строк, удовлетворяющих условию.
  • Проекция (PROJECT) — извлечение определенных столбцов.
  • Объединение (JOIN) — комбинирование данных из нескольких отношений.
  • Декартово произведение (CARTESIAN PRODUCT) — создание всех возможных комбинаций строк из двух отношений.

Фундаментальные свойства отношений

Рассмотрим некоторые важные свойства отношений:

  1. Отсутствие кортежей-дубликатов. То свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения как множества кортежей. В классической теории множеств по определению каждое множество состоит из различных элементов. Для каждого отношения по крайней мере полный набор его атрибутов обладает этим свойством. Однако при формальном определении первичного ключа требуется обеспечение его «минимальности», т.е. в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно отбросить без ущерба для основного свойства - однозначно определять кортеж. Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных. Заметим, что во многих практических реализациях реляционных СУБД допускается нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в ряде случаев позволяет добиться определенных преимуществ, но иногда приводит к серьезным проблемам.
  2. Отсутствие упорядоченности кортежей. Свойство отсутствия упорядоченности кортежей отношения также является следствием определения отношения-экземпляра как множества кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядоченный список кортежей.
  3. Отсутствие упорядоченности атрибутов. Атрибуты отношений не упорядочены. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов.
  4. Атомарность значений атрибутов. Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения).

Целостность сущности и ссылок

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

Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). При правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ ) (первичный ключ -ОТД_НОМЕР) и СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) (первичный ключ - СОТР_НОМЕР).

Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.

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

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

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

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

Преимущества реляционного подхода

Преимущества реляционного подхода достаточно очевидны:

  1. Предсказуемость результатов работы с данными. В основе реляционной модели лежит математическая модель, следовательно, любой запрос к базе данных, составленный на корректном языке влечет ответ, однозначно определяемый схемой БД и конкретными данными. При этом пользователю не требуется информация о физической организации данных.
  2. Предметная область часто достаточно естественно описывается в терминах таблиц.

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

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

Конкретные требования к реляционной СУБД раскрываются в следующих правилах:

  1. Информационное правило. Вся информация, хранимая в базе данных, должна быть представлена единственным образом: в виде значений в реляционных таблицах.

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

  3. Правило наличия значения (missing information). В полностью реляционной СУБД должны иметься специальные индикаторы (отличные от пустой символьной строки или строки из одних пробелов и отличные от нуля или какого-то другого числового значения) для выражения (на логическом уровне, не зависимо от типа данных) того факта, что значение отсутствует по меньшей мере по двум различным причинам: его действительно нет, либо оно не применимо к данной позиции. СУБД должна не только отражать этот факт, но и распространять на такие индикаторы свои функции манипулирования данными не зависимо от типа данных. Как правило это значение обозначается NULL.

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

  5. Правило полноты языка работы с данными. Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выразимый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:

    1. определение данных;
    2. определение правил целостности;
    3. манипулирование данными (в диалоге и из программы);
    4. определение таблиц-представлений (в том числе и возможности их модификации);
    5. определение правил авторизации;
    6. границы транзакций.

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

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

  8. Правило физической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или методах доступа СУБД

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

  10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД, задаваемых языком работы с данными и хранимых в системном каталоге.

  11. Правило независимости от распределенности. Диалоговые операторы и прикладные программы на логическом уровне не должны зависеть от совершаемого физического разнесения данных (если первоначально СУБД работала с нераспределенными данными) или перераспределения (если СУБД распределенная).

  12. Правило ненарушения реляционного языка. Если в реляционной СУБД имеется язык низкого уровня (для работы с отдельными строками), он не должен позволять нарушать или «обходить» правила, сформулированные на языке высокого уровня (множественном) и занесенные в системный каталог.

Контрольные вопросы

  1. Дайте определение реляционной модели данных?
  2. Что описывает реляционная модель данных?
  3. Назовите основные понятия реляционной БД?
  4. Чем тип данных отличается от домена?
  5. Назовите особенности типов данных в базах данных?
  6. Что лежит в основе определения домена?
  7. Назовите преимущества использования доменов?
  8. Что такое атрибут?
  9. Дайте определение записи?
  10. Дайте определение первичного ключа?
  11. Что такое отношение?
  12. Назовите основные операции реляционной алгебры?
  13. Назовите фундаментальные свойства отношений и объясните их смысл?
  14. В чем заключается целостность сущности?
  15. В чем состоит требования целостности по ссылкам?
  16. Как поддерживается целостность по ссылкам?
  17. Объясните преимущества реляционного подхода?
  18. Какие требования предъявляются к реляционным СУБД?