For the complete documentation index, see llms.txt. This page is also available as Markdown.

Couche de données brutes

Consultez les jeux de données sources pour les entités métier, la télémétrie des appareils et les actifs et inventaires, ainsi que les tables clés et la fréquence de mise à jour.

La couche de données brutes contient 3 schémas de données distincts, chacun couvrant différents aspects de la plateforme de télématique et de veille stratégique :

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

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

  • repo - contenant des tables pour la gestion des actifs et des stocks, y compris les types d’actifs configurables, les champs personnalisés, les relations entre actifs et les données géospatiales pour le suivi des ressources de l’organisation.

Chaque schéma est optimisé pour son domaine de données et ses modèles 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

Ce 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

Vous trouverez ci-dessous les détails du 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 sont effectuées de manière incrémentale au fur et à mesure des changements 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 toute la base de données :

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

Définitions des types

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 des unités

Unités de mesure pour les capteurs

units_type : liter, gallon, celsius

Classifications des 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écapitule les tables clés par leur finalité métier :

Entités métier principales

users

Description: Comptes utilisateurs contenant les informations de profil, l’appartenance à l’entreprise, les paramètres de localisation (fuseau horaire, locale) et les relations hiérarchiques via master_id pour les structures de comptes à plusieurs niveaux

Attribut
Détails

Champs clés

- user_id - Identifiant utilisateur unique - 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 - Prénom patronymique de l’utilisateur - locale - Paramètres de langue de l’utilisateur - timezone_label - Fuseau horaire au format IANA - master_id - ID de l’utilisateur principal (si l’utilisateur actuel est subordonné) - registration_datetime - Date d’inscription 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 particulières

Entité centrale reliant les données organisationnelles ; master_id permet des hiérarchies d’utilisateurs pour les structures de comptes à plusieurs niveaux

employees

Description: Enregistrements des employés et des conducteurs utilisés pour représenter les personnes travaillant pour l’organisation, y compris les informations personnelles, les détails du permis, les affectations aux départements, les clés matérielles pour l’identification iButton/RFID et les données de localisation avec prise en charge du géorepérage

Attribut
Détails

Champs clés

- employee_id - Identifiant de l’entité employé - user_id - Identifiant de l’entité utilisateur - object_id - Objet identifiant l’entité - department_id - ID du département auquel l’employé est affecté - first_name - Attribut first_name de la table employees - last_name - Attribut last_name de la table employees - middle_name - 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 - E-mail de l’employé - phone_number - Téléphone de l’employé sans le signe "+" - address - Adresse de l’emplacement - personnel_number - Numéro de personnel de l’employé/du conducteur - citizen_id_number - Numéro de Sécurité sociale - latitude - Emplacement associé à cet employé - longitude - Emplacement associé à cet employé - radius - Emplacement associé à cet employé en mètres - fuel_consumption - Attribut fuel_consumption de la table employees - fuel_cost - Attribut fuel_cost de la table employees - is_deleted - Attribut is_deleted de la table employees

Relations

Liens vers users, departments, objects (traceur affecté), suivi dans driver_history et checkins

Remarques particulières

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, rayon) permettant des analyses basées sur le géorepérage pour le reporting au niveau des départements et l’association de l’emplacement des employés

Attribut
Détails

Champs clés

- department_id - Identifiant de l’entité département - user_id - Identifiant de l’entité utilisateur - department_label - Attribut department_label de la table departments - latitude - Emplacement associé à ce département - longitude - Emplacement associé à ce département - radius - Taille de la géolocalisation en mètres - address - Attribut address de la table departments

Relations

Relie les employés à la structure organisationnelle via department_id

Remarques particulières

Les champs de localisation prennent en charge des analyses basées sur le géorepérage pour le reporting au niveau des départements

Suivi et surveillance

devices

Description: Registre des dispositifs de suivi physiques avec identifiants matériels (IMEI), informations sur la carte SIM, état de la connectivité réseau (puissance du signal, itinérance, opérateur) et affectations de la liste d’état pour la gestion du cycle de vie des appareils

Attribut
Détails

Champs clés

- device_id - ID de l’appareil - owner_id - ID du propriétaire de l’appareil dans le compte duquel la balise a été ajoutée - device_imei - IMEI de l’appareil - phone - Numéro de carte SIM de l’appareil - status_listing_id - ID d’état de l’appareil - network_label - Nom du réseau auquel la carte SIM est connectée - signal_level - Puissance 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é principale reliant objects, models, sensor_description, counters; owner_id references users.user_id

Remarques particulières

Toutes les données télématiques du 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

Attribut
Détails

Champs clés

- object_id - Objet identifiant l’entité - 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 - Groupe d’identifiant d’entité - create_datetime - Date et heure de création d’une nouvelle ligne sur le serveur - is_deleted - Attribut is_deleted de la table objects - is_clone - Indicateur de clone

