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

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

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

• Db2: при использовании Db2 пользователи получают запатентованную систему управления реляционными базами данных от IBM по коммерческой лицензии.
   
• Microsoft SQL Server: система управления реляционными базами данных от Microsoft доступна по платной лицензии Microsoft для конечных пользователей.
   
• MySQL:MySQL является наиболее широко используемой в мире РСУБД с открытым исходным кодом. С момента ее приобретения компанией Oracle, MySQL продается по системе двойного лицензирования. Оригинальное сообщество разработчиков продолжает проект под названием MariaDB.
   
• PostgreSQL: с помощью PostgreSQL пользователи получают доступ к бесплатной объектно-реляционной системе управления базами данных (ORDBMS). Дальнейшее развитие осуществляется сообществом разработчиков с открытым исходным кодом.
   
• Oracle Database: система управления реляционными базами данных, созданная одноименной компанией, Oracle продается как проприетарное программное обеспечение за плату.
   
• SQLite: SQLite — это программная библиотека с открытым исходным кодом, содержащая систему управления реляционными базами данных.

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

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

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

R = (A₁ : Typ₁, A₂ : Typ₂ ,… , A_n : Typ_n)

Реляционная схема (R)включает в себя атрибуты A₁ до A_n. Каждому атрибуту присваивается тип данных (Type_1, Тип₂и т.д.). Это можно проиллюстрировать на конкретном примере.

Следующая схема определяет атрибуты отношения «сотрудник»:

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

Отношение с только что определенной схемой теперь может содержать следующий кортеж:

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

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

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

Таблица: сотрудники

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

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

• Определение структуры данных: когда вы определяете данные, описание структуры данных хранится в словаре данных в системе базы данных с помощью метаданных. Если, например, пользователь создает новую таблицу, то соответствующая схема отношений хранится в словаре данных. Словарь языка базы данных, используемый для определения данных, называется языком определения данных (DDL).
• Определение полномочий: каждый язык баз данных предоставляет синтаксис, позволяющий назначать или отзывать разрешения. Это называется язык управления данными (DCL) — подъязык языка базы данных.
• Определить условия целостности: условия целостности необходимы для состояния базы данных. Когда условия целостности определены, база данных гарантирует, что они выполняются в любое время. Это называется целостным состоянием. Например, основным условием целостности в реляционных системах баз данных является то, что каждая запись данных (кортеж) может быть однозначно идентифицирована.
• Определение транзакций: если база данных переходит из одного целостного состояния в другое, это называется транзакцией. Транзакции содержат серию инструкций и всегда должны быть выполнены полностью. Если транзакция завершается, база данных возвращается в исходное состояние (откат). Каждая транзакция начинается с команды подключения к базе данных. Затем следуют команды, инициирующие фактические операции с данными, и этап проверки (фиксация), обеспечивающий целостность базы данных. Операции, угрожающие целостности, не фиксируются (постоянно записываются в базу данных). Наконец, соединение с базой данных закрывается. Словарь языка базы данных, на котором основана работа с данными, известен как язык манипулирования данными (DML).
• Определение представлений: виртуальный обзор выбранных данных. В случае представления система управления базой данных создает виртуальную таблицу (логическое отношение) на основе физических таблиц. Пользователи могут применять к этим представлениям те же операции с базой данных, что и к физическим таблицам. Существуют различные типы представлений в зависимости от функции представления данных. Часто встречаются представления, которые фильтруют определенные строки (представление выбора) или столбцы (представление проекции) из выбранной таблицы, и представления, которые связывают различные таблицы вместе (составное представление).

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

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

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

Сначала мы используем команду «SELECT», чтобы дать указание РСУБД запросить данные. Затем мы определяем, какие данные мы хотим запросить, указывая таблицу и нужный столбец. Кроме того, мы используем «WHERE» для включения условия в SQL-запрос. Мы не хотим получить все значения атрибутов, хранящиеся в столбце, а только значение определенного набора данных.

Применительно к нашей таблице сотрудников SQL-оператор может выглядеть следующим образом:

Этот оператор SQL дает указание РСУБД получить значение из столбца «Номер социального страхования» таблицы «Сотрудники». В качестве условия мы указали, что значение должно быть взято из набора данных, для которого значение атрибута или столбца e_id соответствует значению 3.

База данных выдает нам результат 25 091225 M 463- номер социального страхования Уокера Макклейна, который имеет идентификатор 3.

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

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

1. Нормальная форма (1NF)

2. Нормальная форма (2НФ)

3. Нормальная форма (3НФ)

Нормальная форма Бойса-Кодда (BCNF)

4. Нормальная форма (4НФ)

5. Нормальная форма (5NF)

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

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

Такие таблицы базы данных, как, например, таблица «Сотрудники», позволяют использовать различные подходы для запроса отдельных значений или целых записей данных. Основное внимание уделяется так называемым ключам. В реляционной модели базы данных ключ — это набор атрибутов, которые подходят для однозначной идентификации записи данных.

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

Ключ со значениями

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

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

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

Затем можно определить следующего кандидата на ключ для приведенной выше таблицы:

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

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

Следующая таблица содержит данные, которые компания могла ввести для своего автопарка. Первичным ключом таблицы «vehicle» является последовательный vehicle_id.

Таблица 3: транспортное средство

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

Таблица: сотрудник

Таблица «Сотрудники» теперь показывает, что сотрудник Шмидт использует служебный автомобиль с vehicle_id 3. Сотрудник Кон управляет автомобилем с vehicle_id 2, а Мюллер и МакКлейн делят автомобиль с vehicle_id 1.

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

JOIN — это операция базы данных, которая позволяет одновременно запрашивать данные из нескольких таблиц базы данных. Данные из выбранных таблиц объединяются в набор результатов и фильтруются в соответствии с заданными пользователем условиями.

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

К наиболее важным типам JOIN относятся:

• INNER JOIN
• ВНЕШНЕЕ СОЕДИНЕНИЕ
• САМОСТОЯТЕЛЬНОЕ СОЕДИНЕНИЕ

Независимо от этого, следует различать EQUI JOINS и NON EQUI JOINs.

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

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

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

С изменениями в Интернете, которые были вызваны web 2.0, реляционная модель баз данных оказалась под огнем на рубеже тысячелетий. В рамках движения NoSQL (сокращение от not only SQL) были разработаны альтернативные модели, такие как документо-ориентированные базы данных. Целью этого движения была разработка мощных концепций баз данных для приложений с интенсивным использованием данных.

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

Объектно-ориентированная модель баз данных предусматривает хранение данных в виде объектов. Объекты модулируются так же, как и в объектно-ориентированном программировании. Объект, определяемый как сущность, содержит:

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

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

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

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

Пользователи взаимодействуют с ODBMS, используя язык запросов на основе SQL для объектных баз данных: язык объектных запросов (OQL). Результатом запроса OQL является не набор результатов, как в SQL, а список тех объектов, которые удовлетворяют условиям запроса OQL.

Известными реализациями объектно-ориентированной модели баз данных являются Realm, ZODB и Perst.

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

