Modélisation d'une base de données

1. Bases de données

Une base de données est un espace de stockage pour contenir des données de manière plus ou moins structurée ainsi qu'un logiciel pour pouvoir y accéder de manière efficace.

Il existe plusieurs types de bases de données: hiérarchique, en arbre, en réseau, sous formes de fichiers (JSON ou XML) ou de graphes, etc. mais nous n'approfondirons qu'un seul type, très courant et très robuste: les bases de données relationnelles. Dans celles-ci, les données sont stockées sous forme de "tables". Les systèmes de bases de données relationnelles permettent généralement de garantir dans une très bonne mesure la pérennité des données (les données persistent même en cas de panne), la cohérence des données (il est très peu probable d'aboutir à un état de "corruption" des données) et l'absence de redondances (la même donnée n'apparaît pas à deux endroits différents).

2. Entités et Attributs

Avant de constituer une Base de Données, il est recommandé d'en établir un modèle.

La première étape consiste à regrouper les données que l'on veut modéliser sous forme d'entités. Une entité est une classe d'objets, qui sont tous décrits avec les mêmes types de donnée. Ces données (chaînes de caractère, nombres, ...) qui caractérisent l'entité sont nommées attributs (ou propriétés).

On peut représenter une entité avec ses attributs par un diagramme. L'entité est représentée par un rectangle, auquel se rattachent les propriétés symbolisées par des ovales.

Par exemple, si on veut modéliser une base de donnée musicale, une entité possible serait un Morceau de musique, dont les propriétés seraient par exemple le nom, la durée et la date d'enregistrement.

On voit bien que les attributs correspondent à des types de donnée faciles à représenter sous forme informatique, tandis que l'entité se détache un peu de l'aspect technique pour représenter quelque chose (abstraction) qui nous intéresse dans le domaine qui est modélisé.

3. Relations entre Entités

Les entités appartenant à une même base de données peuvent être en relation(*) les unes avec les autres.

La caractéristique principale d'une relation entre deux entités est sa cardinalité, c'est-à-dire le nombre d'entités d'un côté qui sont en relation avec une entité de l'autre côté de la relation.

Dans une relation 1-à-1 (aussi appelée 1-1), chaque instance d'une entité est en relation avec une seule instance de l'autre entité.
Dans un diagramme, ce "1" peut être indiqué par une petite barre perpendiculaire à la ligne indiquant la relation.

Dans une relation 1-à-plusieurs (aussi appelée 1-n), une instance de l'entité d'un des deux côtés est en relation avec plusieurs instances de l'entité de l'autre côté.

Dans le diagramme ci-dessus, une instance de l'entité A peut être en relation avec plusieurs instances de l'entité B, mais chaque instance de l'entité B ne peut être en relation qu'avec une seule instance de l'entité A.

Enfin, dans une relation plusieurs-à-plusieurs (aussi appelée n-n), chaque instance d'une entité peut être en relation avec plusieurs instances de l'autre entité et vice-versa.

Dans l'exemple de la base de donnée musicale, nous pouvons décider qu'un morceau est en relation avec un seul artiste, lequel par contre peut avoir composé plusieurs morceaux (relation 1-à-plusieurs), mais qu'un morceau peut correspondre à plusieurs genres musicaux, chacun desquels peut aussi correspondre à plusieurs morceaux (relation plusieurs-à-plusieurs).

(*) NB: nous utilisons le mot relation mais c'est ici un anglicisme et un abus de langage: normalement on devrait parler d'association, la relation étant en principe le lien entre les différents attributs d'une entité; l'avantage de l'anglicisme et de pouvoir comprendre plus facilement les multiples ressources disponibles en anglais, où il est toujours question de diagrammes "ER", pas "EA"

3.1. Relations avec valeur minimale

En plus de préciser si une relation est 1-1, 1-n ou n-n, on peut entrer un peu plus dans le détail et se demander de chaque côté de la relation s'il y a au moins 1 instance de l'entité de l'autre côté de la relation ou bien peut-être 0.

Si on souhaite ce niveau de détail, on peut ajouter un 0 ou un 1 (barre verticale) à côté du symbole de "1" ou "plusieurs", afin d'indiquer, par exemple "exactement 1" ou "entre 0 et 1" (exemple ci-dessous):

Ci-dessus, chaque instance de l'entité A est en relation avec 0 ou 1 (entre 0 et 1) instance de l'entité B (donc en relation, ou pas), tandis que chaque instance de l'entité B est en relation avec exactement 1 instance de l'entité A (entre 1 et 1).

Ci-dessous, une instance de l'entité A peut être en relation avec 0, 1 ou plusieurs instances de l'entité B (entre 0 et n), tandis qu'une instance de l'entité B est en relation avec exactement une instance de l'entité A (entre 1 et 1).

Si on reprend l'exemple musical, on pourrait par exemple préciser qu'un artiste pourrait ne jamais avoir enregistré de morceau (donc il est en relation avec 0, 1 ou plusieurs morceaux) tandis qu'un morceau est composé par exactement 1 artiste:

Évidemment, ce n'est pas le seul choix de modèle possible. On doit bien se poser la question de ce que l'on veut modéliser et comment.

3.2. Diagramme Entité-Relation détaillé

Si on assemble tout ce qui a été indiqué précédemment, on aboutit à un diagramme entité-relation complet, qui peut aussi inclure les attributs. 

Ce diagramme peut évoluer en cours de route lorsque l'on améliore son modèle, par exemple en ajoutant des attributs supplémentaires à une entité ou en précisant un peu plus une relation. On peut aussi décider de donner un nom à certaines relations, auquel cas on l'inscrit sur la ligne symbolisant celle-ci.

4. Tables d'une base de données

Une fois que l'on est satisfait de son modèle, on peut traduire le diagramme entité-relation final en un diagramme des tables, qui correspondent alors à ce qui sera implémenté concrètement dans la base de donnée relationnelle afin de réaliser le modèle. Ce diagramme sert alors aussi de schéma pour la base de donnée concrète.

Une table est constituée de champs, avec un nom et un type de donnée, et d'entrées, ou lignes, contenant une valeur pour chaque champ.

Entités et clés primaires

Lors de cette étape, chaque entité devient une table, dont les champs correspondent aux attributs de l'entité.

De plus, on ajoute habituellement à chaque table un champ supplémentaire nommé clé primaire. C'est un champ contenant par exemple un nombre entier généré automatiquement de manière unique pour chaque nouvelle entrée dans la table. Ce nombre n'est jamais réutilisé par la suite, même si l'entrée concernée est effacée. C'est comme un "compteur" pour les entrées de la table, permettant de se référer de manière claire et sans ambiguïté à une entrée donnée. On peut choisir un autre type pour une clef primaire comme un texte à condition que sa valeur soit bien unique pour chaque entrée. Par exemple, le code international à 2 ou trois lettres pour chaque pays. Dans certains cas, on peut même choisir une combinaison de plusieurs champs pour former une clef une clef primaire.

Dans l'exemple ci-dessous, on représente la table correspondant à l'entité Artiste avec son unique attribut nom et sa clé primaire (CP). À ce stade, il est indispensable que les noms de tables et de champs ne soient constitués que de lettres non accentuées et du caractère "_" ("caractère souligner"). Conventionnellement, les noms de champs sont uniquement en minuscules, tandis qu'un nom de table peut commencer par une majuscule.

NB: on peut aussi indique "PK" au lieu de "CP" pour la clé primaire, comme abréviation de l'anglais "primary key".

Relations et clés étrangères

Enfin, on doit traduire les relations vers les tables:

• pour une relation 1-à-1, on fusionne normalement les deux entités liées en une seule table, vu qu'une seule entrée suffit à décrire les deux entités liées
• pour une relation 1-à-plusieurs, on ajoute dans la table correspondant au côté "plusieurs" de la relation un champ spécial permettant d'indiquer avec quelle instance de l'entité du côté "1" de la relation une instance est liée (un champ suffit vu qu'il n'y a qu'une seule instance en relation de ce côté-là). Cela se fait grâce à une clé étrangère (indiquée comme CE, ou bien FK provenant de l'anglais "foreign key"), qui est simplement une référence à la clé primaire de l'autre côté de la relation. Une flèche indique le chemin d'une clé étrangère vers la clé primaire correspondante.
• pour une relation plusieurs-à-plusieurs, on crée une table supplémentaire, dont les deux champs sont des clés étrangères, qui ensemble constituent une clé primaire pour la relation (chaque combinaison de clés étrangères ne peut apparaître qu'une seule fois).

Ce qui précède devrait être plus clair avec un exemple.

Ci-dessus, les tables Morceau, Artiste, et Genre représentent des entités. Chacune possède sa clé primaire ainsi que des champs pour les attributs de l'entité. De plus, la table Morceau contient un champ de clé étrangère, concrétisant la relation 1-à-plusieurs avec l'entité Artiste: Un morceau peut être en relation avec uniquement un artiste, via la clé étrangère, mais plusieurs morceaux peuvent "pointer" vers le même artiste!

Enfin, la table MorceauGenre concrétise une relation plusieurs-à-plusieurs. Une entrée de cette table est constituée d'une paire de clé étrangères, "pointant" vers un morceau et un genre. Ainsi, un même morceau peut être lié à plusieurs genres, et un genre peut être lié à plusieurs morceaux, chaque lien correspondant à une entrée. Cependant, un même lien n'apparaît qu'une seule fois, donc une paire de clé étrangères devient simultanément la clé primaire de cette table un peu spéciale.

NB: si on a nommé la relation, on peut utiliser le nom de relation comme nom de table, plutôt que de combiner les noms des deux entités liées comme dans l'exemple ci-dessus.

5. Base de données relationnelle

Une base de donnée relationnelle concrète est constituée de tables. Chaque table à des colonnes, aussi appelées champs, et des lignes, aussi appelées entrées.

Une table représente soit une entité soit une relation plusieurs-à-plusieurs du modèle entités-relations.

Les tables représentant des entités ont normalement un champ spécial appelé clé primaire, qui peut par exemple consister en un nombre créé et géré de manière automatisée. La plupart des autres champs correspondent aux attributs de l'entité, c'est-à-dire aux données concrètes contenues dans chaque instance de l'entité. On peut aussi ajouter un ou plusieurs champs spéciaux appelés clés étrangères, dont le but est de "pointer" vers la clé primaire d'une autre table afin de représenter une relation un-à-plusieurs.

Vous pouvez concrétiser le schéma d'une base de donnée relationnelle grâce à l'application SqliteBrowser, disponible à l'école et installable librement ailleurs. Le schema concret est la définition, ou création, des tables avec leurs champs.

Attention: les noms des tables et des champs doivent commencer par une lettre et ne contenir que des lettres non accentuées, des chiffres et le symbole "_" .

Il est ensuite possible d'insérer des données, c'est-à-dire des entrées, chacune étant définie par une valeur donnée à chaque champ. On peut le faire directement dans sqlitebrowser ou bien par exemple depuis un programme en Python qui accède à la base de données. Dans une vraie application, cela serait fait par un programme qui demande des données à travers une interface graphique qui lui est propre ou bien crée directement les données ou les importe depuis une autre base de données.

En fait, aussi bien la création des tables que l'insertion des données se font toujours à travers le langage SQL, mais celui-ci peut être généré indirectement par une interface comme Sqlitebrowser. D'ailleurs, vous verrez toujours le code SQL généré.

Pour consulter la base de données, nous allons apprendre à écrire directement quelques requêtes SQL adaptées. Dans une vraie application, celles-ci seraient générés par le programme principal et leur résultat pourrait alors être utilisé dans celui-ci.