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

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

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

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

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

4.3.1. Общая характеристика

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

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

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

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

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

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

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

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

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

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

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

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

3.1. Базовые понятия реляционной модели

Концепция реляционной модели данных была предложена в 1969 году Эдгаром Коддом, известным специалистом в области баз данных, а в 1970 году она была им опубликованы. Реляционная модель представляет собой совокупность данных, состоящую из набора двумерных таблиц. В теории множеств таблице соответствует термин отношение (relation), физическим представлением которого является таблица, отсюда и название модели – реляционная. Реляционная модель является удобной и наиболее привычной формой представления данных.

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

Любая таблица в реляционной базе состоит из строк, которые называют записями, и столбцов, которые называют полями. На пересечении строк и столбцов находятся конкретные значения данных. Для каждого поля определяется множество его значений, например, поле «Месяц» может иметь двенадцать значений.

Структура таблицы в реляционной базе характеризуется следующим:

• · она состоит из совокупности столбцов;

• · каждый столбец имеет уникальное, то есть не повторяющееся в других столбцах, имя;

• · последовательность столбцов в таблице не существенна;

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

• · в таблице нет одинаковых строк;

• · количество строк в таблице практически не ограничено;

• · последовательность строк в таблице не существенна;

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

Для этого типа модели имеется развитый математический аппарат – реляционная алгебра. В реляционной алгебре поименованный столбец отношения называетсяатрибутом, а множество всех возможных значений конкретного атрибута – доменом. Строки таблицы со значениями разных атрибутов называют кортежами. Например, в таблице, приведенной на рис. 7, кортежи – это d_i1, d_i2,…,d_in (i=1,2,…m); а домены – d_1к, d_2к,…,d_mk (k=1,2,…n). Количество атрибутов, содержащихся в отношении, определяет его степень, а количество кортежей – кардинальность отношения.

Рис. Об этом говорит сайт https://intellect.icu . 7. Домены и кортежи отношения

Один или несколько атрибутов, значения которых однозначно определяют кортеж отношения, называется его ключом, или первичным ключом, или ключевым полем. То есть ключевое поле – это такое поле, значения которого в данной таблице не повторяется. Так, если таблица содержит список сотрудников, и в ней имеются поля:Табельный номер, ФИО, Должность, – то в качестве ключа можно взять поле Табельный номер. Базовые понятия реляционной модели проиллюстрированы на рис. 8.

Рис. 8. Базовые понятия реляционной модели данных

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

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

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

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

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

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

Рис. 9. Схема данных в СУБД Access

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

С появлением ПЭВМ реляционные системы стали доминировать среди систем баз данных. Быстрому распространению реляционных моделей способствовало три фактора.

Во-первых, в реляционной системе данные представляются в виде таблиц (отношений), встречающихся в повседневной практике. Поиск и обработка данных в этих таблицах не зависит от их организации и хранения в памяти машины.

Во-вторых, с математической точки зрения реляционная база – это конечный набор отношений. Таким образом, теория реляционных баз данных становится областью математической логики и реляционной алгебры.

В-третьих, множество объектов реляционной модели данных однородно – структура данных определяется только в терминах отношений. Основная единица обработки в операциях реляционной модели данных не запись (как в сетевых и иерархических моделях данных), а множество записей, то есть отношение.

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

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

Таким образом, достоинства реляционных баз данных можно сформулировать так.

• · Упрощенная схема представления данных – в виде таблицы.
• · Простота инструментальных средств поддержки реляционной модели.
• · Оптимизация доступа к базе данных, поскольку системы сами выбирают наиболее эффективную последовательность действий.
• · Улучшение целостности и защиты, поскольку реляционная модель позволяет улучшить выражение требований целостности путем использования языка высокого уровня.
• · Возможности различных применений, в том числе и рассчитанных на не специалистов в области программирования.
• · Обеспечение пользователя языками высокого уровня при работе с базой данных.
• · Обеспечение методологического подхода, поскольку главной целью модели базы данных является возможность описания реального мира, что проще всего осуществляется в реляционной модели.

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

