Avant de commencer à travailler avec les données, il faut les modéliser afin d'assurer que leur utilisation soit simple et que les données puissent évoluer avec les besoins futurs.
La modélisation des données comprend trois phases :
Afin de bien visualiser comment les données seront regroupées dans la base de données, il est intéressant de commencer par modéliser un diagramme de classes.
Il s'agit d'un schéma dans lequel on dessine une boîte par regroupement d'information. À ce stade, chaque regroupement est en fait une classe. Ces classes deviendront plus tard les tables de la base de données.
Dans chaque classe, on spécifie les attributs qui représentent les informations qui seront enregistrées, par exemple une description, une quantité, une adresse.
On ajoute finalement des lignes qui représentent les relations entre les classes.
Le diagramme de classes est la représentation la plus près des données telles que les non-informaticiens se les représentent.
Le terme diagramme de classes provient de la méthodologie UML (Unified Modeling Language), que nous utiliserons dans cette formation.
Vous constaterez qu'il y a beaucoup de parallèles à faire entre la modélisation de données UML et la programmation objet.
Selon la méthodologie de modélisation utilisée, le diagramme de classes peut porter différents noms :
Voici quelques exemples de diagrammes de classes :
Par exemple :
Notez que dans ces schémas, il n'y a pas de sens aux relations. Plutôt que d'écrire « un étudiant étudie dans un établissement », on aurait aussi bien pu écrire « un établissement admet des étudiants ».
Dans un diagramme de classes, un identifiant est un attribut spécial dont le rôle est d'identifier chaque occurence de la classe de façon unique. Chaque classe doit avoir un identifiant. Les identifiants deviendront les clés primaires lorsqu'on créera les tables de la base de données.
L'identifiant est toujours souligné dans le diagramme de classes.
Dans les premiers temps des bases de données relationnelles, les bonnes pratiques dictaient que pour chaque classe, il fallait sélectionner un attribut dont la valeur était unique. Cet attribut jouait le rôle d'identifiant. Par exemple, dans une classe de produits, l'attribut code était un bon identifiant. Dans le cas où aucun attribut ne permettait de représenter chaque occurence de façon unique, et seulement dans ce cas, on ajoutait un attribut supplémentaire qui servait d'identifiant.
Dans ces années, les coûts de stockage étaient faramineux. C'est pourquoi les spécialistes des bases de données tentaient toujours d'utiliser un attribut existant comme identifiant.
De nos jours, les coûts de stockage de données sont minimes. Aussi, plutôt que de choisir un attribut existant comme identifiant, il est d'usage de toujours ajouter un attribut, généralement nommé id. Ceci facilite la programmation ainsi que la maintenance des applications qui utilisent la base de données.
Dans le contexte où chaque classe a un identifiant qui s'appelle id, il n'est pas nécessaire d'ajouter les identifiants dans le diagramme de classes. Il s'agit d'une information qui n'apporte rien de concret à la représentation.
Notez qu'un diagramme de classe qui représente les identifiants nommés id est tout de même considéré correct.
Le schéma logique de données, parfois appelé modèle logique de données (MLD), correspond à la structure de la base de données : ses tables, ses champs et les relations entre les tables.
Il est obtenu à l'aide de manipulations faites à partir du diagramme de classes :
Voici nos diagrammes de classes convertis en schémas logiques de données :
Le schéma physique de données, ou modèle physique de données, va un peu plus loin que le schéma logique. Dans cette représentation, on ajoute simplement un type et possiblement une taille à chacun des champs. On ajoute également les contraintes d'intégrité référentielle.
Pourquoi ne pas avoir fait cette opération directement à partir du diagramme de classes ? Simplement parce que les types de données peuvent varier d'un SGBD à l'autre. Par exemple, avec MySQL, on pourrait avoir un nom d'établissement de type VARCHAR(50). Sous SQLite, on aura plutôt le type TEXT.
Pour illustrer ces différences, voici le schéma physique pour la base de données du système scolaire en deux exemplaires : un sous MySQL et l'autre sous SQLite.
Les différences de représentations dépendent du logiciel utiisé. Ce que vous devez remarquer, ce sont les types de données qui varient d'un SGBD à l'autre.
« Faites une base de données avec UML ». Open Classrooms. https://openclassrooms.com/courses/faites-une-base-de-donnees-avec-uml/apprehendez-les-objets-et-le-modele-relationnel
« UML et les Bases de Données - IRIT ». Grégory Claude. https://www.irit.fr/~Thierry.Millan/CNAM-NFP107/UML%20et%20les%20Bases%20de%20Donn%C3%A9es.pdf
▼Publicité
