Сервер баз данных Borland InterBase

Активное ядро
Триггеры и хранимые процедуры
Механизм 2PC
Сигнализаторы событий
Строгие правила
Домены
Генераторы
BLOB-массивы
Русский язык

Borland InterClient

История создания Borland InterBase SQL Server

За два с половиной года, пока Borland Delphi завоевывал по всему миру сердца почти миллиона разработчиков (я уж не говорю об армии "партизан", пользующихся пиратскими версиями), существенно прибыло и пользователей сервера баз данных InterBase. Каждый пользователь Delphi получает в свое распоряжение его версию для платформы Windows. Практически половина из них - корпоративные разработчики, ориентирующиеся на версию Delphi Client/Server, включающую однопользовательский вариант Local InterBase и полнофункциональный многопользовательский сервер (сейчас это Borland InterBase 4.2 for Windows 95 & NT). Сервером InterBase комплектуются и другие инструментальные пакеты: IntraBuilder и Borland C++Builder, по праву называемый "Delphi для Cи++", а также продукт компании Corel Paradox Client/Server. По разным оценкам, 20-25% пользователей перечисленных программных средств применяют в своей работе сервер InterBase. Что же представляет собой InterBase и почему пользователи так неравнодушны к "маленькому, но лучше всего охраняемому секрету индустрии баз данных" ("InterBase Evolves", Martin Rennhackkamp, Product Review Server Side, DBMS Magazine, July 1996)?

"Маленький" секрет большой индустрии

За свою 12-летнюю историю InterBase всегда внедряли там, где осваивали новые технологии реляционных СУБД. Развитие этого продукта шло следующими этапами:

1985-появление InterBase на свет; уже есть поддержка больших двоичных данных (BLOB), многомерных массивов (Arrays), определяемых пользователем функций (UDF), генераторов, множественных поколений данных и метаданных (MGA);

1986 - введены Sparse Bit Mapped Indexes, сигнализаторы событий;

1988 - добавлен Shadowing;

1989 - добавление Domain;

1990-введена возможность двухфазного подтверждения транзакций (2 Phase Commit), исключительные ситуации, обновляемые виды, двунаправленные курсоры;

1993 - введена поддержка многоязыковых таблиц БД.

Сегодня сервер баз данных Borland InterBase функционирует более чем на 15 платформах (см. табл. 1), поддерживает симметричную мультипроцессорную обработку (SMP) для таких платформ, как Solaris 2.4/2.5, HP-UX 10.01, AIX 4.1.x (PowerPC), AIX 3.2.x/4.1.x (RS/6000), SGI IRIX 5.3, DG/UX, 3.10/3.2c/4.11 (88K), NCR 2.03 и SCO Open Server 5.0. При этом InterBase корректно работает на всех этих платформах, базируется на стандарте ANSI SQL 92 и поддерживает UNICODE & Cyrillic (DOS866, Win1251, UNIX).

Файлы баз данных InterBase строятся по принципу черных ящиков (black box), т. е. в одном файле хранятся метаданные (описание структуры БД), сами данные, индексы, хранимые процедуры, большие двоичные объекты (BLOB) и т. п. Архитектура множественных поколений записей MGA (Multi-Generational Architecture) предлагает решение одной из наиболее насущных проблем RDBMS - проблемы блокирования доступа к данным. Встроенный в InterBase механизм многоверсионности данных предотвращает блокировки по чтению. При старте транзакций чтения и записи создаются "снимки" БД, которые освобождаются по мере завершения (отката) соответствующих транзакций. Соответственно освободившееся после их использования пространство может быть использовано для хранения новых данных или их версий. Для обеспечения оптимального заполнения освободившегося пространства в InterBase есть дополнительный механизм "сборки мусора" (garbage collection). Он также берет на себя функции очистки пространства, занятого под версии записей, оставшихся после отката транзакций. Поскольку операции удаления записей могут быть отменены, вместо физического удаления записей сервер InterBase лишь помечает их как удаленные. Важно отметить, что следующая транзакция, стартовавшая после освобождения ненужных версий, выполняет не только возложенные на нее функции, но и запускает механизмы сборки мусора, оставшегося после предыдущих транзакций.

