Soit l'entité PROFESSEURS, celle-ci regroupe les professeurs de l'école.
Extrait de la table PROFESSEURS:
id_pro | nom_pro | preno_pro | diplo_pro | datenaiss_pro |
1 | Tartempion | Florimon | Master Mathématique, BAC Sciences, Agrégation | 29/03/1983 |
2 | Doe | John | Master Droit, Agrégation | 04/05/1960 |
3 | Vanpiperzeel | Sam | BAC Informatique, DAP | 21/07/1970 |
4 | Tartempion | Florimon | Régent Français | 29/03/1983 |
5 | Vancleemput | Petronela | Master Physique, Master Mathématique, Master Chimie, Agrégation | 14/10/1953 |
de conception
On constate que le champ diplo_pro peut recevoir plusieurs valeurs, on dit que ce champ est multivalué.
On peut imaginer qu'un programme récupère le champ et le découpe en autant de chaînes de caractères que de diplômes, certes. Mais la question est la suivante:
quelle taille allons-nous donner à ce champ? A priori on peut avoir 1, 5 ou 20 diplômes, et pourquoi pas 25 ou 40?
On butte sur un problème de type "catalogue", on ne peut pas donner de taille au champ diplo_pro!
de redondance
L'information concernant un diplôme est représentée plusieurs fois en différents endroits, on constate que "Master en Mathématique" est présent chez Florimon
Tartempion et Petronela Vancleemput par exemple.
de modification
Forcément, plusieurs professeurs ont le même diplôme, que faire dans le cas où il faut modifier l'intitulé d'un diplôme?
On sera obligé de rechercher tous les professeurs ayant ce diplôme et faire n fois la modification, le risque d'erreurs est très grand, l'intégrité des données n'est plus assurée.
On va sortir le champ diplo_pro et en faire une entité.
Dans un deuxième temps on va lier les deux entités au travers d'une relation qui reprendra les identificateurs des entités PROFESSEURS et DIPLOMES.
On constate que les anomalies citées plus haut sont résolues:
- on peut parfaitement définir une taille pour le champ diplo_pro
- il n'y a plus de redondance des données, seules les clés sont répétées.
- une modification concernera une et une seule donnée.
- chaque information est stockée en un et un seul exemplaire, cette notion est fondamentale pour garantir l'intégrité des données. En effet, tout modification d'une donné se fera en un et un seul endroit, les éventuelle erreurs de mise à jour seront dès lors très facile à détecter.
La relation AVOIR s'exprime comme suit:
- un professeur peut avoir un ou plusieurs diplômes
- un diplôme concerne un ou plusieurs professeurs
Généralisons:
- une occurence de la table PROFESSEURS est en relation avec 1 ou plusieurs (ou n) occurences de la table DIPLOMES
- une occurence de la table DIPLOMES est en relation avec 1 ou plusieurs (ou n) occurences de la table PROFESSEURS
- La relation AVOIR est de type (1-n) (1-n)
Extrait de la table PROFESSEURS:
id_pro | nom_pro | preno_pro | datenaiss_pro |
1 | Tartempion | Florimon | 29/03/1983 |
2 | Doe | John | 04/05/1960 |
3 | Vanpiperzeel | Sam | 21/07/1970 |
4 | Tartempion | Florimon | 29/03/1983 |
5 | Vancleemput | Petronela | 14/10/1953 |
Extrait de la table DIPOMES:
id_dip | intit_dip |
1 | Master Mathématique |
2 | BAC Sciences |
3 | DAP |
4 | Master Droit |
5 | BAC Informatique |
6 | Régent Français |
7 | Master Physique |
8 | Master Chimie |
9 | Agrégation |
Extrait de la table AVOIR:
ID_PRO | ID_DIP |
1 | 1 |
1 | 2 |
1 | 9 |
2 | 4 |
2 | 9 |
3 | 3 |
3 | 5 |
4 | 6 |
5 | 1 |
5 | 7 |
5 | 8 |
5 | 9 |
La relation PROFESSEURS-DIPLOMES est de type (1-n) (1-n)