Couche Bronze

La couche Bronze contient deux schémas de données distincts, chacun servant des aspects différents de la plateforme de télématique et d’intelligence d’affaires :

  • raw_business_data - contenant des tables, attributs et valeurs liées aux informations métier, telles que véhicules, employés, géorepères ajoutés par les utilisateurs, etc.

  • raw_telematics_data - contenant des tables, attributs et valeurs liées aux données télématiques transmises depuis les appareils sous surveillance, telles que les positions, entrées, sorties et événements.

Chaque schéma est optimisé pour son domaine de données spécifique et ses schémas d’accès, offrant une couverture complète des besoins opérationnels, télématiques et de gestion des actifs.

raw_business_data structure

Ce schéma contient plus de 40 tables soigneusement sélectionnées pour couvrir divers aspects métier et cas d’usage. Ces tables représentent vos entités métier principales, la structure organisationnelle et les données opérationnelles.

Le diagramme interactif du schéma raw_business_data est disponible sur dbdiagram.io: https://dbdiagram.io/d/V3-bronze-layer-68ecfd1c2e68d21b4131089a

Consultez les détails du schéma des données métier brutes ci‑dessous.

schéma raw_business_data

Fréquence de mise à jour

Les données de ce schéma sont synchronisées avec la base de données principale. Les mises à jour se produisent de manière incrémentielle lorsque des modifications surviennent dans la base MySQL source, généralement en moins de 5 minutes après la modification source.

description_parameters

Le système inclut des données de référence pour standardiser les valeurs dans la base de données :

Type de référence
Description
Valeurs d'exemple

Définitions de type

Types d'entités standard

vehicle_type: car, truck, bus

Codes d'état

Valeurs d'état des tâches et du système

tasks_status: unassigned, assigned, done

Définitions d'unités

Unités de mesure pour les capteurs

units_type: liter, gallon, celsius

Classifications d'entités

Catégories d'entités métier

entities_type: place, task, customer

Tables clés par catégorie

Les tables dans le raw_business_data schéma sont organisées en catégories fonctionnelles pour faciliter la navigation. Le tableau ci‑dessous résume les tables clés selon leur finalité métier :

Aperçu du schéma de base de données

Catégorie
Nom de la table
Description

Structure organisationnelle

  1. users

  2. departments

  3. employees

  4. groups

  1. Comptes utilisateur avec informations de profil

  2. Départements avec données de géolocalisation

  3. Détails des employés et des conducteurs

  4. Groupes d'organisation des traceurs

Objets et dispositifs

  1. devices

  2. models

  3. objects

  4. vehicles

  5. sensor_description

  1. Dispositifs de suivi physiques

  2. Spécifications des modèles de dispositifs

  3. Objets surveillés

  4. Détails et spécifications des véhicules

  5. Détails de configuration des capteurs

Lieux et zones

  1. places

  2. zones

  3. garages

  4. tags

  1. Points d'intérêt avec géolocalisation

  2. Zones de surveillance géofencées

  3. Lieux de service des véhicules

  4. Libellés organisationnels

Données opérationnelles

  1. tasks

  2. forms

  3. checkins

  4. events

  5. statuses

  6. vehicle_service_tasks

  1. Affectation et suivi des tâches

  2. Formulaires de collecte de données

  3. Enregistrements de présence basés sur la localisation

  4. Événements système et notifications

  5. Définitions des statuts

  6. Dossiers de maintenance des véhicules

raw_telematics_data structure

Le raw_telematics_data schéma contient trois principaux types de tables qui travaillent ensemble pour fournir des données complètes sur les dispositifs.

Bronze layer raw telematics data ERD
ERD des données télématiques brutes - couche Bronze

Le diagramme interactif du schéma raw_telematics_data est disponible sur dbdiagram.io: https://dbdiagram.io/d/v1-schema-telematics-bd-67a0acef263d6cf9a0d8e750

Trouvez ci‑dessous les détails du schéma des données télématiques brutes.

schéma raw_telematics_data

Tables clés par catégorie

