Реляционная модель данных это кратко

Обновлено: 06.07.2024

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

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

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

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

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

Для лучшего понимания РМД следует отметить три важных обстоятельства:

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

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

Этот документ является переводом части лекции Майка Байера (Michael Bayer) о SQLAlchemy, которая была представлена на Pycon 2013.

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

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

Таблица¶

../_images/review_table.jpg

Язык описания данных (DDL)¶

В SQL для создания таблицы используется оператор CREATE TABLE. Этот оператор является примером языка описания данных (DDL). DDL служит для описания структуры базы данных. Пример использования:

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

Правильным считается наличие первичного ключа во всех таблицах базы данных. При этом существует два варианта первичных ключей: искусственный (surrogate primary key) и естественный (natural primary key).

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

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

Пример создания первичного ключа:

Внешние ключи¶

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

../_images/review_foreignkey.jpg

Представленная на рисунке связь может быть описана через DDL следующим образом:

Нормализация¶

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

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

Классический пример денормализованных данных:

Employee Language ¶
name language department
Dilbert C++ Systems
Dilbert Java Systems
Wally Python Engineering
Wendy Scala Engineering
Wendy Java Engineering

Employee Department ¶
name department
Dilbert Systems
Wally Engineering
Wendy Engineering
Employee Language ¶
name language
Dilbert C++
Dilbert Java
Wally Python
Wendy Scala
Wendy Java

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

Если таблицу удаётся сходу свернуть в отношения ключей, то это, зачастую, значит, что она не нормализована.

Язык управления данными (DML)¶

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

Вставка (insert)¶

Новые строки добавляются с помощью команды INSERT . Эта команда содержит часть VALUES , в которой прописаны данные для каждой добавляемой строки:

Автоинкрементные целочисленные ключи

Базы данных с этой функциональностью также позволяют получить сгенерированное при вставке значение. При этом используются нестандартные для SQL конструкции и / или функции. Например, в PostgreSQL это параметр RETURNING :

Обновление (Update)¶

Команда UPDATE служит для изменения данных в существующих строках, использую параметр WHERE для фильтрации строк по какому-либо условию и параметр SET для установки нового значения в нужный столбец:

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

Удаление (Delete)¶

Команда DELETE служит для удаления строк. Также как и UPDATE использует параметр WHERE для выборки нужных строк:

Запросы (Queries)¶

Ключевой особенностью SQL является возможность построения запросов к данным. Для этого используется команда SELECT . Также как и в командах UPDATE и DELETE в ней присутствует параметр WHERE .

../_images/review_select.jpg

Например, можно выбрать строки у которых dep_id равен 12 :

Команда SELECT из примера выше имеет следующие части:

  1. Параметр FROM указывает таблицы, из которых выбираются строки.
  2. Параметр WHERE используется для фильтрации выбираемых строк по какому-либо условию.
  3. Между словами SELECT и FROM расположен список столбцов, которые необходимо показать из каждой отфильтрованной строки.

Результат примера может выглядеть как-то так:

emp_id emp_name
1 wally
2 dilbert
5 wendy

Сортировка¶

К команде SELECT можно добавить параметр ORDER BY задающий по какому полю сортировать результаты:

Объединения (Joins)¶

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

Параметр JOIN помещается внутри блока FROM , между именами объединяемых таблиц. Он, в свою очередь, в себе содержит параметр ON , который отвечает за критерий объединения строк из разных таблиц.

../_images/review_join.jpg

JOIN создаёт промежуточную структуру табличного вида. Она содержит в себе объединенные данные из обоих таблиц.

Используя примеры с таблицами Department и Employee, выберем сотрудников вместе с названиями их отделов:

emp_id emp_name dep_name
2 dilbert Software Artistry
1 wally Software Artistry
5 wendy Software Artistry

Левое внешнее объединение (Left Outer Join)¶

dep_name emp_name
Management dogbert
Management boss
Software Artistry dilbert
Software Artistry wally
Software Artistry wendy
Sales

Агрегация¶

Функция агрегации принимает на вход множество значений, выдавая на выходе одно. Наиболее часто используемая функция агрегации - это``count()``. Она получает набор строк и возвращает их количество.

Другая функция агрегации может вернуть нам среднее количество сотрудников в офисах. Для этого нам также потребуется использовать конструкцию GROUP BY в подзапросе:

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

Группировка¶

Конструкция GROUP BY , применяемая в выражении SELECT , служит для группировки результатов по какому-либо полю. Она зачастую используется совместно с агрегацией для применения агрегирующей функции к каждой из групп.

../_images/review_grouping.jpg

В качестве примера совместного использования агрегации и конструкции GROUP BY рассчитаем количество сотрудников в каждом отделе:

Having¶

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

Выборка. Резюме¶

Рассмотрим, как команда SELECT ведёт себя при комбинации всех вышеописанных конструкций.

Для примера возьмём следующий набор строк:

