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

редактировать
Цифровая база данных, организация которой основана на реляционной модели данных

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

Содержание

  • 1 История
  • 2 Реляционная модель
  • 3 ключа
    • 3.1 Отношения
  • 4 Транзакции
  • 5 Хранимые процедуры
  • 6 Терминология
  • 7 Отношения или таблицы
  • 8 Базовые и производные отношения
    • 8.1 Домен
  • 9 Ограничения
    • 9.1 Первичные ключ
    • 9.2 Внешний ключ
    • 9.3 Хранимые процедуры
    • 9.4 Индекс
  • 10 Реляционные операции
  • 11 Нормализация
  • 12 РСУБД
  • 13 Распределенные реляционные базы данных
  • 14 Доля рынка
  • 15 См. Также
  • 16 Ссылки

История

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

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

В 1974 году IBM начала разработку System R, исследовательского проекта по разработке прототипа СУБД. Первой системой, продаваемой как РСУБД, была Multics Relational Data Store (июнь 1976 г.). Oracle была выпущена в 1979 г. компанией Relational Software, теперь Oracle Corporation. <78 За ними последовали Ingres и IBM BS12. Другие примеры СУБД включают DB2, SAP Sybase ASE и Informix. В 1984 году началась разработка первой СУБД для Macintosh под кодовым названием Silver Surfer, позже она была выпущена в 1987 году как 4th Dimension и известна сегодня как 4D.

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

  • Мичиганский университет - Микро СУБД (1969)
  • Массачусетский технологический институт (1971)
  • IBM UK Scientific Центр в Питерли - IS1 (1970–72) и его преемник, PRTV (1973–79)

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

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

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

. Были предложены и реализованы альтернативные языки запросов, в частности, реализация <114 до 1996 года.>Ingres QUEL.

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

Эта модель организует данные в одну или несколько таблиц (или «отношений») из столбцов и строк <157.>, с уникальным ключом, идентифицирующим каждую строку. Строки также называются записями или кортежами. Столбцы также называются атрибутами. Как правило, каждая таблица / отношение представляет один «тип объекта» (например, покупателя или продукта). Строки представляют экземпляры этого типа объекта (например, «Ли» или «стул»), а столбцы - значения, приписываемые этому экземпляру (например, адрес или цена).

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

Ключи

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

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

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

Отношения

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

Транзакции

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

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

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

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

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

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

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

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

Отношения или таблицы

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

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

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

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

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

Домен

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

Ограничения

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

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

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

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

Внешний ключ

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

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

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

Индекс

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

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

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

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

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

  • Операция выбора или ограничения извлекает кортежи из отношение, ограничивая результаты только теми, которые соответствуют определенному критерию, то есть подмножеством с точки зрения теории множеств. Эквивалентом выбора в SQL является оператор запроса SELECT с предложением WHERE.
  • Операция проекции извлекает только указанные атрибуты из кортежа. или набор кортежей.
  • Операция соединения, определенная для реляционных баз данных, часто называется естественным соединением. В этом типе соединения два отношения связаны своими общими атрибутами. MySQL аппроксимация естественного соединения - это оператор Inner join. В SQL INNER JOIN предотвращает появление декартова произведения, когда в запросе есть две таблицы. Для каждой таблицы, добавленной в SQL-запрос, добавляется одно дополнительное ВНУТРЕННЕЕ СОЕДИНЕНИЕ, чтобы предотвратить декартово произведение. Таким образом, для N таблиц в SQL-запросе должно быть N − 1 ВНУТРЕННИХ СОЕДИНЕНИЙ, чтобы предотвратить декартово произведение.
  • Операция реляционного деления является немного более сложной операцией и по существу включает в себя использование кортежи одного отношения (делимого) для разделения второго отношения (делителя). Оператор реляционного деления фактически противоположен оператору декартового произведения (отсюда и название).

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

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

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

РСУБД

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

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

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

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

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

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

Доля рынка

Согласно DB-Engines, в сентябре 2020 г. широко используемые системы были (ранжированы в следующем порядке):

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

См. также

В Викиучебнике есть книга по теме: Язык структурированных запросов

Ссылки

Последняя правка сделана 2021-06-03 12:16:25
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте