Глава 2.Организация доступа к внешним данным из приложений ms Office
Компоненты Microsoft Office являются хорошей основой для создания клиентских приложений баз данных. Например, можно использовать Word при построении клиентской части приложения, если при создании отчетов или публикаций в них включаются данные из внешних источников. При необходимости статистического анализа данных для разработки приложения лучше использовать Excel.
При разработке приложений на базе Microsoft Office возникает проблема получения клиентским приложением необходимой информации из внешних баз данных. Далее рассматриваются две технологии доступа к данным (ODBC и DAO), реализованные в продуктах Microsoft.
Гибкость системы подразумевает независимость от платформы, в частности от используемой СУБД. То есть система должна быть построена таким образом, чтобы замена БД одного поставщика на БД другого не влияла на работоспособность системы. Существуют различные способы организации доступа к данным, независимые от особенностей СУБД.
2.1.Технологии доступа к данным
Гибкость приложений может быть достигнута за счет правильного выбора средства доступа к данным. В настоящее время существует несколько стандартов. Рассмотрим их.
2.1.1.ODBC
ODBC (Open Data Base Connectivity) – это механизм доступа к БД, предлагающий следующую схему доступа к данным (рис. 36): прикладная программа (ПП) выдает запрос не некоторые данные. Этот запрос принимается диспетчером ODBC, играющим роль универсальной виртуальной СУБД. Далее диспетчер ODBC перенаправляет запрос драйверу конкретной СУБД, который уже работает непосредственно с источником данных. Запросы формируются в виде операторов на языке SQL.
Рис. 36. Доступ к данным с использованием ODBC
2.1.2.DAO
Объекты доступа к данным DAO (Data Access Objects) создавались как объектно-ориентированный интерфейс для ядра баз данных Jet фирмы Microsoft. Ядро Jet обеспечивает возможность доступа к данным независимо от особенностей интерфейса конкретной системы управления базами данных.
К основным недостаткам данного метода можно отнести следующее:
Перед использованием источника необходимо убедиться в том, что в Диспетчере драйверов ODBC описан соответствующий источник данных (в случае необходимости нужно создать новый источник данных), т.е. этот метод доступа привязан к конкретной платформе, что вызывает проблемы с масштабируемостью и переносимостью.
При доступе к серверным источникам данных (SQL Server, Sybase, Oracle) увеличиваются накладные расходы. Это обусловлено, в частности, самим процессом выполнения запроса: для связи с серверными БД используется ODBC, следовательно, операции проходят два уровня (Jet и ODBC).
2.1.3.RDO
Для решения проблем, присущих DAO, был разработан еще один метод доступа – RDO (Remote Data Objects). Он создавался специально для работы с серверными источниками данных, однако ошибка, допущенная при разработке модели, привела к еще большему увеличению накладных расходов.
2.1.4.OLE DB
По мере развития информационных систем, обеспечения доступа только к «стандартным» источникам информации, обычно это были разнообразные форматы СУБД класса MS SQL Server, Oracle, Sybase, Informix и т.п., стало недостаточно. Все чаще разработчики начали обращаться к данным, которые хранятся в формате настольных СУБД, электронных таблиц, в папках хранилищ систем обмена сообщениями. Остро встал вопрос организации стандартизированного доступа к большему разнообразию форматов хранения, чем это было ранее. Кроме того, при обращении к нереляционным хранилищам информации необходимо обеспечить тот же уровень обеспечения целостности данных, разграничения доступа и гибкости при построении запросов, что и при работе с серверами баз данных.
Все вышесказанное привело к тому, что Microsoft разработала набор OLE интерфейсов под общим названием OLE DB.
Работа с источниками данных организована следующим образом: в процессе участвуют два основных типа программных компонентов: OLE DB-поставщик (provider) и OLE DB-потребитель (consumer). Потребитель запрашивает данные, а поставщик их предоставляет. Именно поставщик организует запрос к хранилищу информации.
В отличие от метода ODBC, требующего использования SQL для обращения к данным, OLE DB требует от поставщика всего лишь табличного представления информации и тем самым исключает необходимость организации некоторого варианта SQL процессора для источников, которые стандартно такой функциональности не имеют (в качестве примера можно привести ODBC драйвер для MS Excel, который сам формулирует запросы и сам же их исполняет). В результате, при использовании OLE DB клиентское приложение способно использовать информацию, хранящуюся в любом инородном формате, так как она поступает в удобном для работы приложения табличном представлении.
2.1.5.ADO
Интерфейс OLE DB доступен только для разработчиков, использующих язык С. Для остальных разработаны так называемые ActiveX Data Objects, ADO – это набор объектных интерфейсов, позволяющих создавать приложения в архитектуре клиент-сервер с обращением к базам данных через OLE DB-поставщика.
Если говорить о двух других интерфейсах доступа к данным, таких, как DAO и RDO, то ADO охватывает их функциональность и, сохраняя совместимость с уже существующими приложениями, двигается дальше.
Замечание: OLE DB и ADO НЕ являются заменой ODBC. OLE DB/ADO позволяют работать с данными в разнообразных форматах. Приложения, которые работают только с одним типом данных, например, MS SQL Server, не стоит переделывать на использование ADO только потому, что этот интерфейс существует.
2.1.6.ADO.NET
Следующим шагом в развитии технологий доступа к данным явилось создание на базе ADO нового метода – ADO.Net. Его появление обусловлено стремительным развитием Web-приложений, которое вызвало необходимость пересмотреть методы работы с источниками данных и адаптировать их к специфике таких приложений. Основное отличие ADO.Net от ADO – поддержка работы с XML-документами.
Средство ADO.Net было представлено Microsoft с новой платформой .NET. Именно этот метод представляется в настоящее время наиболее адекватным для организации независимого от СУБД доступа к данным.