Объектно-реляционные и объектные базы данных

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

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


Таблица

Таблица — это базовая единица данных. В реляционной алгебре она называется «отношение» (relation). Состоит из столбцов (columns), которые определяют конкретные типы данных. Данные в таблице организованы в строки (rows), которые содержат множества значений столбцов.

Язык описания данных (DDL)

В SQL для создания таблицы используется оператор CREATE TABLE. Этот оператор является примером языка описания данных (DDL). DDL служит для описания структуры базы данных. Пример использования:

CREATE TABLE employee (
  emp_name VARCHAR(30),
  dep_id INTEGER
)

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

При создании таблицы могут быть использованы различные «ограничения» (constraints), которые содержат правила, указывающие, какие данные представлены в ней. Одним из самых используемых ограничений является первичный ключ (primary key constraint), который гарантирует, что каждая строка таблицы должна содержать уникальное значение. Первичный ключ может состоять из одного или нескольких столбцов. Первичные ключ, состоящие из нескольких столбцов, также называются «составными» (composite).

Правильным считается наличие первичного ключа во всех таблицах базы данных. При этом существует два варианта первичных ключей: искусственный (surrogate primary key) и естественный (natural primary key).

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

Второй же вариант представляет собой данные, которые уже присутствуют в описываемой предметной области. Например, почтовые индексы могут быть использованы как естественные первичные ключи без дополнительной обработки. Их использование, если, конечно, оно возможно, считается более правильным, чем искусственных.

Пример создания первичного ключа:

CREATE TABLE employee (
  emp_id INTEGER,
  emp_name VARCHAR(30),
  dep_id INTEGER,
  PRIMARY KEY (emp_id)
)

Внешние ключи

В то время как одна таблица имеет первичный ключ, другая таблица может иметь ограничение, описывающее, что её строки ссылаются на гарантированно существующие строки в первой таблице. Это реализуется через создание в «удалённой» таблице («потомке») столбца (может быть и несколько), значениями которого являются значения первичного ключа из «локальной» таблицы («родителя»). Вместе наборы этих столбцов составляют внешний ключ (foreign key constraint), который является механизмом базы данных, гарантирующим что значения в «удалённых» столбцах присутствуют как первичные ключи в «локальных». Это ограничение контролирует все операции на этих таблицах: добавление / изменение данных в «удалённой» таблице; удаление / изменение данных в «родительской» таблице. Внешний ключ проверяет, чтобы данные корректно присутствовали в обоих таблицах. Иначе операции будут отменены.

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

В примере представлена таблица «department», которая связана с таблицей «employee» через отношение столбцов «employee.dep_id» и «department.dep_id»:


Представленная на рисунке связь может быть описана через DDL следующим образом:

CREATE TABLE department (
  dep_id INTEGER,
  dep_name VARCHAR(30),
  PRIMARY KEY (dep_id)
)

CREATE TABLE employee (
  emp_id INTEGER,
  emp_name VARCHAR(30),
  dep_id INTEGER,
  PRIMARY KEY (emp_id),
  FOREIGN KEY (dep_id)
    REFERENCES department(dep_id)
)

Правила Кодда

Правило 0: Основное правило (Foundation Rule):

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

Правило 1: Информационное правило (The Information Rule):

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

Правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):

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

Правило 3: Систематическая поддержка отсутствующих значений (Systematic Treatment of Null Values):

Неизвестные, или отсутствующие значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных — как пустые строки.

Правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):

Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.

Правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):

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

Правило 6: Возможность изменения представлений (View Updating Rule):

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

Правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):

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

Правило 8: Физическая независимость данных (Physical Data Independence):

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

Правило 9: Логическая независимость данных (Logical Data Independence):

Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

Правило 10: Независимость контроля целостности (Integrity Independence):

Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.

Правило 11: Независимость от расположения (Distribution Independence):

База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияния на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.

Правило 12: Согласование языковых уровней (The Nonsubversion Rule):

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

Определение и свойства отношения

Пусть дана совокупность типов данных T1, T2, …, Tn, называемых также доменами, не обязательно различных. Тогда n-арным отношением R, или отношением R степени n называют подмножество декартовa произведения множеств T1, T2, …, Tn.

