Возникновение технологии баз данных тесно связано с фирмой IBM. Само осознание необходимости такой технологии возникло в IBM, и первый программный продукт класса СУБД также родился в IBM в начале 60-х годов. Это была СУБД IMS (Information Management System), основанная на иерархической модели данных. Эта СУБД существует и применяется и по сей день.

Во второй половине 60-x годов фирма IBM начала фундаментальный проект по разработке технологий баз данных, и именно на первой стадии этого проекта доктором Э. Коддом была разработана реляционная модель и ее формальный аппарат. Первая публикация Кодда датирована 1970 г. [3], она вызвала широкий резонанс в научном сообществе и стимулировала как теоретические исследования, так и попытки практического их воплощения. Наиболее интересной из таких попыток была инициатива разработчиков IBM System/38. Еще до первых публикаций Кодда они приняли решение встроить СУБД в базовое программное обеспечение разрабатываемой системы. Ознакомившись с докладом Кодда на одном из внутренних семинаров IBM, они решили положить в основу своей СУБД реляционную модель, что и сделали, несмотря на протесты самого Кодда, еще не считавшего свою работу готовой для практического воплощения. Встроенная СУБД System/38 явилась первой "промышленной СУБД с реляционными возможностями". Назвать ее реляционной было нельзя потому, что из 8 реляционных операций она обеспечивала только 6. Но ранний старт System/38 обеспечил ей долговременное преимущество в гонке промышленных СУБД. Хотя, идя впереди всех, эта система иногда уходила в сторону от избиравшегося рынком впоследствии основного направления, ее нынешний наследник - DB2 for iSeries и сегодня является лидером.

70-е годы ознаменовались множеством экспериментальных и промышленных проектов СУБД, из которых наибольшее влияние на дальнейшее развитие оказали два - Ingress (Университет г.Беркли) и System R (IBM).

СУБД Ingress с самого начала разрабатывалась для Unix и в своей внутренней структуре использует свойства этой операционной системы, а в программном интерфейсе - язык QUEL, базирующийся на реляционном исчислении и EQUEL - расширение для применения QUEL в среде языка C. Эта СУБД существует и сейчас - в свободном и коммерческом вариантах (принадлежит фирме Computer Associates), тесно интегрированная с операционной системой BSD Unix. У СУБД Ingress есть сообщество верных сторонников, но она не принадлежит к числу гигантов рынка.

Ход работы над проектом IBM System R широко освещался в научной периодике, оказывая значительное влияние на других разработчиков. В чистом виде System R никогда не стала промышленной системой, но фактически большая часть современных промышленных СУБД в той или иной мере является ее наследниками. В ходе этой разработки был создан и язык запросов SQL. Первая коммерческая СУБД фирмы Oracle (1979 г.), также может считаться наследницей System R, хотя и со значительными оговорками, так как в ряде случаев в ней были выбраны совершенно оригинальные решения. Первыми коммерческим продуктом, на практике воплощающим System R, явилась IBM SQL/DS (1980 г.), а затем - IBM DB2 (1983 г.). Все промышленные СУБД того времени, следуя System R, были многопользовательскими, они обеспечивали создание и ведение интегрированных баз данных - единого репозитория данных, обслуживающего различные приложения одной информационной системы.

"Персональная революция" и персональные СУБД создали у некоторых пользователей и даже специалистов иллюзию того, что в сложных многопользовательских СУБД больше нет нужды, ибо все необходимые данные и программы для их обработки могут быть размещены на одном рабочем месте, а персональное использование данных снимало необходимость в многозадачной среде. Новое поколение СУБД - dBase. FoxPro, Paradox, Access и др. - создавалось для персональных компьютеров и сред MS DOS, Windows 3.1, Windows 95 - с отсутствием или ограниченностью реальной многозадачности. Это поколение отличается тем, что внимание разработчиков сместилось от проблем интегрированности, надежности и безопасности (вес этих проблем в персональной среде вообще значительно уменьшился) к проблемам максимально удобного для пользователя интерфейса. Персональные СУБД, как правило, предоставляют пользователю собственные инструментальные средства разработки приложений, основанные на табличном и визуальном программировании или упрощенных способах формулирования запросов. Язык SQL появляется в этих СУБД только в виде своих подмножеств и как дополнительная возможность.

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

Какими же путями можно выполнить современные требования?

