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.

Первые годы

Статья доктора Кодда вызвала волну исследований в области реляционных баз данных, включая большой исследовательский проект компании 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 и его роль в качестве стандартного языка управления реляционными базами данных.

• SQL был разработан научными сотрудниками компании IBM, и поддержка языка со стороны IBM является главной составляющей его успеха.
• Существуют официальные стандарты SQL, утвержденные ANSI/ISO, ко­торые существенно выросли как по сложности, так и по количеству охва­тываемых тем со времени первой версии 1986 года.
• Вопреки наличию стандартов, имеется множество коммерческих диалек­тов SQL. Ни один из них не соответствует в точности другому.
• SQL стал стандартным языком управления базами данных в широком диапазоне компьютерных систем и приложений, включая мэйнфреймы, рабочие станции, персональные компьютеры, системы оперативной об­работки транзакций, системы "клиент/сервер", хранилища данных и Интернет.

Вас заинтересует / Intresting for you:

Правила именование объектов SQ... 9859 просмотров Дэн Sat, 05 Jun 2021, 09:02:07

Типы данных SQL: стандарт ANSI... 4977 просмотров Дэн Sat, 05 Jun 2021, 09:43:17

Назначение языка SQL и необход... 3603 просмотров Ирина Светлова Mon, 28 Jun 2021, 19:23:28

Язык SQL: краткая инструкция п... 2527 просмотров Дэн Sun, 30 May 2021, 07:39:59