Если объекты из объектно-ориентированного языка программирования (например, C#, C++ или Java) должны храниться в реляционной базе данных, неизбежно возникает несовместимость из-за фундаментальных различий между двумя парадигмами программирования.

• Реляционные базы данных не поддерживают объектно-ориентированные концепции, такие как классы и наследование
• Независимая от состояния идентификация объектов не может быть реализована в модели реляционной базы данных
• Механизм защиты инкапсуляции данных недоступен в реляционной модели баз данных

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

Однако разработчики приложений, не желающие отказываться от преимуществ реляционного хранения данных, могут компенсировать несовместимость с помощью объектно-реляционных отобразителей (O/R mappers). Функциональные возможности объектно-реляционного отображения (ORM) реализованы в библиотеках. Они создают слой абстракции между объектно-ориентированным приложением и данными, хранящимися в таблицах.

Многие производители реляционных баз данных также оснащают свои продукты функциями, которые компенсируют несовместимость с объектно-ориентированным программированием. Системы баз данных такого рода известны как «объектно-реляционные».

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

Чтобы обеспечить управление абстрактными типами данных, объектно-реляционные базы данных расширяют реляционную модель баз данных:

• Сложные, определяемые пользователем типы данных
• Конструкторы типов
• Функции и методы

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

На рубеже тысячелетий объектно-реляционные расширения, такие как структурированные типы, были включены в новые версии стандарта SQL. Однако не все СУБД поддерживают их. Известными системами баз данных, предоставляющими расширения, являются IBM Db2, Oracle Database и Microsoft SQL Server.

В то время как реляционные базы данных хранят данные в таблицах базы данных, документно-ориентированная модель баз данных основана на гетерогенной базе данных отдельных документов. Это могут быть структурированные документы, такие как JSON, YAML или XML файлы, или неструктурированные файлы, такие как двоичные большие объекты (BLOB) — например, изображения, видео или аудио файлы.

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

Например, документ в формате JSON (JavaScript Object Notation), который используется для хранения данных о сотрудниках, может выглядеть следующим образом:

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

Запросы реализуются с помощью функций — например, через JavaScript. Системы управления базами данных, ориентированные на работу с документами, также присваивают уникальный идентификатор каждому документу. Однако, в отличие от реляционной модели базы данных, здесь нет схемы базы данных, охватывающей всю базу данных. Документы в базе данных, основанной на документах, не обязаны соответствовать нормальной форме, также нет предопределенных структурных особенностей, которые должны применяться ко всем документам. В принципе, каждый документ может быть структурирован по-своему. Однако мы рекомендуем создавать документы в схеме, соответствующей приложению, во время разработки приложения, чтобы создать предпосылки для конкретных запросов.

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

Документно-ориентированные системы баз данных особенно подходят для обработки больших объемов данных с неоднородной структурой и низкими сетевыми требованиями. Такая модель хранения данных особенно полезна для сценариев больших данных.

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

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

Примерами документно-ориентированных баз данных являются BaseX, CouchDB, eXist, MongoDB и RavenDB.

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

• Простая модель данных: реляционные базы данных основаны на модели данных, которая сравнительно проста в реализации и управлении. Множество информации — например, данные о клиентах, списки заказов или движения по счетам, — которую компании могут захотеть хранить длительное время, можно легко представить с помощью структуры таблиц, на которой основана модель реляционной базы данных.
• Низкая избыточность данных: модель реляционной базы данных определяет точно определенные правила для избежания избыточности с помощью различных нормальных форм. Если требования нормализации последовательно выполняются, системы реляционных баз данных более или менее позволяют хранить данные без избыточности. Это упрощает сопровождение и обслуживание данных, поскольку изменения необходимо вносить только в одном месте.
• Высокая согласованность данных: нормализованные реляционные базы данных обеспечивают последовательное хранение данных и тем самым способствуют согласованности данных. Системы реляционных баз данных также предлагают функции, позволяющие определять и проверять условия целостности. Транзакции, которые ставят под угрозу целостность данных, исключаются.
• Количественно-ориентированная обработка данных: система реляционных баз данных основана на количественно-ориентированной обработке данных, при которой каждая сущность разбивается на атомарные значения. Это позволяет связывать различные сущности через их содержание, а также выполнять сложные запросы к базе данных, такие как JOIN.
• Единый язык запросов: для запросов к реляционным базам данных был разработан язык баз данных SQL, стандартизированный комитетом из ISO и IEC. Цель этой стандартизации заключается в том, что приложения могут разрабатываться и выполняться в основном независимо от системы управления базой данных. Однако поддержка SQL все еще сильно варьируется в зависимости от СУБД.

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

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

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

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

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