Об эволюции и многообразии моделей данных

Известно много моделей данных. Некоторые из них уже рассматривались выше. Родословная моделей данных представлена на Рис. 3.

Рис. 3. Родословная моделей данных

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

Управление ассоциативным доступом и обработкой, ориентированной на наборы, было настолько распространено, что в сообществе COBOL выделилась группа Data Base Task Group (DBTG) для определения стандартного способа спецификации таких данных и доступа к ним. Чарльз Бахман (Charles Bachman) в GE (General Electric) построил прототип системы навигации по данным. За руководство работы DBTG, разработавшей стандартный язык определения данных и манипулирования данными, Бахман получил Тьюринговскую премию. В своей Тьюринговской лекции он описал эволюцию моделей плоских файлов к новому миру, где программы могут осуществлять навигацию между записями, следуя связям между записями. Модель Бахмана напоминает систему Memex Ванневара Буша (Vannevar Bush) или навигационную модель страниц и ссылок сегодняшнего Internet.

В сообществе баз данных COBOL кристаллизовалась концепция схем и независимости данных. Они обозначили потребность в сокрытии физических деталей расположения записей. Программы должны были видеть только логическую организацию записей и связей, так что программы продолжали работать при изменении и развитии способов хранения данных. Записи, поля и связи, не используемые программой, следовало сокрыть – как по соображениям безопасности, так и для того, чтобы изолировать программу от неизбежных изменений схемы базы данных. В этих ранних базах данных поддерживались три вида схем данных: 1) логическая схема, которая определяет глобальный логический проект записей базы данных и связей между записями; 2) физическая схема, описывающая физическое размещение записей базы данных на устройствах памяти и в файлах, а также индексы, нужные для поддержки логических связей; 3) предоставляемая каждому приложению подсхема, раскрывающая только часть логической схемы, которую использует программа. Механизм логических, физических и подсхем обеспечивал независимость данных. И на самом деле, многие программы, написанные в ту эпоху, все еще работают сегодня с использованием той же самой подсхемы, с которой все начиналось, хотя логическая и физическая схемы абсолютно изменились.

К 1980 году сетевые (и иерархические) модели данных, ориентированные на наборы записей, стали очень популярны. Основанная Бахманом компания Cullinet была крупнейшей и наиболее быстро растущей софтверной компанией в мире.

Несмотря на успех сетевой модели данных, многие разработчики программного обеспечения чувствовали, что навигационный программный интерфейс был интерфейсом слишком низкого уровня. Было трудно проектировать и программировать эти базы данных. В статье Э.Ф. (Теда) Кодда (E.F. Codd) 1970 года была обрисована реляционная модель [4], которая казалась альтернативой низкоуровневому навигационному интерфейсу. Идея реляционной модели состоит в том, чтобы единообразно представлять и сущности, и связи. Реляционная модель данных обладала унифицированным языком для определения данных, навигации по данным и манипулирования данными, а не отдельными языками для каждой из этих задач. Еще более важно то, что реляционная алгебра имеет дело со множествами записей (отношениями) как единым целым, применяя операции к множествам записей целиком и производя множества записей в результате. Реляционные модель данных и операции дают возможность получения более коротких и более простых программ для решения задач управления записями. В качестве конкретного примера на рис. 2.d показана база данных авиалиний из предыдущего раздела, представленная в виде пяти таблиц. Вместо неявного хранения связи между рейсами и путешествиями в реляционной системе явно хранится каждая пара рейс-путешествие как запись базы данных.

Реляционная модель обладает некоторыми неожиданными преимуществами, кроме повышения продуктивности программистов и простоты использования. Реляционная модель оказалась хорошо пригодной к использованию в архитектуре клиент-сервер, к параллельной обработке и графическим пользовательским интерфейсам. Приложение клиент-сервер разбивается на две части. Клиентская часть отвечает за поддержку ввода и представление выводных данных для пользователя или клиентского устройства. Сервер отвечает за хранение базы данных, обработку клиентских запросов к базе данных, возврат клиенту общего ответа. Реляционный интерфейс особенно удобен для использования в архитектуре клиент-сервер, поскольку приводит к обмену высокоуровневыми запросами и ответами. Высокоуровневый интерфейс SQL минимизирует коммуникации между клиентом и сервером. Сегодня многие клиент-серверные средства строятся на основе протокола Open Database Connectivity (ODBC), который обеспечивает для клиента стандартный механизм запросов высокого уровня к серверу. Парадигма клиент-сервер продолжает развиваться. Как разъясняется в следующем разделе, имеется возрастающая тенденция интеграции процедур в серверах баз данных. В частности, такие процедурные языки, как BASIC и Java, были добавлены к серверам, чтобы клиенты могли вызывать прикладные процедуры, выполняемые на сервере.

Параллельная обработка баз данных была вторым неожиданным преимуществом реляционной модели. Отношения являются однородными множествами записей. Реляционная модель включает набор операций, замкнутых по композиции: каждая операция получает отношения на входе и производит отношение как результат. Поэтому реляционные операции естественным образом предоставляют возможности конвейерного параллелизма путем направления вывода одной операции на вход следующей. Редко удается найти длинные конвейеры, но часто реляционные операции могут быть разделены таким образом, что образуется N клонов каждой операции и каждый клон может работать с одной N-й частью отношения-операнда. Пути применения этих идей были проложены в академическом сообществе и компанией Teradata Corporation (теперь NCR). Сегодня распространенной практикой реляционных систем является стократное увеличение скорости за счет параллелизма. Задачи интеллектуального анализа данных (data mining), для решения которых могли бы потребоваться недели или месяцы поиска в многотерабайтных базах данных, при использовании параллелизма выполняются за часы. Этот параллелизм полностью автоматизирован. Проектировщики только поставляют данные системе баз данных, и сама система разделяет и индексирует данные. Пользователи предоставляют системе запросы (на основе ODBC), и система автоматически обеспечивает параллельный план выполнения запроса и выполняет его.

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

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