Бронзовый слой
Слой Bronze содержит две отдельные схемы данных, каждая из которых обслуживает различные аспекты платформы телематики и бизнес-аналитики:
raw_business_data - содержит таблицы, атрибуты и значения, связанные с бизнес-информацией, такими как транспортные средства, сотрудники, геозоны, добавленные пользователями, и т.д.
raw_telematics_data - содержит таблицы, атрибуты и значения, связанные с телематическими данными, передаваемыми от контролируемых устройств, такими как местоположения, входы, выходы и события.
Каждая схема оптимизирована для своей предметной области данных и шаблонов доступа, обеспечивая всестороннее покрытие оперативных, телематических и задач управления активами.
raw_business_data structure
raw_business_data structureЭта схема содержит более 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 схеме организованы по функциональным категориям для удобства навигации. В таблице ниже приведено краткое описание ключевых таблиц по их бизнес-назначению:
Обзор схемы базы данных
Организационная структура
users
departments
employees
groups
Учетные записи пользователей с информацией профиля
Отделы с геолокационными данными
Сведения о сотрудниках и водителях
Группы организации трекеров
Объекты и устройства
devices
models
objects
vehicles
sensor_description
Физические трекинговые устройства
Спецификации моделей устройств
Мониторируемые объекты
Данные и спецификации транспортных средств
Детали конфигурации датчиков
Места и зоны
places
zones
garages
tags
Точки интереса с геолокацией
Области мониторинга с геозаборами
Места обслуживания транспортных средств
Организационные метки
Операционные данные
tasks
forms
checkins
events
statuses
vehicle_service_tasks
Назначения и отслеживание задач
Формы для сбора данных
Записи посещений по местоположению
События системы и уведомления
Определения статусов
Записи обслуживания транспортных средств
raw_telematics_data structure
raw_telematics_data structureСхема raw_telematics_data содержит три основных типа таблиц, которые работают совместно, обеспечивая полный набор данных об устройствах.
Ниже приведены детали схемы необработанных телематических данных.
Ключевые таблицы по категориям
Каждая таблица выполняет конкретную функцию для захвата разных аспектов информации об устройстве:
tracking_data_core
tracking_data_coreНазначение: Основные данные о местоположении и движении
Ключевые поля
device_id, device_time, platform_time, latitude, longitude, speed, altitude, satellites, hdop, event_id
Индексация
Оптимизировано с индексом на (device_id, device_time)
Особые замечания
Данные местоположения (широта и долгота) используют целочисленный формат с точностью 10⁷ для оптимальной производительности в TimescaleDB Скорость также хранится в целочисленном формате, поэтому её необходимо делить на 100
inputs
inputsНазначение: Показания датчиков с устройств
Ключевые поля
input_id, device_id, device_time, sensor_name, value
Содержание
Аналоговые показания (уровень топлива, температура, напряжение), вычисляемые значения (обороты двигателя)
Связи
FROM raw_telematics_data.inputs AS i
JOIN raw_business_data.sensor_description AS sd
ON i.device_id = sd.device_id AND i.sensor_name = sd.input_label
JOIN raw_telematics_data.tacking_data_core AS tdc
ON i.device_id = tdc.device_id AND i.device_time = tdc.device_timestates
statesНазначение: Индикаторы состояния устройства и рабочие режимы
Ключевые поля
state_id, device_id, device_time, state_name, value
Содержание
Индикаторы режимов работы (работа, простои, выкл.), состояния компонентов (зажигание, двери)
Формат значения
Булевы значения (1/0) или специфические коды статусов
Данные в этой схеме поступают напрямую от устройств с минимальной задержкой (обычно секунды). Схема оптимизирована для временных рядов с использованием TimescaleDB для эффективного хранения и выборки.
Дополнительная информация
Валидация данных
База данных обеспечивает целостность данных посредством нескольких механизмов:
Ограничения CHECK проверяют, что значения находятся в допустимых границах
Внешние ключи обеспечивают согласованность связей между таблицами
Ограничения NOT NULL гарантируют, что обязательные поля всегда содержат значения
Значения по умолчанию DEFAULT обеспечивают запасной вариант, когда данные явно не предоставлены
Оптимизация запросов
Таблицы организованы со специфическими стратегиями индексации:
Во всех таблицах включены временные индексы на
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, резервирование и т.д.)
Категоризация
ci_tag, ci_catalog_category
Обеспечивают гибкое тегирование и организацию каталога
Ключевые таблицы по категориям
Таблицы в repo схема организована в функциональные категории. Описания ниже суммируют наиболее важные таблицы по их бизнес-назначению.
organization
organizationНазначение: Иерархическое управление организациями
Ключевые поля
id, parent_id, path, organization_type_id, title_en, is_active, deleted_at
Индексация
GiST-индекс на path для иерархических запросов, индексы на parent_id и organization_type_id
Особые замечания
Использует ltree для многоуровневых иерархий, наследуется от customizable_entity для поддержки пользовательских полей
user
userНазначение: Учетные записи пользователей и аутентификация
Ключевые поля
id, organization_id, user_type_id, identity_provider, identity_provider_id, full_name, is_active
Индексация
Уникальный индекс на (organization_id, identity_provider, identity_provider_id)
Особые замечания
Интеграция внешних поставщиков идентификации (Keycloak, Auth0, Okta), наследуется от customizable_entity
device
deviceНазначение: Физические трекинговые устройства
Ключевые поля
id, organization_id, device_type_id, status_id, hw_id, label
Индексация
Индексы на organization_id, device_type_id, status_id, hw_id
Особые замечания
Аппаратный идентификатор для отслеживания устройства, наследуется от customizable_entity для пользовательских полей
asset
assetНазначение: Физические или виртуальные активы
Ключевые поля
id, organization_id, asset_type_id, label, description
Индексация
Индексы на organization_id и asset_type_id
Особые замечания
Наследуется от customizable_entity, связаны с устройствами через device_asset_link
inventory
inventoryНазначение: Инвентарные и складские записи
Ключевые поля
id, organization_id, inventory_type_id, code
Индексация
Уникальный индекс на (organization_id, code)
Особые замечания
Уникальные коды в рамках организации, связаны с устройствами через device_inventory_link
asset_group
asset_groupНазначение: Группировка активов с историческим отслеживанием
Ключевые поля
id, organization_id, group_type_id, title_en, description
Связи
FROM repo.asset_group AS ag JOIN repo.asset_group_item AS agi ON agi.group_id = ag.id JOIN repo.asset AS a ON a.id = agi.asset_id WHERE agi.detached_at IS NULL
Особые замечания
Членство, основанное на времени, через asset_group_item, запросите текущих членов с помощью WHERE detached_at IS NULL
custom_field_def
custom_field_defНазначение: Определения и метаданные пользовательских полей
Ключевые поля
id, organization_id, owner_entity_type_id, code, field_type, is_multi, is_required
Содержание
Типы полей включают text, number, boolean, date, datetime, entity_ref, catalog_item_ref
Особые замечания
Обеспечивает гибкие пользовательские поля для любого типа сущности, значения хранятся в типоспецифичных custom_field_value_* таблицах
acl_role_permission
acl_role_permissionНазначение: Управление разрешениями на основе ролей
Ключевые поля
id, role_id, permission_scope_id, target_entity_id, actions
Содержание
Битовая маска действий (READ=1, UPDATE=2, DELETE=4, CREATE=8), разрешения могут быть специфичны для цели или для всего типа сущности
Связи
FROM repo.user_role AS ur JOIN repo.acl_role_permission AS rp ON rp.role_id = ur.role_id WHERE ur.user_id = $user_id
Особые замечания
Работает с user_role и acl_user_scope для определения окончательных прав пользователя
audit_event
audit_eventНазначение: Единый журнал аудита для всех изменений в системе
Ключевые поля
id, event_category, user_id, aggregate_type, aggregate_id, event_type, event_data, occurred_at
Индексация
Индексы на (user_id, occurred_at), (aggregate_type, aggregate_id, occurred_at), (event_category, occurred_at)
Особые замечания
Разделение по occurred_at (ежемесячно), две категории: auth (аутентификация) и domain (бизнес-события), хранит дельты изменений на уровне полей в event_data JSONB
Связи данных
Схема 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 для обязательных полей
ЗНАЧЕНИЯ DEFAULT для временных меток и булевых флагов
Проверки на уровне приложения
Проверка типа сущности для полиморфных ссылок
Проверка каталога для ссылок пользовательских полей
Проверка типа пользовательского поля
Управление массивами для полей с множественными значениями
Оптимизация запросов
Таблицы организованы со специфическими стратегиями индексации:
Стандартные индексы:
Все внешние ключи имеют выделенные индексы
Временные индексы по
created_at,updated_at,deleted_atСоставные индексы для часто объединяемых столбцов
Специализированные индексы:
GiST-индексы на путях ltree для иерархических запросов
Частичные уникальные индексы, поддерживающие мягкое удаление
Индексы значений пользовательских полей для фильтрации и сортировки
Индексы событий аудита по времени + сущности для эффективных поисков
Соображения по производительности:
Рекомендуется пула соединений (PgBouncer)
Регулярное обслуживание VACUUM для больших таблиц
Возможное будущее разбиение для
deviceтаблица поorganization_idМатериализованные представления для сложных вычислений контроля доступа
Последнее обновление
Это было полезно?