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

This 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.

The interactive diagram of raw_business_data schema is available on dbdiagram.io: https://dbdiagram.io/d/V3-bronze-layer-68ecfd1c2e68d21b4131089a

Find raw business data schema details below.

raw_business_data schema

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

The system includes reference data to standardize values across the database:

Reference type
Description
Example values

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

users

Purpose: User account and profile information

Attribute
Details

Key fields

user_id, company_label, first_name, last_name, middle_name, locale, timezone_label, master_id, registration_datetime

Relationships

Parent user via master_id, linked to employees, departments, places, tasks through user_id

Special notes

Central entity connecting organizational data; master_id enables user hierarchies for multi-level account structures

employees

Purpose: Employee and driver records with licensing and assignment details

Attribute
Details

Key fields

employee_id, user_id, object_id, department_id, first_name, last_name, driver_license_number, driver_license_valid_till, hardware_key

Relationships

Links to users, departments, objects (assigned tracker), tracked in driver_history and checkins

Special notes

Hardware key enables driver identification via iButton or RFID; supports geofencing with latitude, longitude, radius fields

departments

Purpose: Organizational units with geographic location

Attribute
Details

Key fields

department_id, user_id, department_label, latitude, longitude, radius, address

Relationships

Links employees to organizational structure through department_id

Special notes

Location fields support geofence-based analytics for department-level reporting

Tracking and monitoring

devices

Purpose: Physical tracking device information and network status

Attribute
Details

Key fields

device_id, owner_id, device_imei, phone, status_listing_id, network_label, signal_level, has_roaming, created_at

Relationships

Core entity linking to objects, models, sensor_description, counters; owner_id references users.user_id

Special notes

All telematic data in raw_telematics_data schema references this table via device_id

objects

Purpose: Monitored entities (vehicles, assets, personnel)

Attribute
Details

Key fields

object_id, client_id, device_id, object_label, model, group_id, create_datetime, is_deleted

Relationships

Central hub connecting devices to users (client_id), vehicle details, tracking history, tasks, and rules

Special notes

Represents the "trackable unit" in the system; one object per device in active use

models

Purpose: Device hardware specifications and capabilities

Attribute
Details

Key fields

model_id, model, vendor, alternative_label, analog_amount, digital_amount, outputs_amount, has_battery_level, has_altitude, has_phone

Content

Boolean capability flags indicate which data fields are available from this device type

Special notes

Use capability flags to determine valid sensors and inputs when querying telematic data

sensor_description

Purpose: Sensor configuration and calibration data

Attribute
Details

Key fields

sensor_id, device_id, sensor_label, input_label, sensor_type, units_type, multiplier, divider, accuracy, calibration_data

Relationships

Links device inputs (from raw_telematics_data.inputs) to business logic through device_id and input_label matching

Special notes

calibration_data (JSONB) stores sensor-specific calibration tables for fuel level sensors; multiplier and divider convert raw values to units

Asset management

vehicles

Purpose: Vehicle specifications, documentation, and operational parameters

Attribute
Details

Key fields

vehicle_id, user_id, object_id, garage_id, vehicle_label, registration_number, vin, manufacture_year, fuel_type, fuel_cost, standard_fuel_consumption, max_speed

Relationships

Links to objects (current tracker), garages (service location), vehicle_service_tasks; tracked in vehicle_trackers_history

Special notes

Physical dimension fields (payload_length, payload_width, payload_height, gross_weight) support load planning analytics; insurance dates enable compliance tracking

garages

Purpose: Service and maintenance facility locations

Attribute
Details

Key fields

garage_id, user_id, latitude, longitude, radius, address, organization_label, mechanic_name, dispatcher_name

Relationships

Referenced by vehicles.garage_id for service location assignment

Special notes

Location fields enable geofence-based service visit detection and proximity analysis

vehicle_service_tasks

Purpose: Maintenance schedules and service history

Attribute
Details

Key fields

service_task_id, vehicle_id, description, status, cost, start_date, end_date, completion_date, predicted_datetime, mileage_limit, engine_hours_limit

Content

Supports three trigger types: date-based, mileage-based, engine-hours-based; notification settings for email, SMS, push

Special notes

is_repeat and interval fields enable recurring maintenance schedules; is_unplanned distinguishes scheduled vs. reactive maintenance

Location and routing

zones

Purpose: Geofenced areas for monitoring and automation

Attribute
Details

Key fields

zone_id, client_id, zone_label, zone_type, latitude, longitude, circle_center_latitude, circle_center_longitude, radius, address, color

Content

Zone types include circle, polygon (defined via geofence_points), and special area classifications

Relationships

