Перри сразу же понял, что разработчики System/38 строят очень похожую базу данных, за исключением того, что в ней нет соединения. Он позвонил Кодду, чтобы сообщить о работах в Рочестере и предложить свою поддержку. Но Кодд ответил, что, по его мнению, реляционные базы данных предназначены только для больших систем; а малым нужны только функции сортировки и слияния. По словам Перри, разговор не был сердечным. Тон Кодда он сравнил с тоном полицейских во время перекрестного допроса их защитниками на процессе О. Дж. Симпсона (O. J. Simpson) — вежливый, но холодный. Кодд и Тейлор больше никогда не разговаривали.

Через три года после объявления System/38 база данных System/R была объявлена как DB2 и признана в качестве первой реляционной базы данных[ 51 ]. Так как первоначально System/38 не поддерживала операции соединения, то она считается первой коммерческой базой данных с реляционными возможностями.

Говоря о базе данных, мы имеем в виду не просто некоторое место для размещения данных. Мы говорим о системе управления базой данных. СУБД — среда для хранения и выборки данных, включающая определения данных, правила обеспечения их целостности и механизмы поддержания, а также операции сохранения и выборки данных. СУБД должна иметь интерфейс, чтобы пользователи могли работать с ней. В этом разделе мы представим два интерфейса СУБД AS/400: DDS (Data Description Specifications) и SQL (Structured Query Language), в следующих разделах — детально рассмотрим саму СУБД.

Когда IBM начинала проект System/38, стандартных интерфейсов к реляционной базе данных не существовало. Поэтому проектировщикам пришлось разработать собственный уникальный интерфейс для этой системы. Не удивительно, что этот интерфейс DDS очень похож на файловую систему, которую должен был заменить. Создатели интерфейса ограничились несколькими системными командами и функциями управления базой данных, а также ввели в MI команды для таких операций как чтение, запись, обновление и удаление. Программисты могли непосредственно использовать эти команды из таких языков как RPG и Cobol. Например, многие используют DDS-RPG: DDS для определений данных, RPG для доступа к ним. Интерфейс DDS перешел из System/38 в AS/400, и многие по-прежнему предпочитают его. Бывшим пользователям мэйнфреймов, перешедшим на AS/400, он также нравится, поскольку очень похож на интерфейс базы данных для больших систем IBM — IMS (Information Management System).

Примерно в то же время, когда разрабатывалась AS/400, в IBM и других фирмах выполнялись проекты по стандартизации SQL (из System/R) в качестве языка реляционных баз данных. Проект продвигался не слишком гладко, на создание стандарта потребовалось около десятилетия. Ingres многие годы использовала язык-соперник QUEL, пока, наконец, тоже не поддалась общей тенденции. Появившаяся в 1988 году AS/400 поддерживала и собственный интерфейс DDS, и SQL. Операторы SQL могут включаться непосредственно в программы на RPG, Cobol и С, заменяя «родные» команды, такие как чтение, запись и обновление. Для трансляции этих операторов SQL DB2/400 содержит прекомпиляторы.

При более внимательном взгляде становится видно, что DB2/400 состоит из двух отдельных частей. Собственно СУБД и язык DDS входят в состав OS/400. Query Manager and SQL Development Kit — особый продукт, приобретаемый отдельно. Как следует из названия, этот продукт содержит Query Manager — ПО AS/400 для конечного пользователя, позволяющее выдавать запросы на SQL. В состав продукта входят кроме того интерактивный пользовательский интерфейс к SQL (Interactive SQL), а также прекомпиляторы для различных языков, используемые при вставке операторов SQL в ЯВУ. К несчастью сложилось так, что IBM требует от Вас платить за SQL отдельно, тогда как DDS входит в состав OS/400. Такая ситуация — основная причина непопулярности SQL у многих пользователей AS/400, считающих его внешним продуктом, каковым он на самом деле не является. Сегодня большинство разработчиков баз данных в Рочестере думают в терминах SQL, а не DDS. Интерфейс DDS будет поддерживаться и далее, но новые функции, скорее всего, будут в SQL.

Хотя AS/400 и поддерживает два разных интерфейса к базе данных, крайне важно понимать, что сама база данных только одна. Доступ к данным, определение данных и манипуляции с ними на AS/400 возможны как посредством DDS, так и посредством SQL. Так как интерфейс SQL использует те же команды MI, что и DDS, каждый из интерфейсов может работать с объектами данных, созданных посредством другого интерфейса. Эта возможность смешения двух интерфейсов обеспечивает базе данных AS/400 дополнительные мощь и гибкость.

Самая большая проблема двух интерфейсов состоит в путанице, вызываемой терминологическими различиями. Как и в случае различий имен между объектами OS/ 400 и системными объектами MI, имена для разных интерфейсов базы данных подбирались разными группами. Например, в интерфейсе DDS имеются физические файлы, содержащие данные. Как мы видели ранее, физический файл — это двумерная таблица. В интерфейсе SQL тот же самый физический файл называется таблицей, что больше подходит для этой структуры. Логический файл в интерфейсе DDS не содержит данные, а указывает на реальные данные и дает программе некоторую их проекцию. В SQL логический файл называется проекцией (view). Аналогично, то, что в терминологии DDS — запись и поле, в интерфейсе SQL — строка и столбец (чтобы отразить концепцию таблицы).

В этом разделе мы рассмотрим различные компоненты базы данных AS/400. Я не ставил здесь перед собой задачу проинструктировать Вас, как использовать эту базу данных. Уже есть целый ряд хороших книг, посвященных внешним аспектам базы данных и использованию двух ее интерфейсов в программах[ 52 ]. А я лишь хочу предложить Вам обзор характеристик СУБД и основ ее функционирования.

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

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

определение и описание таблиц базы данных;

операции управления данными (вставка, выборка, обновление и удаление);

возможность определить, что представляют собой данные независимо от программы;

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

множественные проекции данных для разных прикладных программ;

защита данных;

целостность данных.

Теперь посмотрим, как эти функции реализованы в AS/400.