Chapitre 2 Exercice 2-1 DF élémentaire pas DF car des élèves peuvent avoir le même nom DF car on ne stockera que le premier prénom (DF élémentaire aussi) DF élémentaire DF élémentaire pas DF car plusieurs enseignants peuvent être dans le même bureau DF élémentaire DF élémentaire DF élémentaire pas DF car un étudiant peut s'inscrire à plus d'une UV DF mais pas élémentaire, car codeEtu-->nom est une DF DF mais pas élémentaire, car codeUv-->moyUv est une DF DF mais pas élémentaire, car codeUv-->titreUv est une DF pas DF car un étudiant peut avoir plusieurs notes à différentes UVs pas DF car un étudiant peut avoir plusieurs notes à une UV DF élémentaire DF élémentaire pas DF car une UV concerne plusieurs contrôles DF élémentaire pas DF car un contrôle regroupe plusieurs notes pas DF car un enseignant peut écrire plusieurs rapports lors de différents contrôles pas DF car plusieurs rapports peuvent être écrits lors d'un contrôle DF mais pas élémentaire, car codeEns,nCont --> rappSurveillance est une DF élémentaire DF élémentaire Avec 3,4 et 5 par transitivité on trouve codeEtu --> adresse, prenom (3'). 4 devient redondante. 9 est non directe à cause de 7 et 8. Les ensemble de DF regroupées par partie gauche sont : E1 = {1, 5, 3'} E2 = {8} E3 = {9} E4 = {12, 13} E5 = {16} E6 = {17} E7 = {20} E8 = {23} E9 = {24} Le modèle relationnel en troisième forme normale est le suivant. E1[codeEtu, nom, ninsee, adresse, prenom] E2[codeEns, nomEns#] E3[nomEns, telEns] E4[codeUV, moyUV, titreUV] E5[codeEtu#, codeUV#, note_uv] E6[codeEtu, codeUV, note_uv] E7[nCont, codeUV#] E8[codeEns#, nCont#, rappSurveillance] E9[codeEns#, codeSalle, nCont#, tempsPasse] Remarque : les relations E2 et E3 peuvent être fusionnées (dénormalisation de la troisième forme normale) car codeEns et nomEns jouent le rôle de clés candidates : E2_3[codeEns, nomEns, telEns]. Exercice 2-2 Il faut appliquer la transitivité puis l'union. Il faut appliquer des augmentations puis l'union. L'astuce est d'utiliser la réflexivité pour obtenir "z" en partie gauche d'une DF. Exercice 2-3 Les DF sont les suivantes : numlivre -> titre, editeur, anneedit titre -> nbexemplaires codetu -> nometu, adretu numlivre -> datederpret titre -> editeur codeauteur -> nomauteur codeauteur, titre -> ordreauteur codetu, numlivre -> datepret Historique La DF à ajouter est codetu, numlivre, dsortie -> dretour. Le diagramme UML met en oeuvre deux classes- associations. Cette modélisation permet à un étudiant d'emprunter plusieurs fois dans l'année le même exemplaire. Exercice 2-4 La DF (4) est non directe car issue de la transivité de (1) et de (2). Les DFs (6) et (1) par pseudo-transitivité donnent a,a -> d (donc a->d qu'on appelle 6'). Les DFs (8) et (1) par pseudo-transitivité donnent a,a -> c (donc a->c qui est une DF éliminée par aileurs). Donc la DF (8) est redondante. Les DFs (9) et (1) par pseudo-transitivité donnent a,a,f -> h (donc a,f->h). Par ailleurs, les DF (1) et (5) donnent a->f par transitivité. En conséquence, la DF a,f->h se réduit à a->h par pseudo- transitivité (on l'appelle 9'). Les ensemble de DF regroupées par partie gauche sont : E1 = {1, 3, 6', 9'} E1 = {2, 5} E1 = {7} E1 = {10} Le modèle relationnel en troisième forme normale est le suivant. E1[a, b#, d#, h] E2[b, c, f] E3[d, g] E4[a#, i, j] Le diagramme UML se déduit naturellement en traduisant les clés étrangères en associations et les clés primaires composés en classes-associations. Le modèle relationnel déduit est le suivant. CompagnieAerienne[codeComp, nomComp, budget] Aeroport[codeOACI, nomAero, nbPistes, capacite, OACIsuperviseur#] Relier[codeOACI1#, codeOACI2#, km] Guichet[codeOACI#, codeComp#] Les DF induites sont les suivantes : codeComp -> nomComp, budget codeOACI -> nomAero, nbPistes, capacite, OACIsuperviseur codeOACI1, codeOACI2 -> km codeOACI, codeComp -> NULL Exercice 2-6 Le modèle relationnel déduit est le suivant. Personnel[numPers, nomPers, salaire] Aeroport[codeOACI, nomAero, nbPistes, capacite] Compagnie[codeComp, nomComp, budget] Effectif[numPers#, codeOACI#, codeComp#] Embaucher[numPers#, codeComp#] Les DF induites sont les suivantes : numPers -> nomPers, salaire codeOACI -> nomAero, nbPistes, capacite numPers, codeOACI -> codeComp numPers, codeComp -> NULL Exercice 2-7 Le modèle relationnel déduit est le suivant. Pays[codePays, nbhabitant] Musée[numMus, nomMus, nblivres, codePays#] Visiter[numMus#, jour, nbvisiteurs] Ouvrage[ISBN, nbPage, titre, codePays#] Bibliothèque[numMus#, ISBN#, dateAchat] Site[nomSite, anneedecouv, codePays#] Referencer[nomSite#, numeroPage, ISBN#] Relier[nomSite1#, nomSite2#, distance] Les réponses des assertions sont les suivantes : Non, rien n'est inscrit sur le schéma qui corresponde à cela. Oui le nombre de visite dépend du couple (musée,jour). Non, une page peut être associée à plusieurs couples (ouvrage,livres) : "1,N". Il peut l'être par la cardinalité "1,N" du côté de "Site". Les DF induites au niveau du site sont les suivantes : nomSite -> anneedecouv, codePays nomSite1,nomSite2 -> distance nomSite, ISBN, numeroPage -> NULL Exercice 2-8 Le modèle relationnel déduit est le suivant. On choisit de transformer l'héritage par distinction. Client[num, nom, adresse, numtel] Compte[nCompte, solde, dateOuv, num#] Courant[nCptCour#, nbOpCB] Epargne[nCptEpar#, txInt] Employe[numEmp, nomEmp] DroitSignataire[nCptCou#, num#, droit, numEmp#] Mouvement[nCptCour#, dateOp, num#, montant] Quelques explications de la modélisation : Un client peut avoir différents comptes de différentes natures. Un compte courant peut être manipulé par différents signataires qui ont un seul droit par compte. Le droit est donné par un employé de la banque. Une opération est un transfert (positif ou négatif) réalisé par un client d'une somme d'un compte courant. Les DF induites au niveau du compte courant sont les suivantes : nCptCour -> nCompte nCptCour -> nbOpCB nCptCour, num -> droit, numEmp nCptCour, dateOp, num -> montant Exercice 2-9 1. Le modèle relationnel déduit du schéma de l'exercice 1.3 est le suivant. Caracteristiques[typeAvion, nomAvion, npMax] Compagnie[comp, nomComp] Avion[immatriculation, capacite, comp#, typeAvion#] Affreter[immatriculation#, comp#] VolJour[(immatriculation, comp)#, dateVol] Vol[(immatriculation, comp, dateVol)#, heure, minute, nbPax, cout] Affreter et VolJour ne deviendront pas forcément des tables. Seule "Vol" contiendra les données caractérisant chaque affretement. En conséquence, les clés étrangères peuvent être modifiées, dans le cas ou ni Affreter, ni VolJour ne deviennent des tables : Vol[immatriculation#, comp#, dateVol, heure, minute, nbPax, cout] Un modèle objet qui privilégie l'accès aux vols par l'avion est le suivant (on utilise une collection dans la classe Avion. Les références sont indiquées en italique. Caracteristiques[typeAvion, nomAvion, npMax] Compagnie[comp, nomComp] Avion[immatriculation, capacite, refCompagnie, refTypeAvion, {refCompagnie, dateVol , heure, minute, nbPax, cout}] 2. Le modèle relationnel déduit du schéma de l'exercice 1.5 est le suivant. Portable[numPortable, typeCombine] Internet[formule, prixpMois, heureSupp] Abonne[numAbonne, nomAbonne, adresse, consoLocale, consoNationale, consoInternet, consoMobiles, consoAutres, debitLigne, numTel, formule#, numPortable#] Fournisseur[URL, adresseFourni, responsable] Historique[(formule#, URL#, premierContact, finContrat] Reduction[numAbonne#, telPrefere, dureePrefere] Un modèle objet qui privilégie l'accès aux fournisseurs d'accès Internet est le suivant. Deux collections sont présentes, la première qui liste les numéros de téléphone préférés, la seconde qui réalise l'association plusieurs-à-plusieurs entre fournisseurs et formule Internet. Portable[numPortable, typeCombine] Internet[formule, prixpMois, heureSupp] Abonne[numAbonne, nomAbonne, adresse, consoLocale, consoNationale, consoInternet, consoMobiles, consoAutres, debitLigne, numTel, refInternet, refPortable, {telPrefere, dureePrefere}] Fournisseur[URL, adresseFourni, responsable, {refInternet,premierContact, finContrat}] 3. Le modèle relationnel déduit du schéma de l'exercice 1.6 est le suivant. Club[nClub, aerodrome, nomClub] Competiteur[nComp, nomComp, pays, nClub#] Avion[immat, typeAvion, nClub#] Utilisation[immat#, nComp#] Vol[(immat, nComp)#, dateVol, typeProgramme] Inventeur[nInventeur, nomInv, typePilote] Figure[nFigure, nomFig, dateCreation, pageManuel, noteMax, nInventeur#] Notes[(immat, nComp, dateVol)#, nFigure#, note] Liste[(immat, nComp, dateVol)#, nFigure#, numeroChrono] Un modèle objet qui privilégie l'accès par les compétiteurs va utiliser des collections dans cette classe. Club[nClub, aerodrome, nomClub] Avion[immat, typeAvion, refClub] Inventeur[nInventeur, nomInv, typePilote] Figure[nFigure, nomFig, dateCreation, pageManuel, noteMax, refInventeur] Competiteur[nComp, nomComp, pays, refClub, {refAvion}, {refAvion, dateVol, typeProgramme}, {refAvion,dateVol,refFigure,note,numeroChrono}] Exercice 2-10 Le modèle relationnel déduit du schéma est le suivant. Agent[codea, noma] Vehicule[nimmat, totalkm] Chantier[numch, adresse] Mission[nimmat#, datem, km, codea#, numch#] Transporter[datem, codea#, nimmat#] Un modèle objet qui privilégie l'accès par la date pour les transportés, les chantiers et les véhicules utilise une collection dans laquelle chaque ligne représente une mission. Pour chaque mission une autre collection imbriquée recense les passagers transportés. Agent[codea, noma] Vehicule[nimmat, totalkm] Chantier[numch, adresse] Mission[datem, {refVehicule, km, refAgent, refChantier, {refAgent} }] Le diagramme UML équivalent est le suivant.