✖


Jump to content

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

(Перенаправлено из реляционного запроса )

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

История

[ редактировать ]

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

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

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

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

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

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

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

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

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

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

[ редактировать ]
Основная статья: Реляционная модель

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

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

Ключи

[ редактировать ]

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

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

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

Отношения

[ редактировать ]

Отношения — это логические связи между различными таблицами (сущностями), устанавливаемые на основе взаимодействия этих таблиц. Эти отношения можно смоделировать как модель «сущность-связь» .

Транзакции

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]
Терминология реляционных баз данных

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

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

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

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

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

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

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

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

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

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

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

Домен

[ редактировать ]
Основная статья: Область данных

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

Ограничения

[ редактировать ]

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

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

[ редактировать ]
Основные статьи: Уникальный ключ и Первичный ключ.

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

Внешний ключ

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

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

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

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

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

Индекс

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

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

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

[ редактировать ]
Основная статья: Реляционная алгебра

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

  • Оператор объединения (υ) объединяет кортежи двух отношений и удаляет из результата все повторяющиеся кортежи. Оператор реляционного объединения эквивалентен оператору SQL UNION .
  • Оператор пересечения (∩) создает набор кортежей, которые являются общими для двух отношений. Пересечение реализовано в SQL в виде оператора INTERSECT .
  • Оператор разности множеств (-) действует на два отношения и создает набор кортежей из первого отношения, которых нет во втором отношении. Разница реализована в SQL в виде оператора EXCEPT или МИНУС.
  • Декартово произведение (X) двух отношений — это соединение, не ограниченное никакими критериями, в результате чего каждый кортеж первого отношения сопоставляется с каждым кортежем второго отношения. Декартово произведение реализовано в SQL как оператор перекрестного соединения .

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

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

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

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

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

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

СУБД

[ редактировать ]
Общая структура реляционной базы данных
См. Также: База данных § Система управления базами данных.