Обсуждение многоверсионности может превратиться в целую монографию. Подход, предлагаемый InterBase, до сих пор остается уникальным, несмотря на свой солидный возраст. Поскольку эта тема слишком велика, отмечу лишь, что технология "безблокировочного чтения" на основе многоверсионного ядра позволяет обеспечить согласованность данных и быстрое восстановление при сбоях. Это возможно благодаря тому, что исчезает необходимость в хранении и поддержании журнальных файлов. Кстати, при активном блокировочном доступе их размер может составлять до 10% от размера всех баз данных.

Говоря о MGA, вспомним, что для реализации систем поддержки принятия решений (DSS-Decision Support Systems) и анализа данных в режиме реального времени (OLAP), необходимо обеспечивать непротиворечивость данных для достаточно длительных (по сравнению с операциями добавления данных) транзакций на фоне обновления БД. Именно в таких сложных задачах InterBase и проявил себя особенно хорошо: на Бостонской бирже, в проекте Magnavox в вооруженных силах США и т. п. Во многом из-за таких возможностей ограничение на ввоз InterBase в бывший СССР было снято одним из последних.

Использование MGA обеспечивает и такие положительные "побочные" эффекты, как возможность резервного архивирования данных (backup) без останова сервера и отключения пользователей. Не это ли действительно работа "24 часа в день, 7 дней в неделю и 365 дней в году"? Особенно на фоне быстрого восстановления БД без вмешательства администратора баз данных.

Технология MGA не остановилась в развитии. Одним из важных расширений, введенных в последней версии InterBase 4.2, является возможность изменения метаданных без останова сервера, т. н. применение многоверсионности не только к данным, но и метаданным.

Какие секреты раскрывает InterBase?

Активное ядро

Один из секретов - активное ядро. InterBase (1985г.!) изначально создавался как сервер с активным ядром - заметим, еще до реального признания SQL в качестве полнофункционального стандарта. Для придания динамичности в InterBase использовался специально разработанный язык GDML, так как возможностей SQL не хватало, а процедурные расширения были лишь экспериментами. Однако с развитием SQL, и особенно SQL-92, стало возможным применить и для него уже отработанные механизмы активного ядра.

Триггеры и хранимые процедуры

InterBase не ограничивает разработчиков при использовании таких процедурных расширений, как триггеры, и позволяет применять в их теле функции, определяемые пользователем, - UDF (Users Defined Functions). Возможность создания UDF является чрезвычайно мощным средством обеспечения высокопроизводительных расширений функциональности. Представляя собой динамические библиотеки (DDL в случае Windows), линкуемые к ядру сервера InterBase, UDF обеспечивают максимально высокую производительность.Обычно UDF создаются на так называемых host-языках. Как правило, для обеспечения лучшей переносимости кода между платформами используется язык Cи. Очевидно, что в качестве родного средства для написания UDF может выступать всякий компилируемый язык. В качестве доказательства этого читатель может найти в Internet большое количество библиотек, созданных на Delphi. Среди российских разработок отметим пакет UDFDemo - Tech yourself UDF programming in 21 minutes, подготовленный Олегом Кукарцевым.

Для полной переносимости требуется, чтобы и расширения были переносимы. При всей популярности Cи с этой задачей он не очень-то справляется. Напрашивается вопрос: не Java ли будет следующим шагом? Говорить об этом пока рано. Лучше подождем следующей версии InterBase, благо версия 4.5 уже готовится к выпуску.

Механизм 2PC

Механизм 2PC (Two Phase Commit) - двухфазная фиксация транзакций - предназначен для автоматического контроля транзакций, задействующих несколько баз данных. Например, если при попытке закрепления (commit) завершенной транзакции хотя бы одна база данных генерирует исключительную ситуацию - Exceptions (исключительные ситуации также поддерживаются InterBase) или не может произвести действия в рамках этой транзакции, то все операции, произошедшие во время транзакции, отменяются или откатываются (rollback) для всех задействованных в ней базах данных.

Сигнализаторы событий

