Qu’est-ce qu’un modèle de données ?

Lorsque l’on souhaite créer un site web, un logiciel ou une application mobile il est important de comprendre ce qu’est un modèle de données, et ce, même si l’on ne fait pas partie de l’équipe dite “technique”.

En effet, ce dernier représente la base de toute application, il permet de structurer votre métier. Uber a un modèle de données, Facebook a un autre modèle de données, Deliveroo a également un autre modèle de données.

Toutefois, tous ces services ont certains points communs. Par exemple, ils permettent tous de s’inscrire en tant qu’utilisateur, de se connecter, etc. Mais tous n’ont pas besoin des mêmes données sur l’utilisateur et cela est matérialisé dans le modèle de données.

Entrons dans le vif du sujet.

Pour faire simple, les trois principaux termes à connaitre lorsque l’on parle de modèle de données sont : Entité, Attribut et Relation.

Qu’est-ce qu’une entité ?

Une entité représente un élément de votre business correspondant souvent à un élément de la vie réelle, mais pas toujours. Des exemples d’entités en fonction de services que vous connaissez :

• Facebook : Utilisateur, Statut, AlbumPhoto, Photo
• Uber : Utilisateur, Conducteur, Trajet, Avis
• Twitter : Utilisateur, Tweet
• Blog : Rédacteur, Catégorie, Article
• Site e-commerce : Catégorie, Produit, Commande

Comme vous pouvez le voir, il peut être difficile d’identifier des entités mais lorsque l’on parvient à le faire cela semble naturel.

Les entités ont des attributs

Venons en maintenant aux attributs. Ils appartiennent toujours à une entité. Un attribut a un type qui correspond au type de donnée qu’il contient : nombre entier, nombre décimal, texte libre, booléen (vrai ou faux), date, email, URL…

Si vous n’arrivez pas à déterminer le type d’un attribut c’est probablement que c’est une entité à part ou une relation (voir plus loin).

Prenons l’entité Produit du site e-commerce pour donner des exemples d’attributs :

• Nom : le nom du produit (texte)
• Description : description détaillée (texte)
• Date de disponibilité : quand le produit sera disponible (date)
• Stock : le nombre de produits encore en stock (nombre entier)
• Site du fabricant : lien vers le fabricant (URL)
• Prix TTC : le prix TTC du produit (nombre décimal) Vous savez celui qui finit toujours par ,99€…

Quid des relations ?

Les relations sont légèrement plus compliquées à comprendre mais ce n’est pas insurmontable. Elles permettent de lier des entités entre elles. Vous avez certainement déjà entendu parler de bases de données “relationnelles”. (Attention ça ne veut pas dire que les bases non relationnelles ne permettent pas d’implémenter de relations).

Prenons l’exemple de la relation entre un Produit et une Catégorie du site e-commerce pour illustrer.

Dans le cahier des charges de notre site e-commerce, il est mentionné :

Un Produit appartient à une seule catégorie

On peut donc modéliser de la façon suivante :

C’est le cas le plus simple. Il y a une référence (représentée via la flèche) au niveau de l’entité Produit vers l’entité Catégorie. Autrement dit, nous avons un attribut “Catégorie” dans l’entité “Produit” qui contient la référence unique de la catégorie. Ainsi, nous pouvons facilement lister les produits d’une catégorie donnée par exemple.

Maintenant, le cahier des charges change :

Un Produit peut avoir plusieurs catégories

Développeur :

Arghhh ! T’aurais pas pu le dire avant ?!

Le modèle précédemment choisi ne convient plus car quelle référence unique allons-nous mettre dans l’attribut Catégorie ?

Il faut donc créer une entité un peu spéciale qui lie les deux que l’on pourra appeler LienProduitCategorie.

Cette entité a deux attributs : référence unique du produit (flèche vers produit) et référence unique de la catégorie (flèche vers catégorie). Avec ce modèle, nous pouvons lier un produit à autant de catégories que l’on souhaite.

Rien n’empêche naturellement d’ajouter des attributs spécifiques dans l’entité ProductCategoryLink. Comme la date à laquelle le produit a été assigné à telle catégorie.

Tiens tiens, ce n’est pas ce genre de modélisation qui permettrait à Facebook de vous dire quand est-ce que vous avez intégré un groupe par exemple ?

Le mot de la fin

Même s’il est simplifié, cet article peut sembler compliqué. Il est nécessaire toutefois pour une personne non technique de comprendre les mécanismes afin de mettre sur papier son idée et discuter de façon pragmatique avec un développeur. Le travail du développeur est d’autant plus simplifié si le modèle de données est déjà établi.

À noter, qu’il ne doit pas y avoir de lien entre le modèle de données et la technique associée. En effet, peu importe le type de base de données que vous utilisez (SQL, NoSQL orienté document, NoSQL orienté colonnes…), votre modèle de données reste le même car il modélise votre métier dans l’absolu. L’implémentation technique change en fonction de la solution de stockage et du framework/langage de programmation.

Pour aller plus loin, vous pouvez lire des articles sur le modèle de classes UML.

Si vous avez besoin d’aider pour modéliser votre modèle, n’hésitez pas à nous contacter : hello@apiloop.io ou à tester notre solution https://www.apiloop.io.