Database Tables¶
La couche Database de CMonChoix Platform est organisée autour de plusieurs familles de tables correspondant aux différentes étapes du cycle de vie des données.
Cette organisation reflète directement l'architecture de la Platform.
Une table n'est jamais créée pour répondre à un besoin ponctuel. Chaque structure appartient à une couche clairement identifiée et possède une responsabilité unique.
Principes¶
La conception des tables respecte plusieurs règles fondamentales.
- une responsabilité par table ;
- aucun mélange entre données techniques et données métier ;
- aucune logique métier embarquée dans le schéma ;
- aucune dépendance directe avec le Frontend ;
- aucune dépendance à une verticale spécifique.
La structure de la base doit rester suffisamment stable pour permettre l'évolution indépendante des différentes couches applicatives.
Classification des tables¶
Les tables sont regroupées selon leur rôle dans le pipeline.
Database
│
├── Import
│
├── Stage
│
├── Normalisation
│
├── Canonical Identity
│
├── Projection
│
├── Navigation
│
├── Runtime
│
├── Monitoring
│
└── Historique
Cette classification constitue la référence documentaire utilisée dans toute la Platform.
Tables d'import¶
Les tables d'import représentent les données telles qu'elles sont reçues depuis les marchands.
Responsabilités :
- conserver les informations téléchargées ;
- permettre une réimportation ;
- conserver une traçabilité complète ;
- servir de point d'entrée au pipeline.
Ces tables ne sont jamais utilisées directement par le Frontend.
Tables de Stage¶
Les tables de Stage constituent la zone de travail du Pipeline.
Elles permettent notamment :
- les simulations ;
- les audits ;
- les comparaisons ;
- les traitements intermédiaires.
Les données qu'elles contiennent ne sont pas encore considérées comme consolidées.
Tables de normalisation¶
Ces structures regroupent les données progressivement harmonisées.
On y retrouve notamment :
- les identifiants normalisés ;
- les attributs harmonisés ;
- les enrichissements génériques ;
- les informations préparant la résolution.
Ces tables sont principalement utilisées par le Domain Core.
Voir :
Tables de Canonical Identity¶
Ces tables représentent les objets métier consolidés.
Elles permettent de construire une représentation stable d'un produit indépendamment :
- du marchand ;
- du feed ;
- des identifiants utilisés ;
- des variantes de présentation.
La Canonical Identity constitue la référence utilisée par les traitements suivants.
Voir :
Tables de projection¶
Les projections représentent les données optimisées pour la consultation.
Leur objectif est de fournir :
- une structure simple ;
- des lectures rapides ;
- une stabilité fonctionnelle.
Les projections ne recalculent jamais la logique métier.
Elles sont entièrement produites par les traitements précédents.
Voir :
Tables de navigation¶
Les structures de navigation permettent de représenter le catalogue.
Leur contenu est optimisé pour :
- la hiérarchie des catégories ;
- les parcours utilisateurs ;
- les filtres ;
- les menus.
Ces tables sont reconstruites automatiquement par les traitements de la Platform.
Tables Runtime¶
Certaines structures sont utilisées pendant l'exécution des traitements.
Elles peuvent contenir :
- l'état d'une synchronisation ;
- les traitements en cours ;
- les informations techniques nécessaires à l'orchestration.
Le Runtime ne doit jamais y stocker une logique métier.
Voir :
Tables de monitoring¶
Ces tables permettent de suivre le fonctionnement de la Platform.
On y retrouve notamment :
- les statistiques ;
- les métriques ;
- les temps d'exécution ;
- les indicateurs techniques.
Leur objectif est d'améliorer l'observabilité du système.
Tables historiques¶
Certaines informations doivent être conservées dans le temps.
Ces structures permettent :
- d'analyser une synchronisation passée ;
- de comparer plusieurs exécutions ;
- d'expliquer une évolution ;
- de reproduire un traitement.
Cette traçabilité constitue un élément central de la méthode industrielle de CMonChoix.
Relations entre les familles¶
Les différentes familles suivent un ordre logique.
Import
│
▼
Stage
│
▼
Normalisation
│
▼
Canonical Identity
│
▼
Projection
│
▼
Navigation
│
▼
Frontend
Une famille ne doit jamais modifier directement une famille située en amont.
Contraintes d'architecture¶
Les règles suivantes s'appliquent à toutes les tables.
Responsabilité unique¶
Chaque table possède une mission clairement définie.
Une table ne doit jamais remplir plusieurs rôles métier.
Couplage minimal¶
Les dépendances entre structures doivent rester limitées.
Les traitements applicatifs assurent les transformations plutôt que le schéma lui-même.
Lecture optimisée¶
Les projections sont organisées afin de réduire les traitements réalisés au moment de la consultation.
Cette approche améliore :
- les performances ;
- la stabilité ;
- la prévisibilité des temps de réponse.
Reproductibilité¶
Toutes les étapes importantes doivent pouvoir être reproduites.
Cela implique la conservation des informations nécessaires à l'analyse d'un traitement.
Garde-fous¶
Les évolutions de la base de données doivent respecter plusieurs principes.
Ne jamais :
- utiliser une projection comme source de vérité ;
- ajouter une logique métier dans le schéma SQL ;
- mélanger données techniques et données métier ;
- créer des dépendances circulaires ;
- faire dépendre une table d'une verticale particulière.
Évolution¶
L'architecture des tables est conçue pour accompagner la croissance progressive de la Platform.
Les évolutions futures porteront principalement sur :
- l'amélioration des projections ;
- l'optimisation des performances de lecture ;
- l'enrichissement des capacités d'observabilité ;
- la prise en charge de nouvelles verticales ;
- l'amélioration des mécanismes de reconstruction.
Ces évolutions devront préserver les principes décrits dans ce document.