[DOC] Master1, ESC, 2011/2012 UE : Introduction aux Bases de Données ...

Les trois exercices sont indépendants. NB : toutes les réponses doivent être justifiées. Exercice 1 Modélisation entités-associations et production du schéma de ...

Part of the document


Master1, ESC, 2011/2012
UE : Introduction aux Bases de Données
TD N°1 : le Modèle Entité-Association (éléments de solutions)


Exercice 1 : (Modèle E-A)











Expliquer brièvement ce schéma en indiquant les concepts du modèle E-A
impliqués.
Solution :
Dans ce schéma, il est présenté :
. A gauche, une entité nommée Medecin et ayant pour identifiant la
propriété code. Les autres propriétés de cette entité sont Nom,
Prénom, Adresse, Age et Grade.
. A droite, les occurrences de l'entité Médecin (ne sont présentées que
quatre).
Il est présenté aussi les occurrences des différentes propriétés, y compris
l'identifiant. Nous avons :
. Les différentes occurrences de l'identifiant sont : 01, 02, 14 et 37.
. Les différentes occurrences de la propriété Nom sont : Mokhtar,
Debouz, Meddour et Allouche.
. Etc.

Exercice 2 : (Modèle E-A)











1. Expliquer ce schéma
2. Indiquer les cardinalités dans les deux cas suivants:
a. Tournoi de tennis (matchs joués en simple exclusivement)
b. Tournoi de tennis (matchs joués en simple et en double)
Solution :
1. Le schéma représente un MCD (ou, un diagramme E-A), composé de 2
entités (Match, Joueur) et de deux associations binaires (Jouer,
Gagner). L'entité Match a pour propriétés code (c'est l'identifiant),
Nom, Lieu et Score. L'entité Joueur a pour propriétés N-Joueur (c'est
l'identifiant), Nom, Prénom, Age et Nationalité.
Dans ce schéma, on peut lire :
a. Un match est joué par un (des) joueur(s), un joueur joue dans un
(plusieurs) match(s).
b. Un match est gagné par un (des) joueurs (s), un joueur gagne un
(plusieurs) match(s).
Cardinalité (dans le cas où on est dans un match de tennis) :
a. Si les matchs sont joués en simple exclusivement : un match est
joué à deux, il n'y a qu'un seul gagnant, chaque joueur peut jouer
plusieurs matchs (au moins 1, puisqu'il est déjà dans le tournoi)
et chaque joueur peut gagner plusieurs matchs comme il ne peut n'en
gagner aucun : donc la cardinalité de l'association Jouer est 2,2
côté Match, et 1,N côté Joueur ; et la cardinalité de l'association
Gagner est 1,1 côté Match, et 0,N côté Joueur.
b. Si les matchs sont joués en simple et en double : un match est joué
à deux ou à quatre, il peut y avoir un seul gagnant (dans le cas
des matchs en simple), comme il peut y avoir deux gagnants (dans le
cas des matchs en double), chaque joueur peut jouer plusieurs
matchs (au moins 1, puisqu'il est déjà dans le tournoi) et chaque
joueur peut gagner plusieurs matchs comme il ne peut n'en gagner
aucun : donc la cardinalité de l'association Jouer est 2,4 côté
Match, et 1,N côté Joueur ; et la cardinalité de l'association
Gagner est 1,2 côté Match, et 0,N côté Joueur.
Remarques : il est préférable, dès ce stade, de suivre des règles de bonne
conduite :
. La propriété Nom est dupliquée ; elle existe dans Match et dans
Joueur. On procède comme suit ; dans Match, remplacer la propriété Nom
par Nom_Match, et dans Joueur, remplacer la propriété Nom par
Nom_Joueur.
. On peut harmoniser les deux identifiants : code et N-Joueur peuvent
être remplacés par CodeMatch et CodeJoueur.
Oui mais pas de problème car tous les attributs seront remplacés par des
codes synonymes lors de l'implémentation de la base de données. (donc pas
de souci)

Exercice 3 : (premier pas vers une BDD)
Dans une université (prenons comme exemple l'Ecole Supérieure de Commerce),
nous avons recensé les entités suivantes : étudiants (omar, fodil, fadéla,
...), notes (10, 12, ...), examens (1er Examen, 2ème Examen, Examen de
Rattrapage), enseignants (Mammeri, Bouchama, ...), Unité d'enseignement
(bases de données, introduction aux systèmes d'information, introduction au
commerce électronique, ...), départements (Finance, Management, ...),
salles (salle 1, ...), labos (labo1, ...), bureaux (B1, B2, ...).
1. Proposer un identifiant et quelques propriétés pour chaque entités.
2. Donner, dans le modèle E-A, le schéma correspondant pour chaque entité
(souligner l'identifiant, et écrire le nom de l'entité en majuscule).
3. Trouver des associations binaires entre les entités précédentes (deux à
deux). Compléter les cardinalités pour en obtenir des diagrammes Entité-
Association. Interpréter les associations avec leurs cardinalités.
4. Trouver d'autres entités et d'autres associations, et construire les
diagrammes correspondants.
Solution : (l'exercice est à revoir, pour le bien fixé, mais il peut faire
quand même un sujet de discussion)
Étudiant (idÉtudiant, NomÉtud, PrénomÉtud)
Enseignant (idEnseignant, NomEns, PrénomEns)
UE (idUE, NomUE, coefficient)
Département (idDépartement, NomDépart)
Bureau (idBureau, lieu, étage, porte, téléphone)
Salle
Examen
Labo
....
Occuper1 (Enseignant, Bureau)
Occuper2 (Département, Bureau)
Enseigner (Enseignant, Étudiant) non un enseignant est en lien avec groupe
ou classe pas avec étudiant
Assurer (Enseignant,UE)
Responsable1 (Enseignant, Département)
Responsable2 (Enseignant, UE)
Notes(etudiant, ue, date)
Se deroule (examen, salle)
Appartient (examen, module).....
Les étudiants peuvent appartenir à des groupes. Pour une année donnée, un
étudiant ne peut appartenir qu'à un seul groupe.
Groupe (idGroupe, libelléGroupe)
Cours (enseignant, groupe, salle)
Faire partie (Étudiant, Groupe), l'association peut posséder une propriété
Année (c'est à discuter).

Exercice 4 : (BD École Doctorale)
Une université veut construire une base de données pour gérer une école
doctorale. La base de données gère des étudiants qui effectuent une thèse
dans une équipe de recherche et sont encadrés par un chercheur. Une équipe
de recherche appartient à un laboratoire dirigé par un chercheur. Dans ces
équipes de recherche, travaillent des chercheurs et chaque équipe est
dirigée par un chercheur.
1. Recenser les différentes entités que doit manipuler la base de données.
2. Identifier toutes les associations possibles entre ces entités.
3. Proposer un identifiant pour chaque entité.
4. Proposer des propriétés pour chaque entité.
5. Proposer un modèle E-A pour cette base de données.
6. Calculer toutes les cardinalités.
Solution :
1. Les entités sont marquées en bleu gras.
2. Les associations sont marquées en rouge gras.
3. Chercheur (idChercheur), Equipe (idEquipe), Etudiant (idEtudiant),
Laboratoire (idLabo)
4. Chercheur (idChercheur, Nom_Chercheur, Prénom_Chercheur,
Mail_Chercheur, Tél_Chercheur), Equipe (idEquipe, Nom_Equipe,
Web_Equipe), Etudiant (idEtudiant, Nom_Etudiant, Prénom_Etudiant,
Mail_Etudiant), Laboratoire (idLabo, Nom_Labo, Adresse_Labo, Web_Labo)
5. Doctorant dans [Etudiant1,1, Equipe0,N] ; est encadré [Etudiant1,1,
Chercheur0,N] ; appartenir à [Equipe1,1, Laboratoire1,N] ; est dirigé
par [Laboratoire1,1, Chercheur0,1] ; travailler dans [Chercheur1,1,
Equipe1,N] ; diriger [Chercheur0,1, Equipe1,1]
6. Voir réponse 5.

Exercice 5 : (BD d'une Discothèque Personnelle)
Soit une collection d'albums de musique, comprenant plusieurs types de
support (K7, CDsimple, CDdouble, 33trs, 45trs, MP3, ...), et évidemment
plusieurs artistes.
Vous voulez identifier les albums que vous prêtez à vos ami(e)s
référencé(e)s dans une liste « d'abonné (e)s ».
Ceci peut être représenté par un modèle E-A.
Faire le schéma du MCD, en représentant les entités (souligner les
identifiants), les propriétés ou attribut (au minimum, deux par entité),
les associations entre entités, ainsi que les cardinalités.
Envisager les deux cas suivants : (à construire deux MCD, un pour chaque
cas)
1. Le cas où un album peut exister sur plusieurs types de support.
2. Le cas où un album n'existe que sur un seul type de support.
Rappel méthodologique : un des attributs de l'entité Abonné sera
Nom_Abonné, soit le nom de la personne qui a emprunté un album.
Solution :
1. Les entités sont marquées en bleu gras. (type support support) donc
deux entité différentes de type père fils
2. D'après le texte, on peut synthétiser comme suit :
. un album peut exister sur plusieurs supports.
. Un support appartient à un seul type de support.
. Un album peut être prêté à plusieurs abonnés (ou amis) : pas
l'album qui est prêté mais le support, logiquement il existe
plusieurs supports (exemplaires) pour un album, en plus dans une
discothèque on doit gérer l'emprunt des supports (aller - retour
des supports)
Attention un même abonné peut prendre le même album plusieurs
fois mais sur des supports différents, on doit connaitre donc
les supports de prêt pour éviter le vol et pour garder
l'historique
. Dans un album, peuvent participer plusieurs artistes.
Les associations qu'on peut ressortir sont :
Exister sur [Album, Support]
Etre prêté [Album support , Abonné]
Participer [Artiste, Album]
3. album (idAlbum, titreAlbum), support (idSupport, libéléSupport),
artiste (idArtiste, nomArtiste, prénomArtiste), abonné (idAbonné,
nomAbonné, prénomAbonné, telAbonné)
4. Cas ou un album existe sur un seul support :
Participer [album1,N, artiste0,N] ; Exister sur [album1,1,
support0,N] ; Etre prêté [album0,1, abonné0,N]
Remarque : dans ce cas, on peut enlever l'entité Support et la
remplacer par une propriété dans l'entité Album.
5. Cas ou un album existe sur plusieurs supports :
Participer [album1,N,