Реляционная модель данных: кем, когда и для чего создана
Структура данных в реляционной модели данных
Отношения и их реализация в реляционной модели данных
Ключи отношения в реляционной модели данных
Достоинства и недостатки реляционной модели данных
Ссылки на используемые источники в тексте
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
- Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.
- Аспект (составляющая) целостности — отношения отвечают определённым условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
- Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями и не могут быть ни «плоскими», ни «неплоскими».
Для лучшего понимания РМД следует отметить три важных обстоятельства:
- модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
- для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
- наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Принципы реляционной модели были сформулированы в 1969—1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые публично изложены в статье «A Relational Model of Data for Large Shared Data Banks»[1][2], ставшей классической.
Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems» («Дейт, К. Дж. Введение в системы баз данных»).
Наиболее известными альтернативами реляционной модели являются иерархическая модель, и сетевая модель. Некоторые системы, использующие эти старые архитектуры, используются до сих пор. Кроме того, можно упомянуть об объектно-ориентированной модели, на которой строятся так называемые объектно-ориентированные СУБД, хотя однозначного и общепринятого определения такой модели нет.
Реляционная модель данных: кем, когда и для чего создана
Реляционная модель данных — созданная Эдгаром Коддом логическая модель данных, описывающая:
- структуры данных в виде (изменяющихся во времени) наборов отношений;
- теоретико-множественные операции над данными: объединение, пересечение разность и декартово произведение;
- специальные реляционные операции: селекция, проекция, соединение и деление;
- специальные правила, обеспечивающие целостность данных.
Эдгар Франк «Тед» Кодд — (23 августа 1923 —18 апреля 2003) — британский учёный, работы которого заложили основы теории реляционных баз данных. Работая в компании IBM, он создал реляционную модель данных. В 1970 издал работу «A Relational Model of Data for Large Shared Data Banks», которая считается первой работой по реляционной модели данных.
Реляционная модель данных — это способ рассмотрения данных, то есть предписание для способа представления данных (посредством таблиц) и для способа работы с таким представлением (посредством операторов). Она связана с тремя аспектами данных: структурой (объекты), целостностью и обработкой данных (операторы).
В 2002 журнал Forbes поместил реляционную модель данных в список важнейших инноваций последних 85 лет.
Цели создания реляционной модели данных:
- обеспечение более высокой степени независимости от данных;
- создание прочного фундамента для решения семантических вопросов и проблем непротиворечивости и избыточности данных;
- засширение языков управления данными за счёт включения операций над множествами.
Структура данных в реляционной модели данных
Реляционная модель данных предусматривает структуру данных, обязательными объектами которой являются:
- отношение;
- атрибут;
- домен;
- кортеж;
- степень;
- кардинальность;
- первичный ключ.
Отношение — это плоская (двумерная) таблица, состоящая из столбцов и строк:
ID |
Фамилия |
Имя |
Должность |
г.р. |
1 |
Петров |
Игорь |
Директор |
1968 |
2 |
Иванов |
Олег |
Юрист | |
3 |
Ким |
Елена |
Бухгалтер |
1980 |
4 |
Сенин |
Илья |
Менеджер |
1981 |
5 |
Васин |
Сергей |
Менеджер |
1978 |
Атрибут — это поименованный столбец отношения.
Домен — это набор допустимых значений для одного или нескольких атрибутов.
Кортеж — это строка отношения.
Степень определяется количеством атрибутов, которое оно содержит
Кардинальность — это количество кортежей, которое содержит отношение.
Первичный ключ — это уникальный идентификатор для таблицы.
Соответствие между формальными терминами реляционной модели данных и неформальными:
отношение (формальный термин) — таблица (неформальный термин);
атрибут — столбец;
кортеж — строка или запись;
- отношение (формальный термин) — таблица (неформальный термин);
- атрибут — столбец;
- кортеж — строка или запись;
- степень — количество столбцов;
- кардинальное число — количество строк;
- первичный ключ — уникальный идентификатор;
- домен — общая совокупность допустимых значений.
Отношения и их реализация в реляционной модели данных
Отношение R на множестве доменов D1, D2, …, Dn — это подмножество декартова произведения этих доменов:
R ⊆ D1 × D2 × … × Dn
Пример 1. Определены домены: D1 — множество фамилий преподавателей, D2 — множество аудиторий, D3 — множество учебных групп, D4 — множество учебных дисциплин. Записать отношения: 1) закрепление преподавателей за учебными курсами; 2) расписание занятий в группах.
Решение.
1) закрепление преподавателей за учебными курсами:
R ⊆ D1 × D4.
Это отношение определяет множество преподавателей, ведущих множество учебных дисциплин.
2) расписание занятий в группах:
R ⊆ D2 × D3 × D4.
Это отношение определяет множество аудиторий, в которых проводятся занятия по множеству учебных дисциплин для множества учебных групп.
Свойства отношений:
- уникальное имя отношения;
- уникальное имя атрибута;
- нет одинаковых кортежей;
- кортежи не упорядочены сверху вниз;
- атрибуты не упорядочены слева направо;
- все значения атрибутов атомарные (нормализованное отношение).
Таким образом, реляционная база данных — это набор нормализованных отношений. Для того, чтобы перейти к видам отношений, введём понятие переменной отношения. Переменная отношения — это именованный объект, значение которого может изменяться с течением времени. Переменная отношения в разное время — это различные таблицы базы данных, у которых разные строки, но одинаковые столбцы.
Виды отношений:
- именованное отношение;
- базовое отношение;
- производное отношение;
- выражаемое отношение;
- представление (view);
- снимки (snapshot);
- результат запроса;
- промежуточный результат.
Именованное отношение — это переменная отношения, определённая в СУБД (системе управления базами данных) посредством оператора CREATE (CREATE TABLE, CREATE BASE RELATION, CREATE VIEW, CREATE SNAPSHOT).
Базовое отношение — это именованное отношение, которое не является производным. Существование базового отношения не зависит от существования других отношений.
Производное отношение — это отношение, которое определено через другие именованные отношения. Производное отношение зависит от существования других — базовых — отношений.
Выражаемое отношение — это отношение, которое можно получить из набора именованных отношений посредством некоторого реляционного выражения. Каждое именованное отношение является выражаемым отношений, но не наоборот. Примеры выражаемых отношений — базовые отношения, представления, снимки, промежуточные и окончательные результаты. Множество всех выражаемых отношений — это множество всех базовых и всех производных отношений.
Представление — это именованное производное отношение. Представлены в базе данных в виде определения. Представление не хранится в физической памяти системы управления базой данных (СУБД), а формируется с использованием других именованных отношений.
Снимки (snapshot) — это то же, что и представление, но с физическим сохранением и с периодическим обновлением.
Результат запроса — это неименованное производное отношение. СУБД не обеспечивает постоянного существования результатов запросов. Для сохранения результата запроса его можно присвоить какому-либо именованному отношению.
Промежуточный результат — это неименованное производное отношение, являющееся результатом подзапроса, вложенного в бОльшее выражение.
Ключи отношения в реляционной модели данных
Ключи отношения могут быть следующми:
- суперключ;
- потенциальный ключ;
- первичный ключ;
- внешний ключ;
- суррогатный ключ.
Ключ отношения — это подсхема исходной схемы отношения, состоящая из одного или нескольких атрибутов, для которых декларируется условие уникальности значений в кортежах отношений. При объявлении схемы базового отношения могут быть заданы объявления нескольких ключей.
Ключ отношения может быть простым или составным. Простой ключ – это ключ, состоящий из одного и не более атрибута. Составной ключ -ключ, состоящий из двух и более атрибутов.
Суперключ — это атрибут или множество атрибутов, которое единственным образом идентифицирует кортеж данного отношения. Он может включать дополнительные атрибуты. Суперключ не обладает свойством неизбыточности.
Потенциальный ключ — это подмножество атрибутов отношения, удовлетворяющее требованиям уникальности и неизбыточности. Он обладает следующими свойствами. Уникальность: в таблице нет двух разных строк с одинаковыми значениями в нашем потенциальном ключе. Неизбыточность: нельзя убрать один из столбцов из ключа, так, чтобы он не потерял уникальности. В отношении может быть больше одного потенциального ключа.
Первичный ключ (primary key, PK) — это один из потенциальных ключей отношения, выбранный в качестве основного ключа. Допустимо объявление одного и только одного первичного ключа. Атрибуты первичного ключа не могут принимать значения Null.
Внешний ключ (foreign key, FK) — это ключ, объявленный в базовом отношении, который при этом ссылается на первичный того же самого или какого-то другого базового отношения.
Суррогатный ключ — это служебный атрибут, добавленный к уже имеющимся информационным атрибутам отношения. Предназначение суррогатного ключа — служить первичным ключом отношения. Значение этого атрибута генерируется искусственно.
Пример 2. Есть база данных сети аптек. В ней есть таблица «Аптеки», в которую занесены все аптеки сети, и есть таблица «Препараты». Кроме того, есть таблица «Наличие», в которую заносятся данные о наличии препаратов в каждой аптеке. В таблице наличие есть поля: «Аптека» (в ней — идентификаторы аптек), «Препарат» (в ней — идентификаторы препаратов), «Количество». Возникает проблема: в случае поступления в аптеку некоторого количества препарата можно не заметить, что в той же аптеке тот же препарат уже содержится в некотором количестве и сделать новую записись в таблице, в которой аптека и препарат будут повторяться. Как на уровне ключей избежать этой проблемы?
Решение. Можно объявить первичным ключём таблицы «Наличие» составной ключ, состоящий из идентификатора аптеки и идентификатора препарата. Тогда в таблице невозможно повторение в разных записях сочетания аптеки и прапарата. Первичный ключ может быть не только простым, но и составным.
В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Как мы видели в предыдущем разделе, это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.
Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).
Достоинства и недостатки реляционной модели данных
- Изложение информации в простой и понятной для пользователя форме (таблица).
- Реляционная модель данных основана на строгом математическом аппарате, что позволяет лаконично описывать необходимые операции над данными.
- Независимость данных от изменения в прикладной программе при изменении.
- Позволяет создавать языки манипулирования данными не процедурного типа.
- Для работы с моделью данных нет необходимости полностью знать организацию БД.
- Относительно медленный доступ к данным.
- Трудность в создании БД основанной на реляционной модели.
- Трудность в переводе в таблицу сложных отношений.
- Требуется относительно большой объем памяти.
Ссылки на используемые источники в тексте.
1) https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
2) https://function-x.ru/sql_relation_data_model.html
3) https://ru.bmstu.wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85