Chaque table remplit une fonction spécifique pour capturer différents aspects de l'information sur les dispositifs :

tracking_data_core

Objectif: Données principales de localisation et de mouvement

Attribut
Détails

Champs clés

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

Indexation

Optimisé avec un index sur (device_id, device_time)

Remarques particulières

Les données de localisation (latitude et longitude) utilisent un format entier avec une précision de 10⁷ pour des performances optimales sur TimescaleDB La vitesse est également stockée en entier ; vous devez donc la diviser par 100

inputs

Objectif: Lectures de capteurs provenant des dispositifs

Attribut
Détails

Champs clés

input_id, device_id, device_time, sensor_name, value

Contenu

Lectures analogiques (niveau de carburant, température, tension), valeurs calculées (régime moteur)

Relations

states

Objectif: Indicateurs d'état du dispositif et modes opérationnels

Attribut
Détails

Champs clés

state_id, device_id, device_time, state_name, value

Contenu

Indicateurs de mode de fonctionnement (working, idle, off), états des composants (ignition, doors)

Format de valeur

Valeurs booléennes (1/0) ou codes d'état spécifiques

Les données de ce schéma sont ingérées directement depuis les dispositifs, avec une latence minimale (typiquement quelques secondes). Le schéma est optimisé pour les séries temporelles en utilisant TimescaleDB pour un stockage et une récupération efficaces.

Informations supplémentaires

Validation des données

La base de données applique l'intégrité des données via plusieurs mécanismes :

  • Contraintes CHECK valider que les valeurs se situent dans des plages acceptables

  • Clés étrangères assurer que les relations entre les tables restent cohérentes

  • Contraintes NOT NULL garantir que les champs obligatoires ont toujours des valeurs

  • Valeurs DEFAULT fournir un repli lorsque les données ne sont pas fournies explicitement

Optimisation des requêtes

Les tables sont organisées avec des stratégies d'indexation spécifiques :

  • Toutes les tables incluent index temporels sur record_added_at

  • Les colonnes de clés étrangères ont des index dédiés pour améliorer les performances des jointures

  • Les combinaisons de colonnes fréquemment utilisées ont des index composites

  • TimescaleDB fournit des index spécialisés pour les requêtes sur séries temporelles

repo structure des données

Le repo le schéma fournit un cadre complet pour gérer les structures organisationnelles, les actifs, les dispositifs et leurs relations dans des environnements multi‑locataires. Basé sur PostgreSQL 14+ avec l'extension ltree, le schéma prend en charge des organisations hiérarchiques, des définitions de champs personnalisés pour tout type d'entité, un contrôle d'accès basé sur les rôles avec restrictions au niveau des objets et des pistes d'audit complètes avec suivi des modifications au niveau des champs. Toutes les entités peuvent être étendues sans modification du schéma, localisées pour des déploiements internationaux et liées via des relations polymorphes flexibles.

Le schéma traite des scénarios complexes de gestion des données, y compris les hiérarchies d'actifs de flotte à travers les niveaux organisationnels, les plateformes SaaS multi‑locataires nécessitant l'isolement des données, les opérations soumises à conformité avec exigences d'audit détaillées, et les systèmes nécessitant des modèles de données dynamiques adaptables via des champs personnalisés plutôt que des migrations de base de données.

Le diagramme interactif derepo schéma de données est disponible sur dbdiagram.io: https://dbdiagram.io/d/Navixy-Repo-data-schema-68ad788c1e7a611967a0930e

Trouvez le repo détails du schéma ci‑dessous.

repo schéma de données

Fréquence de mise à jour

Les données dans le repo schéma sont synchronisées en temps réel avec les systèmes sources. Les mises à jour sont effectuées immédiatement dès qu’un changement survient, les pistes d’audit capturant toutes les modifications pour la conformité et l’analyse historique.

ci_base

Le repo le schéma utilise un modèle Single Table Inheritance pour toutes les données de référence via la ci_base table :

