Реляционная база данных ( RDB [ 1] ) — это база данных , основанная на реляционной модели данных, предложенной Э. Ф. Коддом в 1970 году. [2] Система управления базами данных , используемая для поддержки реляционных баз данных, — это система управления реляционными базами данных ( RDBMS ). Многие системы реляционных баз данных оснащены возможностью использования SQL (языка структурированных запросов) для запросов и обновления базы данных. [3]
Концепция реляционной базы данных была определена Э. Ф. Коддом в IBM в 1970 году. Кодд ввел термин «реляционный» в своей исследовательской работе «Реляционная модель данных для больших общих банков данных». [2] В этой и более поздних работах он определил, что он имел в виду под отношением . Одно известное определение того, что представляет собой система реляционной базы данных, состоит из 12 правил Кодда . Однако ни одна коммерческая реализация реляционной модели не соответствует всем правилам Кодда, [4] поэтому этот термин постепенно стал описывать более широкий класс систем баз данных, которые как минимум:
В 1974 году IBM начала разработку System R , исследовательского проекта по разработке прототипа СУРБД. [5] [6] Первой системой, проданной как СУРБД, была Multics Relational Data Store (июнь 1976 года). [ требуется ссылка ] Oracle была выпущена в 1979 году компанией Relational Software, ныне Oracle Corporation . [7] Затем последовали Ingres и IBM BS12 . Другими примерами СУРБД являются IBM Db2 , SAP Sybase ASE и Informix . В 1984 году началась разработка первой СУРБД для Macintosh под кодовым названием Silver Surfer, которая была выпущена в 1987 году как 4th Dimension и сегодня известна как 4D. [8]
Первыми системами, которые относительно точно реализовали реляционную модель, были:
Наиболее распространенное определение СУРБД — это продукт, который представляет представление данных как набор строк и столбцов, даже если он не основан строго на реляционной теории . Согласно этому определению, продукты СУРБД обычно реализуют некоторые, но не все 12 правил Кодда.
Вторая школа мысли утверждает, что если база данных не реализует все правила Кодда (или современное понимание реляционной модели, как выражено Кристофером Дж. Дейтом , Хью Дарвеном и другими), то она не является реляционной. Эта точка зрения, разделяемая многими теоретиками и другими строгими приверженцами принципов Кодда, дисквалифицировала бы большинство СУБД как нереляционные. Для пояснения они часто называют некоторые СУБД истинно реляционными системами управления базами данных (TRDBMS), называя другие псевдореляционными системами управления базами данных (PRDBMS). [ необходима цитата ]
По состоянию на 2009 год большинство коммерческих реляционных СУБД используют SQL в качестве языка запросов . [13]
Были предложены и реализованы альтернативные языки запросов, в частности реализация Ingres QUEL до 1996 года .
Реляционная модель организует данные в одну или несколько таблиц (или «отношений») столбцов и строк с уникальным ключом, идентифицирующим каждую строку. Строки также называются записями или кортежами . [14] Столбцы также называются атрибутами. Как правило, каждая таблица/отношение представляет один «тип сущности» (например, клиент или продукт). Строки представляют экземпляры этого типа сущности (например, «Ли» или «стул»), а столбцы представляют значения, приписываемые этому экземпляру (например, адрес или цена).
Например, каждая строка таблицы классов соответствует классу, а класс соответствует нескольким ученикам, поэтому связь между таблицей классов и таблицей учеников — «один ко многим» [15]
Каждая строка в таблице имеет свой собственный уникальный ключ. Строки в таблице могут быть связаны со строками в других таблицах путем добавления столбца для уникального ключа связанной строки (такие столбцы известны как внешние ключи ). Кодд показал, что взаимосвязи данных произвольной сложности могут быть представлены простым набором концепций. [2]
Часть этой обработки включает в себя возможность последовательно выбирать или изменять одну и только одну строку в таблице. Поэтому большинство физических реализаций имеют уникальный первичный ключ (PK) для каждой строки в таблице. Когда новая строка записывается в таблицу, генерируется новое уникальное значение для первичного ключа; это ключ, который система использует в первую очередь для доступа к таблице. Производительность системы оптимизирована для PK. Другие, более естественные ключи также могут быть идентифицированы и определены как альтернативные ключи (AK). Часто для формирования AK требуется несколько столбцов (это одна из причин, по которой один целочисленный столбец обычно делается PK). Как PK, так и AK имеют возможность уникально идентифицировать строку в таблице. Дополнительная технология может применяться для обеспечения уникального идентификатора по всему миру, глобально уникального идентификатора , когда существуют более широкие системные требования.
Первичные ключи в базе данных используются для определения связей между таблицами. Когда PK мигрирует в другую таблицу, он становится внешним ключом в другой таблице. Когда каждая ячейка может содержать только одно значение, а PK мигрирует в обычную таблицу сущностей, этот шаблон проектирования может представлять либо связь «один к одному» , либо «один ко многим» . Большинство проектов реляционных баз данных разрешают связи «многие ко многим» путем создания дополнительной таблицы, содержащей PK из обеих других таблиц сущностей — связь становится сущностью; затем таблица разрешения именуется соответствующим образом, и два FK объединяются для формирования PK. Миграция PK в другие таблицы является второй основной причиной, по которой системно назначенные целые числа обычно используются в качестве PK; обычно нет ни эффективности, ни ясности при миграции множества других типов столбцов.
Отношения — это логическая связь между различными таблицами (сущностями), устанавливаемая на основе взаимодействия между этими таблицами. Эти отношения можно смоделировать как модель сущность-связь .
Для того чтобы система управления базами данных (СУБД) работала эффективно и точно, она должна использовать транзакции ACID . [16] [17] [18]
Часть программирования в СУРБД выполняется с использованием хранимых процедур (SP). Часто процедуры могут использоваться для значительного сокращения объема информации, передаваемой внутри и за пределы системы. Для повышения безопасности дизайн системы может предоставлять доступ только к хранимым процедурам, а не напрямую к таблицам. Фундаментальные хранимые процедуры содержат логику, необходимую для вставки новых и обновления существующих данных. Более сложные процедуры могут быть написаны для реализации дополнительных правил и логики, связанных с обработкой или выбором данных.
Реляционная база данных была впервые определена в июне 1970 года Эдгаром Коддом из исследовательской лаборатории IBM в Сан-Хосе . [2] Взгляд Кодда на то, что можно квалифицировать как СУРБД, обобщен в 12 правилах Кодда . Реляционная база данных стала преобладающим типом баз данных. Другие модели, помимо реляционной, включают иерархическую модель базы данных и сетевую модель .
В таблице ниже приведены некоторые наиболее важные термины реляционных баз данных и соответствующие им термины SQL :
В реляционной базе данных отношение — это набор кортежей , имеющих одинаковые атрибуты . Кортеж обычно представляет объект и информацию об этом объекте. Объекты обычно являются физическими объектами или концепциями. Отношение обычно описывается как таблица , которая организована в строки и столбцы . Все данные, на которые ссылается атрибут, находятся в одном домене и соответствуют одним и тем же ограничениям.
Реляционная модель определяет, что кортежи отношения не имеют определенного порядка и что кортежи, в свою очередь, не накладывают никакого порядка на атрибуты. Приложения получают доступ к данным, указывая запросы, которые используют такие операции, как select для идентификации кортежей, project для идентификации атрибутов и join для объединения отношений. Отношения могут быть изменены с помощью операторов insert , delete и update . Новые кортежи могут предоставлять явные значения или быть выведенными из запроса. Аналогично запросы идентифицируют кортежи для обновления или удаления.
Кортежи по определению уникальны. Если кортеж содержит кандидат или первичный ключ, то он, очевидно, уникален; однако, первичный ключ не обязательно должен быть определен для строки или записи, чтобы быть кортежем. Определение кортежа требует, чтобы он был уникальным, но не требует определения первичного ключа. Поскольку кортеж уникален, его атрибуты по определению составляют суперключ .
Все данные хранятся и доступны через отношения . Отношения, которые хранят данные, называются «базовыми отношениями», а в реализациях называются «таблицами». Другие отношения не хранят данные, а вычисляются путем применения реляционных операций к другим отношениям. Эти отношения иногда называют «производными отношениями». В реализациях они называются « представлениями » или «запросами». Производные отношения удобны тем, что они действуют как единое отношение, хотя они могут захватывать информацию из нескольких отношений. Кроме того, производные отношения можно использовать в качестве уровня абстракции .
Домен описывает набор возможных значений для данного атрибута и может считаться ограничением на значение атрибута. Математически присоединение домена к атрибуту означает, что любое значение для атрибута должно быть элементом указанного набора. Например, строка символов "ABC" не находится в целочисленном домене, но целочисленное значение 123 находится. Другой пример домена описывает возможные значения для поля "CoinFace" как ("Heads","Tails"). Таким образом, поле "CoinFace" не будет принимать входные значения типа (0,1) или (H,T).
Ограничения часто используются для того, чтобы сделать возможным дальнейшее ограничение домена атрибута. Например, ограничение может ограничить заданный целочисленный атрибут значениями от 1 до 10. Ограничения предоставляют один из методов реализации бизнес-правил в базе данных и поддерживают последующее использование данных на уровне приложения. SQL реализует функциональность ограничений в форме проверочных ограничений . Ограничения ограничивают данные, которые могут храниться в отношениях . Они обычно определяются с помощью выражений, которые приводят к логическому значению, указывающему, удовлетворяют ли данные ограничению. Ограничения могут применяться к отдельным атрибутам, к кортежу (ограничивая комбинации атрибутов) или ко всему отношению. Поскольку каждый атрибут имеет связанный домен, существуют ограничения ( ограничения домена ). Два основных правила для реляционной модели известны как целостность сущностей и ссылочная целостность .
Каждое отношение /таблица имеет первичный ключ, что является следствием того, что отношение является множеством . [ 19] Первичный ключ однозначно определяет кортеж в таблице. Хотя естественные атрибуты (атрибуты, используемые для описания вводимых данных) иногда являются хорошими первичными ключами, вместо них часто используются суррогатные ключи . Суррогатный ключ — это искусственный атрибут, назначенный объекту, который однозначно идентифицирует его (например, в таблице информации о студентах в школе им всем может быть назначен идентификатор студента, чтобы различать их). Суррогатный ключ не имеет внутреннего (врожденного) значения, но скорее полезен благодаря своей способности однозначно идентифицировать кортеж. Другим распространенным явлением, особенно в отношении мощности N:M, является составной ключ . Составной ключ — это ключ, состоящий из двух или более атрибутов в таблице, которые (вместе) однозначно идентифицируют запись. [20]
Внешний ключ относится к полю в реляционной таблице, которое соответствует столбцу первичного ключа другой таблицы. Он связывает два ключа. Внешние ключи не обязательно должны иметь уникальные значения в ссылочном отношении. Внешний ключ может использоваться для перекрестных ссылок на таблицы, и он эффективно использует значения атрибутов в ссылочном отношении для ограничения домена одного или нескольких атрибутов в ссылочном отношении. Концепция формально описывается следующим образом: «Для всех кортежей в ссылочном отношении, спроецированных на ссылочные атрибуты, должен существовать кортеж в ссылочном отношении, спроецированный на те же атрибуты, так что значения в каждом из ссылочных атрибутов соответствуют соответствующим значениям в ссылочных атрибутах».
Хранимая процедура — это исполняемый код, связанный с базой данных и обычно хранящийся в ней. Хранимая процедура обычно собирает и настраивает общие операции, такие как вставка кортежа в отношение , сбор статистической информации о шаблонах использования или инкапсуляция сложной бизнес-логики и вычислений. Часто они используются в качестве интерфейса прикладного программирования (API) для безопасности или простоты. Реализации хранимых процедур в SQL RDBMS часто позволяют разработчикам использовать преимущества процедурных расширений (часто специфичных для поставщика) стандартного декларативного синтаксиса SQL. Хранимая процедура не является частью модели реляционной базы данных, но все коммерческие реализации включают их.
Индекс — это один из способов предоставления более быстрого доступа к данным. Индексы могут быть созданы для любой комбинации атрибутов в отношении . Запросы, которые фильтруют с использованием этих атрибутов, могут находить соответствующие кортежи напрямую с помощью индекса (аналогично поиску в хэш-таблице ), без необходимости проверять каждый кортеж по очереди. Это аналогично использованию индекса книги для прямого перехода на страницу, на которой находится нужная вам информация, так что вам не нужно читать всю книгу, чтобы найти то, что вы ищете. Реляционные базы данных обычно предоставляют несколько методов индексирования, каждый из которых оптимален для некоторой комбинации распределения данных, размера отношения и типичной схемы доступа. Индексы обычно реализуются с помощью деревьев B+ , R-деревьев и битовых карт . Индексы обычно не считаются частью базы данных, поскольку они считаются деталью реализации, хотя индексы обычно поддерживаются той же группой, которая поддерживает другие части базы данных. Использование эффективных индексов как для первичных, так и для внешних ключей может значительно повысить производительность запросов. Это связано с тем, что индексы B-дерева приводят к времени выполнения запроса, пропорциональному log(n), где n — количество строк в таблице, а индексы хэша приводят к постоянному времени выполнения запросов (без зависимости от размера, пока соответствующая часть индекса помещается в памяти).
Запросы, сделанные к реляционной базе данных, и производные relvars в базе данных выражаются в реляционном исчислении или реляционной алгебре . В своей оригинальной реляционной алгебре Кодд ввел восемь реляционных операторов в двух группах по четыре оператора в каждой. Первые четыре оператора были основаны на традиционных математических операциях над множествами :
Остальные операторы, предложенные Коддом, включают специальные операции, характерные для реляционных баз данных:
После того, как Кодд представил первоначальные восемь операторов, были введены или предложены другие операторы, включая, среди прочего, реляционные операторы сравнения и расширения, которые предлагают поддержку вложенных и иерархических данных.
Нормализация была впервые предложена Коддом как неотъемлемая часть реляционной модели. Она охватывает набор процедур, предназначенных для устранения непростых доменов (неатомарных значений) и избыточности (дублирования) данных, что в свою очередь предотвращает аномалии манипулирования данными и потерю целостности данных. Наиболее распространенные формы нормализации, применяемые к базам данных, называются нормальными формами .
Коннолли и Бегг определяют систему управления базами данных (СУБД) как «программную систему, которая позволяет пользователям определять, создавать, поддерживать и контролировать доступ к базе данных». [21] СУРБД — это расширение этого аббревиатуры, которое иногда используется, когда базовая база данных является реляционной.
Альтернативное определение для системы управления реляционной базой данных — это система управления базами данных (СУБД), основанная на реляционной модели . Большинство баз данных, широко используемых сегодня, основаны на этой модели. [22]
СУРБД были распространенным вариантом для хранения информации в базах данных, используемых для финансовых записей, производственной и логистической информации, данных о персонале и других приложений с 1980-х годов. Реляционные базы данных часто заменяли устаревшие иерархические базы данных и сетевые базы данных , поскольку СУРБД были проще в реализации и администрировании. Тем не менее, реляционные хранимые данные получили постоянные, безуспешные вызовы со стороны систем управления объектными базами данных в 1980-х и 1990-х годах (которые были введены в попытке решить так называемое несоответствие объектно-реляционного импеданса между реляционными базами данных и объектно-ориентированными прикладными программами), а также со стороны систем управления базами данных XML в 1990-х годах. [23] Однако из-за расширения технологий, таких как горизонтальное масштабирование компьютерных кластеров , базы данных NoSQL в последнее время стали популярными в качестве альтернативы базам данных СУРБД. [24]
Распределенная реляционная архитектура баз данных (DRDA) была разработана рабочей группой IBM в период с 1988 по 1994 год. DRDA позволяет сетевым реляционным базам данных взаимодействовать для выполнения SQL-запросов. [25] [26] Сообщения, протоколы и структурные компоненты DRDA определяются распределенной архитектурой управления данными .
По данным DB-Engines , в январе 2023 года самыми популярными системами на сайте db-engines.com были: [27]
По данным исследовательской компании Gartner , в 2011 году пятью ведущими поставщиками проприетарного программного обеспечения для реляционных баз данных по объему выручки были Oracle (48,8%), IBM (20,2%), Microsoft (17,0%), SAP , включая Sybase (4,6%) и Teradata (3,7%). [28]
Продукт назывался SQL/DS (Structured Query Language/Data Store) и работал в среде операционной системы DOS/VSE.
{{cite book}}: CS1 maint: дата и год ( ссылка )