Назад в раздел
Borland Database Engine и IDAPI
Untitled
Borland Database Engine и IDAPI
Обзор технологии
Материал подготовлен в
Демо-центре клиент-серверных
технологий Borland на основе
статьи Pandu Rudraraju из
IDAPI Technology Development
"BDE and IDAPI. A technology
overview"
Введение
--------
Термин IDAPI (Integrated Database API) используется не только для ссылки
на API продукт, но и для ссылки на всю технологию. Название Borland Database
Engine (BDE) используется для описания пакета, состоящего из основной
технологии (которая включает IDAPI инфраструктуру и обработчик запросов)
плюс три IDAPI драйвера (Paradox, dBase и текстовый драйвер) плюс IDAPTER и
в качестве опций один или больше IDAPI SQL драйверов. Термин IDAPI заменил
предшествовавший ему термин ODAPI (Open Database API), который использовался
в ранней реализации этой технологии.
Эволюция технологии IDAPI: 1990-1994
------------------------------------
Проект IDAPI начался в апреле 90-го года. Эта технология впервые
поставлялясь под названием ODAPI для Quattro Pro for Windows 1.0 в сентябре
1992 года. В основном похожий инструмент поставлялся с Paradox for Windows 1.0
в феврале 1993 года. Этот пакет состоял уже из Paradox и dBase драйверов и
обработчика запросов QBE. Это был ODAPI 1.0.
Позднее, в сентябре 1993 года, версия ODAPI 1.1 с SQL драйверами для
InterBase, Oracle и Sybase поставлялась с Paradox for Windows 4.5 и Quattro
Pro for Windows 5.0. Позже, в марте 1994 года появился SQL драйвер для
Informix.
Следующая версия этой технологии - IDAPI 1.2. Эта версия являлась
результатом работы, проделанной техническим комитетом IDAPI ( состоящем из
представителей Borland, IBM, Novell и WordPerfect). Эта реализация включала
множество новых черт, а также дополнительные драйвера, в частности,
IDAPTER, который позволял использовать любой ODBC драйвер как драйвер
IDAPI.
Предыстория
-----------
Чтобы понять основные особенности IDAPI технологии, полезно было бы
понять, как происходили события в мире, связанном с Парадоксом (хотя этот
анализ более-менее применим и к другим СУБД для IBM PC, например DOS dBase
IV). dBase и Paradox становятся популярными СУБД для персональных
компьютеров, потому что они предоставляют среду для разработки приложений к
базам данных, которые объединяют управление данными, доступ к данным,
управление приложениями, а также пользовательский интерфейс для
взаимодействия пользователей. Из опыта работы следуют несколько простых
выводов:
Если желательно получить доступ к данным из какого-либо другого
приложения, разработчику нужно либо преобразовать форматы данных, либо
положиться на какой-либо уже существующий драйвер, который имеет
неизвестно какие характеристики по совместимости.( С этой точки зрения -
хотя бы внутри борландовских продуктов - код для чтения и записи файлов в
формате Парадокс дублировался в четырех различных продуктах. И это кошмар -
держать в соответствии эти коды. С выходом в свет Paradox Engine это число
сократилось до двух - хотя и одного уже много :)
Единственным способом работать с неродными форматами данных было
вначале преобразовывать данные в родной формат, а затем уже манипулировать
ими, используя языки или инструментарий СУБД. В любом случае, когда данные
фактически дублировались неконтролируемым образом (родной формат + неродной),
результатом были только дополнительные проблемы.
Еще хуже были проблемы, когда предстояло модифицировать неродные данные.
Для этого вам предстояло преобразовать данные к неродному виду, а затем
использовать некие другие инструменты для завершения модификации данных.
С того момента, как в фирме Borland задумались о создании следующего
поколения продуктов для работы с базами данных, стало совершенно ясно, что
необходимо выделять доступ к данным в отдельный инструмент. Следующая глава
описывает цели и выводы, которыми фирма Borland руководствовалась при
создании IDAPI и Borland Database Engine.
Цели и причины создания BDE/IDAPI
---------------------------------
Проект BDE/IDAPI начался, преследуя несколько целей. Для того, чтобы
лучше понять IDAPI желательно понять эти цели и причины, поскольку именно
они явились тем базисом, на основе которого принимались те или иные решения
при реализации API или других частей всей системы. Эти цели и причины, наравне
со сделанными базовыми предположениями и допущениями, как они появлялись
при реализации IDAPI, описаны ниже:
- различные языки для описания форматов файлов данных и доступа к данным
При построении следующего поколения систем БД для персональных компьютеров
мы должны выделить язык описания формата данных. Это позволит нам работать
с языком описания приложения и языком описания форматов данных и методов
доступа раздельно. Это - первый шаг для превращения среды БД в открытую
систему. Следовательно - нам нужен database engine (Неудивительно, что
СУБД для мэйфрэймов развиваются похожим образом!). В случае выделения
такого database engine любое количество приложений (в том числе и приложения,
разработанные третьими фирмами) могут иметь доступ к тем же файлам данных без
того, чтобы дублировать методы доступа.
- PC стали инструментом интеграции данных
Теперь, когда почти каждый информационный работник (а все мы используем
информацию тем или иным способом в нашей работе) получил доступ к
персональному компьютеру, PC стала играть роль инструмента интеграции данных.
В то время как информационная технология охватывает все больше и больше
областей год за годом, даже маленькая компания обнаруживает, что необходимые
ей данные распределены по многим системам и зачастую в различных форматах.
Для того, чтобы эффективно работать в этих условиях, требуется, чтобы
каждый работник имел возможность получать данные из множества источников.
Хороший инструмент работы с БД должен сделать это возможным.
- Прямой доступ вместо Импорта/Экспорта
Импорт/экспорт данных больше не приемлем в качестве решения для ежедневного
доступа к данным. Слишком уж много времени тратится на то чтобы безучастно
наблюдать за преобразованием данных из одного формата в другой. А иногда
это даже практически невозможно сделать - что если вы имеете гигабайтную
базу данных? Данные актуальны только в тот момент, когда они копируются и
дублируются. Всегда, когда мы можем избежать ненужного переписывания
данных, мы повышаем актуальность этих данных. Идеальным решением должен быть
доступ только к той порции данных, в которой вы нуждаетесь и только в тот
момент, КОГДА вы в ней нуждаетесь; другими словами, идеальное решение -
прямой доступ.
- Единственный API как для родных, так и для неродных источников данных
Если в таких СУБД, как Paradox for Windows и dBase for Windows надо сделать
доступ к чужим форматам данных таким же простым, как к своим форматам, идеаль-
ным способом достичь этого было бы реализовать единственный API для доступа
данным с любым форматом. Если же этого не сделать, продукт будет выглядеть
"тормозом", когда будет иметь дело с данными в чужом формате (похоже, что
конкурирующие продукты имеют те же проблемы).
Как Paradox for Windows, так и dBase for Windows используют общий IDAPI для
своего доступа к данным. Каждый продукт может иметь какие-то свои преимущества
своего формата данных, но этого вовсе не требуется при работе с различными
форматами. С появлением BDE и IDAPI, мы достигаем цели без потери в
производительности.
- Унификация доступа к персональным и SQL базам данных
В течение последних нескольких лет СУБД выросли в две различные семьи. С
одной стороны есть СУБД для персоналок. Они исторически ориентируются на
ISAM (Index Sequential Acces Method), и язык доступа к данным таких систем
(к примеру dBase) близко соотносится с ISAM-моделью.
Однако базы данных SQL развивались в соответствии с совершенно другой
моделью, использующей API базирующийся на SQL. Необходима унифицированная
модель, если уж мы должны поддерживать оба типа БД естественно и эффективно.
Ни только-SQL, ни только-ISAM типы API не могут объединять естественный и
эффективный доступ к данным этих двух типов БД. Разработчик приложений
должен быть свободен при смешивании и использовании этих типов доступа и
должен быть свободен в выборе лучшего решения для своей задачи.
- Упрощение разработки приложений БД
Если уж необходимо делать выбор между легкостью разработки приложения и
следования стандартам, то следует отдавать предпочтение первому.
- DB Engine должен быть расширяемым
Сегодня форматы dBase и Paradox могут быть превалирующими форматами. Завтра
же в этом качестве может выступить что-то еще. Желательно было бы говорить
о новом формате данных без модификации всей системы. Решением этой проблемы
явлется архитектура, основанная на драйверах. Также желательно было бы
ввести возможность добавлять собственные методы индексации и компрессии
данных в систему.
- Эффективная поддержка среды программирования таких СУБД, как dBase
Одной из существенных целей IDAPI была необходимость поддержки среды
программирования такой, как dBase и PAL в этом API. Это важно для
сохранения сделанных инвестиций в пользовательские приложения для этой
системы. Причем недостаточно просто поддерживать эти среды, необходимо
было сделать их такими же эффективными, как тогда, когда они пользовались
своими методами доступа к только родным данным.
Представим себе, насколько менее успешным было бы внедрение Windows 3.1,
если бы там не было бы поддержки DOS программ. Или какой потенциал был бы у
Chicago, если бы там нельзя было бы запускать Win 3.x и DOS программы так же
хорошо и эффективно, как в своей собственной среде. IDAPI обязан был
преследовать аналогичные цели для Windows-версий Paradox и dBase. Хочется
верить, что эти цели были достигнуты.
- Не только минимально необходимый уровень
Когда принимались решения относительно того, каким должен был быть IDAPI,
был большой соблазн выбрать его архитектуру такой, чтобы покрыть только
наиболее общие черты различных форматов данных. Это НЕ приемлемо. И хорошей
иллюстрацией того, что цель была достигнута, является тот факт, что и
Paradox for Windows и dBase for Windows используют IDAPI при ЛЮБОМ обращении
к данным.
- Поддержка национальных особенностей
В настоящее время более 50 процентов поступлений от продажи программного
обеспечения крупнейших компаний происходят от продаж на интернациональном
рынке. Поэтому критическим становится то время, которое затрачивается на
маркетинг национальных версий. Выпуск вначале американской версии, а затем
затрата нескольких месяцев, чтобы произвести различные национальные версии -
нет, это больше не приемлемо. Database engine должен поддерживать нужды
программистов в разных странах без того, чтобы изготавливать его различные
национальные варианты.
- Сохранение преимуществ персональных БД
Персональные СУБД (например, Paradox или dBase) делают работу с данными
естественной и легкой. IDAPI не должен создавать дополнительных трудностей
или терять эти преимущества. С другой стороны, IDAPI должен попытаться
расширить эту модель взаимодействия также и на серверные БД - и в результате
предоставить лучшее из этих двух миров.
IDAPI и навигационный доступ к данным
-------------------------------------
IDAPI делает упор на навигационном доступе к данным. В данном случае
не будем очень подробно обсуждать тонкости этого метода доступа. Хотя
,конечно, многие имеют в виду разные вещи, говоря о навигационном методе
доступа к данным.
Borland ввел навигационный доступ к БД в ODAPI с реализацией Paradox for
Win Version 1.0. После того, как ODAPI превратился в IDAPI, навигационные
черты были усилены, особенно в отношении SQL драйверов.
Навигационный доступ состоит из набора API, которые содержат в себе browse-
типы операций, используемых в интерактивных приложениях, а также dBase/PAL
типы БД-приложений.
Можно сказать - системы с типом доступа ISAM давно существуют( например,
B-trieve, файловая система VSAM на мэйнфреймах IBM, Paradox Engine - и
каждый имеет свой низкоуровневый API!) - так что же нового в IDAPI?
Основное отличие состоит в том, что IDAPI выделяет основные особенности
этих API в абстракцию курсорной модели, которая эфеективно может быть
наложена на конкретные модели этих API. Интерфейсы IDAPI достаточно богаты
возможностями, чтобы поддерживать практически все ISAM-типы доступа к данным
и в то же время достаточно эффективны, чтобы не добавлять бесполезное
переписывание данных для доступа к основным типам данных.
Однако IDAPI на этом не останавливается. IDAPI также включает концепцию
запросов (либо SQL, либо QBE) в эту же унифицированную модель.
Это делается приведением SQL и ISAM типов доступа к данным к той же
курсорной модели.
Давайте обсудим некоторые навигационные черты IDAPI, чтобы прояснить
концепцию. Важно понять, что навигационные черты полезны независимо от
типа источника данных (ISAM или SQL). ВСЕ драйвера IDAPI поддерживают
навигационные черты. Большинство навигационных особенностей доступны
когда курсор получен при помощи опции "Open Table".
Итак, если вы получили курсор IDAPI, то навигация будет означать
следующее:
- Возможность движения в обоих направлениях через результирующее множество.
Это весьма желательная возможность для построения приложений,
ориентированных на browse. Все курсоры IDAPI обладают этой возможностью.
В клиент-серверных средах курсоры IDAPI автоматически заносят в локальный
кэш соответствующее количество записей, делая процесс навигации очень
эффективным. Прикиньте количество программистского труда, от которого
вы будете избавлены, если будете использовать такие курсоры!
- Упорядочивание данных по доступному индексу. Нахождение записи в
результирующем множестве по значению ключа. А также возможность
переключаться на другой доступный индекс (или возврат к естественному
порядку записей безо всякого индекса) без потери доступа к текущей
записи. Это обычная программистская практика, которую поддерживает
IDAPI.
- Запомнить текущее положение курсора, чтобы вернуться к нему позднее.
Программисты всегда традиционно использовали вещи вроде номеров
записи, значений ключа и другие трюки, чтобы запомнить расположение
записи. Однако в ситуации, когда вы имеете дело с различными
форматами/файлами/данными, было бы неплохо отыскать некий универсальный
способ делать это, не вдумываясь в какие-то излишние детали. В IDAPI
введен механизм ЗАКЛАДОК для этих целей. В отличие от упомянутых
способов, закладка, полученная в одной транзакции, может быть доступна
и в других. Например, используя закладку IDAPI, вы можете сохранить
текущее состояние окна browse (скажем, когда вы просматривали
текущие счета клиентов), выключить ваш компьютер, и продолжить с
этого самого места, когда вернетесь.
- Найти запись по ее номеру, если нижний уровень источника данных
поддерживает это. Вообще-то, нельзя сказать, что это хороший способ
писать приложения - однако, если вы должны использовать такой метод
в силу некоторых причин - IDAPI должен поддерживать это. ( К примеру,
без этой возможности в-принципе нельзя было реализовать dBase for
Windows!).
- Возможность модернизировать текущую запись вне зависимости от того,
как вы получили доступ к этой записи. Возможность модернизировать
текущую запись даже если у нее нет уникального идентификатора,
поскольку нижний уровень не поддерживает его (например таблицы
Paradox безо всяких индексов.). И если запись изменена,
то надо иметь возможность захватить эту запись в
качестве текущей записи (быть может, вы хотите в это время модерни-
зировать другую запись!) - даже если изменилось значение ключа, по
которому курсор был отсортирован. IDAPI позволяет делать такие вещи.
- Возможность заблокировать отдельную запись. Множество не-SQLных
приложений зависят от существования такой возможности. А кроме
того, возможность держать блокировку столь долго, сколько нужно -
конечно же в предположении, что нижний уровень позволяет сделать это.
IDAPI позволяет блокировать отдельную запись. Если же нижний уровень
не поддерживает блокировку записи, IDAPI-драйвер эмулирует ее
используя наиболее оптимистичную блокировку.
- Живой доступ к данным (не просто доступ к снимку, который обычно
возвращают SQL запросы). Там, где возможно, IDAPI предоставляет
обновление данных (чтобы проследить за дальнейшей модернизацией)
или по крайней мере контроль за этим обновлением. Возможность
освежать локальный кэш данных без того, чтобы заново вручную
перепрочитывать данные( к примеру, некоторые драйвера могут иметь
механизмы оптимизации, для того, чтобы обновлять только те данные,
которые действительно подверглись изменениям - как это сделано в
драйверах Paradox и InterBase.)
- Возможность создания множества записей курсора, основанного на
значении другого курсора ( например создание результирующего множества
курсора "заказы" для данного заказчика, на которого указывает курсор
"заказчик"). СВЯЗАННЫЕ КУРСОРЫ IDAPI предоставляют такую возможность.
В Paradox'е for Windows мультитабличные формы реализованы через
связанные курсоры. А такая вещь в языке dBase for Windows как
"SET RELATION TO" тоже реализована при помощи связанных курсоров.
- Возьмем IDAPI-курсор и применим к нему фильтр. Курсор ведет себя так
же, как и раньше, за исключением того, что вы видите только те записи,
которые удовлетворяют фильтру. Если исходный курсор модернизирован таким
образом, он является уже "перестроенным" (constrained) курсором (Между
прочим, могут быть построены и множественные фильтры просто наложением
одного на другой). Если вы строите интерактивный инструмент для
обработки данных или реализуете фильтры в языке dBase, поддержка API
для этих целей весьма эффективна. Драйвера IDAPI могут реализовывать
фильтры наиболее эффективным способом, какой только возможен, используя
преимущества и особенности доступа к индексам и фильтрации данных
нижнего уровня.
- Возможность клонирования курсоров, для того, чтобы независимо
передвигать полученные клоны. Не нужно беспокоиться о том, какой из
курсоров был получен первым - и это очень полезно. Предположим, даны
два курсора на ту же самую таблицу. Мощная возможность - спозиционировать
один курсор на запись, на которую указывает второй. IDAPI это
предоставляет.
Итак, навигационный доступ дает больше свободы, больше гибкости и больше
возможностей при доступе к данным. Если вы пишете программу, работающую
с данными как в dBase или же высоко интерактивные приложения, вы обнаружите,
что навигационный подход в IDAPI - неоценимая вещь. Но если же вы работаете
с SQL-запросами, IDAPI не заставит вас это как-либо обходить. А так как
вы свободно можете смешивать оба подхода, вы можете использовать лучший
метод из этих двух миров.
Полезно знать, что SQL драйвера IDAPI переводят навигационные вызовы в
соответствующие SQL-запросы. Поэтому если вы разрабатываете интерактивное
приложение и хотите использовать любой SQL API, вы будете делать то же, что
и IDAPI, только вручную. Поскольку IDAPI делает это за вас, вы сэкономите
массу времени при разработке.
Преимущества IDAPI - в предоставлении такой схемы реализации курсоров, где
курсор может быть связан с SQL-запросом, напрямую с таблицей, или с таблицей
и с ассоциированным индексом. Сущност IDAPI состоит в том, что он объединяет
доступ к данным ISAM и обработку запросов посредством единой курсорной
абстракции.
Архитектура BDE/IDAPI
[В данный момент речь идет о реализации для Microsoft Windows 3.1. Если
надо будет перейти в новую среду типа Chicago или NT, архитектура системы
существенно не изменится.]
Рассмотрим здесь архитектуру IDAPI. IDAPI основан на драйверах. Для каждого
отдельного источника данных существует отдельный драйвер. Каждый данный
драйвер поддерживает близко связанную семью источников данных( к примеру,
драйвер dBase поддерживает форматы dBase III+, IV и в ограниченной степени
также и формат Foxpro). Драйвера IDAPI отвечают за любое обращение к данным.
Новые драйвера могут быть инсталлированы в любое время.
Архитектура IDAPI является объектно-ориентированной. Несмотря на то, что
клиентский API представляет из себя средство, основанное на С-шном API, боль-
шинство внутренних API основаны на объектах. Это делает всю инфраструктуру
легко расширяемой и обобщаемой. Инфраструктура IDAPI предоставляет также
богатый сервисный набор наподобие менеджера буфера, сортировки, языковых
драйверов и т.п., которые могут использоваться всеми драйверами. Этот
сервис подробно описывается в следующей главе.
Среда IDAPI конфигурируется посредством конфигурационного файла, который
может быть установлен при помощи API, являющегося частью IDAPI. При этом
пользователю не надо редактировать .INI файлы, а кроме того, позволяет
портировать инфраструктуру IDAPI в новую (не Windows) среду значительно
проще. Cистемный менеджер IDAPI управляет всеми ресурсами: загрузкой
драйверов при расширении, управлении конфигурацией, ведением записей о
ресурсах типа об открытии базы данных, курсорах и пр.
IDAPI поддерживает два класса драйверов. Драйвера, которые понимают
некоторый диалект SQL ( напр. драйвер SQL InterBase, драйвер SQL Oracle и пр.)
и другие, которые этого делать не могут( в BDE это драйвера Paradox, dBase
и текстовый драйвер). Другие будущие кандидаты в последнюю категорию
включают драйвер B-Trieve, драйвер для IBM VSAM файлов.
Обычный обработчик запросов (query engine) поддерживает два разных
языка запросов: SQL и QBE. SQL - это язык запросов, соответствующий
промышленному стандарту, в то время как QBE соответствует модели запросов,
ориентированных на пользователя - популяризованного в свое время Парадоксом.
Обычный обработчик запросов управляет запросами для не-SQLных драйверов типа
Парадоксовского или dBase напрямую, без излишнего дублирования. Поскольку
обработчик запросов построен на основе общей для IDAPI курсорной абстракции,
он может оперировать связями (joins) между разными БД, а также строить
результирующие множества в локальном формате для любого из доступных драйверов.
Архитектура IDAPI поддерживает требования международных рынков в языковых
драйверах. Все IDAPI-драйвера, а также общие сортировщики и обработчики
запросов, построены с использованием языковых драйверов. BDE оснащен более
чем 50 языковыми драйверами ( в это число входит большинство языков, основанных
на латинском шрифте). Таким образом, приложения, построенные при помощи IDAPI,
автоматически становятся международными - по крайней мере, с точки зрения базы
данных - а именно они являются труднейшей частью при интернационализации
всей системы.
Архитектура IDAPI не построена путем компромисса с производительностью.
IDAPI не вносит дополнительного переписывания данных, а следовательно не
замедляет исходной скорости доступа к базам данных. Кроме того, внутренние
тестовые испытания показывают, что BDE обладает наивысшей производительностью
среди всех инструментов доступа (database engines) к форматам файлов Paradox
и dBase.
BDE и Express Link to InterBase 4.0
InterBase - это мощный промышленный SQL-сервер фирмы Borland. Приблизи-
тельно через месяц появится коммерческая версия InterBase 4.0. В дополнение
к Unix-версиям, она будет доступна для платформ на NT и NetWare. Interbase 4.0
будет поддерживать с серверной стороны некоторые уникальные особенности для
того, чтобы сделать навигационный подход IDAPI максимально эффективным.
Имеется в виду поддержка двунаправленных курсоров (bidirectional cursors) ,
блокировки на уравне записи, явное использование индексов, закладки и пр. -
все это поддерживается на уровне сервера.
Эти уникальные черты InterBase 4.0 не будут доступны, если работать
через обычный SQL API. C ними можно работать только через низкоуровневый
интерфейс, который называется BLR. Разработчики IDAPI представили специаль-
ный драйвер для Interbase 4.0, который испольует преимущества этих
уникальных особенностей сервера. Этот драйвер называется Express Link. С
точки зрения BDE он ведет себя как обыкновенный SQL-драйвер. Однако ему
нет необходимости эмулировать навигационные свойства IDAPI на верхнем
уровне, поэтому производительность навигационного доступа существенно
возрастает. Кроме того, он напрямую поддерживает SQL, как и любой другой SQL-
драйвер. Express Link можно охарактеризовать как гибридный драйвер,
имеющий наилучшие характеристики как ISAM-драйвера, так и SQL-драйвера.
Общая инфраструктура BDE/IDAPI. Посмотрим внутрь.
Инфраструктура IDAPI предоставляет некоторое количество дополнительного
сервиса. Это позволяет максимально использовать стандартные библиотечные
процедуры и сделать всю систему модульной и легко переносимой. Используя
этот сервис, можно строить IDAPI-драйвера проще чем любые другие. (В
настоящий момент собственно разработчики IDAPI построили восемь драйверов.
Без этого сервиса это потребовало бы в два-три раза больше инженерного
труда.) Этот сервис описывается ниже.
Сервис ОС
Все, что зависит от операционной системы и платформы, находится здесь.
Файловый ввод-вывод, сетевой доступ и управление памятью на уровне ОС
выделены в этот модуль. Все остальное в системе уже не зависит от ОС или
платформы и, следовательно, легко портируемо.
Менеджер памяти
Этот модуль предоставляет дополнительный сервис по управлению памятью, при
этом реже происходит обращение к системному менеджеру ОС. В отладочном
режиме этот модуль помечает, трассирует и разрешает все попытки разместить и
использовать память.
Менеджер буфера
Большинство высокопроизводительных СУБД обладают своими менеджерами
буфера. Системы управления виртуальной памятью в ОС и схемы кэширования
диска в ОС не полностью удовлетворяют требованиям драйверов СУБД.
Инфраструктура IDAPI предоставляет менеджер буфера, основанный на использовании
приоритетов. Все драйвера IDAPI пользуются преимуществами этого сервиса.
Кроме того, в IDAPI все устроено так, что буфера, принадлежащие разным
драйверам, могут сосуществовать в одном и том же пуле памяти.
Сортировщик
Наиболее общий сервис в IDAPI - это скоростной сортировщик. Сортировщик
автоматически выбирает оптимальное использование доступной памяти; превращает
сортировку в сортировку слиянием, если памяти не хватает. Сортировщик также
доступен в качестве функции из IDAPI. Сортировщик использует также особенности
языкового драйвера (в частности, схему упорядочивания) для того, чтобы работать
с различными наборами знаков. Парадоксовский и дибэйзовский драйвера через
BDE используют этот сортировщик.
Кэш для больших двоичных объектов (BLOb)
BLOb'ы могут быть произвольно большими. Для того, чтобы обработать BLOb
(особенно в клиент-серверной среде) программисты должны сначала скопировать
BLOb в файл либо использовать свою собственную кэш-схему. Чтобы сделать
доступ к BLOb максимально эффективным, IDAPI предоставляет общий сервис для
кэширования. Драйвера IDAPI используют возможности этого сервиса. В отличие
от других API, IDAPI позволяет производить чтение/запись произвольного места
в BLOb'е. При переполненнии кеша осуществляется автоматическая запись
кэша BLOb'ов в разделяемый файл. Может быть открыто одновременно
любое количество BLOb'ов.
Обработчик запросов (Query engine)
Общий обработчик запросов поддерживает SQL и QBE в качестве альтернативных
языков запросов. Он построен с использованием абстракции курсоров, предлагаемой
драйверами IDAPI. Поэтому обработчик запросов работает с любым источником
данных и может естественно проводить операции однвременно с разными БД.
Из этого следует, что результат запроса может быть записан в формате Paradox
или dBase, или предоставлен напрямую через результирующее множество курсоров.
Если запрос может быть напрямую выполнен на сервере, он сразу выполняется на
сервере (если это был QBE-запрос, он вначале транслируется в SQL-запрос).
В результате выполнения запроса можно также получить так называемое
Live Answer set - где результирующий курсор есть модернизируемый курсор.
Под Live Answer set следует понимать помещение данных в кэш, причем если
эти данные изменяются в результате завершения других транзакций, они
автоматически заменяются в кэше на более свежие. Обработчик запросов написан
с использованием языковых драйверов для того, чтобы поддерживать националь-
ные особенности.
SQL генератор
Общий обработчик запросов поддерживает QBE в качестве альтернативного
языка запросов. Когда запрос обрабатывается на SQL сервере, обработчик
QBE транслирует запрос в эквивалентный SQL-запрос (если возможно). Для
того, чтобы это делать, предлагается такая возможность, как некий модуль,
основанный на SQL-генераторе. Каждый SQL-драйвер предоставляет свои
собственные возможности (например, поддерживаются или нет внешние joins),
чтобы управлять этим модулем.
Реструктурирование
В BDE поддерживается сервис по реструктурированию.(В настоящее время поддер-
живается как драйвером Paradox, так и драйвером dBase). Он поддерживает
сложные изменения структуры таблиц, в том числе добавление новых полей,
удаление полей, изменение имени поля, изменение свойств поля (тип, размер и
т.п.), изменение ссылочной целостности таблицы и т.д. Этот модуль создает
соответствующие новые таблицы, трансформирует данные и копирует даннные в
новую таблицу. Когда в таблицу добавляются новые условия ссылочной
целостности, этот модуль по желанию может создать таблицу записей, которые
не удовлетворяют новым условиям ссылочной целостности.
Функции пакетной обработки
В BDE поддерживается некоторые основные функции пакетной обработки. Они
включают в себя копирование данных из одного формата в другой, переименование
таблиц и пр.
Сервис Xlate
Так как большинство функций и возможностей IDAPI выполняют операции с
разными БД, написан сервисный модуль для основных преобразований данных.
Для каждых данных двух сравнимых форматов данных, модуль Xlate находит
наиболее оптимальное преобразование. Это возможно благодаря тому, что
каждый драйвер экспортирует функции для перевода в и из соответствующего
формата в принятые в IDAPI логические форматы данных. Все функции
пакетной обработки, обработчик запросов и модуль реструктурирования исполь-
зуют этот сервисный модуль.
Связанные курсоры
IDAPI поддерживает концепцию связанных курсоров для того, чтобы поддержать
существование зависимостей "один к многим" между двумя таблицами. Так как
курсоры IDAPI являются внутренними объектами, связанные курсоры реализованы
при помощи основных курсорных методов. Благодаря этому нет специфических
обращений напрямую к драйверам. Предположим, курсор, указывающий на "Заказы",
связан с курсором в таблице "Заказчики". Как только связь установлена, курсор
"Заказы" автоматически выводит курсор "Заказчики", создавая непротиворечивое
множество записей только на те заказы, которые принадлежат соответствующему
заказчику. Разработчики могут оценить преимущества связанных курсоров, строя
сложнейшие многотабличные приложения с помощью минимальных програмистских
усилий.
Таблицы в памяти (In-Memory Tables)
Этот модуль предоставляет бесконечную виртуальную память, ориентированную
на таблицы. Он поддерживает курсоры приложений, как и любые другие курсоры
IDAPI. Например, большинство schema inquiry функций, запрашивающих структуру
БД, которые возвращают курсоры, возвращают курсоры в этих Таблицах в памяти.
Cортировка использует Таблицы в памяти для промежуточной пакетной обработки.
SQL-драйвера используют Таблицы в памяти для локального кэширования данных.
Работа Таблиц в памяти тесно связана с работой менеджера буфера - и это делает
их весьма эффективными.
Этот модуль также доступен для разработчиков.
Mодуль поддержки SQL-драйверов
Все SQL-драйвера, включая IDAPTOR, построены при помощи этого модуля. Этот
сервисный набор на 80% обеспечивает построение SQL-драйвера. То есть для
каждого нового SQL-драйвера только 20 процентов кода приходится переписывать.
Вот некоторые из его возможностей: модули, которые "накладывают" навигационный
API на SQL, локальное кэширование записей, функции, запрашивающие структуру
БД, управление BLObами по логическому имени... Модуль поддержки SQL-драйверов,
в свою очередь построен при использовании других модулей IDAPI, например,
сервис ОС и Таблицы в памяти.
Ресурсы
Все ресурсы, напр. сообщения об ошибках, находятся в отдельном dll.
Приложение может зарегистрировать свой язык при начале работы или может
использовать по умолчанию язык, указанный в конфигурационном файле IDAPI.
IDAPI может одновременно поддерживать множество ресурсов - и это может быть
очень полезным в многоязычных странах.
Языковые драйвера
IDAPI осуществляет национальную поддержку для международного рынка. Такие
вещи, как схемы упорядочивания (способ сортировки по нац. алфавиту), правила
использования заглавных букв, OEM/ANSI преобразования, содержатся во всех
языковых драйверах. Все IDAPI-драйвера и все сервисные IDAPI-модули написаны
так, чтобы поддерживать языковые драйверы. Таким образом, вся IDAPI-среда
сразу же работает с национальными особенностями и не требует дорогостоящей
локализации.
Конфигурационный менеджер
Конфигурационный менеджер устанавливает конфигурационную информацию IDAPI.
При стартовой загрузке он читает конфигурационный файл для того, чтобы
подрегулировать параметры среды. Все драйвера и псевдонимы зарегистрированы в
конфигурационном файле. Манипулирование конфигурацией системы осуществляется
некоторым множеством API. В дополнение к системному уровню настроек (напр.
таких как формат данных) каждый IDAPI-драйвер имеет свои собственные настройки
(например языковой драйвер, используемый по умолчанию).
Системный менеджер
Все ресурсы системного уровня управляются системным мененджером. Он отвечает
за загрузку драйверов, если это потребовалось, отслеживание открытвых БД
и курсоров, отслеживание контекста каждого приложения и т.д. Когда клиентское
приложение заканчивает работу, системный менеджер очищает все ресурсы,
ранее затребованные клиентом.
Концепции IDAPI
В дополнение к точке зрения на IDAPI как на набор свойств и характеристик
полезно понять внутрение концепции, лежащие в основе IDAPI. Некоторые из
этих концепций были объяснены, когда мы обсуждали различные особенности
системы. Здесь мы соберем и суммируем сказанное, чтобы эти концепции
прояснить. Заметим, что большинство из того, что будет описано далее,
представляют из себя собственно объекты.
Система
Это глобальный объект, устанавливающий состояние системы. Система инициали-
зируется при установке конфигурации. Когда системный объект активен, он
имеет одного или более зарегистрированных клиентов (или приложений). Он
может также иметь несколько загруженных драйверов или вообще их не иметь.
Клиенты/приложения
Клиент или экземпляр приложения, когда он вызывает функцию IDAPI "Init",
регистрируется в качестве клиента системы. Клиент может иметь одну или более
одной активных сессий. Когда клиент зарегистрирован, автоматически стартует
сессия по умолчанию - и остается активной до тех пор, пока не будет вызвана
функция IDAPI "Exit". Здесь и далее мы будем смешивать термины Клиент и
Приложение.
Сессии
Все, что делается клиентом, происходит внутри контекста сессии. Клиент
может запустить множество сессий.С точки зрения базы данных, каждая
сессия выглядит для нее как отдельный пользователь. К примеру, запросы на
блокировку из одной сессии конфликтуют с блокировкой, установленной
другой сессией даже в том случае, когда обе сессии принадлежат одному и
тому же клиенту. Сессии - это способ полностью изолировать одно действие
с базой данных от другого. Перед тем, как действие с БД будет выполнено
в течение одной сессии, должна быть вначале открыта одна или более БД.
Сессия может одновременно иметь любое количество открытых БД. Каждая сессия
может быть настроена независимо в отношении таких вещей, как Call-back-
функции, языки для сообщения об ошибках, формат данных и т.д.
Базы данных и псевдонимы
БД может быть либо "стандартной" базой данных либо действительно серверной
базой данных. Стандартные БД поддерживает значение БД используя каталогово-
файловую систему и таким образом имеет текущую директорию, связанную с
ними. Псевдонимы - это механизм идентификации БД через имя, например нечто
вроде "mydb". Основное преимущество использования псевдонимов состоит
в том, что они дают легкость нахождения БД. Псевдонимы могут быть
зарегистрированы в системном конфигурационном файле. Когда приложение
открывает базу данных посредством псевдонима, IDAPI будет использовать
информацию, прикрепленную к псевдониму, чтобы открыть соответствующую
физическую базу данных - будь это в действительности серверная БД или
просто имя директории. БД может иметь активными один или более курсоров.
Курсоры
Курсоры - это основное средство для любого доступа данных в IDAPI. Курсорный
объект порождает свои экземпляры одним из дрех способов:
1. Выполнением "Open Table"
2. Выполнением SQL или QBE запроса, в резултате которого возвращается
результирующее множество
3. Выполнением функции запроса структуры БД или функции запроса
возможностей
Когда курсор получен, вы используете то же самое множество API в IDAPI.
Наиболее важная характеристика курсора - это его текущая позиция.
Все курсоры имеют явное описание и свойства курсора могут быть затребованы
при помощи различных курсорных функций. Некоторые операции над курсором
могут быть не выполнимы в силу каких-нибудь свойств курсора. К примеру,
если курсор является read-only курсором, все операции модификации данных
будут возвращать ошибку. Связанные курсоры являются соответствующим
образом настроенными курсорами - это уже детально объяснялось выше.
Курсоры являются наиболее важными объектами в IDAPI. Курсоры обеспечивают
механизм унификации навигационного и SQL -доступа в IDAPI.
Запросы
Когда готовится SQL или QBE-запрос, создается объект-"запрос". Точно так же,
как и любой другой объект, объект-запрос имеет набор свойств. К примеру,
вы можете установить свойство "живой ответ" ("Live answer"). Если
соответствующие свойства установлены, запрос может быть выполнен, при этом
может быть возвращен курсор (если запрос возвращает результирующее множество).
Как уже упоминалось, запрос может быть либо на SQL, либо на QBE-языке.
Закладки
Закладки - это обобщенный механизм сохранения текущей позиции курсора.
Если курсор установлен на какую-либо позицию (в том числе BOF или EOF),
может быт получена закладка, и позднее (возможно, после визита к другим
записям) курсор может быть переустановлен обратно на место, указанное
закладкой. Так как закладки расположены в пространстве приложения, может
быть установлено любое количество закладок.
ODBC и IDAPTER
--------------
В компании Borland отдают себе отчет в том, что сегодня доступно уже
множество ODBC-драйверов. И в данный момент не имело бы практической
ценности для Borland строить драйвера для каждого источника данных.
C использованием IDAPTER BDE предлагает доступ к широчайшему спектру
источников данных. Иными словами, IDAPI превращает любой ODBC-драйвер
в IDAPI-драйвер - предоставляя таким образом значительно большее
количество источников данных, доступных IDAPI-приложению. Тем не менее
Borland продолжает свою работу по построению "родных" IDAPI-драйверов.
IDAPTER был разработан на основе того же сервисного пакета для
построения SQL-драйверов, который используется для построения "родных"
IDAPI-драйверов. В силу этого вы получаете все достоинства IDAPI -
в частности, и навигационные возможности. Для того, чтобы получить
полный набор возможностей IDAPI при использовании ODBC- источников
данных, ODBC-драйвер должен быть по крайней мере уровня 1 или выше.
IDAPI будет также работать с ODBC-драйверами на уровне ядра -
хотя и с уменьшенными возможностями.
Что касается новых промышленных стандартов, то когда поставщики СУБД
начнут поддерживать API, основанные на X-OPEN CLI, Borland будет
поставлять CLI-драйвера, которые будут взаимодействовать со всеми БД,
поддерживающими CLI.
Что добавлено в IDAPI по сравнению с ODBC
Богатые навигационные возможности IDAPI позволяют получить разработчикам
неоценимые преимущества, так как IDAPI поставляет инструментарий, существенно
облегчающий разработку приложений. Мы не будем описывать здесь навигационные
свойства, они подробно были обсуждены ранее. IDAPTER делает их доступными
даже для ODBC-драйверов.
Используя IDAPI, разработчики получают следующие преимущества по сравнению
с ODBC:
- Все навигационные возможности IDAPI-курсоров, такие как двунаправленные
курсоры, автоматическое локальное кэширование данных, закладки и пр.
- Все возможности одновременной работы с несколькими БД, такие как
связь БД (joins) в запросах, связанные курсоры, функции пакетной обработки,
которые могут передавать данные через БД
- Выбор или QBE или SQL в качестве языка запросов для источников данных
ODBC также
- Модернизируемые запросы при использовании обобщенного механизма IDAPI,
позволяющего выбрать SQL или QBE
- Поддержка национальных особенностей без необходимости портирования
приложения
- Уникальные особенности ISAM баз данных типа dBase и Paradox, которые
недоступны через SQL
IDAPI делает возможным использование гораздо больше источников данных типа
ISAM/VSAM без переписывания их в формат, доступный при помощи SQL. Когда
к таким данным производился доступ при помощи только SQL-запросов,
зачастую значительно уменьшались возможности по модернизации таких данных.
IDAPI-драйвера, написанные для этих типов данных, позволяют использовать
такие источники данных гораздо шире. IDAPI дает уникальную возможность
доступа к источникам данных, с которыми вам не нужно работать через SQL,
если вы его не имеете.
Фундаментальная разница между ODBC и IDAPI состоит в том, что ODBC предла-
гает вам работать только через SQL, в то время как IDAPI предлагает унифи-
цированный доступ для навигационного и SQL-подходов. Заметим, что
аналогичного BDE продукта на рынке программных средств просто нет. Ближе
всего к BDE/IDAPI находится так называемый Jet Engine компании Microsoft.
Он обладает некоторыми возможностями IDAPI. В настоящее время он является
частью собственных продуктов Microsoft типа Access. Поскольку он представляет
из себя надстройку над ODBC, неясно, какой сорт API он поддерживает и
будет ли он доступен и в каком виде для разработчиков.
Возможности и преимущества использования BDE SDK в разработке.
Для разработчиков приложений BDE/IDAPI открывает новые перспективы и
предлагает преимущества, которые несравнимы ни с каким другим инструментарием,
доступным на рынке программных средств. Некоторые из этих преимуществ
приведены ниже:
- Высокопроизводительный доступ к файлам Paradox и dBase. Все уникальные
особенности этих форматов данныхдоступны через API (вспомним, что и
Paradox for Windows и dBase for Windows свой доступ к данным осуществляют
через IDAPI. Вы теперь больше не должны ни переписывать файл, конвертируя
формат, ни полагаться на какой-либо третий инструментарий, который
может быть, а может и не быть 100% совместимым.
- Непревзойденные возможности по интеграции данных. Поддержка запросов
одновременно к нескольким БД с различными форматами данных, функции
пакетной обработки для передвижения данных из базы в базу, получение
результатов запроса в любом формате - с этими возможностями вы сможете
ощутить вкус работы со многими БД при помощи BDE.
- Навигационные особенности IDAPI позволяют легко разрабатывать
интерактивные приложения. (Большинство этих особенностей были
созданы под влиянием требований при разработке интерактивных приложений
при помощи таких инструментов, как Paradox for Windows). Все это
доступно теперь для разработчиков.
- Псевдонимы предоставляют прозрачность доступа к данным независимо от
их местонахождения. Вы можете получит данные с сервера БД так же легко,
как и локальные данные.
- Вам нет нужды напрягаться для изучения SQL. Если у вас уже разработаны
приложения, и они использовали ISAM-методы доступа к данным, вы легко
перенесете их в архитектуру клиент-сервер при помощи BDE без существенного
перепроектирования. BDE открывает дверь вашим разработкам для перехода в
клиент/серверный мир, чего не даст никакой другой инструмент.
- Такая вещь, как "живой ответ" (live answer) для SQL и QBE-запросов
позволяет использовать навигационные особенности даже если вы
используете только SQL или QBE.
- IDAPTER предлагает пользователям широчайший выбор источников данных.
- Функции обработки событий (call-back functions) дают возможность
разработчикам использовать преимущества асинхронной обработки событий.
К примеру, регистрируя соответствующую функцию для большого запроса,
ваше приложение может показывать, насколько продвинулся процесс
обработки этого запроса. Такие возможности весьма редко предоставляются
другим инструментарием.
- Полная совместимость ваших приложений с форматами файлов Paradox и
dBase. Если уж новые особенности будут добавлены в эти форматы, вы
также получите к ним доступ.
- Один инструмент для доступа к наиболее распространеным для персональных
компьютеров форматам данных и к форматам данных SQL - серверов (и
возможно к другим источникам данных в будущем) - в то время как можно
использовать уникальные особенности каждого такого источника.
- Один инструмент для большинства из национальных рынков (текущая версия
не поддерживает только 16-битовые символы). Все драйвера, которые вам
нужны, есть в SDK.
Честно говоря IDAPI создавался в основном под влиянием нужд Paradox for
Windows и dBase for Windows. Однако хочется верить, что IDAPI достаточно
открыт и эффективен для того, чтобы проводить разработку для любого типа
приложений.
Версия 1.2. Что дальше?
Borland Database Engine (BDE) версии 1.2 состоит из следующих драйверов
и компонент:
(Однако разные поставки могут варьировать этот набор.)
Доступные драйвера:
Paradox
dBase
Ascii text
Interbase SQL
Interbase Expresslink
Oracle SQL
Sybase/MS SQL
Informix SQL
IDAPTER для любого ODBC
Основные особенности:
обработчик запросов SQL и QBE
запросы с поддержкой "живого ответа" (live answer)
операции сразу с несколькими БД там где они находятся
поддержка сквозных SQL-запросов
связанный курсоры, упрощающие приложения,
работающие с отношениями "один к многим"
функции пакетной обработки для упрощения администрирования данных
управление конфигурацией из API
драйвера национальных языков
Направления развития
Примечание: Эта часть дается только для того, чтобы информировать
пользователей IDAPI-технологии о текущих планах Borland c тем, чтобы
можно было принять правильные решения. Ни одна из описанных далее
особенностей не включается в текущую поставку BDE.
С появлением Chicago Windows окончательно станет операционной системой
достаточно сильной для промышленного применения. Это позволит многим
серьезным приложениям (критичным к быстродействию среды) появиться для
работы в этой среде. Большинство таких приложений так или иначе используют
базы данных.
Borland заинтересован в введении Paradox и dBase в этот мир новых
возможностей. Точно так же, как Chicago сохраняет огромные инвестиции,
сделанные в приложения для DOS и Windows 3.х, BDE сохранит инвестиции
пользователей, сделанные в приложения и данные Paradox и dBase, к тому
же предложив инновационные решения для объединения их преимуществ. Мы
имеем в виду следующее:
- полностью 32-разрядный код
- транзакции для драйверов Paradox и dBase
- инструментарий, поддерживающий стандарт SQL-92
- интегрированный словарь данных
- больше драйверов для различных источников данных
- серверная версия IDAPI для платформ NT и NetWare
Выводы
------
Borland Database Engine - это уникальный продукт, предлагающий инструментарий
работы с БД, удовлетворяющий почти любому типу приложений. Аргументом,
говорящим о возможности строить чрезвычайно сложные приложения, является
тот факт, что Paradox for Windows и dBase for Windows опираются на BDE. Тот
же самый инструмент теперь доступен для любого разработчика приложений.
Комбинируя гибкость ISAM-доступа и мощность SQL-доступа в единой курсорной
модели, BDE становится мостом через пропасть, разделяющую эти два мира. Раз-
рабатываете ли вы простое приложение под Paradox/dBase, или сложнейшее
клиент-серверное приложение, BDE даст вам то, что требуется. Уникальные
навигационные черты BDE делают разработку интерактивного приложения более
простым делом, чем если использовать любой другой инструмент.
|
|
 |
|
