Доступ к данным из приложений; технологии ADO, OLE, ODBC.

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

Обычно Windows-версии клиентского программ­ного обеспечения наиболее популярных серверных СУБД, в ча­стности MicrosoftSQLServer, Oracle, Informix, содержат также СОМ-серверы, предоставляющие объекты для доступа к данным и метаданным.

Использование клиентского API (или клиентских Сом-объектов) является наиболее очевидным (и нередко самым эффек­тивным с точки зрения производительности) способом манипу­ляции данными в приложении. Однако в этом случае созданное приложение сможет использовать данные только СУБД этого производителя, и замена ее на другую (например, с целью рас­ширения хранилища данных или перехода в архитектуру «кли­ент-сервер») повлечет за собой переписывание значительной части кода клиентского приложения – клиентские API и объ­ектные модели не подчиняются никаким стандартам и различны для разных СУБД.

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

Отметим, что достоинством универсальных механизмов яв­ляется возможность применения одного и того же абстрактного API, а во многих случаях – СОМ-серверов, компонентов, клас­сов для доступа к разным типам СУБД. Поэтому приложения, использующие универсальные механизмы доступа к данным, легко модифицировать при необходимости замены СУБД. При­чем модификация, как правило, затрагивает не код приложения как таковой, а настройки доступа к данным, содержащиеся в реестре или внешних файлах. Недостатками универсальности яв­ляются невозможность доступа к уникальной функциональности конкретной СУБД, снижение производительности приложений, а также усложнение процедуры поставки приложения — ведь в его состав нужно включать библиотеки, ответственные за реали­зацию универсальных механизмов, драйверы для конкретных СУБД, а также обеспечивать настройки, необходимые для их правильного функционирования.

Известные наиболее популярные универсальные механизмы доступа к данным:

• BDE (Borland Database Engine);

• ODBC (Open Database Connectivity);

• OLE DB;

• ADO (ActiveX Data Objects).

Универсальные механизмы ODBC, OLEDB и ADO фирмы Microsoft представляют собой по существу промышленные стан­дарты. BDE фирмы Borland так и не стал промышленным стан­дартом, однако до недавнего времени применялся довольно ши­роко, так как до выхода Delphi 5 был практически единственным универсальным механизмом доступа к данным, поддерживаемым средствами разработки Borland на уровне компонентов и классов.

Графическая интерпретация механизмов доступа к данным из приложений приведена на рис.

Рис. Возможные механизмы доступа к данным из приложений

В общем случае приложение, использующее БД, может при­менять следующие механизмы доступа:

• непосредственный вызов функций клиентскогоAPI (или обращение к СОМ-объектам клиентских библиотек);

• вызов функций ODBCAPI (или применение классов, ин­капсулирующих подобные вызовы);

• непосредственное обращение к интерфейсам OLEDB;

• применение ADO (или применение классов, инкапсули­рующих обращение к объектам ADO);

. применение ADO + OLEDB + ODBC;

• применение BDE + SQLLinks (или применение классов, инкапсулирующих обращение к функциям BDE);

• применение BDE + ODBCLink + ODBC.

Кроме вышеуказанных, существуют и другие способы досту­па к данным, использующие перечисленные универсальные ме­ханизмы или непосредственно клиентские API.

1. Основные задачи администрирования баз данных

Работа с базами данных – достаточно сложная сфера применения информационных технологий. Процессы создания и использования приложений баз данных требуют квалифицированного управления. Управление базами данных на всех стадиях их жизненного цикла принято называть администрированием; специализирующееся на этом лицо или группа лиц называется администратор баз данных (АБД). На предприятиях для этих целей создаются службы АБД.

Администрирование баз данных требует знания архитектуры СУБД, всех ее функций и объектов, необходимо владеть методами проектирования и разработки баз данных. АБД отвечает за целостность информационных ресурсов. На нем лежит ответственность по созданию, обновлению и сохранности связанных между собой резервных копий файлов, исходя из задач предприятия. АБД должен в подробностях знать существующие механизмы восстановления программного обеспечения БД.

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

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

