Bon, vous êtes connectés à votre BDD préférée et ce n'est pas parce que j'ai choisi PostgreSQL que vous avez dû en faire autant...
Cependant, celles et ceux qui n'ont pas fait le même choix que moi peuvent aller directement vers le sous-chapitre sur SQL (sauf s'ils ont déjà les bases, qu'ils aillent dans ce cas directement au chapitre suivant...).
Déjà, les bases de données servent à stocker des informations, ça, vous le savez !

Mais ce que vous ignorez peut-être, c'est que, pour ranger correctement nos informations, nous allons devoir analyser celles-ci...
Ce tuto n'est pas non plus un tuto sur l'analyse combinée avec des diagrammes entités-associations... Dans le jargon, c'est ce dont on se sert pour créer des BDD, enfin, pour organiser les informations (tables et contenu de tables) !
Nous allons juste poser un thème et nous ferons comme si vous saviez faire tout ça !

Pour ceux que la réalisation de modèles entités-associations intéressent, vous pouvez faire un tour
ici.
Voilà : pour notre base de données, nous allons gérer une école, dont voici les caractéristiques :
- cette école est composée de classes ;
- chaque classe est composée d'élèves ;
- chaque classe à un professeur de chaque matière dispensée par cette école ;
- un professeur peut enseigner plusieurs matières et exercer ses fonctions sur plusieurs classes.
Voilà le point ZÉRO de toute base de données !
Vous vous rendez compte qu'il y a beaucoup d'informations à gérer. Bon, en théorie, nous devrions faire un dictionnaire des données, voir à qui appartient quelle donnée, poursuivre avec une modélisation façon MCD (
Modèle Conceptuel de Données) et simplifier le tout suivant certaines règles pour terminer avec un MPD (
Modèle Physique de Données). Nous allons raccourcir le processus et je vais fournir un modèle tout fait, que je vais tout de même vous expliquer...
Tous ces beaux éléments seront nos futures tables. De plus, les attributs dans celles-ci se nomment des "champs".
Vous pouvez voir que tous les acteurs mentionnés se trouvent symbolisés dans ce schéma (classe, professeur, élève...). Vous constaterez que ces acteurs ont un attribut nommé '
id', ceci correspond à son identifiant : c'est un champ de type entier qui s'incrémentera pour chaque nouvelle entrée, c'est aussi grâce à ce champ que nous créons des liens entre nos acteurs.
Oui... Vous avez remarqué que j'avais colorié des tables en bleu.

Ces tables ont toutes un champ qui a une spécificité : un champ dont le nom se termine par '
_k'.
D'abord, vous devez savoir que la flèche signifie '
a un', de ce fait, un élève '
a une' classe !
Bon, on te suit, mais pourquoi les autres tables ont deux champs comme ça ?
C'est simple, c'est parce que je vous ai dit qu'un professeur pouvait exercer plusieurs matières : dans ce cas, nous avons besoin de ce qu'on appelle une
table de jointure.
Ainsi, nous pouvons dire que tel professeur exerce telle ou telle matière et qu'une association prof-matière est assignée à une classe !
La donnée que nous utiliserons pour lier des tables n'est autre que l'identifiant : id.
De plus - difficile de ne pas avoir vu ça - chaque champ à un type (entier, double, date, boolean...).
Nous avons tout ce dont nous avons besoin pour construire notre BDD !