В настоящее время многие известные системы управления базами данных используют именно реляционную модель представления данных –:это dBase, FoxBase,FoxPro, Paradox, Oracle, Microsoft Access, Clarion, Clipper, Ingres; отечественные: ПАЛЬМА, HyTech и др.

3.2. Связи между данными

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

где А и В – объекты;

F(x) – вид связи объекта А с объектом В;

G(x) – вид связи объекта В с объектом А.

Функции F(x) и G(x) могут принимать значения U – единичная и N – множественная связь. Обычно рассматривают четыре вида отношений.

Связь один к одному (1:1):

означает, что каждому элементу объекта А может соответствовать только один элемент объекта В и наоборот, например:

Связь один ко многим (1:N):

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

Университет Факультеты; Группа Студенты.

Связь многие к одному (N:1)

означает, что каждому экземпляру объекта А может соответствовать только один экземпляр объекта В, но среди экземпляров объекта В могут быть такие, которым соответствует несколько экземпляров объекта А, например:

Университет Факультеты; Покупатели Продавец.

Очевидно, что если 1:N – тип связи между А и В, то N:1 – тип связи между В и А.

Связь многие ко многим (N:M), или групповое:

означает, что может существовать экземпляр объекта А, которому соответствует несколько экземпляров объекта В и наоборот. Например:

Преподаватели Предметы; Покупатели Продавцы.

3.3. Операции в реляционных базах данных

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

К операциям обновления базы данных относятся те операции, которые выполняют вставку новых кортежей, удаление ненужных, корректировку значений атрибутов существующих кортежей, а именно: это операции Включить, Удалить, Обновить.

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

Операция Удалить требует наименования отношения, а также идентификации кортежа или группы кортежей, подлежащих удалению.

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

Что касается операций обработки, то они позаимствованы из реляционной алгебры. Существует несколько подходов к определению реляционной алгебры. Они отличаются набором операций и их интерпретацией. Рассмотрим набор операций, который предложил Э. Кодд. Согласно его подходу реляционная алгебра включает восемь операций, пять из которых являются базовыми: Выборка, Проекция, Умножение, Объединение, Вычитание.

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

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

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

В результате Объединения двух отношений получается третье, включающее кортежи, входящие хотя бы в одно отношение, то есть содержащее все элементы исходных отношений.

При Вычитании выдаются лишь те кортежи первого отношения, которые остались от вычитания второго отношения, то есть из первого отношения выбрасываются все кортежи второго.

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

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

Пересечение двух отношений является отношение, включающее все кортежи, входящие в оба отношения.

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

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

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

Операция Объединение (C1 = A И B) предполагает, что на входе задано два совместимых отношения, одинаковой размерности: А и В. Результат объединения есть отношение С1, той же структуры, содержащее все кортежи отношения А и все кортежи отношения В (рис. 10).

А ( банки Центрального района):

В ( банки Приморского района):

(C1 = A И B) ( банки Центрального и Приморского районов):

Рис. 10. Объединение отношений

Операция Пересечение (C2 = A З B) предполагает наличие на входе двух отношений одинаковой размерности: А и В. На выходе создается отношение той же структуры, содержащее только те кортежи отношения А, которые есть в отношении В (рис 11).

Отношение А Отношение В Отношение С

Рис. 11. Операция пересечения

Операция Деление. На входе операции используется два отношения: А и В. Пусть отношение А, называемое делимым, содержит атрибуты (А_1, А₂, А₃,…, А_n). Отношение В – делитель и содержит подмножество атрибутов А: (А_1, А₂, …, А_к), где kк+1, А_к+2,…,А_n.

Отношение А Отношение В Отношение С

Рис. 12. Операция деления

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

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

Вау!! 😲 Ты еще не читал? Это зря!

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

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