Введение
Цифровая база данных, организация которой основана на реляционной модели данных.
Реляционная база данных (RDB) — это база данных, построенная на реляционной модели данных, предложенной Э. Ф. Коддом в 1970 году.
Ключи
Каждая строка в таблице имеет свой уникальный ключ. Строки в таблице могут быть связаны со строками в других таблицах путем добавления столбца для уникального ключа связанной строки (такие столбцы известны как внешние ключи). Кодд показал, что отношения данных любой сложности могут быть представлены простым набором концепций.
Сохраненные процедуры
Часть программирования в СУБД выполняется с использованием хранимых процедур (SP). Часто процедуры могут использоваться для значительного уменьшения объема информации, передаваемой внутри и вне системы. Для повышения безопасности проектирование системы может предусматривать доступ только к хранимым процедурам, а не напрямую к таблицам. Базовые хранимые процедуры содержат логику, необходимую для добавления новых и обновления существующих данных. Более сложные процедуры могут быть написаны для реализации дополнительных правил и логики, связанных с обработкой или выбором данных.
Ссылки или таблицы
В реляционной базе данных, реляция представляет собой набор кортежей, имеющих одинаковые атрибуты. Кортеж обычно представляет объект и информацию об этом объекте. Объекты обычно являются физическими объектами или понятиями. Реляция обычно описывается как таблица, организованная в строки и столбцы. Все данные, на которые ссылается атрибут, принадлежат одному домену и соответствуют одним и тем же ограничениям. Реляционная модель определяет, что кортежи реляции не имеют определенного порядка, и сами кортежи не накладывают порядок на атрибуты. Приложения получают доступ к данным, задавая запросы, использующие операции, такие как выборка для идентификации кортежей, проекция для идентификации атрибутов и соединение для объединения реляций. Реляции могут быть изменены с помощью операторов вставки, удаления и обновления. Новые кортежи могут содержать явные значения или быть получены из запроса. Аналогично, запросы идентифицируют кортежи для обновления или удаления. Кортежи по определению уникальны. Если кортеж содержит кандидатный или первичный ключ, то он, очевидно, уникален; однако, для того чтобы строка или запись являлись кортежем, не обязательно должен быть определен первичный ключ. Определение кортежа требует его уникальности, но не требует определения первичного ключа. Поскольку кортеж уникален, его атрибуты по определению составляют суперключ.
Базовые и производные отношения
Все данные хранятся и к ним осуществляется доступ посредством отношений. Отношения, хранящие данные, называются "базовыми отношениями", а в реализациях – "таблицами". Другие отношения не хранят данные, а формируются путем применения реляционных операций к другим отношениям. Эти отношения иногда называют "производными отношениями". В реализациях они называются "представлениями" или "запросами". Производные отношения удобны тем, что функционируют как единое отношение, хотя могут извлекать информацию из нескольких отношений. Кроме того, производные отношения могут использоваться как уровень абстракции.
Домен
Домен описывает множество возможных значений для заданного атрибута и может рассматриваться как ограничение на значение этого атрибута. Математически, назначение домена атрибуту означает, что любое значение атрибута должно быть элементом указанного множества. Например, символьная строка "ABC" не входит в целочисленный домен, но целочисленное значение 123 – входит. Другой пример домена описывает возможные значения поля "CoinFace" как ("Heads", "Tails"). Следовательно, поле "CoinFace" не будет принимать входные значения, такие как (0,1) или (H,T).
Ограничения
Ограничения часто используются для дальнейшего сужения области допустимых значений атрибута. Например, ограничение может сузить диапазон допустимых значений целочисленного атрибута до значений от 1 до 10. Ограничения предоставляют один из способов реализации бизнес-правил в базе данных и поддерживают последующее использование данных на уровне приложения. В SQL функциональность ограничений реализуется в виде ограничений CHECK. Ограничения ограничивают данные, которые могут быть сохранены в таблицах (отношениях). Обычно они определяются с помощью выражений, возвращающих булево значение, указывающее, удовлетворяют ли данные условию ограничения. Ограничения могут применяться к отдельным атрибутам, к кортежам (ограничивающим комбинации атрибутов) или ко всей таблице (отношению). Поскольку каждый атрибут имеет связанный домен, существуют ограничения домена. Два основных правила реляционной модели известны как целостность сущностей и ссылочная целостность.
Первичный ключ
Каждое отношение/таблица имеет первичный ключ, что является следствием того, что отношение представляет собой множество. Первичный ключ однозначно определяет кортеж в таблице. Хотя естественные атрибуты (атрибуты, используемые для описания вводимых данных) иногда могут быть хорошими первичными ключами, чаще используются суррогатные ключи. Суррогатный ключ – это искусственный атрибут, присваиваемый объекту для его уникальной идентификации (например, в таблице информации о студентах школы каждому студенту может быть присвоен идентификационный номер для их различения). Суррогатный ключ не имеет внутренней (собственной) смысловой нагрузки, но полезен благодаря своей способности однозначно идентифицировать кортеж. Другим распространенным случаем, особенно при N:M кардинальности, является составной ключ. Составной ключ – это ключ, состоящий из двух или более атрибутов в таблице, которые вместе однозначно идентифицируют запись.
Иностранный ключ
Иностранный ключ – это поле в реляционной таблице, которое соответствует столбцу первичного ключа другой таблицы. Он устанавливает связь между этими двумя ключами. В ссылающей таблице значения иностранного ключа не обязаны быть уникальными. Иностранный ключ используется для установления связей между таблицами, эффективно используя значения атрибутов в ссылаемой таблице для ограничения допустимых значений одного или нескольких атрибутов в ссылающей таблице. Формальное определение концепции выглядит следующим образом: "Для всех кортежей в ссылающей таблице, спроецированных на ссылающие атрибуты, должен существовать кортеж в ссылаемой таблице, спроецированный на те же атрибуты, такой, чтобы значения в каждом из ссылающих атрибутов совпадали с соответствующими значениями в ссылаемых атрибутах."
Сохраненные процедуры
Сохраненная процедура — это исполняемый код, который связан с базой данных и обычно в ней хранится. Храненные процедуры обычно объединяют и адаптируют общие операции, такие как вставка кортежа в отношение, сбор статистической информации об образцах использования или инкапсуляция сложной бизнес-логики и вычислений. Часто они используются как интерфейс прикладного программирования (API) для повышения безопасности или упрощения разработки. Реализации хранимых процедур в SQL СУБД часто позволяют разработчикам использовать процедурные расширения (часто специфичные для конкретного поставщика) к стандартному декларативному синтаксису SQL. Хранимые процедуры не входят в модель реляционной базы данных, но все коммерческие реализации их поддерживают.
Индекс
Индекс – это один из способов обеспечения более быстрого доступа к данным. Индексы могут быть созданы на любой комбинации атрибутов отношения. Запросы, фильтрующие данные по этим атрибутам, могут находить соответствующие кортежи непосредственно через индекс (аналогично поиску в хеш-таблице), без необходимости последовательной проверки каждого кортежа. Это аналогично использованию указателя в книге для быстрого перехода к странице с нужной информацией, вместо чтения всей книги целиком. Реляционные базы данных обычно предоставляют несколько методов индексации, каждый из которых оптимален для определенной комбинации распределения данных, размера отношения и типичного шаблона доступа. Индексы обычно реализуются с помощью B+-деревьев, R-деревьев и битовых карт. Индексы обычно не рассматриваются как часть базы данных, поскольку считаются деталью реализации, хотя их обычно обслуживает та же группа, что и остальные компоненты базы данных. Использование эффективных индексов как для первичных, так и для внешних ключей может значительно повысить производительность запросов. Это связано с тем, что B-дерево индексы обеспечивают время запроса, пропорциональное log(n), где n – количество строк в таблице, а хеш-индексы обеспечивают запросы за постоянное время (не зависящее от размера, пока соответствующая часть индекса помещается в память).
Нормализация
Нормализация была впервые предложена Коддом как неотъемлемая часть реляционной модели. Она охватывает набор процедур, разработанных для устранения не простых доменов (неатомарных значений) и избыточности (дублирования) данных, что, в свою очередь, предотвращает аномалии при манипулировании данными и потерю целостности данных. Наиболее распространенные формы нормализации, применяемые к базам данных, называются нормальными формами.
СБУД
Коннолли и Бегг определяют систему управления базами данных (СУБД) как «программную систему, позволяющую пользователям определять, создавать, поддерживать и контролировать доступ к базе данных». RDBMS – это расшифровка этого аббревиатуры, которая иногда используется, когда лежащая в основе база данных является реляционной. Альтернативное определение реляционной системы управления базами данных – это система управления базами данных (СУБД), основанная на реляционной модели. Большинство баз данных, широко используемых сегодня, построены на этой модели. С 1980-х годов RDBMS стали распространенным выбором для хранения информации в базах данных, используемых для финансовых записей, производственной и логистической информации, данных о персонале и других приложений. Реляционные базы данных часто заменяли устаревшие иерархические и сетевые базы данных, поскольку RDBMS было проще внедрять и администрировать. Тем не менее, реляционные хранимые данные неоднократно подвергались безуспешным попыткам вытеснения со стороны систем управления объектными базами данных в 1980-х и 1990-х годах (которые были представлены в попытке решить так называемое несоответствие между реляционными базами данных и объектно-ориентированными приложениями), а также со стороны систем управления XML-базами данных в 1990-х годах. Однако, благодаря развитию технологий, таких как горизонтальное масштабирование компьютерных кластеров, базы данных NoSQL в последнее время стали популярной альтернативой базам данных RDBMS.
Распределенные реляционные базы данных
Архитектура распределенных реляционных баз данных (DRDA) была разработана рабочей группой в IBM в период с 1988 по 1994 год. DRDA позволяет реляционным базам данных, подключенным к сети, взаимодействовать для выполнения SQL-запросов. Сообщения, протоколы и структурные компоненты DRDA определены архитектурой распределенного управления данными.