Referenced by rules2zones, users2zones; polygon vertices stored in geofence_points

Special notes

PostGIS functions can be used to check point-in-polygon for complex geofence analysis

places

Purpose: Points of interest with custom attributes

Attribute
Details

Key fields

place_id, user_id, place_label, latitude, longitude, radius, address, description, external_id, custom_fields

Relationships

Extended with custom field values through places_text_fields, places_decimal_fields, places_bigint_fields, places_longtext_fields, places_linked_entity_fields

Special notes

custom_fields JSONB provides quick access; related tables enable filtering and sorting on custom attributes

geofence_points

Purpose: Polygon vertex coordinates for complex geofence shapes

Attribute
Details

Key fields

zone_id, number, latitude, longitude

Relationships

Multiple records per zone_id define polygon boundaries; number field determines vertex order

Special notes

Query with ORDER BY number to reconstruct polygon path; use with PostGIS ST_MakePolygon for geometric operations

Task and workflow management

tasks

Purpose: Work order assignments and execution tracking

Attribute
Details

Key fields

task_id, user_id, object_id, parent_task_id, task_label, status, task_type, latitude, longitude, radius, arrival_datetime, created_at, status_change_datetime, custom_fields

Content

Supports hierarchical tasks via parent_task_id; time windows defined by time_from/time_to; geofence validation with location and radius

Relationships

Links to forms (data collection), task_history (status changes), objects (assigned tracker)

Special notes

stay_duration and arrival_duration_minutes enable compliance monitoring for delivery and service tasks

forms

Purpose: Data collection forms and submissions

Attribute
Details

Key fields

form_id, task_id, object_id, form_label, fields, values, submitted_at, submission_latitude, submission_longitude, is_submission_in_zone

Content

fields defines form structure (JSON); values contains submitted data (JSON)

Relationships

Links to tasks (associated work order), objects (submitter), referenced in checkins

Special notes

Location validation flag is_submission_in_zone enables geofence-based form submission rules

checkins

Purpose: Location-based attendance and activity records

Attribute
Details

Key fields

checkin_id, employee_id, object_id, form_id, user_id, planned_datetime, actual_datetime, latitude, longitude, radius, address, comment

Relationships

Connects employees to forms and locations; tracks deviation from planned schedule

Special notes

Time variance between planned_datetime and actual_datetime enables punctuality reporting; radius defines acceptable location tolerance

task_history

Purpose: Audit trail for task lifecycle events

Attribute
Details

Key fields

task_history_id, task_id, user_id, activity, event_datetime, payload

Content

Activity types defined in description_parametrs; payload stores event-specific details (text)

Special notes

Essential for task completion analysis, status transition reporting, and user activity tracking

Rules and automation

rules

Purpose: Event triggers and alert configurations

Attribute
Details

Key fields

rule_id, object_id, client_id, event_type, event_label, event_group, description, parameters, alert_email, alert_sms, alert_phone, is_push_enabled, created_at, is_deleted

Content

Rule parameters (JSONB) define trigger conditions; supports email, SMS, phone, and push notifications

Relationships

Links to objects via rules2objects, zones via rules2zones

Special notes

event_type defines specific monitoring scenario (speeding, geofence breach, sensor threshold); maximum field enables event aggregation for threshold-based alerting

rules2objects

Purpose: Rule-to-object associations with instance-specific parameters

Attribute
Details

Key fields

rule_id, object_id, param_group_number, object_params

Content

object_params (JSONB) enables per-object rule customization (e.g., different speed limits per vehicle)

Special notes

Many-to-many relationship allows one rule to monitor multiple objects with different parameters

rules2zones

Purpose: Associates rules with geofence triggers

Attribute
Details

Key fields

rule_id, zone_id

Special notes

Many-to-many relationship enables multi-zone monitoring for a single rule (e.g., alert when entering any of several restricted areas)

Status and categorization

statuses

Purpose: Custom status definitions for status listings

Attribute
Details

Key fields

status_id, listing_id, status_label, color, order_sort, is_deleted

Relationships

Groups of statuses organized by listing_id (references status_listings); used in status_history

Special notes

order_sort defines display sequence; color enables visual differentiation in reporting

status_listings

Purpose: Status set definitions for devices or employees

Attribute
Details

Key fields

status_listing_id, user_id, status_listing_label, is_supervisor_controlled, is_employee_controlled, is_deleted

Relationships

Referenced by devices.status_listing_id and statuses.listing_id

Special notes

Control flags determine who can change statuses: supervisor-only, employee self-service, or both

status_history

Purpose: Audit trail for status changes

Attribute
Details

Key fields

status_history_id, device_id, old_status_id, new_status_id, updated_by, changed_datetime, server_datetime, latitude, longitude, address

