Couche Bronze
La couche Bronze contient deux schémas de données distincts, chacun couvrant 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és 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és aux données télématiques transmises par les appareils sous surveillance, telles que les localisations, entrées, sorties et événements.
Chaque schéma est optimisé pour son domaine de données et ses modes d'accès spécifiques, 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'utilisation. Ces tables représentent vos entités métier principales, la structure organisationnelle et les données opérationnelles.
Trouvez les détails du schéma raw business data ci-dessous.
Fréquence de mise à jour
Les données de ce schéma sont synchronisées avec la base de données centrale. Les mises à jour se produisent de manière incrémentielle lorsque des modifications surviennent dans la base de données 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 l'ensemble de 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 du 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 :
Entités métier principales
Suivi et surveillance
Gestion des actifs
Localisation et routage
Gestion des tâches et des flux de travail
Règles et automatisation
Statut et catégorisation
Groupes et hiérarchie
Champs personnalisés et entités
Suivi historique
Données de référence et de recherche
raw_telematics_data structure
raw_telematics_data structureLe raw_telematics_data schéma contient trois types de tables principaux qui fonctionnent ensemble pour fournir des données complètes sur les appareils.
Trouvez les détails du schéma des données télématiques brutes ci‑dessous.
Tables clés par catégorie
Chaque table sert un objectif spécifique pour capturer différents aspects de l'information sur l'appareil :
Les données de ce schéma sont ingérées directement depuis les appareils, avec une latence minimale (typiquement en secondes). Le schéma est optimisé pour les séries temporelles en utilisant TimescaleDB pour un stockage et une récupération efficaces.
Informations complé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 garantir que les relations entre les tables restent cohérentes
contraintes NOT NULL garantir que les champs requis ont toujours des valeurs
valeurs DEFAULT fournir un secours 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 basés sur le temps sur
record_added_atLes colonnes de clés étrangères disposent d'index dédiés pour les performances de jointure
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 de données
repo structure de donnéesCe schéma est actuellement en développement. Si vous êtes intéressé par un accès anticipé ou avez des questions sur cette fonctionnalité, veuillez contacter [email protected].
Le repo le schéma fournit un cadre complet pour gérer les structures organisationnelles, les actifs, les appareils et leurs relations dans des environnements multi‑locataires. Construit 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 répond à des scénarios complexes de gestion des données incluant les hiérarchies d'actifs de flotte à travers les niveaux organisationnels, les plateformes SaaS multi‑locataires nécessitant l'isolation 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
Données dans le repo schéma sont synchronisées en temps réel avec les systèmes sources. Les mises à jour se produisent immédiatement au fur et à mesure des changements, les pistes d'audit capturant toutes les modifications pour la conformité et l'analyse historique.
ci_base
ci_baseLe repo 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 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 l'utilisateur en une structure unifiée, offrant cohérence et flexibilité dans l'ensemble du schéma.
Architecture :
Le ci_base table sert de fondation pour toutes les données de référence, en utilisant un champ discriminant pour identifier le type de référence spécifique. Chaque type de référence possède une table correspondante (comme ci_device_type, ci_asset_type) qui partage le même id 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 des sous‑types pour définir leur classification et leur comportement :
organisation→ référenceci_organization_type(qui hérite deci_entity_type→ci_base)utilisateur→ référenceci_user_type(qui hérite deci_entity_type→ci_base)appareil→ 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)inventaire→ référenceci_inventory_type(qui hérite deci_entity_type→ci_base)groupe_d_actifs→ référenceci_asset_group_type(qui hérite deci_entity_type→ci_base)
Catégories de types de référence :
Configuration système
ci_module, ci_country, ci_role
Définir les modules système, les références géographiques et les rôles utilisateur
Définitions de 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
État 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 quelles permissions peuvent être accordées (connecté à ci_module et ci_entity_type)
Relations
ci_device_relation_type
Définir les types de relations entre appareils (maître‑esclave, sauvegarde, etc.)
Catégorisation
ci_tag, ci_catalog_category
Permettre un balisage flexible et une organisation du catalogue
Tables clés par catégorie
Les tables du repo les schémas sont organisés en catégories fonctionnelles. Les descriptions ci‑dessous résument les tables les plus importantes selon leur objectif métier.
Relations de données
Le repo le schéma implémente des modèles de relation 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
Schémas d'héritage
Héritage de table :
customizable_entity→ entités métier (organisation,utilisateur,appareil,asset,inventaire,groupe_d_actifs)Héritage d'ID :
ci_base→ tables de type de référenceDiscrimination de type via
entity_type_idetchampchamps
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 quellecustomizable_entityacl_user_scope.target_entity_id→ n'importe quellecustomizable_entityentity_tag.entity_id→ n'importe quellecustomizable_entity
Ces relations sont validées au niveau de l'application.
Informations complémentaires
Validation des données
Le repo le schéma garantit l'intégrité des données via plusieurs mécanismes :
Contraintes de base de données
Contraintes UNIQUE avec prise en charge de la suppression logique (index partiels WHERE
deleted_atIS NULL)Contraintes CHECK (par ex.,
device_relationassuremaster_id≠slave_id)Contraintes NOT NULL sur les champs obligatoires
Valeurs DEFAULT pour les horodatages et les drapeaux booléens
Validation au niveau de l'application
Validation du type d'entité pour les références polymorphes
Validation du catalogue pour les références de champs personnalisés
Validation du type de champ personnalisé
Gestion des tableaux de champs à valeurs multiples
Optimisation des requêtes
Les tables sont organisées avec des stratégies d'indexation spécifiques :
Indexes standard :
Toutes les clés étrangères ont des index dédiés
Indexes temporels sur
created_at,updated_at,deleted_atIndex composites pour les colonnes fréquemment jointes
Indexes spécialisés :
Indexes GiST sur les chemins ltree pour les requêtes hiérarchiques
Index uniques partiels prenant en charge la suppression logique
Index des valeurs de champs personnalisés pour le filtrage et le tri
Index d'événements d'audit sur le temps + l'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
appareiltable 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 ?