Sans plan, vous risquez de bâtir une base de données bancale. Listez les informations dont vous allez avoir besoin, classez-les, regroupez-les, caractérisez-les au mieux, selon les besoins, selon la philosophie du produit que vous construisez. Miro, LucidChart, un crayon et un papier même peuvent vous aider à créer vos premières listes.

L'essentiel du travail, la difficulté principale, cette habitude qu’il vous faut prendre, parfois contre-nature, c'est d'abstraire. Abstraire, c'est dégager une caractéristique commune à un ensemble de données.

C'est caractériser, généraliser, prendre de la hauteur.

C'est une manière de penser, de réfléchir, de structurer qui n'est pas forcément intuitive pour tout le monde. Mais même si ce n'est pas votre truc au départ, en respectant les principes, on peut toujours s'en sortir.

Je suis un fan de cinéma, et mes amis le savent, j'adore regarder les bonus et savoir comment tout ça est construit. C'est un monde qui me fascine, par la diversité des métiers artistiques ou intellectuels qui y sont liés. C'est donc dans ce monde que nous allons évoluer.

Quel est le point commun entre Christopher Nolan, Steven Spielberg ou David Fincher ? Ce sont des réalisateurs de génie, certes. Mais n'ont-ils rien de plus, rien de plus grand en commun ?

Vous avez décidé de créer un service, une application, une sorte de wiki par exemple. Allez-vous créer un groupement, une liste, qui ne contient que des réalisateurs ? Car si c'est votre intention, qu'allez-vous faire de Tarantino, qui réalise, évidemment, mais joue aussi dans certains films, est le scénariste dans d'autres ou une combinaison de ces rôles ? Réalisateur, acteur, scénariste ? Sur trois listes différentes ? Peut-on accepter d'avoir la même information présente à plusieurs endroits dans une base de données ?

La réponse à cette dernière question est non. Non car stocker la même information à différents endroits, nous y reviendrons dans le troisième principe, c'est inefficace et dangereux.

C'est là que l'abstraction est importante. Quel est le point commun entre tous ?

Nolan, Spielberg, Fincher, Tarantino, Clooney, ce sont des cinéastes. Mais Clooney, par exemple, est aussi engagé dans d’autres domaines. Si l’application, le service que vous créez est uniquement lié au cinéma, une catégorie CINEASTES est envisageable. Ce sera votre niveau d’abstraction, notre généralisation suffisante et nécessaire.

Par contre, si votre service couvre d’autres domaines que les réalisateurs, acteurs ou scénaristes, CINEASTES risque de ne pas être assez abstrait. Quelle caractéristique peut-on alors dégager pour généraliser encore plus si on veut ajouter les producteurs, les techniciens, les costumiers ?

Ce sont des gens, des personnes. On peut donc abstraire une table des PERSONNES plutôt que de créer des tables différentes par métier, par domaine.

Il y a une limite à l'abstraction cela dit. On pourrait mettre nos PERSONNES dans la grande catégorie des VIVANTS, au milieu des plantes et des animaux, mais ce niveau d'abstraction n'est pas nécessaire dans notre projet. Restons-en donc aux PERSONNES, dans le cadre qui nous occupe.

Le deuxième principe, Structurer, nous apprendra que les données d’une base de données sont toutes placées dans des colonnes. Chacune de ces colonnes possède un type. Discutons d’ores et déjà du cas des colonnes du type Select ou Multi-Select, les sélections uniques ou multiples, qui permettent, dans une colonne, de faire un ou plusieurs choix parmi une liste d’éléments prévus.

Là encore, le niveau d’abstraction demandé par votre application va déterminer si l’utilisation de ces types de champs est nécessaire ou risque de poser un souci. Par exemple, le pays de naissance d’une personne peut être stocké sous forme d’une sélection unique, mais pas d’une sélection multiple, évidemment. On ne peut être né que dans un seul pays.

Mais en allant plus loin, est-ce que ça vaut la peine d’abstraire le pays et de créer une table spécifique pour les pays ? Pour le dire autrement, faut-il abstraire une table des PAYS ?

C’est un choix qui peut se justifier, selon les données nécessaires ailleurs dans votre base de données. Si on ne parle nulle part ailleurs des pays, pourquoi pas garder un champ de sélection unique ou multiple. Mais si on parle de pays à plusieurs endroits, dans plusieurs tables de la base de données, alors sans doute est-il judicieux de créer une table des PAYS et de créer une Relation entre cette table PAYS et les PERSONNES, les ENTITES ou toute autre table qui la nécessiterait.

<aside> 👉🏻 Premier Principe des bases de données, il faut abstraire pour structurer. Généraliser pour créer de grandes familles. Trouver une caractéristique commune pour faire des groupements. Et si plusieurs groupes ont la même caractéristique commune, il faut encore abstraire, encore généraliser, jusqu'au point où ça ne fait plus sens dans votre projet, dans le grand tout.

</aside>