Какого языка нет в sql

Программное обеспечение работы с современными базами данных

История возникновения языка SQL восходит к 1970 году [ [ 3.1 ] ], когда доктор Е.Ф. Кодд предложил реляционную модель в качестве новой модели базы данных. Для доказательства жизнеспособности новой модели данных внутри компании IBM был создан мощный исследовательский проект, получивший название System/R. Проект включал разработку собственно реляционной СУБД и специального языка запросов к базе данных. Так в начале 70-х годов появился первый исследовательский прототип реляционной СУБД. Для этого прототипа разрабатывались и опробовались разные языки запросов, один из которых получил название SEQUEL (Structured English Query Language). С момента создания и до наших дней этот язык претерпел массу изменений, но идеология осталась неизменной.

Период с 1979 года (окончание проекта System/R) до настоящего времени характеризуется развитием и совершенствованием языка SQL и его постоянно увеличивающейся ролью в индустрии, связанной с созданием и эксплуатацией баз данных. Совершенно очевидно, что язык никогда не получил бы мирового признания, если бы на него не было никаких стандартов. Стандартизация – важная часть технологических процессов конца XX века. Именно наличие разработанных и официально признанных стандартов позволило утвердиться многим современным технологиям (не только в индустрии разработки программного обеспечения, но и в многих других сферах человеческой деятельности). Как обстоит дело со стандартами языка SQL и их поддержкой в распространенных СУБД?

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

• ANSI (American National Standards Institute) – Американский национальный институт стандартов;
• ISO ( International Standards Organization) – Международную организацию по стандартизации.

Работа над официальным стандартом языка SQL началась в 1982 году [8] в рамках комитета ANSI. В 1986 году (обратите внимание, сколько времени ушло на разработку стандарта и согласование деталей!) был утвержден первый вариант стандарта ANSI, а в 1987 году этот стандарт был утвержден и ISO. В 1989 году стандарт претерпел незначительные изменения, но именно этот вариант получил название SQL-1 или SQL-89 . В чем особенность SQL-89 ? За время разработки стандарта (1982–1989 гг.) были созданы, представлены на рынке и активно использовались несколько различных СУБД, в которых в том или ином виде был реализован некоторый диалект языка SQL. С учетом того, что разработкой стандартов занимались те же люди, кто внедрял SQL в СУБД, стандарт SQL-89 представлял собой плод множества компромиссов, приведших к наличию в нем большого количества «белых пятен», т.е. мест, которые не были описаны, а отданы на усмотрение разработчиков диалекта. В результате чуть ли не все имеющиеся диалекты стали совместимыми со стандартом, но особой пользы это не принесло.

Следующая реализация стандарта была призвана решить эту проблему. В результате длительных обсуждений и согласований в 1992 году был принят новый стандарт ANSI SQL-2 или SQL-92. SQL-92, который заполнил многие «белые пятна», впервые добавив в стандарт возможности, еще не реализованные в существующих коммерческих СУБД.

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

В систему управления базами данных Microsoft SQL Server входит язык Transact-SQL, разработанный на основе одного из стандартов SQL.

11.3.2. Достоинства языка SQL

Для ознакомления с достоинствами языка обратимся к соответствующей литературе [ [ 3.1 ] ]. Вот некоторые из них:

• межплатформенная переносимость;
• наличие стандартов;
• одобрение и поддержка компанией IBM (СУБД DB2);
• поддержка со стороны компании Microsoft (СУБД SQL Server, протокол ODBC и технология ADO);
• реляционная основа;
• высокоуровневая структура;
• возможность выполнения специальных интерактивных запросов ;
• обеспечение программного доступа к базам данных;
• возможность различного представления данных;
• полноценность как языка, предназначенного для работы с базами данных;
• возможность динамического определения данных;
• поддержка архитектуры клиент/сервер;
• поддержка корпоративных приложений;
• расширяемость и поддержка объектно-ориентированных технологий;
• возможность доступа к данным в Интернете;
• интеграция с языком Java (протокол JDBC);
• промышленная инфраструктура.

11.3.2. Общая характеристика SQL

Язык запросов SQL основан на операциях реляционной алгебры и, таким образом ориентирован на работу с множествами (отношениями), а не с отдельными записями. Как и в реляционной алгебре , операндами языка являются отношения (таблицы), результатами выполнения операции также являются отношения (таблицы). Таким образом, язык SQL предназначен для выполнения операций над таблицами, причем как над таблицами в целом (создание, удаление, изменение структуры), так и над данными таблиц (выборка, изменение, добавление и удаление). Отметим, что в явном виде язык SQL не является универсальным языком программирования в обычном понимании. В нем отсутствуют операторы условного перехода, организации циклов, позволяющие управлять ходом выполнения программы. Поэтому язык SQL относится к классу непроцедурных языков программирования. Это именно язык запросов к базе данных , который служит исключительно для организации базы данных и работы с ней. Как уже отмечалось выше, для разработки прикладных программ необходимо использовать другие базовые средства программирования, в который операторы языка SQL будут встраиваться. Языку SQL посвящено большое количество литературы, в том числе и учебников. Подробное изучение языка SQL не входит в задачи настоящего курса, это может занимать отдельный курс. Заметим, что этому языку посвящено большое количество литературы, в том числе и учебников. В связи с этим, здесь будут изложены только общие сведения о языке, как фундаментальном инструменте работы с базами данных.

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

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

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

Разновидности SQL

Как отмечалось выше, в отличие от «обычных» языков программирования в SQL отсутствует возможность объявления переменных, нет инструкции IF, нет цикла FOR и т.д. Собственно программирование (разработка прикладных программ) на подобном языке практически невозможно. Поэтому к настоящему моменту используются следующие технологии (режимы) работы с базой данных на языке SQL (в некоторых источниках эти технологии называют разновидностями языка SQL):