Отношение R состоит из заголовка (схемы) и тела. Заголовок представляет собой множество атрибутов (именованных вхождений домена в заголовок отношения), а тело — множество кортежей, соответствующих заголовку. Более строго:

  • Заголовок (или схема) H отношения R — конечное множество упорядоченных пар вида (Ai, Ti), где Aiимя атрибута, а Tiимя типа (домена), i=1,…, n. По определению требуется, чтобы все имена атрибутов в заголовке отношения были различными (уникальными).
  • Тело B отношения R — множество кортежей t. Кортеж t, соответствующий заголовку H, — множество упорядоченных триплетов (троек) вида <Ai, Ti, vi>, по одному такому триплету для каждого атрибута в H, где vi — допустимое значение типа (домена) Ti. Так как имена атрибутов уникальны, то указание домена в кортеже обычно излишне. Поэтому кортеж t, соответствующий заголовку H, нередко определяют как множество пар (Ai, vi).

Количество кортежей называют кардинальным числом отношения (кардинальностью), или мощностью отношения.

Количество атрибутов называют степенью, или «арностью» отношения; отношение с одним атрибутом называется унарным, с двумя — бинарным и т.д., с n атрибутами — n-арным. С точки зрения теории вполне корректным является и отношение с нулевым количеством атрибутов, которое либо не содержит кортежей, либо содержит единственный кортеж без компонент (пустой кортеж).

Основные свойства отношения:

  • В отношении нет двух одинаковых элементов (кортежей).
  • Порядок кортежей в отношении не определён.
  • Порядок атрибутов в заголовке отношения не определён.

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

Шаг 1. Подготовка данных

Для того чтобы нам было с чем работать, я набрал в твиттере запрос “#databases” и сформировал таблицу из 10 записей:

Таблица 1

full_name username text created_at following_username
Boris Hadjur _DreamLead What do you think about #emailing #campaigns #traffic in #USA? Is it a good market nowadays? do you have #databases? Tue, 12 Feb 2013 08:43:09 +0000 Scootmedia, MetiersInternet
Gunnar Svalander GunnarSvalander Bill Gates Talks Databases, Free Software on Reddit http://t.co/ShX4hZlA #billgates #databases Tue, 12 Feb 2013 07:31:06 +0000 klout, zillow
GE Software GEsoftware RT @KirkDBorne: Readings in #Databases: excellent reading list, many categories: http://t.co/S6RBUNxq via @rxin Fascinating. Tue, 12 Feb 2013 07:30:24 +0000 DayJobDoc, byosko
Adrian Burch adrianburch RT @tisakovich: @NimbusData at the @Barclays Big Data conference in San Francisco today, talking #virtualization, #databases, and #flash memory. Tue, 12 Feb 2013 06:58:22 +0000 CindyCrawford, Arjantim
Andy Ryder AndyRyder5 http://t.co/D3KOJIvF article about Madden 2013 using AI to prodict the super bowl #databases #bus311 Tue, 12 Feb 2013 05:29:41 +0000 MichaelDell, Yahoo
Andy Ryder AndyRyder5 http://t.co/rBhBXjma an article about privacy settings and facebook #databases #bus311 Tue, 12 Feb 2013 05:24:17 +0000 MichaelDell, Yahoo
Brett Englebert Brett_Englebert #BUS311 University of Minnesota’s NCFPD is creating #databases to prevent “food fraud.” http://t.co/0LsAbKqJ Tue, 12 Feb 2013 01:49:19 +0000 RealSkipBayless, stephenasmith
Brett Englebert Brett_Englebert #BUS311 companies might be protecting their production #databases, but what about their backup files? http://t.co/okJjV3Bm Tue, 12 Feb 2013 01:31:52 +0000 RealSkipBayless, stephenasmith
Nimbus Data Systems NimbusData @NimbusData CEO @tisakovich @BarclaysOnline Big Data conference in San Francisco today, talking #virtualization, #databases,& #flash memory Mon, 11 Feb 2013 23:15:05 +0000 dellock6, rohitkilam
SSWUG.ORG SSWUGorg Don’t forget to sign up for our FREE expo this Friday: #Databases, #BI, and #Sharepoint: What You Need to Know! http://t.co/Ijrqrz29 Mon, 11 Feb 2013 22:15:37 +0000 drsql, steam_games

В первую очередь, давайте разберёмся с колонками:

  • full_name: имя пользователя
  • username: логин в Twitter-е
  • text: текст твита
  • created_at: время создания твита
  • following_username: список пользователей, разделённых запятыми, которые подписались на этот твитт. Для краткости я сократил этот список до 2 имён.

Это реальные данные. Если хотите, вы можете их найти и обновить.

