Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Реляционная модель данных, её особенности.

Содержание:

Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты:

  • Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.
  • Аспект (составляющая) целостности — отношения отвечают определённым условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
  • Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

Кроме того, в состав реляционной модели данных включают теорию нормализации.

Термин «реляционный» означает, что теория основана на математическом понятии отношение (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

Иванов

Олег

Юрист

1973

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