3.1. Общий обзор средств для работы с базами данных
В состав Delphi Client/Server Suite входят следующие средства для разрабо1ки и эксплуатации приложений, использующих базы данных:•
BDE (Borland Database Engine), машина баз данных фирмы BorlandПредставляет собой набор библиотек. Должна устанавливаться на каждом компьютере, который использует приложения для работы с БД, написанные на Delphi. Выполняет действия по доступу к данным и проверке их правильности. Является, по существу, центральным средством для работы с БД из приложений, созданных с помощью Delphi.
•SQL Links
Драйверы для работы с удаленными "промышленными" СУБД, такими как
Sybase, MS SQL Server, Oracle. Для работы с "родным" SQL-сервером Borland InterBase устанавливать SQL Links нет необходимости. Доступ к таблицам локальных ("настольных", "персональных") СУБД типа Paradox, dBase также осуществляется BDE напрямую, без использования SQL Links.• BDE Administrator
Утилита для установки псевдонимов (имен) баз данных, параметров БД и драйверов баз данных на конкретном компьютере. При работе с БД из приложения, созданного с помощью
Delphi, доступ к базе данных производится по ее псевдониму (имени). Параметры БД, определяемой псевдонимом, действуют только для этой БД; параметры, установленные для драйвера БД, действуют для всех баз данных, использующих драйвер. Кроме этого, в утилите BDE Administrator можно произвести установку таких общих для всех БД параметров, как формат даты и времени, форматы представления числовых значений, используемый языковый драйвер и т.д. Поддерживает информацию о конфигурации БД на конкретном компьютере в файле IDAPI32.CFG.• Database Desktop (DBD)
Средство для создания, изменения и просмотра БД. Эта утилита прежде всего ориентирована на работу с таблицами локальных ("персональных") СУБД, таких как
Paradox и dBase. В ряде случаев может использоваться и для работы с таблицами удаленных СУБД. Например, из DBD можно с некоторыми ограничениями создавать таблицы БД, работающих под управлением InterBase, Oracle, и просматривать их содержимое.Общая модель взаимодействия приложения, реализованного с помощью
Delphi, со средствами БД приведена на рис. 3.1.• Database Explorer (SQL Explorer)
Утилита для конфигурирования псевдонимов БД, просмотра структуры БД, таблиц БД, выдачи запросов к БД, создания словарей данных.
•SQL Monitor
Средство для трассировки выполнения
SQL-запросов.• Visual Query Builder
Средство в составе интегрированной среды
Delphi для автоматического создания SQL-запросов методом QBE (Query By Example, запрос по образцу).• Data Dictionary
Словарь данных. Средство для хранения атрибутов полей таблиц БД отдельно от самих БД и приложений. Информация о полях может использоваться различными приложениями.
• Data Module
Невизуальные компоненты типа
TDataModule применяются для централизованного хранения наборов данных в приложении, работающем с БД. Одним из главных удобств является приписывание каждому набору данных правил по управлению данными. Такие правила называются бизнес-правилами. Они обычно определяют реакцию системы при добавлении, изменении, удалении данных, при вводе ошибочных значений и реализуют блокировку действий, которые могут разрушить ссылочную и смысловую целостность БД.Такие бизнес-правила, хранящиеся централизованно на уровне приложения, при использовании одного и того же набора данных в разных формах приложения, позволяют унифицировать поведение НД на уровне всего приложения.
• Object Repository
Репозиторий объектов
Delphi. Будучи единожды разработанными для какого-либо приложения, формы с визуальными и невизуальными компонентами, а также компоненты TDataModule могут сохраняться в репозитории. Тогда они могут использоваться другими, вновь создаваемыми приложениями. Таким образом устраняется необходимость повторного написания идентичного или схожего кода в приложениях.• Data Migration Wizard
Средство для перемещения данных между БД различных типов
•
Невизуальные компоненты для работы с БДНевизуальные компоненты Delphi служат для соединения приложения с таблицами БД. Они расположены на странице компонентов Data Access палитры компонентов в интегрированной среде разработки Delphi. Невизуальный компонент "перетаскивается" из палитры компонентов в форму разрабатываемого приложения. После этого Delphi автоматически описывает в форме экземпляр компонента указанного класса. Далее разработчик определяет свойства компонента, кодирует обработчики событий, где в программном коде вызывает необходимые ему методы компонента.
•
Визуальные компоненты для работы с БДВизуальные компоненты Delphi предназначены доя визуализации записей наборов данных (например, компонент TDBGrid) или отдельных полей текущей записи набора данных (например, TDBEdit, TDBText). Эти компоненты расположены на странице компонентов Data Controls палитры компонентов в интегрированной среде разработки Delphi. Визуальный компонент "перетаскивается" из палитры компонентов в форму разрабатываемого приложения. После этого Delphi автоматически описывает в форме экземпляр компонента указанного класса. Далее разработчик определяет соединение визуального компонента с невизуальными компонентами, определяет по необходимости различные свойства компонента, кодирует обработчики событий, где в программном коде вызывает необходимые ему методы компонента.
•
Компоненты для построения отчетовВ интегрированной среде разработчика Delphi на странице палитры компонентов QReport размещено около двух десятков компонентов для построения отчетов. Их добавление в приложение происходит аналогично добавлению визуальных компонентов для работы с данными.
Ранее поставлявшееся в составе Delphi автономное средство ReportSmith с Delphi версии 3 более не поставляется.
• Local InterBase Server
Локальная однопользовательская версия
SQL-сервера Borland InterBase. Поддерживает 2 активных соединения клиентов с сервером. Используется в основном для создания БД, отладки клиентских приложений, которые будут работать с Удаленными БД. В дальнейшем, после отладки, БД переносятся на действительно удаленный сервер, а приложение клиентского места перенастраивается для работы с удаленной БД. Данная перенастройка обычно не требует больших трудозатрат.• InterBase Server for Windows 95
4-х-пользовательская версия SQL-сервера Borland InterBase, которая может устанавливаться на компьютерах, работающих под управлением Windows 95. Используется для тех же цедей< что и Local InterBase Server, однако на InterBase for Windows 95 можно производить отладку в многопользовательском режиме, что важно для проверки корректности изменений, одновременно вносимых пользователями в БД при параллельной работе с ней.
На рис. 3.2. показаны основные средства в составе интегрированной среды Delphi для работы с БД
Интегрированная среда разработчика Delphi (IDE, Integrated Development Environment)
Общий состав средств, необходимых для работы готового приложения с БД, показан на рис. 3.3. Согласно этой общей схеме, мы имеем цепочку Приложение —>
BDE —> базы данныхВ структуре приложения имеется цепочка Невизуальные компоненты —> Визуальные компоненты
Более подробно взаимосвязи между компонентами приложения рассматриваются ниже. Местоположение
BDE и самих баз данных в этой цепочке не отражены.Между тем, местоположение
BDE и баз данных зависит от используемой архитектуры. Имеется четыре разновидности архитектур баз данных:• локальные базы данных;
• архитектура "файл-сервер";
• архитектура "клиент-сервер";• многозвенная (трехзвенная
N-tier или multi-tier) архитектура.Использование той или иной архитектуры накладывает сильный отпечаток на общую идеологию работы приложения, на программный код в приложении, на состав компонентов для работы с БД, используемых в приложении (прежде всего это касается невизуальных компонентов).
3.2.1 Локальные базы данных и архитектура "файл-сервер"
При работе с локальными базами данных сами БД расположены на том же компьютере, что и приложения, осуществляющие доступ к ним. Работа с БД происходит в однопользовательском режиме.
BDE распложена на компьютере пользователя. Приложение ответственно за поддержание целостности БД и за выполнение запросов к БД. Общая схема однопользовательской архитектурыпоказана на рис. 3.4.
При работе в архитектуре "файл-сервер" БД и приложение расположены на файловом сервере сети (например, Novell NetWare). Возможна многопользовательская работа с одной и той же БД, когда каждый пользователь со своего компьютера запускает приложение, расположенное на сетевом сервере. Тогда на компьютере пользователя запускается копия приложения. По каждому запросу к БД из приложения данные из таблиц БД перегоняются на компьютер пользователя, независимо от того, сколько реально нужно данных для выполнения запроса. После этого выполняется запрос. Каждый пользователь имеет на своем компьютере локальную копию данных, время от времени обновляемых из реальной БД, расположенной на сетевом сервере. При этом изменения, которые каждый пользователь вносит в БД, могут быть до определенного момента неизвестны другим пользователям, что делает актуальной задачу систематического обновления данных на компьютере пользователя из реальной БД. Другой актуальной задачей является блокирование записей, которые изменяются одним из пользователей; это необходимо для того, чтобы в это время другой пользователь не внес изменений в те же данные.В архитектуре "файл-сервер" вся тяжесть выполнения запросов к БД и управления целостностью БД ложится на приложение пользователя. БД на сервере является пассивным источником данных. Общая схема архитектуры "файл-сервер" показана на рис. 3.5.
Кардинальных различий с точки зрения архитектуры между однопользовательской архитектурой и архитектурой "файл-сервер" нет. И в том, и в ином случае в качестве СУБД применяются так называемые "персональные" (или "локальные") СУБД, такие как
Paradox, dBase и пр. Сама база данных в этом случае представляет собой набор таблиц, индексных файлов, файлов полей комментариев (мемо-полей) и пр., хранящихся в одном каталоге на диске в виде отдельных файлов.3.2.2. Удаленные базы данных и архитектура "клиент-сервер"
Архитектура "файл-сервер" неэффективна по крайней мере в двух отношениях:
1. При выполнении запроса к базе данных, расположенной на файловом сервере, в действительности происходит запрос к локальной копии данных на компьютере пользователя. Поэтому перед выполнением запроса данные в локальной копии обновляются из реальной БД. Данные обновляются в полном объеме. Так, если таблица БД состоит из 1000 записей, а для выполнения запроса (например, выдать сумму премий за октябрь в отделе
Y) реально нужно 10 записей, все равно перегоняются все 1000 записей. Таким образом, не нужно иметь слишком много пользователей и запросов от них, чтобы серьезно "забить" сеть, что, конечно же, не может не сказаться на ее быстродействии.2. Обеспечение целостности БД производится из приложений. Это потенциальный источник ошибок, нарушающих физическую и логическую целостность БД, поскольку различные приложения могут производить контроль целостности БД по-разному, взаимоисключающими способами, или не проводить такого контроля вовсе. Намного эффективнее управлять БД из единого места и по единым законам, нежели из разных приложений и по потенциально разным законам (все зависит от того, как написано приложение). Поэтому безопасность при работе в архитектуре "файл-сервер" невысока и всегда присутствует элемент неопределенности. Секретность и конфиденциальность при работе с БД в архитектуре "файл-сервер" обеспечить также тяжело - любой, кто имеет доступ в каталог сетевого сервера, где хранится БД, может изменять таблицы БД любым образом, копировать их, заменять и т.д.
Архитектура "клиент-сервер" разделяет функции приложения пользователя (называемого клиентом) и сервера.
Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов
SQL (Structured Query Languague), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер -специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами.Все это повышает быстродействие системы и снижает время ожидания результата запроса.
При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый
SQL-серверами, позволяет исключить одновременное изменение одних и тех желанных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно.Таким образом, функциями приложения-клиента являются:
1. посылка к серверу запросов;
2. интерпретация результатов запросов, полученных от сервера, и представление их пользователю в требуемой форме;
3. реализация интерфейса пользователя.
SQL
-сервер - это программа, расположенная на компьютере сетевого сервера. SQL-сервер должен быть загружен на момент принятия запроса от клиента. Функциями сервера БД являются:1. прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;
2. управление целостностью БД, обеспечение системы безопасности, блокировка неверных действий приложений-клиентов;
3. хранение бизнес-правил, часто используемых запросов в уже интерпретированном виде;
4. обеспечение одновременной безопасной и отказоустойчивой многопользовательской работы с одними и теми же данными.
В архитектуре "клиент-сервер" используются так называемые "удаленные" (или "промышленные") СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.
К разрядку промышленных СУБД принадлежат
Oracle, Gupta, Informix, Sybase, MS SQL Server, DB2, InterBase и ряд других.Как правило,
SQL-сервер управляется отдельным сотрудником или группой сотрудников (администраторы SQL-сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии (разрешения на доступ определенного уровня к конкретным БД, SQL-серверу) различным пользователям.Кроме этого, существует отдельная категория сотрудников, называемых администраторами баз данных. Как правило, это администраторы сервера, разработчики БД или пользователи, имеющие привилегии на создание, изменение, настройку оптимальных параметров отдельных серверных БД. Администраторы БД также отвечают за предоставление прав на разноуровневый доступ к сопровождаемым ими БД для других пользователей.
Использование архитектуры "клиент-сервер":
1. резко уменьшает сетевой график;
2. понижает сложность приложений-клиентов (поскольку тем уже нет 1 необходимости обеспечивать целостность и безопасность БД и следить за параметрами многопользовательской работы с БД);
3. понижает требования к аппаратным средствам, на которых эти приложения функционируют (т.е. к компьютерам пользователей- клиентов);
4. повышает надежность БД, ее целостность, безопасность и секретность.
3.2.3. Многозвенная архитектура "клиент-сервер"
Развитие идеи архитектуры "клиент-сервер" привело к появлению многозвенной архитектуры доступа к базам данным (в литературе ее также называют трехзвенноя архитектурой,
N-tier или multi-tier архитектурой).Архитектура "клиент-сервер" является двухзвенной. Первым звеном является приложение клиента, вторым - сервер БД и сама БД.
В трехзвенной архитектуре наборы данных, бывшие ранее "собственностью" клиентских приложений, выделяются в отдельное звено, называемое сервером приложений (рис. 3.7).
Выше говорилось о модулях данных (
Data Module). По существу, это компонент Delphi контейнерного типа, подобно компоненту формы TForm, хранящий в себе другие компоненты. Такими компонентами для Data Module могут служить только невизуальные компоненты БД - компоненты типа "набор данных" (TTable, TQuery, TStoredProc) и компоненты типа TDataSource, являющиеся промежуточными компонентами, связывающими между собой компоненты типа "набор данных" и визуальные компоненты БД.Использование контейнеров
Data Module имеет то преимущество, что компоненты типа "набор данных", единожды размещенные в Data Module, могут использоваться во всех формах приложения. При этом компоненты типа "набор данных", размещенные в Data Module, обладают единым поведением для всего приложения. Это особенно важно при реализации бизнес-правил, хранящихся в приложениях клиента.Кроме того, модули данных, экспортированные в репозиторий, могут использоваться при разработке других приложений. Это обеспечивает повторное использование единожды разработанного программного кода и гарантирует единообразное поведение наборов данных во всех приложениях, использующих один и тот же модуль данных из репозитория.
Итак, модули данных в трехзвенной архитектуре "клиент-сервер" выделяются в отдельный "сервер приложений". Совместно с ним располагается
BDE. Теперь, при изменении бизнес-правил нет необходимости изменять приложения клиентов и обновлять их у всех пользователей-клиентов, как это было ранее, когда часть бизнес-правил хранилась в приложении клиента.Сервер приложений разделяется несколькими клиентами Он формирует запрос к удаленной БД (т.е. к
SQL-серверу). На нем расположены реальные наборы данных (в двухзвенной архитектуре "клиент-сервер" располагавшиеся в приложении клиента). В клиентском приложении размещается "клиентский набор данных" (компонент TClientDataSet). Он представляет собой локальную копию данных с сервера приложений. Таким образом, все изменения, вносимые пользователем в данные при помощи клиентского приложения, вносятся в локальную копию НД. При обновлении удаленного НД клиентское приложение посылает серверу приложений только изменившиеся записи. Сервер приложений, в свою очередь, отсылает эти изменения SQL-серверу, который вносит их в удаленную БД. Взаимодействие клиентского приложения (в многозвенном приложении называемого "тонким клиентом", thin client) с сервером приложений осуществляется при помощи так называемых "брокеров данных". Это появившиеся в Delphi 3 компоненты TRemoteServer (располагающийся в приложении тонкого клиента) и TProvider (расположенный на сервере приложений).3.3. Общая структура приложения, работающего с базами данных
На рис. 3.8 показана общая структура приложения, работающего с базами данных.
Как видно из рисунка, при рассмотрении структуры приложения работающего с БД, вполне можно абстрагироваться от расположения
BDE и самой базы данных. Приложение состоит из невизуальных и визуальных компонентов работы с БД, компонентов для выдачи отчетов (которые представляют разновидность визуальных компонентов), а также модулейданных.
Невизуальные компоненты имеют прямой выход на
BDE, которая, в свою очередь, контактирует с БД.Визуальные компоненты служат для представления данных из невизуальных компонентов, т.е. служат целям обеспечения интерфейса пользователя при работе с данными.
Модули данных служат для централизованного хранения отдельных экземпляров невизуальных компонентов с целью придания тем или иным наборам данных единообразного поведения во всем приложении.
Приложение состоит из одной или нескольких форм. Каждая форма может:• хранить и использовать свои "собственные" невизуальные компоненты;
• использовать невизуальные компоненты, хранящиеся в одном или нескольких модулях данных;
• использовать невизуальные компоненты, хранящиеся и используемые в
других формах.
Каждая форма может воспользоваться только "собственными" визуальными компонентами, поскольку визуальные компоненты выполняют интерфейсные функции и при деактивизации формы теряют свою видимость на экране.