к оглавлению

Архитектура ODBC, JDBC, OCI, OLE DB и ADO

ODBC

Допустим, есть клиент, написанный к примеру на Visual C, есть база данных (ORACLE, MS SQL) и целая куча разных Desktops БД (Access, dBase, Paradox, Excel и т.д.). Как же происходит взаимодействие? Прежде всего, в системе устанавливается Microsoft Driver Manager (odbc32.dll). Эта dll-ка взаимодействует иногда с odbcint.ini и odbc.ini. Для работы с этой dll-кой есть администратор, который позволяет подключать драйверы (то что мы видим в панели управления).
Есть ODBC Administrator – это ничто иное, как odbcad32.exe, odbccp32.dll и odbccp32.cpl – видим в панели управления. С помощью этих средств мы запускаем администратор (через пиктограмму odbccp32.cpl), и там можно устанавливать имя базы, подключать драйверы, псевдонимы давать базам данных и т.д. и т.д. Для каждой базы данных в системе должен быть соответствующий драйвер. Например, ODBC driver для ORACLE (как правило, есть в системе); драйвер для MS SQL Server – тоже есть; драйвер, который чаще всего интегрирован, поскольку это базы все простенькие, – odbcjt32.dll – для разных Desktop–овских СУБД.

Архитектура ODBC, JDBC, OCI, OLE DB и ADO
Рис. 1. Архитектура ODBC

Таким образом, промежуточное программное обеспечение достаточно большое. Клиент в ручном режиме настраивает псевдоним и указывает путь для базы данных, выбирает драйвер. Когда клиент обращается, то он обращается к driver managerу, берет нужный драйвер, а нужный драйвер бывает часто записан в этих файлах, а в последнее время в реестре Windows (лезет в реестр Windows и находит драйвер, подключает этот драйвер и обращается к БД).

ODBC API

ODBC API включает около 56 функций. Это было создано в 1992 году, поэтому она реализована на уровне функций, т.е. имеет функциональное представление.
Чуть позже был разработан BDE, который фактически условно считается объектно-ориентированным, но объектно-ориентированного там мало, все равно там есть тоже функции. BDE лучше обеспечивает доступ к Desktop–овским СУБД, поскольку у Borland более простые базы данных. Там можно настраивать разные языки. Но сейчас это правда никому не нужно, т.к. все драйверы стали делать универсальными, - им все равно. Драйверы пропускают просто данные вне зависимости от языка. В результате получилось так, что для использования BDE надо инсталлировать 17мб и не ясно, что из них “можно выбросить”, в то время как реализация конкретного доступа на ODBC потребует меньше мегабайта.

JDBC

Стандарт JDBC первоначально разработанный, чтобы иметь доступ к БД по такой же архитектуре сначала включал в себя мост JDBC/ODBC Bridge, а дальше подключались ODBC–шные драйвера. Но с течением времени научились делать и свои драйверы более прямые, и естественно здесь, как говорится, многократное преобразование, а там получилось одно преобразование и обращения к БД стали более быстрыми.

OCI

Стандарт OCI предназначен только для доступа к базам данных ORACLE. В отличие от Microsoft предлагает немного другой драйвер. Т.е. имеется: клиент, sqloci32.dll, который соединяется с NET8.
Драйвер NET8 всегда есть в базе данных ORACLE. Microsoft, в свою очередь, подключается к ORACLE, минуя NET8 с любой операционной системой, если вы устанавливаете Office, то там этот драйвер есть. Однако сам ORACLE для себя делает более маленькую dll-ку, потому что у него всегда есть хорошо отлаженный драйвер NET8.

OLE DB и ADO

С течением времени чисто функциональный подход к созданию промежуточного программного обеспечения стал немножко входить в диссонанс с объектно-ориентированными средами разработки, и было разработано два новых стандарта OLE DB и ADO.
Что собой представляют OLE DB и ADO фактически? Общая более современная структура доступа от приложения к БД по мнению Microsoft на сегодня выглядит следующим образом:

Архитектура ODBC, JDBC, OCI, OLE DB и ADO
Рис. 2. Современная структура доступа от приложения к БД

Есть приложение или клиент, драйверы OLE DB или поставщики, имеется ADO. Вот как по структуре от Microsoft может быть реализован доступ к SQL – им данным и к не SQLским данным (например, к каким-то текстовым данным, тоже есть драйверы). OLE DB провайдеры чисто объектно-ориентированные: там есть классы, объекты, методы. Однако поскольку OLE DB сам стандарт достаточно тяжелый, “такие книги по нему”, то для упрощения доступа сделан простой интерфейс ADO, с помощью которого из многих сред таких как Visual Basic, Delphi, и др. можно по-простому обращаться вот таким образом. ODBC никуда не исчез, потому что есть OLE DB провайдеры. Microsoft сделал только семь провайдеров: для “себя любимого”, для ORACLE, для ODBC для всех других баз данных, для текстовых и т.д. всего их 7 штук. Желающих дальше разрабатывать этот провайдер не оказалось, и эта система вот так вот и осталась. Если есть прямой провайдер к MS SQL и ORACLE то можно напрямую (1).
ADO позволяет иметь доступ: либо вот так (2), если провайдера нет, и (3), если провайдер имеется.

Архитектура ODBC, JDBC, OCI, OLE DB и ADO
Рис.3. Набор объектов ADO

connection – организует соединение базы данных, т.е. инкапсулирует все сведения о соединении: имя базы данных и т.д. и т.д.
command – объект имеющий методы для выполнения команд.
streams – работа с потоками.
fields – для работы с полями.
Такова архитектура ADO для доступа базам данных, т.е. это небольшой комплект объектов, у которого есть некоторый набор методов, с помощью которых считывать записи напрямую через потоки, если из файлов считывать и т.д.
Таким образом к сегодняшнему дню сформировано целое направление промежуточного программного обеспечения (ODBC, JDBC, ADO, OLE DB, BDE, OCI), назначение которого дать возможность разрабатывать клиентские приложения на различных языках и подключаться к существующим базам данных. Для этого нужные только драйверы и вот это промежуточное ПО, которое может работать с этими драйверами. Тем самым “был развязан узел” между поставщиками баз банных и поставщиков языков, они конечно поставляли языки но средства были очень и очень ограничены.

к оглавлению

Знаете ли Вы, что релятивистское объяснение феномену CMB (космическому микроволновому излучению) придумал человек выдающейся фантазии Иосиф Шкловский (помните книжку миллионного тиража "Вселенная, жизнь, разум"?). Он выдвинул совершенно абсурдную идею, заключавшуюся в том, что это есть "реликтовое" излучение, оставшееся после "Большого Взрыва", то есть от момента "рождения" Вселенной. Хотя из простой логики следует, что Вселенная есть всё, а значит, у нее нет ни начала, ни конца... Подробнее читайте в FAQ по эфирной физике.

Bourabai Research Institution home page

Bourabai Research - Технологии XXI века Bourabai Research Institution