Мир объектов Excel 2000



              

Интерфейс 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.




Содержание  Назад  Вперед