БД - Раздел 5.

Базы данных

Раздел 5. Средства разработки приложений. Защита баз данных (Лекции 15÷16)

Лекция 15. Современные средства разработки приложений. Доступ к данным из прикладных приложений. Обзор технологий ADO, OLE, ODBC. Создание форм и отчетов; программный инструментарий создания пользовательского интерфейса.

При работе с реляционными БД можно условно выделить две основные задачи:

- собственно работа с БД, включающая создание и ведение БД (создание таблиц, добавление записи в таблицу, удаление записи, обновление, выборка нужной записи);

- создание пользовательских приложений, включающих разработку пользовательского интерфейса по работе с базой данных.

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

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

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

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

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

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

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

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

Как указывалось, целью проектирования модулей является реализация функциональных возможностей, которые удовлетворяют бизнес-требованиям, выявленным в функциональной модели предметной области базы данных. Однако при этом необходимо рассмотреть достаточное число процессов, которые не вытекают непосредственно из сформулированных бизнес-функций. Например, возможность выдачи результатов работы модуля в файл или на принтер.

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

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

Проектировщик базы данных самостоятельно разрабатывает спецификации таких модулей.

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

При этом следует придерживаться следующих простых правил:

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

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

• Задействовать хранимые процедуры для инкапсуляции общих бизнес-функций.

• Использовать требования производительности при принятии окончательного выбора о разделении кода.

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

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

Разработка должна включать проектирование процесса тестирования модулей приложений. Как правило, тесты и их проведение планируются для удовлетворения требований приемо-сдаточных испытаний. Поэтому разработку стратегии тестирования следует начинать с детального изучения этих требований.

Как показывает практика, планирование тестирования приложений базы данных должно начинаться еще на стадии анализа. Имеется вероятность того, что заказчик может отказаться от ранее принятых критериев испытаний в процессе выполнения проекта. Однако чаще всего планирование тестирования откладывают до этапа проектирования, и, таким образом, составление плана тестирования становится задачей проектировщика базы данных или администратора баз данных.

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

Как правило, в процессе проектирования проектировщик базы данных предлагает стратегию (или план) комплексного и системного тестирования. При разработке стратегии тестирования следует помнить о том, что должны использоваться тесты следующих категорий:

• Автономные тесты (тесты модулей).

• Тесты связей модулей.

• Системный тест для приложения базы данных в целом.

• Приемо-сдаточные испытания (которые может проводить заказчик).

• Тесты производительности.

Обычно после проведения приемо-сдаточных испытаний подписывается Акт приемки-сдачи. Считается, что система переходит в состояние опытной эксплуатации, на которой выявляются и исправляются ошибки. После окончания стадии опытной эксплуатации систему переводят в состояние промышленной эксплуатации.

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

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

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

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

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

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

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

• BDE (Borland Database Engine);

• ODBC (Open Database Connectivity);

• OLE DB;

• ADO (ActiveX Data Objects).

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

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

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

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

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

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

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

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

. применение ADO + OLE DB + ODBC;

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

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

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

Лекция 16. Основные задачи администрирования баз данных. Защита баз данных; целостность и сохранность баз данных. Подходы к повышению производительности и оптимизации баз данных.

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

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

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

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