Объекты ADO

Разработчику приложений не обойтись в своей работе без использования разнообразных источников данных. Как я уже говорил, тема баз данных весьма обширна и не является основным предметом данной книги. Но для VBA-программиста связь с самыми разными источниками данных может, как правило, осуществляться единообразно с использованием одного и того же интерфейса, и значительную роль при этом будут играть объекты ADO - ActiveX Data Object. Учитывая их важность, я постараюсь рассказать о них достаточно подробно. Но прежде давайте рассмотрим общую картину и ту стратегию доступа к данным, которую Microsoft реализует в семействе своих операционных систем.

Универсальный доступ к данным и ADO

Microsoft предлагает своим пользователям и, прежде всего, разработчикам корпоративных приложений единую стратегию доступа к данным - Universal Data Access (UDA), не зависящую, в высокой степени, от типа используемых хранилищ данных, применяемых инструментальных средств и языков программирования. В основе этой стратегии лежат компоненты доступа к данным - Microsoft Data Access Components (MDAC). Три базисных интерфейса и, соответственно, три группы объектов определяют UDA и MDAC:

• Низко уровневый, высоко эффективный по производительности COM-интерфейс баз данных - интерфейс OLE DB (OLE Data Base), позволяющий получать доступ как к реляционным (табличным), так и не реляционным (иерархическим и потоковым) базам данных.
• Низко уровневый, высоко производительный интерфейс ODBC (Open Data Base Connectivity), специально спроектированный для связи с различными реляционными базами данных и структурированным языком запросов SQL (Structured Query Language).
• Интерфейс высокого уровня ADO, являющийся надстройкой над интерфейсом OLE DB, позволяющий получать легкий доступ к данным при работе не только на VC, но и на VB/VBA и VB Script.

Начиная с Windows 2000, MDAC является частью операционной системы. Microsoft создала специальный Web-узел - Microsoft Universal Data Access Web site, на котором можно найти последние версии компонент и свободно произвести обновление операционной системы от Windows 95 до Windows Me.

Поскольку для VBA - разработчика, как я уже говорил, наибольший интерес представляет интерфейс верхнего уровня - ADO, то я ограничусь лишь штрихами к портрету низкоуровневых интерфейсов.

Интерфейс OLE DB

Целевая установка при разработке этого интерфейса была следующей. Решения в сфере бизнеса нужно принимать оперативно. Эти решения должны быть основаны на полной и достоверной информации. Конечно же, основным источником данных для принятия решений является корпоративная база данных, например, MS SQL Server или Oracle. Но только этих данных, как правило, недостаточно для принятия оперативного решения. Необходимо учитывать данные, хранящиеся в личных базах данных, таких как Microsoft Access или FoxPro. Необходимые данные необходимо уметь извлекать из систем электронной почты. Данные могут храниться в индексно-последовательных файлах системы Betrieve, может быть, просто в бинарных файлах, наконец, в документах Office 2000, например, в списках Excel. Все возрастающую роль, как источника данных, играют Web-страницы интернет. Чтобы обеспечить единообразный способ работы с разнообразными источниками данных и создавался интерфейс OLE DB, представляющий некоторое множество интерфейсов, основанных на стандарте COM (Component Object Model).

Кратко опишу основные понятия (объекты), составляющие концептуальную и объектную модель OLE DB. Процесс работы с данными можно описать в терминах взаимодействия двух объектов - Поставщика данных (Provider) и Потребителя данных (Consumer). Потребителем является приложение, запрашивающее данные и непосредственно вызывающее функции, заданные интерфейсом. Поставщик данных или Провайдер - это приложение, экспонирующее функции интерфейса, - это тот посредник, стоящий между приложением, запрашивающим данные, и источником данных. Функциональные возможности набора COM-интерфейсов могут зависеть от Провайдера, от того, как тот или иной Провайдер реализует функциональность интерфейса для конкретного источника данных. Для наиболее часто используемых источников данных фирмой Microsoft, так и другими фирмами, разработаны ряд Провайдеров, ставших стандартами "де факто".

Разработчики, создающие Провайдеров, отображают функциональность, присущую конкретному источнику данных в функциональность, определенную интерфейсом. Разработчики, создающие терминальное приложение - Потребителя данных, - вызывают функции, экспонируемые Провайдером, для получения доступа к данным. Позже я чуть подробнее расскажу о различных экземплярах объекта Provider, обеспечивающих связь с различными источниками данных. Провайдеры поддерживают не только непосредственный доступ к данным, но и другие службы (Services) - транзакции, удаленный доступ, структуризацию кэш-памяти (cache) и другие службы. Кэш-память - это промежуточная память, в которой происходит изменение данных, их обновление, удаление и добавление, пока не наступает момент фактического обмена данными между кэш-памятью и источником данных.