Relations

Hub 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 particulières

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

Attribut
Détails

Champs clés

- model_id - Identifiant du modèle d’entité - model - Attribut model de la table models - vendor - Nom de l’entreprise qui a publié le traceur - alternative_label - Attribut alternative_label de la table models - analog_amount - Nombre d’entrées analogiques du traceur - digital_amount - Nombre d’entrées discrètes du traceur - outputs_amount - Nombre de sorties discrètes du traceur - has_battery_level - Détermine si le traceur transmet les relevés du niveau de batterie - has_altitude - Détermine si le traceur transmet l’altitude - has_phone - Y a-t-il une carte SIM ? - has_gsm_level - Un traceur peut-il transmettre la puissance du signal GSM ? - has_gsm_name - Le traceur peut-il transmettre le nom du réseau GSM ou le code opérateur (MCC + MNC) ? - has_gsm_roaming - Le traceur peut-il transmettre l’état d’itinérance ? - has_detach_button - Le traceur dispose-t-il d’un capteur de détachement ? - type_output_control - Profil de contrôle des sorties du traceur - 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 de conduite dangereuse (hbm_telfm) pour les équipements Teltonika - is_clone - Le modèle est-il un clone d’un autre modèle ?

Contenu

Les indicateurs booléens de capacité précisent quels champs de données sont disponibles pour ce type d’appareil

Remarques particulières

Utilisez les indicateurs de capacité pour déterminer les capteurs et les 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ées, les unités de mesure, les facteurs de conversion (multiplier/divider), les tables d’étalonnage pour les capteurs de carburant, les seuils de précision et la logique de regroupement pour les relevés de capteurs agrégés

Attribut
Détails

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 - Nom du champ du message (attribut) à partir duquel les données du capteur sont prises. S’il est égal à "input_status", il s’agit d’un capteur discret - sensor_type - Type de capteur - units_type - Unités de mesure - multiplier - Multiplicateur - nombre par lequel multiplier la valeur du champ. Pour les capteurs de mesure uniquement - divider - Diviseur - nombre par lequel diviser la valeur du champ. Pour les capteurs de mesure uniquement - accuracy - 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 ont lieu. Ceci est utilisé uniquement pour les capteurs de carburant - calibration_data - 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 comme appartenant 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. Il est utilisé pour les capteurs de mesure - group_type - 0 - additionner les valeurs des capteurs d’un groupe, 1 - moyenne - sensor_units - Nom de l’unité saisi par l’utilisateur si units_type=0 (personnalisé) - parameters - Objet facultatif avec des paramètres supplémentaires parent_ids - tableau facultatif de parent_ids pour un capteur composite. volume - double. Facultatif. Volume pour capteur composite. parent_ids - facultatif. tableau d’entiers. Tableau de parent_ids pour capteur composite. volume - facultatif. Double. Volume pour capteur composite. min - facultatif. Double. Valeur brute minimale acceptable pour un capteur. max - facultatif. Double. Valeur brute maximale acceptable pour un capteur. max_lowering_by_time - facultatif. Double. Diminution maximale légale de la valeur par heure. max_lowering_by_mileage - facultatif. Double. Diminution maximale légale de la valeur par 100 km. ignore_drains_in_move - facultatif. Booléen. La valeur par défaut est false. Si true, les vidanges de carburant ne seront pas détectées pendant le déplacement. ignore_refuels_in_move - facultatif. Booléen. La valeur par défaut est false. Si true, les ravitaillements ne seront pas détectés pendant le déplacement. refuel_gap_minutes - facultatif. Entier. La valeur par défaut est 5. Le temps en minutes après le début du déplacement, les ravitaillements seront détectés pendant le déplacement. custom_field_name - facultatif. Booléen. La valeur par défaut est 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 du traceur dispose 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 la correspondance

Remarques particulières

calibration_data (JSONB) stocke les tables d’étalonnage spécifiques aux capteurs pour les capteurs de niveau de carburant ; multiplier et divider convertit 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 traceur via object_id pour la gestion de flotte et le suivi de conformité

Attribut
Détails

Champs clés

