Любое программное приложение предполагает информационный обмен и оперирование данными, т.е. информация поступает в приложение извне, потом обрабатывается и хранится в нем, затем потребляется пользователями. Поэтому важно взвешенно подходить к подготовке структуры данных, по которой будет распределяться информация, исходя из бизнес-задачи, которую должно решить приложение.
Механизм таблиц и полей
Механизм таблиц и полей в платформе S1 позволяет управлять структурой приложения и ее моделью данных.
Таблицы
На низшем уровне, SimpleOne хранит данные и настройки бизнес-логики в таблицах. Таблицы состоят из колонок и взаимосвязаны во многих отношениях.
Существует два набора таблиц: системные и функциональные таблицы. Системные таблицы используются для реализации бизнес-логики. Они хранят внутренние механизмы, разработанные поверх платформы, и защищены от структурных изменений, что позволяет предотвратить сбои системы и нарушения бизнес-логики. Функциональные таблицы предназначены для хранения модели данных, используемых при реализации бизнес-логики.
Атрибуты таблиц
Атрибуты таблиц – системные свойства, которые позволяют настраивать таблицы и определять их связь с другими таблицами
Нумерация записей
Нумерация записей – специальный атрибут таблицы, который позволяет определить формат номера создаваемых в этой таблице записей.
Модель данных
Несмотря на то, что данные и информация являются похожими по смыслу понятиями, между ними есть значительное различие.
Информация это точные и систематизированные данные. Другими словами, прежде чем данные станут информацией, они должны приобрести структурированный вид.
База данных - это упорядоченный набор структурированной информации или данных, которые обычно хранятся в электронном виде в компьютерной системе.
Проще говоря - база данных это хранилище, содержащее информацию. Например, меню в ресторане. Меню - это база, перечисленные в нём цены и блюда - это данные.
Для того чтобы управлять и работать с данными используют системы управлениями базы данных или сокращенно СУБД. В платформе SimpleOne используется реляционная СУБД - PostgreSQL. СУБД позволяет описать взаимосвязи между данными, определить методы работы с этими данными, определить, как одни данные соотносятся с другими. Всё перечисленное называется логической моделью данных.
Существуют различные модели данных. Например, иерархическая модель данных в Windows, где при помощи папок и подпапок организуется вложенная структура. В реляционных базах данных используется реляционная модель данных. Реляционная модель данных это логическая модель данных в основе которой лежат отношения и операции над этими отношениями. Реляционная модель берет свое название от английского relation (отношение). Отношения по сути это таблицы, в которых лежат (хранятся) данные.
Для данных в таблицах определен ряд операций:
добавление данных;
удаление данных;
чтение данных;
изменение данных.
В академической теории используют следующие определения:
отношение - это таблица
атрибут – это столбец таблицы
кортеж - это строка таблицы
первичный ключ - это уникальный идентификатор
При работе с данными на экземпляре, вместо термина отношение мы будем использовать термин таблицы или справочники. Атрибуты таблиц называем столбцами, строки таблиц называем записями в таблице. Первичные ключи в терминологии SimpleOne называются идентификаторами или ID.
Отношение многие-ко-многим
В модели данных S1 возможно построение отношений "многие-ко-многим", которые позволяют определить связи между записями любых двух таблиц, указав тип связи, отличный от "один-к-одному".
Например, таблицы Пользователь и Группа могут содержать множество записей пользователей и групп соответственно. Пользователь может состоять более чем в одной группе, а группа может включать множество пользователей. В таком случае, эти две таблицы должны быть связаны, как показано ниже:
Таблица "многие-ко-многим" – это таблица, которая описывает, как две таблицы связаны друг с другом. Вы можете посмотреть типичный пример такой связи на изображении ниже:
Расширение структуры данных
S1 позволяет как использовать подготовленные структуры данных из коробки (например, таблица Задачи - Tasks), расширяя их модель данных, так и создавать новые полностью с нуля под свои нужды.
Расширять модель данных, можно как на уровне самой целевой таблицы, так и на уровне ее потомка. Важно понимать, что первом случае, обновленная модель данных (т.е. добавленные колонки) будут применяться ко всем дочерним таблицам, т.к. будут унаследованы.
Еще один способ расширения модели данных - это REM. Это когда не создаются новые таблицы и поля, а создаются атрибуты данных применимые выборочно к определенным записям таблицы.
Кроме расширения вручную в системе возможно автоматическое создание таблиц и колонок при помощи скриптов.
Добавление колонок
Самый простой способ расширить структуру данных – добавление новых колонок в существующие таблицы. Он также является наименее гибким. Не подходит для существующих структур данных, т.к. образуется большое количество незаполненных полей. Также вновь создаваемые колонки наследуются, что может нарушить логическую стройность дочерних таблиц.
Наследование
Наследование позволяет создавать дочерние структуры данных, наследующие все атрибуты родительской структуры, и дополняющие их своими собственными атрибутами. Это позволяет отказаться от большого количества дублирующихся колонок и выстроить иерархическую структуру объектов, в которой каждый следующий дочерний элемент представляет собой более специализированное подмножество. Наследование может быть многоуровневым. Наследуемые значения могут переназначаться на уровне той или иной дочерней таблицы. Как работает переназначение с пропуском уровней?
При использовании наследования необходимо учитывать, что многие механизмы имеют опцию срабатывания и в рамках дочерних сущностей.
Расширенная модель записи
Механизм наследования работает хорошо при наличии небольшого количества дочерних таблиц и большого количества общих атрибутов между ними. Однако при увеличении числа дочерних таблиц и уменьшения числа общих атрибутов, управление данной моделью данных становится сложным. У модели данных с большой, сложной структурой наследования есть недостатки:
Для хранения записей требуется больше места.
Снижается скорость выполнения скриптов.
Становится сложнее настраивать функции, связанные с определенным справочником, такие как импорт данных, настройка форм представления и т.д.
Примером такой таблицы является каталог запросов: он состоит из родительской таблицы для каталога и записей в таблице для каждого шаблона запроса с определенными атрибутами.
При применении модели расширения записи к той или иной записи, для нее создается вспомогательный набор записей, в котором хранится информация по значениям конкретных атрибутов. Таким образом у записи есть атрибуты, унаследованные от таблицы и, дополнительно, атрибуты, которые берутся из модели расширения.
REM-атрибуты позволяют обойти ограничения модели наследования. Позволяет добавлять к записям атрибуты, которые не будут наследоваться дочерними таблицами. Без REM атрибутов пришлось бы создавать большое количество уровней наследования, на которых родитель отличается от потомка наличием всего одного поля. Кроме того, REM-атрибуты могут объединяться в рем-модели, позволяющие осуществлять категоризацию объектов из одной таблицы. Примером такого использования является каталог услуг.
Функциональность REM позволяет расширять атрибутную модель таблицы. До появления REM, расширение модели было возможно только через создание колонок Column (sys_db_column). При таком подходе невозможно добавить колонку в родительской таблице без унаследования колонки дочерними таблицами.
Помимо основных свойств (атрибутов) записи к ней может быть привязана расширенная модель записи REM. Данная модель содержит дополнительные атрибуты, которые добавляются к записи в таблице. Например, есть запись запроса на обслуживание ЗНО в таблице ITSM Request [itsm_request]. Таблица Request является дочерней от таблицы ITSM Task [itsm_task]. Таблица ITSM Task наследуется от таблицы Task:
Поэтому для запроса определены основные поля задачи Task (number, caller, subject, state, assigned_user, service) и дополнительные поля ITSM сущности, такие как closure_code и поля запроса Request - request_template, master_request. Помимо этих полей, к запросу запроса может быть прикреплена модель "Выдача оборудования" с атрибутами: device_id, items, delivery:
Настройка REM модели для таблицы Request имеет вид:
Создание структуры каталога услуг на базе REM
Каталоги услуг позволяют создавать упорядоченную структуру внутренних и внешних услуг, предоставляемых потребителям. Посредством Каталога услуг пользователи могут получать доступ к услугам в любое время и с любого устройства. Конечными формами каталога являются формы типовых запросов. Каталог позволяет типизировать обращения пользователей для обеспечения высокого и повторяемого качества услуг.
В платформе SimpleOne представлено две версии каталогов, принципиальным отличием версий каталогов является подход к организации моделей запросов:
Каталог услуг
Первая версия каталога (страница портала / catalog) не использует функциональность REM моделей. Настройка моделей запросов в этой версии выполняется посредством записей Request Templates. Особенностью настройки является необходимость создавать таблицу для каждой модели. Версия каталога не поддерживает настройку доступа к элементам каталога (категориям и формам) с использованием пользовательских критериев, а также не позволяет настроить повторную классификацию типовых запросов.
В настоящее время данный подход к настройке каталога считается устаревшим и не рекомендован для использования.
REM Каталог услуг
Вторая версия каталога (страница портала /sc) основана на расширенной модели записи REM. Настройка типовых запросов в этой версии выполняется посредством записей Request Models.
Преимущества использования REM каталога:
для всех моделей запросов можно использовать одну и ту же таблицу, что позволяет настроить повторную классификацию типовых запросов в рамках первоначального запроса.
возможно настраивать общие наборы атрибутов (REM коллекции), которые будут использоваться в нескольких моделях.
настройка доступа к элементам каталога возможно с использованием Пользовательских критериев.
При настройке каталога услуг возникает необходимость настраивать формы запросов с множеством специфичных атрибутов. Для решения подобной задачи мы рекомендуем использовать функциональность REM.
Особенности работы с REM атрибутами
В текущей версии платформы REM атрибуты недоступны для построения условия через Condition Builder.
Для получения значения атрибута в скрипте необходимо использовать dotWalking через свойство rem_attr. Например, значение атрибута Bot Name будет доступно через обращение: current.rem_attr.bot_name , где bot_name – Column Name атрибута.
Маппинг значения атрибута в колонку записи через Map to Column выполняется только при создании записи.
Маппинг через Map to Column возможен только при совпадении типа атрибута и типа колонки записи.
Настройка доступа к элементам REM каталога
Администратор системы имеет возможность настраивать доступ к элементам каталога (категориям и моделям запросов) с использованием пользовательских критериев. Для настройки доступа к категориям и моделям используются соответственно записи в таблицах Category User Criteria и Request Model User Criteria. Списки этих таблиц представлены в категории навигатора Request Model Catalog.
При переходе пользователя в каталог услуг выполняется проверка на соответствие пользователя критериям категории и критериям модели по схеме:
Рекомендации по настройке REM каталога услуг
Перед созданием моделей каталога услуг Request Models [sys_rmc_model] необходимо:
выполнить категоризацию запросов;
создать записи услуг Service [sys_cmdb_ci_service];
определить общие наборы атрибутов.
После можно приступать к созданию коллекций и наполнению их атрибутами. Не стоит создавать коллекции с большим числом атрибутов.
Это может помешать использовать коллекцию в нескольких моделях и потребует написания дополнительных клиентских скриптов для скрытия ненужных атрибутов коллекции
Общие атрибуты, такие как Caller, Description, Contact Type, Urgency лучше добавлять в модели в виде отдельных коллекций с одним атрибутом (вытекает из п.2).
Пример добавления такой коллекции изображен на схеме ниже (коллекция Collection 2 добавляется в модель Model 3).
При настройке пользовательских критериев для определения доступа к элементам каталога, нужно предоставлять доступ для всех агентов первой линии. В противном случае агенты не смогут выполнять классификацию пользовательских вопросов User Query в запросы каталога.
Коллекции REM-атрибутов
REM атрибуты могут быть объединены в коллекции, использующие отношение многие-ко-многим.
Конфигурационные пакеты
Все способы изменения структуры вне зависимости от способа данных собираются в конфигурационные пакеты.
Система контроля версий SimpleOne (Version Control System или VCS) – позволяет отслеживать изменения конфигурации экземпляра, выполнять откат (восстановление) предыдущих версий конфигурации и производить сборку пакетов для переноса (импорта) конфигурации на другие экземпляры SimpleOne.
В контексте контроля версий выделяют два класса таблиц:
Транзакционные
Конфигурационные
Принадлежность таблицы к тому или иному классу определяется типом хранимых данных и влиянием данных на конфигурацию экземпляра.
Основные типы данных:
Транзакционные данные – данные, которые образовались в результате выполнения предприятием каких-либо бизнес-транзакций. Например, для сервисного подразделения компании это предоставление услуг, регистрация и обработка обращений, планирование и согласование работ, уведомления конечного пользователя и исполнителя и т.п. Транзакционные системы широко используют мастер-данные при выполнении транзакций. Пример транзакционных таблиц: task, sys_approval, sys_email.
Исторические данные – данные, которые включают в себя исторические транзакционные и мастер-данные. Используются для решения различных аналитических задач и принятия управленческих решений. Пример таблиц исторических данных: sys_history, sys_log, sys_activity_feed_item.
Мастер-данные – базовые данные, которые определяют бизнес-сущности, с которыми имеет дело предприятие. К таким бизнес-сущностям (в зависимости от отраслевой направленности предприятия) относятся клиенты, поставщики, продукция, услуги, договоры, счета, пациенты, граждане и т.п. Кроме информации непосредственно о той или иной мастер-сущности, в мастер-данные входят взаимосвязи между этими сущностями и иерархии. Например, с точки зрения поиска дополнительных возможностей продаж, может быть очень важно выявлять явные и неявные взаимосвязи между физическими лицами. Пример мастер-данных - таблица org_company, user, content_item.
Метаданные – это данные о данных. Они нужны для понимания и определения того, какими данными оперирует предприятие. Метаданные определяют структуры, типы данных, доступы к ним и т.д. Пример таблиц метаданных: sys_db_table, sys_db_column, sys_security_acl.
Референс-данные – данные, которые определяют значения конкретных сущностей, используемых при выполнении операций в рамках всего предприятия. К таким сущностям чаще всего относятся: часовые пояса, страны, языки и т.д. Референс-данные относительно редко меняются. Пример таблиц референс-данных: sys_timezome, cmn_country, sys_language.
При установке платформы по умолчанию на экземпляре создается приложение Simple. Приложение Simple предназначено для хранения конфигурации системы. Например, настройки системных таблиц и их колонок, связанные переводы, настройки представлений форм и списков и т.д.
Принадлежность записи конфигурации к приложению определяется через системную колонку Application [application_id]. Значение в колонке Application указывается автоматически при создании версионируемой записи, в соответствии с текущим приложением пользователя и не может быть изменено после создания.
Записи конфигурации одного приложения не могут быть изменены в рамках другого приложения. Если пользователь с ролью admin находится на записи конфигурации, которую он может редактировать и текущее приложение пользователя не совпадает с приложением конфигурации, пользователь увидит сообщение вида:
Кроме приложения Simple, устанавливаемого на экземпляр по умолчанию, на экземпляр могут быть установлены коробочные бизнес приложения. При выполнении настройки экземпляра разработчики дополняют конфигурацию коробочных решений. В начале разработки при выборе приложения пакета необходимо обращать внимание на приложение таблиц, для которых будет разрабатываться бизнес логика. Например, Вам необходимо выполнить настройку бизнес-правил для таблицы инцидентов Incident [itsm_incident]. Таблица инцидентов поставляется в приложении ITSM, следовательно, создание бизнес правил для нее нужно выполнять в приложении ITSM, т.к. помимо настройки правил может потребоваться изменение коробочной конфигурации приложения ITSM.
Создание собственного приложения должно быть обосновано изолированность разрабатываемого модуля функциональности. Например, таблицы модуля будут наследоваться от коробочных таблиц, но большая часть бизнес логики будет переопределена через создание дополнительной конфигурации.
Если вы создадите собственное приложение для настройки коробочного приложения процесс разработки будет осложнен необходимостью постоянно менять приложение и собирать несколько локальных пакетов в нескольких приложениях. Как следствие, данные пакеты будет невозможно объединить, т.к. они будут связаны с разными приложениями.
Настройку SSO, LDAP, почтовых аккаунтов следует производить в приложении Simple, т.к. с большой вероятностью Вам понадобится настраивать связанные системные свойства, которые находятся в приложении Simple.
