2.1.2. Организация доступа к данным

Выбор технологии доступа к данным является одной из стратегических задач, от решения которой зависит как производительность будущей системы и способность реализовывать дополнительные функции, так и совместимость ее с другими программными платформами и технологиями, переносимость с одной платформы на другую.[5]

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

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

Рассмотрим наиболее популярные на сегодняшний день технологии доступа к данным. На сегодняшний день наиболее популярными технологиями доступа к данным являются технологии, разработанные корпорацией Microsoft, которые можно применять для доступа к большинству существующих источников данных.

Раньше в Microsoft ключевыми технологиями доступа к данным считались Data Access Objects (DAO) для настольных систем и Remote Data Objects (RDO), основанная на Open Database Connectivity (ODBC), – для клиент-серверных баз данных. Но на смену им пришла единая модель Universal Data Access (UDA), поддерживающая данные любых типов.

Цель UDA – обеспечить высокопроизводительный доступ как к нереляционным, так и к реляционным источникам данных, предоставив удобный, независимый от инструментальных средств и языка интерфейс программирования.

Согласно утверждению Microsoft, Universal Data Access представляет собой «стратегию обеспечения доступа ко всем типам информации, используемой в масштабах предприятия (фирмы). Она обеспечивает высокопроизводительный доступ к различным информационным источникам (включая как реляционные, так и нереляционные данные), в том числе к базам данных мэйнфреймов ISAM/VSAM, а также к иерархическим базам данных; файлам электронной почты и файловой системе; текстовым, графическим и географическим данным и так далее». Более того, поскольку хранение информации продолжает совершенствоваться, появляются новые форматы данных и это должно учитываться при разработке приложений. Таким образом, нам действительно необходим некий универсальный метод доступа к данным, предоставляющий интерфейс, как существующим форматам данных, так и тем, которые могут появиться в будущем. [8]

Главная цель Microsoft Universal Data Access состоит в обеспечении доступа ко всем вышеупомянутым типам данных с помощью единой модели.

В настоящее время Universal Data Access взаимодействует со всеми основными платформами баз данных, а также с некоторыми источниками данных, не относящимися к СУБД, облегчая разработку приложений с использованием баз данных посредством общих интерфейсов.

Архитектура Universal Data Access включает в себя следующие элементы.

1. Microsoft ActiveX Data Objects (ADO) представляет собой интерфейс прикладного программирования для доступа к данным, хранящимся в различных источниках. С точки зрения программиста, ADO и его расширения являются упрощенным высокоуровневым объектно-ориентированным интерфейсом для работы с OLE DB.

2. OLE DB предоставляет низкоуровневый интерфейс доступа к данным в масштабе предприятия. ADO работает «за кулисами» с OLE DB, однако, в случае необходимости, мы можем непосредственно использовать OLE DB.

3. Open Database Connectivity (ODBC) является стандартом Microsoft для работы с реляционными данными. Этот компонент служит для обеспечения совместимости с более ранними разработками, так как в современных решениях его роль играют собственные провайдеры OLE DB.

Поскольку в данной разработке предполагается использовать технологию доступа к данным, ADO то рассмотрим ее более подробно.

ActiveX Data Objects (ADO)

ADO реализует высокопроизводительный и удобный прикладной интерфейс для OLE DB. Технология ADO нетребовательная к системным ресурсам, создает минимальную нагрузку на сеть и отличается минимальным числом уровней между приложением и источником данных. ADO предоставляет COM интерфейс Automation, поэтому она поддерживается любой ведущей инструментальной средой быстрой разработки приложений, а также другими инструментальными средствами разработки баз данных, приложений и сценариев.

Разработчики ADO постарались объединить в ней все лучшее, что было в RDO и DAO, предполагалось, что по мере возможности ADO заменить собой эти технологии. В ней применяются похожие соглашения, но с упрощенной семантикой, что представляет собой усовершенствованную версию RDO Data Source Control.

Часть ADO, носящая название службы удаленных данных (Remote Data Service, RDS), отвечает за передачу клиентам отсоединенных наборов записей по протоколу HTTP или Distributed COM (DCOM), что позволяет разрабатывать полнофункциональные, ориентированные на работу с данными Web приложения.

Объектная модель ADO показана на рис. 2.2 и призвана обеспечить доступ к наиболее часто применяемым функциям OLE DB. ADO состоит из трех основных компонентов: объекта Connection, объекта Command и объекта Recordset.

Объект Connection устанавливает соединение между приложением и внешним источником данных, например SQL Server. Кроме того, он отвечает за инициализацию и создание подключения, выполнение запросов и механизм транзакций. В объектной модели ADO Connection находится на вершине иерархии объектов.[8]

Объект Command формирует запросы на выборку записей из источников данных, учитывая заданные пользователем параметры. Как правило выбранные записи возвращаются в объекте Recordset. Объект Command создается на базе таблицы БД или результатов SQL запроса. Кроме того, можно задать отношения между несколькими объектами Command для представления взаимосвязанных данных в виде иерархической структуры.

Рис. 2.2. Объектная модель ADO

Объект Recordset обеспечивает доступ к записям, выбранным SQL запросом, его применяют для редактирования, добавления или удаления записей в источнике данных.

Отличие объектной модели ADO от DAO и RDO состоит в том, что многие ее объекты независимы друг от друга. Иерархия объектов ADO допускает создание только непосредственно нужных объектов, когда экземпляры Recordset, Connection и Command порождаются напрямую без создания их родителей. Например, можно создать Recordset без явной инициализации объекта Connection – ADO сделает это самостоятельно.

В настоящее время с появлением и активным развитием платформы Microsoft .NET дальнейшее развитие получила и технология ADO, которая стала более универсальной и ориентированной на создание распределенных приложений. Универсальность ее достигается во многом благодаря использованию языка XML, являющегося сегодня стандартом обмена данными между различными системами и средами.