- vehicle_id - Identifiant de l’entité véhicule - user_id - Identifiant de l’entité utilisateur - object_id - Objet identifiant l’entité - garage_id - Identifiant de l’entité garage - vehicle_label - Attribut vehicle_label de la table vehicles - registration_number - Numéro d’immatriculation / plaque d’un véhicule - vin - Attribut vin de la table vehicles - manufacture_year - Attribut manufacture_year de la table vehicles - fuel_type - Attribut fuel_type de la table vehicles - fuel_cost - Attribut fuel_cost de la table vehicles - fuel_tank_volume - Attribut fuel_tank_volume de la table vehicles - max_speed - Attribut max_speed de la table vehicles - model - Attribut model de la table vehicles - color - Attribut color de la table vehicles - trailer - Attribut trailer de la table vehicles - additional_info - Attribut additional_info de la table vehicles - vehicle_type - Attribut vehicle_type de la table vehicles - vehicle_subtype - Attribut vehicle_subtype de la table vehicles - vehicle_status_id - Identifiant d’état de l’entité véhicule - chassis_number - Attribut chassis_number de la table vehicles - frame_number - Attribut frame_number de la table vehicles - trailer_reg_number - Attribut trailer_reg_number de la table vehicles - payload_weight - Attribut payload_weight de la table vehicles - payload_height - Attribut payload_height de la table vehicles - payload_length - Attribut payload_length de la table vehicles - payload_width - Attribut payload_width de la table vehicles - passenger_capacity - Nombre maximal de passagers - gross_weight - Attribut gross_weight de la table vehicles - standard_fuel_consumption - Consommation moyenne normale de carburant en litres par 100 km - fuel_grade - Attribut fuel_grade de la table vehicles - wheel_arrangement - 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 - Attribut liability_insurance_policy_number de la table vehicles - liability_insurance_valid_till - Date jusqu’à laquelle l’assurance responsabilité civile est valide - free_insurance_policy_number - 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 (traceur actuel), garages (lieu de service), vehicle_service_tasks; suivi dans vehicle_trackers_history

Remarques particulières

Les champs de dimensions physiques (payload_length, payload_width, payload_height, gross_weight) prennent en charge les analyses de planification de chargement ; les dates d’assurance permettent le suivi de conformité

garages

Description: Emplacements des installations de service et de maintenance avec coordonnées géographiques (latitude, longitude, rayon), informations de contact pour les mécaniciens et les répartiteurs, permettant la détection des visites de service basée sur le géorepérage et l’analyse de proximité

Attribut
Détails

Champs clés

- garage_id - Identifiant de l’entité garage - user_id - Identifiant de l’entité utilisateur - latitude - Objet d’emplacement - longitude - Objet d’emplacement - radius - Taille de la géolocalisation en mètres - address - Objet d’emplacement - 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 particulières

Les champs de localisation permettent la détection des visites de service basée sur le géorepérage et l’analyse de proximité

vehicle_service_tasks

Description: Suivi du calendrier d’entretien et de l’historique des services avec plusieurs types de déclencheurs (basés sur la date, le kilométrage, les heures moteur), des intervalles de tâches récurrentes, des notifications multicanales (e-mail, SMS, push) et une distinction entre les événements de maintenance planifiés (is_repeat) et non planifiés

Attribut
Détails

Champs clés

- service_task_id - Identifiant de l’entité tâche de service - vehicle_id - Identifiant de l’entité véhicule - description - Attribut description de la table vehicle_service_tasks - status - Valeur d’état de l’attribut status - cost - Attribut cost de la table vehicle_service_tasks - start_date - Date et heure associées à l’attribut start_date - end_date - Date et heure associées à l’attribut end_date - completion_date - Date et heure associées à l’attribut completion_date - predicted_datetime - Date et heure associées à l’attribut predicted_datetime - mileage_limit - Attribut mileage_limit de la table vehicle_service_tasks - engine_hours_limit - Attribut engine_hours_limit de la table vehicle_service_tasks - start_mileage - Attribut start_mileage de la table vehicle_service_tasks - start_engine_hours - Attribut start_engine_hours de la table vehicle_service_tasks - mileage_notification_interval - Attribut mileage_notification_interval de la table vehicle_service_tasks - engine_hours_notification_interval - 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 - Attribut mileage_repeat_interval de la table vehicle_service_tasks - engine_hours_repeat_interval - Attribut engine_hours_repeat_interval de la table vehicle_service_tasks - date_repeat_interval - Conversion d’un entier N en N jours - notification_emails - Attribut notification_emails de la table vehicle_service_tasks - notification_sms_phone_numbers - Attribut notification_sms_phone_numbers de la table vehicle_service_tasks - is_notification_push_enabled - Attribut is_notification_push_enabled de la table vehicle_service_tasks - completion_mileage - Attribut completion_mileage de la table vehicle_service_tasks - completion_engine_hours - Attribut completion_engine_hours de la table vehicle_service_tasks - is_repeat - Attribut is_repeat de la table vehicle_service_tasks - is_unplanned - Attribut is_unplanned de la table vehicle_service_tasks - comment - 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 ; paramètres de notification pour e-mail, SMS, push

Remarques particulières

is_repeat et les champs d’intervalle permettent des calendriers d’entretien récurrents ; is_unplanned distingue la maintenance planifiée de la maintenance réactive

Localisation et itinéraire