Существует и запатентованный секрет - сигнализаторы событий (event alerters), часто называемые уведомителями. Представим себе следующую задачу: необходимо контролировать критический производственный процесс, обеспечивая сбор и анализ телеметрических данных, постоянно отслеживая величину факторов риска. Что предлагают для решения таких задач традиционные РСУБД? Постоянно опрашивать необходимые столбцы таблиц, чтобы знать о выполнении определенных условий, или ограничиться выполнением конструкций в рамках языка манипулирования данными (Data Manipulation Language). Но как поставить в известность пользователя о наступлении неблагоприятных факторов? В данном случае поставщики серверов баз данных предпочитают переложить груз проблем на разработчиков. А применение сигнализаторов событий обеспечивает выполнение клиентских косвенно вызываемых функций (callback) по наступлении описанных метаданными событий, на которые тот или иной пользователь "подписан".

Рассмотрим следующее правило, реализованное как триггер:

SET TERM !! ;
CREATE TRIGGER POST_NEW_ORDER FOR SALES
AFTER INSERT AS
BEGIN
        POST_EVENT "new_order";
END !!
SET TERM ; !!

Оно срабатывает при введении нового заказа в БД и извещает пользовательские приложения, зарегистрировавшие свои callback-функции посредством вызовов специальных функций клиентского API InterBase. События могут организовывать очередь. Для обработки очередей событий InterBase также предоставляет специальный API.

Строгие правила

Динамичность и активное ядро - прекрасные средства. Но они померкли бы, если бы в InterBase не было строгих правил декларативной поддержки ссылочной целостности. Такие правила в InterBase присутствуют на уровне SQL-92 Entry Level (входной уровень). Так называемые Integrity constraints поддерживают SQL-конструкции PRIMARY KEY, UNIQUE, FOREIGN KEY. Разрешаются атрибуты NOT NULL, значения по умолчанию и определения, среди которых могут быть даже определения CHARACTER SET и CHECK. Некоторые перечисленные правила используются при определении таблицы в следующем примере:

CREATE TABLE JOB
        (JOB_CODE JOBCODE NOT NULL,
        JOB_GRADE JOBGRADE NOT NULL,
        JOB_COUNTRY COUNTRYNAME NOT NULL,
        JOB_TITLE VARCHAR(25) NOT NULL,
        MIN_SALARY SALARY NOT NULL,
        MAX_SALARY SALARY NOT NULL,
        JOB_REQUIREMENT BLOB(400,1),
        LANGUAGE_REQ VARCHAR(15) [5],
        PRIMARY KEY (JOB_CODE, JOB_GRADE, JOB_COUNTRY),
        FOREIGN KEY (JOB_COUNTRY) REFERENCES COUNTRY (COUNTRY),
        CHECK (MIN_SALARY < MAX_SALARY));

Домены

Краеугольным камнем грамотного описания структуры данных в InterBase является понятие домена (domain), абстрактно определяющего столбец таблицы базы данных. Домены чем-то напоминают шаблоны, по которым описываются столбцы конкретных таблиц. Причем эти шаблоны могут включать проверки not NULL и другие ограничения. Поддержка доменов в InterBase соответствует стандарту ANSI SQL-92 и по сравнению с другими серверами баз данных является более чем уникальной. Введенные в язык описания данных DDL сервера InterBase еще в 1989 г., домены до сих пор полностью соответствуют концепции, предложенной Коддом (Codd). В некоторых РСУБД домены просто отсутствуют. Мнение же Кодда на этот счет однозначно: "3/4без адекватной поддержки целостности, которая невозможна без доменов, поставщики РСУБД заставляют потребителей неоправданно рисковать".

В InterBase синтаксис определения характеристик доменов весьма развит:

 = {
VALUE   
| VALUE [NOT] BETWEEN  AND  
| VALUE [NOT] LIKE  [ESCAPE ] 
| VALUE [NOT] IN ( [,  ...]) 
| VALUE IS [NOT] NULL 
| VALUE [NOT] CONTAINING  
| VALUE [NOT] STARTING [WITH] 
| ()
| NOT 
|  OR 
|  AND 
}

, где

 = {= | < | > | <= | >= | !< | !> | <> | !=}

Вот пример описания домена:

CREATE DOMAIN CUSTNO
        AS INTEGER
        DEFAULT 9999
        CHECK (VALUE > 1000);

Генераторы

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

