Как реляционная модель Кодда превратилась в SQL

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

Кодд отделил данные от путей доступа

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

В опубликованной в 1970 году статье «A Relational Model of Data for Large Shared Data Banks» Кодд поставил в центр другую задачу. Пользователь и большинство прикладных программ должны работать с логическим представлением данных и не зависеть от того, как эти данные организованы внутри машины. Для этого он описал модель на основе отношений, то есть множеств кортежей, а также операции, с помощью которых из одних отношений можно получать другие.

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

Математической модели понадобился язык

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

Чемберлин и Бойс сначала работали над языком SQUARE, а затем упростили его запись и приблизили её к английским конструкциям. Их статья 1974 года «SEQUEL: A Structured English Query Language» описывала язык для профессиональных программистов и людей, обращающихся к базе лишь время от времени. Пользователь задавал нужные столбцы, источники и условия, не указывая конкретный путь чтения записей:

SELECT name, age
FROM users
WHERE age > 18

Название SEQUEL расшифровывалось как Structured English Query Language, но сохранилось недолго. В устной истории Чемберлина переименование описано довольно буднично: слово оказалось чужим товарным знаком, поэтому он убрал гласные и получил SQL, который по-прежнему можно было расшифровать как Structured Query Language. На встрече участников проекта в 1995 году владельцем знака назвали британскую Hawker Siddeley; это был повод сменить имя, а не отдельная техническая глава в развитии языка.

Бойс не был второстепенным участником этой работы. Он руководил языковой группой System R и вместе с Чемберлином проектировал SEQUEL, но в июне 1974 года внезапно умер от аневризмы мозга. Чемберлин позднее подчёркивал, что половина результатов этой совместной работы принадлежала Бойсу. Его вклад также сохранился в названии нормальной формы Бойса-Кодда, связанной с устранением аномалий и избыточности при проектировании отношений.

System R был важной ветвью, но не единственной

System R иногда называют первой реляционной СУБД, хотя такая формулировка стирает параллельную работу других команд. Сама IBM в описании архитектуры 1976 года называла System R исследовательской системой, а не будущим продуктом. Проект позволил проверить не только язык запросов, но и выбор путей доступа, стоимостную оптимизацию, блокировки, журналирование и восстановление, поэтому его влияние вышло далеко за пределы синтаксиса SQL.

Почти одновременно в Калифорнийском университете в Беркли создавали Ingres. Эта система тоже опиралась на реляционную модель, но использовала язык QUEL, близкий к реляционному исчислению. В описании Ingres говорится, что первая версия QUEL заработала в октябре 1974 года; авторы также отмечали влияние SEQUEL на выбор более читаемых ключевых слов. Два проекта не образовывали простую последовательность, в которой одна команда придумала всё, а остальные повторили: они по-разному превращали одну теоретическую основу в работающие системы и обменивались опубликованными идеями.

Именно практические результаты System R помогли SQL выйти за пределы прототипа. Ретроспектива проекта 1981 года описывает его как проверку того, можно ли получить удобство реляционной модели вместе с функциями и производительностью, нужными для повседневной работы. Исследования повлияли на IBM SQL/DS и DB2, а опубликованное описание языка использовали и другие разработчики. Подробности этого перехода сами участники собрали в расшифровке встречи «The 1995 SQL Reunion», где история SQL показана как результат работы исследователей, продуктовых команд и нескольких компаний, а не как выпуск одного готового изобретения.

Стандарт закрепил общее ядро, а не один диалект

К середине 1980-х SQL уже существовал в нескольких продуктах, поэтому стандартизаторы описывали язык с накопившейся практикой и различиями, а не начинали с чистого листа. В 1986 году появился американский стандарт ANSI X3.135-1986, а в июне 1987 года был опубликован международный ISO 9075:1987. Их целью была переносимость определений баз данных и прикладных программ, но наличие стандарта не обязывало все системы одновременно отказаться от прежнего синтаксиса и собственных возможностей.

Дальнейшие редакции SQL добавляли новые части языка, а продукты реализовывали разные версии, подмножества и расширения. Поэтому PostgreSQL использует, например, ILIKE, RETURNING и ON CONFLICT, MySQL предлагает AUTO_INCREMENT, а SQLite имеет собственные PRAGMA и таблицы WITHOUT ROWID. Документация самих проектов прямо отмечает такие отличия: PostgreSQL называет ILIKE расширением стандарта, MySQL отдельно описывает AUTO_INCREMENT, а SQLite предупреждает, что PRAGMA специфична для SQLite.

SQL при этом не является буквальной записью реляционной алгебры. Практический язык включает определение схем, изменение данных, управление транзакциями, NULL, сортировку и другие механизмы, которых не было в исходной математической модели в таком виде. Его долговечность объясняется не полной теоретической чистотой, а удачным разделением обязанностей: разработчик описывает требуемые данные, а СУБД выбирает способ их получить.

Что делает SQL Formatter

SQL Formatter работает целиком в браузере и форматирует запрос по токенам, не отправляя его на сервер. Инструмент распознаёт ключевые слова, строки, идентификаторы, однострочные и блочные комментарии, а также PostgreSQL dollar-quoted strings, после чего расставляет переносы и отступы вокруг основных конструкций.

В нём доступны четыре словаря ключевых слов: Standard SQL, MySQL, PostgreSQL и SQLite. Переключатель диалекта улучшает распознавание и подсветку характерных конструкций, но не проверяет грамматику запроса и не гарантирует, что выбранная СУБД выполнит его. Это особенно важно для редкого или сложного синтаксиса, поскольку форматтер использует токенизацию, а не полноценное синтаксическое дерево.

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

select u.id,u.name,count(o.id) as orders from users u left join orders o on u.id=o.user_id where u.active=1 group by u.id,u.name having count(o.id)>5 order by orders desc

Форматирование полезно для чтения, ревью и документации, но перед выполнением запрос всё равно должен проверить парсер конкретной СУБД. Эта граница как раз следует из истории SQL: общий каркас у языка один, а окончательный смысл некоторых конструкций задаёт выбранная реализация.

Похожие инструменты

SQL FormatterФорматируйте SQL с ключевыми словами на новой строке и настраиваемым отступом или минифицируйте в одну строку — с учётом диалекта MySQL, PostgreSQL и SQLite.JSON ToolboxПроверяйте синтаксис, форматируйте или минифицируйте данные и просматривайте вложенные API-ответы и конфиги в виде дерева.Конвертер YAML, JSON, TOML и .envКонвертируйте между YAML, JSON, TOML, .env и shell-экспортом с автоопределением входного формата, настраиваемым отступом и явным предупреждением там, где целевой формат не умеет что-то выразить — null в TOML, вложенность в .env.Regex TesterТестируйте паттерны вживую с подсветкой совпадений и группами захвата, переключайтесь на замену или split и читайте разбор каждого токена простым языком.