1. Ввести интегрирующие свойства и многопользовательский доступ в персональные СУБД
2. Расширить старые СУБД средствами дружественного интерфейса
3. Разработать совершенно новые продукты

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

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

Третий путь тоже оказался не бесперспективный. Хороший пример - СУБД SQL Server, которую начинали делать совместно фирмы Microsoft, Sybase и Ahton. Впоследствии их пути разошлись, и сейчас мы имеем Microsoft SQL Server и Sybase SQL Server - продукты, по крайней мере, заметные на рынке. Однако, выясняется, что новые СУБД должны решать не столько новые проблемы, сколько те, которые уже решались в старых СУБД, поэтому новые находятся в положении догоняющих.

Возможно, одной из наиболее ожесточенных современных конкурентных войн в сфере информационных технологий является борьба между фирмами IBM и Oracle за лидерство на рынке СУБД.

Сложилось так, что IBM в начале развития своей СУБД ориентировалась прежде всего на мейнфреймы, а Oracle - на Unix-машины, и обе фирмы прочно завоевали лидирующие позиции в выбранных средах. СУБД Oracle раньше была портирована в среду Windows и некоторое время лидировала в этой среде, лишь недавно уступив лидерство Microsoft SQL Server. DB2 несколько запоздала с выходом в среды Unix и Windows, но выйдя на этот рынок, фирма IBM стала проводить весьма экспансионистскую политику. По темпам роста объемов продаж на этих платформах DB2 находится впереди своих конкурентов.

Ежегодно независимая экспертная фирма Gartner Group публикует рейтинг коммерческих СУБД по объему продаж. В отчетах за 2000 - 2002 гг. отмечалось, что темпы общего мирового бизнеса СУБД несколько снижаются, в 2002 г. этот рынок потерял почти 7% доходов. Это объясняется общей стагнацией экономики США и других западных стран. Поскольку СУБД являются краеугольным камнем в обработке данных для современной экономики, состояние последней непосредственно отражается на уровне продаж СУБД.

Рейтинг за 2002 г. по данным Gartner Group представлен в следующей таблице:

Качественно такая же картина наблюдается во все последние годы. Фирма IBM вышла в 2001 г. на первое место отчасти благодаря экспансии СУБД DB2 на платформах Unix и Windows, отчасти благодаря покупке фирмы Informix, занимавшей в рейтинге 2000 г. третье место (3%). DB2 является основным, но не единственным продуктом IBM, относящимся к бизнесу баз данных. Если же принимать во внимание только реляционные СУБД, то фирма Oracle сохраняет лидерство. IBM и Oracle вместе владеют более 70% рынка, и эта цифра немного увеличивается с каждым годом. Стабильно увеличивается доля Microsoft, но, как правило, не за счет IBM и Oracle. Доля же всех остальных производителей ежегодно уменьшается.

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

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

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

1. Революционный переход к объектно-ориентированным СУБД.
2. Эклектическое соединение свойств реляционных и объектно-ориентированных СУБД.
3. Создание новых концепций, системно интегрирующих объектно-ориентированные и реляционные свойства.

Язык SQL - Structured Query Language - был разработан в 1974 г. в ходе работы над System R. В период становления технологий баз данных SQL был не единственным и, возможно, не самым лучшим языком запросов реляционных баз данных, но со временем стал де-факто и де-юре стандартом в этой области. Более того, в настоящее время даже некоторые нереляционные программные продукты предоставляют пользователям интерфейс SQL для обращения к данным. Такая "победа" языка SQL обусловлена, во-первых, ориентацией на него первых и ведущих производителей коммерческих СУБД, во-вторых, тем, что уже в своей версии для System R он был достаточно хорошо развит не только как язык запросов, но и обеспечивал в полном объеме описание и управление данными. Коммерческие продукты далеко не сразу обеспечили свойства исходной версии SQL в полном объеме.

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

В соответствии с требованиями к современным СУБД, сформулированным в начале этой главы, мы считаем, что язык SQL состоит из трех подмножеств:

• языка определения данных;
• языка манипулирования данными;
• языка управления данными.

Первым двум подмножествам посвящены соответственно главы 2 и 3 нашего пособия. Различия в диалектах разных СУБД для этих подмножеств незначительны. Язык управления данными более подвержен диалектным различиям. В остальных главах пособия мы рассматриваем некоторые наиболее общие возможности этого подмножества SQL.

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

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