Обзор технологий доступа к данным для операционной системы Windows Текст научной статьи по специальности «Компьютерные и информационные науки»

ОБЗОР ТЕХНОЛОГИЙ ДОСТУПА К ДАННЫМ ДЛЯ ОПЕРАЦИОННОЙ СИСТЕМЫ WINDOWS

В.А. Козак Научный руководитель - А.А. Малинин

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

Введение

На сегодняшний день разработаны сотни баз данных различных типов, способных работать на компьютерах любой мощности - от мэйнфреймов до карманных компьютеров и других портативных мобильных устройств [1]. Кроме того, с каждым годом компьютеры одной организации или нескольких различных организаций все чаще соединяются друг с другом. Поэтому возникает необходимость в налаживании совместного доступа к базам данных по сети. Главным препятствием для совместного использования баз данных является несовместимость системного программного обеспечения и приложений, работающих на разных компьютерах.

С середины 1980-х годов программисты пытаются создать универсальный программный интерфейс API, который позволил бы им разрабатывать приложения, одинаковым образом взаимодействующие с различными источниками данных. За истекшее время было предложено множество решений в этой области. В данной работе производится обзор наиболее весомых технологий доступа к данным для операционной системы Windows. Большое внимание уделяется рассмотрению их архитектур и составных компонентов, выявляются достоинства и недостатки, а также описываются возможности доступа рассматриваемых технологий к различным источникам данных. К источникам могут относиться, например, различные базы данных, индексно-последовательный файл (ISAM file), текстовый файл (например, в формате XML) и т.д. Определяются возможности интеграции локальных и Web-приложений с базами данных. Представлена информация о том, какие технологии лучше использовать для локальных данных, а какие - для удаленных. Одним из основополагающих предыдущих исследований в данной области является статья Аша Рофаляя (Ash Rofail) и Яссера Шоуда (Yasser Shohoud) «VS 6.0 Benchmarks: New Features Don't Impact Speed», опубликованная в журнале VBPJ [2]. Кроме того, существует еще ряд довольно мощных работ, но в большинстве из них рассматриваются две-три технологии. В данном же обзоре освещены все значительные разработки в данной области, включая последнюю технологию компании Microsoft - ADO.NET.

Основная часть

Наиболее значительным среди ранних решений является ODBC (Open DataBase Connectivity, открытый интерфейс доступа к базам данных) - это стандартный интерфейс между базой данных и приложением, взаимодействующим с ней.

Первая версия Microsoft ODBC вышла в свет в 1992 году. Сейчас повсеместно используется третья версия ODBC, которая была представлена в 1996 году. ODBC выполнен в виде набора функций. Этот интерфейс создавался для доступа к реляционным базам данных. Сейчас же это единый универсальный интерфейс, позволяющий приложениям работать с СУБД различных типов, для которых имеется драйвер ODBC. Менеджер драйверов (Driver Manager) взаимодействует с приложением и обеспечивает загрузку драйвера, необходимого для доступа к конкретному источнику данных.

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

Интерфейс ODBC состоит из четырех функциональных компонентов, отраженных на рис. 1.

Рис. 1. Компоненты ODBC [3]

Благодаря каждому из них достигается гибкость ODBC, позволяющая взаимодействовать любым ODBC-совместимым клиентам и серверам. Ниже представлено описание этих компонентов.

• Приложение - часть ODBC, с которой непосредственно работает пользователь.

• Менеджер драйверов - библиотека динамической компоновки (dinamic link library, DLL), которая загружает необходимый драйвер.

• Драйвер - программный модуль, получающий вызовы функций посредством стандартного интерфейса ODBC и переводящий их в код, понятный источнику данных. Как только источник данных возвращает результат, драйвер в обратном порядке преобразует его в стандартный для ODBC вид.

• Источники данных - различные базы данных, индексно-последовательные файлы (ISAM file), текстовые файлы (например, в формате XML) и т.д. [3].

Неоспоримыми достоинствами ODBC являются его быстродействие, мощность, гибкость и переносимость исходного кода. Главный недостаток - сложность использования.

