Эволюция баз данных

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

Одной из первых и наиболее известной сетевой СУБД стала IDMS – интегрированная система управления базами данных, соз-

32

данная компанией Cullinet, основанной Ч. Бахманом. Пик популярности сетевых СУБД пришелся на конец 1970-х гг. (табл. 6). Благодаря своей высокой выразительности сетевая модель стала очень популярной среди отечественных разработчиков, создавших целый ряд сетевых СУБД.

2.6. Реляционные базы данных

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

(Edgar Codd). Работая в компании IBM,

он в 1970 г. опубликовал статью о реляционной модели данных для больших банков данных, предназначенных для совместного использования [22]. Кодд стал прародителем современной технологии хранилищ данных. В 1981 г. он был удостоен Тьюринговской премии.

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

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

33

9). Первая таблица содержит данные о работниках, вторая – об отделах, третья – о связи между работниками и отделами (напомним, что в иерархической модели для хранения этой связи экземпляры сегментов «вкладывались» друг в друга).

Первой реляционной СУБД стала System R, созданная в середине 1970-х гг. в рамках исследовательского проекта IBM. Несмотря на то, что в основу ее разработки легли идеи Кодда, он не участвовал в этом проекте. Для работы с данными был создан специаль-

ный язык SEQUEL (Structured English QUEry Language, англ., струк-

турированный английский язык запросов). Согласно непроверенным сведениям, слово «SEQUEL» в то время являлось торговой маркой английской авиакомпании, вследствие чего язык был пере-

именован в SQL (Structured Query Language, англ.)11.

11В программистской среде до сих пор можно услышать «сикуэл», а не «эс- ку-эль».

34

При создании SQL разработчики System R достаточно вольно трактовали положения реляционной теории. Будучи в оппозиции, Кодд покинул IBM и вместе с программистом Крисом Дейтом (Christopher J. Date) основал независимую консалтинговую компанию, где они продолжили работу над реляционной моделью. По сегодняшний день, читая книги Дейта [1], можно почувствовать его критическую позицию по отношению ко многим допущениям SQL (например, о допустимости значения NULL).

Тем не менее, SQL стал первым языком, реализующим реляционный подход к структурированию данных. Первый официальный стандарт языка SQL – SQL-86 был принят в 1986 г. Американским национальным институтом стандартов (ANSI, American National Standards Institute) и одобрен Международной организацией по стандартизации (ISO, International Standardization Organization). За-

тем появились его модификации SQL-89, SQL-92 (или SQL2), SQL1999 (SQL3), SQL-2003, SQL-2006, SQL-2008. Полное официальное описание SQL содержится в девяти стандартах серии ISO/IEC 9075:2008. Information technology – Database languages – SQL.

System R была исследовательским проектом, а коммерциализация реляционной технологии произошла благодаря двум другим разработкам – Ingres и Oracle. Разработка СУБД Ingres велась в Калифорнийском университете параллельно System R и поддерживалась военными ведомствами США. Ingres стала «полигоном» для отработки технологий, реализованных позднее в Sybase, Informix и MS SQL Server. После коммерциализации Ingres группа разработчиков из Калифорнийского университета приступила к созданию на ее основе новой СУБД Postgres (Post Ingres), вышедшей в 1995 г.

Наибольшее влияние на коммерческое распространение реляционной модели оказала СУБД Oracle, выпущенная компанией Relational Software, Inc. (ныне Oracle Corporation) в 1979 г. (табл. 10). IBM также участвовала в конкурентной борьбе, выпустив в 1982 г. реляционную СУБД DB2.

Следующий исторический шаг в развитии реляционных баз данных сделала компания Sybase, выпустив в 1987 г. Sybase SQL Server, предназначенный для построения высокопроизводительной клиент-серверной архитектуры. С 1988 по 1996 гг. Sybase сотрудничала с Microsoft, при этом практически один и тот же продукт выпускался под двумя названиями Sybase SQL Server и Microsoft

35

SQL Server. К середине 1990-х гг. формируется «большая тройка» производителей СУБД: Sybase-Oracle-Informix.

