Формирование и ведение данных¶
Правила подготовки данных¶
В данном разделе описывается формирование модели reference (ссылки) констант и переменных. Классификация констант и переменных позволяет идентифицировать объект и иметь представление об объектах, которым он принадлежит. Данная информация применима к объектам PromUC для сбора, маршрутизации, визуализации и управления.
Примечание
Информация об объектах PromUC Framework (хранение данных) находится в разделе «Порядок и средства заполнения базы данных» и не относится к разделу «Правила подготовки данных»
Классификация объектов¶
Классификатор объектов имеет обязательную, типизированную часть и пользовательскую часть, которая разрабатывается в рамках проекта.
/owner/project/class/objects/objects/objects/
owner - Владелец, логин юридического или физического лица
project - Проект, название проекта. В одной системе может быть несколько проектов
class - Класс, назначение классификатора в системе
Остальная часть классификатора имеет произвольную форму, разработанную в рамках проекта.
Примечание
Ниже приводятся примеры применения классификатора для сферы IoT, но данный подход может быть применен к любым моделям в сфере IT и даже за ее пределами.
Пример применения классификатора ниже для получения сигнала с датчика температуры:
/gazprom/lakhta-center/telemetry/heating/itp-2/hub-27/ai/27074
рекомендуется при проектировании конфигураций для визуализации данных использовать относительный принцип, при этом:
подставится текущий {owner}
./lakhta-center/telemetry/heating/itp-2/hub-27/ai/27074
подставится текущий {owner} и {project}
telemetry/heating/itp-2/hub-27/ai/27074
Основные Классы¶
Наименование класса в классификаторе определяет назначение всего классификатора в системе и находится после {owner} и {project}
/owner/project/class/objects/objects/objects/
Основные классы в PromUC:
scada - вызывает визуализацию конкретной системы
template - вызывает шаблон визуализации
svg - svg примитивы
img - png, gif, jpeg примитивы
pult - вызывает пульт управления
telemetry - данные с датчиков и контроллеров
control - телеуправление
Примечание
Классы определяют алгоритмы (функции или методы) для работы с этими объектами, могут быть дополнены разработчиками PromUC.
Классификация topic mqtt¶
Для отправки сообщения в топик брокера MQTT используется классификатор класса {telemetry}
Пример топика публикации MQTT
/gazprom/lakhta-center/telemetry/heating/itp-2/hub-27/ai/27074
сокращение топика при отправке в типизированной части не допускается, допускается подписка на группу топиков.
Пример подписки на группу:
/gazprom/lakhta-center/telemetry/*
При этом для каждого пользователя в RabbitMQ устанавливается точка входа с правами по приведенному выше примеру.
Для публикации сообщения управления через брокер (в случае если такая функция активирована) служит класс {control}
Пример топика управления аналоговым сигналом:
/gazprom/lakhta-center/telemetry/heating/itp-2/hub-27/ao/27032
Порядок и средства заполнения базы данных¶
PromUC Framework — это гибкий интерфейс доступа к данным, позволяющий создавать необходимую модель данных с возможностью модернизации с минимальными затратами в процессе эксплуатации системы.
Основными элементами модели данных в PromUC Framework являеются Классы, Объекты и Свойства.
Определение:
Класс - модель для создания объектов определённого типа, описывающая их структуру (набор полей и их начальное состояние) и определяющая алгоритмы (функции или методы) для работы с этими объектами.
Свойство - описывают объекты, экземпляры в классе создавая его структуру.
Объект - экземпляр класса.
Классы классифицируют объекты, которые, в свою очередь, могут также являться классами. Класс может быть наследован от другого класса. Объекты - это экземпляры классов. Они могут иметь входящие или исходящие связи с объектами других классов.
Класс является объектом родительского класса.
Каждый класс описан свойствами. Свойства - это так же объекты определенного класса «Поля» унаследованного от класса «Свойства». Объекты класса «Поля» связаны с свойством Тип данных.
Классы и Объекты PromUC Framework делятся на Системные и Пользовательские.
Системные Классы и Объекты¶
Системные объекты имеют отражение в коде системы PromUC Framework определяющие алгоритмы (функции или методы) для работы с этими объектами.
Примечание
Расширение системных объектов - это увеличение функциональности системы и производится разработчиком системы PromUC Framework.
Класс «objects» является корнем системы. Он содержит свойства общие для всех объектов, например, «экземпляр». Расширение класса «objects» позволит добавить свойства всем объектам системы.
Например:
Добавим пользовательское свойство "Дата" для обозначения даты создания объекта.
Это свойство получат все объекты системы (Классы, Поля, Связи итд)
Все объекты классифицированы и каждый класс является экземпляром (объектом) класса «Классы». Класс «Классы» является экземпляром (объектом) самого себя. Класс «Классы» унаследован от Класса «objects» который так же является экземпляром (объектом) класса «Классы». Другими словами класс «objects» и класс «Классы» классифицированы и описаны в классе «Классы» а сам класс «Классы» унаследован от класса «objects».
Класс «Свойства» является абстрактным (не предполагает создания экземпляров) и описывает общие свойства всех своих потомков. От класса «Свойства» унаследованы классы «Поля», «Значения», «Константы». От класса «Поля» унаследованы Классы «Связи», которые описывают связи между объектами. Класс «Действие» описывает какие действия можно производить с объектами, экземпляры (объекты) класса «Действие» могут быть только системные.
Например:
Системный объект "delete" описывает удаление объектов
Пользовательские Классы и Объекты¶
Пользовательские классы не имеют отражение в коде системы PromUC Framework, они классифицируются в системном классе «Классы», поэтому система понимает как с ними работать. Пользователь может создать любую модель данных на основе системных классов имеющую большое количество пользовательских классов и объектов, а так же связей между ними. Пользователь может наследовать пользовательские классы от системных перенося их функционал на свою модель, заполнять базу данными и получать данные в нужном виде и с необходимыми условиями.
Такой подход позволяет создавать гибкие пользовательские интерфейсы, где не требуется написание специализированных форм, функции или методов для каждой модели работы с базой данных, вместо этого пишутся универсальные инструменты работы с PromUC Framework, что в будущем не требует исправления программного кода в случае модернизации системы.
Например, мы создаем пользовательский класс «Сотрудники» в системном классе «Классы», в классе «Поля» добавляем все необходимые свойства описывающие класс «Сотрудники», например «Фамилия», «Имя», «Отчество» некоторые свойства, например «Должность», связываем с объектами Класса «Должности», который описывается и классифицируется своими свойствами. Форма для заполнения данных в клиентском приложении должна быть разработана универсальная, которая, при открытии, запрашивает объекты класса «Поля» и свойства класса «Сотрудники». В ответ приходит вся необходимая информация описывающая свойства объекта «Сотрудники» в классе «Поля» и «Наименование», «Тип данных» и тд, что позволяет вывести пользователю необходимую форму для просмотра и редактирования данных в различных представлениях. В случае модернизации, например мы добавили классу «Сотрудники» новое свойство, а классу «Поля» объект «Департамент» и связали с объектами класса «Департаменты». Нам нет необходимости дорабатывать программу, так как при открытии формы, она получит все свойства, включая новые, и отобразит их. Это позволит вносить и просматривать новые данные.
На самом деле PromUC Framework позволяет клиенту отдать по запросу сразу всю необходимую информацию структурируя ее в JSON (о чем ниже), но в примере мы разбирали последовательность для понимания как это работает.
Системная модель данных¶
Для каждого класса создается таблица в базе данных. В таблице принадлежащей классу хранятся принадлежащие ему объекты. В столбцах таблицы отражены свойства класса, которые, в свою очередь, являются объектами класса «Поля» кроме унаследованных, унаследованные свойства хранятся в родительских классах. Иначе говоря таблица соответствующая классу содержит в столбцах специфичные ему свойства.
Идентификаторы всем экземплярам классов (объектам) присваиваются сквозным методом; для системных, начиная с 10 000 000, и для пользовательских, начиная с 20 000 000. Колонки таблиц связаны с объектами класса «Связь» унаследованного от класса «Поля» и именуются тем же сквозным идентификатором.
Класс |
Свойства |
Наименование |
|---|---|---|
10 000 000 |
Объекты |
|
10 000 000 |
||
10 000 022 |
Класс-владелец |
|
10 000 023 |
Объекты-помощники |
|
10 000 001 |
Классы |
|
10 000 000 |
||
10 000 024 |
Обозначение |
|
10 000 025 |
Название |
|
10 000 026 |
||
10 000 027 |
Унаследованы |
|
10 000 059 |
Количество элементов |
|
10 000 002 |
Внутренний тип |
|
10 000 000 |
||
10 000 028 |
Обозначение |
|
10 000 029 |
Название |
|
10 000 030 |
PG тип |
|
10 000 031 |
PG код скаляра |
|
10 000 032 |
PG код массива |
|
10 000 003 |
Типы |
|
10 000 000 |
||
10 000 033 |
Обозначение |
|
10 000 034 |
Название |
|
10 000 035 |
Внутренний тип |
|
10 000 004 |
Свойства |
|
10 000 000 |
||
10 000 036 |
Класс-владелец |
|
10 000 037 |
Обозначение |
|
10 000 038 |
Название |
|
10 000 039 |
Тип |
|
10 000 040 |
Массив |
|
10 000 041 |
Измерения |
|
10 000 042 |
Значение функции |
|
10 000 005 |
Поля |
|
10 000 000 |
||
10 000 043 |
Значение по-умолчанию |
|
10 000 044 |
Обязательное |
|
10 000 006 |
Связи |
|
10 000 000 |
||
10 000 045 |
Класс источник |
|
10 000 046 |
Связь с владельцем |
|
10 000 047 |
Обратная связь |
|
10 000 007 |
Значения |
|
10 000 000 |
||
10 000 008 |
Константы |
|
10 000 000 |
||
10 000 009 |
Функции |
|
10 000 000 |
||
10 000 010 |
Действия |
|
10 000 000 |
||
10 000 048 |
Обозначение |
|
10 000 050 |
Тип |
|
10 000 051 |
Массив |
|
10 000 052 |
Измерения |
Основные решения Framework¶
создать интерфейс пользователя с гибкими возможностями для доступа к хранилищу информации;
получать наглядное представление связанных данных;
создать с помощью технологии no code хранилище данных необходимой модели с быстрым доступом к нему по API;
получать данные по API используя различные фильтры, условия, сортировки, ограничения;
осуществлять поиск данных;
создавать приложения на основе данных и автоматически изменять формы и структуру приложения, меняя структуру данных.
Основная идея работы с сервисом - своя уникальная гибкая модель данных позволяющая обеспечить все функциональные требования с возможностью модернизации с минимальными затратами в процессе эксплуатации.
Процедуры изменения и контроля базы данных¶
API¶
Метод |
URL |
Функция |
Описание |
|---|---|---|---|
GET |
/api/[id] |
api_get_object |
Получить объект по id |
DELETE |
/api/[id] |
api_delete_object |
Удалить объект по id |
PUT |
/api/ |
api_put_object |
Обновить/создать объект. Если нет ID - создать объект, owner_id - класс, содержащий объект |
POST |
/api/ |
api_save_objects |
Создать объект(ы) |
GET |
/api/ |
api_get_method_list |
Список методов |
GET |
/api/default/{class} |
api_get_object_default |
Получить объект по-умолчанию |
GET |
/api/list/{class} |
api_get_list |
Получить объекты, возможно добавить услови |
DELETE |
/api/list/{class} |
api_delete_list |
Удалить объекты по условию |
GET |
/api/json/[id]/{linked} |
api_get_json |
Получить связанные объекты |
GET |
/api/export/class/{class} |
api_export_class |
Экспорт структуры класса |
GET |
/api/load |
api_load_objects |
Загрузить объекты |
GET |
/api/delete |
api_delete_objects |
Удалить по URL |
DELETE |
/api/delete |
api_delete_objects_body |
Удалить в теле |
GET |
/api/service/reinit |
api_reinit_database |
Очистить базу данных и загрузить только ядро |
GET |
/api/delete |
api_delete_objects |
Удалить по URL |
GET |
/api/inherits/{classes} |
api_inherits |
Унаследовать класс |
GET |
/api/special/user_journal_events/{user} |
api_special_user_journal_events |
Журналы для пользователей |
GET |
/api/special/user_journal_events/{journal}/{user} |
api_special_user_journal_events_filter |
Журналы для пользователей с фильтром |
Фильтры¶
PromUC Framework обладает возможностью гибкой фильтрации и сортировки данных, позволяя в запросах передавать необходимые условия и делать поиск данных по сложному критерию
Методы фильтрации по условию: filter - ключевое слово, которое означает, что дальше будут условия фильтрации field (свойство), value (значение)
filter[field]=value «Фильтрация по условию»
filter[field]=value&filter[field]=value «Фильтрация по нескольким условиям»
Методы фильтрации по выражению: - filter ключевое слово, которое означает, что дальше будут условия фильтрации - field (свойство), value (значение)
filter[field]=[«>»,value] «Фильтрация по выражению больше»
filter[field]=[«<»,value] «Фильтрация по выражению меньше»
filter[field]=[«!=»,value] «Фильтрация по выражению не равно»
filter[field]=[«<>»,value] «Фильтрация по выражению не равно»
filter[field]=[«>=»,value] «Фильтрация по больше или равно»
filter[field]=[«<=»,value] «Фильтрация по меньше или равно»
filter[field]=[«~»,value] «Фильтрация по выражению содержит»
Если тип фильтруемого поля ссылется на внутренний тип bool, то фильтр будет выглядеть так:
filter[field]=value
Если тип фильтруемого поля ссылается на внутренний тип text, то тогда следует экранировать value двойными кавычками «
filter[field]=[«~»,»value»] filter[field]=[«<>»,»value»] filter[field]=[«!=»,»value»]
Методы сортировки: - order ключевое слово, которое означает, что дальше будут условия сортировки - id, name (свойство) для сортировки по нескольким свойствам - class_id- (свойство) для обратной сортировки
order=id «Сортировка по ID»
order=name,class_id- «Сортировка сначала по name, а затем обратная по class_id»
Метод ограничения вывода: - limit лимит выводимых объектов по результату поиска. - offset смещение объектов (пропуск с первого найденного)
limit=100 «Ограничить вывод 100 объектами»
offset=1000 «Получить объекты с смещением на 1000 объектов»
Можно совмещать различные условия, выражения, сортировки.
Например:
* /api/list/{class}?filter[fieldName1]=fieldValue1&filter[fieldName2]=fieldValue2&offset=1000&limit=100
Удаление объектов¶
Для удаления объектов используйте API описанный в разделе «API». При удалении объекта, у которого есть наследники, его наследники тоже будут удалены. Удаление данных возможно как по условию так и с использованием фильтров.
Пример метода «Удаление по значению»
/api/delete/{mnemo}
Пример метода «Удаление используя фильтры»
/api/delete/{class}?filter[id]=20000243
Порядок и средства восстановления базы данных¶
Модель данных может быть сохранена с учетом версионности в формате YAML и использована на других проектах. Системную и Пользовательскую модель рекомендуется сохранять в отдельных файлах конфигурации.