Employee ¶
emp_id emp_name dep_id
1 wally 1
2 dilbert 1
3 jack 2
4 ed 3
5 wendy 1
6 dogbert 4
7 boss 3

К которому будет применён вот этот код:

Конструкция FROM определяет таблицы, из которых будут выбраны строки. В нашем примере это таблица employee :

emp_id emp_name dep_id
1 wally 1
2 dilbert 1
3 jack 2
4 ed 3
5 wendy 1
6 dogbert 4
7 boss 3

Каждая строка проверяется на соответствие условию, описанному в блоке WHERE . Только строки, прошедшие эту проверку, подвергаются дальнейшей обработке:

emp_id emp_name dep_id
1 wally 1
2 dilbert 1
4 ed 3
5 wendy 1
6 dogbert 4
7 boss 3

Затем производится фоновая группировка по какому-либо критерия с помощью конструкции GROUP BY . Дальнейшая обработка производится уже над этими группами. Для текущего примера это выглядит следующим образом:

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

В конце применяется конструкция ORDER BY . Важно помнить, что реляционная математика, заложенная в основу SQL, базируется на понятии множеств. Которые являются по определению неупорядоченными. В обычном случае выборка, агрегация и фильтрация применяются к неупорядоченным строкам. И только в конце, перед отдачей результата пользователю, производится упорядочивание по какому-либо признаку:

Модель ACID¶

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

Атомарность (Atomicity)¶

Согласованность (Consistency)¶

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

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

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

Изолированность (Isolation)¶

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

Надежность (Durability)¶

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

© Copyright 2019, Кафедра Интеллектуальных Информационных Технологий ИнФО УрФУ. Created using Sphinx 1.7.6.

Реляционная модель данных: кем, когда и для чего создана

Реляционная модель данных - созданная Эдгаром Коддом логическая модель данных, описывающая:

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

Реляционная модель данных - это способ рассмотрения данных, то есть предписание для способа представления данных (посредством таблиц) и для способа работы с таким представлением (посредством операторов). Она связана с тремя аспектами данных: структурой (объекты), целостностью и обработкой данных (операторы).

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

Цели создания реляционной модели данных:

  • обеспечение более высокой степени независимости от данных;
  • создание прочного фундамента для решения семантических вопросов и проблем непротиворечивости и избыточности данных;
  • засширение языков управления данными за счёт включения операций над множествами.

Структура данных в реляционной модели данных

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

Отношение - это плоская (двумерная) таблица, состоящая из столбцов и строк:

IDФамилияИмяДолжностьг.р.
1ПетровИгорьДиректор1968
2ИвановОлегЮрист1973
3КимЕленаБухгалтер1980
4СенинИльяМенеджер1981
5ВасинСергейМенеджер1978

Атрибут - это поименованный столбец отношения.

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

Кортеж - это строка отношения.

Степень определяется количеством атрибутов, которое оно содержит

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

Первичный ключ - это уникальный идентификатор для таблицы.

Соответствие между формальными терминами реляционной модели данных и неформальными:

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

Отношения и их реализация в реляционной модели данных

Отношение R на множестве доменов D 1 , D 2 , …, D n - это подмножество декартова произведения этих доменов:

Пример 1. Определены домены: D 1 - множество фамилий преподавателей, D 2 - множество аудиторий, D 3 - множество учебных групп, D 4 - множество учебных дисциплин. Записать отношения: 1) закрепление преподавателей за учебными курсами; 2) расписание занятий в группах.

1) закрепление преподавателей за учебными курсами:

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

2) расписание занятий в группах:

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

Свойства отношений:

  • уникальное имя отношения;
  • уникальное имя атрибута;
  • нет одинаковых кортежей;
  • кортежи не упорядочены сверху вниз;
  • атрибуты не упорядочены слева направо;
  • все значения атрибутов атомарные (нормализованное отношение).

Таким образом, реляционная база данных - это набор нормализованных отношений. Для того, чтобы перейти к видам отношений, введём понятие переменной отношения. Переменная отношения - это именованный объект, значение которого может изменяться с течением времени. Переменная отношения в разное время - это различные таблицы базы данных, у которых разные строки, но одинаковые столбцы.

Виды отношений:

  • именованное отношение;
  • базовое отношение;
  • производное отношение;
  • выражаемое отношение;
  • представление (view);
  • снимки (snapshot);
  • результат запроса;
  • промежуточный результат.

Именованное отношение - это переменная отношения, определённая в СУБД (системе управления базами данных) посредством оператора CREATE (CREATE TABLE, CREATE BASE RELATION, CREATE VIEW, CREATE SNAPSHOT).

Базовое отношение - это именованное отношение, которое не является производным. Существование базового отношения не зависит от существования других отношений.

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

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

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

Снимки (snapshot) - это то же, что и представление, но с физическим сохранением и с периодическим обновлением.

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

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

Ключи отношения в реляционной модели данных