Хорошо. Теперь все наши данные находятся в одном месте. Даёт ли это нам возможность легко осуществить поиск по ним? Не совсем. Данная таблица далека от идеала. Во-первых, в некоторых столбцах у нас есть повторяющиеся записи: к примеру, в х “username” и “following_username”. Также колонка “following_username” нарушает правила реляционных моделей, т.к. её в ячейках присутствует более 1 значения (записи разделены запятыми).

К тому же у нас попадаются дубликаты и в строках.

Повторяющиеся данные действительно являются проблемой, т.к. они затрудняют процесс CRUD. К примеру, при поиске по данной таблице на обработку дубликатов будет уходить дополнительное время. К тому же, если пользователь обновит твитт, то нам нужно будет перезаписать все дубликаты.

Решение данной проблемы заключается в разделении Таблицы 1 на несколько таблиц. Давайте примемся за решение первой проблемы, а именно — устранение дубликатов в столбцах.

Основные операторы

— само отношение А (отношение здесь синонимично с таблицей и предикатом) является выражением реляционной алгебры, более того, так как это алгебра, любое выражение реляционной алгебры возвращает отношение (свойство замыкания операторов)

Selection (выборка; ограничение)

— selection (выборка; ограничение), A — отношение (предикат, таблица), – булева формула, по которой происходит отбор строк (кортежей, записей, etc)

Selection является по сути горизонтальным фильтром строк, т.е., можно представить, что мы идем по каждой строке и оставляем только те, что удовлетворяют условию . Простой пример для наглядности:

Projection (проекция)

— projection (проекция) на атрибуты A, B, …. Возвращает таблицу, в которой остаются только колонки (атрибуты) A, B, …. Простой пример ниже. По сути является фильтром по атрибутам т.е. это в некотором смысле вертикальный фильтр.

Переименование

— переименовывает колонку a в b в отношении A (атрибут, аргумент предиката, etc); два чая тому господину, который покажет, что алгебра строго более выразима с оператором переименования (нужно привести пример запроса, который не выразим без этого оператора, но выразим с )

Реляционная система управления базой данных (РСУБД)

Реляционная система управления базой данных (РСУБД) — СУБД, управляющая реляционными базами данных.

Доступ к реляционным базам данных осуществляется через реляционные системы управления базами данных (РСУБД). Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее. Причины такого доминирования неочевидны. На протяжении всего существования реляционных БД они постоянно предлагали наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости в сфере управлении данными.

Например, простой SELECT запрос может иметь сотни потенциальных путей выполнения, которые оптимизатор оценит непосредственно во время выполнения запроса. Все это скрыто от пользователей, однако внутри РСУБД создает план выполнения, основывающийся на вещах вроде алгоритмов оценки стоимости и наилучшим образом отвечающий запросу. Однако чтобы обеспечить все эти особенности, реляционные хранилища невероятно сложны внутри.

Реляционная система управления базой данных содержит:

  • командный язык;
  • язык программирования с ориентацией на обработку таблиц;
  • интерпретирующую и/или компилирующую систему; и
  • пользовательскую оболочку.

Подготовка эксперимента

Вышеизложенные теоретические рассуждения хотелось бы проверить на практике – это и было целью возникшей на долгих выходных задумки. Для этого необходимо оценить скорость работы нашего «условного приложения» во всех описанных сценариях использования базы, а также рост этого времени с ростом размера социальной сети (n). Целевым параметром, который нас интересует и который мы будем замерять в ходе эксперимента, является время, затраченное «условным приложением», на выполнение одной «бизнес-операции». Под «бизнес-операцией» мы понимаем одну из следующих:

  • Добавление одного нового друга
  • Проверка, является ли пользователь А другом пользователя Б
  • Удаление одного друга

Таким образом, с учетом обозначенных в изначальной постановке требований, сценарий проверки вырисовывается следующий:

  • Запись данных. Сгенерировать случайным образом исходную сеть размером n. Для большего приближения к «реальному миру» количество друзей у каждого пользователя – так же случайная величина. Замерить время, за которое наше «условное приложение» запишет в HBase все сгенерированные данные. Потом полученное время разделить на общее количество добавленных друзей – так мы получим среднее время на одну «бизнес-операцию»
  • Чтение данных. Для каждого пользователя составить список «личностей», для которых надо получить ответ, подписан ли на них пользователь или нет. Длина списка = примерно кол-ву друзей пользователя, причем для половины проверяемых друзей ответ должен быть «Да», а для другой половины – «Нет». Проверка производится в таком порядке, чтобы ответы «Да» и «Нет» чередовались (то есть в каждом втором случае нам придется перебирать все колонки строки для вариантов 1 и 2). Общее время проверки затем разделить на количество проверяемых друзей для получения среднего времени на проверку одного субъекта.
  • Удаление данных. Удалить у пользователя всех друзей. Причем порядок удаления – случайный (то есть «перемешиваем» изначальный список, использовавшийся для записи данных). Общее время проверки затем разделить на количество удаляемых друзей для получения среднего времени на одну проверку.