CREATE GENERATOR EMPNO_GEN;
SET TERM !! ;
CREATE TRIGGER CREATE_EMPNO FOR EMPLOYEES
        BEFORE INSERT
                POSITION 0
        AS BEGIN
                NEW.EMPNO = GEN_ID(EMPNO_GEN, 1); 
        END
SET TERM ; !!

BLOB-массивы

Для работы с неструктурированными данными в InterBase впервые были введены большие двоичные объекты - BLOB и массивы (arrays) до 16 размерностей. InterBase поддерживает пользовательские типы BLOB. Для организации автоматической конвертации BLOB-массивов из одного формата в другой предназначены специальные так называемые BLOB-фильтры. Более того, через определяемые пользователем функции (UDF) можно реализовать дополнительные функции обработки, например поисковые, кроме предопределенных операций чтения и записи.

Русский язык

Что всегда интересует отечественного пользователя ПО, так это поддержка русского языка. InterBase обеспечивает работу с кодировками DOS866, Win1251 и Unix-кодировкой, позволяя назначать разным столбцам одной и той же таблицы БД разные последовательности символов и правила сортировки (character sets & collation orders).

Программы и утилиты InterBase

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

Помогают также и программы для командной строки:

Для создания клиентских приложений имеются средства, обеспечивающие прямой доступ к InterBase (поставляются как Borland, так и другими компаниями):

Из CASE-инструментов, поддерживающих InterBase, особо отметим PowerSoft PowerDesignor (ранее называвшийся S-Designor), Embarsadero ER/1, Popkin Software System Architect, CSA SilverRun и LogicWorks ErWin 2.6. В большинстве случаев доступ к InterBase осуществляется из этих средств с помощью интерфейса ODBC. Один из 32-разрядных ODBC-драйверов, соответствующий спецификации ODBC 2.5, разработан для InterBase компанией Visigenic Software и поставляется вместе с InterBase 4.2 для ОС Windows 95 & NT.

Продукты самой компании Borland основаны на механизме доступа BDE (Borland DataBase Engine). А последние версии таких продуктов, как Delphi, включают специальные средства, позволяющие работать с метаданными и осуществлять мониторинг SQL-запросов для их оптимизации.

Заключение

В мире компьютерного бизнеса часто складываются ситуации, когда та или иная компания хочет подхлестнуть развитие технологии или продукта, предоставив разработчикам больше самостоятельности и возможностей реагировать на требования рынка. В этом случае линия продуктов выносится в специально создаваемую дочернюю фирму (subsidiary company). Акцентируя внимание на серверных технологиях, Borland International организовала специальную компанию, одноименную с сервером баз данных InterBase. По многим англоязычным телеконференциям прошло открытое письмо ее президента Джима Вейла (Jim Weil), в котором он пишет: "Мы думаем, что возможности применения Java будут существенно расширяться3/4 мы планируем сделать поддержку Java важной частью нашей стратегии3/4 наравне с дальнейшим развитием функциональных возможностей сервера и традиционным акцентом на высокую производительность и надежность обработки данных" (30 апреля 1997г.).

Я думаю, что готовящаяся к выпуску версия InterBase 4.5 будет содержать много существенных нововведений (почаще заглядывайте на www. borland.com!).

Borland InterClient

Сейчас все мы наблюдаем уже не только бурные дискуссии, но и вполне реальные попытки внедрения Internet/Intranet-технологий в корпоративные среды. В сложившейся ситуации все более важную роль играет возможность доступа к серверам баз данных из Java. Компания JavaSoft (дочернее предприятие Sun) уделяет большое внимание и доступу к базам данных с помощью интерфейса API JDBC (Java DataBase Connectivity), позволяющего разработчикам создавать Java-код, не зависящий от конкретного сервера баз данных. Это обеспечивает хорошую масштабируемость систем, как вертикальную (миграция на более надежную и/или функциональную ОС, более мощный сервер БД), так и горизонтальную (переход на другой сервер БД, имеющий специфические механизмы).

Общепризнанной концепцией организации универсального доступа к БД, применяемой в ODBC, BDE и т. п., является драйверная архитектура. Каждый драйвер транслирует вызовы универсального API во внутренние (native) вызовы API сервера баз данных. При этом драйверы регистрируются в базе специального менеджера, загружающего их по мере обращений к определенным пользователем псевдонимам (aliases) соединений, которые идентифицируют базы данных и настройки характеристик доступа к ним, например объем кэша, транслитерацию и т. п.