Ключи отношения могут быть следующми:

  • суперключ;
  • потенциальный ключ;
  • первичный ключ;
  • внешний ключ;
  • суррогатный ключ.

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

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

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

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

Первичный ключ (primary key, PK) - это один из потенциальных ключей отношения, выбранный в качестве основного ключа. Допустимо объявление одного и только одного первичного ключа. Атрибуты первичного ключа не могут принимать значения Null.

Внешний ключ (foreign key, FK) - это ключ, объявленный в базовом отношении, который при этом ссылается на первичный того же самого или какого-то другого базового отношения.

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

Пример 2. Есть база данных сети аптек. В ней есть таблица "Аптеки", в которую занесены все аптеки сети, и есть таблица "Препараты". Кроме того, есть таблица "Наличие", в которую заносятся данные о наличии препаратов в каждой аптеке. В таблице наличие есть поля: "Аптека" (в ней - идентификаторы аптек), "Препарат" (в ней - идентификаторы препаратов), "Количество". Возникает проблема: в случае поступления в аптеку некоторого количества препарата можно не заметить, что в той же аптеке тот же препарат уже содержится в некотором количестве и сделать новую записись в таблице, в которой аптека и препарат будут повторяться. Как на уровне ключей избежать этой проблемы?

Решение. Можно объявить первичным ключём таблицы "Наличие" составной ключ, состоящий из идентификатора аптеки и идентификатора препарата. Тогда в таблице невозможно повторение в разных записях сочетания аптеки и прапарата. Первичный ключ может быть не только простым, но и составным.

Целостность данных в реляционной модели данных

Понятия реляционной целостности:

  • определитель NULL;
  • целостность сущностей;
  • ссылочная целостность;
  • корпоративные ограничения целостности.

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

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

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

  1. Ограничение удаления–Delete: Restrict.
  2. Каскадное удаление–Delete: Cascade.
  3. Установка значения NULL, перевод значения внешнего ключа в неопределённое состояние – Delete: Set NULL.

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

Каскадное удаление. При удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.

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

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

Как это делается на уровне языка запросов SQL - в материале SQL ALTER TABLE - изменение таблицы базы данных.

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

В 1970 году появились работы, в которых обсуждались возможности применения различных табличных моделей данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших совместно используемых банков данных). CACM 13: 6, June 1970), где впервые был применен термин "реляционная модель данных". Проект System R был разработан в исследовательской лаборатории корпорации IBM. Этот проект был задуман с целью доказать практичность реляционной модели. Реляционные СУБД относятся к СУБД второго поколения.

Цели создания реляционной модели данных:

1. Обеспечение более высокой степени независимости от данных.

2. Создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.

3. Расширение языков управления данными за счет включения операций над множествами.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД.

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

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

- реляционная БД – набор нормализованных отношений;

- отношение – файл, плоская таблица, состоящая из столбцов и строк; таблица, в которой каждое поле является атомарным;

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

- универсум – совокупность значений всех полей или совокупность доменов;

- кортеж – запись, строка таблицы;

- кардинальность - количество строк в таблице;

- атрибуты – поименованныеполя, столбцы таблицы;

- степень отношения - количество полей (столбцов);

- схема отношения – упорядоченный список имен атрибутов;

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

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

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

Соотношение этих понятий иллюстрируется на рис. 4.5.

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

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

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




Внешние ключи реализуют связи между таблицами БД.

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

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

Каждая реляционная таблица обладает следующими свойствами:

- имеет имя, которое отличается от имен всех других таблиц;

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

- все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

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

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

В 1970 году появились работы, в которых обсуждались возможности применения различных табличных моделей данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших совместно используемых банков данных). CACM 13: 6, June 1970), где впервые был применен термин "реляционная модель данных". Проект System R был разработан в исследовательской лаборатории корпорации IBM. Этот проект был задуман с целью доказать практичность реляционной модели. Реляционные СУБД относятся к СУБД второго поколения.

Цели создания реляционной модели данных:

1. Обеспечение более высокой степени независимости от данных.

2. Создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.

3. Расширение языков управления данными за счет включения операций над множествами.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД.

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

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

- реляционная БД – набор нормализованных отношений;

- отношение – файл, плоская таблица, состоящая из столбцов и строк; таблица, в которой каждое поле является атомарным;

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

- универсум – совокупность значений всех полей или совокупность доменов;

- кортеж – запись, строка таблицы;

- кардинальность - количество строк в таблице;

- атрибуты – поименованныеполя, столбцы таблицы;

- степень отношения - количество полей (столбцов);

- схема отношения – упорядоченный список имен атрибутов;

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

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

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

Соотношение этих понятий иллюстрируется на рис. 4.5.

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

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

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

Внешние ключи реализуют связи между таблицами БД.

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

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

Каждая реляционная таблица обладает следующими свойствами:

- имеет имя, которое отличается от имен всех других таблиц;

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

- все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

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

Читайте также: