Реляционная база данных

Реляционная база данных-это цифровая база данных, основанная на реляционной модели данных, предложенной Э. Ф. Коддом в 1970 году. Программная система, используемая для обслуживания реляционных баз данных, представляет собой систему управления реляционными базами данных (СУБД). Многие реляционные системы баз данных имеют возможность использовать стандартный SQL (Structured Query Language) для запроса и обслуживания базы данных.

История

Термин "реляционная база данных" был изобретен Э. Ф. Коддом в IBM в 1970 году. Кодд ввел этот термин в свою исследовательскую работу "реляционная модель данных для больших общих банков данных".[3] В этой статье и последующих работах он определил, что он имел в виду под "реляционными". Одно из хорошо известных определений того, что представляет собой реляционная система баз данных, состоит из 12 правил Codd . Однако ни одна коммерческая реализация реляционной модели не соответствует всем правилам Codd [4], поэтому этот термин постепенно стал описывать более широкий класс систем баз данных, которые как минимум:

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

В 1974 году IBM начала разработку System R, исследовательского проекта по разработке прототипа СУБД.[5][6] Однако первой коммерчески доступной СУБД был Oracle, выпущенный в 1979 году компанией Relational Software, ныне Oracle Corporation .[7] Другие примеры СУБД включают DB2, SAP Sybase ASE и Informix . В 1984 году начали разрабатываться первые СУБД для Macintosh, получившие кодовое название Silver Surfer, позже они были выпущены в 1987 году как 4th Dimension и известны сегодня как 4D. [8]

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

   Мичиганский университет-микро СУБД (1969)
   Массачусетский Технологический институт (1971) [9]
   IBM UK Scientific Centre at Peterlee-IS1 (1970-72) и его преемник PRTV (1973-79)

Первой системой, проданной в качестве СУБД, было реляционное хранилище данных Multics (1978). Затем последовали Энгр и IBM BS12.

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

Вторая школа мышления утверждает, что если база данных не реализует все правила Codd (или текущее понимание реляционной модели , как выражено Кристофером Дж.Дейтом, Хью Дарвеном и другими), она не является реляционной. Эта точка зрения, разделяемая многими теоретиками и другими строгими приверженцами принципов Codd, дисквалифицировала бы большинство СУБД как не реляционные. Для уточнения они часто ссылаются на некоторые РСУБД как на истинно-реляционные системы управления базами данных (TRDBMS), называя другие псевдо-реляционные системы управления базами данных (PRDBMS).

По состоянию на 2009 год большинство коммерческих реляционных СУБД используют SQL в качестве языка запросов .[10]

Были предложены и реализованы альтернативные языки запросов, в частности до 1996 года была реализована программа Ingres QUEL . Реляционная модель Основная статья: реляционная модель

Эта модель организует данные в одну или несколько таблиц (или" отношений") столбцов и строк , с уникальным ключом, идентифицирующим каждую строку. Строки также называются записями или кортежами .[11] столбцы также называются атрибутами. Как правило, каждая таблица/отношение представляет один "тип сущности" (например, клиент или продукт). Строки представляют экземпляры этого типа сущности (например, "Lee" или "chair"), а столбцы-значения, приписываемые этому экземпляру (например, адрес или цена). Ключи

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

Часть этой обработки включает в себя последовательную возможность выбора или изменения одной и только одной строки в таблице. Поэтому большинство физических реализаций имеют уникальный первичный ключ (PK) для каждой строки в таблице. Когда новая строка записывается в таблицу, создается новое уникальное значение для первичного ключа; это ключ, который система использует главным образом для доступа к таблице. Производительность системы оптимизирована для PKs. Другие, более естественные ключи также могут быть идентифицированы и определены как альтернативные ключи (АЛЯСКА.) Часто для формирования AK требуется несколько столбцов (это одна из причин, по которой один целочисленный столбец обычно становится PK). Как PKs, так и AKs имеют возможность однозначно идентифицировать строку в таблице. Дополнительная технология может быть применена для обеспечения уникального идентификатора по всему миру, глобального уникального идентификатора , когда существуют более широкие системные требования.

Первичные ключи в базе данных используются для определения связей между таблицами. Когда PK мигрирует в другую таблицу, он становится внешним ключом в другой таблице. Когда каждая ячейка может содержать только одно значение и PK мигрирует в обычную таблицу сущностей, этот шаблон проектирования может представлять либо отношение "один к одному", либо отношение "один ко многим". Большинство конструкций реляционных баз данных решают многие ко многим отношения путем создания дополнительной таблицы, содержащей PKs из обеих других таблиц сущностей-отношение становится сущностью; таблица разрешения затем называется соответствующим образом, и два FKs объединяются для формирования PK. Миграция PKs в другие таблицы является второй основной причиной, по которой назначенные системой целые числа обычно используются в качестве PKs; обычно нет ни эффективности, ни ясности в переносе группы других типов столбцов.

Отношения

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

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

Хранимые процедуры

Большинство [сомнительно – обсуждение ] программирования в рамках СУБД выполняется с использованием хранимых процедур (SPs). Часто процедуры могут быть использованы для значительного сокращения объема информации, передаваемой внутри и вне системы. Для повышения уровня безопасности конструкция системы может предоставлять доступ только к хранимым процедурам, а не непосредственно к таблицам. Основные хранимые процедуры содержат логику, необходимую для вставки новых и обновления существующих данных. Более сложные процедуры могут быть написаны для реализации дополнительных правил и логики, связанных с обработкой или выбором данных.

Терминология реляционных баз данных.

Терминология

Реляционная база данных была впервые определена в июне 1970 года Эдгаром Коддом из Исследовательской лаборатории IBM в Сан-Хосе .[1] представление Codd о том, что квалифицируется как СУБД, кратко изложено в 12 правилах Codd . Реляционная база данных стала преобладающим типом базы данных. К другим моделям, помимо реляционной модели, относятся иерархическая модель базы данных и сетевая модель .

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

Термин SQL	Термин реляционной базы данных	Описание
Ряд	Кортеж или запись	Набор данных, представляющий один элемент
Колонна	Атрибут или поле	Помеченный элемент кортежа, например "адрес" или " дата рождения"
Таблица	Отношение или основание relvar	Набор кортежей с одинаковыми атрибутами; набор столбцов и строк
Просмотр или результирующий набор	Производный релвар	Любой набор кортежей; отчет о данных из СУБД в ответ на запрос

Связи или таблицы

Основные статьи: Связь (база данных) и таблица (база данных)

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

Реляционная модель указывает, что кортежи отношения не имеют определенного порядка и что кортежи, в свою очередь, не накладывают никакого порядка на атрибуты. Приложения получают доступ к данным путем задания запросов, которые используют такие операции, как select для идентификации кортежей, project для идентификации атрибутов и join для объединения связей. Связи можно изменить с помощью операторов insert , delete и update. Новые кортежи могут предоставлять явные значения или быть получены из запроса. Аналогичным образом, запросы определяют кортежи для обновления или удаления.

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

Базовые и производные отношения

Основные статьи: Relvar and View (база данных)

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

Домен

Основная статья: Домен данных

Домен описывает набор возможных значений для данного атрибута и может рассматриваться как ограничение на значение атрибута. Математически присоединение домена к атрибуту означает, что любое значение атрибута должно быть элементом указанного набора. Символьная строка "ABC", например, не находится в целочисленной области, но целочисленное значение 123 есть. Другой пример домена описывает возможные значения для поля "CoinFace" как ("Heads", "Tails"). Таким образом,поле "CoinFace" не будет принимать входные значения, такие как (0,1) или (H, T).

Ограничения

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

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

Основная статья: Уникальный ключ

