Введение в базы данных
Часть 5. Механизмы доступа к данным. OLE DB и ADO
Microsoft Universal Data Access
Microsoft ActiveX Data Objects
ADO Extensions for Data Definition and Security (ADOX)
ADO Multi-Dimensional Extensions (ADOMD)
В предыдущей статье данного цикла, опубликованной в № 6’2000, мы обсудили различные механизмы доступа к данным и подробно рассмотрели библиотеку Borland Database Engine (BDE), архитектуру использующих ее приложений, а также выяснили, с помощью каких продуктов третьих фирм можно заменить BDE в средствах разработки фирмы Borland. Как мы уже говорили, применение BDE нередко связано с определенными ограничениями, причина которых — отсутствие необходимых BDE-драйверов. В настоящей статье мы рассмотрим другой универсальный механизм доступа к данным — Microsoft ADO (ActiveX Data Objects), ныне широко применяемый не только в средствах разработки фирм Microsoft и Borland, но и во многих «пользовательских» продуктах, таких как Microsoft Office, Microsoft Internet Explorer, в ASP-приложениях и др. ADO становится все более и более популярным способом доступа к данным, так как не только входит в состав Microsoft Office 2000 и Microsoft Internet Explorer 5.0, но и является частью ядра операционных систем семейства Windows 2000. В предыдущей статье цикла мы упоминали, что OLE DB и ADO, являясь частью универсального механизма доступа к данным фирмы Microsoft (Microsoft Universal Data Access), позволяют осуществить доступ как к реляционным, так и к нереляционным источникам данных, таким как файловая система, данные электронной почты, многомерные хранилища данных и др. Эту статью мы хотим целиком посвятить универсальному механизму доступа к данным фирмы Microsoft.
Microsoft Universal Data Access
Универсальный механизм доступа к данным (Universal Data Access) являет собой стратегию предоставления доступа к любому типу информации предприятия. Он обеспечивает высокопроизводительный доступ к различным источникам информации (включая реляционные и нереляционные данные), в том числе к данным, хранящимся на мэйнфреймах, данным электронной почты и файловой системы, текстовым, графическим и географическим данным и др. Для многих современных приложений, использующих данные, характерно подобное разнообразие их источников. Более того, вполне очевидно, что могут появляться новые форматы данных и способы их хранения, поэтому разумным требованием к универсальному механизму доступа к данным была бы возможность поддержки не только существующих в настоящее время форматов и источников данных, но и форматов данных, которые будут созданы в будущем.
Назначение универсального механизма доступа к данным фирмы Microsoft — предоставить доступ к перечисленным источникам данных с помощью единой модели доступа к данным.
В настоящее время универсальный механизм доступа к данным фирмы Microsoft поддерживает все наиболее популярные настольные и серверные СУБД, о которых мы писали в предыдущих статьях данного цикла.
Далее мы рассмотрим основные компоненты архитектуры универсального механизма доступа к данным Microsoft и обсудим их более детально:
- Microsoft ActiveX Data Objects (ADO) представляет собой программный интерфейс для доступа к данным из приложений. С точки зрения программирования ADO и его расширения являются упрощенным высокоуровневым объектно-ориентированным интерфейсом к OLE DB;
- OLE DB — это низкоуровневый интерфейс для доступа к данным. ADO использует OLE DB, но можно использовать OLE DB и напрямую, минуя ADO;
- Open Database Connectivity (ODBC), уже обсуждавшийся в одной из предыдущих статей данного цикла, — стандартный способ доступа к реляционным данным. Этот компонент универсального механизма доступа к данным оставлен с целью обеспечения совместимости с прежними версиями программного обеспечения. В современных приложениях применению ODBC-драйверов предпочитают использование OLE DB-провайдеров.
Архитектура универсального механизма доступа к данным Microsoft схематически представлена на рис.1.
Так как OLE DB является низкоуровневым интерфейсом доступа к данным, мы начнем рассмотрение составных частей универсального механизма доступа к данным фирмы Microsoft именно с него. Ниже мы обсудим архитектуру и интерфейсы OLE DB, а затем покажем, как OLE DB взаимодействует с ADO.
 |
