Технологии доступа к данным

Одной из основных задач, необходимых решить проектировщику или программисту ИС - это выбор технологии доступа к БД. Выбор технологии доступа к данным является одной из стратегических задач, от решения которой зависит как производительность будущей системы и способность реализовывать дополнительные функции, так и совместимость ее с другими программными платформами и технологиями, переносимость с одной платформы на другую.

Существует несколько способов решения задачи обеспечения доступа к данным.

Во многих современных СУБД имеются библиотеки, содержащие специальный интерфейс прикладного программирования (API), который представляет собой набор функций для манипулирования данными. В СУБД для настольных систем API осуществляет лишь чтение и запись данных в БД. В СУБД типа клиент/сервер API инициирует отправку по сети запроса к серверу и получение результатов или кодов ошибок для дальнейшей их обработки клиентским приложением.

Один из способов доступа к данным заключается в непосредственном использовании API, однако это означает полную зависимость приложения от используемой СУБД. Таким образом, необходим некий универсальный механизм доступа к данным, обеспечивающий для клиентского приложения стандартный набор общих функций, классов, сервисов, служб, необходимых для работы с различными СУБД. Эти стандартные функции (классы или сервисы) должны размещаться в библиотеках, именуемых драйверами или провайдерами баз данных (data base drivers (providers)). Каждая такая библиотека реализует набор стандартных функций, классов или сервисов, используя обращения API к конкретной системе управления базами данных.

4.3.1. Открытый интерфейс доступа к базам данных – ODBC

Основа ODBC

Интерфейс ODBC (Open Database Connectivity) был разработан фирмой Microsoft как открытый интерфейс доступа к базам данных. Он предоставляет унифицированные средства взаимодействия прикладной программы, называемой клиентом (или приложением-клиентом), с сервером - базой данных.

В основу интерфейса ODBC были положены спецификация CLI-интерфейса (Call-Level Interface), разработанная X/Open, и ISO/IEC для API баз данных, а также язык SQL (Structured Query Language) как стандарт языка доступа к базам данных.

Интерфейс ODBC проектировался для поддержки максимальной интероперабельности приложений, которая обеспечивает унифицированный доступ любого приложения, использующего ODBC, к различным источникам данных. Так, если приложение, соответствующее стандарту ODBC и SQL, первоначально разрабатывалось для работы с базой данных Microsoft Access, а затем таблицы этой базы были перенесены в базу данных Microsoft SQL Server или базу данных Oracle, то приложение сможет и дальше обрабатывать эти данные без внесения дополнительных изменений.

Для взаимодействия с базой данных приложение-клиент вызывает функции интерфейса ODBC, которые реализованы в специальных модулях, называемых ODBC-драйверами. Как правило, ODBC-драйверы - это DLL-библиотеки, при этом одна DLL-библиотека может поддерживать несколько ODBC-драйверов. При установке на компьютер любого SQL-сервера (базы данных, поддерживающей один из стандартов языка SQL, например, SQL-92) автоматически выполняется регистрация в реестре Windows и соответствующего ODBC-драйвера.

Архитектура ODBC

Архитектура ODBC представлена четырьмя компонентами Рис. 75:

· Приложение-клиент, выполняющее вызов функций ODBC.

· Менеджер драйверов, загружающий и освобождающий ODBC-драйверы, которые требуются для приложений-клиентов. Менеджер драйверов обрабатывает вызовы ODBC-функций или передает их драйверу.

· ODBC-драйвер, обрабатывающий вызовы SQL-функций, передавая SQL-серверу выполняемый SQL-оператор, а приложению-клиенту - результат выполнения вызванной функции.

· Источник данных, определяемый как конкретная локальная или удаленная база данных.

Рис. 75. Архитектура ODBC

Основное назначение менеджера драйверов - загрузка драйвера, соответствующего подключаемому источнику данных, и инкапсуляция взаимодействия с различными типами источников данных посредством применения различных ODBC-драйверов.

ODBC-драйверы, принимая вызовы функций, взаимодействуют с приложением-клиентом, выполняя следующие задачи:

· управление коммуникационными протоколами между приложением-клиентом и источником данных;

· управление запросами к СУБД;

· выполнение передачи данных от приложения-клиента в СУБД и из базы данных в приложение-клиент;

· возвращение приложению-клиенту стандартной информации о выполненном вызове ODBC-функции в виде кода возврата;

· поддерживает работу с курсорами и управляет транзакциями.

Приложение-клиент одновременно может устанавливать соединения с несколькими различными источниками данных, используя разные ODBC-драйверы, а также несколько соединений с одним и тем же источником данных, используя один и тот же ODBC-драйвер.

Функции ODBC API

Все функции ODBC API условно можно разделить на четыре группы:

· основные функции ODBC, обеспечивающие взаимодействие с источником данных;

· функции установки (setup DLL);

