Académique Documents
Professionnel Documents
Culture Documents
Préambule 2
Définitions synthétiques 2
11 - Règle du 80/20 31
Nous pouvons définir une base de données comme une collection structurée d'informations non
nécessairement du même type mais généralement relatives à une thématique ou une discipline
donnée. La base de donnée crée est usuellement disposée sur un même support, généralement
informatisé (numérique).
Nous effectuerons notre apprentissage sur un exemple très simple, la gestion des notes d'étudiants
(tout le monde sait ce qu’est un fichier de notes).
Nous verrons dans ce tutorial plusieurs notions sans qu’on puisse pour autant parler de cours
magistral sur les bases de données. L'idée maîtresse est que vous soyez rapidement opérationnels
sans perdre trop de temps à assimiler des concepts trop théoriques. Vous verrez que la logique et le
bon sens sont essentiels dans ce travail. Ce tutorial est ainsi assez axé sur la pratique permettant de
développer, concevoir et réaliser une base de données assez rapidement sur ACCESS tout en mettant
en scène les principaux concepts associés à la notion de base de données. Les étudiants très curieux
pourront trouver sur le web une foule de cours théoriques portant sur les bases de données qui
contribueront à étoffer leurs connaissances, bien que cela ne soit pas nécessaire.
Nous verrons ainsi à travers ce premier exemple les notions de : bases de données relationnelles et
de Système de Gestion de Base de Données Relationnelles (SGBDR), de modèle conceptuel des
données, de modèle logique des données, d'entités, d'attributs, de relations (encore appelées
liaisons ou associations) et de cardinalités. Mais aussi bien d'autres choses encore, sans que vous
vous en rendiez vraiment compte. Il sera l'occasion de faire vos premières armes sur ACCESS, un
logiciel très utilisé, vous offrant ainsi une compétence recherchée.
Pascal RIGOLET
Enseignant à Paris-Saclay
Définitions synthétiques
(loin d’être uniques et loin d’être parfaites)
- SGBDR (Système de Gestion de Base de Données Relationnelles) : logiciel moteur qui pilote
la base de données et en permet la manipulation et l’exploitation (interrogation,…)
La modélisation est une étape fondamentale de la conception d’une base de données dans la mesure
où, d’une part, on y détermine son contenu et, d’autre part, on y définit la nature des relations entre
les principales entités qui la constituent. Une situation à modéliser peut conduire à plusieurs
schémas différents, chaque modèle présentant des avantages et des inconvénients.
Il existe une méthode pour réaliser (construire) une base de données : la méthode MERISE
Sans le savoir, ou même l’évoquer, on va appliquer les principes de cette méthode et faire preuve de
bon sens.
MERISE :
Vocabulaire de spécialiste
Faite pour organiser le travail des informaticiens (dès les années 60-70) et rendre le traitement
de l’information structurée plus performant
Modèle conceptuel des données vision pratique de la base de données
L’essentiel est conçu avec une feuille de papier et un crayon ! C’est la première étape du travail.
La phase papier/crayon doit être suffisamment claire et exacte pour passer à la pratique
immédiatement. Ceci implique de procéder à une étape de «brain storming» puis d’établir et de
suivre un cahier des charges. Finalement le schéma des relations doit conduire à la réalisation
d’une première version de la base ACCESS faisant passer le Modèle Conceptuel des Données
(MDC) à un Modèle Logique de Données (MLD)
- Validation du modèle
Brain Storming
Il est très simple et évident dans cet exemple. Ce n’est pas toujours le cas
Rassembler les données en catégories et répertorier les entités qui vont composer la base
Sans trop compliquer la procédure, quelques catégories d’informations (entités) nous viennent à l’esprit :
???
Commençons donc par éclater et catégoriser l’information pour faire apparaitre les différentes
entités et leurs attributs (ceci va permettre de repérer les futures tables et de définir les futurs
champs des enregistrements). On repère ainsi assez facilement ainsi qu’au moins deux entités
(catégories ; tables) peuvent être créées regroupant une information cohérente. Il reste un
problème : où ranger les notes ?
En nous intéressant à l’information la plus facile à définir, trois entités peuvent être en fait
rapidement identifiées. Nous les représenterons par des rectangles et les identifierons de façon
explicite à l’aide d’un identificateur unique que nous mettrons dans un cadre au-dessus du rectangle
de l’entité (ici : Etudiants, Matières et Enseignants). Une quatrième entité, nommée « Autres»,
contiendra les informations dont le traitement ou la catégorisation n’est pas évidente; c’est le cas
des notes elles-mêmes. Chacune des entités est définie par des attributs (propriétés caractérisant les
entités) dont les noms sont indiqués les uns en dessous des autres dans les rectangles des entités
(ex : noms ; prénom ; date_naissance pour l’entité Etudiants).
Notes
Résultats ??
A ce stade, nous ne pouvons progresser dans le développement du modèle conceptuel des données
sans définir une phrase simple et claire rendant compte du contexte de la création et de la gestion
des données dans la base. Il va donc falloir proposer (plusieurs essais sont parfois nécessaires) une
phrase permettant de placer la base de données dans un certain contexte. Cette phrase permettra
de définir plus facilement la façon dont les entités sont reliées entre elles.
Aussi surprenant que cela puisse paraître, une base de données est associée à un contexte que l’on
peut décrire (on peut même aller jusqu’à dire qu’il y a une histoire sous-jacente)
> La phrase doit rassembler tous les éléments définissant le contexte (acteurs + actions)
Le contexte (répété autant de fois que nécessaire) dans cette base est :
L’étudiant machin a obtenu la note de X/20 dans la matière Truc enseignée par l’enseignant
Bidule
A l’issue d’un examen, la note de X/20 a été obtenue par l’étudiant machin dans la matière
truc enseignée par l’enseignant bidule
Simplifions alors, dans un premier temps, la problématique pour essayer de définir un modèle
répertoriant les inscriptions des étudiants aux matières proposées dans les différentes UEs ou
formations (inscriptions pédagogiques, par exemple). Oublions donc, pour le moment, l’Entité
« Autres ». Ce qui donne l’ensemble suivant :
La phrase « l’étudiant machin suit la matière truc enseignée par l’enseignant bidule » va nous
permettre d’établir une première série de relations entre les 3 entités Etudiants, Matieres et
Enseignants.
On représentera une liaison par une ellipse traversée et prolongée par un trait et contenant le
verbe à l’infinitif qui contribue le mieux à définir la nature, le contexte et le type de la liaison établie
entre deux entités distinctes. Une liaison peut avoir des attributs (précisant son contexte). On
portera une attention toute particulière aux verbes employés, qui seront à l’origine des relations
(associations, liaisons) que l’on pourra établir entre les entités.
Relation « un à un » (1 à 1)
Table_Etudiant 0 ,1 0, 1 Table_Bicyclette
1 Posséder
0, 1 0, 1
1 étudiant circule avec 1 vélo qui est le sien donc n’appartient qu’à lui
Il n’est pas dit que tous les étudiants possèdent un vélo et qu’il n’existe pas de vélo sans propriétaire
Ici le verbe est « posséder »
0 à 1 étudiant « possède » 0 à 1 vélo
Et 0 à 1 vélo « est possédé » par 0 à 1 étudiant
Relation « un à plusieurs » (1 à N)
Table_Matiere 1 ,1 1, N Table_Enseignant
Enseigner
1, 1 1, 1
1 matière est enseignée par un ou plusieurs enseignants ; chacun d’eux n’enseignant qu’une seule
matière
Hypothèses : toutes les matières sont enseignées (par au moins un enseignant)
Chaque enseignant enseigne une et une seule matière
Ici le verbe est « enseigner »
1 à 1 enseignant « enseigne » 1 à 1 matière
Et 1 à 1 matière « est enseignée » par 1 à N enseignant(s)
Table_Etudiant 0 ,N 0, N Table_Matiere
Suivre
0, N 1, N
1 matière est suivie par un ou plusieurs étudiants ; chacun d’eux suivant aucune à plusieurs matière
Hypothèses : - les étudiants inscrits mais ne suivant pas les cours ne suivent aucune matière
- certaines matières ne sont suivies par aucun étudiant (option n’ouvrant pas cette année-là)
Ici le verbe est « suivre »
0 à N étudiant(s) « suit » par 0 à N matières(s)
Et 1 à N matières(s) « est/sont suivie(/s) » 0 à N étudiant(s)
A l’issue d’un examen, la note de X/20 a été obtenue par l’étudiant machin dans la matière
truc enseignée par l’enseignant bidule
(on remarque que la note obtenue est un attribut de la relation « passer un examen »)
Hypothèses de travail : une matière peut être enseignée par plusieurs enseignants mais un enseignant
n’intervient que dans une seule matière (d’où la relation 1 à N figurant sur le schéma du MCD)
L’étape suivante va consister à transformer le Modèle Conceptuel des Données (MCD) en Modèle
Logique des Données (MLD) avant de passer à la pratique de la réalisation (et du renseignement) de
la base avec un ACCESS (ou tout autre SGBDR, tel par exemple php/Mysql).
Il n’est pas toujours aussi évident que cela de déterminer quel type de relation (ou cardinalité) doit
être utilisée entre 2 tables de la base.
Prenez l’habitude de définir les cardinalités (minimum et maximum possibles) dans les deux sens.
Répondez pour cela à la question suivante : pour un enregistrement de la première table considérée
combien peut-il y en avoir dans la seconde table ?
De plus, essayer d’associer un verbe (à l’infinitif) dans le schéma qui résulte de cette relation.
Dans le Modèle logique de données, les entités deviennent des tables et les attributs deviennent des
champs
Afin de mieux assurer la portabilité de la base de données dans le monde anglo-saxon, nous
enlèverons les accents présents dans les identificateurs de tables et de champs (nous verrons que
cela facilitera la réalisation des requêtes).
Rq : On peut également (je le déconseille) créer un lien provisoire dans une requête
Dans le modèle conceptuel de donnée, l’information portée par la relation « enseigner » n’apporte
pas d’information particulière. La relation 1 à N se définit donc simplement par un lien entre les
champs code_enseignant et ID_enseignants
Dans le modèle conceptuel de donnée, une relation de type N à M (ou « plusieurs à plusieurs ») se
transforme en table (dite de liaison). Elle apporte, outre les champs permettant l’échange
d’information (en général gérée par codes), des champs permettant de mieux contextualiser la
relation (ici : la date de l’examen et, bien sûr, la note obtenue à cet examen). Appelons cette table
« Tables_notes ». Il apparait, et c’est logique, que la table note est la table principale (ou centrale) de
la base de données ; c’est elle qui apporte toute l’information variable (en oposition à l’info figée
contenue dans la Table_Etudiant, la Table-Matiere ou encore la Table_Enseignant).
Nous constatons que la table principale est une table intermédiaire, celle qui contient les notes que
les étudiants ont obtenues dans les différentes matières. Les principaux éléments définissant le
contexte de la création de la base de données sont réunis dans ce schéma.
Astuce : d’une façon générale, on peut avoir intérêt, ne serait-ce que pour gagner du temps, à définir
d’emblée une table centrale qui contient les champs les plus impliqués dans le contexte de la base de
données (quitte à revoir, à posteriori, le schéma des relations).
Il y aura autant de notes que de couples (matière,étudiant) : notes(matière,étudiant)
Ce schéma est bien compatible avec le fait que plusieurs matières peuvent être enseignées par un
enseignant, qu’un enseignant peut intervenir dans plusieurs matières, qu’il a plusieurs étudiants, que
les étudiants peuvent avoir plusieurs profs et plusieurs matières et que chacune des matières
regroupe plusieurs étudiants.
Maintenant que l’étape de conceptualisation est terminée, nous sommes maintenant prêts à
passer à la réalisation de cette première version dans ACCESS (ou dans tout autre SGBDR)
(La création de la base de données avec d’autres version d’ACCESS procède d’une démarche
très voisine de celle employée ci-dessous)
Remarque : Sans attendre d’avoir terminé l’ébauche du modèle logique des données, il est déjà
possible commencer la prise en main du logiciel ACCESS (étape de création des 3 premières tables
par exemple).
Nous abordons ici l’aspect du contenu pour la première fois.
Commençons par créer une base Access qui contiendra l’ensemble des données structurées sous le
nom note1.accd (note1.mbd si créée avec la version 2003) ; il faut toujours miser sur la prudence en
numérotant les versions de la base de données pour garder une trace de sa réalisation progressive et
archiver les versions fonctionnelles dans un répertoire « Versions ».
Pour créer une nouvelle base il faut commencer par créer une « base de données vide » ; c’est la
règle sous ACCESS.
Laissez-vous guider par les commandes, les fonctions et autres options que proposent les menus
déroulants et les boutons du logiciel. Vous verrez que la prise en main est assez intuitive et rapide.
On y retrouve déjà les rubriques habituelles de création et gestion de fichiers, d’édition et de
manipulation de données.
A ce stade, vous venez de facto de créer une base de données vide. Il faut maintenant commencer à
organiser son contenu et créer les tables prévues à l’étape de conception (figurant sur le schéma).
Il est clair que 4 tables (les entités du MCD deviennent des tables) vont être créées l’une après l’autre.
- renseigner les noms des champs et le type des données (ne pas se tromper dans les formats).
On peut ajouter des champs à n’importe quel moment en basculant vers le mode création
- enregistrer la table en cours (soit à l'aide d'un clic droit puis Enregistrer, soit en basculant en
mode feuille de données, ce qui engendre automatiquement une fenêtre demandant si l’on veut
enregistrer les modifications)
Table_enseignant
Table_matière
Table_étudiant
Id_prof texte (‘nom’)
Id_matiere numéro auto clé primaire
matière texte Id_etudiant numéro auto clé primaire
intitule texte
tel numérique nom texte
coef numérique (entier)
(entier) prenom texte
e-mail texte
Table_notes Id_INE numérique
Il est logique de commencer par définir le format de la table (contenant) en précisant la structure des
champs des enregistrements, répondant à des types de données précis. On bascule donc en mode
création (en cliquant sur le bouton "Affichage").
Dès lors la définition précise de chacun des champs composant les enregistrements peut commencer
Il est assez simple de définir chacun des champs par son identificateur et son type. On pourra
avantageusement utiliser les cases Description pour saisir des commentaires et préciser certains
éléments. L’unicité de l’information n’étant pas garantie avec le nom ou même avec le couple (nom,
prénom), elle le sera grâce au numéro ID de l’étudiant. On associe alors (avec le bouton clé primaire,
cerclé en rouge sur la figure, ou à l’aide d’un clic droit souris / choix clé primaire) la clé primaire sur
le champ ID_etudiant
On remarque que la structure des enregistrements est décrite de telle façon qu’à chaque ligne
correspond la définition d’un champ dans l’ordre de leur rencontre.
On voit que les enregistrements sont affichés les uns après les autres selon la structure que l’on a
définie en mode création, à raison d’un enregistrement par ligne. Les colonnes de la table
correspondent ainsi aux champs des enregistrements crées (le champ ID_etudiant est
automatiquement incrémenté d’une unité à chaque enregistrement crée, on ne s’en occupe pas).
Nous pouvons récupérer les noms des étudiants depuis un fichier texte
Table_notes
On a créé un champ code_etudiant (ajouté dans la table table_étudiant) pour avoir un numéro unique.
Dans table_étudiant : clic droit Id_etudiant clé primaire (ou clic direct sur clé primaire)
Quand un champ correspond à la clé primaire il ne peut pas être supprimé (il faut au préalable
supprimer l’attribut « clé primaire »)
Table_étudiant
Table_matière
Id_etudiant numéro auto clé primaire
nom texte Id_matiere numéro auto clé primaire
prenom texte intitule texte
e-mail texte coef numérique
Id_INE numérique code_enseignt numérique
Table_enseignant
1 plusieurs
Hypothèses :
1. un étudiant a plusieurs notes mais une seule par matière
2. Un enseignant peut enseigner plusieurs matières
3. Chaque matière à son coefficient
4. Il y a un seul correcteur par matière
Exercice :
Comment transformer cette structure pour tenir compte du fait qu’une matière peut également
faire intervenir plusieurs enseignants (il y a plusieurs solutions) ?
Listes de choix
Dans table_matière il faut pouvoir imposer que le coefficient soit compris dans une liste :
- On crée une nouvelle table ‘Table_coef’ avec un seul champ ‘coef_matiere’ qui est
numérique.
- Dans ‘Table_matiere’ on change le type de données (si cela ne marche pas effacer le champ
puis recommencer) et on sélectionne ‘assistant liste de choix’ au lieu de ‘numérique’.
Assistant liste de choix doit rechercher dans ‘table,….’, on choisit ‘Table_coef’ puis le champ
‘coef_matiere’.
- Ainsi lorsque l’on veut renseigner d’un coefficient dans le champ ‘coef’ on dispose d’un
ascenseur qui nous permet de choisir parmi les valeurs de ‘coef_matiere’ dans la
‘Table_coef’.
- !!! Attention !!! on peut mettre d’autres valeurs, si l’on veut rester dans la fourchette
donnée par la ‘Table_coef’ il faut aller dans valide si … >0 Et <=5
Attribut
Base_Notes : notes [ étudiant, matière, enseignant, date ]
Transformation de la base de données des notes pour intégrer le champ code_enseignant dans la
table Table_note et relier cette table à la table Table_enseignant (relation N à M)
Ceci va autoriser l’application de l’hypothèse : plusieurs enseignants peuvent enseigner dans une
même matière et un enseignant peut enseigner plusieurs matières
Vous pouvez réarranger l’organisation des tables dans le schéma des relations afin de faire
apparaître la table Table_enseignant sous la table Table_matiere. De cette façon, le nouveau lien se
construira plus facilement et l’on y gagnera en présentation.
Il est alors possible de rajouter un champ dans la table Table_note dont le contenu sera partagé avec
l’identificateur de l’enseignant. Bouton de souris droit puis choix « insérer des lignes ». Ensuite
création du champ (numérique) correspondant à la clé étrangère : code_enseignant.
Il ne nous reste plus qu’à créer le lien « 1 à N » (« 1 à plusieurs ») entre la table Table_note et la table
Table_enseignant par l’intermédiaire du partage de contenu entre les champs code_enseinant
(Table_notes) et ID_enseinant (Table_enseignant). N’oubliez pas de fermer les tables concernées
pour créer ce nouveau lien.
Pour finir, supprimez le champ code_prof de la table Table_matiere qui ne sert plus à rien.
Ainsi construite, la base de données est encore plus performante. Nous avons atteint là un bon
niveau de MDC (Modèle Conceptuel des Données).
La clé primaire est définie sur les champs code_etudiant et code_matiere pour éviter les doublons
dans l’attribution des notes
Table_notes
Table_etudiant
Table_matiere
Id_etudiant numéro auto clé primaire
nom texte Id_matiere numéro auto clé primaire
prenom texte intitule texte
e-mail texte coef numérique
Id_INE numérique code_enseignt numérique
Table_enseignant
SQL : System Query Langage langage de programmation reconnu par Access (transparent pour nous)
But : pouvoir sortir la liste des étudiants pour chaque spécialité + pouvoir sortir la liste des spécialités
pour chaque étudiant (1 ou plusieurs)
Créer une nouvelle table. Chaque étudiant peut suivre une ou plusieurs spécialités. Créer une table
avec la liste des spécialités pour pouvoir choisir dans la ‘Table_master’ la spécialité dans la liste
‘Liste_master’.
Table_master_étudiant
Règle du 80/20 :
code_etu numérique
Permet de combiner indépendamment des
code_specialite numérique
informations nouvelles corrélées (spécialités = intitulé
précis du master)
Soit la nouvelle table ‘Table_master’ est en
Table_étudiant amont de ‘Table_matière’, soit la ‘Table_master’
directement reliée par une relation de 1 à plusieurs (1
Id_etudiant numéro auto clé primaire
à n) à la ‘Table_étudiant’.
nom texte
prenom texte
e-mail texte
Id_INE numérique Les requêtes permettent d’afficher (ou non) cette
nouvelle information avec les autres.
Table_master
Liste_master
Id_master numéro auto clé primaire
Intitule liste Nom_master texte
Responsable texte
11 - Règle du 80/20
Le parfait n’existe pas, il faut déjà faire quelque chose de bien. Apprendre à travailler vite et bien.
Aller à l’essentiel (au plus évident).
Les étapes de la construction d’une base de données relationnelle peuvent être résumées comme suit :
1/ décrire, à l’aide d’une phrase scénario, le contexte de la création de la base de données relationnelle ;
3/ établir une liste des attributs pour chacune des entités et, parmi eux, un identifiant ;
4/ construire les relations entre les entités et leur donner un nom (généralement un verbe à l’infinitif) ;
5/ ajouter, si nécessaire, des attributs propres à chacune des relations et définir les cardinalités ;
12/ Validation de la base avec les utilisateurs, dans une situation réelle
La qualité d’une modélisation de type entités-relations peut être évaluée à l’aide de plusieurs
critères utilisables de manière combinée :
- L’expressivité (qui traduit la richesse sémantique du schéma et qui peut être caractérisée par
- La minimalité (qui tend à privilégier les schémas avec un nombre de redondances minimales) ;
- La simplicité (qui privilégie les schémas contenant un nombre de concepts minimal et qui peut
Exercice :
l’administrateur de la base qui gère les informaticiens (créent le SGBD, définissent les requêtes,
fonctions, validations etc…), les personnes qui renseignent la base de données (donnent un contenu
fiable à la base) et celles qui saisissent les données.
Besoin de faire des tests pour révéler le maximum d’erreur mises à jour de la base.
A l’issue de ce travail, nous sommes prêts à nous intéresser à des considérations plus
environnementales