Le repo le schéma utilise un Single Table Inheritance modèle pour toutes les données de référence via la ci_base table. Cette conception consolide les dictionnaires système, les classifications et les éléments de référence définis par les utilisateurs en une structure unifiée, offrant cohérence et flexibilité à travers tout le schéma.

Architecture :

Le ci_base la table sert de base pour toutes les données de référence, en utilisant un discriminateur champ pour identifier le type de référence spécifique. Chaque type de référence a une table correspondante (comme ci_device_type, ci_asset_type) qui partage le même id en tant que ci_base, créant une relation d’héritage sûre par type.

Comment les entités métier se connectent à ci_base :

Toutes les entités métier du repo schéma référencent ci_base les sous-types pour définir leur classification et leur comportement :

  • organization → référence ci_organization_type (qui hérite de ci_entity_typeci_base)

  • user → référence ci_user_type (qui hérite de ci_entity_typeci_base)

  • device → référence ci_device_type et ci_device_status (les deux héritent de ci_base)

  • asset → référence ci_asset_type (qui hérite de ci_entity_typeci_base)

  • inventory → référence ci_inventory_type (qui hérite de ci_entity_typeci_base)

  • asset_group → référence ci_asset_group_type (qui hérite de ci_entity_typeci_base)

Catégories de types de référence :

Catégorie
Tables
Objectif

Configuration du système

ci_module, ci_country, ci_role

Définir les modules du système, les références géographiques et les rôles utilisateur

Définitions des types d’entités

ci_entity_type, ci_device_type, ci_asset_type, ci_inventory_type, ci_organization_type, ci_user_type, ci_asset_group_type

Classer toutes les entités métier par type

Statut et classification

ci_device_status, ci_asset_type_category

Suivre les états des entités et regrouper les types en catégories

Contrôle d’accès

ci_permission_scope

Définir les permissions pouvant être accordées (connectées à ci_module et ci_entity_type)

Relations

ci_device_relation_type

Définir les types de relations entre appareils (maître-esclave, secours, etc.)

Catégorisation

ci_tag, ci_catalog_category

Permettre le balisage flexible et l’organisation du catalogue

Exemples de modèles de requêtes

Tables clés par catégorie

Les tables dans le repo les schémas sont organisés en catégories fonctionnelles. Les descriptions ci‑dessous résument les tables les plus importantes selon leur finalité métier.

organization

Finalité : Gestion hiérarchique des organisations

Attribut
Détails

Champs clés

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

Indexation

Index GiST sur path pour les requêtes hiérarchiques, index sur parent_id et organization_type_id

Remarques particulières

Utilise ltree pour les hiérarchies multi-niveaux, hérite de customizable_entity pour le support des champs personnalisés

user

Finalité : Comptes utilisateur et authentification

Attribut
Détails

Champs clés

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

Indexation

Index unique sur (organization_id, identity_provider, identity_provider_id)

Remarques particulières

Intégration des fournisseurs d’identité externes (Keycloak, Auth0, Okta), hérite de customizable_entity

device

Finalité : Dispositifs de suivi physiques

Attribut
Détails

Champs clés

id, organization_id, device_type_id, status_id, hw_id, label

Indexation

Index sur organization_id, device_type_id, status_id, hw_id

Remarques particulières

Identifiant matériel pour le suivi des appareils, hérite de customizable_entity pour les champs personnalisés

asset

Finalité : Actifs physiques ou virtuels

Attribut
Détails

Champs clés

id, organization_id, asset_type_id, label, description

Indexation

Index sur organization_id et asset_type_id

Remarques particulières

Hérite de customizable_entity, lié aux appareils via device_asset_link

inventory

Finalité : Inventaires et enregistrements d’entrepôt

Attribut
Détails

Champs clés

id, organization_id, inventory_type_id, code

Indexation

Index unique sur (organization_id, code)

Remarques particulières

Codes uniques au sein d’une organisation, liés aux appareils via device_inventory_link

asset_group

Finalité : Regroupement d’actifs avec suivi historique

Attribut
Détails

Champs clés

id, organization_id, group_type_id, title_en, description

Relations

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

Remarques particulières

