Любое приложение, разрабатываемое на платформе SimpleOne, предполагает информационный обмен и оперирование данными, т.е. информация поступает в приложение извне, потом обрабатывается и хранится в нем, затем потребляется пользователями. Поэтому важно взвешенно подходить к подготовке структуры данных, по которой будет распределяться информация, исходя из бизнес-задачи, которую должно решить приложение.
Механизм таблиц и полей
Механизм таблиц и полей в платформе S1 позволяет управлять структурой приложения и ее моделью данных.
Таблицы
На низшем уровне, SimpleOne хранит данные и настройки бизнес-логики в таблицах. Таблицы состоят из колонок и взаимосвязаны во многих отношениях.
Существует два набора таблиц: системные и функциональные таблицы. Системные таблицы используются для реализации бизнес-логики. Они хранят внутренние механизмы, разработанные поверх платформы, и защищены от структурных изменений, что позволяет предотвратить сбои системы и нарушения бизнес-логики. Функциональные таблицы предназначены для хранения модели данных, используемых при реализации бизнес-логики.
Атрибуты таблиц
Атрибуты таблиц – системные свойства, которые позволяют настраивать таблицы и определять их связь с другими таблицами
Нумерация записей
Нумерация записей – специальный атрибут таблицы, который позволяет определить формат номера создаваемых в этой таблице записей.
Модель данных
Несмотря на то, что данные и информация являются похожими по смыслу понятиями, между ними есть значительное различие. Информация это точные и систематизированные данные. Другими словами, прежде чем данные станут информацией, они должны приобрести структурированный вид.
База данных - это упорядоченный набор структурированной информации или данных, которые обычно хранятся в электронном виде в компьютерной системе. Проще говоря - база данных это хранилище, содержащее информацию.
Для того чтобы управлять и работать с данными используют системы управлениями базы данных или сокращенно СУБД. В платформе SimpleOne используется реляционная СУБД - PostgreSQL. СУБД позволяет описать взаимосвязи между данными, определить методы работы с этими данными, определить, как одни данные соотносятся с другими. Всё перечисленное называется логической моделью данных.
Существуют различные модели данных. Например, иерархическая модель данных в Windows, где при помощи папок и подпапок организуется вложенная структура. В реляционных базах данных используется реляционная модель данных. Реляционная модель данных это логическая модель данных в основе которой лежат отношения и операции над этими отношениями. Реляционная модель берет свое название от английского relation (отношение). Отношения по сути это таблицы, в которых лежат (хранятся) данные.
Для данных в таблицах определен ряд операций:
- добавление
- удаление
- чтение
- изменение
В академической теории используют следующие определения:
отношение - это таблица
атрибут – это столбец таблицы
кортеж - это строка таблицы
первичный ключ - это уникальный идентификатор
При работе с данными на экземпляре, вместо термина отношение мы будем использовать термин таблицы или справочники. Атрибуты таблиц называем столбцами, строки таблиц называем записями в таблице. Первичные ключи в терминологии SimpleOne называются идентификаторами или ID.
Отношение "многие-ко-многим"
Распространенной ситуацией при построении модели данных является необходимость описывать сложные связи между записями любых двух таблиц, при котором одна из записей в одной таблице может быть соотнесена с несколькими записями в другой таблице, и наоброт. Например, таблицы Пользователь и Группа могут содержать множество записей пользователей и групп соответственно. Пользователь может состоять более чем в одной группе, а группа может включать множество пользователей. В таком случае, эти две таблицы должны быть связаны с использованием отношения "многие-ко-многим". В системе SimpleOne такие отношения представлены в виде специальных таблиц, описывающих, как записи в двух таблицах связаны друг с другом. Процесс создания таких таблиц описан в статье Отношение "многие-ко-многим".
Расширение модели данных
Кроме создания новых структур данных с нуля, система SimpleOne позволяет приспособить под нужды бизнес-решения заранее подготовленные структуры данных, поставляемые с коробочным решением. Для этого доступны несколько способов, каждый из которых имеет свою область применения, достоинства и недостатки.
Конфигурационные пакеты
Все способы изменения структуры вне зависимости от способа данных собираются в конфигурационные пакеты.
Система контроля версий 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.