Сценарии необходимо прогнать для каждого из 5 вариантов моделей данных и для разных размеров социальной сети, чтобы посмотреть, как меняется время с ее ростом. В рамках одного n связи в сети и список пользователей для проверки должны быть, естественно, одинаковыми для всех 5 вариантов. Для лучшего понимания ниже привожу пример сгенерированных данных для n= 5. Написанный «генератор» дает на выходе три словаря ID-шников:

  • первый – для вставки
  • второй – для проверки
  • третий – для удаления

Как можно заметить, все ID, большие 10 000 в словаре для проверки – это как раз те, которые заведомо дадут ответ False. Вставка, проверка и удаление «друзей» производятся именно в указанной в словаре последовательности.

С учетом вычислительной мощности конкретного ноутбука экспериментально был выбран запуск для n = 10, 30, …. 170 – когда общее время работы полного цикла тестирования (все сценарии для всех вариантов для всех n) было еще более-менее разумным и умещалось во время одного чаепития (в среднем 15 минут).

Тут необходимо сделать ремарку, что в данном эксперименте мы в первую очередь оцениваем не абсолютные цифры производительности. Даже относительное сравнение разных двух вариантов может быть не совсем корректным. Сейчас нас интересует именно характер изменения времени в зависимости от n, так как с учетом указанной выше конфигурации «тестового стенда» получить временные оценки, «очищенные» от влияния случайных и прочих факторов, очень сложно (да и такой задачи не ставилось).

Кластеры атакуют!

В начале нового тысячелетия в технологическом мире лопнул пузырь доткомов (), надувавшийся в 1990-х годах. Это вызвало у многих людей вопросы об экономических перспективах Интернета, но в 2000-х годах некоторые из главных свойств сети веб приобрели очень большой масштаб.

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

Рост объема данных сопровождался ростом количества пользователей – крупнейшие сайты достигли громадных размеров и обслуживали огромное количество клиентов.

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

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

Когда произошел сдвиг в сторону кластеров, возникла новая проблема – реляционные базы данных не предназначены для работы на кластерах. Кластерные реляционные базы данных, такие как Oracle RAC или Microsoft SQL Server, основаны на концепции общей дисковой подсистемы. Они используют кластерную файловую систему, выполняющую запись данных в легко доступную дисковую подсистему, но это значит, что дисковая подсистема по-прежнему является единственным источником уязвимости кластера. Реляционные базы данных также могут работать на разных серверах с разными наборами данных, эффективно выполняя фрагментацию базы данных (sharding). Хотя это позволяет разделить рабочую нагрузку, вся процедура фрагментации должна контролироваться приложением, которое должно следить за тем, какой сервер базы данных и за какой порцией данных обращается.

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

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

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

В частности, большое влияние оказали две компании — Google и Amazon. Они вышли на передний фронт работы с горизонтально масштабированными кластерами; более того, они хранили огромные объемы данных. Это стимулировало остальные компании.

Обе компании были успешными и быстро растущими высокотехнологичными предприятиями, обладающими средствами и возможностями. Им не приходило в голову, что они уничтожают свои реляционные базы данных. Когда прошло первое десятилетие нового века, обе компании опубликовали короткие, но очень важные документы о своих усилиях: BigTable от компании Google и Dynarno от компании Amazon.


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

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

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

Язык управления данными (DML)¶

После того как определена схема базы данных и таблиц, в них можно помещать данные и изменять их с помощью DML, который реализован частью конструкций SQL. Далее будут подробно разобраны основные из этих конструкций.

Вставка (insert)

Новые строки добавляются с помощью команды . Эта команда содержит часть VALUES, в которой прописаны данные для каждой добавляемой строки:

INSERT INTO employee (emp_id, emp_name, dep_id)
    VALUES (1, 'dilbert', 1);

INSERT INTO employee (emp_id, emp_name, dep_id)
    VALUES (2, 'wally', 1);

Автоинкрементные целочисленные ключи

