Modélisez vos bases de données

Bon… résumons un peu ce que nous avons appris jusqu’à maintenant. Une base de données, c’est comme un entrepôt. Elle est destinée à alimenter un programme informatique, de la même manière qu’un entrepôt de matières premières alimente une usine textile. Entre les deux, il y a le SGBD, qui est comme l’entreprise qui gère l’entrepôt.

Comme nous l’avons vu, il existe des données très structurées et d’autres moins structurées. L’objet de ce cours, c’est d’apprendre à modéliser une base de données pour des données structurées (les données des lieux de tournage), ce qui implique que nous utilisions une base de données relationnelle.

Quand on organise un entrepôt, on commence par placer les rayonnages, qui sont des sortes d’énormes étagères qui accueilleront plus tard les matières premières. Mais ces rayonnages, il ne faut pas les disposer au hasard : avant même qu’ils accueillent leur marchandise, il faut connaître les caractéristiques de ce que l’on va y déposer :

• Le tissu sera-t-il stocké sous forme de rouleaux, ou dans des cartons ? 

• Quel sera le poids d’un rouleau de tissu ?

• Quelles seront ses dimensions ? 

Toutes ces informations sont cruciales pour choisir les étagères de la bonne taille et pouvant supporter le poids des cartons.

Concevoir la disposition des rayonnages, c’est modéliser votre entrepôt : et cela commence toujours par un schéma au papier-crayon (oui bon, aujourd'hui on peut aussi dessiner sur ordinateur, c’est vrai ! ;) ).

Si vous deviez modéliser un grand entrepôt, il y aurait plusieurs étapes :

1. Faire un brouillon de votre schéma. Vous l'exposez à votre équipe pour qu'elle vous donne son avis. Ici, il faut rester assez général : votre schéma doit être compréhensible par n’importe quelle personne : rien de très technique. 

2. Préciser de plus en plus votre modélisation. 

3. Déterminer les caractéristiques techniques de chaque étagère : dimensions précises, position, matériau (bois ? métal ?), etc. 

Pour modéliser une BDD, c’est le même principe : il y a plusieurs étapes, le plus souvent au nombre de trois :

1. La première sera un schéma généraliste et compréhensible de la structure de vos données.

2. La seconde sera plus adaptée à une représentation en tableaux.

3. La dernière sera plus technique et très spécifique au SGBDR que vous aurez choisi.

1. Construisez votre modèle conceptuel de données (MCD)

La première étape, c’est le modèle conceptuel des données (MCD). Elle se décompose elle-même en trois sous-étapes :

1. Cherchez les concepts présents dans vos données.

Par exemple, dans nos données des lieux de tournage, on a comme concepts :

• Les films ;

• Les réalisateurs ;

• Les lieux de tournage ;

• Les sociétés de production (plus couramment appelées « boîtes de production »).

2. Cherchez les associations qui existent entre ces concepts, par exemple :

• Un film est PRODUIT par une société de production ;

• Un réalisateur RÉALISE un film ;

• Un film EST TOURNÉ sur un lieu de tournage.

3. Caractérisez ces associations par une multiplicité, que vous indiquez grâce à des signes du type   0, 1, 1..*, 0..*,, etc. 

Pour dessiner le modèle conceptuel, il y a plusieurs possibilités. Les deux plus répandues sont :

• Le modèle Entité-Associations (E-A), qui fait partie de la méthode MERISE ;

• Le diagramme de classes, qui fait partie du langage de modélisation UML.

Dans leurs principes, ces deux méthodes de modélisation sont très similaires, même si elles utilisent des conventions graphiques un peu différentes. Par exemple, un modèle E-A ressemble à ceci :

Alors qu’un diagramme de classes UML ressemble plutôt à cela :

Non, l’un des deux suffit. 😎

2. Concevez votre modèle logique de données (MLD)

Le modèle conceptuel est un ensemble de concepts. Mais maintenant, il va falloir donner une structure à ces concepts.

Vous vous souvenez ? On a dit que des données structurées peuvent se représenter sous forme de tableaux. Eh bien c’est notre prochaine étape : formater tous nos concepts en des tableaux !

Vous allez construire le modèle logique des données (MLD). Ici, vous n’avez plus vraiment le choix entre plusieurs modes de représentation comme c’était le cas pour le MCD. Vous utiliserez la modélisation relationnelle.

La principale transformation pour passer de l’UML au modèle relationnel sera de transformer les multiplicités des associations en clés étrangères. Le concept des clés étrangères vous est étranger ? Ne vous inquiétez pas, vous y viendrons ! 🙂

Ici, vous vous rapprochez de la solution technique, car vous commencez à façonner vos données pour qu’elles puissent rentrer dans un SGBDR.

Voici un exemple de modèle relationnel :

Pas de panique ! En fait, le MLD découle du MCD. Pas besoin de trop réfléchir : il n’y a qu’à appliquer des règles de transformation basiques pour passer du MCD au MLD ;) .

