FlexiObjDB

FlexiObjDB
Объектно-ориентированное на предметную область
долговременное хранилище информации.

Все узлы в "дереве" узлов имеют сквозную нумерацию.

В текущей версии хранилища приняты след. ограничения :

1. Кол-во символов в идентификаторе узла : 1 .. 4
2. Допустимые символы (в идентификаторе узла) : '0' .. '9' (т.е., допускается только цифровой идентификатор)
3. Узел должен иметь уникальный идентификатор в контексте "дерева" узлов !

Идентификатор конкретного узла "зашивается" на уровне хранимой процедуры : GET_ID_THISNODE

После того, как в узел начали поступать данные (на уровне таблиц баз данных, включая и таблицы самого узла) - идентификатор узла НЕ может быть изменен. Иначе это приведет к "информационным коллизиям" при синхронизации данных в контексте "дерева" узлов !

Примеры корректных идентификаторов узлов :

0 1 2 10 20 23 99 100 230 9999 789 и т.д.

Примеры НЕ корректных идентификаторов узлов :

00 01 002 0000 01234 12345 и т.д.

Все "базы данных" в контексте узла имеют сквозную нумерацию.

В текущей версии хранилища приняты след. ограничения :

1. Кол-во символов в идентификаторе "базы данных" : 1 .. 2
2. Допустимые символы (в идентификаторе узла) : '0' .. '9' (т.е., допускается только цифровой идентификатор)
3. База Данных должна иметь уникальный идентификатор в контексте узла !
4. Узел также считается "базой данных". Его идентификатор (как базы данных) = '0'.
5. В каждой "базе данных" хранится идентификатор узла, к которому она "привязана".

Идентификатор конкретной базы данных "зашивается" на уровне хранимой процедуры : GET_ID_THISDB.
Идентификатор узла, к которому "привязана" база данных , "зашивается" на уровне хранимой процедуры : GET_ID_THISNODE.

После того, как в "базу данных" начали поступать данные (на уровне таблиц) - идентификатор НЕ может быть изменен. Иначе это приведет к "информационным коллизиям" при синхронизации данных в контексте как узла, так и "дерева" узлов !

Примеры корректных идентификаторов "баз данных" :

0 1 2 10 23 40 99 75 и т.д.

Примеры НЕ корректных идентификаторов :

00 01 02 03 012 123 и т.д.

"Полный идентификатор" базы данных в контексте "дерева" узлов формируется следующим образом :

Символ разделитель определен в контексте хранимой процедуры GET_DELIMITER_IDNODE.
В текущей версии в качестве разделителя (между id-узла и id-базы_данных) принят символ : ! (восклицательный знак)

Примеры "полных идентификаторов" "баз данных":

Для идентификации строк в таблицах "базы данных" используются (за некоторым исключением) генераторы.
Строка получает уникальный ID - в контексте триггера таблицы "before insert".
После того, как строка создана - ее ID изменить невозможно (контроль на уровне триггеров "before update").

Идентификация любой сущности (строки таблиц) "базы данных", в контексте узла, производится единообразно (за некоторым исключением) следующим образом :

"Полный ID-сущности" = "Полный ID-базы_данных" + разделитель + "ID-строки(на уровне таблицы)"

"Полный ID-сущности" вычисляется в хранимой процедуре GET_IDTHIS_WITH_NODE_DB.

Символ разделитель определен в контексте хранимой процедуры GET_DELIMITER_IDDB.
В текущей версии в качестве разделителя принят символ : - (минус)

0!1-1 - идентификатор строки в таблице какого-либо справочника
12!32-0_0_75432 - идентификатор строки в "дереве" объектов/процессов (см. ниже)

SYS_EVENTS_IN_TABLES	- системный протокол событий на уровне таблиц "базы данных". Поэтому, строки в этой таблице имеют тип INTEGER.
SYS_CALENDAR	- системный календарь (в качестве "primary key" принята "Дата")
SYS_HHMMSS	- системные "сутки" (в качестве "primary key" принято "Время hh:mm:ss")
Перечень таблиц "баз данных" хранилища :
SYS_TABLES_TOP SYS_TABLES_MACRO SYS_TABLES_GRP SYS_TABLES_LIST SYS_TABLE_FIELDS	эта информация относится к концептуальным свойствам всей системы и должна быть едина для всех "баз данных" хранилища (изменяться не должна). Поэтому, строки в этих таблицах имеют тип INTEGER.

Идентификация всех строк таблиц (кроме исключений; "дерева" объектов/процессов; свойств объектов/процессов) производится по следующему алгоритму :

1. Проверяется (в триггере "before insert") "входное" значение "ключевого поля" (ID_THIS).
Если значение "пустое", то производится вычисление значения поля, в противном случае - нет (предполагается, что значение было вычислено в ПО)

2. Для вычисления используется значение, возвращаемое соответствующим генератором, и "Полный ID-базы_данных".

/* Проверяем, задан ли ID в ПО */
EXECUTE PROCEDURE THIS_ID_IS_EMPTY(NEW.ID_THIS) RETURNING_VALUES :C;
IF (:C>0) THEN BEGIN /* ID не задан - вычисляем */
    /* ===================================== */
    /* Вычислить значение поля ID_THIS для новой записи (с учетом ID-узла и id-DB) */
    C = GEN_ID(GEN_L_PROPENUM_VAL,1);
    EXECUTE PROCEDURE GET_IDTHIS_WITH_NODE_DB (:C) RETURNING_VALUES (NEW.ID_THIS);
    /* ===================================== */
END

Термин "пустое" означает , что величина может иметь любое из следующих значений :

    NULL     - "отсутствие" значения
    ''       - пустая строка
    'empty' - цепочка символов empty
    'aaa'    - цепочка символов aaa

Возможно (в дальнейшем) этот перечень будет расширен или изменен.
Поэтому рекомендуется для оценки "пустого" значения поля ID_THIS применять хранимую процедуру THIS_ID_IS_EMPTY.

Идентификация строк в таблице OBJECTS_TREE производится по след. алгоритму (может отличаться от текущей реализации) :

Весь этот алгоритм реализован на уровне хранимой процедуры: GET_ID_OBJECT .

Весь этот алгоритм реализован на уровне хранимой процедуры: GET_ID_OBJPROPENUM .

Весь этот алгоритм реализован на уровне хранимой процедуры: GET_ID_OBJPROPNUMBER .

______________________________________
(c) Sergey Popov, респ.Коми, г.Усинск,(2009)