Bronze слой
Слой Bronze содержит две отдельные схемы данных, каждая из которых обслуживает разные аспекты платформы телематики и бизнес-аналитики:
raw_business_data - содержащие таблицы, атрибуты и значения, связанные с бизнес-информацией, такими как транспортные средства, сотрудники, геозоны, добавленные пользователями и т.д.
raw_telematics_data - содержащие таблицы, атрибуты и значения, связанные с телематическими данными, передаваемыми от устройств под наблюдением, такими как местоположения, входы, выходы и события.
Каждая схема оптимизирована для своей конкретной области данных и шаблонов доступа, обеспечивая всестороннее покрытие потребностей в операционном, телематическом и управлении активами.
raw_business_data структура
raw_business_data структураЭта схема содержит более 40 тщательно отобранных таблиц, чтобы охватить различные бизнес-аспекты и сценарии использования. Эти таблицы представляют ваши основные бизнес-сущности, организационную структуру и операционные данные.
Ниже приведены детали схемы raw business data.
Частота обновления
Данные в этой схеме синхронизируются с основной БД. Обновления происходят инкрементально по мере изменений в исходной базе данных MySQL, как правило, с задержкой менее 5 минут от момента изменения в источнике.
description_parameters
description_parametersСистема включает справочные данные для стандартизации значений по всей базе данных:
Определения типов
Стандартные типы сущностей
vehicle_type: car, truck, bus
Коды статусов
Значения статусов задач и системы
tasks_status: unassigned, assigned, done
Определения единиц
Единицы измерения для датчиков
units_type: liter, gallon, celsius
Классификации сущностей
Категории бизнес-сущностей
entities_type: place, task, customer
Ключевые таблицы по категориям
Таблицы в raw_business_data схеме организованы по функциональным категориям для облегчения навигации. В таблице ниже приведено краткое описание ключевых таблиц по их бизнес-назначению:
Основные бизнес-сущности
Отслеживание и мониторинг
Управление активами
Местоположение и маршрутизация
Управление задачами и рабочими процессами
Правила и автоматизация
Статусы и категоризация
Группы и иерархия
Пользовательские поля и сущности
Историческое отслеживание
Справочные и справочные данные
raw_telematics_data структура
raw_telematics_data структураСхема raw_telematics_data содержит три основных типа таблиц, которые работают вместе, чтобы предоставлять комплексные данные об устройстве.
Ниже приведены подробности схемы необработанных телематических данных.
Ключевые таблицы по категориям
Каждая таблица выполняет определенную функцию в фиксации различных аспектов информации об устройстве:
Данные в этой схеме поступают напрямую от устройств с минимальной задержкой (обычно в секундах). Схема оптимизирована для временных рядов с использованием TimescaleDB для эффективного хранения и выборки.
Дополнительная информация
Проверка данных
База данных обеспечивает целостность данных посредством нескольких механизмов:
CONSTRAINT CHECK проверяют, что значения находятся в допустимых пределах
Внешние ключи обеспечивают согласованность связей между таблицами
Ограничения NOT NULL гарантируют, что обязательные поля всегда имеют значения
ЗНАЧЕНИЯ ПО УМОЛЧАНИЮ обеспечивают резервный вариант, когда данные явно не предоставлены
Оптимизация запросов
Таблицы организованы с использованием специальных стратегий индексирования:
Все таблицы включают индексы, основанные на времени по
record_added_atСтолбцы внешних ключей имеют выделенные индексы для повышения производительности соединений
Часто используемые сочетания колонок имеют составные индексы
TimescaleDB предоставляет специализированные индексы для запросов по временным рядам
repo структура данных
repo структура данныхЭта схема в настоящее время находится в разработке. Если вы заинтересованы в раннем доступе или у вас есть вопросы по этой функциональности, пожалуйста, свяжитесь с [email protected].
Схема repo схема предоставляет всеобъемлющую структуру для управления организационными структурами, активами, устройствами и их отношениями в мультиарендных средах. Построенная на PostgreSQL 14+ с расширением ltree, схема поддерживает иерархические организации, определение пользовательских полей для любых типов сущностей, контроль доступа на основе ролей с ограничениями на уровне объектов и полные журналы аудита с отслеживанием изменений на уровне полей. Все сущности могут быть расширены без изменений схемы, локализованы для международных развертываний и связаны через гибкие полиморфные отношения.
Схема решает сложные сценарии управления данными, включая иерархии активов автопарка на разных уровнях организации, мультиарендные SaaS-платформы, требующие изоляции данных, операции, ориентированные на соответствие требованиям с подробными аудит-требованиями, и системы, которым требуются динамические модели данных, адаптируемые через пользовательские поля вместо миграций базы данных.
Ниже найдите repo подробности схемы.
Частота обновления
Данные в repo схеме синхронизируются в режиме реального времени с исходными системами. Обновления происходят немедленно по мере внесения изменений, при этом журналы аудита фиксируют все модификации для соответствия требованиям и исторического анализа.
ci_base
ci_baseСхема repo схема использует шаблон Single Table Inheritance для всех справочных данных через ci_base таблицу:
Схема repo схема использует Single Table Inheritance шаблон для всех справочных данных через ci_base таблицу. Такой дизайн объединяет системные словари, классификации и элементы справочника, определяемые пользователем, в единую структуру, обеспечивая согласованность и гибкость во всей схеме.
Архитектура:
Схема ci_base таблица служит основой для всех справочных данных, используя дискриминатор поле для идентификации конкретного типа справочника. У каждого типа справочника есть соответствующая таблица (например ci_device_type, ci_asset_type), которая разделяет тот же id что и ci_base, создавая типобезопасное отношение наследования.
Как бизнес-сущности подключаются к ci_base:
Все бизнес-сущности в repo схеме ссылаются на ci_base подтипы для определения своей классификации и поведения:
organization→ ссылается наci_organization_type(который наследует отci_entity_type→ci_base)user→ ссылается наci_user_type(который наследует отci_entity_type→ci_base)device→ ссылается наci_device_typeиci_device_status(оба наследуют отci_base)asset→ ссылается наci_asset_type(который наследует отci_entity_type→ci_base)inventory→ ссылается наci_inventory_type(который наследует отci_entity_type→ci_base)asset_group→ ссылается наci_asset_group_type(который наследует отci_entity_type→ci_base)
Категории типов справочников:
Конфигурация системы
ci_module, ci_country, ci_role
Определяют модули системы, географические справочники и роли пользователей
Определения типов сущностей
ci_entity_type, ci_device_type, ci_asset_type, ci_inventory_type, ci_organization_type, ci_user_type, ci_asset_group_type
Классифицируют все бизнес-сущности по типам
Статусы и классификация
ci_device_status, ci_asset_type_category
Отслеживают состояния сущностей и группируют типы в категории
Контроль доступа
ci_permission_scope
Определяют, какие разрешения могут быть предоставлены (связано с ci_module и ci_entity_type)
Связи
ci_device_relation_type
Определяют типы отношений между устройствами (master-slave, backup и т. д.)
Категоризация
ci_tag, ci_catalog_category
Обеспечивают гибкую систему тегирования и организацию каталога
Ключевые таблицы по категориям
Таблицы в repo схема организована по функциональным категориям. Описания ниже суммируют наиболее важные таблицы по их бизнес-целям.
Связи данных
Схема repo схема реализует сложные шаблоны связей для гибкого моделирования данных:
Иерархические структуры
Организации используют пути ltree для эффективных древовидных запросов
Элементы справочника (
ci_base) поддерживают необязательные иерархииАвтоматическое поддержание путей с помощью триггеров базы данных
Шаблоны наследования
Наследование таблиц:
customizable_entity→ бизнес-сущности (organization,user,device,asset,inventory,asset_group)Наследование ID:
ci_base→ таблицы типов справочниковРазличение типов через
entity_type_idидискриминаторполя
Полиморфные связи
Некоторые таблицы используют полиморфные ссылки без внешних ключей для максимальной гибкости:
acl_role_permission.target_entity_id→ любойcustomizable_entityacl_user_scope.target_entity_id→ любойcustomizable_entityentity_tag.entity_id→ любойcustomizable_entity
Эти связи проверяются на уровне приложения.
Дополнительная информация
Проверка данных
Схема repo схема обеспечивает целостность данных с помощью нескольких механизмов:
Ограничения базы данных
UNIQUE-ограничения с поддержкой мягкого удаления (частичные индексы WHERE
deleted_atIS NULL)CHECK-ограничения (например,
device_relationобеспечиваетmaster_id≠slave_id)NOT NULL-ограничения для обязательных полей
ЗНАЧЕНИЯ ПО УМОЛЧАНИЮ для временных меток и булевых флагов
Проверка на уровне приложения
Проверка типа сущности для полиморфных ссылок
Проверка каталога для ссылок на настраиваемые поля
Проверка типов настраиваемых полей
Управление массивами для полей с несколькими значениями
Оптимизация запросов
Таблицы организованы с использованием специальных стратегий индексирования:
Стандартные индексы:
У всех внешних ключей имеются соответствующие индексы
Временные индексы на
created_at,updated_at,deleted_atСоставные индексы для часто объединяемых столбцов
Специализированные индексы:
GiST-индексы на путях ltree для иерархических запросов
Частичные уникальные индексы с поддержкой мягкого удаления
Индексы значений настраиваемых полей для фильтрации и сортировки
Индексы событий аудита по времени + сущности для эффективных поисков
Соображения по производительности:
Рекомендуется пул соединений (PgBouncer)
Регулярное выполнение VACUUM для больших таблиц
Возможное будущее разделение по партициям для
deviceтаблицы поorganization_idМатериализованные представления для сложных вычислений контроля доступа
Последнее обновление
Это было полезно?