Bronze layer
The Bronze layer contains two distinct data schemas, each serving different aspects of the telematics and business intelligence platform:
raw_business_data - containing tables, attributes, and values related to business information, such as vehicles, employees, geofences added by users, etc.
raw_telematics_data - containing tables, attributes, and values related to the telematics data transmitting from devices under monitoring, such as locations, inputs, outputs, and events.
Each schema is optimized for its specific data domain and access patterns, providing comprehensive coverage of operational, telematic, and asset management needs.
raw_business_data structure
raw_business_data structureThis schema contains 40+ carefully selected tables to cover various business aspects and use cases. These tables represent your core business entities, organizational structure, and operational data.
Find raw business data schema details below.
Update frequency
Data in this schema is synchronized with the core DB. Updates occur incrementally as changes happen in the source MySQL database, typically less than 5 minutes of the source change.
description_parameters
description_parametersThe system includes reference data to standardize values across the database:
Type definitions
Standard entity types
vehicle_type: car, truck, bus
Status codes
Task and system status values
tasks_status: unassigned, assigned, done
Unit definitions
Measurement units for sensors
units_type: liter, gallon, celsius
Entity classifications
Business entity categories
entities_type: place, task, customer
Key tables by category
The tables in the raw_business_data schema are organized into functional categories for easier navigation. The table below summarizes key tables by their business purpose:
Core business entities
Tracking and monitoring
Asset management
Location and routing
Task and workflow management
Rules and automation
Status and categorization
Groups and hierarchy
Custom fields and entities
Historical tracking
Reference and lookup data
raw_telematics_data structure
raw_telematics_data structureThe raw_telematics_data schema contains three primary table types that work together to provide comprehensive device data.
Find raw telematics data schema details below.
Key tables by category
Each table serves a specific purpose in capturing different aspects of device information:
Data in this schema is ingested directly from devices, with minimal latency (typically seconds). The schema is optimized for time-series data using TimescaleDB for efficient storage and retrieval.
Additional information
Data validation
The database enforces data integrity through multiple mechanisms:
CHECK constraints validate that values fall within acceptable ranges
Foreign keys ensure relationships between tables remain consistent
NOT NULL constraints guarantee that required fields always have values
DEFAULT values provide fallback when data isn't explicitly provided
Query optimization
Tables are organized with specific indexing strategies:
All tables include time-based indexes on
record_added_atForeign key columns have dedicated indexes for join performance
Frequently used column combinations have composite indexes
TimescaleDB provides specialized indexes for time-series queries
repo data structure
repo data structureThis schema is currently in development. If you're interested in early access or have questions about this functionality, please contact [email protected].
The repo schema provides a comprehensive framework for managing organizational structures, assets, devices, and their relationships in multi-tenant environments. Built on PostgreSQL 14+ with the ltree extension, the schema supports hierarchical organizations, custom field definitions for any entity type, role-based access control with object-level restrictions, and complete audit trails with field-level change tracking. All entities can be extended without schema modifications, localized for international deployments, and linked through flexible polymorphic relationships.
The schema addresses complex data management scenarios including fleet asset hierarchies across organizational levels, multi-tenant SaaS platforms requiring data isolation, compliance-driven operations with detailed audit requirements, and systems needing dynamic data models adaptable through custom fields rather than database migrations.
Find the repo schema details below.
Update frequency
Data in the repo schema is synchronized in real-time with source systems. Updates occur immediately as changes happen, with audit trails capturing all modifications for compliance and historical analysis.
ci_base
ci_baseThe repo schema uses a Single Table Inheritance pattern for all reference data through the ci_base table:
The repo schema uses a Single Table Inheritance pattern for all reference data through the ci_base table. This design consolidates system dictionaries, classifications, and user-defined reference items into one unified structure, providing consistency and flexibility across the entire schema.
Architecture:
The ci_base table serves as the foundation for all reference data, using a discriminator field to identify the specific reference type. Each reference type has a corresponding table (like ci_device_type, ci_asset_type) that shares the same id as ci_base, creating a type-safe inheritance relationship.
How business entities connect to ci_base:
All business entities in the repo schema reference ci_base subtypes to define their classification and behavior:
organization→ referencesci_organization_type(which inherits fromci_entity_type→ci_base)user→ referencesci_user_type(which inherits fromci_entity_type→ci_base)device→ referencesci_device_typeandci_device_status(both inherit fromci_base)asset→ referencesci_asset_type(which inherits fromci_entity_type→ci_base)inventory→ referencesci_inventory_type(which inherits fromci_entity_type→ci_base)asset_group→ referencesci_asset_group_type(which inherits fromci_entity_type→ci_base)
Reference type categories:
System configuration
ci_module, ci_country, ci_role
Define system modules, geographic references, and user roles
Entity type definitions
ci_entity_type, ci_device_type, ci_asset_type, ci_inventory_type, ci_organization_type, ci_user_type, ci_asset_group_type
Classify all business entities by type
Status and classification
ci_device_status, ci_asset_type_category
Track entity states and group types into categories
Access control
ci_permission_scope
Define what permissions can be granted (connected to ci_module and ci_entity_type)
Relationships
ci_device_relation_type
Define types of relationships between devices (master-slave, backup, etc.)
Categorization
ci_tag, ci_catalog_category
Enable flexible tagging and catalog organization
Key tables by category
The tables in the repo schema are organized into functional categories. The descriptions below summarize the most important tables by their business purpose.
Data relationships
The repo schema implements sophisticated relationship patterns for flexible data modeling:
Hierarchical structures
Organizations use ltree paths for efficient tree queries
Reference items (
ci_base) support optional hierarchiesAutomatic path maintenance via database triggers
Inheritance patterns
Table inheritance:
customizable_entity→ business entities (organization,user,device,asset,inventory,asset_group)ID inheritance:
ci_base→ reference type tablesType discrimination via
entity_type_idanddiscriminatorfields
Polymorphic relationships
Certain tables use polymorphic references without foreign key constraints for maximum flexibility:
acl_role_permission.target_entity_id→ anycustomizable_entityacl_user_scope.target_entity_id→ anycustomizable_entityentity_tag.entity_id→ anycustomizable_entity
These relationships are validated at the application level.
Additional information
Data validation
The repo schema enforces data integrity through multiple mechanisms:
Database constraints
UNIQUE constraints with soft delete support (partial indexes WHERE
deleted_atIS NULL)CHECK constraints (e.g.,
device_relationensuresmaster_id≠slave_id)NOT NULL constraints on required fields
DEFAULT values for timestamps and boolean flags
Application-level validation
Entity type validation for polymorphic references
Catalog validation for custom field references
Custom field type validation
Multi-value field array management
Query optimization
Tables are organized with specific indexing strategies:
Standard indexes:
All foreign keys have dedicated indexes
Time-based indexes on
created_at,updated_at,deleted_atComposite indexes for frequently joined columns
Specialized indexes:
GiST indexes on ltree paths for hierarchical queries
Partial unique indexes supporting soft delete
Custom field value indexes for filtering and sorting
Audit event indexes on time + entity for efficient lookups
Performance considerations:
Connection pooling recommended (PgBouncer)
Regular VACUUM maintenance for large tables
Possible future partitioning for
devicetable byorganization_idMaterialized views for complex access control calculations
Last updated
Was this helpful?