Appartenance basée sur le temps via asset_group_item, interroger les membres actuels avec WHERE detached_at IS NULL

custom_field_def

Finalité : Définitions et métadonnées des champs personnalisés

Attribut
Détails

Champs clés

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

Contenu

Les types de champs incluent text, number, boolean, date, datetime, entity_ref, catalog_item_ref

Remarques particulières

Permet des champs personnalisés flexibles pour tout type d’entité, les valeurs sont stockées dans des custom_field_value_* tables

acl_role_permission

Finalité : Gestion des permissions basée sur les rôles

Attribut
Détails

Champs clés

id, role_id, permission_scope_id, target_entity_id, actions

Contenu

Masque d’actions (READ=1, UPDATE=2, DELETE=4, CREATE=8), permissions ciblées ou globales par type d’entité

Relations

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

Remarques particulières

Fonctionne avec user_role et acl_user_scope pour déterminer les permissions finales de l’utilisateur

audit_event

Finalité : Journal d’audit unifié pour toutes les modifications du système

Attribut
Détails

Champs clés

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

Indexation

Index sur (user_id, occurred_at), (aggregate_type, aggregate_id, occurred_at), (event_category, occurred_at)

Remarques particulières

Partitionné par occurred_at (mensuel), deux catégories : auth (authentification) et domain (événements métier), stocke les deltas de changement au niveau des champs en event_data JSONB

Relations de données

Le repo le schéma implémente des modèles de relations sophistiqués pour une modélisation de données flexible :

Structures hiérarchiques

  • Les organisations utilisent des chemins ltree pour des requêtes d’arbre efficaces

  • Les éléments de référence (ci_base) prennent en charge des hiérarchies optionnelles

  • Maintenance automatique des chemins via des triggers de base de données

Modèles d’héritage

  • Héritage de table : customizable_entity → entités métier (organization, user, device, asset, inventory, asset_group)

  • Héritage d’ID : ci_base → tables de types de référence

  • Discrimination de type via entity_type_id et discriminateur champs

Relations polymorphes

Certaines tables utilisent des références polymorphes sans contraintes de clé étrangère pour une flexibilité maximale :

  • acl_role_permission.target_entity_id → n’importe quel customizable_entity

  • acl_user_scope.target_entity_id → n’importe quel customizable_entity

  • entity_tag.entity_id → n’importe quel customizable_entity

Ces relations sont validées au niveau de l’application.

Informations supplémentaires

Validation des données

Le repo le schéma applique l’intégrité des données via plusieurs mécanismes :

Contraintes de base de données

  • Contraintes UNIQUE avec support de suppression douce (index partiels WHERE deleted_at IS NULL)

  • Contraintes CHECK (par ex., device_relation assure que master_idslave_id)

  • Contraintes NOT NULL sur les champs requis

  • Valeurs DEFAULT pour les timestamps et les drapeaux booléens

Validation au niveau de l’application

  • Validation du type d’entité pour les références polymorphes

  • Validation de catalogue pour les références de champs personnalisés

  • Validation du type de champ personnalisé

  • Gestion des tableaux pour les champs à valeurs multiples

Optimisation des requêtes

Les tables sont organisées avec des stratégies d'indexation spécifiques :

Index standards :

  • Toutes les clés étrangères disposent d’index dédiés

  • Index temporels sur created_at, updated_at, deleted_at

  • Index composites pour les colonnes fréquemment jointes

Index spécialisés :

  • Index GiST sur les chemins ltree pour les requêtes hiérarchiques

  • Index uniques partiels supportant la suppression douce

  • Index des valeurs de champs personnalisés pour le filtrage et le tri

  • Index des événements d’audit sur le temps + entité pour des recherches efficaces

Considérations de performance :

  • Pool de connexions recommandé (PgBouncer)

  • Maintenance VACUUM régulière pour les grandes tables

  • Partitionnement futur possible pour device table par organization_id

  • Vues matérialisées pour des calculs complexes de contrôle d’accès

Mis à jour

Ce contenu vous a-t-il été utile ?