zones

Description: Zones géorepérées définissant des périmètres virtuels à l’aide de cercles ou de polygones pour surveiller les événements d’entrée et de sortie des véhicules/actifs, prenant en charge l’automatisation basée sur les règles et l’analyse de localisation avec un codage couleur pour la différenciation visuelle

Attribut
Détails

Champs clés

- zone_id - Identifiant de l’entité zone - client_id - Identifiant de l’entité client - zone_label - Attribut zone_label de la table zones - zone_type - Attribut zone_type de la table zones - latitude - Objet facultatif, la boîte englobante pouvant contenir entièrement le résultat renvoyé - longitude - Objet facultatif, la boîte englobante pouvant contenir entièrement le résultat renvoyé - circle_center_latitude - Attribut circle_center_latitude de la table zones - circle_center_longitude - Attribut circle_center_longitude de la table zones - radius - Taille de la géolocalisation en mètres - address - Attribut address de la table zones - color - Attribut color de la table zones

Contenu

Les types de zones incluent circle, polygon (défini via geofence_points), et des classifications spéciales de zones

Relations

Référencé par rules2zones, users2zones; les sommets du polygone sont stockés dans geofence_points

Remarques particulières

Les fonctions PostGIS peuvent être utilisées pour vérifier l’appartenance d’un point à un polygone pour une analyse complexe de géorepérage

places

Description: Points d’intérêt avec coordonnées géographiques, définitions de rayon et prise en charge extensible de champs personnalisés pour stocker les informations de contact des clients et les données propres à l’entreprise, permettant l’intégration CRM/ERP via external_id et le reporting basé sur la localisation

Attribut
Détails

Champs clés

- place_id - Identifiant de l’entité lieu - user_id - Identifiant de l’entité utilisateur - place_label - Attribut place_label de la table places - latitude - Objet d’emplacement - longitude - Objet d’emplacement - radius - Taille de la géolocalisation en mètres - address - Attribut address de la table places - description - 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’attribution du point d’intérêt à l’utilisateur

Relations

Étendu avec les valeurs de champs personnalisés via places_text_fields, places_decimal_fields, places_bigint_fields, places_longtext_fields, places_linked_entity_fields

Remarques particulières

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 des 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à de simples zones circulaires, utilisées avec PostGIS ST_MakePolygon pour les opérations géométriques

Attribut
Détails

Champs clés

- zone_id - ID de la zone à laquelle ce formulaire est attaché - number - Numéro de série - latitude - Emplacement - longitude - Emplacement

Relations

Plusieurs enregistrements par zone_id définissent les limites du polygone ; number le champ détermine l’ordre des sommets

Remarques particulières

Interroger avec ORDER BY number pour reconstruire le tracé du polygone ; à utiliser avec PostGIS ST_MakePolygon pour les opérations géométriques

Gestion des tâches et des flux de travail

tasks

Description: Affectations d’ordres de travail avec validation de la localisation (latitude, longitude, rayon), plages horaires (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 interventions terrain et des opérations de livraison

Attribut
Détails

Champs clés

- task_id - Identifiant de l’entité tâche - user_id - Identifiant de l’entité utilisateur - object_id - Objet identifiant l’entité - parent_task_id - Identifiant de l’entité tâche parente - task_label - L’attribut task_label de la table tasks - status - Valeur d’état de l’attribut status - task_type - Type de tâche, tâche, itinéraire ou point de contrôle - 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 - Moment où 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 la 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 d’affectation pour terminer 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. Temps maximum de retard autorisé pour un employé. Toute tâche terminée pendant ce délai sera marquée comme « en retard » - 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; plages horaires définies par time_from/time_to; validation de géorepérage avec emplacement et rayon

Relations

Liens vers forms (collecte de données), task_history (changements de statut), objects (traceur attribué)

Remarques particulières

stay_duration et arrival_duration_minutes permettre le suivi de la 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 enregistrements dans l’application mobile, avec des champs et des valeurs stockés en JSON, une validation de localisation facultative (is_submission_in_zone) et des exigences de soumission obligatoires lorsqu’ils sont attachés à des tâches

Attribut
Détails

Champs clés

- form_id - Identifiant de l’entité formulaire - task_id - ID de la tâche à laquelle ce formulaire est attaché - object_id - Objet identifiant l’entité - form_label - Libellé du formulaire défini par l’utilisateur - champs - Si vrai, le formulaire ne peut être soumis que dans la zone de la tâche - values - Carte avec les ID de champs comme clés et des objets field_value comme valeurs. Clé utilisée pour relier le champ et sa valeur correspondante - submitted_at - Date de la dernière soumission des valeurs du formulaire - 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 vrai, le formulaire ne peut être soumis que dans la zone de la tâche - description - Date de création de ce formulaire (ou de son rattachement à la tâche) - created_at - Date de création de ce formulaire (ou de son rattachement à la tâche)

Contenu

champs définit la structure du formulaire (JSON) ; values contient les données soumises (JSON)

Relations

Liens vers tasks (ordre de travail associé), objects (soumetteur), référencé dans checkins

Remarques particulières

Indicateur de validation de la localisation is_submission_in_zone permet des 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 par rapport aux heures réelles (planned_datetime vs actual_datetime) avec coordonnées géographiques et mesures de précision de localisation (radius) pour le reporting de ponctualité

Attribut
Détails

Champs clés

- checkin_id - Identifiant de l’entité checkin - employee_id - L’identifiant de l’entité employé est aussi l’identifiant des conducteurs - object_id - Appareil de l’employé - form_id - Identifiant de l’entité formulaire - user_id - Utilisateur employé - planned_datetime - Heure de l’appareil lorsque le check-in a été effectué - actual_datetime - Heure du 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 un point, 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 particulières

Variance temporelle entre planned_datetime et actual_datetime permet le reporting de ponctualité ; radius définit la tolérance de localisation acceptable

task_history

Description: Piste d’audit complète des événements du cycle de vie des tâches capturant tous les changements de statut, affectations, mises à jour et modifications de champs avec horodatage (event_datetime), attribution à l’utilisateur et types d’activité (create, update, assign, status_change) stockés dans le champ payload pour l’analyse de conformité et des flux de travail

Attribut
Détails

Champs clés

- task_history_id - Identifiant de l’entité historique de tâche - task_id - Identifiant de l’entité tâche - user_id - Identifiant de l’entité utilisateur - activity - Opération qui s’est produite. 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 généralement les champs qui ont été modifiés pendant l’opération

Contenu

Types d’activité définis dans description_parameters; payload stocke les détails spécifiques à l’événement (texte)

Remarques particulières

Essentiel pour l’analyse de l’achèvement des tâches, le reporting des transitions de statut et le suivi de l’activité des utilisateurs

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 multicanal (alert_email, alert_sms, alert_phone, is_push_enabled) pour la surveillance et les alertes automatisées basées sur les données de l’appareil et du serveur

Attribut
Détails

Champs clés

- rule_id - Identifiant de l’entité règle - object_id - Objet identifiant l’entité - 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 - E-mail pour les notifications - alert_sms - Numéros de téléphone pour les notifications SMS - alert_phone - Numéros de téléphone pour les appels vocaux - is_push_enabled - Si vrai, 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 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 ; prennent en charge les notifications par e-mail, SMS, téléphone et push

Relations

Liens vers les objets via rules2objects, zones via rules2zones

Remarques particulières

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 des alertes basées sur des seuils

rules2objects

Description: Relation plusieurs-à-plusieurs reliant les règles aux objets surveillés avec personnalisation des paramètres par objet via object_params (JSONB), permettant d’appliquer différentes valeurs de seuil (par exemple, limites de vitesse) à chaque véhicule ou actif au sein d’une même règle

Attribut
Détails

Champs clés

- rule_id - Identifiant de l’entité règle - object_id - Objet identifiant l’entité - 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 exemple, différentes limites de vitesse par véhicule)

Remarques particulières

La relation plusieurs-à-plusieurs permet à une règle de surveiller plusieurs objets avec des paramètres différents

rules2zones

Description: Relation plusieurs-à-plusieurs associant des règles à des zones géorepérées, permettant à une seule règle de surveiller les événements d’entrée/sortie dans plusieurs zones géographiques pour des scénarios de surveillance spatiale complexes

Attribut
Détails

Champs clés

- rule_id - Identifiant de l’entité règle - zone_id - Identifiant de l’entité zone

Remarques particulières

La relation plusieurs-à-plusieurs permet une surveillance multi-zones pour une seule règle (par exemple, alerter lors de l’entrée dans l’une de plusieurs zones restreintes)

Statut et catégorisation

statuses

Description: Définitions de statuts personnalisés au sein des listes de statuts, y compris les propriétés d’affichage (color pour l’affichage sur le site Web, order_sort pour le positionnement) utilisées pour représenter les états de travail des appareils ou des employés, avec prise en charge de la suppression douce via l’indicateur is_deleted

Attribut
Détails

Champs clés

- status_id - Identifiant de l’entité statut - listing_id - Identifiant de l’entité liste - status_label - Valeur de statut de l’attribut status_label - color - Couleur utilisée pour l’affichage sur le site Web - order_sort - Position de tri dans la liste des 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 particulières

order_sort définit la séquence d’affichage ; la couleur permet une différenciation visuelle dans les rapports

status_listings

