<<
>>

Модель приложения БД

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

Schema - структура, описывающая схему БД (таблицы), расширенную информацией о связях, способах организации данных для пользователя (представления) и связях с пространственными данными;

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

Rules - структура для описания специфических бизнес-правил приложения;

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

Таким образом, модель приложения БД можно представить в следующем виде:

M=

Рассмотри структуры модели более подробно. Структура Schema=описывает множества таблиц Tbls={t1,...,tn}, пе\ и связей Refs={r1,...,rm}, meNмежду ними. Для всех таблиц БД определено множество схем C={c1,...,cl}.Тогда ti(cj), i=1,...,n, j=1,...,m- таблица со схемой cj, где Cj={a1,...,ap}схема таблицы ti, а ah, h=1,...,p- атрибут таблицы.

Каждый атрибут относится к определённому типу данных: VahR Type(ah)- тип атрибута. Определенны восемь типов Type={I,F,S,D,B,X,G,SD},где I- множество целых чисел, F- множество действительных чисел, S- множество строковых значений, D- множество значений дат и времени, B={true;false}- булевы значения, X- множество бинарных данных, G- множество растровых данных, SD- множество пространственных данных. Тип атрибута таблицы влияет на способ отображения и обработки данных из этого поля.

Каждая таблица состоит из конечного множества записей запись со схемой jа kg(ah)- значение записи kgна атрибуте ah,т.е.

значение поля.

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

присутствовать естественные ключи (например, «Район», «Улица», «Дом»). Комбинации полей естественных ключейбудем

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

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

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

Связи вида LRбудем называть простыми связями или ссылками на справочники.

Связи вида PR- это связи по первичным ключам.

Такие связи необходимо отличать от ссылок на справочники поскольку бизнес-правила совместной работы с таблицами отличаются. Например, при работе с представлением построенном на таблице A связанной с таблицей B связью вида PR,сначала создаётся запись в таблице A, а соответствующая запись (с таким же PK) в таблице B должна создаваться только при редактировании её полей (таблицы B).

Связи вида DR- связь типа детали.

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

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

Наличие связей типа LRили PRпозволяют строить представления. сохранёнными SQL-запросами, представления в предлагаемой модели являются наборами данных, которые построены на одной базовой таблице и содержат информацию о декодировании связей для получения данных из связанных таблиц. Такие представления позволяют автоматически организовать работу со связанными таблицами, как с одним набором данных. НаРисунок 4 представление построено на таблице Т1и содержит значения из таблиц T2 и Т3 полученные через декодирование связей типа PRс Т3 и LRс Т1.

Рисунок 4 Пример представления

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

Как правило, современные приложения БД имеют оконный интерфейс. Каждое окно приложения ориентировано на решение определённой задачи и является формой, на которой размещены визуальный компоненты интерфейса. Для ПБД свойственны следующих визуальные компоненты: Btn - кнопка, Edt - текстовое поле, Lbl - надпись, Cbx- выпадающий список для выбора значений, Dtp- календарь, Chkt- флаг, Img- поле с картинкой, Grd- сетка (таблица), GB - контейнер, TS- закладка.

Edt, Lbl, Cbx, Dtp, Chkt, Img- относятся к информационным компонентам, их задача отображение информации пользователю. Grd, GB, TS- организационные компоненты, позволяющие структурировать другие компоненты на формах. Btn- является элементом инициирования события. Выделим как отдельный компонент fCbx- выпадающий список с функцией «автокомплит» (автоматическая фильтрация при вводе значений). И так, элементы пользовательского интерфейса для представления и обработки данных из БД можно представить следующим множеством:

E={Btn,Edt,Lbl, Cbx,Dtp, Chkt,Img,fCbx, Grd, GB, TS}.

Практических во всех приложениях БД для работы пользователя с каждой таблицей реализуется два режима Mod=(List,Card).В режиме Listданные представляются пользователю в виде списка записей. При этом используется элемент Grd. Другой режим Cardпредназначен для работы с индивидуальной записью таблицы (представления) и реализуется через комбинацию визуальных компонентов из Eразмещённых на форме.

Для каждого атрибута ahe Cj, h=1,...,pна форме должны создаваться элементы идентификатор и модификатор. В качестве идентификаторов выступают элементы Lbl,в которые отображаю имена атрибутов. Элементы модификаторы определяются на основе типов атрибутов структуры Schema и их принадлежности базовой или связанным таблицам (полученным по ссылкам):

k(ah) → Edt, если Type(ah)=IVFVS, k∈ti, h=1,... ,p;