Задачи администратора базы данных

К основным задачам, стоящим перед АБД относят следующие:

· Проектирование базы данных

· Установка (инсталляция) СУБД. Конфигурирование СУБД

· Соединение СУБД с поддерживающим программным обеспечением инфраструктуры

· Управление производительностью. Отслеживание и настройка производительности. Оптимизация запросов

· Безопасность, разграничение доступа и авторизация в базах данных; управление прописанными в базе пользователями, определение их полномочий, ограничений, ролей

· Целостность данных. Регистрация и прослеживание событий данных

· Резервирование и восстановление

· Загрузка и выгрузка данных. Групповое перемещение данных

· Репликация и распространение

· Обновление версии или выпуска СУБД. Переход к новой версии СУБД

В соответствии с кругом решаемых задач возможно выделение (обособление) следующих типов администраторов баз данных.

· Системный администратор базы данных -Архитектор баз данных

· Аналитик баз данных -Разработчик моделей данных

· Администратор приложений, относящихся к базам данных

· Проблемно-ориентированный администратор базы данных

· Администратор хранилища данных

1. Подходы к повышению производительности и оптимизации баз данных.

Обработка запросов

Большая часть обращений к БД ини­циируется пользователями и приложениями, что не оказывает влияния на схему БД, но затрагивает ее содержи­мое (если команда предусматривает внесение изменений) либо предполагает чтение данных (если команда содержит запрос). Такие команды оформляются с помощью языка управления дан­ными DML (Data Definition Language – язык определения данных), или, проще говоря, языка запросов (query language). Существует множество различных языков управления данными, но самым распространенным и мощным из них явля­ется SQL. Инструкции языка DML обрабатываются двумя от­дельными подсистемами СУБД, описываемыми ниже.

Получение ответа на запрос.Запрос анализируется и оптими­зируется компилятором запросов. Сформированный компилято­ром план запроса, или последовательность действий, подлежащих выполнению системой с целью получения ответа на запрос, передается исполняющей машине. Машина направляет группу запросов на получение небольших порций данных – как прави­ло, строк (кортежей) таблицы (отношения) – менеджеру ресур­сов, который «осведомлен» об особенностях размещения инфор­мации в файлах данных, содержащих таблицы, о форматах и размерах записей в этих файлах и о структурах индексных фай­лов, обеспечивающих существенное ускорение процессов поиска запрошенных данных.

Менеджеры буферов и хранения данных.Информация, храни­мая в БД, обычно располагается на носителях вторичных уст­ройств хранения, т. е. на магнитных дисках. Но для выполнения любой полезной операции над данными необходимо перенести их в оперативную память. Задача управления размещением ин­формации на диске и обмена ею между диском и оперативной памятью возлагается на менеджера хранения данных.

Транзакции. Запросы и другие команды язы­ка управления данными группируются в транзакции – процес­сы, которые должны выполняться атомарным образом и изоли­рованно друг от друга. Зачастую каждый отдельный запрос или операция по изменению данных является самостоятельной тран­закцией.

Обработка транзакций.Менеджер транзакций получает от приложения команды транзакций, которые свидетельствуют о начале и завершении транзакции, а также передают информа­цию о предпочтениях приложения в отношении параметров транзакции (приложение, например, может отказаться от свой­ства атомарности транзакции). Процессор транзакций выполня­ет функции, рассмотренные ниже.

Протоколирование.Для удовлетворения требованию устойчи­вости транзакций каждое изменение в БД фиксируется в специ­альных дисковых файлах. Менеджер протоколирования в своей работе руководствуется одной из нескольких стратегий, при­званных исключить вредные последствия системных сбоев во время выполнения транзакции, а менеджер восстановления в случае возникновения подобных ситуаций способен считать протокол изменений и привести БД в некоторое сообразное со­стояние. Информация протокола изначально сохраняется в бу­ферах; затем менеджер протоколирования в определенные мо­менты времени взаимодействует с менеджером буферов, чтобы проверить сохранность содержимого буферов на диске (где дан­ные находятся под надежной защитой в момент возможного краха системы).