Conception d'un modèle de données (MCD)
Dans cet article, je ne vais pas vous proposer un modèle de données « clés en main », mais plutôt un chemin de réflexion qui vous permettra de concevoir vous-même vos bases de données.
L’objectif de cet exemple est de définir ensemble un modèle de données qui évite au maximum la redondance d’informations, offre de bonnes performances et reste évolutif.
Nous allons donc prendre comme exemple une bibliothèque [Library].
Une bibliothèque est composée des éléments suivants:
Des zones = Areas
Des allées = Driveways
Des armoires = Cabinets
Des étagères = Shelves
Des livres = Books
*Traductions faites avec Google Translate car je ne parle couramment Anglais que sous la torture 😉
Table des matières
Ajoutons notre première table Books1 au modèle de données "Library"
Elle contient les informations suivantes
L’id numérique du livre
Son code ISBN (International Standard Book Number)
Son titre
Le nom de l’auteur
Le nom de la zone dans la bibliothèque (histoire, art, etc)
Le nom de l’allée
Le N° de l’armoire
Le N° de l’étagère
Sa position sur l’étagère
Toutes les informations requises pour localiser un livre semblent être présentes, notre table Books1 parait-elle remplir pleinement son rôle !?
Que pensez-vous de la colonne Author ?
Notre table Books1, contient bien les informations dont nous avons besoin, mais elle souffre d’un gros problème de conception.
Que se passera-il si nous avons un livre écrit par plusieurs auteurs ? pire, pouvons-nous gérer la notion d’auteur / co-auteur ?
Il nous faut revoir le modèle pour le rendre plus souple et surtout plus évolutif, ne jamais s’enfermer dans une voie qui nous obligerait à altérer le modèle après conception pour revenir sur des erreurs, car l’impact peut être énorme.
Nous allons donc créer une table d’auteurs « Authors » pour palier à cet oubli.
Ajoutons notre table Authors au modèle de données "Library"
Notre table d’auteurs « Authors » est volontairement simplifiée, mais elle nous donne déjà pas mal d’informations.
Reste qu’il faut trouver le moyen de la lier à notre table de livres désormais nommée « Books2 ».
Or, si nous ajouton une colonne AuthorId dans Books2, le problème n’est pas réglé.
Nous ne pouvons pas non plus ajouter un nombre N de colonnes comme par exemple AthorId1, AthorId2, AthorIdN ne sachant pas à l’avance combien il peut y avoir d’auteurs, de plus en termes de recherche nous serions dépendants du fait qu’il faudrait chercher un auteur dans toutes ces colonnes.
Nous devons trouver une solution qui nous permette non seulement d’associer un nombre N d’auteurs à nos livres mais aussi, de gérer la notion de co-auteur.
Vous avez une idée ??…
Ajoutons notre table de liens
Pour associer les auteurs de notre table « Authors » avec les livres de notre table « Books2 », nous allons utiliser ce que l’on appelle une table de liens, que nous appellerons « LinkBooksAuthors ».
Celle-ci nous permettra de gérer aussi la notion de co-auteur avec une valeur booléenne (0 non / 1 oui) et surtout d’éviter la répétition inutile de données (Redondance).
Nous allons économiser de l’espace disque et gagner en performance pour les recherches avec une bonne indexation.
Le modèle semble plus compliqué au premier abord, mais en fait il est plus facile à gérer, évolutif et nous ne travaillons que sur des clés numériques, donc nous avons les perfs maximum.
Il sera désormais facile de lier des auteurs et co-auteurs à nos livres sans aucune limitation.
En avons-nous fini ?? Ou pouvons-nous optimiser encore notre modèle ??
il nous reste encore des choses à optimiser, par exemple:
-Le nom de la zone
-Le nom de l’allée
-Le N° de l’armoire
-Le N° de l’étagère
-La position du livre sur l’étagère
Toutes ces données n’ont pas besoins d’être redondantes, par exemple, l’armoire se trouve dans une allée, l’étagère dans une armoire, et une allée se trouve dans une zone de notre bibliothèque.
Nous avons encore de sérieuses pistes d’optimisation en commencent par utiliser des référentiels pour définir la hiérarchie de nos éléments…
*Ici Référentiel aurait put aussi s’appeler dictionnaire, la différence entre les deux est que normalement un référentiel est immuable alors qu’un dictionnaire peut être enrichi (pas de polémique svp).
Ajoutons nos référentiels
Au final, nous avons une table Books3 qui est réduite à son strict minimum et la hiérarchie de nos éléments, Zones, allées, Armoires, Etagères, est en place dans des référentiels.
Si nous reprenons notre table Books1 comme base de travail, nous pouvons constater que dans le cadre d’une réorganisation des zones ou du déplacement d’une armoire, par exemple, si nous avions 1 million de livres dans cette armoire, il nous faudrait mettre à jour (UPDATE) 1 million de lignes rien que pour changer la zone et /ou l’allée.
Dans notre nouveau modèle, il nous suffit de mettre à jour une seule ligne dans notre table Cabinets [DrivewayId] pour modifier l’emplacement d’une armoire, son contenu lui n’a pas changé, il est toujours dans cette même armoire.
Nous pouvons à loisir modifier l’organisation de notre bibliothèque sans impact significatif sur notre base de données.
Nous gagnons en performance en réduisant les mises à jours à leur strict minimum (sans parler du log), c’est juste du bon sens.
Finalement, nous avons un modèle relativement bien conçu, qui évite la redondance et permet de poser toutes sortes de questions à la base de données par requête avec de bonnes performances.
Certes, cet exemple est simple, mais il permet de comprendre le chemin de réflexion qui a conduit à ce résultat en partant au départ d’une simple table et d’une vague idée…