ГЛАВА 1 ема базы данных

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

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

Как правило, каждый программный компонент уровня интерфейса данных тесно связан с одним из компонентов уровня интерфейса пользователя. При этом один программный компонент интерфейса данных может поддерживать несколько компонентов интерфейса пользователя (рис. 10-2)-Допустим, в системе присутствует форма Customer Maintenance, где отображается информация об одном покупателе и форма Customer Smrmту. котощл выводит информацию о нескольких покупателях. Поскольку обе этих формы представляют сущность Customer Ш-.ль), они могут иметь общие модули для форматирования и проверки параметра CusfomerNumbei (Номер покупателя) - функции, принадлежащей уровню интерфейса данных.

На физическом уровне компоненты интерфейса пользователя, как

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

На уровне интерфейса реализуются правила проверки дан-

ных, однако логика бизнес-процессов не входит в этот уровень. Так,

фрагмент кода или программный модуль, выполняющий проверку

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

товаров, пока не проверена платежеспособность заказчика) относятся к уровню интерфейса транзакций.

ЧАСТЬ 2 жт рити,тннщк сметем dss данных

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

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

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

физической реализации псриы.ч удобнее всего применять Visual Basic и Access. Например, объект Гнл7о/ ;<./чадеиствует метод Update,Bbi3bi-ваемы пце несколькими компонентами уровне фейса данных. Важно поскольку уровень интерфейса данных должен

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

Другими словами, вызов метода может иметь вид:

MyCustomer. Update ler. Cusioiner Name ,.

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

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

На уровне интерфейса внешнего доступа реализуется обмен данными между приложением и источниками данных. В системах баз данных программные компоненты уровня интерфейса внешнего доступа обрабатывают события обмена данными с механизмом

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

В идеале все процедуры на этом уровне должны быть реализованы так, полностью изолировать транзакции от специфики меха-

низма СУБД. Теоретически, при этом для переноса приложения, разработанного для работе! с механизмом СУБД Microsoft Jet, на платформу SQL Server достаточно всего лишь изменить программные компоненты уровня интерфейса внешнего доступа. Однако воплотить эту идею на практике весьма непросто.

Как уже упоминалось, на уровне слоя интерфейса за-

просы формируются, а на уровне слоя интерфейса внешнего досту-

на - только выполняются. Но учитывая различия между разными диалектами языка SQL, редко удается реализовать систему так, чтобы

ГЛАВА 10 Скемз liiau даннмх

полностью разделить эти два уровня. Рассмотрим простой пример: генерацию набора результатов, полученного при выполнении запроса одним оператором TRANSFORM в диалекте SQL, используемом механизмом СУБД Microsoft Jet. Чтобы выполнить запрос, потребуется написать несколько операторов на диалекте SQL, используемом SQL Server.

Если заранее известно, какие запросы будет выполнять разрабатываемое приложение, можно их непосредственно в схему базы данных и тем самым избежать проблем, связанных с особенностями мкснса, Здесь очень полезны параметрические запросы. Допустим, нужно найти в базе данных записи, относящиеся к клиенту по фамилии Джонс (Jones) или Смит (Smith). Вам не придется всякий раз заново составлять запросы - достаточно передать значение Jones или Smith в качестве параметра заранее составленного запроса.

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

tfieEngine = myData. EngineName Select Case theEngine Case SQLServer

build a SOL Server flavored query Case Jet

build a Microsoft Jet query Case Else

return an unl<nown engine error to tlie Data Interface layer

End Select

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