JDBC также основывается на концепции драйверов и предоставляет доступ и управление ими с помощью JDBC Driver Manager.

Необходимо отметить, что JDBC описывает лишь Java-интерфейсы. А JDBC-драйверы, в свою очередь, являются реализацией этих интерфейсов в виде конкретных классов. Обращения из кода, написанного на Java, в действительности восходят к экземплярам классов.

При непосредственной работе с БД используется язык запросов SQL. Из этого следует, что непременным условием соответствия драйвера спецификации JDBC на сегодня является поддержка входного уровня (entry level) стандарта ANSI SQL-92.

Возможно несколько способов реализации JDBC-драйверов для доступа к серверам баз данных:

- посредством моста JDBC-ODBC; явный недостаток такого подхода - появление далеко не самого производительного промежуточного звена, функционирующего только под управлением Windows;

- с использованием JDBC-серверов; такие серверы функционируют "рядом" с сервером баз данных, общаясь с последним на уровне внутренних (native) вызовов, что обеспечивает максимально высокую производительность. При этом взаимодействие с клиентской частью, например с Java-аплетом, осуществляется через протокол TCP/IP, гарантируя независимость от платформы (или, не дай бог, установленного service pack) Java-кода.

Конечно, полностью отбрасывать первый вариант нельзя, так как доступ ко многим источникам данных иначе как через ODBC просто не возможен. Однако второй вариант выглядит более перспективным как с точки зрения производительности, так и с точки зрения развития Java вообще. Интересным средством доступа является Java DataDirect, подробную информацию о котором можно найти на Web-сервере компании JavaSoft (http://www.javasoft.com).

Так как сервер InterBase является многоплатформенным и используется с клиентскими приложениями, функционирующими не только под управлением Windows, то Java-доступ к InterBase основывается на концепции сервера JDBC под названием Borland InterClient for InterBase. Серверная составляющая этого продукта соответственно называется InterServer.

Рассмотрим, каким же образом должна быть сконфигурирована машина пользователя, которому необходим Java-доступ к InterBase. Если клиентское приложение, использующее InterClient, является аплетом, загружаемым по сети при открытии соответствующей HTML-страницы, InterClient package (упаковка, содержащая классы, реализующие JDBC-доступ) загружается на клиентскую машину автоматически. При этом клиентское место должно иметь установленную виртуальную машину Java с библиотекой базовых классов Java и инсталлированным JDBC Driver Manager.

Если клиент является самостоятельным (stand-alone) Java-приложением, то необходимо добавить установку InterClient package.

При запуске серверной части InterServer под Windows 95 или NT доступ к его настройкам можно осуществить аналогично InterBase, т. е. через соответствующую пиктограмму InterServer, располагающуюся в правой части панели задач Windows (рядом с часами) или напрямую через группу Borland InterClient.

Для проверки возможности установления связи с InterBase через InterClient предназначены диагностические Java-приложение и аплет InterClient Communication Diagnostic.

В состав InterClient также входит полная справочная документация в формате HTML: описание содержимого InterClient package, построенное в соответствии с требованиями к Java-документации, и описание InterClient Installation and Configuration в варианте для Windows 95/NT в формате Windows Help.

Ознакомиться с бета-версией (0.90) InterClient для платформ Sun Solaris и Windows 95/NT можно свободно, обратившись на Web-сервер Borland (http://www.borland.com).

История создания Borland InterBase SQL Server

InterBase SQL Server был создан фирмой Interbase Software Corporation (ISC). Когда предложения сотрудника DEC Джеймса Старки (James Starkey) расширить возможности RDB были отвергнуты фирмой, он создал собственную компанию, разработавшую собственную реляционную систему управления базами данных, первоначальное название которой было Groton Database System (GDS).

Во время существования ISC дистрибуцией InterBase (тогда продукт еще назывался StarBase) занималась фирма Cognos Inc. Эта компания и до настоящего времени является одной из основных фирм, оказывающих техническую поддержку InterBase. Позднее фирма ISC перешла в руки Borland.

При создании и развитии InterBase SQL Server было использовано большое количество нетрадиционных решений и новых технологий: UDF - определяемые пользователем функции. Расширяемость SQL-сервера достигнута не за счет увеличения количества нестандартных встроенных функций или реализации сложного встроенного языка программирования, а с помощью внешних модулей, создаваемых на компилируемых языках 3GL (изначально Cи и в настоящий момент Delphi). Поля типа "массив" разработаны по просьбе анонимной самолетостроительной компании (район Сиэтла). По техническому заданию компании требовалось хранить в БД данные, получаемые единовременно с большого количества датчиков, и обрабатывать эти данные по горизонтали и по вертикали. Сейчас этой уникальной возможностью InterBase SQL Server с успехом пользуются самолетостроительные, исследовательские компании и финансовые биржи. Каскадные триггеры позволяют разбивать на отдельные части логику обработки вставки, изменения и удаления записей. Фактически каскадные триггеры реализуют "процедурное программирование" обработки данных, допуская изменение порядка выполнения триггеров и отключение/включение триггеров "на ходу". Фильтры полей типа BLOB - пользовательские процедуры (UDF), подсоединяемые к операциям чтения и записи данных в поля BLOB, позволяют осуществлять преобразование данных "на ходу", упаковку/сжатие данных и т. д. Для каждого подтипа BLOB могут быть написаны свои фильтры. У термина BLOB есть своя забавная история. Вот что рассказывает тот же Дж. Старки:

"Барри Рабинсон, мой босс в DEC, ходил кругами и бубнил: "BLOBы, BLOBы, у нас должны быть BLOBы". Когда я спросил, что это такое, он ответил, что именно я являюсь архитектором и сам должен знать об этом.

Бездельничая в Колорадо-Спрингс (из-за снежных заносов я не мог выехать на работу ), я решил заняться BLOBами. Тут-то я и понял, что за штука такая - BLOB.

Ребята, занимавшиеся Rdb/VMS, объявили созданным мною BLOBам войну - во-первых, они сказали, что никогда не потеряют в продажах из-за отсутствия BLOB. Во-вторых, документы и графика не являются частью БД и должны храниться в отдельных файлах. В третьих, если даже нужно хранить документ в БД, то его надо разбить на строки и хранить именно таким образом.

BLOBы были переименованы в "сегментированные строки" и все-таки стали частью DSRI.

Намного позже менеджер по маркетингу Apollo Терри Маккивер влюбилась в концепцию BLOB, но решила, что это слово должно как-то расшифровываться. В первом варианте это было "basic large objects". Но Apollo не закрепило за собой право на такую "расшифровку", и она привлекла внимание (я думаю) Informix: было объявлено, что в будущем Informix будет поддерживать "binary large objects". И началось ...

Кто-то спросил у менеджера по продуктам DEC о том, будут ли поддерживаться BLOB. Ответ был такой - "когда-нибудь в будущем". А между тем группа разработчиков уже была в курсе BLOB.

Ashton Tate купила InterBase, Borland купил Ashton Tate, и расшифровываемый термин BLOB начал использоваться повсюду. Вот так".

Сигнализаторы событий - концепция "активного сервера", уведомляющего клиентов о наступлении события. Клиент не должен ожидать события от сервера, а должен "подписаться" на уведомление. Когда событие произойдет, сервер сам уведомит подписанного на это событие клиента (патент # 5.592.664). Первая коммерческая реализация двухфазного подтверждения транзакций (2PC), полное соответствие entry level ANSI SQL-92 - похоже, что ни один коммерческий SQL-сервер не соответствует данному стандарту. Безусловно, такие серверы имеют собственные расширения, и, например, части из intermediate level и даже full level, но полностью entry level они не соответствуют. Механизм генераторов уникальных чисел - независимый от транзакций и данных в таблицах механизм, позволяющий пользователям получать гарантированно уникальные идентификаторы. Множественные поколения записей - обеспечение уровней изоляции пользователей, блокировки на уровне записи, гарантия отсутствия блокировок по чтению, быстрое восстановление БД при сбоях (отсутствие лога отката), обеспечение производительности OLAP и DSS транзакций.