corrections TD1

Solutions du TD1 : M1 MIAG et INFO
2008-2009
Exercice 1 :
class Client {
attribute string nom;
attribute string addr;
attribute string téléphone;
attribute integer Numss;
relationship Set<Compte> Possède
inverse Compte::PossédéPar;
}
class Compte {
attribute integer num;
attribute string type;
attribute real solde;
relationship Set<Client> PossédéPar
inverse Client::Possède
}
Exercice 2
class Personne ne {
attribute string nom;
relationship Personne mèreDe
inverse Personne::enfantDeFemelle
relationship Personne pèreDe
inverse Personne ::enfantDeMale
relationship Set<Personne > enfant
inverse Personne ::parentsDe
relationship Set<Personne > enfantDeFemelle
inverse Personne :: mèreDe
relationship Set<Personne > enfantDeMale
inverse Personne :: pèreDe
relationship Set<Personne > parentsDe
inverse Personne :: enfant
}
Notons qu’il y a six relations ici. Par exemple, l'inverse de la relation qui relie une Personne à
leur (unique) mère est une relation qui relie une mère (c'est-à-dire, une Personne de sexe
féminin) à l'ensemble de ses enfants. Cette relation, que nous appelons EnfantDeFemelle, est
différente de la relation des enfants, qui relie toute personne - homme ou femme - de leurs
enfants.
Exercice 3
Struct dip {string nom, string lieu, string date} diplôme
Exercice 4.1
Nous pensons que numéro de sécurité sociale doit être la clé de la classe Client, et le numéro
de compte doit être la clé pour la classe compte. Voici la solution ODL avec les déclarations
des clés et de l’extent. (page 36)
class Client
(extent Clients key NumSS)
{
attribute string nom;
attribute string addr;
attribute string téléphone;
attribute integer NumSS;
relationship Set<Compte> Possède
inverse Compte::PossédéPar;
}
class Compte
(extent Comptes key num)
{
attribute integer num;
attribute string type;
attribute real solde;
relationship Set<Client> PossédéPar
inverse Client::Possède
}
Exercice 4.2
Puisque la relation entre les clients et les comptes est many-many le schéma relationnel est le
suivant.
CLients(NmuSS, nom, address, téléphone)
Comptes(num, type, solde)
ClientCompt(NmuSS, num)
Exercise 4.3
Il y a seulement un attribut, et trois paires de relations de Personne à lui-même. Puisque
mèreDe et pèreDe sont deux relations de type many-many, on peut enregistrer leurs inverses
dans la relation de personne. Pour chaque Personne, EnfantDemale et EnfantDefemmelle
indiquera père et mère de Personne. La relation Enfants est many-many, et exige sa propre
relation. Cette relation en réalité s'avère être redondante, dans le sens ou ses tuples peuvent
être déduits des relations enregistrées avec Personne. Le schéma est le suivant:
Personnes (nom, EnfantDeFemelle, EnfantDeMale)
Parent-Enfant(parent, enfant)
Exercice 5
(1) Struct Carte {
enum valeur {2,3, 10,valet, Roi, AS} val ;
enum coul {pique, coeur, carreau, trèfle} couleur;
}
(2.2) Type main : set(Carte);
(2.2) class Mains {
attribute Set(carte) Lamain;
}
(3) Mains(MainId, valeur, couleur)
Notons que la classe Mains n’ a pas de clés, donc nous avons besoin de créer une clés :
MainID. Chaque main a, dans la relation Mains, un tuple pour chaque carte dans la main.
(4)
Struct Joueur-Main {string nomJoeur, Main SaMain }
class Mises {
attribute Set (Joeur-Main) laMise
}
Rq : Joueur-Main peut être définie directement dans la déclaration de l'attribut LaMise.
Comme suit :
class Mises {
attribute Set (Struct Joueur-Main {string nomJoeur, Main
SaMain } LaMise ;
}
(5)
Puisque la classe Mains et la classe Mises n’ont de clés, pour concevoir le schéma de relation
il faut avoir une relation qui lie entre les paires Mises et joueur-Main, et une autre relation
pour spécifier le contenu de la classe Mains.
Mises(MiseID, nom-Joueur, MainID)
Mains(MainID, valeur, couleur)
Toutefois, on peut se débarrasser de MainID et de lier la mise et le joueur directement aux
cartes de joueur :
Mises(MiseID, nom-joueur, valeur, couleur)
(6)
Tout d'abord, la carte est un ensemble constitué d'une valeur et d’une couleur, nous avons
donc besoin de deux attributs dans un schéma de relation pour représenter des cartes.
Toutefois, et le plus important est le fait que le schéma proposé ne distingue pas la carte qui
est dans la main. Ainsi, nous avons besoin d'un autre attribut qui indique à quelle main, dans
la mise, qu’une carte appartient :
Mises(MiseID, MainID, valeur, couleur)