Capa Bronze
La capa Bronze contiene dos esquemas de datos distintos, cada uno que sirve a diferentes aspectos de la plataforma de telemática e inteligencia empresarial:
raw_business_data - que contiene tablas, atributos y valores relacionados con la información empresarial, como vehículos, empleados, geocercas añadidas por los usuarios, etc.
raw_telematics_data - que contiene tablas, atributos y valores relacionados con los datos telemáticos transmitidos desde dispositivos en monitoreo, como ubicaciones, entradas, salidas y eventos.
Cada esquema está optimizado para su dominio de datos específico y patrones de acceso, proporcionando una cobertura integral de las necesidades operativas, telemáticas y de gestión de activos.
raw_business_data estructura
raw_business_data estructuraEste esquema contiene más de 40 tablas cuidadosamente seleccionadas para cubrir varios aspectos empresariales y casos de uso. Estas tablas representan sus entidades comerciales principales, la estructura organizativa y los datos operativos.
Consulte los detalles del esquema de datos empresariales sin procesar a continuación.
Frecuencia de actualización
Los datos en este esquema se sincronizan con la base de datos principal. Las actualizaciones ocurren de forma incremental a medida que se producen cambios en la base de datos MySQL de origen, típicamente en menos de 5 minutos desde el cambio en la fuente.
description_parameters
description_parametersEl sistema incluye datos de referencia para estandarizar valores en toda la base de datos:
Definiciones de tipo
Tipos de entidad estándar
vehicle_type: car, truck, bus
Códigos de estado
Valores de estado de tareas y del sistema
tasks_status: unassigned, assigned, done
Definiciones de unidades
Unidades de medida para sensores
units_type: liter, gallon, celsius
Clasificaciones de entidad
Categorías de entidades comerciales
entities_type: place, task, customer
Tablas clave por categoría
Las tablas en el raw_business_data esquema están organizadas en categorías funcionales para facilitar la navegación. La tabla a continuación resume las tablas clave según su propósito empresarial:
Descripción general del esquema de base de datos
Estructura organizativa
users
departments
employees
groups
Cuentas de usuario con información de perfil
Departamentos con datos de geolocalización
Detalles de empleados y conductores
Grupos de organización de rastreadores
Objetos y dispositivos
devices
models
objects
vehicles
sensor_description
Dispositivos de seguimiento físicos
Especificaciones de modelos de dispositivos
Objetos monitorizados
Detalles y especificaciones de vehículos
Detalles de configuración de sensores
Lugares y zonas
places
zones
garages
tags
Puntos de interés con geolocalización
Áreas de monitoreo geovalladas
Ubicaciones de servicio de vehículos
Etiquetas organizativas
Datos operativos
tasks
forms
checkins
events
statuses
vehicle_service_tasks
Asignaciones de tareas y seguimiento
Formularios de recopilación de datos
Registros de asistencia basados en la ubicación
Eventos y notificaciones del sistema
Definiciones de estado
Registros de mantenimiento de vehículos
raw_telematics_data estructura
raw_telematics_data estructuraEl raw_telematics_data esquema contiene tres tipos de tablas principales que trabajan conjuntamente para proporcionar datos completos del dispositivo.
Encuentre los detalles del esquema de datos telemáticos sin procesar a continuación.
Tablas clave por categoría
Cada tabla tiene un propósito específico para capturar diferentes aspectos de la información del dispositivo:
tracking_data_core
tracking_data_corePropósito: Datos principales de ubicación y movimiento
Campos clave
device_id, device_time, platform_time, latitude, longitude, speed, altitude, satellites, hdop, event_id
Indexación
Optimizado con índice en (device_id, device_time)
Notas especiales
Los datos de ubicación (latitud y longitud) usan formato entero con precisión de 10⁷ para un rendimiento óptimo en TimescaleDB La velocidad también se almacena como entero, por lo que debe dividirse entre 100
inputs
inputsPropósito: Lecturas de sensores desde dispositivos
Campos clave
input_id, device_id, device_time, sensor_name, value
Contenido
Lecturas analógicas (nivel de combustible, temperatura, voltaje), valores calculados (RPM del motor)
Relaciones
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
statesPropósito: Indicadores de estado del dispositivo y modos operativos
Campos clave
state_id, device_id, device_time, state_name, value
Contenido
Indicadores de modo operativo (trabajando, inactivo, apagado), estados de componentes (encendido, puertas)
Formato de valor
Valores booleanos (1/0) o códigos de estado específicos
Los datos en este esquema se ingieren directamente desde los dispositivos, con latencia mínima (típicamente segundos). El esquema está optimizado para datos de series temporales usando TimescaleDB para almacenamiento y recuperación eficientes.
Información adicional
Validación de datos
La base de datos aplica integridad de datos mediante múltiples mecanismos:
Restricciones CHECK validar que los valores estén dentro de rangos aceptables
Claves externas asegurar que las relaciones entre tablas permanezcan consistentes
Restricciones NOT NULL garantizar que los campos obligatorios siempre tengan valores
Valores DEFAULT proporcionar valores por defecto cuando los datos no se suministran explícitamente
Optimización de consultas
Las tablas se organizan con estrategias de indexación específicas:
Todas las tablas incluyen índices basados en el tiempo en
record_added_atLas columnas de claves externas tienen índices dedicados para el rendimiento de joins
Las combinaciones de columnas de uso frecuente tienen índices compuestos
TimescaleDB proporciona índices especializados para consultas de series temporales
repo estructura de datos
repo estructura de datosEste esquema está actualmente en desarrollo. Si está interesado en acceso anticipado o tiene preguntas sobre esta funcionalidad, por favor contacte [email protected].
El repo El esquema proporciona un marco integral para gestionar estructuras organizativas, activos, dispositivos y sus relaciones en entornos multiinquilino. Construido sobre PostgreSQL 14+ con la extensión ltree, el esquema admite organizaciones jerárquicas, definiciones de campos personalizados para cualquier tipo de entidad, control de acceso basado en roles con restricciones a nivel de objeto y registros de auditoría completos con seguimiento de cambios a nivel de campo. Todas las entidades pueden extenderse sin modificaciones del esquema, localizarse para despliegues internacionales y vincularse mediante relaciones polimórficas flexibles.
El esquema aborda escenarios complejos de gestión de datos, incluyendo jerarquías de activos de flotas a través de niveles organizativos, plataformas SaaS multiinquilino que requieren aislamiento de datos, operaciones sujetas a cumplimiento con requisitos detallados de auditoría y sistemas que necesitan modelos de datos dinámicos adaptables mediante campos personalizados en lugar de migraciones de base de datos.
Encuentre el repo detalles del esquema a continuación.
Frecuencia de actualización
Los datos en el repo esquema se sincronizan en tiempo real con los sistemas de origen. Las actualizaciones ocurren inmediatamente a medida que suceden los cambios, con registros de auditoría que capturan todas las modificaciones para cumplimiento y análisis histórico.
ci_base
ci_baseEl repo el esquema utiliza un patrón de Herencia de Tabla Única para todos los datos de referencia a través de la ci_base tabla:
El repo el esquema utiliza un Herencia de Tabla Única patrón para todos los datos de referencia a través de la ci_base tabla. Este diseño consolida diccionarios del sistema, clasificaciones y elementos de referencia definidos por el usuario en una estructura unificada, proporcionando consistencia y flexibilidad en todo el esquema.
Arquitectura:
El ci_base la tabla sirve como la base para todos los datos de referencia, utilizando un discriminador campo para identificar el tipo de referencia específico. Cada tipo de referencia tiene una tabla correspondiente (como ci_device_type, ci_asset_type) que comparte el mismo id que ci_base, creando una relación de herencia segura por tipo.
Cómo las entidades de negocio se conectan a ci_base:
Todas las entidades de negocio en el repo esquema hacen referencia a ci_base subtipos para definir su clasificación y comportamiento:
organization→ referenciaci_organization_type(que hereda deci_entity_type→ci_base)user→ referenciaci_user_type(que hereda deci_entity_type→ci_base)device→ referenciaci_device_typeyci_device_status(ambos heredan deci_base)asset→ referenciaci_asset_type(que hereda deci_entity_type→ci_base)inventory→ referenciaci_inventory_type(que hereda deci_entity_type→ci_base)asset_group→ referenciaci_asset_group_type(que hereda deci_entity_type→ci_base)
Categorías de tipos de referencia:
Configuración del sistema
ci_module, ci_country, ci_role
Definen módulos del sistema, referencias geográficas y roles de usuario
Definiciones de tipos de entidad
ci_entity_type, ci_device_type, ci_asset_type, ci_inventory_type, ci_organization_type, ci_user_type, ci_asset_group_type
Clasifican todas las entidades de negocio por tipo
Estado y clasificación
ci_device_status, ci_asset_type_category
Agrupan estados de entidad y tipos de grupo en categorías
Control de acceso
ci_permission_scope
Definen qué permisos se pueden otorgar (conectado a ci_module y ci_entity_type)
Relaciones
ci_device_relation_type
Definen tipos de relaciones entre dispositivos (maestro-esclavo, respaldo, etc.)
Categorización
ci_tag, ci_catalog_category
Permiten etiquetado flexible y organización de catálogos
Tablas clave por categoría
Las tablas en el repo los esquemas se organizan en categorías funcionales. Las descripciones a continuación resumen las tablas más importantes según su propósito empresarial.
organization
organizationPropósito: Gestión organizacional jerárquica
Campos clave
id, parent_id, path, organization_type_id, title_en, is_active, deleted_at
Indexación
Índice GiST en path para consultas jerárquicas, índices en parent_id y organization_type_id
Notas especiales
Utiliza ltree para jerarquías multinivel, hereda de customizable_entity para soporte de campos personalizados
user
userPropósito: Cuentas de usuario y autenticación
Campos clave
id, organization_id, user_type_id, identity_provider, identity_provider_id, full_name, is_active
Indexación
Índice único en (organization_id, identity_provider, identity_provider_id)
Notas especiales
Integración de proveedores de identidad externos (Keycloak, Auth0, Okta), hereda de customizable_entity
device
devicePropósito: Dispositivos de seguimiento físicos
Campos clave
id, organization_id, device_type_id, status_id, hw_id, label
Indexación
Índices en organization_id, device_type_id, status_id, hw_id
Notas especiales
Identificador de hardware para seguimiento de dispositivos, hereda de customizable_entity para campos personalizados
asset
assetPropósito: Activos físicos o virtuales
Campos clave
id, organization_id, asset_type_id, label, description
Indexación
Índices en organization_id y asset_type_id
Notas especiales
Hereda de customizable_entity, vinculado a dispositivos a través de device_asset_link
inventory
inventoryPropósito: Registros de inventario y almacén
Campos clave
id, organization_id, inventory_type_id, code
Indexación
Índice único en (organization_id, code)
Notas especiales
Códigos únicos dentro de la organización, vinculados a dispositivos a través de device_inventory_link
asset_group
asset_groupPropósito: Agrupación de activos con seguimiento histórico
Campos clave
id, organization_id, group_type_id, title_en, description
Relaciones
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
Notas especiales
Membresía basada en tiempo a través de asset_group_item, consultar miembros actuales con WHERE detached_at IS NULL
custom_field_def
custom_field_defPropósito: Definiciones y metadatos de campos personalizados
Campos clave
id, organization_id, owner_entity_type_id, code, field_type, is_multi, is_required
Contenido
Los tipos de campo incluyen texto, número, booleano, fecha, fecha y hora, entity_ref, catalog_item_ref
Notas especiales
Permite campos personalizados flexibles para cualquier tipo de entidad, los valores se almacenan en tablas custom_field_value_* tablas
acl_role_permission
acl_role_permissionPropósito: Gestión de permisos basada en roles
Campos clave
id, role_id, permission_scope_id, target_entity_id, actions
Contenido
Máscara de bits de acción (READ=1, UPDATE=2, DELETE=4, CREATE=8), permisos específicos por destino o por tipo de entidad
Relaciones
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
Notas especiales
Funciona con user_role y acl_user_scope para determinar los permisos finales del usuario
audit_event
audit_eventPropósito: Registro de auditoría unificado para todos los cambios del sistema
Campos clave
id, event_category, user_id, aggregate_type, aggregate_id, event_type, event_data, occurred_at
Indexación
Índices en (user_id, occurred_at), (aggregate_type, aggregate_id, occurred_at), (event_category, occurred_at)
Notas especiales
Particionado por occurred_at (mensual), dos categorías: auth (autenticación) y domain (eventos de negocio), almacena deltas de cambio a nivel de campo en event_data JSONB
Relaciones de datos
El repo el esquema implementa patrones sofisticados de relaciones para modelado de datos flexible:
Estructuras jerárquicas
Las organizaciones usan rutas ltree para consultas de árbol eficientes
Los elementos de referencia (
ci_base) admiten jerarquías opcionalesMantenimiento automático de rutas mediante triggers de base de datos
Patrones de herencia
Herencia de tablas:
customizable_entity→ entidades de negocio (organization,user,device,asset,inventory,asset_group)Herencia de ID:
ci_base→ tablas de tipo de referenciaDiscriminación de tipo via
entity_type_idydiscriminadorcampos
Relaciones polimórficas
Ciertas tablas usan referencias polimórficas sin restricciones de clave externa para máxima flexibilidad:
acl_role_permission.target_entity_id→ cualquiercustomizable_entityacl_user_scope.target_entity_id→ cualquiercustomizable_entityentity_tag.entity_id→ cualquiercustomizable_entity
Estas relaciones se validan a nivel de la aplicación.
Información adicional
Validación de datos
El repo el esquema aplica integridad de datos mediante múltiples mecanismos:
Restricciones de la base de datos
Restricciones UNIQUE con soporte de borrado suave (índices parciales WHERE
deleted_atIS NULL)Restricciones CHECK (por ejemplo,
device_relationaseguramaster_id≠slave_id)Restricciones NOT NULL en campos requeridos
Valores DEFAULT para marcas de tiempo y banderas booleanas
Validación a nivel de la aplicación
Validación de tipo de entidad para referencias polimórficas
Validación de catálogo para referencias de campos personalizados
Validación de tipo de campo personalizado
Gestión de arrays de campos multi-valor
Optimización de consultas
Las tablas se organizan con estrategias de indexación específicas:
Índices estándar:
Todas las claves foráneas tienen índices dedicados
Índices basados en tiempo en
created_at,updated_at,deleted_atÍndices compuestos para columnas frecuentemente unidas
Índices especializados:
Índices GiST en rutas ltree para consultas jerárquicas
Índices únicos parciales que soportan borrado suave
Índices de valores de campos personalizados para filtrado y ordenación
Índices de eventos de auditoría por tiempo + entidad para búsquedas eficientes
Consideraciones de rendimiento:
Se recomienda agrupación de conexiones (PgBouncer)
Mantenimiento regular VACUUM para tablas grandes
Posible particionado futuro para
devicetabla pororganization_idVistas materializadas para cálculos complejos de control de acceso
Última actualización
¿Te fue útil?