• формирование непосредственно пользователем запроса на языке SQL в интерактивном режиме ( интерактивный SQL );
• формирование запроса на языке SQL в прикладной программме (программный или встроенный SQL):
  • статическое формирование запроса ( статический SQL );
  • динамическое формирование запроса ( динамический SQL );
  • формирование запроса с помощью библиотек ( API – интерфейсы вызова подпрограмм ).

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

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

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

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

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

  В настоящем пособии для всех указанных технологий (разновидностей SQL) будут приведены основные идеи и рассмотрены ключевые концепции. Интерактивный SQL будет рассмотрен более подробно, чем программный. Детальное рассмотрение статического, динамического SQL и различных API-интерфейсов (ODBC, JDBC, DB Library и др.) выходит за рамки нашего курса.

  Краткие итоги: В лекции рассматриваются общие принципы организации программного обеспечения работы с реляционными базами данных, включающего

  • создание и ведение базы данных;
  • создание пользовательских приложений, включающих разработку пользовательского интерфейса по работе с базой данных.

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

  По языку SQL написано достаточно много литературы. Для более подробного знакомства можно указать, в частности [ [ 3.1 ] — [ 5.4 ] ].

  Какого языка нет в sql

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

  

  Освойте профессию «Аналитик данных»

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

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

  Находите закономерности и делайте выводы, которые помогут бизнесу

  

  Для чего нужен SQL

  SQL — это не язык программирования, поэтому написать приложение или сайт с его помощью не получится, но при этом внутренняя работа сайта (backend) невозможна без запросов. Поиск информации в Google — это тоже модель использования SQL. Пользователь задает параметры, которые его интересуют, и отправляет запрос на сервер; затем происходит магия и в поисковой выдаче появляются результаты, соответствующие именно этому запросу.

  SQL используют разные виды специалистов:

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

  Как работают запросы

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

  Пользователь → Клиент → Запрос → Система управления → База данных → Таблица с базами данных

  Данные для работы с SQL хранятся в таблицах. Как именно они устроены — разберемся ниже; пока же просто представим их. На пути от пользователя к таблице находится несколько посредников:

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

  

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

  Что такое база данных в SQL

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

  Основные понятия реляционной модели:

  1. Отношение — это сама таблица, она двумерная и состоит из столбцов и строк.

  2. Атрибут — столбец в таблице, который содержит один конкретный параметр: название, тип, дату, стоимость или другую характеристику.

  

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

  4. Кортеж (строка или запись) — это табличная строка с порядковым номером, в которой содержится информация об одном конкретном объекте.

  

  5. Значение — элемент таблицы, который находится на пересечении столбцов и строк.

  

  6. Ключ — это самый важный столбец в таблице, за счет этих значений и происходит взаимодействие в реляционной базе данных, он связывает таблицы между собой.

  

  Ключи бывают нескольких видов:

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

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

  Список пиццерий в городе Ассортимент одной из пиццерий с ключом id — 1

  SQL-операторы

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

  Операторы в SQL делятся на несколько групп в соответствии с задачами, которые они решают.

  DDL (Data Definition Language) — операторы определения данных. Они работают с объектами, то есть с целыми таблицами. Если базу нужно дополнить таблицей с новыми данными или, наоборот, убрать одну из таблиц с ошибочными данными — используется этот набор операторов.

  • CREATE — создание объекта в базе данных
  • ALTER — изменение объекта
  • DROP — удаление объекта

  DML (Data Manipulation Language) — операторы манипуляции данными. Эти операторы уже работают с содержимым таблиц — строками, атрибутами и значениями. С их помощью можно вносить изменения в конкретное значение. Например, заменить поле в колонке «Фамилия» в строке с данными сотрудницы компании посте того, как она вышла замуж. Или удалить строку с данными уволенного сотрудника.

  • SELECT — выбор данных в соответствии с условием
  • INSERT — добавление новых данных
  • UPDATE — изменение существующих данных
  • DELETE — удаление данных

  DCL (Data Control Language) — оператор определения доступа к данным. Он определяет, кто из пользователей может отправлять запросы к базе, менять объекты и значения. Например, можно отозвать доступ у сотрудника, перешедшего в другой отдел, а также открыть доступ к базе новому маркетологу или разработчику.

  • GRANT — предоставление доступа к объекту
  • REVOKE — отзыв ранее выданного разрешения
  • DENY — запрет, который является приоритетным над разрешением

  TCL (Transaction Control Language) — язык управления транзакциями. Транзакции — это набор команд, которые выполняются поочередно. Если все команды выполнены, транзакция считается успешной, а если где-то произошла ошибка — транзакция откатывается назад, отменяя все выполненные команды. Наглядный пример такой транзакции — оплата онлайн, когда банк просит сначала ввести сумму и получателя, затем проверить и подтвердить операцию, а после ввести одноразовый код. На каждом из этих этапов оплату можно отменить и транзакция откатится назад.

  • BEGIN TRANSACTION — обозначение начала транзакции
  • COMMIT TRANSACTION — изменение команд внутри транзакции
  • ROLLBACK TRANSACTION — откат транзакции
  • SAVE TRANSACTION — указание промежуточной точки сохранения внутри транзакции

  Виды СУБД

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

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

  Существуют разные виды таких систем, которые разрабатывает и техногиганты, вроде Google, Microsoft и Amazon, и более нишевые студии. Разработчики стремятся сделать свой продукт лучше, чтобы их система быстрее и качественнее других обрабатывала данные. Из-за этого появились разные виды языка SQL — так называемые SQL-диалекты. У каждой СУБД диалект имеет что-то общее со всеми, а также свои особенности, которые не будут работать в другой системе.

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

  • PostgreSQL — это объектно-ориентированная система, то есть она обрабатывает данные как абстрактные объекты. Каждый объект, в отличие от простых табличных значений, может иметь собственные характеристики и уникальные методы взаимодействия с другими объектами. Это позволяет PostgreSQL обрабатывать более сложные структуры данных и выполнять более сложные процедуры. Например, Яндекс.Почта в свое время перешла на эту систему, чтобы поддерживать стабильное соединение десятков тысяч пользователей к одной базе.
  • MySQL — простая в изучении и функциональная система, которая работает с сайтами и веб-приложениями. Чаще всего используется в системах управления контентом сайтов (CMS), на сайтах с возможностью регистрации пользователей, в корпоративных системах CRM, в планировщиках, чатах и форумах. MySQL считается одним из самых безопасных и высокоскоростных решений, которое существует на рынке.
  • SQLite — это облегченная встраиваемая версия СУБД. В ней нет возможности поделиться правами доступа, как во многих других системах, но благодаря своему устройству эта система быстрая и мощная. SQLite подходит для обработки запросов на сайтах с низким и средним трафиком, а также в однопользовательских мобильных приложениях и играх. Преимущество такой системы — файловая структура, то есть база в SQLite состоит из одного файла, поэтому ее очень легко переносить.
  • Oracle — одна из первых СУБД, которая появилась еще в 1977 году и развивается до сих пор. Это кроссплатформенная система, которая может работать на Windows, Linux, MacOS, мобильных и других ОС. Система используется в крупных коммерческих проектах. Например, в России с Oracle сотрудничают операторы МТС и Теле2, банк «Открытие» и ВТБ.
  • Google Cloud Spanner — это облачная система управления данными, которую Google разработал для управления собственными сервисами, например AdWords и Google Play. В 2017 году систему сделали общедоступной. Cloud Spanner относят к категории NewSQL — это системы, которые совмещают в себе преимущества реляционных и нереляционных СУБД.

  Как начать работу с SQL

  Для начала работы с SQL достаточно разбираться в основах Excel, чтобы понимать принцип работы запросов, а также иметь базовый уровень английского на уровне A1-A2. Эти навыки необходимы, чтобы понимать синтаксис SQL:

  • SELECT — выбери данные
  • FROM — вот отсюда
  • JOIN — добавь еще эти таблицы
  • WHERE — при таком условии
  • GROUP BY — сгруппируй данные по этому признаку
  • ORDER BY — отсортируй данные по этому признаку
  • LIMIT — нужно такое количество результатов
  • ; — конец предложения

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

  

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

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

  SQL: история, стандарты и перспективы языка

  

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

  SQL и эволюция управления базами данных

  Одной из основных задач вычислительной системы является хранение и обра­ботка данных. В конце 1960-х-начале 70-х годов стали появляться специализиро­ванные компьютерные программы для решения этой задачи, известные под назва­нием системы управления базами данных (СУБД). СУБД помогала пользователям компьютеров организовывать и структурировать данные и позволяла вычисли­тельной системе играть более активную роль в обработке данных. Хотя изначально СУБД использовались на больших ЭВМ (мэйнфреймах), их популярность быстро распространилась на мини-компьютеры, а затем и на рабочие станции, персо­нальные компьютеры и специализированные серверы.

  Системы управления базами данных играли ключевую роль в стремительном развитии компьютерных сетей и Интернета. Ранние СУБД работали в крупных монолитных вычислительных комплексах, где данные, программное обеспечение СУБД и прикладные программы, осуществлявшие доступ к базе данных, работали в единой системе. В 1980-x-l 990-х годах получила распространение архитектура «клиент/сервер», в которой пользователь персонального компьютера или при­кладная программа посредством локальной сети выполняли обращение к базе данных, расположенной в другой системе. В конце 90-х годов растущая популяр­ность Интернета и Веб оказала влияние на архитектуру управления данными. Се­годня пользователю зачастую достаточно иметь лишь веб-браузер, чтобы получить доступ к базам данных, расположенным не только в его организации, но и в любой точке земного шара. Такие интернет-архитектуры обычно включают три и более компьютерных систем: одна, где работает веб-браузер, обеспечивает взаимодейст­вие с пользователем и подключена через Интернет ко второй — серверу прило­жений,— где работает прикладное программное обеспечение, а та, в свою оче­редь, подключена к третьей системе, где работает СУБД.

  Сегодня рынок СУБД — это очень большой бизнес. Независимые компании по производству программного обеспечения и крупные поставщики продают про­граммы для управления базами данных па миллиарды долларов ежегодно. Прак­тически все компьютерные приложения уровня предприятия, поддерживающие деятельность крупных компаний и иных организаций, используют базы данных. Эти приложения включают некоторые быстрорастущие категории приложений, такие как ERP (Enterprise Resource Planning, управление ресурсами предприятия), CRM (Customer Relationship Management, система управления взаимосвязями с клиентами и партнерами), SCM (Supply Chain Management, управление цепоч­ками поставок), SFA (Sales Force Automation, автоматизация процесса продаж), а также финансовые приложения. Специализированные высокопроизводительные серверы, оптимизированные для работы большинства популярных баз данных, об­разуют многомиллиардный рынок, и еще большие миллиарды добавляет рынок дешевых серверов. Базы данных работают «за сценой» большинства транзакцион­но-ориентированных веб-сайтов и используются для хранения и анализа пользова­тельских транзакций. Таким образом, управление данными пронизывает все сег­менты компьютерного рынка.

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

  Краткая история SQL

  История SQL тесно связана с развитием реляционных баз данных. В табл. 1 пе­речислены основные вехи его сорокалетней истории. Понятие реляционной базы данных было введено доктором Э. Ф. Коддом (Edgar Frank «Ted» Codd), научным со­трудником компании IBM. В июне 1970 года доктор Кода опубликовал в журнале Communications of the Association for Computing Machinery статью «Реляционная модель для больших банков совместно используемых данных» («A Relational Model of Data for Large Shared Data Banks»), в которой в общих чертах была изложена ма­тематическая теория хранения данных в табличной форме и их обработки. От этой статьи и берут свое начало реляционные базы данных и SQL.

  Год

  Событие

  Доктор Кода создает модель реляционной базы данных

  Начинается разработка проекта System/R компании IBM

  Первая статья с описанием языка SEQUEL

  Опытная эксплуатация проекта System/R

  Появляется первая коммерческая СУРБД компании Oracle

  Компания Relational Technology выпускает СУБД Ingres

  Компания IBM создает СУБД SQL/DS

  ANSI формирует комитет по стандартизации языка SQL

  Компания IBM объявляет о создании СУБД DB2

  ANSI принимает стандарт SQL1

  Компания Sybase создает СУРБД для обработки транзакций

  ISO одобряет стандарт SQL1

  Компании Ashton-Tate и Microsoft объявляют о выпуске СУБД SQL Server для операционной системы OS/2

  Опубликован первый тест производительности ТРС (ТРС-А)

  Опубликован тест производительности ТРС-В

  Консорциум SQL Access Group публикует спецификацию доступа к базам данных

  Компания Microsoft публикует спецификацию протокола ODBC

  ANSI принимает стандарт SQL2 (SQL-92)

  Опубликован тест производительности ТРС-С (OLTP)

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

  Первые поставки программных продуктов, поддерживающих протокол ODBC

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

  Первый выпуск СУРБД с открытым кодом MySQL

  Опубликован стандарт API-функций для доступа к базам данных OLAP и тест производительно­сти OLAP-систем

  Компания IBM выпускает СУБД DB2 Universal Database, унифицировав ее архитектуру для работы на платформах других поставщиков

  Ведущие поставщики СУБД объявили о поддержке Java-технологий

  Компания Microsoft выпустила СУБД SQL Server 7, обеспечив поддержку корпоративных баз данных для платформы Windows NT

  Выпущена СУБД Oracle 8i, ознаменовавшая отход от архитектуры «клиент/сервер” и обеспе­чившая интеграцию баз данных с Интернетом

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

  J2EE стандартизовал JDBC-доступ к базам данных со стороны серверов приложений

  Первые годы

  Статья доктора Кодда вызвала волну исследований в области реляционных баз данных, включая большой исследовательский проект компании IBM. Цель этого проекта, названного System/R, заключалась в том, чтобы доказать работоспособ­ность реляционной модели и приобрести опыт реализации реляционной СУБД. Работа над проектом System/R началась в середине 70-х годов в лаборатории Сан­та-Тереза компании IBM в городе Сан-Хосе, штат Калифорния.

  В 1974-1975 годах, на первом этапе выполнения проекта System/R, был создан минимальный прототип реляционной СУБД. Кроме разработки самой СУБД, в рамках проекта System/R проводилась работа над созданием языков запросов к базе данных. Один из этих языков был назван SEQUEL (Structured English Query Language— структурированный английский язык запросов). В 1976-1977 годах разработанный прототип проекта System/R был полностью переделан, и в 1978­1979 годах новая реализация проекта System/R была установлена на компьютерах нескольких заказчиков компании IBM для опытной эксплуатации. Эта эксплуата­ция принесла пользователям первый реальный опыт работы с СУБД System/R и ее языком базы данных, который по юридическим соображениям был переименован в SQL. В 1979 году исследовательский проект System/R завершился, и IBM сделала заключение, что реляционные базы данных не только вполне работоспособны, но и могут служить основой для создания коммерческих программных продуктов.

  Первые реляционные СУБД

  Проект System/R и созданный в его рамках язык работы с базами данных под названием SQL были подробно описаны в технических журналах 1970-х годов. Се­минары по технологии баз данных характеризовались дебатами о достоинствах новой «еретической» реляционной модели. Уже в 1976 году было ясно, что IBM стала энтузиастом реляционной технологии баз данных и прилагает значительные усилия для развития языка SQL.

  Сообщения о проекте System/R привлекли внимание группы инженеров из го­рода Менлоу Парк, штат Калифорния, которые решили, что исследования компа­нии IBM предвещают значительный рынок сбыта для реляционных баз данных. В 1977 году они организовали компанию Relational Software, Inc., чтобы создать реляционную СУБД, основанную на SQL. Поставки этой СУБД, названной Oracle, начались в 1979 году. Oracle стала первой реляционной СУБД на компьютерном рынке. Она на целых два года опередила появление первой реляционной СУБД компании IBM и предназначалась для мини-компьютеров VAX компании Digital, которые были дешевле больших ЭВМ компании IBM. Эта компания агрессивно продвигала новый реляционный стиль управления базами данных и в конечном счете в качестве нового имени приняла название своей разработки. Сегодня Oracle Corporation является ведущим поставщиком реляционных СУБД с годовым оборо­том свыше десяти миллиардов долларов.

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

  В 1980 году несколько профессоров покинули Беркли и основали компанию Relational Technology, Inc., чтобы создать коммерческую версию системы Ingres, поставки которой на рынок начались в 1981 году. Ingres и Oracle сразу же вступи­ли в острую конкурентную борьбу, но это соперничество лишь привлекло внима­ние к технологии реляционных баз данных. Несмотря на техническое превосход­ство во многих областях, Ingres вскоре стала сдавать свои позиции, не выдержав конкуренции с возможностями, предлагаемыми языком SQL, а также по причине агрессивной маркетинговой политики компании Oracle. В 1986 году первоначаль­ный язык запросов QUEL был заменен на SQL. Это являлось свидетельством того, что стандарт SQL стал важным рыночным фактором. В середине 90-х годов техно­логия Ingres была продана компании Computer Associates, ведущему производи­телю программного обеспечения для мэйнфреймов (которая продала свою долю в Ingres в 2005 году).

  Продукты IBM

  В то время как Oracle и Ingres становились коммерческими продуктами, ком­пания IBM также предпринимала усилия по превращению проекта System/R в коммерческую разработку, получившую название SQL/Data System (SQL/DS). В 1981 году IBM объявила о создании СУБД SQL/DS, а в 1982 году начала ее по­ставки на рынок. В 1983 году IBM анонсировала версию SQL/DS для операцион­ной системы VM/CMS, часто используемой на больших ЭВМ компании IBM в корпоративных информационных центрах.

  В 1983 году IBM разработала еще одну реляционную СУБД для своих больших ЭВМ — Database 2 (DB2). Эта СУБД функционировала под управлением операци­онной системы MVS, которая являлась «рабочей лошадкой» в крупных центрах по обработке данных на мэйнфреймах. Поставки на рынок первой версии DB2 нача­лись в 1985 году, и представители компании IBM назвали ее своим стратегическим программным продуктом. С этого времени DB2 стала флагманом реляционных СУБД компании IBM. Благодаря значительному влиянию IBM на рынок вычисли­тельных систем, язык SQL этой СУБД фактически стал стандартом языка управле­ния базами данных. Технология, реализованная в DB2, затем была использована в программных продуктах всех направлений компании IBM, от персональных компьютеров до сетевых серверов и мэйнфреймов. В 1997 году IBM пошла еще дальше, объявив о создании версий DB2 для компьютерных систем своих конку­рентов— компаний Sun Microsystems и Hewlett-Packard. DB2 для мэйнфреймов остается центральным элементом стратегии IBM в области баз данных.

  Коммерческое признание

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

  Однако у реляционных продуктов было большое преимущество. Реализован­ные в них языки реляционных запросов (SQL, QUEL и другие) позволяли выпол­нять запросы к базе данных без написания программ и немедленно получать ре­зультаты. В результате реляционные базы данных постепенно стали использовать­ся в качестве инструментов для поддержки принятия решений. В мае 1985 года компания Oracle с гордостью объявила о том, что количество инсталляций реля­ционных продуктов ее производства превысило одну тысячу. Ingres к тому време­ни также была инсталлирована на сравнимом количестве компьютеров. Посте­пенно начали получать признание и продукты DB2 и SQL/DS, общее число ин­сталляций которых тоже превысило тысячу.

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

  В конце 1980-х годов росту популярности SQL начали способствовать и рыноч­ные тенденции. Компания IBM продвигала на рынок систему DB2 как лучшее ре­шение 1990-х годов. Опубликование в 1986 году стандарта SQL, принятого ANSI/ISO, официально придало SQL статус стандартного языка баз данных. Кро­ме того, SQL стал стандартом для компьютерных систем на базе UNIX, популяр­ность которых также росла ускоренными темпами в конце 1980-х годов. По мере увеличения мощности персональных компьютеров и объединения их в локальные сети возникла необходимость в более сложных СУБД. Поставщики таких СУБД при создании систем нового поколения для персональных компьютеров взяли за основу SQL, а поставщики СУБД для мини-компьютеров, чтобы выдержать конку­ренцию со стороны персональных компьютеров, вышли на зарождающийся ры­нок локальных вычислительных сетей.

  В начале 1990-х годов усовершенствование реализаций SQL и резкое возраста­ние мощи процессоров сделали SQL практичным решением для приложений об­работки транзакций. И наконец, SQL стал ключевой частью архитектуры «клиент/сервер», использующей персональные компьютеры, локальные сети и се­тевые серверы для построения дешевых систем обработки информации. С разви­тием Интернета для SQL нашлась новая роль — в качестве языка баз данных для интернет-приложений и электронной коммерции.

  Однако SQL не испытывал и недостатка в конкуренции. К началу 1990-х годов объектно-ориентированное программирование зарекомендовало себя как наибо­лее перспективный метод разработки приложений, особенно для персональных компьютеров и в области пользовательских графических интерфейсов. Объектная модель данных, со своими объектами, классами, методами и наследованием, плохо соотносилась с реляционной моделью таблиц, строк и столбцов данных. Ранние «объектные базы данных» включали Gemstone от Servio Logic, Gbase от Graphael и Vbase от Ontologic. В средине 1990-х годов выросло новое поколение компаний, рассчитывавших на то, что объектные базы данных вытеснят с рынка реляционные базы данных и их производителей, так же как в свое время SQL поступил с нере­ляционными базами данных. Здесь можно упомянуть такие продукты, как ITASCA от Itasca Systems, Jasmine от Fujitsu, Matisse от Matisse Software, Objectivity/DB от Objectivity, ONTOS от Ontos, Inc. (переименованного из Ontologic), 02 от 02 Technology, а также с полдесятка других. Ho SQL и реляционная модель более чем устояли перед этим натиском. Некоторые из упомянутых продуктов остались на рынке и сегодня, но большинство было просто куплено или сгинуло во мгле вре­мени. Например, 02 Technology постигла судьба некоторых других компаний, ку­пленных Informix, a Informix, в свою очередь, позже был приобретен IBM. Общие годовые доходы объектно-ориентированных баз данных измеряются миллионами долларов, в то время как рынок SQL, СУРБД, соответствующих инструментов и служб оценивается в десятки миллиардов долларов в год.

  По мере развития SQL этот язык стал применяться для решения множества за­дач, связанных с управлением данными, и постепенно, к концу 90-х годов, рынок баз данных перестал быть монолитным, разделившись на ряд специализированных сегментов. Одним из наиболее быстрорастущих среди них стал сегмент хранилищ данных, где базы данных применяются для анализа огромных объемов информа­ции на предмет выявления скрытых тенденций и моделей развития. Другим на­правлением является внедрение в SQL новых типов данных (в частности, мульти­медийных) и объектно-ориентированных принципов. Третий важный сегмент — это «мобильные» базы данных для переносных персональных компьютеров, взаи­модействующие с централизованными базами данных как в оперативном, так и в автономном режиме. Еще одним сегментом оказываются базы данных, работаю­щие с оперативной памятью, разрабатывающиеся как очень высокопроизводи­тельные, ориентированные на работу с потоком базы данных, предназначенные для управления сетевыми потоками данных.

  Несмотря на появление различных сегментов рынка, SQL по-прежнему остает­ся их общим знаменателем. И через сорок лет после его возникновения позиции SQL так же сильны, как и ранее. SQL остается стандартом в области баз данных. Всегда будут появляться новые проблемы — например, сейчас это необходимость включения поддержки XML и его иерархической модели данных, а также необхо­димость поддержки огромных массивов данных в масштабе Интернета. Но исто­рия последних сорока лет дает все основания рассчитывать на то, что SQL и реля­ционная модель обладают изрядным запасом сил и способны справиться с новыми требованиями к управлению данными.

  Стандарты SQL

  Одним из наиболее важных шагов на пути к признанию SQL на рынке стало появление стандартов этого языка. Обычно при упоминании «стандарта SQL» имеют в виду официальный стандарт, утвержденный Американским националь­ным институтом стандартов (American National Standards Institute, ANSI) и Меж­дународной организацией по стандартизации (International Standards Organi­zation, ISO). Однако существуют и другие важные стандарты, включая стандарт де- факто, каковым является SQL, реализованный в семействе продуктов DB2 компа­нии IBM, и Oracle-диалект SQL, доминирующий на рынке.

  Стандарты ANSI/ISO

  Работа над официальным стандартом SQL началась в 1982 году, когда ANSI по­ставил перед своим комитетом ХЗН2 задачу по созданию стандарта языка управ­ления реляционными базами данных. Вначале в комитете обсуждались преимуще­ства различных предложенных языков. Однако, поскольку к тому времени на рынке стандартом де-факто стал SQL, комитет ХЗН2 остановил свой выбор на нем и занялся его стандартизацией.

  Разработанный в результате стандарт в большей степени был основан на диалек­те SQL системы DB2, хотя и содержал в себе ряд существенных отличий от этого диалекта. После нескольких доработок в 1986 году стандарт был официально утвер­жден как стандарт ANSI номер Х3.135, а в 1987 году — в качестве стандарта ISO. За­тем стандарт ANSI/ISO был принят правительством США как федеральный стан­дарт США в области обработки информации (Federal Information Processing Standard, FIPS). Этот стандарт, незначительно пересмотренный в 1989 году, обычно называют стандартом SQL1 или SQL-89.

  Многие из членов комитетов ANSI и ISO представляли фирмы-поставщики различных СУБД, в каждой из которых был реализован собственный диалект SQL. Как и диалекты человеческого языка, диалекты SQL были, в основном, похожи друг на друга, однако несовместимы в деталях. Во многих случаях комитет просто обошел существующие различия и не стандартизировал некоторые части языка, определив, что они реализуются по усмотрению разработчика. Этот подход по­зволил объявить большое число реализаций SQL совместимыми со стандартом, однако сделал сам стандарт относительно слабым.

  Чтобы заполнить эти пробелы, комитет ANSI продолжил свою работу и создал проект нового, более жесткого, стандарта SQL2. В отличие от стандарта 1989 года, проект SQL2 предусматривал возможности, выходящие за рамки возможностей, уже реализованных в реальных коммерческих продуктах. А для следующего за ним стандарта SQL3 были предложены еще более глубокие изменения. Кроме то­го, была предпринята попытка официально стандартизировать те части языка, на которые давно существовали «собственные» стандарты в различных СУБД. В ре­зультате предложенные стандарты SQL2 и SQL3 оказались более противоречивы­ми, чем исходный стандарт. Стандарт SQL2 прошел процесс утверждения в ANSI и был окончательно принят в октябре 1992 года. В то время как первый стандарт 1986 года занимает не более ста страниц, стандарт SQL2 (официально называемый SQL-92) содержит около шестисот.

  Существенным нововведением стало официальное утверждение трех уровней совместимости со стандартом SQL2. На самом нижнем, начальном, уровне (Entry Level) от СУБД требуются лишь минимальные дополнительные возможности в сравнении со стандартом SQL-89. Промежуточный уровень (Intermediate Level) представляет собой значительный шаг вперед по отношению к стандарту SQL-89, хотя и не затрагивает наиболее сложных и системно-зависимых аспектов языка SQL. Третий, самый высокий, уровень (Full Level) требует от СУБД реализации всех воз­можностей стандарта SQL2. В самом стандарте определение каждой возможности сопровождается описанием того, как она должна быть реализована на каждом из трех уровней. Сегодня специализированные базы данных, такие как используемые во встраиваемых приложениях или в приложениях с открытым кодом, в ряде облас­тей обладают начальным уровнем соответствия стандарту SQL, но все основные базы данных уровня предприятия полностью поддерживают стандарт SQL-92.

  После принятия SQL-92 работа над стандартами SQL шла в разных направле­ниях. Единый комитет разделился на ряд подкомитетов, каждый из которых рабо­тал над различными расширениями языка. Некоторые из них, например сохра­няемые процедуры, уже имелись во многих коммерческих SQL-базах данных. Другие, такие как предложенные объектные расширения SQL, пока что не были широко доступны или полностью реализованы. Новые версии стандарта были вы­пущены в 1999, 2003, 2006 и 2008 годах. Стандарт 2006 года включал существенные дополнения к XML-части стандарта.

  В процессе работы стандарт ANSI/ISO был разделен на 14 частей. Одни из них после некоторой активности в данном направлении оказались заброшены, неко­торые вошли в другие части, а над остальными продолжается активная работа.

  • Часть 1 — SQL/Framework содержит общие определения и служит «оглавлением» для других частей.
  • Часть 2 — SQL/Foundation представляет собой наибольшую часть и со­держит определения основных инструкций SQL для определения струк­туры базы данных и управления данными. Это потомок версий SQL-89 и SQL-92 стандарта. Данная часть существенно расширена путем вклю­чения структур для бизнес-анализа.
  • Часть 3 —SQL/CLI (Call Level Interface, интерфейс уровня вызовов) опи­сывает интерфейс уровня вызова процедур, хорошо известный как стан­дарт Microsoft ODBC. Он появился в 1995 году.
  • Часть 4—SQL/PSM (Persistent Stored Modules, постоянные хранимые модули) описывает процедурные расширения SQL, аналогичные воз­можностям, имеющимся в популярных процедурных SQL-языках напо­добие PL/SQL в Oracle.
  • Часть 5—SQL/Bindings описывает встраивание SQL в другие проце­дурные языки. Эта часть была объединена с частью 2 в версии SQL:2003 стандарта.
  • Часть 6 —SQL/Transaction была посвящена вопросам распределенных транзакций, но затем работа в данном направлении была остановлена.
  • Часть 7 —SQL/Temporal была посвящена расширениям SQL для работы с календарными и временными данными, но затем работа в данном на­правлении была прекращена.
  • Часть 8—SQL/Objects в процессе работы над SQL3 содержала объект­но-ориентированные расширения SQL. Эти расширения были внесены в часть 2 в стандарте SQLil
  • Часть 9 —SQL/MED (Management of External Data, управление внешни­ми данными) добавляет в язык возможности по работе с нереляционны­ми источниками данных; появилась в стандарте SQL:2003.
  • Часть 10—SQL/OLB (Object Language Bindings, связи с объектными языками) описывает обращение к SQL из языка программирования Java. Она связана с JDBC и SQL, встроенным в Java, и появилась в стандарте SQL:2003.
  • Часть 11 —SQL/Schemata содержит стандарты для »каталога базы дан­ных», или таблиц с самоописывающей базу данных системной информа­цией. Эта спецификация находилась в стандарте SQL:1999 в части 2, но была вынесена в отдельную часть в стандарте SQL:2003.
  • Часть 12 —SQL/Replication изначально определяла стандарты копиро­вания из одной SQL-базы данных в другую, но затем работа в данном на­правлении была прекращена.
  • Часть 13—SQL/JRT (Java Routines and Types, подпрограммы и типы Java) описывает подпрограммы и типы, используемые языком програм­мирования Java для доступа к SQL-базам данных; впервые появилась в стандарте SQL:2003.
  • Часть 14—SQL/XML описывает интеграцию XML (Extensible Markup Language, расширяемый язык разметки) в язык Впервые появилась в стандарте SQL:2003 и с тех пор была значительно расширена.

  С нескольких сотен страниц, описывающих базовые возможности языка SQL в 1986 году, стандарт ANSI/ISO SQL значительно вырос— как по объему, так и в смысле сложности и охвата различных тем. «Реальный» стандарт SQL, конечно, представляет собой SQL, реализованный в продуктах, занимающих важное место на рынке. Программисты и пользователи, как правило, предпочитают придержи­ваться тех частей языка, которые одинаковы у большинства продуктов. Большин­ство новых расширений SQL начинаются как новшества крупных производителей баз данных. Некоторые из них так и не получают поддержку и со временем исче­зают из языка. Другие годами остаются в языке с единственной целью обеспечить обратную совместимость. Третьи же, наиболее удачные в коммерческом смысле, попадают «в струю», широко распространяются среди баз данных и в конечном счете оказываются в официальном стандарте.

  Другие ранние стандарты SQL

  Хотя стандарт ANSI/ISO наиболее широко распространен, он не был единст­венным стандартом SQL во времена его становления. Европейская группа постав­щиков X/OPEN также приняла SQL в качестве одного из своих стандартов для среды переносимых приложений на основе UNIX. Стандарты группы X/OPEN иг­рали важную роль на европейском компьютерном рынке, где ключевой задачей являлась переносимость приложений между компьютерными системами различ­ных производителей.

  Компания IBM также включила SQL в свою спецификацию Systems Application Architecture (архитектуры прикладных систем) в 1990-х годах и пообещала, что все ее продукты в конечном счете будут переведены на этот диалект SQL. Хотя данная спецификация и не оправдала надежд на унификацию линии продуктов компании IBM, движение в сторону унификации IBM SQL продолжается. Система DB2 остает­ся основной СУБД компании IBM для мэйнфреймов, однако компания выпустила реализацию DB2 и для OS/2, собственной операционной системы для персональных компьютеров, и для линии серверов и рабочих станций RS/6000, работающих под управлением UNIX. Распространение DB2 (не только на разные аппаратные систе­мы, но и для разных типов данных) воплотилось в названии одной из последних реа­лизаций DB2 — Universal Database (универсальная база данных, UDB).

  ODBC и консорциум SQL Access Group

  В технологии баз данных существует важная область, которую не затрагивали ранние официальные стандарты. Это взаимодействие баз данных — методы, с по­мощью которых различные базы данных могут обмениваться информацией, обычно по сети. В 1989 году несколько производителей программного обеспечения сформировали консорциум SQL Access Group специально для решения этой про­блемы. В 1991 году консорциум опубликовал спецификацию RDA (Remote Database Access, удаленный доступ к базам данных). К сожалению, эта специфи­кация была тесно связана с сетевыми протоколами OSI, которые проиграли сете­вую битву протоколам TCP/IP, поэтому она никогда не была широко реализована.

  Второй стандарт от SQL Access Group повлиял на рынок существенно сильнее. В результате настойчивых требований компании Microsoft консорциум SQL Access Group обратил свое внимание на интерфейс уровня вызовов. Спецификация CLI (Call Level Interface, интерфейс уровня вызовов), основанная на разработках компании Microsoft, увидела свет в 1992 году. В этом же году был опубликован и протокол ODBC (Open Database Connectivity, открытый доступ к базам данных) компании Microsoft, основанный на спецификации CLI. Благодаря рыночному влиянию Microsoft и благо­словению, полученному «открытым стандартом» от SQL Access Group, ODBC оказал­ся стандартом де-факто для интерфейсов доступа к SQL-базам данных на персональ­ных компьютерах. Весной 1993 года компании Apple и Microsoft объявили о соглаше­нии относительно поддержки ODBC в Macintosh и Windows, что закрепило за этим протоколом статус промышленного стандарта в обеих популярных средах с графиче­ским пользовательским интерфейсом. Вскоре появилась реализация ODBC для плат­формы UNIX. В 1995 году, с публикацией стандарта SQL/Call-Level Interface, интер­фейс ODBC стал стандартом ANSI/ISO.

  В течение последних десяти лет ODBC продолжает развиваться, но существен­но медленнее. Microsoft продолжает поддерживать ODBC, но основные усилия пе­ренесены в область создания более высокоуровневых, объектно-ориентированных интерфейсов для универсального доступа к базам данных. Тем не менее ODBC продолжает играть главную роль в обеспечении переносимости баз данных для приложений уровня предприятия и инструментария баз данных. Достаточно рас­пространена ситуация, когда инструментарий базы данных или приложение уровня предприятия поддерживает «драйвер», оптимизирующий непосредствен­ный доступ к базам данных Oracle, DB2 или SQL Server с помощью их специфиче­ских интерфейсов уровня вызова. Такое приложение обычно включает дополни­тельный драйвер, использующий в качестве способа поддержки широкого диапа­зона других баз данных ODBC. Поскольку этот подход принят очень многими приложениями и инструментами, практически все производители баз данных предоставляют доступ с применением ODBC, иногда в качестве основного интер­фейса уровня вызовов, а иногда как дополнение к высокопроизводительному ин­терфейсу, специфичному для данной базы данных.

  JDBC и серверы приложений

  Стремительный рост популярности Интернета привел к дальнейшему развитию стандартов обращения к базам данных, с тем чтобы они поддерживали работу с объ­ектно-ориентированным языком программирования Java. Java стал, по сути, стан­дартным языком для создания интернет-приложений, работающих на серверах приложений на базе Java. Компания Sun Microsystems, разработчик Java, приложи­ла немалые усилия по стандартизации применения Java для серверов приложений в спецификации Java2 Enterprise Edition (J2EE). J2EE включает Java Database Connectivity (JDBC) в качестве стандарта доступа к реляционным базам данных из Java. В отличие от доступа к базам данных из языка программирования С, где ODBC многие годы предшествовали интерфейсы уровня вызовов конкретных баз данных, стандарт JDBC был разработан относительно рано, на пике роста популярности Java. В результате частные интерфейсы для подключения к Java так и не появились, и единственным стандартом SQL-доступа со стороны Java стал JDBC.

  SQL и переносимость

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

  

  Рис. 1. Миф о переносимости SQL

  • Типы данных. В стандарте SQL определен достаточно широкий набор типов данных, однако производители постоянно добавляют новые типы. Даже старые типы данных могут помешать переносимости — например, специфичный для Oracle тип данных NUMBER широко используется для представления числовых данных в базах данных Oracle, — и при этом только в них.
  • Обратная совместимость. Не такая уж редкость встретить приложение уровня предприятия, работающее один-два десятка лет после того, как оно было написано, когда все программисты, создававшие его, давно уво­лены (или уволились). Такие программы становятся «неприкасаемыми», поскольку детальное знание о том, как они функционируют, оказывается утраченным. Большие разделы этих программ могут зависеть от старых, специфичных для данной базы данных, свойств SQL, так что производи­тели баз данных вынуждены поддерживать обратную совместимость, иначе имеется риск, что старые приложения перестанут работать. Такие увековеченные отличия диалектов препятствуют переносимости.
  • Системные таблицы. В стандарте SQL описание системных таблиц, в кото­рых содержится информация о структуре самой базы данных, появилось только в версии SQL-92. Поэтому каждый производитель создавал собствен­ные системные таблицы, которые продолжают развиваться и эволюциони­ровать и зачастую содержат информацию, которая выходит за указанные в стандарте пределы. Приложения, использующие такие специфичные для конкретной базы данных системные таблицы, непереносимы.
  • Программный интерфейс. В раннем стандарте SQL определен абстракт­ный способ использования SQL в приложениях, написанных на таких язы­ках программирования, как COBOL, С, FORTRAN и другие, который не был широко принят сообществом программистов. Стандарт SQL/CLI 1995 года окончательно определил программный доступ к SQL, но к тому времени коммерческие СУБД уже популяризовали собственные интер­фейсы и внедрили их в сотни тысяч пользовательских приложений и при­кладных пакетов. Хотя в настоящее время стандартные API и широко под­держиваются, большинство производителей баз данных продолжают пре­доставлять собственные интерфейсы, обеспечивающие более высокую производительность и более богатую функциональность, побочным дейст­вием которых является привязка к конкретной базе данных.
  • Семантические отличия. Поскольку некоторые элементы определены в стандартах как зависящие от реализации, может возникнуть ситуация, когда в результате выполнения одного и того же запроса в двух отве­чающих стандарту реализациях SQL будут получены два различных на­бора результатов. Примеры таких отличий могут быть найдены, напри­мер, в обработке значений NULL, в разных статистических функциях и в несовпадении процедур удаления повторяющихся строк.
  • Репликация и зеркальное копирование данных. Многие промышлен­ные базы данных содержат таблицы, которые дублируются в двух или большем количестве географически разнесенных баз данных, чтобы обеспечить высокую степень доступности или восстановления после ава­рий, для распределения нагрузки или снижения задержек при работе в сети. Методы, используемые для определения таких схем репликации и управления ими, у каждой базы данных свои, и от попыток стандарти­зовать процессы репликации пришлось отказаться.
  • Коды ошибок. Коды, возвращаемые инструкциями SQL при возникно­вении ошибок, появились в стандарте SQL-92, но все популярные СУБД к настоящему времени давно используют собственные коды ошибок. Да­же при использовании режима со стандартными кодами ошибок расши­рения в конкретных базах данных могут генерировать собственные коды, выходящие за рамки, определенные стандартом.
  • Структура базы данных. В стандарте SQL-89 определен язык SQL, кото­рый используется уже после того, как база данных открыта и подготов­лена к работе. Детали наименования баз данных и установки первона­чального подключения к тому времени уже сильно отличались. Стандарт SQL-92 в некоторой степени унифицирует этот процесс, но не может полностью скрыть детали реализации.

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

  SQL и сети

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

  Централизованная архитектура

  На рис. 2 изображена традиционная централизованная архитектура баз дан­ных, использовавшаяся в DB2 и первоначальных базах данных для мини­компьютеров, таких как Oracle и Ingres. В этой архитектуре и СУБД, и сами физи­ческие данные размещаются на центральном мини-компьютере или мэйнфрейме вместе с приложением, принимающим входную информацию с пользовательского терминала и отображающим на нем же данные. Прикладная программа «общается» с СУБД с помощью SQL.

  

  Рис. 2. Управление базами данных в централизованной архитектуре

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

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

  Архитектура файлового сервера

  Появление персональных компьютеров и локальных вычислительных сетей привело к разработке архитектуры файлового сервера (рис. 3). При такой архи­тектуре приложение, выполняемое на персональном компьютере, может получить прозрачный доступ к файловому серверу, на котором хранятся совместно исполь­зуемые файлы. Когда приложение, работающее на персональном компьютере, за­прашивает данные из такого файла, сетевое программное обеспечение автомати­чески считывает требуемый блок данных с сервера. Архитектура файловых серве­ров поддерживалась первыми СУБД для персональных компьютеров, такими как dBASE и позднее Microsoft Access, при этом на каждом персональном компьютере работала своя копия СУБД.

  

  Рис. 3. Управление базами данных в архитектуре файлового сервера

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

  Архитектура “клиент/сервер”

  На рис. 4 изображена очередная стадия эволюции сетевых баз данных — ар­хитектура клиент/сервер. В этой схеме персональные компьютеры объединены в локальную сеть, в которой имеется сервер баз данных, хранящий общие базы данных. Функции СУБД разделены на две части: пользовательские программы, та­кие как приложения для формирования интерактивных запросов, генераторы от­четов и прикладные программы, выполняются на клиентском компьютере, а ядро базы данных, которое хранит данные и управляет ими, работает на сервере. В этой архитектуре, популярность которой существенно возросла в течение 1990-х годов, SQL стал стандартным языком, обеспечивающим взаимодействие между пользова­тельскими программами и ядром базы данных.

  

  Рис. 4. Управление базами данных в архитектуре “клиент/сервер”

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

  Архитектура «клиент/сервер» снижает сетевой трафик и распределяет про­цесс загрузки базы данных. Функции для работы с пользователем, такие как обра­ботка ввода и отображение данных, выполняются на персональном компьютере пользователя. Функции для работы с данными, такие как дисковый ввод-вывод и выполнение запросов, выполняются сервером баз данных. Наиболее важно то, что SQL обеспечивает четко определенный интерфейс между клиентской и сер­верной системами, эффективно передавая запросы на доступ к базе данных.

  Преимущества данной архитектуры сделали ее наиболее популярной схемой при разработке новых приложений в середине 1990-х годов. Все ведущие СУБД — Oracle, Informix, Sybase, SQL Server, DB2 и многие другие — стали предлагать кли­ент-серверные возможности. Многие компании начали выпускать средства разра­ботки приложений «клиент/сервер». Некоторые из них разрабатывались произ­водителями баз данных, иные — сторонними производителями.

  У архитектуры «клиент/сервер», как и у всех остальных, есть свои недостатки. Наиболее серьезный из них— проблема управления прикладным программным обеспечением, расположенным на тысячах персональных компьютеров, а не на од­ной центральной машине. Обновление какого-либо приложения одновременно на тысяче персональных компьютеров в крупной компании требовало от его инфор­мационного подразделения огромных усилий. Все становилось еще хуже, если из­менения в прикладной программе должны были быть синхронизированы с измене­ниями в других приложениях или в самой СУБД. Кроме того, пользователи часто самостоятельно инсталлировали вспомогательное программное обеспечение и на­страивали установленные программы на свой манер, что, безусловно, в значитель­ной степени усложняло задачу администрирования. Компании разрабатывали спе­циальные стратегии борьбы с этими проблемами, но все равно к концу 1990-х годов возникла необходимость пересмотреть концепции управления приложениями «клиент/сервер» в больших распределенных системах.

  Многоуровневая архитектура

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

  Методы связывания веб-серверов и СУБД стремительно развивались в конце 1990-х-начале 2000-х годов, и в итоге это вылилось в трехуровневую сетевую архи­тектуру, показанную на рис. 5. Интерфейсом пользователя является веб-браузер, работающий на персональном компьютере или некотором другом «тонком клиен­те», например таком, как смартфон. Браузер взаимодействует с веб-сервером на прикладном уровне. Если пользователь запрашивает нечто большее, чем просто ста­тические веб-страницы, веб-сервер переадресует запрос серверу приложений, роль которого заключается в применении бизнес-логики, необходимой для обработки за­проса. Зачастую запрос включает обращение к старой системе, работающей на мэйнфрейме, либо к корпоративной базе данных. Это серверный уровень модели.

  Как и в случае архитектуры «клиент/сервер», SQL является стандартным язы­ком баз данных для обмена информацией между сервером приложений и серве­рами баз данных. Все программные продукты прикладного уровня для обращения к базам данных оснащены API на основе SQL. Поскольку большинство коммерче­ских серверов приложений использует стандарт Java2 Enterprise Edition (J2EE), ве­дущим API для доступа сервера приложений к базе данных является Java Database Connectivity (JDBC).

  

  Рис. 5. Управление базами данных в трехуровневой интернет-архитектуре

  Влияние SQL на ИТ-индустрию и рынок

  Будучи стандартным языком доступа к реляционным базам данных, SQL оказы­вает большое влияние на все сегменты компьютерного рынка. SQL-база данных IBM DB2 доминирует в области управления данными на мэйнфреймах. База данных Oracle контролирует рынок компьютерных систем и серверов под управлением UNIX. SQL Server от Microsoft — ведущая SQL-база данных для серверных операци­онных систем Windows для рабочих групп и ведомственных приложений. MySQL доминирует на рынке баз данных с открытым кодом. SQL принят в качестве техно­логии для оперативной обработки транзакций (online transaction processing, OLTP), что полностью опровергает мнение 1980-х годов о том, что реляционные базы дан­ных никогда не станут достаточно производительны для применения в приложени­ях обработки транзакций. Хранилища данных и приложения для извлечения ин­формации на базе SQL используются для изучения пользовательского спроса, с тем чтобы предоставлять продукты и услуги, в большей степени соответствующие тре­бованиям рынка. В Интернете базы данных на основе SQL служат основой для более персонализированных продуктов, служб и информационных сервисов, что является ключевым преимуществом электронной коммерции.

  SQL и мэйнфреймы

  Хотя иерархическая база данных IMS от IBM все еще предлагается для мэйн­фреймов IBM и работает со многими высокопроизводительными приложениями, ведущей базой данных для мэйнфреймов уже более чем два десятилетия является SQL-база данных DB2. IBM предлагает реализации DB2 для разных архитектур, но DB2 для мэйнфреймов можно рассматривать как «плавбазу для всей эскадры» баз данных IBM. Любые новые разработки баз данных для мэйнфреймов используют DB2, укрепляя доминирующую роль SQL в области обработки данных на мэйн­фреймах.

  SQL и мини-компьютеры

  Сегмент рынка реляционных СУБД для мини-компьютеров начал развиваться одним из первых. Первые продукты компаний Oracle и Ingres предназначались для мини-компьютеров VAX/VMS компании Digital. С тех пор обе СУБД были пе­ренесены на множество других платформ. СУБД компании Sybase, появившаяся позднее и предназначавшаяся для оперативной обработки транзакций, работала на нескольких платформах, включая VAX.

  Кроме того, на протяжении 1980-х годов поставщики мини-компьютеров раз­рабатывали собственные реляционные СУБД на основе SQL. Компания Digital на каждую систему VAX/VMS устанавливала собственную СУБД Rdb/VMS. Компа­ния Hewlett-Packard поставляла Allbase— СУБД, поддерживающую как HPSQL (диалект SQL от компании Hewlett-Packard), так и нереляционный интерфейс. Компания Data General поменяла свои старые нереляционные базы данных на СУБД DG/SQL. К тому же многие из поставщиков мини-компьютеров перепрода­вали реляционные СУБД независимых поставщиков. Все это помогло языку SQL утвердиться в качестве важной технологии в системах среднего уровня.

  Со средины 1990-х годов SQL-продукты поставщиков мини-компьютеров, в ос­новном, исчезли, уступив место мультиплатформенным разработкам компаний Oracle, Informix, Sybase и др. Oracle приобрела Rdb компании Digital; другие про­дукты постепенно оказались заброшены. Одновременно с этим угасло и влияние специализированных операционных систем для мини-компьютеров— всех их за­менила операционная система UNIX. Вчерашний рынок реляционных продуктов для мини-компьютеров стал сегодняшним рынком серверов баз данных для плат­формы UNIX.

  SQL и UNIX

  SQL был однозначно признан лучшим решением в области управления данны­ми для компьютерных систем на базе платформы UNIX. Операционная система UNIX, которая изначально была разработана в Bell Laboratories, в 1980-х годах ста­ла стремительно завоевывать популярность как независимая от производителя стандартная операционная система. Она работает на разнообразных компьютер­ных системах, начиная от рабочих станций и заканчивая мэйнфреймами, и стала стандартной операционной системой для высококачественных серверных систем, включая серверы баз данных.

  В начале 1980-х годов были доступны четыре большие СУБД для UNIX-систем. Две из них, производства компаний Oracle и Ingres, были UNIX-версиями продуктов для мини-компьютеров компании DEC. Две другие СУБД, Informix и Unify, были созданы специально для UNIX. Вначале ни одна из них не предлагала поддержку SQL, но к 1985 году Unify ввела эту поддержку в свою СУБД, a Informix полностью переписала свою СУБД, предложив Informix-SQL с полной поддержкой SQL.

  На сегодняшний день в данном сегменте рынка лидирует СУБД Oracle, доступ­ная для всех ведущих серверных платформ UNIX. Компания Informix была приоб­ретена IBM, которая продолжает предлагать продукты для своих собственных и чужих UNIX-систем. Серверы баз данных на базе UNIX (и все в большей степени на базе Linux) являются ведущим звеном в архитектуре «клиент/сервер» и в трех­уровневой архитектуре Интернета. Требования к повышению производительно­сти реляционных баз данных являлись одной из основных движущих сил на пути развития аппаратного обеспечения для платформы UNIX. Сюда можно отнести принятие симметричной мультипроцессорности (Symmetric Multiprocessing, SMP) в качестве базовой серверной архитектуры, разработку многоядерных микропро­цессоров (что можно рассматривать как SMP на уровне микросхемы), а также ис­пользование RAID (Redundant Array of Independent Disk, избыточный массив не­дорогих дисков), технологии, обеспечивающей резкое повышение производитель­ности ввода-вывода.

  SQL и персональные компьютеры

  С появлением первых моделей IBM PC базы данных стали приобретать попу­лярность на рынке персональных компьютеров. СУБД dBASE компании Ashton­Tate была инсталлирована более чем на миллионе персональных компьютеров, работавших под управлением MS DOS. Хотя в большинстве СУБД для персональ­ных компьютеров данные хранились в табличной форме, эти СУБД не обладали полной мощью реляционных баз данных и не поддерживали SQL. Первые СУБД для персональных компьютеров представляли собой соответствующим образом переработанные версии известных СУБД для мини-компьютеров и с трудом «умещались» на персональных компьютерах. Например, система Professional Oracle для IBM PC, анонсированная в 1984 году, требовала двух мегабайтов памя­ти — намного больше типичных для того времени 640 Кбайт.

  С появлением в апреле 1987 года операционной системы OS/2, созданной компа­ниями IBM и Microsoft, начался рост популярности SQL на персональных компьюте­рах. Кроме стандартной версии OS/2, компания IBM выпустила собственную расши­ренную редакцию OS/2 (OS/2 Extended Edition, OS/2 ЕЕ) со встроенной поддержкой SQL-базы данных и коммуникаций. Сделав SQL частью операционной системы, ком­пания IBM тем самым вновь подтвердила свою приверженность этому языку.

  Появление OS/2 ЕЕ стало проблемой для компании Microsoft. Поскольку она была разработчиком стандартной OS/2 и продавала ее другим производителям персональных компьютеров, потребовалась альтернатива OS/2 ЕЕ. Ответом Microsoft стала покупка лицензии на СУБД компании Sybase, разработанной для VAX, и перенос этой СУБД в систему OS/2. В январе 1988 года Microsoft и Ashton­Tate (в то время — лидер рынка баз данных для персональных компьютеров со своей dBASE) неожиданно объявили, что они будут совместно продавать новую СУБД, получившую название SQL Server. Компания Microsoft станет поставлять SQL Server вместе с OS/2 производителям компьютеров, а компания Ashton-Tate займется распространением SQL Server по розничным каналам пользователям персональных компьютеров. В сентябре 1989 года компания Lotus Development (еще один член большой тройки производителей программного обеспечения для персональных компьютеров того времени) внесла свой вклад в SQL Server, сделав инвестицию в компанию Sybase. В том же году компания Ashton-Tate отказалась от исключительных прав на распространение этой СУБД и продала свою долю компании Lotus.

  Хотя успех СУБД SQL Server для OS/2 был ограниченным (как, к сожалению, и успех самой весьма неплохой операционной системы), компания Microsoft в ти­пичном для нее стиле продолжала вкладывать деньги в эту СУБД и перенесла ее на платформу Windows NT. В течение некоторого времени компании Microsoft и Sybase оставались партнерами: первая сосредоточила свои усилия на рынке пер­сональных компьютеров, ЛВС и Windows NT, а вторая — на рынке мини­компьютеров и UNIX-серверов. Но по мере того как Windows NT и UNIX станови­лись конкурентами в качестве платформ для серверов баз данных, взаимоотноше­ния между компаниями начали переходить из области сотрудничества в область конкуренции. В конце концов пути компаний окончательно разошлись. Теперь они предлагают совершенно разные продукты, хотя некоторые сходные SQL- расширения (например, хранимые процедуры) выдают в них общее прошлое.

  На сегодняшний день СУБД SQL Server является ведущей СУБД для серверов под управлением Windows. Новые версии этой СУБД выходят каждые два-три го­да, причем с большими изменениями и дополнениями в таких областях, как рабо­та с XML, специальные данные, полнотекстовый поиск, хранилища и анализ дан­ных и высокая доступность. В то время как на очень больших серверах баз данных доминируют UNIX и Oracle, благодаря SQL Server серверы под управлением Windows смогли занять нишу систем среднего уровня.

  SQL и обработка транзакций

  В процессе своего развития SQL и реляционные базы данных почти не приме­нялись в приложениях, предназначенных для оперативной обработки транзакций (Online Transaction Processing, OLTP). Поскольку в реляционных базах данных упор делается на запросы, такие базы данных традиционно использовались в при­ложениях, служащих для поддержки принятия решений, и в приложениях с ма­лым объемом транзакций, где их низкое быстродействие не было недостатком. В области оперативной обработки транзакций, когда требовалось обеспечить од­новременный доступ к данным сотням пользователей и время ожидания каждого из них не должно было превышать доли секунды, доминировала нереляционная СУБД IMS (Information Management System, система управления информацией) компании IBM.

  В 1986 году компания Sybase, новичок на рынке СУБД, представила реляцион­ную СУБД, предназначенную специально для оперативной обработки транзакций. СУБД компании Sybase работала на мини-компьютерах VAX/VMS и рабочих стан­циях Sun и обеспечивала уровень быстродействия, необходимый для обработк и больших объемов транзакций. Вскоре вслед за этим компании Oracle Corporation и Relational Technology объявили, что также выпустят версии своих продуктов Oracle и Ingres для оперативной обработки транзакций. На рынке UNIX-систем компания Informix анонсировала OLTP-версию своей СУБД под названием Informix-Turbo.

  В апреле 1988 года компания IBM присоединилась к поставщикам реляционных СУБД для OLTP, выпустив систему DB2 Version 2. Тесты показали, что на больших мэйнфреймах эта система могла обрабатывать до 250 транзакций в секунду. Компа­ния IBM утверждала, что теперь быстродействие DB2 позволяет использовать ее во всех OLTP-приложениях, кроме наиболее требовательных к быстродействию, и по­ощряла клиентов устанавливать ее вместо IMS. После этого тесты OLTP стали стан­дартным маркетинговым инструментом для реляционных СУБД, вопреки серьезным сомнениям в том, насколько они отражают быстродействие реальных приложений.

  Развитие реляционных технологий и появление более мощных компьютеров при­вели к тому, что роль SQL в OLTP-приложениях резко возросла, как возросли и пока­затели производительности СУБД. Теперь поставщики СУБД начали позициониро­вать свои продукты в зависимости от показателей OLTP-производительности, и на не­сколько лет рынок баз данных погрузился в войну тестов производительности. Неза­висимая организация Transaction Processing Council (ТРС, совет по средствам обрабо тки транзакций) опубликовала серию собственных тестов (ТРС-А, ТРС-В и ТРС- С), чем только подогрела интерес к данной области со стороны поставщиков.

  В начале 2000-х годов реляционные базы данных на базе SQL на UNIX-серверах высокого класса преодолели рубеж 1000 транзакций в секунду. Системы «клиент/сервер», включающие реляционные СУБД, стали признанной архитек­турой для реализации OLTP-приложений. Таким образом, рассматриваемый ра­нее как «непригодный для оперативной обработки транзакций», язык SQL вырос до промышленного стандарта в области построения OLTP-приложений.

  SQL и базы данных для рабочих групп

  Стремительный рост популярности локальных сетей на базе персональных ком­пьютеров в 1980-е-90-е годы создал предпосылки для распространения новой архи­тектуры систем управления базами данных масштаба подразделений, или «рабочих групп». Первоначально СУБД, предназначенные для этого сегмента рынка, работа­ли под управлением операционной системы OS/2 компании IBM. Даже СУБД SQL Server, ныне играющая ключевую роль в стратегии компании Microsoft, связанной с платформой Windows, в свое время дебютировала как продукт для OS/2. В середине 90-х годов фирма Novell тоже изо всех сил старалась сделать свою сетевую операци­онную систему NetWare привлекательной платформой для серверов баз данных ра­бочих групп. На заре эры локальных сетей NetWare прочно утвердилась в качестве доминирующей операционной системы для файл/серверов и серверов печати. Объ­единившись с Oracle и другими разработчиками, Novell рассчитывала распростра­нить свое лидерство и на серверы рабочих групп.

  Однако появление операционной системы Windows NT, специализированной версии Windows для применения на серверах, вызвало настоящий переворот. Если в качестве файл/сервера NetWare явно превосходила NT по производительности, то NT имела более надежную и универсальную архитектуру, во многом подобную архитектуре операционных систем для мини-компьютеров. Microsoft успешно по­зиционировала NT как более привлекательную платформу для работы приложе­ний рабочих групп (в качестве сервера приложений) и баз данных рабочих групп. SQL Server компании Microsoft продавался (а часто просто встраивался) с NT в ка­честве тесно интегрированной платформы разработки приложений для рабочих групп. Поначалу информационные отделы компаний отнеслись к этой пока еще новой и непроверенной технологии с большой осторожностью, но предложение было слишком уж заманчивым: комбинация Windows NT и SQL Server позволяла различным подразделениям разрабатывать собственные небольшие проекты, не прибегая к помощи центрального информационного отдела компании. Поэтому она не только была принята, но и стимулировала интенсивный рост всего сегмента рынка баз данных для рабочих групп.

  Сегодня SQL стал общепризнанным стандартом в качестве языка работы с базами данных для рабочих групп. В дополнение к Windows, популярной платформой для серверов рабочих групп стал Linux. Большая часть рынка поделена между Microsoft SQL Server и Oracle, но в последнее время достаточно сильным (и дешевым) конку­рентом для них начинает становиться база данных с открытым кодом MySQL. Еще одним участником гонки можно назвать другую базу данных с открытым кодом — Postgres, разработанную в Калифорнийском университете в Беркли.

  SQL, хранилища данных и интеллектуальные ресурсы предприятия

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

  Хотя теоретически реляционные базы данных без труда можно использовать и для оперативной обработки транзакций, и для поддержки принятия решений, на практике возникает ряд очень важных проблем. Рабочая нагрузка OLTP-систем состоит из множества коротких транзакций, выполняемых с большой частотой, причем важным фактором является малое время реакции системы. В противопо­ложность этому запросы, связанные с принятием решений (например, «Какова средняя стоимость заказов для данного региона?» или «Насколько увеличился сбыт продукции по сравнению с аналогичным периодом прошлого года?»), могут требовать сканирования огромных таблиц и выполняться минутами или даже ча­сами. Если экономист-аналитик попытается выполнить подобный запрос во время пика деловых транзакций, это может вызвать серьезное снижение производитель­ности всей системы, что для оперативной обработки транзакций просто недопус­тимо. Еще одну проблему составляет размещение данных, необходимых для полу­чения ответов на вопросы из области делового анализа: они могут быть распреде­лены между многими базами данных, причем, как правило, еще и поддерживае­мыми разными СУБД и на разных компьютерных платформах.

  Необходимость в полноценном использовании информационного потенциала предприятия, т.е. накопленных им данных, а также практические проблемы, связан­ные с производительностью OLTP-систем, породили новое технологическое реше­ние, получившее название «хранилище данных» (data warehouses). Идею хранили­ща данных иллюстрирует схема на рис. 6. Бизнес-данные извлекаются из OLTP- систем предприятия, форматируются, проверяются и помещаются в отдельную базу данных, предназначенную исключительно для делового анализа («хранилище»). Из­влечение и форматирование данных можно выполнять на периодической основе в пакетном режиме во время наименьшей загрузки системы. В идеале из транзакци­онных баз данных извлекаются только новые и измененные данные, что позволяет сократить общее количество данных, обрабатываемых во время ежемесячной, еже­недельной или ежедневной операции обновления хранилища. Таким образом, дли­тельные запросы, связанные с деловым анализом, адресуются только к хранилищу данных и не требуют участия систем оперативной обработки транзакций.

  

  Рис. 6. Концепция хранилищ данных

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

  Для удовлетворения специфических потребностей приложений, работающих с хранилищами данных и часто называемых приложениями для оперативной аналитической обработки данных (Online Analytical Processing, OLAP), стали по­являться специализированные СУБД. Их производительность оптимизирована для выполнения сложных запросов, связанных только с чтением данных. Они поддерживают расширенный набор статистических функций и имеют встроен­ные средства для других распространенных типов анализа данных, например хронологического. За счет заблаговременного вычисления статистических дан­ных эти СУБД могут существенно ускорять получение средних и суммарных ве­личин. Среди специализированных СУБД есть некоторое количество таких, ко­торые не используют язык SQL, но большинство использует именно его, благо­даря чему получил распространение еще один сопутствующий термин — реля­ционная оперативная аналитическая обработка данных (Relational Online Analytical Processing, ROLAP).

  Эволюция рынка хранилищ данных привела к тому, что новым важным сег­ментом рынка стали инструменты для работы с хранилищами, часто именуемые интеллектуальными ресурсами (business intelligence). Три ведущие компании в этой области достигли немалого успеха на рынке до того, как были куплены промышленными гигантами. Компания Business Objects была приобретена SAP, ведущим производителем приложений уровня предприятия. Компания Hyperion досталась Oracle, a Cognos — IBM. Как и во многих других сегментах рынка, достоинства SQL в качестве стандарта сделали его важным фактором развития и обеспечили закрепление на рынке SQL-хранилищ данных и анали­тического инструментария.

  SQL и интернет-приложения

  В конце 1990-х годов основной движущей силой развития Интернета стал Веб. Первоначально Веб использовался для распространения информации в форме текста и графики и практически не применялся в области управления данными. Однако в средине 1990-х годов большая часть содержимого на корпоративных веб­сайтах была из корпоративных SQL-баз данных. Например, на коммерческом веб­сайте страницы содержат информацию о товарах, ценах, доступности товара на складе, специальных предложениях и т.п., причем обычно такие страницы созда­ются по запросу, на основе данных, выбранных из SQL-базы данных. Подавляющее большинство страниц на сайтах аукционов или туристических агентств также ос­новано на информации из SQL-баз данных, преобразованной в формат HTML- страниц. Осуществляется поток информации и в другом направлении, когда вве­денные пользователем данные в формы на веб-страницах вносятся в SQL-базы данных, являющиеся частью архитектуры веб-сайта.

  В начале 2000-х годов технологии Интернета стали применяться для соедине­ния компьютерных приложений друг с другом. Такие архитектуры распределен­ных приложений получили широкое распространение под общим названием веб­служб (web services). В соответствии с давними неписаными правилами компью­терной индустрии, появление новой технологии сопровождается появлением двух лагерей с различными стандартами и языками для их реализации. В данном слу­чае это лагерь, возглавляемый Microsoft под флагом .NET Framework, и лагерь сторонников Java и J2EE-cepверов приложений. Обе архитектуры признают клю­чевую роль XML, стандарта обмена структурированными данными наподобие тех, что находятся в SQL-базах данных.

  В ответ на поворот к веб-службам масса продуктов анонсировала поддержку XML в SQL-базах данных. Разработчики баз данных объявили о выпуске новых продуктов с поддержкой XML, доказывая, что именно в их базе данных идеально реализована встроенная возможность обмена данными в XML-формате через Ин­тернет. На это откликнулись известные производители реляционных баз данных, добавляя в свои продукты возможность ввода-вывода в формате XML и соответст­вующие типы данных. Тесная интеграция XML и SQL остается областью активных исследований всех основных производителей баз данных.

  Подход Интернета к масштабируемости также оказывает большое влияние на программное обеспечение баз данных. Многие элементы программного обеспече­ния в Интернете используют горизонтальное масштабирование, когда рабочая на­грузка распределяется между десятками или сотнями недорогих серверов. Поис­ковый механизм Google может служить одним из наиболее выдающихся примеров такой архитектуры, когда даже один простой запрос может быть распределен ме­жду десятками серверов, а общий объем поиска — десятки тысяч серверов в Ин­тернете. Имеется масса трудностей при применении такого подхода к управлению базами данных, и в настоящее время в этой области ведутся активные исследова­тельские работы.

  Заключение

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

  Интернет и базы данных. Часть 05. Язык SQL — структурированный язык запросов

  Язык SQL (Structured Query Language — структурированный язык запросов) — это основное средство общения с реляционными базами данных. Более того: для большинства реляционных СУБД использование языка SQL — это единственный способ выборки и модификации информации в базе.

  Язык SQL был разработан в 1970 году компанией IBM и достаточно быстро получил широкое признание. Разработчики реляционных СУБД один за другим включали SQL в свои продукты, но диалекты языка в разных СУБД достаточно сильно отличались.

  Массовое распространение SQL в различных, довольно сильно отличающихся диалектах привело к необходимости его стандартизации. В 1986 году ISO (Международная организация по стандартизации) и ANSI (Американский национальный институт стандартов) опубликовали стандарт SQL 86, который затем дважды — в 1989 и в 1992 годах — пересматривался. Стандарт SQL 92 действует по сей день.

  В настоящее время практически все разработчики СУБД декларируют соответствие диалектов языка SQL, реализованных в их продуктах, стандарту SQL 92. Но при ближайшем рассмотрении оказывается, что не все так радужно. Те или иные, пусть совсем небольшие, отклонения от стандарта SQL 92 присутствуют во всех СУБД, с которыми мне доводилось работать.

  Основные принципы языка SQL

  SQL — непроцедурный язык. В SQL не записываются шаг за шагом все инструкции, а просто говорится, что нужно сделать. Например: выбрать все строки таблицы Users, в которых UserFIO = «Вася Пупкин». Как это будет делаться, в каком порядке блоки данных будут считываться с диска, какие циклы надо организовать для обработки запроса и т.п. — это уже забота СУБД, а не программиста.

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

  Составные части языка SQL

  Традиционно выделяют две основных части языка SQL (хотя деление это во многом условное):

  • DDL — Data Definition Language — Язык определения данных. DDL включает в себя операторы создания, модификации, удаления объектов (Create, Alter, Drop. ). К DDL обычно также относят операторы управления правами пользователей (Grant, Revoke).
  • DML — Data Manipulation Language — Язык манипулирования данными. DML предназначен для ведения (добавления, модификации, удаления) и выборки информации из базы данных. Основные операторы DML — Select, Insert, Update и Delete.

  Интерактивный, статический и динамический SQL

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

  Похожие публикации:

  1. Как восстановить бэкап ms sql
  2. Как вывести 1 строку в sql
  3. Как вывести первую запись в sql
  4. Как вызвать скалярную функцию в sql