Когда Потребитель связывается с Провайдером и обращается к нему за данными, то он должен вначале создать и инициализировать экземпляр объекта, задающий источник данных данного Провайдера (data source object). С помощью этого объекта можно создать второй центральный объект Провайдера - объект Session. Имея в своем распоряжении объект, задающий сеанс работы, можно уже создать и работать с собственно объектами, определяющими работу с данными - транзакциями, командами, наборами строк (объектами Transaction, Command, Rowset). Говоря о связывании Потребителя и Провайдера, следует упомянуть, что OLE DB определяет возможность использования адресов ресурсов - Uniform Resource Locators (URLs) как альтернативу связывания с помощью строки связывания (Connection String). Адреса URLs могут быть использованы для указания хранилищ данных, строк данных, потоков, наборов строк, объектов Session. Процесс связывания объекта OLE DB с ресурсом, именованным с помощью URL, называется прямым связыванием. При таком способе связывания можно даже и не инициализировать объект Session.

На этом я закончу беглое знакомство с основными понятиями и концепциями OLE DB. Позже я более подробно остановлюсь на рассмотрении объектов верхнего уровня - объектах ADO, которые транслируются в объекты OLE DB, и объектная модель которых на более высоком уровне повторяет объектную модель OLE DB.

Интерфейс ODBC

Скажу несколько слов об интерфейсе ODBC . Он был создан для того, чтобы дать возможность приложению - Потребителю данных - получать данные из различных систем управления базами данных (СУБД - Data Base Management System - DBMS). При этом концептуальная схема работы такова - приложение через набор соответствующих API-функций, которые, собственно говоря, и составляют интерфейс ODBC, обращается к объекту, называемому Менеджер драйверов (Driver Manager). Последний, опять-таки через тот же набор API- функций обращается к драйверу источника данных. Замечу, что большинство существующих баз данных имеют соответствующие драйверы и, следовательно, являются ODBC-источниками данных. Следует также отметить, что языком запросов в этой модели выступает SQL. Взаимодействие четырех основных объектов: Потребителя, Менеджера Драйверов, Драйвера и Источника данных - и определяет концептуальную модель ODBC.

Семейство объектов ADO

Перейдем теперь к подробному рассмотрению объектов ADO - наиболее интересных для VBA-программистов. Более точно, следует говорить о семействе объектов ADO, в которое входят три группы объектов:

• ADO - ActiveX Data Objects. Иногда, когда говорят об объектах ADO, имеют в виду именно объекты этой группы. Эти объекты, как я уже говорил, являются надстройкой над объектами OLE DB. Их назначение - решать те же задачи, ради которых был создан интерфейс OLE DB, но на более высоком языковом уровне общения. В первую очередь эти объекты создавались для того, чтобы дать возможность создавать клиент-серверные и WEB-ориентированные приложения на VB/VBA и VBScript. Вот три главных объекта, находящихся на верхнем уровне иерархии этой группы объектов:
  • Connection - позволяет установить соединение с Провайдером.
  • Command - позволяет задать команду Провайдеру, определяющую операцию, выполняемую над данными.
  • Recordset - сохраняет результаты выполненной команды и обеспечивает, тем самым, возможность работы с результатами запросов и хранимых процедур.
• ADOX - ActiveX Data Objects Extensions for Data Definition Language and Security. Объекты этой группы дополняют функциональные возможности объектов первой группы. Они позволяют манипулировать не с данными, а с объектами более высокого уровня - схемами данных. С их помощью можно модифицировать схему данных, создавать, изменять и удалять ее объекты, например таблицы базы данных. Другое назначение этих объектов - управлять безопасностью доступа к данным, - назначать и изменять права доступа к данным, создавать группы пользователей, обладающих определенными правами. Центральными объектами в этой группе, находящимися на верхнем уровне иерархии, являются объекты Catalog, User, Group. Первый из этих объектов задает источник данных, - он соответствует объекту DataBase в модели объектов DAO. Объекты User и Group позволяют управлять безопасностью доступа, как отдельного пользователя, так и пользователей, объединенных в группы.
• ADO MD - ActiveX Data Objects MultiDimensional. Также как и обычные ADO-объекты, эти объекты являются надстройкой над интерфейсом OLE DB. Их назначение состоит в том, чтобы обеспечить возможность работы с многомерными источниками данных. Для того, чтобы работа с этим объектами была возможной, соответствующий Провайдер должен быть Провайдером многомерных данных (MDP Provider) и удовлетворять специальным спецификациям - OLE DB for OLAP. В этом случае данные представляются не в виде таблиц, а в виде кубов данных. Центральными в этой группе являются объекты CubeDef и CellSet, которые обеспечивают определение куба данных и доступ к множеству ячеек этого куба.

Каждая из трех групп ADO-объектов находится в отдельной DLL библиотеке и подключается к программному проекту независимо друг от друга обычным способом - вручную через меню References, либо программно. Замечу, что описание объектов, которое я буду приводить, соответствует версии библиотеки 2.6, - последней на момент написания данного текста, хотя примеры, которые я буду приводить, разработаны на предыдущей версии 2.5.