|
OLE DB
Итак, OLE DB представляет собой программный интерфейс для доступа к различным источникам данных, таким как реляционные и нереляционные данные, текстовые, графические и географические данные, архивы электронных писем, файловая система, бизнес-объекты. В спецификации OLE DB определен набор COM-интерфейсов (COM, Component Object Model, компонентная модель объектов Microsoft, являющаяся составной частью 32-разрядных версий Windows), инкапсулирующих различные сервисы управления данными и предоставляющих однотипный доступ к перечисленным выше данным. Эти интерфейсы могут быть использованы в приложениях, предоставляющих доступ к данным.
|
|
|
Компоненты OLE DB
На самом верхнем уровне можно отметить три главных компонента OLE DB: потребители (consumers), провайдеры данных (data providers) и сервисные компоненты (service components).
Любой компонент программного обеспечения, применяющий интерфейсы OLE DB, является потребителем. Это может быть какое-либо офисное приложение или иное бизнес-приложение, средство разработки типа Visual Basic или Delphi либо даже COM-объекты для доступа к данным, применяющие интерфейсы OLE DB. Потребители могут обращаться к данным посредством ActiveX Data Objects, представляющих собой высокоуровневый интерфейс к OLE DB, или применять OLE DB непосредственно, используя OLE DB-провайдер.
Провайдер — это часть программного обеспечения, в которой реализованы интерфейсы OLE DB. С точки зрения OLE DB существуют два типа OLE DB-провайдеров — провайдеры данных и сервисные компоненты.
Провайдер данных — это компонент программного обеспечения, манипулирующий данными. Он располагается между потребителем данных и базой данных. В OLE DB все провайдеры представляют данные в табличном формате (аналогичном тому, в котором хранятся данные в реляционных СУБД и файлах электронных таблиц), в виде виртуальных таблиц. Провайдер данных выполняет следующие функции:
- получение от потребителя запросов на получение или модификацию данных;
- получение данных из базы данных или их модификацию в базе данных;
- возвращение данных потребителю.
Примером провайдеров данных является провайдер Microsoft Jet 4.0 OLE DB Provider, который используется для доступа к данным Microsoft Access, а также к данным I-ISAM (Installable Indexed Sequential Access Method), файлам рабочих книг Excel, хранилищ данных Microsoft Outlook и Microsoft Exchange, таблиц dBase и Paradox, текстовым файлам, файлам в формате HTML и др. Еще один пример OLE DB-провайдера — Microsoft OLE DB Provider for SQL Server, применяемый для доступа к базам данных Microsoft SQL Server 6.5 и 7.0.
Провайдер сервисов (или сервисный компонент) реализует расширенную функциональность, не поддерживаемую обычными провайдерами данных, например сортировку и фильтрацию данных, обработку транзакций и SQL-запросов, управление курсором и др. Сервисный компонент может обращаться к хранилищу данных непосредственно или с помощью соответствующего провайдера данных — в этом случае провайдер сервисов является одновременно и провайдером, и потребителем. Например, сервисные компоненты, такие как Microsoft Cursor Service for OLE DB и Microsoft Data Shaping Service for OLE DB, могут использоваться совместно с провайдерами данных OLE DB для расширения их функциональности.
На рис. 2 показано, как компоненты OLE DB взаимодействуют между собой. Из рисунка следует, что потребитель может получать данные как непосредственно с помощью провайдера данных, так и с использованием сервисов, предоставляемых сервисными компонентами.
В табл. 1 приведен список провайдеров, доступных в составе набора MDAC (Microsoft Data Access Components), поставляемого с рядом продуктов Microsoft.
Как мы уже писали, OLE DB представляет собой набор COM-интерфейсов. На рис. 3 схематически представлены четыре основных объекта и их интерфейсы, а также методы, с помощью которых они взаимодействуют.
Отметим, что каждый OLE DB-провайдер должен содержать реализацию объектов DataSource, Session и Rowset. Помимо трех основных объектов могут быть и другие.
Рассмотрим эти объекты более подробно.
|
|
|
Объекты OLE DB
Объектная модель OLE DB содержит четыре ключевых объекта:
- DataSource;
- Session;
- Command;
- Rowset.
|
|
|
Объект DataSource
Объект DataSource, применяемый потребителями данных для соединения с провайдером, может быть создан различными способами, включая вызов функции CoCreateInstance с идентификатором класса (CLSID, Class Identifier) OLE DB-провайдера, использование объекта Enumerator (см. ниже), который занимается поиском источников данных, и пр. Объект DataSource инкапсулирует информацию, связанную с соединением (включая имя пользователя и пароль). Основное назначение этого объекта — предоставлять данные из источника данных потребителю.
Для создания новой сессии (объект Session) потребитель должен вызвать метод CreateSession интерфейса IDBCreateSession объекта DataSource.
|
|
|
Объект Session
Объект Session предоставляет контекст для транзакций, может генерировать наборы данных (rowsets) из источников данных, а также команды для запросов к источнику данных. Объект Session может выполнять роль фабрики классов для объектов Command и Rowset (см. ниже) и объекта Transaction, применяемого для управления вложенными транзакциями. Объекты Command и Rowset могут быть использованы для создания или модификации таблиц и индексов. Интерфейс IOpenRowset используется потребителями данных для работы с отдельными таблицами и индексами в хранилище данных.
С одним объектом DataSource может быть связано несколько объектов Session.
Если OLE DB-провайдер поддерживает команды или запросы, он должен уметь порождать объект Command. С одним объектом DataSource может быть связано несколько объектов Command. Для создания нового объекта Command применяется метод CreateCommand интерфейса IDBCreateCommand.
|
|
|
Объект Command
Объект Command используется для выполнения команд, представляющих собой строки, передаваемые от потребителя данных объекту Data Source для выполнения. В большинстве случаев такая команда представляет собой SQL-предложение SELECT, однако в общем случае это может быть любое другое SQL-предложение (например, DDL-предложение). Команды могут содержать параметры — в этом случае применяется интерфейс ICommandWithParameters. Одна сессия может порождать несколько команд. Результатом выполнения команды (с помощью метода Execute интерфейса ICommand) обычно является новый объект Rowset.
|
|
|
Объект Rowset
Объект Rowset (набор данных) позволяет OLE DB-провайдеру данных представлять данные из источников данных в табличном формате, то есть в виде набора строк, содержащих одну или несколько колонок. Этот объект может быть результатом выполнения команды или может быть сгенерирован непосредственно провайдером данных, если провайдер не поддерживает команд. Все провайдеры данных «умеют» создавать наборы данных напрямую. Объект Rowset может быть также использован для обновления, добавления или удаления строк — это зависит от функциональности провайдера данных.
С помощью интерфейса IRowset из объекта Rowset потребители могут перемещаться по набору данных вперед и, если набор данных позволяет, назад. Некоторые провайдеры могут предоставлять дополнительные функции наподобие непосредственного доступа или определения примерной позиции данной строки в наборе.
Частным случаем объекта Rowset является объект Index, предоставляющий набор строк, использующий соответствующий индекс для получения набора данных в упорядоченном виде.
Существуют также специальные объекты типа Rowset — schema rowsets, содержащие метаданные (то есть сведения о структуре данных), и view rowsets, содержащие подмножество строк и столбцов объекта Rowset.
Помимо четырех основных объектов, перечисленных выше, существуют и другие объекты OLE DB. Они нужны для перечисления источников данных, управления транзакциями, обработки ошибок и др. Некоторые из них мы рассмотрим ниже.
|
|
|
Объект Enumerator
Объект Enumerator необходим для получения списка доступных объектов, обеспечивающих доступ к источникам данных (OLE DB-провайдеров). Этот объект используется потребителями данных для поиска соответствующих объектов. В большинстве случаев сведения, возвращаемые объектом Enumerator, извлекаются из системного реестра. Этот объект реализует интерфейс ISourceRowset и возвращает объект Rowset с описанием всех источников данных и других доступных с его помощью объектов Enumerator. Для этой цели используется метод GetSourcesRowset интерфейса ISourceRowset.