Description: Définitions d’ensembles de statuts contrôlant les valeurs de statut disponibles pour les appareils ou les employés, avec des indicateurs d’autorisation (is_supervisor_controlled, is_employee_controlled) déterminant si les superviseurs, les employés ou les deux peuvent modifier les valeurs de statut

Attribut
Détails

Champs clés

- status_listing_id - Identifiant de l’entité liste de statuts - user_id - Identifiant de l’entité utilisateur - status_listing_label - Valeur de statut de l’attribut status_listing_label - is_supervisor_controlled - Si vrai, les superviseurs peuvent modifier le statut de travail, par exemple à l’aide de l’application mobile de surveillance - is_employee_controlled - Si vrai, les employés peuvent modifier leur propre statut de travail, par exemple à l’aide de l’application mobile de suivi - 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 particulières

Les indicateurs de contrôle déterminent qui peut modifier les statuts : superviseur uniquement, auto-service employé, ou les deux

status_history

Description: Piste d’audit de toutes les transitions de statut des appareils avec horodatage (changed_datetime sur l’appareil, server_datetime sur le serveur), attribution à l’utilisateur (updated_by) et capture de localisation (latitude, longitude, address) permettant l’analyse géographique des changements de statut et le reporting de la localisation de début/fin de journée de travail

Attribut
Détails

Champs clés

- status_history_id - Identifiant de l’entité historique des statuts - device_id - Identifiant de l’entité appareil - old_status_id - Identifiant de l’ancien statut - new_status_id - Identifiant du 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 appareils lors des changements de statut - longitude - Localisation des appareils lors des changements de statut - address - Localisation des appareils lors des changements de statut

Relations

Liens vers devices, statuses (ancien et nouveau), description_parameters (pour updated_by rôle)

Remarques particulières

La capture de localisation permet l’analyse géographique des transitions de statut ; utile pour le reporting de la localisation de début/fin de journée de travail

tags

Description: Étiquettes de catégorisation définies par l’utilisateur avec codage couleur permettant un filtrage et une recherche rapides sur plusieurs types d’entités (lieux, géorepérages, employés, tâches, traceurs, véhicules) pour une organisation flexible

Attribut
Détails

Champs clés

- tag_id - ID de l’entité balise - 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 particulières

Système de catégorisation flexible prenant en charge plusieurs balises par entité

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 uniquement à des fins visuelles

Attribut
Détails

Champs clés

