Двуликая база данных

We use cookies. Read the Privacy and Cookie Policy

Двуликая база данных

Говоря о базе данных, мы имеем в виду не просто некоторое место для размещения данных. Мы говорим о системе управления базой данных. СУБД — среда для хранения и выборки данных, включающая определения данных, правила обеспечения их целостности и механизмы поддержания, а также операции сохранения и выборки данных. СУБД должна иметь интерфейс, чтобы пользователи могли работать с ней. В этом разделе мы представим два интерфейса СУБД 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 — строка и столбец (чтобы отразить концепцию таблицы).