Capa Bronze
La capa Bronze contiene dos esquemas de datos distintos, cada uno sirviendo a diferentes aspectos de la plataforma de telemática e inteligencia de negocios:
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 los dispositivos bajo 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 de gestión operativa, telemática y de activos.
raw_business_data estructura
raw_business_data estructuraEste esquema contiene más de 40 tablas cuidadosamente seleccionadas para cubrir diversos aspectos comerciales y casos de uso. Estas tablas representan sus entidades empresariales principales, la estructura organizativa y los datos operativos.
Consulte los detalles del esquema de datos comerciales en bruto a continuación.
Frecuencia de actualización
Los datos en este esquema se sincronizan con la BD principal. Las actualizaciones ocurren de forma incremental a medida que se producen cambios en la base de datos MySQL de origen, normalmente en menos de 5 minutos desde el cambio en el origen.
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 unidad
Unidades de medida para sensores
units_type: liter, gallon, celsius
Clasificaciones de entidad
Categorías de entidad empresarial
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 siguiente resume las tablas clave según su propósito empresarial:
Entidades comerciales principales
Seguimiento y monitorización
Gestión de activos
Ubicación y enrutamiento
Gestión de tareas y flujos de trabajo
Reglas y automatización
Estado y categorización
Grupos y jerarquía
Campos y entidades personalizadas
Seguimiento histórico
Datos de referencia y consulta
raw_telematics_data estructura
raw_telematics_data estructuraEl raw_telematics_data esquema contiene tres tipos de tabla principales que trabajan juntos 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 cumple un propósito específico al capturar diferentes aspectos de la información del dispositivo:
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 la integridad de los datos mediante múltiples mecanismos:
Restricciones CHECK valide que los valores se encuentren dentro de rangos aceptables
Claves externas garanticen que las relaciones entre tablas permanezcan consistentes
Restricciones NOT NULL garanticen que los campos obligatorios siempre tengan valores
Valores DEFAULT proporcionen un valor alternativo cuando los datos no se proporcionen explícitamente
Optimización de consultas
Las tablas están organizadas con estrategias específicas de indexación:
Todas las tablas incluyen índices basados en tiempo en
record_added_atLas columnas de claves externas tienen índices dedicados para el rendimiento de joins
Combinaciones de columnas usadas frecuentemente 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 a [email protected].
El repo El esquema proporciona un marco integral para gestionar estructuras organizacionales, activos, dispositivos y sus relaciones en entornos multiarrendatarios. 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 ampliarse 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 flota a través de niveles organizacionales, plataformas SaaS multiarrendatario que requieren aislamiento de datos, operaciones impulsadas por 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 los repo detalles del esquema a continuación.
Frecuencia de actualización
Datos en el repo esquema se sincronizan en tiempo real con los sistemas de origen. Las actualizaciones ocurren inmediatamente conforme se producen 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 Single Table Inheritance para todos los datos de referencia a través de la ci_base tabla:
El repo el esquema utiliza un Single Table Inheritance 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 única estructura unificada, proporcionando coherencia y flexibilidad en todo el esquema.
Arquitectura:
El ci_base la tabla sirve como la base para todos los datos de referencia, usando 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:
organización→ referenciaci_organization_type(que hereda deci_entity_type→ci_base)usuario→ referenciaci_user_type(que hereda deci_entity_type→ci_base)dispositivo→ referenciaci_device_typeyci_device_status(ambos heredan deci_base)activo→ referenciaci_asset_type(que hereda deci_entity_type→ci_base)inventario→ referenciaci_inventory_type(que hereda deci_entity_type→ci_base)grupo_de_activos→ 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
Definir 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
Clasificar todas las entidades de negocio por tipo
Estado y clasificación
ci_device_status, ci_asset_type_category
Rastrear estados de entidad y agrupar tipos en categorías
Control de acceso
ci_permission_scope
Definir qué permisos se pueden otorgar (conectado a ci_module y ci_entity_type)
Relaciones
ci_device_relation_type
Definir tipos de relaciones entre dispositivos (maestro-esclavo, respaldo, etc.)
Categorización
ci_tag, ci_catalog_category
Permitir etiquetado flexible y organización de catálogos
Tablas clave por categoría
Las tablas en el repo los esquemas están organizados en categorías funcionales. Las descripciones a continuación resumen las tablas más importantes según su propósito de negocio.
Relaciones de datos
El repo el esquema implementa patrones de relación sofisticados para un 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 (organización,usuario,dispositivo,activo,inventario,grupo_de_activos)Herencia de ID:
ci_base→ tablas de tipo de referenciaDiscriminación de tipo mediante
entity_type_idydiscriminadorcampos
Relaciones polimórficas
Ciertas tablas usan referencias polimórficas sin restricciones de clave foránea para máxima flexibilidad:
acl_role_permission.target_entity_id→ cualquieracustomizable_entityacl_user_scope.target_entity_id→ cualquieracustomizable_entityentity_tag.entity_id→ cualquieracustomizable_entity
Estas relaciones se validan en el nivel de la aplicación.
Información adicional
Validación de datos
El repo el esquema aplica la integridad de datos mediante múltiples mecanismos:
Restricciones de base de datos
Restricciones UNIQUE con soporte de borrado suave (índices parciales WHERE
deleted_atIS NULL)Restricciones CHECK (por ejemplo,
device_relationgarantizamaster_id≠slave_id)Restricciones NOT NULL en campos obligatorios
Valores DEFAULT para marcas de tiempo y banderas booleanas
Validación a nivel de 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 para campos multivalor
Optimización de consultas
Las tablas están organizadas con estrategias específicas de indexación:
Í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 campo personalizado para filtrado y ordenación
Índices de eventos de auditoría por tiempo + entidad para búsquedas eficientes
Consideraciones de rendimiento:
Se recomienda pooling de conexiones (PgBouncer)
Mantenimiento VACUUM regular para tablas grandes
Posible particionado futuro para
dispositivotabla pororganization_idVistas materializadas para cálculos complejos de control de acceso
Última actualización
¿Te fue útil?