13. Data Model
Un data model (ou data modèle en français) est une représentation conceptuelle des tables. On y voit les attributs qu'elles contiennent et des relations qui les unissent. Le data model constitue un plan essentiel dans la conception et le développement d'une base de données relationnelle. Ce modèle sert à organiser et structurer les données de manière à refléter les besoins métier tout en garantissant leur cohérence et leur exploitabilité.
La création d’un data model repose sur la capacité à traduire les besoins métiers en structures de données utilisables dans un système de gestion de bases de données relationnelles (SGBDR). Cette démarche inclut les définitions de clés primaires et de clés étrangères vues dans le chapitre 11.
Exemple de Data Model représentant des commandes (factInternetSale), des produits (dimProduct) et le territoire (dimSalesTerritory) sur lequel ces commandes sont faites.
Les Composants d’un Data Model
Un data model est définit avec les 4 composantes suivantes qui seront détaillées au cours de ce chapitre.
- Tables
- Colonne
- Relation
- Type de relation
- Contrainte et clef
Tables
Les tables sont les éléments principaux du modèle. Elles représentent des objets ou concepts métier (exemple : Client, Commande, Produit). Chaque entité correspond à une table dans la base de données.
Colonnes
Les attributs (ou colonnes) sont les caractéristiques des entités. Par exemple, pour l'entité client, les attributs peuvent être le nom, l'email et l'adresse. Chaque attribut correspond à une colonne dans une table.
Relations
Les relations décrivent les liens logiques entre les entités. Elles permettent de structurer les données pour éviter la redondance et simplifier leur manipulation.
Contraintes et Clés :
- Clé primaire (Primary Key) : Identifie de manière unique chaque enregistrement dans une table.
- Clé étrangère (Foreign Key) : Permet de relier une table à une autre en pointant vers une clé primaire.
Les contraintes comme NOT NULL, UNIQUE ou CHECK garantissent l'intégrité et la qualité des données.
Types principaux de relations
Il existe 3 grands types de relations. Elles seront explorées plus en détail dans le paragraphe suivant.
- Relation Un-à-Un (1:1) Un badge est associé à un seul utilisateur.
- Relation Un-à-Plusieurs (1:N) Un client peut passer plusieurs commandes.
- Relation Plusieurs-à-Plusieurs (N:N) Les étudiants suivent plusieurs cours et chaque cours a plusieurs étudiants.
Relation Un-à-Un (1:1)
Chaque entité dans une table est reliée à une et une seule entité dans une autre table. Considérons un scénario simple avec 2 tables : Utilisateurs et Badges. Chaque utilisateur dans la table Badges est associé à un utilisateur unique dans la table Utilisateurs et vice versa.
La table Badges
| ID_Badge | ID_Utilisateur | Accès |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 1 |
| 3 | 3 | 2 |
| 4 | 4 | 3 |
La table Utilisateurs
| ID_Utilisateur | Nom | |
|---|---|---|
| 1 | Dupont | dupont@example.com |
| 2 | Martin | martin@example.com |
| 3 | Durand | durand@example.com |
| 4 | Lefebvre | lefebvre@example.com |
- ID_Utilisateur dans la table Utilisateurs est la clé primaire qui identifie de manière unique chaque utilisateur.
- ID_Badge dans la table Badge est la clé primaire qui identifie de manière unique chaque profil.
- ID_Utilisateur dans la table Badge sert de clé étrangère pour établir une relation 1-1 avec la table Utilisateurs.
Une variante est la relation 0 à 1 qui signifie que certaines données peuvent apparaitre dans une table et pas dans l'autre. Dans l'exemple ci-dessus, certains utilisateurs auraient un badge et d'autres n'en auraient pas.
Relation Un-à-Plusieurs (1:N)
Une entité dans une table peut être associée à une ou plusieurs entités dans une autre table. Par exemple, un client peut faire plusieurs commandes.
La table Clients
| ID_Client | Nom | |
|---|---|---|
| 1 | Dupont | dupont@example.com |
| 2 | Martin | martin@example.com |
| 3 | Durand | durand@example.com |
| 4 | Lefebvre | lefebvre@example.com |
La table Commandes
| ID_Commande | Date | Montant | ID_Client |
|---|---|---|---|
| 1 | 2024-02-01 | 150.00 | 1 |
| 2 | 2024-02-03 | 80.00 | 2 |
| 3 | 2024-02-05 | 200.00 | 1 |
| 4 | 2024-02-07 | 50.00 | 3 |
| 5 | 2024-02-09 | 120.00 | 2 |
| 7 | 2024-02-13 | 60.00 | 2 |
- ID_Client dans la table Clients est la clé primaire qui identifie de manière unique chaque client.
- ID_Commande dans la table Commandes est la clé primaire qui identifie de manière unique chaque commande.
- ID_Client dans la table Commandes sert de clé étrangère pour établir une relation 1:N avec la table Clients. Cela signifie que chaque commande est directement associée à un seul client mais un utilisateur peut avoir passé plusieurs commandes.
Une variante est la relation 0 à N qui signifie que certaines données peuvent apparaitre dans une table et pas dans l'autre.
Relation Plusieurs-à-Plusieurs (N:N)
Dans une base de données, une relation N:N (plusieurs-à-plusieurs) se produit lorsque plusieurs entités dans une table peuvent être associées à plusieurs entités dans une autre table. Par exemple, des étudiants peuvent suivre plusieurs cours et chaque cours peut être suivi par plusieurs étudiants.
La table Etudiants
| ID_Etudiant | Nom | |
|---|---|---|
| 1 | Dupont | dupont@example.com |
| 2 | Martin | martin@example.com |
| 3 | Durand | durand@example.com |
| 4 | Lefebvre | lefebvre@example.com |
La table Cours
| ID_Cours | Titre | Enseignant |
|---|---|---|
| 1 | Mathématiques appliquées | Dr. Mathieu |
| 2 | Introduction à la physique | Dr. Dupré |
| 3 | Histoire de l'art | Dr. Leroy |
| 4 | Informatique | Dr. Simon |
La table Inscriptions
| ID_Inscription | ID_Etudiant | ID_Cours | Semestre |
|---|---|---|---|
| 1 | 1 | 1 | Automne |
| 2 | 1 | 4 | Automne |
| 3 | 2 | 2 | Automne |
| 4 | 2 | 3 | Automne |
| 5 | 2 | 4 | Ete |
| 6 | 3 | 1 | Ete |
| 7 | 4 | 1 | Ete |
| 8 | 4 | 3 | Ete |
| 9 | 4 | 4 | Ete |
- ID_Etudiant dans la table Etudiants et ID_Cours dans la table Cours servent de clés primaires pour identifier de manière unique chaque étudiant et chaque cours, respectivement.
- La table Inscriptions sert de table d'association pour gérer la relation N:N entre les étudiants et les cours. Elle contient les clés étrangères ID_Etudiant et ID_Cours, ainsi que des informations supplémentaires telles que le Semestre de l'inscription.
- ID_Inscription dans la table Inscriptions est la clé primaire qui identifie de manière unique chaque inscription d'un étudiant à un cours.
Cependant, implémenter directement une relation N:N n'est pas toujours idéal ni possible dans les bases de données relationnelles traditionnelles. Cela peut entraîner des problèmes d'organisation et de gestion des données car les bases de données relationnelles ne supportent pas directement ce type de relation.
La meilleure pratique : La table d'association
Pour modéliser une relation N:N de manière efficace et respectueuse des principes des bases de données relationnelles, on introduit une table d'association (ou table de jointure) entre les 2 tables. Cette approche transforme la relation N:N en 2 relations 1:N.
Une première relation 1:N entre la table d'association et la première entité.
Une deuxième relation 1:N entre la table d'association et la deuxième entité.
Cette méthode :
- Réduit la redondance des données.
- Facilite l'ajout d'attributs supplémentaires liés à la relation.
Les types de modèle
Modèle en étoile (Star Model)
Le modèle en étoile est un modèle de données dimensionnelles couramment utilisé dans les entrepôts de données (data warehouse). Il est caractérisé par une table de faits centrale qui contient les mesures d'intérêt et un ensemble de tables de dimensions qui sont reliées à la table de faits. Les tables de dimensions contiennent des attributs descriptifs relatifs aux dimensions de l'analyse. Ce modèle facilite les requêtes analytiques et est optimisé pour les opérations de lecture.
La table de fait est représentée par factInternetSale (représentant les commandes), est reliée aux tables de dimensions contenant des informations sur les pays, les produits et les dates.
Modèle en flocon (Snowflake Model)
Le modèle en flocon est une variante plus normalisée du modèle en étoile, où les tables de dimensions sont normalisées, c'est-à-dire, décomposées en tables plus petites et plus nombreuses. Bien que cela puisse réduire la redondance des données et économiser de l'espace de stockage, cela peut aussi rendre les requêtes plus complexes et potentiellement moins performantes en raison du nombre accru de jointures nécessaires.
La table de dimension dimProduct qui contient les catégories des produits est lié à une autre table de dimension plus spécifique qui contient les sous-catégories des produits.
Modèle Hybride
Il existe également les modèles hybrides. Ils combinent les avantages des 2 précédents avec certaines dimensions avec le moins de redondance possible (comme dans le flocon) et d'autres directement connectées à la table de faits (comme dans l'étoile). Ce compromis est souvent choisi dans des cas où certaines dimensions nécessitent une maintenance fréquente mais où les performances des requêtes restent critiques
Le modèle en étoile est mis en avant.
Le modèle en flocon est mis en avant.
Pour la visualisation
Si les données sont utilisées pour créer des rapports interractifs sur Power Bi ou Tableau, il est fortement recommandé d'adopter un modèle en étoile car il facilite l'optimisation des performances de calcul et rend les visualisations plus fluides. En revanche, pour des bases de données nécessitant une forte cohérence et où les mises à jour sont fréquentes, un modèle en flocon pourrait être préférable.