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
raw_business_data structureCe 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.
Consultez les détails du schéma des données métier brutes ci‑dessous.
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
description_parametersLe système inclut des données de référence pour standardiser les valeurs dans la base de données :
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
Structure organisationnelle
users
departments
employees
groups
Comptes utilisateur avec informations de profil
Départements avec données de géolocalisation
Détails des employés et des conducteurs
Groupes d'organisation des traceurs
Objets et dispositifs
devices
models
objects
vehicles
sensor_description
Dispositifs de suivi physiques
Spécifications des modèles de dispositifs
Objets surveillés
Détails et spécifications des véhicules
Détails de configuration des capteurs
Lieux et zones
places
zones
garages
tags
Points d'intérêt avec géolocalisation
Zones de surveillance géofencées
Lieux de service des véhicules
Libellés organisationnels
Données opérationnelles
tasks
forms
checkins
events
statuses
vehicle_service_tasks
Affectation et suivi des tâches
Formulaires de collecte de données
Enregistrements de présence basés sur la localisation
Événements système et notifications
Définitions des statuts
Dossiers de maintenance des véhicules
raw_telematics_data structure
raw_telematics_data structureLe raw_telematics_data schéma contient trois principaux types de tables qui travaillent ensemble pour fournir des données complètes sur les dispositifs.
Trouvez ci‑dessous les détails du schéma des données télématiques brutes.
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
tracking_data_coreObjectif: Données principales de localisation et de mouvement
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
inputsObjectif: Lectures de capteurs provenant des dispositifs
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
statesObjectif: Indicateurs d'état du dispositif et modes opérationnels
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_atLes 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
repo structure des donnéesCe schéma est actuellement en développement. Si vous êtes intéressé par un accès anticipé ou si vous avez des questions concernant cette fonctionnalité, veuillez contacter [email protected].
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.
Trouvez le repo détails du schéma ci‑dessous.
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
ci_baseLe 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érenceci_organization_type(qui hérite deci_entity_type→ci_base)user→ référenceci_user_type(qui hérite deci_entity_type→ci_base)device→ référenceci_device_typeetci_device_status(les deux héritent deci_base)asset→ référenceci_asset_type(qui hérite deci_entity_type→ci_base)inventory→ référenceci_inventory_type(qui hérite deci_entity_type→ci_base)asset_group→ référenceci_asset_group_type(qui hérite deci_entity_type→ci_base)
Catégories de types de référence :
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
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
organizationFinalité : Gestion hiérarchique des organisations
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
userFinalité : Comptes utilisateur et authentification
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
deviceFinalité : Dispositifs de suivi physiques
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
assetFinalité : Actifs physiques ou virtuels
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
inventoryFinalité : Inventaires et enregistrements d’entrepôt
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
asset_groupFinalité : Regroupement d’actifs avec suivi historique
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
custom_field_defFinalité : Définitions et métadonnées des champs personnalisés
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
acl_role_permissionFinalité : Gestion des permissions basée sur les rôles
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
audit_eventFinalité : Journal d’audit unifié pour toutes les modifications du système
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 optionnellesMaintenance 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érenceDiscrimination de type via
entity_type_idetdiscriminateurchamps
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 quelcustomizable_entityacl_user_scope.target_entity_id→ n’importe quelcustomizable_entityentity_tag.entity_id→ n’importe quelcustomizable_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_atIS NULL)Contraintes CHECK (par ex.,
device_relationassure quemaster_id≠slave_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_atIndex 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
devicetable parorganization_idVues matérialisées pour des calculs complexes de contrôle d’accès
Mis à jour
Ce contenu vous a-t-il été utile ?