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