3. Déterminez votre modèle physique de données (MPD)

Au bout d’un moment, il va bien falloir dialoguer avec la machine qui accueillera votre BDD. Et comme vous le savez, pour parler avec un ordinateur, on utilise du code ! Youpi ! ;)

La dernière étape est donc de traduire le modèle relationnel en code SQL compréhensible par le SGBDR que vous aurez choisi (PostgreSQL, MySQL, Oracle, SQLite, etc.).

Même si ces SGBDR comprennent tous le langage SQL, il existe parfois des différences. C’est-à-dire que chaque SGBDR a ses propres variantes du langage SQL.

Le SQL peut se décomposer en quatre langages :

• Le langage de définition de données (LDD ou DDL en anglais) : pour créer la structure de la BDD ;

• Le langage de manipulation de données (LMD ou DML) : pour insérer, actualiser, supprimer ou récupérer des données ;

• Le langage de contrôle des données (LCD ou DCL) : pour gérer les droits d’accès aux données ;

• Le langage de contrôle des transactions (LCT ou TCL) : pour la validation ou l’annulation de modifications de données.

Voici un exemple de LDD (création de table en SQL) :

CREATE TABLE film
(
    id_film INT PRIMARY KEY,
    titre VARCHAR(100),
    date_tournage DATE
)

Dans ce cours, nous ne verrons que les deux premiers niveaux : le MCD et le MLD. Quant au MPD, il nécessite d’utiliser le langage SQL et de choisir un SGBDR, puis de l’installer. Nous avons fait le choix de ne pas aller jusque-là pour conserver un cours court. Mais vous aurez la possibilité d’utiliser le SQL le cours Implémentez vos bases de données relationnelles avec SQL ou dans le cours Requêtez une base de données avec SQL.

Bon OK, je vais être gentil : il y aura un chapitre destiné à structurer vos données et à les rentrer dans le SGBDR SQLite (c’est le plus simple à utiliser). Quant au code SQL, je vous le donnerai et vous n’aurez qu’à le copier/coller. ;)

À vous de jouer !

Allez, je vous propose un petit exercice ! Je vous donne un modèle conceptuel d’une base de données, sous forme de diagramme de classes UML.

1. Essayez de deviner quel type de logiciel peut utiliser cette BDD.

2. Essayez ensuite d’aller plus loin, en imaginant quelles fonctionnalités propose ce logiciel, et comment l’utilisateur peut bien l’utiliser.

Réponse :

Il s’agit d’une BDD utilisée par un logiciel de gestion de commandes et de facturation (utilisé dans un magasin, par exemple).

Le logiciel permet d’enregistrer tous les articles en vente, où chaque article fait partie d’une catégorie. Il permet aussi d’enregistrer des commandes, lesquelles sont relatives à un ou plusieurs clients. Chaque commande a une adresse de livraison.

Lorsqu’une commande est expédiée, l’expédition est enregistrée automatiquement dans le logiciel, et une facture est associée à chaque expédition.

En résumé

Tableau valable pour des bases de données structurées :

Vous savez maintenant ce qu’est une modélisation de BDD. Mais sachez que toutes les modélisations ne se valent pas. En effet, nous verrons dans le chapitre suivant un critère fondamental d’une modélisation de qualité.