Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

История [ править ]

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

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

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

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

  • Мичиганский университет - Микро СУБД (1969) [ необходима ссылка ]
  • Массачусетский технологический институт (1971) [9]
  • Британский научный центр IBM в Питерли - IS1 (1970–72) и его преемник PRTV (1973–79)

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

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

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

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

Реляционная модель [ править ]

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

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

Ключи [ править ]

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

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

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

Отношения [ править ]

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

Транзакции [ править ]

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

Хранимые процедуры [ править ]

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

Терминология [ править ]

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

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

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

Отношения или таблицы [ править ]

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

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

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

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

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

Домен [ править ]

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

Ограничения [ править ]

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

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

Первичный ключ [ править ]

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

Внешний ключ [ править ]

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

Хранимые процедуры [ править ]

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

Индекс [ править ]

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

Реляционные операции [ править ]

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

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

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

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

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

Нормализация [ править ]

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

СУБД [ править ]

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

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

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

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

Распределенные реляционные базы данных [ править ]

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

Доля рынка [ править ]

По данным DB-Engines , в январе 2021 года наиболее широко используемыми системами были:

  1. Oracle
  2. MySQL ( бесплатное программное обеспечение )
  3. Microsoft SQL Server
  4. PostgreSQL (с открытым исходным кодом, продолжение разработки после INGRES)
  5. IBM DB2
  6. SQLite (бесплатное программное обеспечение)
  7. Microsoft Access
  8. MariaDB (бесплатное программное обеспечение)
  9. Терадата
  10. База данных Microsoft Azure SQL
  11. Apache Hive (бесплатное программное обеспечение; специализировано для хранилищ данных ). [23]

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

См. Также [ править ]

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

Ссылки [ править ]

  1. ^ a b Кодд, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации ACM . 13 (6): 377–387. DOI : 10.1145 / 362384.362685 .
  2. ^ Эмблер, Скотт. «Реляционные базы данных 101: взгляд на картину целиком» .[ нужен лучший источник ]
  3. ^ «Реляционная модель данных для больших общих банков данных» (PDF) .
  4. ^ Дата, Крис. База данных в глубине: теория отношений для практиков . О'Рейли. ISBN 0-596-10012-4.
  5. ^ Финансирование революции: государственная поддержка компьютерных исследований . Национальная академия прессы. 8 января 1999 г. ISBN 0309062780.
  6. ^ Sumathi, S .; Эсаккираджан, С. (13 февраля 2008 г.). Основы систем управления реляционными базами данных . Springer. ISBN 3540483977. Продукт назывался SQL / DS (язык структурированных запросов / хранилище данных) и работал в среде операционной системы DOS / VSE.
  7. ^ "Oracle Timeline" (PDF) . Журнал "Профит" . Oracle. 12 (2): 26. Май 2007 . Проверено 16 мая 2013 .
  8. ^ «Новая программа для баз данных выводит Macintosh в высшую лигу» . Tribunedigital-chicagotribune . Проверено 17 марта 2016 .
  9. ^ SIGFIDET '74 Труды семинара 1974 ACM SIGFIDET (теперь SIGMOD) по описанию данных, доступу и контролю
  10. ^ Рамакришнан, Рагху; Донжеркович, Донко; Ранганатан, Арвинд; Бейер, Кевин С .; Кришнапрасад, Муралидхар (1998). «SRQL: язык сортированных реляционных запросов» (PDF) . e Труды SSDBM .
  11. ^ «Обзор реляционной базы данных» . oracle.com .
  12. ^ "Универсальная модель отношения для вложенной базы данных" , Модель вложенной универсальной базы данных отношений , Берлин, Гейдельберг: Springer Berlin Heidelberg, стр. 109–135, 1992, ISBN 978-3-540-55493-6, получено 01.11.2020
  13. ^ "Грей будет удостоен премии AM Тьюринга этой весной" . Microsoft PressPass. 1998-11-23. Архивировано 6 февраля 2009 года . Проверено 16 января 2009 .
  14. ^ Грей, Джим (сентябрь 1981). «Концепция сделки: достоинства и ограничения» (PDF) . Труды 7-й Международной конференции по очень большим базам данных . Купертино, Калифорния: тандемные компьютеры . С. 144–154 . Проверено 9 ноября 2006 .
  15. ^ Грей, Джим, и Рейтер, Андреас, Распределенная обработка транзакций: концепции и методы . Морган Кауфманн , 1993. ISBN 1-55860-190-2 . 
  16. ^ Визе, Лена (2015). Расширенное управление данными: для SQL, noSQL, облачных и распределенных баз данных . Walter de Gruyter GmbH & Co KG. п. 192.
  17. ^ Дата (1984) , стр. 268.
  18. ^ Коннолли, Томас М .; Бегг, Кэролайн Э. (2014). Системы баз данных - Практический подход к реализации и управлению дизайном (6-е изд.). Пирсон. п. 64. ISBN 978-1292061184.
  19. ^ Пратт, Филип Дж .; Наконец, Мэри З. (2014-09-08). Концепции управления базами данных (8-е изд.). Курсовая технология. п. 29. ISBN 9781285427102.
  20. ^ «Базы данных NoSQL съедают рынок реляционных баз данных» . Проверено 14 марта 2018 .
  21. ^ Reinsch, R. (1988). «Распределенная база данных для SAA». IBM Systems Journal . 27 (3): 362–389. DOI : 10.1147 / sj.273.0362 .
  22. ^ Справочник по архитектуре распределенной реляционной базы данных . IBM Corp. SC26-4651-0. 1990 г.
  23. ^ «Рейтинг реляционных СУБД DB-Engines» . Проверено 8 января 2021 .
  24. ^ «Oracle - явный лидер на рынке СУБД с оборотом $ 24 млрд» . 2012-04-12 . Проверено 1 марта 2013 .
  • Дата, CJ (1984). Руководство по DB2 (под ред. Студента). Эддисон-Уэсли . ISBN 0201113171. OCLC  256383726 . ПР  2838595М .