Проблема ODBC в его структуре - это просто набор функций. Такая структура подходит для процедурных языков, таких как С, но не соответствует принципам объектно-ориентированного программирования. Сегодняшние прикладные программисты привыкли работать с объектами, и на смену программным интерфейсам пришли объектные. В конце 1992 - начале 1993 года появились DAO (Data Access Objects) и RDO (Remote Data Objects). Появление двух разных механизмов было связано с необходимостью оптимизации решения двух отдельных задач: доступа к локальным и удаленным базам данных соответственно.

DAO (объекты для доступа к данным) - объектно-ориентированная технология доступа к данным компании Microsoft. DAO 1.0 появилась в ноябре 1992 года как API к системе баз данных Jet. Технология Jet поддерживала доступ к файлам формата MDB (Microsoft Access) и к источникам данных ISAM. Начиная с версии 3.1, появилась возможность использовать API DAO, не используя при этом язык БД Jet. В DAO 3.5 были

реализованы уже две объектных модели, первая работала с базами данных Microsoft Jet, вторая, названная ODBCDirect, использовала ODBC [4]. Чистый ODBC, безусловно, быстрее второй модели технологии DAO, но в использовании он гораздо сложнее. Кроме того, в библиотеке MFC (Microsoft Foundation Classes) для С++, библиотеках Visual Basic и в других языках существуют шаблоны, существенно упрощающие процесс разработки. Тип выбранной модели задается при создании соединения (рабочей области) указанием констант: dbUseJet - использовать Jet; dbUseODBC - использовать ODBC. Иерархия объектов DAO для модели Jet представлена на рис. 2, для модели ODBC - на рис. 3.

Рис. 2. Иерархия объектов DAO, модель Jet [4]

DBEugin

h Errors-Error

Workspaces - Woikbpace

-Connections -Connection

-QueryDefs - QueiyDef

I- Parameters Recordsets - Recordset

L Fields -

'-Database?-Database

LRecordsets -Recordset

L Fields -

-Parameter -Field

- Field

Рис. 3. Иерархия объектов DAO, модель ODBCDirect [4]

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

Однако естественное развитие вычислительных систем привело к необходимости создания единого механизма, который обеспечил бы единый подход при работе

с БД различных классов. И в середине 1990-х годов, с развитием и распространением технологии COM (Component Object Model), компания Microsoft объявила о постепенном переходе к использованию новой технологии OLE DB (Objects Linking and Embedding - объекты связанные и внедренные). Объектный интерфейс OLE DB представляет собой открытый стандарт, предназначенный для универсального доступа приложений к базам данных.

OLE DB - это совокупность интерфейсов ActiveX, которые упрощают и унифицируют доступ к данным независимо от того, где и как они хранятся. Приложение, использующее эти элементы, может интегрировать информацию из СУБД (SQL Server, ORACLE, Access) с информацией из систем другого типа, но поддерживающих OLE-механизм [3]. Технология позволяет одинаковым образом обращаться к реляционным базам данных, серверам почты, базам данных для мэйнфреймов с методами доступа IMS, VSAM и т.д. [5].

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

Драйвер Провайдер Описание

MSDASQL ODBC Drivers Драйверы ODBC (по умолчанию)

Microsoft. Jet. OLEDB .3.5 Jet 3.5 Только базы данных MS Access 97

Microsoft. Jet.OLEDB.4.0 Jet 4.0 Базы данных MS Access и другие БД

SQLOLEDB SQL Server Базы данных MS SQL Server

MSDAORA Oracle Базы данных Oracle

MSDAOSP Simple provider Для создания ваших собственных провайдеров, для простых текстовых данных

Таблица. Наиболее часто используемые провайдеры OLE DB [6]

Спецификация компонентов OLE DB представлена на рис. 4.

Рис. 4. Модель компонентов OLE DB [3]

Однако OLE DB, по мнению самой компании Microsoft, является интерфейсом системного уровня, этот интерфейс должен использоваться системными программистами. Технология OLE DB является тяжеловесной, сложной и очень чувствительной к ошибкам. Чтобы облегчить работу с OLE DB, в 1996 году был создан дополнительный прикладной объектный интерфейс более высокого уровня, который получил название ADO (ActiveX Data Objects). Ключевыми элементами этой модели является набор объектов, с помощью которых можно:

• создать соединение с базой данных;

• выполнить команду с параметрами;

• получить результаты выполнения этой команды в виде переменной или набора записей;

• обработать события или ошибки [1].

Отсутствие сложной структуры делает его более гибким и легким в употреблении. Модель объектов ADO представлена на рис. 5.

Рис. 5. Модель компонентов ADO [4]

Здесь стоит упомянуть о результатах тестирования производительности разных методов доступа к данным, приведенных в статье «VS 6.0 Benchmarks: New Features Don't Impact Speed» в журнале VBPJ. Там говорится об исследовании скоростных характеристик разных средств, входящих в состав Visual Studio 6.0, а также VB 6, для различных режимов работы программ (графика, математические задачи, обработка строк и пр.), в том числе и при работе с базами данных.

По результатам тестирования при работе с удаленными данными быстродействие ADO и RDO примерно одинаково. Что же касается локальных баз данных, то скорость ADO в 3-5 раз ниже, чем у DAO [2]. Это плата за универсальность, такой механизм всегда уступает специализированным, имея в качестве преимущества упрощение процесса разработки. Современный стиль разработки заключается именно в таких приоритетах: главное - сократить трудоемкость разработки, а уже потом думать о повышении эффективности приложений. Более важным является другой момент: Microsoft тогда объявила, что будет усовершенствовать и обновлять только модель ADO (что соответствует общей стратегии корпорации на унификацию разных технологий на базе ActiveX), т.е. DAO и RDO постепенно должны были сойти со сцены. Результаты тестирования для локальных данных отражены на рис. 6, для удаленных - на рис. 7.

50

н

b 40

к

к

*30 « * 20

eö Л (U С О

10 0

DAO RDO Client RDO Server ADO-ODBC ADO-ODBC ADO-OLEDB ADO-OLEDB

Cursor Cursor Client Cursor Server Cursor Client Cursor Server Cursor

технология

Рис. 6. Скорость доступа к локальным данным [2]

b 20

к

s

s 15

m

«

* 10

eö

g 5

о

0

RDO Client RDO Server ADO-ODBC ADO-ODBC ADO-OLEDB ADO-OLEDB Cursor Cursor Client Cursor Server Cursor Client Cursor Server Cursor

технология

Рис. 7. Скорость доступа к удаленным данным [2]

Но сегодня и ADO доживает свои последние дни. В 2003 году компания Microsoft анонсировала выход своей новой платформы: .Net Framework, которая является очередной попыткой компании Microsoft заново перепроектировать средства и инструменты разработки программного обеспечения, чтобы сделать их более удобными для создания веб-приложений. ADO.NET является новым развитием ADO, ориентированным на решение проблем, связанных с разработкой веб-систем, и устраняющим многие недостатки устаревшей технологии ADO. Проблема ADO состоит в том, что эта технология основана на COM. Для одно- и двухзвенных приложений COM является вполне приемлемой платформой, однако в мире Веб использовать COM в качестве транспортного механизма фактически невозможно. Для COM характерны три основные проблемы, которые ограничивают использование этой технологии в Веб: во-первых, COM функционирует только в среде Windows, во-вторых, передача наборов записей требует маршализации COM, в-третьих, вызовы COM не могут проникать через корпоративные брандмауэры. Технология ADO.NET решает все три проблемы благодаря использованию XML [5]. Совместная работа классов ADO.NET и XML в .NET Framework обеспечивается объектом DataSet. Это очень мощный объект, обладающий встроенным форматом сериализации XML, с помощью которого можно легко и надежно передавать данные.

Другой важной особенностью ADO.NET является использование разъединенной модели доступа к данным. В клиент-серверных приложениях традиционно используется технология доступа к источнику данных, при которой соединение с базой поддерживается постоянно. Однако после широкого распространения приложений, ориентированных на Интернет, выявились некоторые недостатки такого подхода. ADO.NET предлагает следующую схему взаимодействия клиента с сервером:

• открытие соединения с сервером СУБД;

• отправка запроса к базе данных;

• закрытие соединения;

• обработка данных, полученных в виде объекта класса DataSet;

• открытие соединения с сервером СУБД;

• обновление базы данных с использованием содержимого объекта класса DataSet;

• закрытие соединения [1].

По количеству потребляемых ресурсов и времени выполнения одной из самых затратных команд является выборка данных. Желая максимально повысить скорость считывания данных из БД, программисты Microsoft пришли к тому, что вся выборка кэши-руется на стороне клиента в момент создания DataReader'a [8]. Такое поведение плохо скажется на скорости при частых обращениях к серверу баз данных. Однако описанная

выше разъединенная модель доступа к данным для ADO.NET показывает, что основную работу пользователь будет производить на локальной машине. В этом случае клиентское приложение один раз выкачивает данные из базы данных и, используя сохраненные в кеше данные, с максимальным быстродействием формирует объект DataSet -прообраз базы данных на клиенте.

Таким образом, автор видит технологию ADO.NET достаточно универсальной, логичной и несложной в использовании, отвечающей современным требованиям для распределенных приложений (именно для таких и создавался .NET). Кроме того, при использовании провайдеров, «заточенных» под конкретную базу данных, данная технология демонстрирует быстродействие, сопоставимое с ODBC. Если же применять универсальные провайдеры, такие как ODBC.NET Data Provider или OLE DB.NET Data Provider, быстродействие резко падает - это главный недостаток данной технологии. Тем не менее, именно ADO.NET в ближайшее время будет наиболее популярной технологией для доступа к данным в операционной системе Windows.

Архитектура ADO.NET представлена на рис. 8.

Провайдер данных .NET Framework

Connection

Transaction

Command

Parameters

DataReader

DataAdapter

SelectCommand

InsertCommand

UpdateCommand

DeleteCommand

<4-►

D DataSet

DataTableCollections

DataTable

DataRowCollection

DataColumnCollection

ConstrainCollection

DataRelationCollection

XML

Рис. 8. Архитектура ADO.NET Заключение

В работе проведен обзор основных технологий доступа к данным для операционной системы Windows. Оценивая эволюцию этих технологий, можно сделать вывод, что основной задачей при их разработке было: независимо от типа создаваемого приложения (многоуровневый, распределенный, автономный или Web-ориентированный клиент/сервер) разработчик должен иметь «наилучший» набор инструментов, приложений и источников данных, позволяющих создать такое приложение. Таким образом, для выбранных технологий оценивалось их быстродействие, выявлялись возможности доступа к данным различной природы, изучались способности работы в распределенных системах. В итоге можно сделать вывод, что сегодня мы обладаем технологиями, которые позволяют в кротчайшие сроки реализовывать довольно сложные проекты. Среди решений Microsoft к ним, в первую очередь, относится ADO.NET. Эта технология - не самая быстрая в работе (при использовании стандартных провайдеров), зато она более универсальна, а интуитивно понятные абстракции ADO.NET более просты в использовании и изучении.

Литература

1. Фролов А.В., Фролов Г.В. Визуальное проектирование приложений С#. М.: Кудиц -образ, 2003. 512 с.

2. Rofail A., Shohoud Y. VS 6.0 Benchmarks: New Features Don't Impact Speed. // VBPJ, 1998. № 14. С. 30-44.

3. Пирогов В.Ю. Ms SQL Server 2000 управление и программирование. СПб: БХВ -Петербург, 2005. 608 с.

4. Арчер Т., Уайтчепел Э. Visual C++.NET. Библия пользователя. М-СПб-К.: Вильямс, 2005. 1216 с.

5. Троэлсен Э. С# и платформа.ШТ. СПб: Питер, 2006. 796 с.

6. Кэнту М. Delphi 7. Для профессионалов. СПб: Питер, 2003. 840 с.

7. Марков А.С., Лисовский К.Ю. Базы данных. М.: Финансы и кредит, 2006. 512 с.

8. Михаилов С. Сравнение скорости доступа к данным (ADO.NET, ADO, ascDB). // RSDN Magazine. 2003. № 3. С. 3-34.