Коннолли и Бегг определяют систему управления базами данных (СУБД) как «программную систему, которая позволяет пользователям определять, создавать, поддерживать и контролировать доступ к базе данных». [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]

  1. База данных Oracle
  2. MySQL
  3. Microsoft SQL-сервер
  4. PostgreSQL (бесплатное программное обеспечение)
  5. IBM DB2
  6. Microsoft Доступ
  7. SQLite (бесплатное программное обеспечение)
  8. MariaDB (бесплатное программное обеспечение)
  9. Снежинка
  10. База данных SQL Microsoft Azure
  11. Apache Hive (бесплатное программное обеспечение)
  12. Терадата Преимущество

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Гастингс, Джордан (2003). Портативные программные инструменты для управления таксономиями и создания ссылок на них . Материалы семинара по методам цифрового картографирования '03 . Том. Открытый отчет Геологической службы США 03–471. 2. Технология реляционных баз данных и таксономическое представление. Архивировано из оригинала 21 октября 2014 г. Получено 6 апреля 2024 г. - через Геологическую службу США .
  2. ^ Jump up to: а б с д Кодд, Э.Ф. (1970). «Реляционная модель данных для больших общих банков данных» . Коммуникации АКМ . 13 (6): 377–387. дои : 10.1145/362384.362685 . S2CID   207549016 .
  3. ^ Эмблер, Скотт. «Реляционные базы данных 101: взгляд на всю картину» . [ нужен лучший источник ]
  4. ^ Дэйт, Крис (5 мая 2005 г.). База данных в глубине: реляционная теория для практиков . О'Рейли. ISBN  0-596-10012-4 .
  5. ^ Финансирование революции: государственная поддержка компьютерных исследований . Пресса национальных академий. 8 января 1999 г. ISBN.  0309062780 .
  6. ^ Сумати, С.; Эсаккираджан, С. (13 февраля 2008 г.). Основы систем управления реляционными базами данных . Спрингер. ISBN  978-3540483977 . Продукт назывался SQL/DS (язык структурированных запросов/хранилище данных) и работал в среде операционной системы DOS/VSE.
  7. ^ «Хронология Oracle» (PDF) . Журнал «Прибыль» . 12 (2). Оракул: 26 мая 2007 г. Проверено 16 мая 2013 г.
  8. ^ «Новая программа для баз данных выводит Macintosh в высшую лигу» . tribunedigital-чикаготрибуна . 28 июня 1987 года . Проверено 17 марта 2016 г.
  9. ^ Херши, WR; Истхоуп, Швейцария (1 декабря 1972 г.). «Теоретико-множественная структура данных и язык поиска» . Форум ACM SIGIR . 7 (4). Ассоциация вычислительной техники : 45–55. дои : 10.1145/1095495.1095500 . Проверено 4 января 2024 г.
  10. ^ SIGFIDET '74: Материалы семинара ACM SIGFIDET (ныне SIGMOD) 1974 года по описанию данных, доступу и контролю: модели данных: набор структур данных по сравнению с реляционными . Ассоциация вычислительной техники . 1 января 1975 г. ISBN .  978-1-4503-7418-7 . Проверено 4 января 2024 г.
  11. ^ Нотли, МГ (1972). Система Peterlee IS/1 . Научный центр IBM Соединенного Королевства . Проверено 4 января 2024 г.
  12. ^ Тодд, Стивен (1976). «Машина реляционного тестирования Петерли - обзор системы». IBM Systems Journal . 15 (4): 285–308. дои : 10.1147/sj.154.0285 .
  13. ^ Рамакришнан, Рагху; Донджеркович, Донко; Ранганатан, Арвинд; Бейер, Кевин С.; Кришнапрасад, Муралидхар (1998). «SRQL: язык сортированных реляционных запросов» (PDF) . E Труды SSDBM .
  14. ^ «Обзор реляционной базы данных» . oracle.com .
  15. ^ «Модель универсальных отношений для вложенной базы данных» , Модель базы данных вложенных универсальных отношений , Конспект лекций по информатике, том. 595, Берлин, Гейдельберг: Springer Berlin Heidelberg, стр. 109–135, 1992, doi : 10.1007/3-540-55493-9_5 , ISBN  978-3-540-55493-6 , получено 1 ноября 2020 г.
  16. ^ «Грэй будет удостоен премии А. М. Тьюринга этой весной» . Microsoft ПрессПасс. 23 ноября 1998 г. Архивировано из оригинала 6 февраля 2009 года . Проверено 16 января 2009 г.
  17. ^ Грей, Джим (сентябрь 1981 г.). «Концепция транзакции: преимущества и ограничения» (PDF) . Материалы 7-й Международной конференции по очень большим базам данных . Купертино, Калифорния: Тандемные компьютеры . стр. 144–154 . Проверено 9 ноября 2006 г.
  18. ^ Грей, Джим, и Рейтер, Андреас, Распределенная обработка транзакций: концепции и методы . Морган Кауфманн , 1993 год. ISBN   1-55860-190-2 .
  19. ^ Дата (1984) , с. 268.
  20. ^ Коннолли, Томас М; Бегг, Кэролайн Э (2015). Системы баз данных: практический подход к проектированию, внедрению и управлению (глобальное изд.). Бостон Колумбус Индианаполис: Пирсон. п. 416. ИСБН  978-1-292-06118-4 .
  21. ^ Коннолли, Томас М.; Бегг, Кэролайн Э. (2014). Системы баз данных - практический подход к реализации дизайна и управлению (6-е изд.). Пирсон. п. 64. ИСБН  978-1292061184 .
  22. ^ Пратт, Филип Дж.; Последняя, ​​Мэри З. (8 сентября 2014 г.). Концепции управления базами данных (8-е изд.). Курсовая технология. п. 29. ISBN  9781285427102 .
  23. ^ Фейерлих, Джордж (21 апреля 2010 г.). Датсо 10; Тенденции и направления баз данных: текущие проблемы и возможности (1-е изд.). Прага, Соколовск: МАТФИЗПРЕСС. стр. 163–174. ISBN  978-80-7378-116-3 . {{cite book}}: CS1 maint: дата и год ( ссылка )
  24. ^ «Базы данных NoSQL поглощают рынок реляционных баз данных» . 4 марта 2015 г. Проверено 14 марта 2018 г.
  25. ^ Рейнш, Р. (1988). «Распределенная база данных для SAA». IBM Systems Journal . 27 (3): 362–389. дои : 10.1147/sj.273.0362 .
  26. ^ Справочник по архитектуре распределенных реляционных баз данных . Корпорация IBM SC26-4651-0. 1990.
  27. ^ «Рейтинг реляционных СУБД по движкам DB» . DB-двигатели . Проверено 29 апреля 2022 г.
  28. ^ «Oracle — явный лидер на рынке СУРБД стоимостью 24 миллиарда долларов» . 12 апреля 2012 г. Проверено 1 марта 2013 г.

Источники

[ редактировать ]
В Wikibooks есть книга на тему: Язык структурированных запросов.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Relational_database&oldid=1238397096"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 6f2b2dd57e2dbf7ab6f371be629c9298__1722695520
URL1:https://arc.ask3.ru/arc/aa/6f/98/6f2b2dd57e2dbf7ab6f371be629c9298.html
Заголовок, (Title) документа по адресу, URL1:
Relational database - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)