Общепринято мнение, что SQL безраздельно принадлежит вотчине реляционных баз данных. Действительно, первые версии языка, тогда ещё называвшегося SEQUEL, были разработаны компанией IBM в рамках одной из пионерских реализации реляционной СУБД System R в 1974 году. С тех пор SQL неизменно является основным входным языком для всех реляционных СУБД.
Однако, возможности языка SQL несколько шире благодаря своей декларативной природе. Реализовать интерпретатор SQL можно поверх самых разнообразных структур, не обязательно реляционных. Разумеется, это может наложить некоторые ограничения на конструкции и отход от стандарта, но суть технологии при этом останется неизменной.
Другой подход — отображение и последующая реализация реляционной модели на базе иерархий или сетевой модели (графа). Ведь любая таблица может быть представлена в виде дерева с несколькими уровнями иерархии.
Рис. 1. Пример представления таблицы графом без циклов
Так СУБД Cache, иерархическая в своей основе, и сетевая Raima реализуют собственное подмножество SQL для доступа к данным. В Cache реляционная модель реализуется поверх иерархической, поэтому работа на уровне SQL предоставляет программисту привычные операторы полноценного определения и манипуляции данными в терминах таблиц.
Аналогичным образом реализована реляционная модель поверх сетевой и в Raima. Подмножество SQL поддерживает нестандартный оператор натурального соединения (natural join), позволяющий связывать таблицы в запросе на основе заданной схемы, используя связи «по умолчанию».
Например, следующий запрос с использованием специфичного для Raima расширения SQL
SELECT
orders.number,
products.name_prod,
order_items.amount
FROM
orders
NATURAL JOIN order_items
NATURAL JOIN products
будет эквивалентен стандартному SQL-запрос
SELECT
orders.number,
products.name_prod,
order_items.amount
FROM
orders
INNER JOIN order_items ON orders.id_order = order_items.id_order
INNER JOIN products ON products.id_prod = order_items.id_prod
В рассмотренных случаях у программиста имеется выбор: оставаться лишь в рамках реляционной модели или работать на уровне «родной» для данной СУБД модели данных, прежде всего с целью повышения скорости обработки и выполнения запросов. Оборотной стороной такой универсальности может явиться более низкое быстродействие и ограниченные функциональные возможности по сравнению с СУБД, непосредственно реализующей реляционную модель.
В свете перечисленных возможностей термин NoSQL является бессмысленным в любой своей интерпретации, будь то «не-SQL» или «не только (Not only) SQL»: нереляционные модели, используемые NoSQL - СУБД вполне могут реализовать SQL в качестве входного декларативного языка высокого уровня вместо низкоуровневых манипуляций и навигационного подхода.