Design d'un modèle de données

Pourquoi utiliser un modèle de données

Lorsque l'on travaille sur une base de données complexe (multiples tables, multiples relations), il est utile d'avoir une représentation des tables et de leurs relations pour pouvoir composer nos requêtes, particulièrement celles avec des jointures.

Il existe de multiples méthodes de modélisation, parmi lesquelles l'UML et Merise. L'une comme l'autre sont des sujets complexes qui nécessitent un cours à part entière.

Pour le moment, nous allons utiliser une modélisation très simplifiée, mais qui va déjà nous permettre de nous y retrouver.

Représenter une table

Pour cet exemple, nous allons tenter de représenter une table users. Cette table contient, un id, un email, un password et une date de création.

Votre table est donc représentée par un bloc de couleur, avec en haut, le nom de la table, séparé du reste par un trait.

Ensuite pour chacune des champs de votre table une ligne indique le nom du champ et son type.

Représenter une relation simple

Pour cet exemple, nous allons garder notre table users et rajouter une table posts. Un post a un id, un titre, un contenu, une date de publication et un auteur, qui pointera sur l'id de la table users.

Une relation est représentée par une flèche qui part de la table qui contient la Foreign Key, vers la table qui est référencée par cette Foreign Key.

Représenter une relation complexe

Pour cet exemple, nous gardons nos tables users et posts et nous allons rajouter une table categories. Une category a un id, un nom et une description.

Chaque postpeut avoir plusieurs categories.

Lorsqu'une table peut être liée plusieurs fois à une autre, on appelle on crée une table intermédiaire, appellée table de liaison qui stocke les relations entre différentes lignes des tables. Ici chaque ligne dans la table post_categories représentera la relation entre un post et une category.

Représenter une table qui fait référence à elle-même

Il arrive parfois qu'une table soit en relation avec elle-même, particulièrement si vous gérez des hérarchies d'information. Nous allons modifier un peu la table categories et lui ajouter un champ parent ce qui va permettre de modéliser le fait que nous ayons des catégories et des sous-catégories.

Notre modèle complet