МЕТАСХЕМА АБС БИСКВИТ

Метасхема в АБС Бисквит представляет собой инструмент описания структуры хранения объектов в базе данных. Несмотря на название и наличие сходств, метасхема АБС Бисквита не является метасхемой объектно-ориентированного программирования.

Метасхема АБС Бисквита описывается в следующих таблицах БД:

• Class - классы метасхемы;
• XAttr  - реквизиты классов метасхемы;
• Class-Method - методы классов и реквизитов метасхемы.

КЛАССЫ

Все объекты в АБС Бисквите, такие как договора, счета, документы объединены в соответствующие классы. Так, к примеру, все договоры представляют собой класс loan. Разделение договоров по типу: кредитные, депозитные, частные вклады и т.д., осуществляется посредством создания подклассов для класса loan.

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

Для класса метасхемы определяется основная таблица базы данных, в которой хранятся его объекты. При этом одним из основных реквизитов объекта (полем в таблице) является ссылка на класс к которому он относиться. Так например, все договора в АБС Бисквит хранятся в таблице loan, а класс метасхемы, к которому принадлежит тот или иной договор, определяется значением в поле loan.class-code.

Класс метасхемы АБС Бисквит может быть абстрактным, т.е. не предполагает создания его объектов (экземпляров). Как следствие, такой класс не имеет связи с таблицей базы данных.

В качестве примера абстрактного класса в АБС Бискит можно привести класс СУБЪЕКТЫ. Данный класс не связан ни с какой таблицей базы данных и не предполагает создание его объектов, а является родителем для таких классов как PERSON (ФИЗ. ЛИЦА), CUST-CORP(ЮР. ЛИЦА), BANKS (БАНКИ) и т.д.

У абстрактного класса могут быть определены реквизиты и методы, которые в последствии будут унаследованы всеми  его подклассами.

РЕКВИЗИТЫ КЛАССОВ

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

Код дополнительного реквизита, для которого определяется значение в таблицах signs и tmpsigns указывается в поле code.

Связь значения определенного дополнительного реквизита с объектом, к которому он относится, осуществляется по полям: file-name, значение которого определяет основную таблицу объекта класса, к которому относится дополнительный реквизит и полем surrogate - ссылки на конкретный объект, которому принадлежит дополнительный реквизит. Surrogate представляет собой список значений определенных основных реквизитов, составляющих первичный ключ, по которому однозначно можно идентифицировать объект. Для договоров, например, это список состоит из значения полей loan.contract и loan.cont-code, так для кредитного договора с номером ДОГ00001/2015 surrogate будет равным "Кредит,ДОГ00001/2015".

Описание surrogate для таблиц классов метасхемы можно посмотреть в файле surr.i

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

Таблица хранения значений не индексированных реквизитов:

Таблица хранения значений индексированных реквизитов:

Таблица tmpsigns отличается от signs наличием поля since - даты, на которую определено значение темпорированного реквизита. Таким образом, в таблице tmpsigns в отличии от таблицы signs, для одного дополнительного реквизита может быть несколько записей со значениями определенными на разные даты.

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

АГРЕГИРУЕМЫЕ КЛАССЫ

Для связи объектов одного класса с другим в качестве значения реквизита может быть указан класс метасхемы, с которым осуществляется связь. Типом данных таких реквизитов является "class", а указанные в качестве значения классы - агрегируемыми классами. Заведение таких реквизитов осуществляется из отдельного меню "Агрегируемые классы".

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

FOR EACH <таблица агрегируемого класса> <условие агрегации> NO-LOCK:
   ...
END.

Так например, на классе loan заведен агрегируемый класс loan-cond со следующим условием агрегации:

WHERE loan-cond.contract  = loan.contract
  AND loan-cond.cont-code = loan.cont-code

Следовательно, полный запрос выглядит следующим образом:

FOR EACH loan-cond WHERE loan-cond.contract  = loan.contract
                     AND loan-cond.cont-code = loan.cont-code 
                   NO-LOCK:
...
END.

СВЯЗИ

Раздел Связи класса метасхемы описывает связи данного класса с другими классами метасхемы посредством специальной таблицы связи. Одним из примеров использования таких связей является модуль ПЛАСТИКОВЫЕ КАРТЫ.

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

Все существующие связи между классами метасхемы описаны в отдельной таблице xlink, а непосредственно связь конкретного объекта класса с объектами других связанных с ним классами в таблице links. К слову надо сказать, что таблице links соответствует одноименный класс метасхемы. Браузером класса links является процедура xlink-ed.p

МЕТОДЫ

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

Каждый метод имеет свой  уникальный в рамках класса код. Список всех доступных кодов методов описан в классификаторе class-method.

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

Процедура метода может быть как внешней, так и внутренней из библиотеки интерфейсов. Для указания внешней процедуры, в поле Процедура достаточно указать ее имя без расширения .p. Указание внутренней процедуры из состава библиотеки осуществляется путем указания имени самой процедуры и через разделитель запятая имени интерфейса, в котором она объявлена.

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

Для методов реквизитов look и chkupd, при указании параметров допускается использовать следующие ключевые слова - переменные, которые в процессе вызова метода будут предварительно заменены на следующие значения:
      Class - класс реквизита;
      Surr  - суррогат реквизита;
      Value - значение реквизита.
При этом первым символом в поле Параметры должен быть "^", иначе замена не будет осуществлена и  данные ключевые слова будут восприняты как значения: "Class", "Surr" и "Value".  

Если в качестве значения параметра необходимо передать неизвестное значение (?), то его следует указать как "__?".

Если передаваемое значение содержит символ "," (запятая), то он должен быть заменен на ";". При вызове процедуры метода и передаче ей значение параметра, автоматически будет осуществлена обратная замена.

МЕТОДЫ КЛАССОВ

Для классов, основным набором методов является:

• browse - браузер объектов класса;
• brwquery - метод  формирования запроса отбора записей для браузера;
• fltstruct - метод формирования структуры фильтра браузера;         
• join - контекстное меню;                                          
• form - экранная форма просмотра/редактирования/создания объекта класса.         
• initial - инициализация объекта в УТ
• update - создание объекта в УТ

Основным методом является метод browse. Именно его процедура вызывается из соответствующего меню АБС Бисквита. Методы brwquery и fltstruct являются вспомогательными методами для browse. Brwquery - определяет построение запроса для браузера, fltstruct отвечает за форму фильтра браузера.

Методы Initial и Update определяют процедуры работы с объектами класса в универсальных транзакциях.

МЕТОДЫ РЕКВИЗИТОВ

Основными методами реквизитов являются:

• browse - браузер реквизита;
• chkupd - проверка реквизита при обновлении;
• look - просмотр объекта.