Большинство современных баз данных содержит в себе функционал для генерации инкрементных целочисленных значений, которые обычно используются в качестве искусственных первичных ключей. Как в примере с таблицами «employee» и «department». Например, при использовании , столбец в коде выше будет автоматически создан целочисленным; при использовании MySQL для создания автоинкрементных ключей используется опция ; в PostgreSQL для этих целей служит тип данных . Когда используются генераторы автоинкрементных первичных ключей, можно опустить эти столбцы в команде :

INSERT INTO employee (emp_name, dep_id)
    VALUES ('dilbert', 1);

INSERT INTO employee (emp_name, dep_id)
    VALUES ('wally', 1);

Базы данных с этой функциональностью также позволяют получить сгенерированное при вставке значение. При этом используются нестандартные для SQL конструкции и / или функции. Например, в PostgreSQL это параметр :

INSERT INTO employee (emp_name, dep_id)
    VALUES ('dilbert', 1) RETURNING emp_id;
emp_id
1

Обновление (Update)

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

UPDATE employee SET dep_id=7 WHERE emp_name='dilbert'

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

Основные недостатки

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

Реляционные СУБД все еще доминируют в системах обработки финансовых транзакций, но сегодня компании все шире применяют СУБД новой архитектуры NoSQL — горизонтально масштабируемые, распределенные и разрабатываемые в открытых кодах. Примеры таких систем — Hadoop, MapReduce и VoltDB. По оценкам аналитиков Forrester, около 75% данных на предприятиях это либо полуструктурированная информация (XML, электронная почта и EDI), либо неструктурированная (текст, изображения, аудио и видео), и лишь 5% от этих данных хранится в реляционных СУБД, а остальное — в базах других типов или в виде файлов, и неподвластно обработке реляционными системами.

По мнению Блора, реляционные СУБД «могут умереть так, что этого никто не заметит» — например, если Oracle в своей СУБД попросту заменит SQL-механизм на NoSQL. Таким механизмом, считает аналитик, могла бы стать одна из существующих сегодня столбцовых СУБД.

Операции реляционной алгебры

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

Переименование

Результатом применения операции переименования атрибутов является отношение с изменёнными именами атрибутов.

Синтаксис:

R RENAME Atr1, Atr2, … AS NewAtr1, NewAtr2,

где

R — отношение
Atr1, Atr2, … — исходные имена атрибутов
NewAtr1, NewAtr2, … — новые имена атрибутов.

Объединение

Отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих или A, или B, или обоим отношениям. Синтаксис:

A UNION B

Пересечение

Отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих одновременно обоим отношениям A и B. Синтаксис:

A INTERSECT B

Вычитание

Отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих отношению A и не принадлежащих отношению B. Синтаксис:

A MINUS B

Декартово произведение

Отношение, заголовок (A1, A2, …, An, B1, B2, …, Bm) которого является сцеплением заголовков отношений A(A1, A2, …, An) и B(B1, B2, …, Bm), а тело состоит из кортежей, являющихся всеми вариантами сцеплений кортежей отношений A и B: (a1, a2, …, an, b1, b2, …,bm),

таких, что

(a1, a2, …, an) ∈ A,
(b1, b2, …, bm) ∈ B.

Синтаксис:

A TIMES B

Выборка (ограничение)

Отношение с тем же заголовком, что и у отношения A, и телом, состоящим из кортежей, значения атрибутов которых при подстановке в условие c дают значение ИСТИНА. c представляет собой логическое выражение, в которое могут входить атрибуты отношения A и/или скалярные выражения. Синтаксис:

A WHERE c

Проекция

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

При выполнении проекции выделяется «вертикальная» вырезка отношения-операнда с естественным уничтожением потенциально возникающих кортежей-дубликатов. Синтаксис:

A

или

PROJECT A {x, y, …, z}

Соединение

Операция соединения отношений A и B по предикату P логически эквивалентна последовательному применению операций декартового произведения A и B и выборки по предикату P. Если в отношениях имеются атрибуты с одинаковыми наименованиями, то перед выполнением соединения такие атрибуты необходимо переименовать.

Синтаксис:

(A TIMES B) WHERE P

Деление

Отношение с заголовком (X1, X2, …, Xn) и телом, содержащим множество кортежей (x1, x2, …, xn), таких, что для всех кортежей (y1, y2, …, ym) ∈ B в отношении A(X1, X2, …, Xn, Y1, Y2, …, Ym) найдется кортеж (x1, x2, …, xn, y1, y2, …, ym).

Синтаксис:

A DIVIDEBY B

С этим читают