Первичный ключ однозначно определяет кортеж внутри таблицы. Чтобы атрибут был хорошим первичным ключом,он не должен повторяться. В то время как естественные атрибуты (атрибуты, используемые для описания вводимых данных) иногда являются хорошими первичными ключами, суррогатными ключами часто используются вместо этого. Суррогатный ключ-это искусственный атрибут, присвоенный объекту, который однозначно идентифицирует его (например, в таблице информации о студентах в школе им всем может быть присвоен идентификатор студента, чтобы дифференцировать их). Суррогатный ключ не имеет никакого внутреннего (присущего) значения, а скорее полезен благодаря своей способности однозначно идентифицировать кортеж. Еще одно распространенное явление, особенно в отношении N: M кардинальность является составным ключом. Составной ключ-это ключ, состоящий из двух или более атрибутов внутри таблицы, которые (вместе) однозначно идентифицируют запись. (Например, в базе данных, связанной с учащимися, преподавателями и классами. Классы могут быть однозначно идентифицированы с помощью составного ключа их номера комнаты и временного интервала, так как ни один другой класс не может иметь точно такую же комбинацию атрибутов. На самом деле , использование составного ключа, такого как этот, может быть формой проверки данных, хотя и слабой.

Внешний ключ

Основная статья: Внешний ключ

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

Хранимые процедуры

Основная статья: Хранимая процедура

Хранимая процедура-это исполняемый код, который связан с базой данных и обычно хранится в ней. Хранимые процедуры обычно собирают и настраивают общие операции , такие как вставка кортежа в связь, сбор статистических данных о шаблонах использования или инкапсуляция сложной бизнес-логики и вычислений. Часто они используются в качестве интерфейса прикладного программирования (API) для обеспечения безопасности или простоты. Реализация хранимых процедур на СУБД SQL часто позволяет разработчикам использовать преимущества процедурных расширений (часто зависящих от поставщика) для стандартного декларативного кода синтаксис SQL. Хранимые процедуры не являются частью модели реляционной базы данных, но все коммерческие реализации включают их.

Index

Основная статья: Индекс (база данных)

Индекс является одним из способов обеспечения более быстрого доступа к данным. Индексы могут быть созданы на любой комбинации атрибутов в отношении . Запросы, которые фильтруют с помощью этих атрибутов, могут находить совпадающие кортежи случайным образом, используя индекс, без необходимости проверять каждый кортеж по очереди. Это аналогично использованию индекса книги чтобы перейти непосредственно на страницу, на которой находится информация, которую вы ищете, так что вам не придется читать всю книгу, чтобы найти то, что вы ищете. Реляционные базы данных обычно предоставляют несколько методов индексирования, каждый из которых является оптимальным для некоторой комбинации распределения данных, размера отношения и типичного шаблона доступа. Индексы обычно реализуются через B+ деревья, R-деревья и растровые изображения. Индексы обычно не считаются частью базы данных, поскольку они считаются детализацией реализации, хотя индексы обычно поддерживаются той же группой, которая обслуживает другие части базы данных. Использование эффективных индексов как на первичном, так и на внешнем ключах может значительно повысить производительность запросов. Это связано с тем, что индексы B-дерева приводят к временам запросов, пропорциональным log(n), где n-число строк в таблице, а хэш-индексы приводят к постоянным временным запросам (без зависимости от размера, пока соответствующая часть индекса помещается в память).

Реляционные операции

Основная статья: реляционная алгебра

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

• Оператор union объединяет кортежи из двух отношений и удаляет все повторяющиеся кортежи из результата. Оператор реляционного объединения эквивалентен оператору SQL UNION.
• Оператор пересечения создает набор кортежей, которые являются общими для двух отношений. Пересечение реализовано в SQL в виде оператора INTERSECT.
• Разностный оператор действует на два отношения и производит множество кортежей из первого отношения, которые не существуют во втором отношении. Отличие реализовано в SQL в виде оператора EXCEPT или MINUS.
• Декартово произведение двух отношений является соединением, которое не ограничено никакими критериями, в результате чего каждый кортеж первого отношения сопоставляется с каждым кортежем второго отношения. Декартово произведение реализовано в SQL в виде оператора Cross join.

Остальные операторы, предложенные Codd, включают специальные операции, характерные для реляционных баз данных:

• Операция выбора или ограничения извлекает кортежи из отношения, ограничивая результаты только теми, которые удовлетворяют определенному критерию, т. е. подмножеству в терминах теории множеств. SQL-эквивалентом selection является инструкция SELECT query с предложением WHERE.
• Операция проецирования извлекает только указанные атрибуты из кортежа или набора кортежей.
• Операция соединения, определенная для реляционных баз данных, часто называется естественным соединением. В этом типе соединения два отношения связаны их общими атрибутами. Приближение MySQL естественного соединения является внутренним оператором соединения. В SQL внутреннее соединение предотвращает появление декартового продукта, когда в запросе есть две таблицы. Для каждой таблицы, добавленной в запрос SQL, добавляется одно дополнительное внутреннее соединение, чтобы предотвратить декартово произведение. Таким образом, для n таблиц в SQL−запросе должно быть N-1 внутренних соединений, чтобы предотвратить декартово произведение.
• Операция реляционного деления является несколько более сложной операцией и по существу включает в себя использование кортежей одного отношения (дивиденда) для разделения второго отношения (делителя). Оператор реляционного деления фактически является противоположностью оператору декартова произведения (отсюда и название).

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

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

Основная статья: Нормализация базы данных

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

СУБД

Смотрите также: База данных § Система управления базами данных

Общая структура реляционной базы данных.

Коннолли и Бегг определяют систему управления базами данных (СУБД) как "программную систему, которая позволяет пользователям определять, создавать, поддерживать и контролировать доступ к базе данных".[15] СУБД является расширением этой аббревиатуры, которая иногда используется, когда базовая база данных является реляционной.

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

С 1980-х годов РСУБД стали широко использоваться для хранения информации в базах данных, используемых для финансовой отчетности, производственной и логистической информации, кадровых данных и других прикладных программ. реляционные базы данных часто заменяют устаревшие иерархические базы данных и сетевые базы данных , поскольку РСУБД легче внедрять и администрировать. Тем не менее, в 1980-х и 1990-х годах реляционные базы данных продолжали сталкиваться с неуспешными вызовами со стороны систем управления базами данных объектов (которые были введены в попытке решить проблему так называемого несоответствия импеданса объектно-реляционных систем между реляционными базами данных и объектно-ориентированными прикладными программами), а также с помощью систем управления базами данных XML в 1990-х гг. Однако в связи с широким распространением технологий, таких как горизонтальное масштабирование компьютерных кластеров , базы данных NoSQL в последнее время стали популярными в качестве альтернативы базам данных СУБД.

Распределенные реляционные базы

Распределенная архитектура реляционных баз данных (DRDA) была разработана рабочей группой в составе IBM в период с 1988 по 1994 год. DRDA позволяет подключенным к сети реляционным базам данных сотрудничать для выполнения запросов SQL. Сообщения, протоколы и структурные компоненты DRDA определяются архитектурой распределенного управления данными .

Доля рынка

По данным DB-Engine, в июле 2019 года наиболее широко использовались системы Oracle, MySQL ( свободное программное обеспечение ), Microsoft SQL Server , PostgreSQL ( свободное программное обеспечение ), IBM DB2 , Microsoft Access , SQLite (свободное программное обеспечение) и MariaDB (свободное программное обеспечение).

По данным исследовательской компании Gartner, в 2011 году пятью ведущими поставщиками проприетарного программного обеспечения реляционных баз данных по выручке были Oracle (48,8%), IBM (20,2%), Microsoft (17,0%), SAP в том числе Sybase (4,6%) и Teradata (3,7%).

Смотрите также

• Язык SQL
• База данных объектов (OODBMS)
• Оперативная аналитическая обработка (OLAP) и ROLAP (реляционная оперативная аналитическая обработка)
• Хранилище данных
• Звездная схема
• Схема снежинки
• Список систем управления реляционными базами данных
• Сравнение систем управления реляционными базами данных