Couche Bronze
La couche Bronze contient deux schémas de données distincts, chacun servant différents aspects 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 les 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 dispositifs 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 modèles 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'utilisation. 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
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 font de manière incrémentielle lorsque des changements 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 à travers 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
users
Description: Comptes utilisateur contenant des informations de profil, l'affiliation à une entreprise, les paramètres de localisation (fuseau horaire, locale) et des relations hiérarchiques via master_id pour des structures de comptes multi-niveaux
Champs clés
- user_id - Identifiant unique de l'utilisateur
- company_label - Nom de l'entreprise associée à l'utilisateur
- first_name - Nom d'utilisateur
- last_name - Nom de famille de l'utilisateur
- middle_name - Deuxième prénom de l'utilisateur
- locale - Paramètres de langue de l'utilisateur
- timezone_label - Fuseau horaire au format IANA
- master_id - Identifiant utilisateur principal (si l'actuel est un subordonné)
- registration_datetime - Date d'enregistrement dans le système
- birth_date - Date de naissance de l'utilisateur
Relations
Utilisateur parent via master_id, lié à employees, departments, places, tasks via user_id
Remarques spéciales
Entité centrale reliant les données organisationnelles; master_id permet des hiérarchies d'utilisateurs pour des structures de comptes multi-niveaux
employees
Description: Enregistrements d'employés et de conducteurs utilisés pour représenter les personnes travaillant pour l'organisation, incluant les informations personnelles, les détails de permis, les affectations de département, les clés matérielles pour identification iButton/RFID, et les données de localisation avec prise en charge du géorepérage
Champs clés
- employee_id - Identifiant de l'entité employé
- user_id - Identifiant de l'entité utilisateur
- object_id - Identifiant d'entité objet
- department_id - Identifiant du département auquel l'employé est affecté
- first_name - L'attribut first_name de la table employees
- last_name - L'attribut last_name de la table employees
- middle_name - L'attribut middle_name de la table employees
- driver_license_number - Numéro de permis de conduire
- driver_license_categories - Catégories du permis de conduire
- driver_license_issue_date - Date de délivrance du permis de conduire
- driver_license_valid_till - Date jusqu'à laquelle le permis de conduire est valide
- hardware_key - Une clé matérielle
- email - Email de l'employé
- phone_number - Téléphone de l'employé sans le signe "+"
- address - Adresse du lieu
- personnel_number - Numéro de personnel employé/conducteur
- citizen_id_number - Numéro de sécurité sociale
- latitude - Localisation associée à cet employé
- longitude - Localisation associée à cet employé
- radius - Localisation associée à cet employé en mètres
- fuel_consumption - L'attribut fuel_consumption de la table employees
- fuel_cost - L'attribut fuel_cost de la table employees
- is_deleted - L'attribut is_deleted de la table employees
Relations
Liens vers users, departments, objects (tracker assigné), suivi dans driver_history et checkins
Remarques spéciales
La clé matérielle permet l'identification du conducteur via iButton ou RFID ; prend en charge le géorepérage avec latitude, longitude, radius champs
departments
Description: Unités organisationnelles avec données de localisation géographique (latitude, longitude, radius) permettant des analyses basées sur des géorepères pour les rapports au niveau des départements et l'association de localisation des employés
Champs clés
- department_id - Identifiant de l'entité département
- user_id - Identifiant de l'entité utilisateur
- department_label - L'attribut department_label de la table departments
- latitude - Localisation associée à ce département
- longitude - Localisation associée à ce département
- radius - Taille de la géolocalisation en mètres
- address - L'attribut address de la table departments
Relations
Relie les employés à la structure organisationnelle via department_id
Remarques spéciales
Les champs de localisation prennent en charge des analyses basées sur des géorepères pour les rapports au niveau des départements
Suivi et surveillance
devices
Description: Registre des dispositifs de suivi physiques avec identifiants matériels (IMEI), informations de carte SIM, statut de connectivité réseau (force du signal, itinérance, opérateur), et affectations d'état pour la gestion du cycle de vie des dispositifs
Champs clés
- device_id - ID de l'appareil
- owner_id - ID du propriétaire de l'appareil dans le compte où le beacon a été ajouté
- device_imei - IMEI de l'appareil
- phone - Numéro de la carte SIM de l'appareil
- status_listing_id - ID d'état de l'appareil
- network_label - Le nom du réseau auquel la carte SIM est connectée
- signal_level - Intensité du signal de l'appareil
- has_roaming - Indicateur de disponibilité de l'itinérance
- is_sim_blocked - Indicateur de verrouillage de la carte SIM
- created_at - Date et heure de création de l'entrée
Relations
Entité centrale liée à objects, models, sensor_description, counters; owner_id references users.user_id
Remarques spéciales
Toutes les données télématiques dans raw_telematics_data schéma référencent cette table via device_id
objects
Description: Registre central des entités surveillées (véhicules, actifs, personnel) reliant les dispositifs physiques à la structure organisationnelle via client_id et group_id, représentant l'« unité traçable » avec un objet actif par appareil
Champs clés
- object_id - Identifiant d'entité objet
- client_id - Identifiant de l'entité client
- device_id - Identifiant de l'entité appareil
- object_label - Nom de l'objet
- model - Modèle de l'appareil
- group_id - ID de groupe d'entité
- create_datetime - Date et heure de création d'une nouvelle ligne sur le serveur
- is_deleted - L'attribut is_deleted de la table objects
- is_clone - Indicateur de clonage
Relations
Nœud central reliant les appareils aux utilisateurs (client_id), aux détails du véhicule, à l'historique de suivi, aux tâches et aux règles
Remarques spéciales
Représente l'« unité traçable » dans le système ; un objet par appareil en usage actif
models
Description: Registre central des entités surveillées (véhicules, actifs, personnel) reliant les dispositifs physiques à la structure organisationnelle via client_id et group_id, représentant l'« unité traçable » avec un objet actif par appareil
Champs clés
- model_id - Identifiant du modèle d'entité
- model - L'attribut model de la table models
- vendor - Le nom de la société ayant commercialisé le tracker
- alternative_label - L'attribut alternative_label de la table models
- analog_amount - Nombre d'entrées analogiques du tracker
- digital_amount - Nombre d'entrées discrètes du tracker
- outputs_amount - Nombre de sorties discrètes du tracker
- has_battery_level - Détermine si le tracker transmet des relevés de charge de batterie
- has_altitude - Détermine si le tracker transmet l'altitude
- has_phone - Y a-t-il une carte SIM ?
- has_gsm_level - Un tracker peut-il transmettre la force du signal GSM ?
- has_gsm_name - Le tracker peut-il transmettre le nom du réseau GSM ou le code opérateur (MCC + MNC) ?
- has_gsm_roaming - Le tracker peut-il transmettre l'état d'itinérance ?
- has_detach_button - Le tracker dispose-t-il d'un capteur de détachement ?
- type_output_control - Profil de contrôle des sorties du tracker
- type_special_control - Contient des paramètres spécialisés et des modules fonctionnels pour des modèles d'appareils individuels, tels que le mode conduite dangereuse (hbm_telfm) pour le matériel Teltonika
- is_clone - Le modèle est-il un clone d'un autre modèle ?
Contenu
Les indicateurs de capacité booléens indiquent quels champs de données sont disponibles pour ce type d'appareil
Remarques spéciales
Utilisez les indicateurs de capacité pour déterminer les capteurs et entrées valides lors de l'interrogation des données télématiques
sensor_description
Description: Configuration complète des capteurs reliant les entrées de l'appareil à la logique métier, y compris les mappages d'entrée, les unités de mesure, les facteurs de conversion (multiplicateur/diviseur), les tables d'étalonnage pour les capteurs de carburant, les seuils de précision et la logique de regroupement pour les lectures agrégées des capteurs
Champs clés
- sensor_id - Identifiant de l'entité capteur
- device_id - Identifiant de l'entité appareil
- sensor_label - Nom du capteur pour l'interface utilisateur
- input_label - Le nom du champ du message (attribut) à partir duquel proviennent les données du capteur. Si égal à "input_status", il s'agit d'un capteur discret
- sensor_type - Type de capteur
- units_type - Unités de mesure
- multiplier - Multiplicateur - le nombre par lequel multiplier la valeur du champ. Pour capteurs de mesure uniquement
- divider - Diviseur - le nombre par lequel diviser la valeur du champ. Pour capteurs de mesure uniquement
- accuracy - Un pourcentage spécifié pour calculer l'erreur absolue du volume du réservoir. Cette erreur est utilisée pour déterminer quand des remplissages ou des vidanges se produisent. Utilisé uniquement pour les capteurs de carburant
- calibration_data - L'attribut calibration_data de la table sensor_description
- input_id - Numéro d'entrée pour capteur discret
- group_id - Les capteurs du même type ayant le même group_id et source_id sont considérés appartenir au même groupe. Leurs données sont additionnées ou moyennées, selon la valeur de group_type. Ceci est requis pour les capteurs agrégés. Utilisé pour les capteurs de mesure
- group_type - 0 - sommer les valeurs des capteurs au sein d'un groupe, 1 - faire la moyenne
- sensor_units - Nom d'unité saisi par l'utilisateur si units_type=0 (personnalisé)
- parameters - Objet optionnel avec paramètres supplémentaires parent_ids - tableau optionnel de parent_ids pour capteur composite. volume - double. Optionnel. Volume pour capteur composite. parent_ids - optionnel. tableau d'entiers. Tableau de parent_ids pour capteur composite. volume - optionnel. Double. Volume pour capteur composite. min - optionnel. Double. Valeur brute minimale acceptable pour un capteur. max - optionnel. Double. Valeur brute maximale acceptable pour un capteur. max_lowering_by_time - optionnel. Double. Valeur maximale légale de diminution par heure. max_lowering_by_mileage - optionnel. Double. Valeur maximale légale de diminution par 100 km. ignore_drains_in_move - optionnel. Booléen. Par défaut false. Si vrai, les vidanges de carburant ne seront pas détectées pendant le déplacement. ignore_refuels_in_move - optionnel. Booléen. Par défaut false. Si vrai, les remplissages ne seront pas détectés pendant le déplacement. refuel_gap_minutes - optionnel. Entier. Par défaut 5. Le temps en minutes après le début du mouvement pendant lequel les remplissages seront détectés lors du mouvement. custom_field_name - optionnel. Booléen. Par défaut false. Le paramètre détermine si le champ input_name est une valeur personnalisée saisie par l'utilisateur. Cela n'a de sens que si le modèle de tracker possède la fonctionnalité has_custom_fields
Relations
Relie les entrées de l'appareil (depuis raw_telematics_data.inputs) à la logique métier via device_id et input_label matching
Remarques spéciales
calibration_data (JSONB) stocke des tables d'étalonnage spécifiques aux capteurs pour les capteurs de niveau de carburant ; multiplier et divider convertir les valeurs brutes en unités
Gestion des actifs
vehicles
Description: Registre complet des véhicules contenant les spécifications (dimensions, poids, capacité), la documentation (VIN, immatriculation, assurance), les paramètres opérationnels (consommation de carburant, volume du réservoir) et l'affectation actuelle du tracker via object_id pour la gestion de flotte et le suivi de conformité
Champs clés
- vehicle_id - Identifiant de l'entité véhicule
- user_id - Identifiant de l'entité utilisateur
- object_id - Identifiant d'entité objet
- garage_id - Identifiant de l'entité garage
- vehicle_label - L'attribut vehicle_label de la table vehicles
- registration_number - Numéro d'immatriculation / plaque d'immatriculation d'un véhicule
- vin - L'attribut vin de la table vehicles
- manufacture_year - L'attribut manufacture_year de la table vehicles
- fuel_type - L'attribut fuel_type de la table vehicles
- fuel_cost - L'attribut fuel_cost de la table vehicles
- fuel_tank_volume - L'attribut fuel_tank_volume de la table vehicles
- max_speed - L'attribut max_speed de la table vehicles
- model - L'attribut model de la table vehicles
- color - L'attribut color de la table vehicles
- trailer - L'attribut trailer de la table vehicles
- additional_info - L'attribut additional_info de la table vehicles
- vehicle_type - L'attribut vehicle_type de la table vehicles
- vehicle_subtype - L'attribut vehicle_subtype de la table vehicles
- vehicle_status_id - Identifiant de l'entité statut du véhicule
- chassis_number - L'attribut chassis_number de la table vehicles
- frame_number - L'attribut frame_number de la table vehicles
- trailer_reg_number - L'attribut trailer_reg_number de la table vehicles
- payload_weight - L'attribut payload_weight de la table vehicles
- payload_height - L'attribut payload_height de la table vehicles
- payload_length - L'attribut payload_length de la table vehicles
- payload_width - L'attribut payload_width de la table vehicles
- passenger_capacity - Nombre maximal de passagers
- gross_weight - L'attribut gross_weight de la table vehicles
- standard_fuel_consumption - Consommation moyenne normale de carburant en litres aux 100 km
- fuel_grade - L'attribut fuel_grade de la table vehicles
- wheel_arrangement - L'attribut wheel_arrangement de la table vehicles
- tyre_size - Taille du véhicule : dimensions et taille des roues
- tyres_number - Nombre de roues
- liability_insurance_policy_number - L'attribut liability_insurance_policy_number de la table vehicles
- liability_insurance_valid_till - Date jusqu'à laquelle l'assurance responsabilité est valide
- free_insurance_policy_number - L'attribut free_insurance_policy_number de la table vehicles
- free_insurance_valid_till_date - Date jusqu'à laquelle l'assurance gratuite est valide
Relations
Liens vers objects (tracker actuel), garages (lieu de service), vehicle_service_tasks; suivi dans vehicle_trackers_history
Remarques spéciales
Les champs de dimension physique (payload_length, payload_width, payload_height, gross_weight) prennent en charge les analyses de planification de charge ; les dates d'assurance permettent le suivi de conformité
garages
Description: Lieux de service et d'entretien avec coordonnées géographiques (latitude, longitude, radius), informations de contact pour mécaniciens et répartiteurs, permettant la détection des visites de service basées sur des géorepères et l'analyse de proximité
Champs clés
- garage_id - Identifiant de l'entité garage
- user_id - Identifiant de l'entité utilisateur
- latitude - Objet de localisation
- longitude - Objet de localisation
- radius - Taille de la géolocalisation en mètres
- address - Objet de localisation
- organization_label - ID du dépôt
- mechanic_name - Nom du mécanicien
- dispatcher_name - Nom du répartiteur
Relations
Référencé par vehicles.garage_id pour l'affectation du lieu de service
Remarques spéciales
Les champs de localisation permettent la détection des visites de service basées sur des géorepères et l'analyse de proximité
vehicle_service_tasks
Description: Suivi du planning de maintenance et de l'historique des services avec plusieurs types de déclencheurs (basés sur la date, le kilométrage, les heures moteur), intervalles de tâches récurrentes, notifications multi-canaux (email, SMS, push) et distinction entre événements de maintenance planifiés (is_repeat) et non planifiés
Champs clés
- service_task_id - Identifiant de l'entité tâche de service
- vehicle_id - Identifiant de l'entité véhicule
- description - L'attribut description de la table vehicle_service_tasks
- status - La valeur d'état de l'attribut status
- cost - L'attribut cost de la table vehicle_service_tasks
- start_date - La date et l'heure associées à l'attribut start_date
- end_date - La date et l'heure associées à l'attribut end_date
- completion_date - La date et l'heure associées à l'attribut completion_date
- predicted_datetime - La date et l'heure associées à l'attribut predicted_datetime
- mileage_limit - L'attribut mileage_limit de la table vehicle_service_tasks
- engine_hours_limit - L'attribut engine_hours_limit de la table vehicle_service_tasks
- start_mileage - L'attribut start_mileage de la table vehicle_service_tasks
- start_engine_hours - L'attribut start_engine_hours de la table vehicle_service_tasks
- mileage_notification_interval - L'attribut mileage_notification_interval de la table vehicle_service_tasks
- engine_hours_notification_interval - L'attribut engine_hours_notification_interval de la table vehicle_service_tasks
- date_notification_interval - Conversion d'un entier N en N jours
- mileage_repeat_interval - L'attribut mileage_repeat_interval de la table vehicle_service_tasks
- engine_hours_repeat_interval - L'attribut engine_hours_repeat_interval de la table vehicle_service_tasks
- date_repeat_interval - Conversion d'un entier N en N jours
- notification_emails - L'attribut notification_emails de la table vehicle_service_tasks
- notification_sms_phone_numbers - L'attribut notification_sms_phone_numbers de la table vehicle_service_tasks
- is_notification_push_enabled - L'attribut is_notification_push_enabled de la table vehicle_service_tasks
- completion_mileage - L'attribut completion_mileage de la table vehicle_service_tasks
- completion_engine_hours - L'attribut completion_engine_hours de la table vehicle_service_tasks
- is_repeat - L'attribut is_repeat de la table vehicle_service_tasks
- is_unplanned - L'attribut is_unplanned de la table vehicle_service_tasks
- comment - L'attribut comment de la table vehicle_service_tasks
Contenu
Prend en charge trois types de déclencheurs : basés sur la date, le kilométrage, les heures moteur ; les paramètres de notification pour email, SMS, push
Remarques spéciales
is_repeat et les champs d'intervalle permettent des plannings de maintenance récurrents ; is_unplanned fait la distinction entre maintenance planifiée et réactive
Localisation et routage
zones
Description: Zones géorepérées définissant des périmètres virtuels utilisant des cercles ou des polygones pour surveiller les événements d'entrée et de sortie des véhicules/actifs, prenant en charge l'automatisation basée sur des règles et l'analyse de localisation avec codage couleur pour différenciation visuelle
Champs clés
- zone_id - Identifiant de l'entité zone
- client_id - Identifiant de l'entité client
- zone_label - L'attribut zone_label de la table zones
- zone_type - L'attribut zone_type de la table zones
- latitude - Objet optionnel, la boîte englobante qui peut contenir entièrement le résultat retourné
- longitude - Objet optionnel, la boîte englobante qui peut contenir entièrement le résultat retourné
- circle_center_latitude - L'attribut circle_center_latitude de la table zones
- circle_center_longitude - L'attribut circle_center_longitude de la table zones
- radius - Taille de la géolocalisation en mètres
- address - L'attribut address de la table zones
- color - L'attribut color de la table zones
Contenu
Les types de zone incluent circle, polygon (défini via geofence_points), et des classifications d'aires spéciales
Relations
Référencé par rules2zones, users2zones; sommets du polygone stockés dans geofence_points
Remarques spéciales
Les fonctions PostGIS peuvent être utilisées pour vérifier l'appartenance point-dans-polygone pour des analyses de géorepérage complexes
places
Description: Points d'intérêt avec coordonnées géographiques, définitions de rayon et prise en charge extensible des champs personnalisés pour stocker les informations de contact client et les données métier spécifiques, permettant l'intégration CRM/ERP via external_id et les rapports basés sur la localisation
Champs clés
- place_id - Identifiant de l'entité Place
- user_id - Identifiant de l'entité utilisateur
- place_label - L'attribut place_label de la table places
- latitude - Objet de localisation
- longitude - Objet de localisation
- radius - Taille de la géolocalisation en mètres
- address - L'attribut address de la table places
- description - L'attribut description de la table places
- external_id - ID pour l'intégration avec des systèmes externes (CRM)
- custom_fields - Champs supplémentaires
- assigned_datetime - Date et heure d'affectation du point d'intérêt à l'utilisateur
Relations
Étendu avec les valeurs des champs personnalisés via places_text_fields, places_decimal_fields, places_bigint_fields, places_longtext_fields, places_linked_entity_fields
Remarques spéciales
custom_fields JSONB fournit un accès rapide ; les tables associées permettent le filtrage et le tri sur les attributs personnalisés
geofence_points
Description: Coordonnées de sommets ordonnées (le champ number détermine la séquence) définissant les limites du polygone pour des formes de géorepérage complexes, permettant des périmètres géographiques précis au-delà des zones circulaires simples, utilisé avec PostGIS ST_MakePolygon pour des opérations géométriques
Champs clés
- zone_id - Un ID de la zone auquel ce formulaire est rattaché
- number - Numéro de série
- latitude - Emplacement
- longitude - Emplacement
Relations
Enregistrements multiples par zone_id définir les limites du polygone; number le champ détermine l'ordre des sommets
Remarques spéciales
Interroger avec ORDER BY number pour reconstruire le chemin du polygone ; utiliser avec PostGIS ST_MakePolygon pour des opérations géométriques
Gestion des tâches et des flux de travail
tasks
Description: Affectations d'ordres de travail avec validation de localisation (latitude, longitude, radius), fenêtres temporelles (time_from, time_to), exigences de durée de visite (stay_duration_minutes, arrival_duration_minutes), structure hiérarchique via parent_task_id, et suivi du statut pour la gestion des services sur le terrain et les opérations de livraison
Champs clés
- task_id - Identifiant de l'entité Task
- user_id - Identifiant de l'entité utilisateur
- object_id - Identifiant d'entité objet
- parent_task_id - Identifiant de l'entité tâche parente
- task_label - L'attribut task_label de la table tasks
- status - La valeur d'état de l'attribut status
- task_type - Type de tâche : task, route ou checkpoint
- latitude - L'attribut latitude de la table tasks
- longitude - L'attribut longitude de la table tasks
- radius - Taille de la géolocalisation en mètres
- arrival_datetime - Quand le traceur arrive dans la zone de la tâche. IGNORÉ lors de la création/mise à jour
- created_at - L'attribut created_at de la table tasks
- status_change_datetime - Date et heure de mise à jour de la tâche
- time_from - La date et l'heure associées à l'attribut time_from
- time_to - La date et l'heure associées à l'attribut time_to
- stay_duration - L'attribut stay_duration de la table tasks
- stay_duration_minutes - Durée de visite. Le temps qu'un travailleur mobile doit passer sur le site de la mission pour compléter la tâche avec succès. Plusieurs visites sont cumulatives
- arrival_duration_minutes - Ignorer les visites aléatoires plus courtes que la durée spécifiée. Lors du calcul de la durée minimale, les visites plus courtes que la durée spécifiée seront ignorées
- max_delay_minuts - Retard acceptable. La durée maximale qu'un employé peut avoir de retard. Toute tâche complétée pendant ce temps sera marquée comme « late »
- is_stay_control_enabled - L'attribut is_stay_control_enabled de la table tasks
- address - L'attribut address de la table tasks
- description - L'attribut description de la table tasks
- custom_fields - L'attribut custom_fields de la table tasks
- external_id - Identifiant d'entité externe
- order_sort - L'attribut order_sort de la table tasks
- created_by - Source de la tâche créée
Contenu
Prend en charge les tâches hiérarchiques via parent_task_id; fenêtres temporelles définies par time_from/time_to; validation de géorepérage avec localisation et rayon
Relations
Liens vers forms (collecte de données), task_history (changements de statut), objects (tracker affecté)
Remarques spéciales
stay_duration et arrival_duration_minutes permettre la surveillance de conformité pour les tâches de livraison et de service
forms
Description: Formulaires de collecte de données configurables pour capturer des informations structurées lors de l'exécution d'une tâche ou des pointages via l'application mobile, avec champs et valeurs stockés en JSON, validation optionnelle de localisation (is_submission_in_zone), et exigences de soumission obligatoires lorsqu'ils sont attachés aux tâches
Champs clés
- form_id - Identifiant de l'entité Form
- task_id - Un ID de la tâche auquel ce formulaire est rattaché
- object_id - Identifiant d'entité objet
- form_label - Libellé de formulaire défini par l'utilisateur
- champs - Si true, le formulaire ne peut être soumis que dans la zone de la tâche
- values - Une map avec les IDs de champs comme clés et des objets field_value comme valeurs. Clé utilisée pour lier le champ et sa valeur correspondante
- submitted_at - Date à laquelle les valeurs du formulaire ont été soumises pour la dernière fois
- submission_latitude - Emplacement auquel les valeurs du formulaire ont été soumises pour la dernière fois
- submission_longitude - Emplacement auquel les valeurs du formulaire ont été soumises pour la dernière fois
- submission_address - Emplacement auquel les valeurs du formulaire ont été soumises pour la dernière fois
- is_submission_in_zone - Si true, le formulaire ne peut être soumis que dans la zone de la tâche
- description - Date de création de ce formulaire (ou date à laquelle il a été attaché à la tâche)
- created_at - Date de création de ce formulaire (ou date à laquelle il a été attaché à la tâche)
Contenu
champs définit la structure du formulaire (JSON) ; values contient les données soumises (JSON)
Relations
Liens vers tasks (bon de travail associé), objects (soumetteur), référencé dans checkins
Remarques spéciales
Indicateur de validation de localisation is_submission_in_zone active les règles de soumission de formulaire basées sur le géorepérage
checkins
Description: Enregistrements de présence et d'activité basés sur la localisation soumis via l'application mobile, suivant les heures d'arrivée prévues vs réelles (planned_datetime vs actual_datetime) avec coordonnées géographiques et mesures de précision de localisation (radius) pour les rapports de ponctualité
Champs clés
- checkin_id - Identifiant de l'entité Checkin
- employee_id - L'identifiant de l'entité employé est également l'identifiant pour les conducteurs
- object_id - Appareil de l'employé
- form_id - Identifiant de l'entité Form
- user_id - Utilisateur employé
- planned_datetime - Heure de l'appareil lorsque le check-in a été effectué
- actual_datetime - Heure serveur lorsque la requête/le message a été traité
- latitude - Emplacement auquel les check-ins ont été soumis
- longitude - Emplacement auquel les check-ins ont été soumis
- radius - Erreur de positionnement en mètres
- address - Adresse du check-in
- comment - L'attribut comment de la table checkins
Relations
Relie les employés aux formulaires et aux emplacements ; suit l'écart par rapport au planning prévu
Remarques spéciales
Variance de temps entre planned_datetime et actual_datetime permet les rapports de ponctualité ; le radius définit la tolérance d'emplacement acceptable
task_history
Description: Traçabilité complète des événements du cycle de vie des tâches capturant tous les changements de statut, affectations, mises à jour et modifications sur le terrain avec horodatages (event_datetime), attribution d'utilisateur, et types d'activité (create, update, assign, status_change) stockés dans le champ payload pour l'analyse de conformité et de flux de travail
Champs clés
- task_history_id - Identifiant de l'entité Task history
- task_id - Identifiant de l'entité Task
- user_id - Identifiant de l'entité utilisateur
- activity - Opération qui a eu lieu. Peut être « create », « update », « assign » ou « status_change »
- event_datetime - Date et heure de l'événement
- payload - Dépend de l'opération. Contient typiquement les champs qui ont été modifiés lors de l'opération
Contenu
Types d'activité définis dans description_parameters; payload stoke des détails spécifiques à l'événement (texte)
Remarques spéciales
Essentiel pour l'analyse de l'achèvement des tâches, les rapports de transition de statut et le suivi de l'activité utilisateur
Règles et automatisation
rules
Description: Règles de détection d'événements avec conditions de déclenchement configurables (excès de vitesse, violations de géorepérage, seuils de capteurs, temps d'inactivité) stockées dans parameters (JSONB), et paramètres de notification multi-canaux (alert_email, alert_sms, alert_phone, is_push_enabled) pour la surveillance automatisée et les alertes basées sur les données du dispositif et du serveur
Champs clés
- rule_id - Identifiant de l'entité Rule
- object_id - Identifiant d'entité objet
- client_id - Identifiant de l'entité client
- event_type - L'attribut event_type de la table rules
- event_label - L'attribut event_label de la table rules
- event_group - L'attribut event_group de la table rules
- description - L'attribut description de la table rules
- parameters - Paramètres d'événement. Pour plus de détails sur les paramètres disponibles, voir Navixy API docs.
- alert_email - Mail pour les notifications
- alert_sms - Numéros de téléphone pour les notifications SMS
- alert_phone - Téléphones pour les appels vocaux
- is_push_enabled - Si true, les notifications push sont disponibles
- created_at - L'attribut created_at de la table rules
- is_deleted - L'attribut is_deleted de la table rules
- maximum - Limites appliquées à diverses règles. Par exemple, pour la règle de temps d'inactivité avec le moteur en marche en minutes
- event_comment1 - L'attribut event_comment1 de la table rules
- event_comment2 - L'attribut event_comment2 de la table rules
Contenu
Les paramètres de règle (JSONB) définissent les conditions de déclenchement ; prend en charge les notifications par email, SMS, téléphone et push
Relations
Liens vers les objets via rules2objects, zones via rules2zones
Remarques spéciales
event_type définit un scénario de surveillance spécifique (excès de vitesse, violation de géorepérage, seuil de capteur) ; maximum le champ permet l'agrégation d'événements pour les alertes basées sur des seuils
rules2objects
Description: Relation plusieurs-à-plusieurs liant les règles aux objets surveillés avec personnalisation des paramètres par objet via object_params (JSONB), autorisant différentes valeurs de seuil (par ex., limites de vitesse) pour chaque véhicule ou actif dans la même règle
Champs clés
- rule_id - Identifiant de l'entité Rule
- object_id - Identifiant d'entité objet
- param_group_number - L'attribut param_group_number de la table rules2objects
- object_params - L'attribut object_params de la table rules2objects
Contenu
object_params (JSONB) permet la personnalisation des règles par objet (par ex., différentes limites de vitesse par véhicule)
Remarques spéciales
La relation plusieurs-à-plusieurs permet à une règle de surveiller plusieurs objets avec des paramètres différents
rules2zones
Description: Relation plusieurs-à-plusieurs associant les règles aux zones géorepérées, permettant à une seule règle de surveiller des événements d'entrée/sortie sur plusieurs zones géographiques pour des scénarios de surveillance spatiale complexes
Champs clés
- rule_id - Identifiant de l'entité Rule
- zone_id - Identifiant de l'entité Zone
Remarques spéciales
La relation plusieurs-à-plusieurs permet la surveillance multi-zone pour une seule règle (par ex., alerter lorsqu'on entre dans n'importe laquelle de plusieurs zones restreintes)
Statut et catégorisation
statuses
Description: Définitions de statut personnalisées au sein des listes de statuts, y compris les propriétés d'affichage (color pour l'affichage web, order_sort pour le positionnement) utilisées pour représenter les états de travail des dispositifs ou des employés avec prise en charge de la suppression logique via le drapeau is_deleted
Champs clés
- status_id - Identifiant de l'entité status
- listing_id - Identifiant de l'entité listing
- status_label - Valeur du statut de l'attribut status_label
- color - Couleur utilisée pour l'affichage sur le site web
- order_sort - Position de tri au sein de la liste de statuts
- is_deleted - L'attribut is_deleted de la table statuses
Relations
Groupes de statuts organisés par listing_id (références status_listings); utilisé dans status_history
Remarques spéciales
order_sort définit la séquence d'affichage ; color permet la différenciation visuelle dans les rapports
status_listings
Description: Définitions d'ensembles de statuts contrôlant quelles valeurs de statut sont disponibles pour les dispositifs ou les employés, avec des drapeaux d'autorisation (is_supervisor_controlled, is_employee_controlled) déterminant si les superviseurs, les employés ou les deux peuvent changer les valeurs de statut
Champs clés
- status_listing_id - Identifiant de l'entité Status listing
- user_id - Identifiant de l'entité utilisateur
- status_listing_label - Valeur du statut de l'attribut status_listing_label
- is_supervisor_controlled - Si true, les superviseurs peuvent changer le statut de travail, p.ex. en utilisant l'application de surveillance mobile
- is_employee_controlled - Si true, les employés peuvent changer leur propre statut de travail, p.ex. en utilisant l'application de suivi mobile
- is_deleted - L'attribut is_deleted de la table status_listings
Relations
Référencé par devices.status_listing_id et statuses.listing_id
Remarques spéciales
Les drapeaux de contrôle déterminent qui peut changer les statuts : superviseur uniquement, autoservice employé, ou les deux
status_history
Description: Traçabilité de toutes les transitions de statut des dispositifs avec horodatages (changed_datetime sur l'appareil, server_datetime côté serveur), attribution d'utilisateur (updated_by), et capture de localisation (latitude, longitude, address) permettant l'analyse géographique des changements de statut et le reporting des emplacements de début/fin de journée de travail
Champs clés
- status_history_id - Identifiant de l'entité status history
- device_id - Identifiant de l'entité appareil
- old_status_id - Identifiant de l'entité ancien statut
- new_status_id - Identifiant de l'entité nouveau statut
- updated_by - La date et l'heure associées à l'attribut updated_by
- changed_datetime - Date et heure d'attribution d'un nouveau statut sur l'appareil
- server_datetime - Date et heure d'attribution du nouveau statut côté serveur
- latitude - Localisation des dispositifs lors des changements de statut
- longitude - Localisation des dispositifs lors des changements de statut
- address - Localisation des dispositifs lors des changements de statut
Relations
Liens vers devices, statuses (ancien et nouveau), description_parameters (pour updated_by role)
Remarques spéciales
La capture de localisation permet l'analyse géographique des transitions de statut ; utile pour le reporting des emplacements de début/fin de journée
tags
Description: Étiquettes de catégorisation définies par l'utilisateur avec codage couleur permettant un filtrage et une recherche rapide à travers plusieurs types d'entités (places, geofences, employees, tasks, trackers, vehicles) pour une organisation flexible
Champs clés
- tag_id - ID de l'entité tag
- user_id - Identifiant de l'entité utilisateur
- tag_label - L'attribut tag_label de la table tags
- color - L'attribut color de la table tags
Relations
Appliqué aux entités via tag_links; portée définie par l'utilisateur
Remarques spéciales
Système de catégorisation flexible supportant plusieurs tags par entité
tag_links
Description: Table de relation polymorphe associant des tags à n'importe quel type d'entité via entity_type et entity_id, avec un champ ordinal pour la gestion de l'ordre d'affichage, permettant le marquage multi-entités flexible
Champs clés
- tag_id - ID de l'entité tag
- entity_type - L'attribut entity_type de la table tag_links
- entity_id - Identifiant d'entité
- ordinal - L'attribut ordinal de la table tag_links
Contenu
entity_type identifie la table (vehicle, employee, task, etc.) ; ordinal définit l'ordre d'affichage
Remarques spéciales
La relation polymorphe permet le marquage à travers différents types d'entités
Groupes et hiérarchie
groups
Description: Structure de regroupement organisationnel pour les traceurs permettant une organisation visuelle dans l'interface utilisateur avec des couleurs personnalisables (group_color) et une gestion hiérarchique de type dossier, servant actuellement une fonction purement visuelle
Champs clés
- group_id - Groupe de traceurs (lié par objects.group_id). La division en groupes peut être vue dans la liste des balises, par exemple
- client_id - Identifiant de l'entité client
- group_label - Titre de groupe spécifié par l'utilisateur, 1 à 60 caractères imprimables, p.ex. « Employees »
- group_color - Couleur du groupe au format web (sans #), p.ex. « FF6DDC ». Détermine la couleur des marqueurs de traceur sur la carte
Relations
Référencé par objects.group_id; propriété du client via client_id (références users)
Remarques spéciales
Permet une organisation de type dossier des entités de surveillance pour les rapports et les permissions
groups_objects
Description: Relation plusieurs-à-plusieurs entre groups et objects utilisant une clé primaire composite (groups_client_id, objects_client_id), permettant aux objets d'appartenir simultanément à plusieurs groupes pour des structures organisationnelles flexibles
Champs clés
- groups_client_id - Identifiant de l'entité client pour les groupes
- objects_client_id - Identifiant de l'entité client pour les objets
Remarques spéciales
Permet aux objets d'appartenir simultanément à plusieurs groupes ; interroger avec les deux client_id valeurs pour l'appartenance au groupe
Champs personnalisés et entités
entities
Description: Registre des types d'entités définissant quelles entités métier prennent en charge les champs personnalisés et la structure de disposition de leurs champs (sections, field_order) stockée dans entity_label (JSONB), permettant l'extension dynamique du schéma à travers places, tasks et autres entités sans modifications de la base de données
Champs clés
- entity_id - Identifiant d'entité
- user_id - Identifiant de l'entité utilisateur
- entity_label - id - int. Identifiant de l'entité. type - enum. Actuellement, seul « place » est pris en charge. layout - objet décrivant la disposition des champs pour l'entité. sections - tableau d'objets. Chaque section peut contenir un ou plusieurs champs. Au moins une section doit exister dans une disposition. label - chaîne. Nom de la section. field_order - tableau de chaînes. Champs intégrés et IDs des champs personnalisés (en tant que chaînes)
- builtin_type - L'attribut builtin_type de la table entities
Relations
Référencé par custom_fields pour définir quels champs personnalisés s'appliquent à quels types d'entités
Remarques spéciales
builtin_type liens vers description_parameters pour les classifications d'entités définies par le système
custom_fields
Description: Définitions de champs personnalisés permettant l'extension dynamique du schéma pour les types d'entités, avec types de champ configurables (custom_field_type), règles de validation et options dans parameters (JSONB), et drapeaux d'obligation (is_required) pour une capture de données flexible sur places, tasks et autres entités
Champs clés
- custom_field_id - Identifiant de l'entité champ personnalisé
- entity_id - Identifiant d'entité
- custom_field_label - Nom du champ
- custom_field_type - Type de données du champ
- description - Description du champ
- is_required - Est-ce requis ou non ?
- parameters - Paramètres du champ
Contenu
parameters (JSONB) stocke la configuration spécifique au type de champ (règles de validation, options de liste déroulante, etc.)
Relations
Définit les attributs personnalisés disponibles pour les entités ; le type de champ se lie à description_parameters
Remarques spéciales
Permet l'extension dynamique du schéma sans modifications de la base de données ; utilisé largement dans places et tasks
Suivi historique
driver_history
Description: Traçabilité complète des affectations employé-vers-véhicule au fil du temps suivant les transitions d'old_employee_id vers new_employee_id avec horodatages (changed_datetime, server_datetime), données de localisation (latitude, longitude, address), informations sur la clé matérielle et attribution utilisateur (updated_by) permettant des analyses spécifiques au conducteur lorsque les conducteurs changent de véhicule
Champs clés
- driver_history_id - Identifiant de l'entité driver history
- object_id - Identifiant d'entité objet
- old_employee_id - Identifiant de l'entité ancien employé
- new_employee_id - Identifiant de l'entité nouvel employé
- hardware_key - L'attribut hardware_key de la table driver_history
- changed_datetime - Date et heure des modifications apportées à l'appareil
- server_datetime - Date et heure des modifications effectuées sur le serveur
- updated_by - La date et l'heure associées à l'attribut updated_by
- latitude - L'attribut latitude de la table driver_history
- longitude - L'attribut longitude de la table driver_history
- address - L'attribut address de la table driver_history
Relations
Suit les affectations des conducteurs aux véhicules au fil du temps ; liens vers employees et objects
Remarques spéciales
Essentiel pour les rapports spécifiques au conducteur lorsque les conducteurs changent de véhicule ; la capture de localisation permet l'analyse des lieux de changement d'affectation
vehicle_trackers_history
Description: Traçabilité indiquant quels appareils GPS (object_id) ont été installés dans quels véhicules (vehicle_id) au fil du temps avec horodatages de changement (changed_datetime), permettant une attribution précise des données historiques et le calcul du kilométrage lorsque les traceurs sont déplacés entre véhicules
Champs clés
- vehicle_tracker_history_id - Identifiant de l'entité vehicle tracker history
- vehicle_id - Identifiant de l'entité véhicule
- object_id - Identifiant d'entité objet
- changed_datetime - La date et l'heure associées à l'attribut changed_datetime
Relations
Suit quel appareil GPS a été installé dans quel véhicule au fil du temps
Remarques spéciales
Critique pour l'analyse des données historiques lorsque les traceurs sont déplacés entre véhicules ; permet une attribution précise du kilométrage et de l'utilisation
Données de référence et de consultation
description_parameters
Description: Données de référence à l'échelle du système fournissant des libellés lisibles par l'humain (description) pour des valeurs entières énumérées (key) utilisées dans toute la base de données, organisées par le champ type (p.ex., task_status, fuel_type, counter_type, entity_classification) pour une traduction cohérente des valeurs dans les rapports et l'interface utilisateur
Champs clés
- key - Valeur possible dans l'attribut
- type - Un attribut composite consistant du nom de la table suivi d'un underscore et du nom d'un attribut dans la table
- description - Valeur implicite d'un attribut
Contenu
Fournit des libellés lisibles pour les valeurs codées dans toute la base de données (statut de tâche, types de carburant, types de compteur, etc.)
Relations
Référencé via des clés étrangères depuis plusieurs tables pour une catégorisation standardisée
Remarques spéciales
Essentiel pour traduire des codes entiers en valeurs lisibles dans les rapports ; type groupes de champs liés aux énumérations
counters
Description: Configurations d'odomètre et de compteur d'heures moteur reliant les lectures de capteurs de l'appareil (sensor_id) aux mesures de distance ou de temps avec coefficients multiplicateurs pour la conversion d'unités (km, miles, heures) et counter_type depuis description_parameters définissant le type de mesure
Champs clés
- counter_id - ID interne
- device_id - Identifiant de l'entité appareil
- counter_type - Type de compteur
- sensor_id - Identifiant de l'entité capteur
- multiplier - Coefficient de conversion des valeurs en l'une des métriques (km, l, etc.)
Relations
Relie les dispositifs aux lectures de capteurs qui représentent des compteurs de distance ou de temps
Remarques spéciales
multiplier convertit les impulsions du capteur en unités réelles (km, miles, heures) ; counter_type from description_parameters définit le type de mesure
device_output_name
Description: Libellés personnalisés pour les canaux de sortie d'appareil mappant les identifiants numériques de sortie (number) à des noms définis par l'utilisateur (label) tels que "Door Lock" ou "Engine Block" pour des rapports lisibles et l'analyse des commandes et états de sortie de l'appareil
Champs clés
- device_id - Identifiant de l'entité appareil
- number - L'attribut number de la table device_output_name
- label - L'attribut label de la table device_output_name
Contenu
Mappe les numéros de canal de sortie à des noms définis par l'utilisateur (par ex., "Door Lock", "Engine Block")
Remarques spéciales
Permet des rapports lisibles lors de l'analyse des commandes et états de sortie des appareils
raw_telematics_data structure
raw_telematics_data structureLe raw_telematics_data schéma contient trois types de tables primaires qui travaillent ensemble pour fournir des données complètes sur les appareils.
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.
Tables clés par catégorie
Chaque table sert un objectif spécifique dans la capture de différents aspects des informations de l'appareil :
tracking_data_core
But: 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 spéciales
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
But: Lectures de capteurs provenant des appareils
Champs clés
input_id, device_id, device_time, sensor_name, valeur
Contenu
Lectures analogiques (niveau de carburant, température, tension), valeurs calculées (régime moteur)
Relations
états
But: Indicateurs d'état de l'appareil et modes de fonctionnement
Champs clés
state_id, device_id, device_time, state_name, valeur
Contenu
Indicateurs de mode de fonctionnement (en service, au ralenti, éteint), états des composants (allumage, portes)
Format de la 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 appareils, avec une latence minimale (typiquement des secondes). Le schéma est optimisé pour les données en série temporelle 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 explicitement fournies
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 les performances des jointures
Les combinaisons de colonnes fréquemment utilisées ont index composites
TimescaleDB fournit des index spécialisés pour les requêtes en série temporelle
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. 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 des 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 modifications 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 des hiérarchies d'actifs de flotte à travers les niveaux organisationnels, des plateformes SaaS multi-locataires nécessitant l'isolation des données, des opérations soumises à la conformité avec des exigences d'audit détaillées, et des 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.
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 se produisent immédiatement au fur et à mesure des changements, avec des 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 d'héritage à table unique pour toutes les données de référence via la ci_base table :
Le repo le schéma utilise un Héritage à table unique modèle pour toutes les données de référence via la ci_base table. Ce design consolide les dictionnaires système, les classifications et les éléments de référence définis par l'utilisateur en une seule structure unifiée, fournissant cohérence et flexibilité à travers l'ensemble du schéma.
Architecture :
Le ci_base la table sert de fondation pour toutes les données de référence, utilisant un discriminator 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 que ci_base, créant une relation d'héritage assurant la sécurité des types.
Comment les entités métier se connectent à ci_base :
Toutes les entités métier dans le repo schéma référencent ci_base des sous-types pour définir leur classification et 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(tous 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 utilisateurs
Définitions des types d'entité
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 (lié à 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
Activer l'étiquetage flexible et l'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 finalité métier.
organization
Objectif : Gestion organisationnelle hiérarchique
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, des index sur parent_id et organization_type_id
Remarques spéciales
Utilise ltree pour des hiérarchies multi‑niveaux, hérite de customizable_entity pour la prise en charge des champs personnalisés
user
Objectif : Comptes utilisateurs 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 spéciales
Intégration de fournisseurs d'identité externes (Keycloak, Auth0, Okta), hérite de customizable_entity
device
Objectif : Appareils 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 spéciales
Identifiant matériel pour le suivi des appareils, hérite de customizable_entity pour les champs personnalisés
asset
Objectif : 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 spéciales
Hérite de customizable_entity, lié aux appareils via device_asset_link
inventory
Objectif : Enregistrements d'inventaire et d'entrepôt
Champs clés
id, organization_id, inventory_type_id, code
Indexation
Index unique sur (organization_id, code)
Remarques spéciales
Codes uniques au sein de l'organisation, liés aux appareils via device_inventory_link
asset_group
Objectif : Regroupement d'actifs avec historisation
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 spéciales
Adhésion basée sur le temps via asset_group_item, interroger les membres actuels avec WHERE detached_at IS NULL
custom_field_def
Objectif : 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 texte, nombre, booléen, date, datetime, entity_ref, catalog_item_ref
Remarques spéciales
Permet des champs personnalisés flexibles pour tout type d'entité, valeurs stockées dans des custom_field_value_* tables
acl_role_permission
Objectif : 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 étendues à un 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 spéciales
Fonctionne avec user_role et acl_user_scope pour déterminer les permissions finales de l'utilisateur
audit_event
Objectif : Journal d'audit unifié pour tous les changements 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 spéciales
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 dans event_data JSONB
Relations de données
Le repo le schéma met en œuvre 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 (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_idetdiscriminatorchamps
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 par 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 requis
Valeurs DEFAULT pour les horodatages et les indicateurs booléens
Validation au niveau applicatif
Validation du type d'entité pour les références polymorphes
Validation du catalogue pour les références de champs personnalisés
Validation des types de champs personnalisés
Gestion des tableaux pour les champs multi‑valeurs
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 prenant en charge la suppression logique
Index de valeurs de champs personnalisés pour le filtrage et le tri
Index d'é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 possible futur 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 ?