История реляционных СУБД для микро-ЭВМ началась с dBASE II. Она была создана на базе никому не известной СУБД Vulcan, работавшей под CP/M. Римская цифра II по замыслу менеджеров компании должна была подчеркнуть, что данный продукт является более продвинутым и устойчивым, чем никогда не существовавшая dBASE I (аналогичный маркетинговый ход был сделан и менеджерами Oracle). Основным вкладом этой СУБД в историю баз данных стал новый формат .dbf, который затем использовался целым поколением разработчиков. Этот формат был предназначен для хранения одного отношения вместе с названиями и форматами его полей. Несмотря на то, что записи в файле .dbf имели фиксированную длину, допускалось создание полей неопределенной длины

– такие поля хранились в отдельном файле с расширением .dbt или .fpt. Этот формат подхватили другие фирмы, создавшие dBaseподобные языки и СУБД, такие как FoxBase, Paradox, Clipper.

12Современный далеко не полный список составляет более 100 наименований, а перечислить все реляционные СУБД, созданные более чем за 30 лет, просто невозможно. В таблице приведены только те СУБД, которые оказали существенное влияние на историю, в том числе и отечественную.

36

37

2.7. Уроки истории и перспективы

Анализ истории структур данных показывает, что, пройдя через очень замысловатые модели, мир в итоге пришел к самой простой двумерной табличной форме представления, основанной на строгом математическом аппарате теории множеств и логики первого порядка. Реляционная модель является простой, однако с ее помощью можно реализовать схему данных любой сложности – и сетевую, и иерархическую. Строго говоря, все эти модели данных отличаются друг от друга только способом физического расположения записей и хранения информации о связях между ними. История знает случаи, когда модель, которая на логическом уровне выглядит как сетевая, на физическом уровне реализовывалась в реляционном виде (табл. 11).

38

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

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

1)частичный возврат к структурам данных с навигационными механизмами, большим количеством перекрестных ссылок, индексов и словарей;

2)еще большее упрощение реляционной структуры, когда несколько связанных на логическом уровне отношений сливаются в одно, называемое «многомерным кубом» (dimensional model);

3)применение объектно-ориентированного подхода к хранению данных, смешиваемого иногда с реляционным – так называемый объектно-реляционный подход.

39

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

2.8. Многомерные хранилища данных

В1993 г. Э. Кодд публикует отчет [23], в котором показывает, что реляционная концепция недостаточно приспособлена к задачам интеллектуальной обработки данных. Так, существующая на предприятиях информация отражает самые разные стороны его функционирования – финансы, структуру, проекты, заказы и др. Иначе говоря, информационная модель предприятия (как и любой предметной области) многомерна по своей природе, а любой серьезный анализ, как правило, затрагивает многие из этих «измерений».

Вданной работе Кодд предлагает концепцию оперативной ана-

литической обработки данных (On-Line Analytical Processing, OLAP, англ.), основанную на многомерном представлении данных. Для такого представления необходимо, чтобы предметная область описывалась схемами, напоминающими звезду или снежинку. В таких схемах выделяется одно базовое отношение, с которым связаны несколько вспомогательных. Базовое отношение чаще всего содержит описание каких-либо фактов или событий предметной области, например, ПРОДАЖА ТОВАРА (табл. 12). Из-за этого базовое отношение часто называют таблицей фактов. Вспомогательными отношениями являются таблицы, «расшифровывающие» отдельные элементы фактов, например, МАГАЗИН, ДАТА, ТОВАР. Такие таблицы могут содержать как справочную, так и оперативную информацию и называются таблицами измерений (табл. 13–15). Эти таблицы в свою очередь могут быть окружены своими вспомогательными таблицами – такая схема называется снежинкой (рис. 19). Если дело ограничивается только одним уровнем вспомогательных таблиц, то схема называется звездой.

Звездообразная схема образует многомерное информационное пространство или многомерный куб 13. Координатными осями или измерениями этого пространства являются вспомогательные табли-

цы. В нашем случае имеем трехмерное пространство с измерениями МАГАЗИН, ДАТА и ТОВАР14 (рис. 20). По каждой оси откладыва-

13Другие названия – многомерный массив данных, инфокуб, гиперкуб.

14Для простоты таблицы ПРОИЗВОДИТЕЛЬ и КАТЕГОРИЯ не рассматриваются, а наименования производителя и категории указаны непосредственно в таблице ТОВАР.

40