k(ah) → Dtp, если Type(ah)=D, k∈ti, h=1,...,p;

k(ah) → Chkt, если Type(ah)=B, k∈ti, h=1,...,p;

k(ah) → Cbx, если, Type(ah)=IvF VS, k(ah) ∈v(c,)=(ti(cj), V,, LR,,PR,), ahє cj, h=1,. ,p;

k(ah) → Img, если Type(ah)=G, k∈ti, h=1,...,p;

k(ah) →fCbx, если Type(ah)=IvFVS, k(ah) ∈v(c,)=(ti(cj), V', LR,,PR,), ah∈NF⊂Cj.

В случаях, когда поля получены по ссылкам (в представлениях) или являются FK рядом с ними присутствует кнопка (Btn)для перехода к записям по ссылке. Несколько полей могут быть выделены в отдельные блоки. Поддерживается два вида блоков - группа (GB) и закладка (TS). Если Type(ah)=SD,то создаётся кнопка (Btn) вызывающая таблицу связей объектов цифровой карты с записями таблиц (представлений).

Структура Rules={RO^CHK^MO^RO^COLORTEX^COLORFILTER}отвечает за специфические режимы и правила работы с данными. Например, если RO(ti),то работа с таблицей tiбудет в режиме «только для чтения», поля таблицы будут не активны для редактирования.

Режим CHK(ti(c'i),{0,1})отвечает за проверку вводимых данных на уникальность значений, при этом существует два режима проверки: ошибка (1) и предупреждение (0). В первом режиме при вводе уже существующего в таблице значения сохранение записи блокируется, пока пользователь не введёт уникальные значения. Второй режим предупреждает о совпадении вводимых значений с уже существующими, но сохранять позволяет.

Механизм MO(ti, tii, r=DR(ti, tii), loci∈LOC)позволяет автоматически создавать пространственные объекты вида loci∈LOC, LOC={Point, Line, PolyLine, Polygon, PolyPolygon } для записей из tiна цифровой топооснове по метрике из таблицы деталей tii

Структура Plugins=отвечает за взаимодействие с внешними приложениями, решающими специфические задачи. Данная структура обеспечивает для ti∈Tblsпередачу данных во внешнее приложение dllz∈Dll,вызов которых осуществляется из пользовательского интерфейса dx∈D, D^Display.

ROWCOLORи TEXTCOLORрежимы задания цвета и текста в строках таблицы (для элемента интерфейса Grd)в зависимости от значений определённых атрибутов.

2.3.

<< | >>
Источник: Фереферов Евгений Сергеевич. ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ СОЗДАНИЯ ПРИЛОЖЕНИЙ БАЗ ДАННЫХ С ГИС-ФУНКЦИОНАЛЬНОСТЬЮ НА ОСНОВЕ ИХ ДЕКЛАРАТИВНЫХ СПЕЦИФИКАЦИЙ. ДИССЕРТАЦИЯ на соискание ученой степени кандидата технических наук. Иркутск - 2014. 2014

Еще по теме Модель приложения БД:

  1. Регрессионные модели оценки ставки восстановления
  2. Оценка ставки восстановления на основе моделей ценообразования финансовых инструментов
  3. Ставка восстановления как объясняющая переменная в моделях оценки кредитного риска и ценообразования облигаций
  4. Модель личностных и профессионально важных качеств идеального школьного учителя
  5. 17.1. Структурные модели административно- государственного управления в зарубежных странах.
  6. Приложения
  7. 4.3 Модель формирования электрического потенциала в системе «медь - графит»
  8. 3.1. Ценностные и коммуникативные основания модели идеального школьного учителя
  9. Глава 2 Сравнительный анализ действующих моделей оценки ставки восстановления
  10. Модели движения воздуха в воздушных пространствах конструкций вентфасадов при турбулентном режиме
  11. Глава 3. Разработка модели оценки ставки восстановления по корпоративным облигациям российских эмитентов
  12. Модели движения воздуха в воздушных пространствах конструкций вентфасадов при переходном режиме
  13. Модели движения воздуха в воздушных пространствах конструкций вентфасадов при ламинарном режиме
  14. ПРИЛОЖЕНИЕ 4
  15. ПРИЛОЖЕНИЕ
  16. ПРИЛОЖЕНИЕ 1
  17. Приложение 1
  18. ПРИЛОЖЕНИЕ 3
  19. ПРИЛОЖЕНИЕ
  20. ПРИЛОЖЕНИЕ 2