В процессе разработки нередко приходится производить определение метаданных дважды: при создании серверной части информационной системы и при создании клиентских приложений, что потенциально является источником ошибок и несогласованности метаданных серверной и клиентских частей информационной системы. Кроме того, такие системы сложно модернизировать и сопровождать, особенно в случае изменения структуры базы данных. Разработка интерфейсов пользователя для приложений, основанных на сложных структурах данных, предъявляет к разработчику высокие требования даже при использовании таких совершенных инструментов, как Borland Delphi.
Однако нередко доступ к модели данных желателен не только в процессе проектирования, но и в процессе выполнения приложения, особенно когда информационная система подвергается модернизации. Эта ситуация весьма типична - к сожалению, даже эксперт в предметной области, обслуживаемой разрабатываемой информационной системой, нередко не в состоянии предусмотреть всех нюансов ее реальной эксплуатации. В случае, если к модели данных приложение обращается во время выполнения, процесс модернизации и сопровождения информационной системы требует меньших временных и финансовых затрат.
Проблема использования созданной с помощью CASE-средства модели данных в системах с так называемым "толстым" клиентом может быть решена по-разному. Наприме , некоторые CASE-средства (ERwin, S-Designer) позволяют генерировать формы при ожения SQL Windows или PowerBuilder на основе модели данных (как правило, стан артного внешнего вида). В случае Delphi эта проблема решается несколько иным способом - в данном случае используется тот факт, что формат словаря данных Delphi известен, так же как и форматы словарей данных (или непосредственно ER-диаг амм) CASE-средств, что должно позволить осуществлять перенос данных между ними. На этом принципе основано действие включенного в комплект поставки Delphi 2.01 CASE Expert-а, осуществляющего односторонний перенос расширенных атрибутов из ER-диаграмм популярных CASE-средств в словарь данных Delphi 2.01, что позволяет в какой-то степени использовать серверные бизнес-правила при проектировании клиентского приложения. Однако у этого инструмента есть свои недостатки. Во-первых, невозможен перенос метаданных обратно из словаря данных в ER-диаграмму. Во-вторых, это средство с ERwin работает некорректно. В-третьих, проблемы проекти ования пользовательского интерфейса в случае сложной модели данных решаются лишь частично.
Еще одним способом решения проблемы доступа к метаданным из клиентского приложения является создание чувствительных к метаданным компонентов. Эта проблема ешается с помощью описываемого ниже инструмента MetaBASE (Erwin for Delphi).
Из этого следует, что метаданные постоянно доступны в процессе разработки и в полнения приложения. Поэтому возможна модификация модели данных и, соответствен о, серверной части информационной системы без модификации клиентских приложе ий, так как визуальные компоненты MetaBASE, используемые в приложении, адапти уются к изменениям в модели данных.. При этом повышается скорость разработки при ожений и упрощается модернизация и сопровождение информационной системы даже в случае сложных моделей данных, так как программист в этом случае избавлен от еобходимости написания кода, реализующего бизнес-логику приложения.
MetaGen также может осуществлять перенос измененных объектов MetaBASE обратно в модель данных. Иными словами, это полноценный инструмент two-way-tool.
Metamodel - объект, который содержит всю информацию об объектах модели данных - сущ остях, индексах, атрибутах, доменах и связях. Кроме того, Metamodel содержит расширенные атрибуты типа масок, меток и т.д., которые могут быть изменены в редакторе MetaBASE Editor.. Все объекты модели данных доступны при создании приложения.
MetaBASE Editor- иерархическое окно просмотра метамодели, позволяющее редактировать модель анных, изменять расширенные атрибуты, синхронизировать модели данных в ER-диаг амме и в словаре данных, выбирать интерфейсные элементы для отображения таблиц и полей, выбирать способ доступа к данным (таблица или запрос). Этот редактор метаданных используется в среде разработки в качестве редактора свойств компоне т, входящих в комплект поставки MetaBASE (рис.1).
Библиотека визуальных компонентов MetaBASE, имеющих прямой доступ к словарю данных.. Эти VCL-компоненты существуют в 16- азрядном и 32-разрядном вариантах.
TApplicationGS используется для определения общей информации, не имеющей непос едственного отношения к модели данных. Пример - "горячие клавиши", которые яв яются допустимыми в приложении.
TMetaBaseGS представляет собой центральный модуль для определения бизнес-прави . В его свойствах определяются правила проверки достоверности, форматирования и значений по умолчанию. Посредством этого компонента осуществляется связь меж у словарем данных Metamodel и приложением.
TQueryGS - наследник стандартного компонента TQuery Delphi. Однако этот компо ент непосредственно связан с Metamodel . Все поля, содержащиеся в TQueryGS, автоматически используют бизнес-правила, определенные в TMetaBaseGS. Кроме стандартных функций, TQueryGS поддерживает асширенные функции QBE (Query By Example - запрос по образцу).
TTableGS - наследник стандартного компонента TTable Delphi's, также непосре ственно связанный с Metamodel. Все поля, содержащиеся в TTableGS, автоматически подчиняются бизнес-прави ам, определенным в TMetaBaseGS. Кроме стандартных функций, TTableGS поддерживает асширенный поиск и функции индексирования.
TDataSourceGS - интерфейс между компонентами набора данных (TTableGS, TQueryGS) и визуальными компонентами форм. TDataSourceGS - наследник TDataSource Delphi, способный использоваться в качестве переключателя между обычным режимом визуального отображения данных, режимом запроса по образцу или режимом поиска в таб ице и режимом индексации.
TDBGridGS - многофункциональный компонент, который может отобразить данные в виде "интеллектуальных" таблиц (наподобие DBControlGrid). При этом TDBGridGS ото ражает поля с помощью тех интерфейсных элементов, которые определены в словаре данных Metamodel (например CheckBox, Search Table и т.д.). TDBGridGS может также быть испо ьзован для режима Query By Example.
TDBFieldGS - центральный компонент для отображения данных.. Он отоображается самостоятельно в виде того интерфейсного элемента, который определен в словаре анных Metamodel (например как check-box или lookup field)
TLabelGS связан с TDBFieldGS и представляет собой метку, определенную в в с оваре данных Metamodel
TDBEntityResolveGS - информационный компонент, который позволяет представить текст для расшифровки поля из текущего набора данных, используя связанную слова ную таблицу.
TDBAttributResolveGS применяется для отображения дополнительной информации, оступной с помощью внешнего ключа, из связанной таблицы (а именно, атрибуты соответствующей записи).
TIdxDBFieldGS используется для определения значения поиска в индексированной таблице.
TIdxControllerGS используется для активизации процесса поиска (возможно, пос едством диалога)
TQbeDBFieldGS похож на компонент TIdxDBFieldGS.. Он используется для ввода з ачений Query By Example. Компоненты TQbeDBFieldGS могут быть скомбинированы для выполнения запроса к нескольким полям.
TQbeControllerGS из всех значений, записанных в компонентах TQbeDBFieldGS, создает команду SQL и выполняет запрос. При объединении этого компонента с TDBGridGS, можно переключаться между режимом визуального отображения данных и режимом Query By Example.
TDBIndexComboGS предназначен для изменения индекса таблицы, отображаемой с помощью компонента TTableGS.
TDBEntityComboGS позволяет выбрать таблицу из словаря данных во время выполне ия.
TDBAttributComboGS позволяет изменить атрибут DBFieldGS во время выполнения.
Первым этапом создания информационной системы является анализ предметной области, проектирование на его основе логической схемы будущей базы данных (определение сущностей, атрибутов и связей), создание соответствующей физической схемы и, наконец, генерация объектов базы данных (таблиц, индексов, триггеров). Для этой цели используется ERwin (в нашем случае версии 2.6 beta). Центральная сущ ость Objects1 связана с другими сущностями посредством внешних ключей. Структура модели данных выглядит следующим образом (рис.2):
Соответствующая физическая структура была сгенерирована на сервере Personal Oracle 7.2 for Windows 95, и в таблицы был занесен тестовый набор данных.
Так как приложение должно иметь доступ к модели данных во время выполнения, с едующим шагом является перенос метаданных в словарь данных MetaBASE (рис.3) и создание соответствующих BDE-алиасов (псевдонимов), при этом имя проекта в ути ите MetaGen и имя соответствующего алиаса должны совпадать. Для простоты будем хранить словарь данных и саму базу данных под одними тем же псевдонимом.
Далее выбираем нужный нам файл ER-диаграммы формата .erx, выбираем BDE-алиас для хранения словаря данных и осуществляем перенос метаданных в созданный слова ь данных.
После переноса метаданных можно отредактировать их с помощью MetaBASE Editor (рис.1).
Теперь можно приступить к созданию клиентского приложения. Для этого нужно создать в Delphi новый проект и поместить на пустую форму компонент MetaBaseGS (именно он отвечает за бизнес-правила и связь с метаданными) со страницы MetaBASE палитры компонентов.
Далее нужно присвоить свойству DataBaseName в инспекторе объектов Delphi имя соответствующего BDE-алиаса (в нашем случае NUCLEAR), а свойству Connected значение ‘true’. С этого момента среде разработки станут доступны метаданные, перенесенные анее на сервер.После двойного щелчка мышью на этом компоненте появится окно MetaBASE Editor (рис.5).
Для начала создадим броузер для просмотра и редактирования списка предприятий. Для этой цели нажмем в окне MetaBASE Editor кнопки G и T , что соответствует использованию по умолчанию компонентов TableGS и DBGridGS
Возьмем объект OBJECTS1 и переместим его на нашу форму . На форме появится сетка, отображающая данные из этой таблицы, а также все MetaBASE-компоненты, необходимые для ее функционирования, например, компонент DataSourceGS и компонент TableGS . (рис.6)
После компиляции проекта можно исследовать функционирование полученного приложения. Следует обратить внимание на то, что все поля, имеющие связи с помощью внешнего ключа, отображаются в виде так называемых полей помощи (assist field в терминологии авторов продукта). При нажатии на кнопку с многоточием появляется вспомогательная таблица (assist table), связанная с исходной по данному полю (рис.7).
Следует отметить, что при разработке приложения можно влиять на внешний вид и состав вспомогательной таблицы.
При необходимости отсортировать таблицу в порядке возрастания или убывания какого-либо атрибута достаточно выбрать раздел Indexes в MetaBASE Editor, выбрать атрибут для сортировки и перенести его на существующую сетку формы (рис.8).
Чтобы помещать поля редактирования на форму, достаточно перенести на форму нужные атрибуты. При этом на форму автоматически будут перенесены метки и единицы измерения величин.
Для управления данными в таблице полезно поместить на форму компонент DBNavigatorGS и установить свойство DataSource этого компонента равным dsOBJECTS1. Затем можно скомпилировать приложение (рис.9):
Следует отметить, что редактировать данные можно и в таблице, и в полях редактирования, при этом для полей, по которым осуществляется связь с другими таб ицами, можно активизировать соответствующие вспомогательные таблицы, а при изменении модели данных изменится и вид таблицы (при этом перекомпилировать приложение не требуется)
Теперь добавим в наше приложение возможности поиска. С этой целью добавим компонент IdxControllerGS на форму и установим свойство DataSource для этого компонента равным равным dsOBJECTS1. Скомпилируем приложение (рис.10):
При нажатии кнопки поиска появляется диалог поиска, похожий на показанный ниже При этом можно использовать вспомогательные таблицы для облегчения процесса поиска (рис.11).
Теперь попробуем отобразить в приложении связь (master-detail). Для этого нуж о из MetaBASE Editor выбрать сущность DEVICE и переместить ее на форму. Для установления связи меж у таблицами DEVICE и OBJECTS1 возьмем отношение OBJECTS1 сущности DEVICE и поместим его на таблицу OBJECTS1. В этом случае таблица DEVICE будет являться master-таблицей, а OBJECTS1 - detail-таблицей. Далее следует выбрать нужные строки в появившемся диалоге (рис.12):
После компиляции можно убедиться, что таблица OBJECTS1 связана с таблицей DEVICE (рис.13):
Теперь создадим проект, основанный на запросах (что более удобно в случае большого объема данных). Для этой цели создадим новый проект и поместим на пустую форму компонент MetaBaseGS. Далее переключим кнопки в окне MetaBASE Editor, выбрав кнопку G и кнопку Q, что соответствует использованию по умолчанию компонента QueryGS
Далее переносим на форму сущность OBJECTS1 и, как и в предыдущем проекте, получаем в результате броузер с данными из этой таблицы. После этого добавим на форму компонент QbeControllerGS (рис.14).
После компиляции проекта получим броузер для таблицы OBJECTS1 (рис.15).
При нажатии на кнопку, в виде которой отображается QbeControllerGS, можно осуществить запрос по образцу с использованием вспомогательных таблиц и выпадающих меню для знаков операций отношения: (рис.16)
Отметим, что мы не написали ни одной строки кода, создавая эти приложения, и при этом могли в процессе разработки постоянно модифицировать модель данных, синхронизируя ее с ER-диаграммой.
Задать вопросы о MetaBASE и получить trial-версию этого продукта можно в компании Interface Ltd.
Литература.
e-mail: elmanova@interface.ru