· функции инсталляции (installer DLL) ODBC и источников данных;

· функции преобразования данных (translation DLL).

Объявления всех функций и используемых ими типов данных содержатся в заголовочных файлах. Группа основных функций ODBC API разбита на три уровня:

· функции ядра ODBC;

· функции 1 уровня;

· функции 2 уровня.

 

Интерфейс ODBC API реализован как набор расслоенных DLL-функций для Windows. Динамическая библиотека ODBC.DLL – это основная библиотека управления драйверами ODBC, которая содержит функции вызовов специализированных драйверов для разных поддерживаемых системой баз данных. Каждый драйвер совместим со своим уровнем и относится к одной из двух категорий: одноуровневые или многоуровневые драйверы.

Одноуровневые драйверы предназначены для использования при работе с теми источниками данных, которые не могут быть прямо обработаны с использованием ANSI SQL. Обычно это локальные базы данных на персональных компьютерах, такие как dBase, Paradox, FoxPro и Excel. Драйверы, соответствующие этим базам данных, производят компиляцию ANSI SQL в наборы инструкций более низкого уровня, которые непосредственно обрабатывают составляющие базу данных файлы.

Многоуровневые драйверы используют сервер СУБД для обработки SQL-предложений и предназначены для работы в среде клиент-сервер. Помимо обработки ANSI SQL, они также могут поддерживать и собственные конструкции конкретной РСУБД, поскольку ODBC может без трансляции передавать SQL-операторы источникам данных (механизм "passthrough"). Драйверы ODBC для баз данных, поддерживаемым в технологии клиент-сервер реализованы для практически для всех промышленных серверов БД.

Существует 4 важных этапа (шага) процедуры запроса данных через ODBC API.

· Шаг 1 - установление соединения. Первый шаг состоит в размещении указателей (handle) среды ODBC, которые выделяют оперативную память под ODBC драйверы и библиотеки. Затем происходит выделение памяти для указателей соединения, и соединение устанавливается.

· Шаг 2 - выполнение оператора SQL. Выделяется указатель оператора, локальные переменные связываются со столбцами в SQL-выражении (это необязательное действие), и выражение представляется главному ODBC-драйверу для обработки.

· Шаг 3 - извлечение данных. Перед извлечением данных возвращается информация о результирующем наборе, в частности, число столбцов в наборе. Исходя из этого числа, результирующий набор помещается в буфер записей, выполняется цикл его просмотра и содержимое каждого столбца помещается в соответствующую локальную переменную. Этот шаг необязателен, если используется связывание столбцов с локальными переменными.

· Шаг 4 - освобождение ресурсов. После того, как данные получены, ресурсы освобождаются путем вызова функций освобождения указателей оператора, соединения и среды. Указатели оператора и соединения могут быть использованы в процессе обработки.

Технология ODBC разрабатывалась как общий, независимый от источников данных, способ доступа к данным. Применение технологии должно было также обеспечить переносимость приложений в среду различных баз данных без потребности переработки самих приложений. В этом смысле технология ODBC уже стала промышленным стандартом, ее поддерживают практически все производители СУБД и средств разработки.

Однако универсальность стоит дорого. Если при разработке приложений одним из основных критериев является переносимость на различные СУБД, то использование ODBC является оправданным. Для увеличения производительности и эффективности приложения активно применяют специфические для данной СУБД расширения языка SQL, используют хранимые на сервере процедуры и функции. В этом случае теряется роль ODBC как общего метода доступа к данным. Тем более, что для разных СУБД драйверы ODBC поддерживают разные уровни совместимости. Поэтому многие производители средств разработки, помимо поддержки ODBC, поставляют "прямые" драйверы к основным СУБД.

Объектная модель OLE DB

OLE DB представляет собой набор COM-интерфейсов (Component Object Model), которые предоставляют приложению-клиенту унифицированный доступ к различным источникам данных.

Можно сказать, что OLE DB - это метод доступа к любым данным через стандартные COM-интерфейсы, вне зависимости от типа данных и места их расположения. В качестве данных могут выступать базы данных, простые документы, таблицы Excel и любые другие источники данных. В отличие от доступа, предоставляемого посредством драйверов OBDC, OLE DB позволяет реализовывать доступ к источникам данных, как с применением языка SQL (к SQL-серверам), так и к любым другим произвольным источникам данных.

Средства, предоставляющие доступ к источнику данных с использованием технологии OLE DB, называются OLE DB провайдерами. Программы-клиенты, использующие для доступа OLE DB провайдеры, называются потребителями данных.

В том случае, если существует только ODBC-драйвер для доступа к конкретному источнику данных, то для применения технологии OLE DB можно использовать OLE DB провайдер, предназначенный для доступа к ODBC-источнику данных.

Так как архитектура OLE DB основана на COM, то механизм создания результирующих наборов состоит из последовательностей шагов типа: 1. создание объекта -> 2. запрос указателя на интерфейс созданного объекта -> 3. вызов метода интерфейса.

Аналогично комплексу действий, который производится после создания результирующего набора при применении технологии ODBC - выполнению связывания, в технологии OLE DB используется механизм аксессоров. Аксессоры описывают, каким образом данные записываются в область памяти потребителя данных, устанавливая адресное соответствие между областью памяти в буфере потребителя данных и столбцами данных в результирующем наборе. Иногда такой набор связей называют картой столбцов (column map).

Спецификация OLE DB описывает набор интерфейсов, реализуемых объектами OLE DB. Каждый объектный тип определен как набор интерфейсов. Спецификация OLE DB определяет набор интерфейсов базового уровня, которые должны реализовываться любыми OLE DB провайдерами.

В базовую модель OLE DB входят следующие объекты:

· объект DataSource (источник данных), используемый для соединения с источником данных и создания одного или нескольких сеансов. Этот объект управляет соединением, использует информацию о полномочиях и аутентификации пользователя;

· объект Session (сеанс) управляет взаимодействием с источником данных - выполняет запросы и создает результирующие наборы. Сеанс также может возвращать метаданные. В сеансе может создаваться одна или несколько команд;

· объект Rowset (результирующий набор) представляет собой данные, извлекаемые в результате выполнения команды или создаваемые в сеансе.

OLE DB представляет собой интерфейс системного уровня, обеспечивающий доступ к различным источникам данных – реляционным и нереляционным, содержащим текст, графические и географические данные, к файлам электронной почты, содержимому файловых систем и создаваемым пользователями бизнес-объектам. OLE DB определяет набор интерфейсов компонентной объектной модели (Component Object Model, COM), включающих в себя службы различных систем управления базами данных для обеспечения универсального доступа к данным. С помощью этих интерфейсов программисты могут создавать дополнительные сервисы баз данных.

Любой компонент программного обеспечения, который использует интерфейсы OLE DB, является потребителем OLE DB. Это может быть бизнес-приложение, инструментальное средство разработки программного обеспечения, например, Borland Delphi, сложные приложения или же объектная модель ActiveX Data Objects, использующая интерфейсы OLE DB. Потребители используют либо те ActiveX Data Objects (ADO), которые являются интерфейсом прикладного уровня для обеспечения косвенного (indirect) доступа к данным с применением OLE DB, либо непосредственно OLE DB – для прямого доступа к данным с помощью провайдера OLE DB.

С точки зрения OLE DB, может быть два вида провайдеров: OLE DB - провайдеры данных и провайдеры сервисов (служб).

Провайдер данных (data provider) представляет собой компонент программного обеспечения, "владеющий" данными. Он находится между потребителем и непосредственным массивом данных. В OLE DB все провайдеры представляют данные в табличном формате (с которым мы уже знакомы по реляционным базам данных и электронным таблицам), в виде виртуальных таблиц. Провайдер данных выполняет следующие задачи.

· Принимает запросы, поступающие от потребителя, на доступ к данным.

· Выполняет выборку или обновление данных из массива данных.

· Возвращает эти данные потребителю.

Одним из примеров провайдера данных служит Microsoft Jet 4.0 OLE DB Provider. Он используется совместно с механизмом доступа к базам данных Microsoft Jet, применяемым для обработки информации в базах данных Microsoft Access, а также для доступа как к базам данных к информации, упорядоченной с помощью так называемого инсталлируемого индексно-последовательного метода доступа (Indexed Sequential Access Method, I-ISAM), который поддерживается в Jet. К таким данным относятся таблицы, хранимые в рабочих книгах Excel, почтовые файлы Outlook и Microsoft Exchange, таблицы dBase и Paradox, текстовые и HTML-файлы и т. д. Другим провайдером OLE DB является Microsoft OLE DB Provider for SQL Serwer, используемый для работы с базами данных Microsoft SQL Server 6.5, 7.0, 2000.

Провайдер сервисов (служб) реализует расширенные функциональные возможности, которые не поддерживаются обычными провайдерами данных, и сам не "владеет" данными. Этот провайдер, например, обеспечивает сортировку, фильтрацию, управление транзакциями, обработку SQL-запросов, функции указателя (курсора) и т. д. Провайдер сервисов может напрямую работать с массивами данных или же через соответствующий провайдер данных; в этом случае он выступает в роли потребителя и провайдера.

Например, такие провайдеры сервисов, как Microsoft Cursor Service for OLE DB и Microsoft Data Shaping Service for OLE DB могут интегрироваться с базовыми провайдерами данных OLE DB для расширения их функциональных возможностей.
Такие провайдеры сервисов, как Microsoft Cursor Service for OLE DB и Microsoft Data Shaping Service for OLE DB могут интегрироваться с базовыми провайдерами данных OLE DB для расширения их функциональных возможностей.