Relationships

Links to devices, statuses (old and new), description_parametrs (for updated_by role)

Special notes

Location capture enables geographic analysis of status transitions; useful for workday start/end location reporting

tags

Purpose: User-defined categorization labels

Attribute
Details

Key fields

tag_id, user_id, tag_label, color

Relationships

Applied to entities via tag_links; scope defined by user

Special notes

Flexible categorization system supporting multiple tags per entity

Groups and hierarchy

groups

Purpose: Organizational grouping for objects (trackers)

Attribute
Details

Key fields

group_id, client_id, group_label, group_color

Relationships

Referenced by objects.group_id; client ownership via client_id (references users)

Special notes

Enables folder-like organization of monitoring entities for reporting and permissions

groups_objects

Purpose: Many-to-many relationship between groups and objects

Attribute
Details

Key fields

Composite primary key: groups_client_id, objects_client_id

Special notes

Enables objects to belong to multiple groups simultaneously; query with both client_id values for group membership

Custom fields and entities

entities

Purpose: Entity type definitions for custom field framework

Attribute
Details

Key fields

entity_id, user_id, entity_label, builtin_type

Relationships

Referenced by custom_fields to define which custom fields apply to which entity types

Special notes

builtin_type links to description_parametrs for system-defined entity classifications

custom_fields

Purpose: Custom field definitions

Attribute
Details

Key fields

custom_field_id, entity_id, custom_field_label, custom_field_type, description, is_required, parameters

Content

parameters (JSONB) stores field-type-specific configuration (validation rules, dropdown options, etc.)

Relationships

Defines available custom attributes for entities; field type links to description_parametrs

Special notes

Enables dynamic schema extension without database changes; used extensively in places and tasks

Historical tracking

driver_history

Purpose: Employee-to-object assignment change log

Attribute
Details

Key fields

driver_history_id, object_id, old_employee_id, new_employee_id, hardware_key, changed_datetime, server_datetime, updated_by, latitude, longitude, address

Relationships

Tracks driver assignments to vehicles over time; links to employees and objects

Special notes

Essential for driver-specific reporting when drivers switch vehicles; location capture enables assignment change location analysis

vehicle_trackers_history

Purpose: Vehicle-to-tracker assignment change log

Attribute
Details

Key fields

vehicle_tracker_history_id, vehicle_id, object_id, changed_datetime

Relationships

Tracks which GPS device was installed in which vehicle over time

Special notes

Critical for historical data analysis when trackers are moved between vehicles; enables accurate mileage and usage attribution

Reference and lookup data

description_parametrs

Purpose: System reference data and enumeration values

Attribute
Details

Key fields

key, type, description

Content

Provides human-readable labels for coded values throughout the database (task status, fuel types, counter types, etc.)

Relationships

Referenced via foreign keys from multiple tables for standardized categorization

Special notes

Essential for translating integer codes to readable values in reporting; type field groups related enumerations

counters

Purpose: Odometer and engine-hour tracking configuration

Attribute
Details

Key fields

counter_id, device_id, counter_type, sensor_id, multiplier

Relationships

Links devices to sensor readings that represent distance or time counters

Special notes

multiplier converts sensor pulses to actual units (km, miles, hours); counter_type from description_parametrs defines measurement type

device_output_name

Purpose: Custom labels for device output channels

Attribute
Details

Key fields

device_id, number, label

Content

Maps output channel numbers to user-defined names (e.g., "Door Lock", "Engine Block")

Special notes

Enables readable reporting when analyzing device output commands and states

raw_telematics_data structure

The raw_telematics_data schema contains three primary table types that work together to provide comprehensive device data.

Bronze layer raw telematics data ERD
Bronze layer raw telematics data ERD

The interactive diagram of raw_telematics_data schema is available on dbdiagram.io: https://dbdiagram.io/d/v1-schema-telematics-bd-67a0acef263d6cf9a0d8e750

Find raw telematics data schema details below.

raw_telematics_data schema

Key tables by category

Each table serves a specific purpose in capturing different aspects of device information:

tracking_data_core

Purpose: Core location and motion data

Attribute
Details

Key fields

device_id, device_time, platform_time, latitude, longitude, speed, altitude, satellites, hdop, event_id

Indexing

Optimized with index on (device_id, device_time)

Special notes

Location data (latitude and longitude) uses integer format with 10⁷ precision for optimal TimescaleDB performance Speed is also stored in integer, so you need to divide it with 100

inputs

Purpose: Sensor readings from devices

Attribute
Details

Key fields

input_id, device_id, device_time, sensor_name, value

Content

Analog readings (fuel level, temperature, voltage), calculated values (engine RPM)