- group_id - Groupe de traceurs (lié par objects.group_id). La division en groupes peut être observée dans la liste des balises, par exemple - client_id - Identifiant de l’entité client - group_label - Titre du groupe défini par l’utilisateur, de 1 à 60 caractères imprimables, par exemple « Employees » - group_color - Couleur du groupe au format Web (sans #), par exemple « FF6DDC ». Détermine la couleur des marqueurs du traceur sur la carte

Relations

Référencé par objects.group_id; propriété du client via client_id (références users)

Remarques particulières

Permet une organisation de type dossier des entités de suivi pour les rapports et les autorisations

groups_objects

Description: Relation plusieurs-à-plusieurs entre les groupes et les objets 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

Attribut
Détails

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 particulières

Permet aux objets d’appartenir simultanément à plusieurs groupes ; interroger avec les deux client_id valeurs d’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 pour les lieux, tâches et autres entités sans modification de la base de données

Attribut
Détails

Champs clés

- entity_id - Identifiant de l’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 de l’entité. sections - tableau d’objets. Chaque section peut contenir un ou plusieurs champs. Au moins une section doit exister dans une disposition. label - string. Nom de la section. field_order - tableau de chaînes. Champs intégrés et ID des champs personnalisés (sous forme de 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 particulières

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 des types de champs configurables (custom_field_type), des règles de validation et des options dans parameters (JSONB), ainsi que des indicateurs d’obligation (is_required) pour une capture de données flexible sur les lieux, tâches et autres entités

Attribut
Détails

Champs clés

- custom_field_id - Identifiant de l’entité champ personnalisé - entity_id - Identifiant de l’entité - custom_field_label - Nom du champ - custom_field_type - Type de données du champ - description - Description du champ - is_required - Est-ce obligatoire 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 est lié à description_parameters

Remarques particulières

Permet l’extension dynamique du schéma sans modification de la base de données ; utilisé largement dans places et tasks

Suivi historique

driver_history

Description: Piste d’audit complète des affectations employé-véhicule au fil du temps, suivant les transitions de old_employee_id vers new_employee_id avec horodatage (changed_datetime, server_datetime), données de localisation (latitude, longitude, address), informations de clé matérielle et attribution à l’utilisateur (updated_by), permettant des analyses spécifiques aux conducteurs lorsqu’ils changent de véhicule

Attribut
Détails

Champs clés

- driver_history_id - Identifiant de l’entité historique du conducteur - object_id - Objet identifiant l’entité - old_employee_id - Ancien identifiant de l’entité employé - new_employee_id - Nouvel identifiant de l’entité employé - hardware_key - L’attribut hardware_key de la table driver_history - changed_datetime - Date et heure auxquelles les modifications ont été effectuées sur 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 ; relie à employees et objects

Remarques particulières

Essentiel pour le reporting spécifique aux conducteurs lorsqu’ils changent de véhicule ; la capture de localisation permet l’analyse de l’emplacement des changements d’affectation

vehicle_trackers_history

Description: Piste d’audit suivant quels appareils GPS (object_id) ont été installés dans quels véhicules (vehicle_id) au fil du temps avec horodatage des modifications (changed_datetime), permettant une attribution historique précise des données et le calcul du kilométrage lorsque les traceurs sont déplacés entre les véhicules

Attribut
Détails

Champs clés

- vehicle_tracker_history_id - Identifiant de l’entité historique du traceur de véhicule - vehicle_id - Identifiant de l’entité véhicule - object_id - Objet identifiant l’entité - 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 particulières

Critique pour l’analyse des données historiques lorsque les traceurs sont déplacés entre les 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 (par ex. task_status, fuel_type, counter_type, entity_classification) pour une traduction cohérente des valeurs dans les rapports et l’affichage de l’interface utilisateur

Attribut
Détails

Champs clés

- key - Valeur possible dans l’attribut - type - Attribut composite constitué du nom de la table suivi d’un underscore et du nom d’un attribut de la table - description - Valeur implicite d’un attribut

Contenu

Fournit des libellés lisibles par l’humain pour les valeurs codées dans toute la base de données (statut des tâches, types de carburant, types de compteurs, etc.)

Relations

Référencé via des clés étrangères depuis plusieurs tables pour une catégorisation standardisée

Remarques particulières

Essentiel pour traduire les codes entiers en valeurs lisibles dans les rapports ; type Champs groupés, énumérations associées

counters

Description: Configurations des compteurs kilométriques et des heures moteur reliant les relevés des capteurs de l’appareil (sensor_id) aux mesures de distance ou de temps avec des coefficients multiplicateurs pour la conversion d’unités (km, miles, hours) et counter_type à partir de description_parameters définissant le type de mesure

Attribut
Détails

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 appareils aux relevés de capteurs représentant des compteurs de distance ou de temps

Remarques particulières

multiplier convertit les impulsions des capteurs en unités réelles (km, miles, hours) ; counter_type de description_parameters définit le type de mesure

device_output_name

Description: Libellés personnalisés pour les canaux de sortie des appareils, associant des identifiants numériques de sortie (number) à des noms définis par l’utilisateur (label) tels que « Door Lock » ou « Engine Block » pour des rapports et analyses lisibles des commandes et états de sortie des appareils

Attribut
Détails

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 particulières

Permet des rapports lisibles lors de l’analyse des commandes et des états de sortie des appareils

device_settings

Description: Paires clé-valeur de configuration des appareils synchronisées depuis la plateforme source. Chaque ligne stocke un paramètre de configuration pour un appareil spécifique.

Attribut
Détails

Champs clés

- device_id - Identifiant de l’entité appareil - key - Nom du paramètre - value - Valeur du paramètre

Clé primaire

Composite : (device_id, key)

Remarques particulières

Renseigné lors de la synchronisation complète du client. Utilisez cette table pour lire les valeurs de configuration au niveau de l’appareil, en plus des données télématiques ou métier.

event_description

Description: Table de référence des codes d’événements du traceur avec des descriptions lisibles par l’humain. Contient 134 entrées couvrant les événements courants du traceur tels que SOS, mode veille, ignition et les changements d’entrées/sorties numériques.

Attribut
Détails

Champs clés

- event_id - Code d’événement (clé primaire) - description - Nom de l’événement lisible par l’humain

Remarques particulières

Joindre à raw_telematics_data.tracking_data_core sur event_id pour afficher les noms d’événements dans les rapports et les tableaux de bord au lieu de codes numériques.

raw_telematics_data structure

La raw_telematics_data le schéma contient trois principaux types de tables qui fonctionnent ensemble pour fournir des données complètes sur les appareils.

Bronze layer raw telematics data ERD
ERD des données télématiques brutes de la 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 raw telematics data.

Tables clés par catégorie

Chaque table a une fonction spécifique dans la capture de différents aspects des informations de l’appareil :

tracking_data_core

Objectif: Données de localisation et de mouvement principales

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 de TimescaleDB La vitesse est également stockée en entier, donc vous devez la diviser par 100

inputs

Objectif: Relevés de capteurs des appareils

Attribut
Détails

Champs clés

input_id, device_id, device_time, sensor_name, value

Contenu

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

Relations

states

Objectif: Indicateurs d’état de l’appareil et modes de fonctionnement

Attribut
Détails

Champs clés

state_id, device_id, device_time, state_name, value

Contenu

Indicateurs du mode de fonctionnement (en marche, au ralenti, arrêté), états des composants (contact, 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 (généralement de quelques secondes). Le schéma est optimisé pour les données de séries temporelles grâce à TimescaleDB, afin d’assurer un stockage et une récupération efficaces.

Informations supplémentaires

Validation des données

La base de données garantit l'intégrité des données grâce à plusieurs mécanismes :

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

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

  • Contraintes NOT NULL garantissent que les champs obligatoires ont toujours une valeur

  • Valeurs DEFAULT fournissent une valeur de 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 des index basés sur le temps sur record_added_at

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

  • Les combinaisons de colonnes fréquemment utilisées disposent d' index composites

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

repo structure des données

La repo Le schéma fournit un cadre complet pour la gestion des structures organisationnelles, des actifs, des appareils et de leurs relations dans des environnements multi-tenant. Construit sur PostgreSQL 14+ avec l'extension ltree, le schéma prend en charge les organisations hiérarchiques, les définitions de champs personnalisés pour tout type d'entité, le 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 le suivi des modifications au niveau des champs. Toutes les entités peuvent être étendues sans modification du schéma, localisées pour les déploiements internationaux et reliées par des relations polymorphes flexibles.

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

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

Trouvez les 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 appliquées immédiatement au fur et à mesure des changements, et les pistes d'audit enregistrent toutes les modifications à des fins de conformité et d'analyse historique.

ci_base

La repo 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 :

La repo schéma utilise un Héritage à table unique modèle pour toutes les données de référence via la ci_base table. Cette conception regroupe les dictionnaires système, les classifications et les éléments de référence définis par l'utilisateur dans une structure unifiée, offrant cohérence et flexibilité sur l'ensemble du schéma.

Architecture :

La ci_base table sert de fondation pour toutes les données de référence, en utilisant un discriminator champ 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 ainsi une relation d'héritage typée de manière sûre.

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

Toutes les entités métier dans le repo schéma font référence aux ci_base sous-types pour définir leur classification et leur comportement :

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

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

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

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

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

  • asset_group → fait 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
Tableaux
Objectif

Configuration système

ci_module, ci_country, ci_role

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

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

Classent toutes les entités métier par type

État et classification

ci_device_status, ci_asset_type_category

Suivent les états des entités et classent les types de groupes en catégories

Contrôle d'accès

ci_permission_scope

Définissez quelles permissions peuvent être accordées (liées à ci_module et ci_entity_type)

Relations

ci_device_relation_type

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

Catégorisation

ci_tag, ci_catalog_category

Permet un balisage flexible et une organisation du catalogue

Exemples de modèles de requêtes

Tables clés par catégorie

Les tables du repo Le schéma est organisé en catégories fonctionnelles. Les descriptions ci-dessous résument les tables les plus importantes selon leur objectif métier.

organization

Objectif : Gestion hiérarchique de l'organisation

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 multiniveaux, hérite de customizable_entity pour la prise en charge des champs personnalisés

user

Objectif : Comptes utilisateurs 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 d'un fournisseur d'identité externe (Keycloak, Auth0, Okta), hérite de customizable_entity

device

Objectif : Appareils 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

Objectif : 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

Objectif : Enregistrements d'inventaire et 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 de l'organisation, liés aux appareils via device_inventory_link

asset_group

Objectif : 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 temporelle via asset_group_item, interrogez les membres actuels avec WHERE detached_at IS NULL

custom_field_def

Objectif : 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 champ incluent texte, nombre, booléen, 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 tables custom_field_value_* spécifiques au type

acl_role_permission

Objectif : 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 de bits d'actions (READ=1, UPDATE=2, DELETE=4, CREATE=8), permissions spécifiques à une cible ou à l'ensemble du 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

Objectif : 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 modification au niveau des champs dans event_data JSONB

Relations de données

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

Structures hiérarchiques

  • Les organisations utilisent des chemins ltree pour des requêtes arborescentes efficaces

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

  • Maintenance automatique des chemins via des déclencheurs 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'identifiant : ci_base → tables de types de référence

  • Discrimination de type via entity_type_id et discriminator 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

La repo Le schéma garantit 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_at IS NULL)

  • Contraintes CHECK (par ex., device_relation garantit master_idslave_id)

  • Contraintes NOT NULL sur les champs obligatoires

  • Valeurs DEFAULT pour les horodatages et les indicateurs 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 à plusieurs 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_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 prenant en charge la suppression logique

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

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

Considérations de performance :

  • Utilisation recommandée du pool de connexions (PgBouncer)

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

  • Partitionnement futur possible pour device table par organization_id

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

Mis à jour

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