Relationships

states

Purpose: Device status indicators and operational modes

Attribute
Details

Key Fields

state_id, device_id, device_time, state_name, value

Content

Operating mode indicators (working, idle, off), component statuses (ignition, doors)

Value Format

Boolean values (1/0) or specific status codes

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_at

  • Foreign 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

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.

The interactive diagram ofrepo data schema is available on dbdiagram.io: https://dbdiagram.io/d/Navixy-Repo-data-schema-68ad788c1e7a611967a0930e

Find the repo schema details below.

repo data schema

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

The 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 → references ci_organization_type (which inherits from ci_entity_typeci_base)

  • user → references ci_user_type (which inherits from ci_entity_typeci_base)

  • device → references ci_device_type and ci_device_status (both inherit from ci_base)

  • asset → references ci_asset_type (which inherits from ci_entity_typeci_base)

  • inventory → references ci_inventory_type (which inherits from ci_entity_typeci_base)

  • asset_group → references ci_asset_group_type (which inherits from ci_entity_typeci_base)

Reference type categories:

Category
Tables
Purpose

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

Example query patterns

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.

organization

Purpose: Hierarchical organization management

Attribute
Details

Key fields

id, parent_id, path, organization_type_id, title_en, is_active, deleted_at

Indexing

GiST index on path for hierarchical queries, indexes on parent_id and organization_type_id

Special notes

Uses ltree for multi-level hierarchies, inherits from customizable_entity for custom fields support

user

Purpose: User accounts and authentication

Attribute
Details

Key fields

id, organization_id, user_type_id, identity_provider, identity_provider_id, full_name, is_active

Indexing

Unique index on (organization_id, identity_provider, identity_provider_id)

Special notes

External identity provider integration (Keycloak, Auth0, Okta), inherits from customizable_entity

device

Purpose: Physical tracking devices

Attribute
Details

Key fields

id, organization_id, device_type_id, status_id, hw_id, label

Indexing

Indexes on organization_id, device_type_id, status_id, hw_id

Special notes

Hardware identifier for device tracking, inherits from customizable_entity for custom fields

asset

Purpose: Physical or virtual assets

Attribute
Details

Key fields

id, organization_id, asset_type_id, label, description

Indexing

Indexes on organization_id and asset_type_id

Special notes

Inherits from customizable_entity, linked to devices via device_asset_link

inventory

Purpose: Inventory and warehouse records

Attribute
Details

Key fields

id, organization_id, inventory_type_id, code

Indexing

Unique index on (organization_id, code)

Special notes

Unique codes within organization, linked to devices via device_inventory_link

asset_group

Purpose: Asset grouping with historical tracking

Attribute
Details

Key fields

id, organization_id, group_type_id, title_en, description

Relationships

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

Special notes

Time-based membership via asset_group_item, query current members with WHERE detached_at IS NULL

custom_field_def

Purpose: Custom field definitions and metadata

Attribute
Details

Key fields

id, organization_id, owner_entity_type_id, code, field_type, is_multi, is_required

Content

Field types include text, number, boolean, date, datetime, entity_ref, catalog_item_ref

Special notes

Enables flexible custom fields for any entity type, values stored in type-specific custom_field_value_* tables

acl_role_permission

Purpose: Role-based permission management

Attribute
Details

Key fields

id, role_id, permission_scope_id, target_entity_id, actions

Content

Action bitmask (READ=1, UPDATE=2, DELETE=4, CREATE=8), target-specific or entity-type-wide permissions

Relationships

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

Special notes

Works with user_role and acl_user_scope to determine final user permissions

audit_event

Purpose: Unified audit log for all system changes

Attribute
Details

Key fields

id, event_category, user_id, aggregate_type, aggregate_id, event_type, event_data, occurred_at

Indexing

Indexes on (user_id, occurred_at), (aggregate_type, aggregate_id, occurred_at), (event_category, occurred_at)

Special notes

Partitioned by occurred_at (monthly), two categories: auth (authentication) and domain (business events), stores field-level change deltas in event_data JSONB

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 hierarchies

  • Automatic 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 tables

  • Type discrimination via entity_type_id and discriminator fields

Polymorphic relationships

Certain tables use polymorphic references without foreign key constraints for maximum flexibility:

  • acl_role_permission.target_entity_id → any customizable_entity

  • acl_user_scope.target_entity_id → any customizable_entity

  • entity_tag.entity_id → any customizable_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_at IS NULL)

  • CHECK constraints (e.g., device_relation ensures master_idslave_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_at

  • Composite 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 device table by organization_id

  • Materialized views for complex access control calculations

Last updated

Was this helpful?