Une étude de cas, cours 5.

7
Une Etude de Cas
On va modéliser un même ensemble d’informations à l’aide des 3 modèles : relationnel,
à objet, et semi-structuré.
But : illustrer analogies et différences entre les trois approches, limites respectives, etc.
212
La BD des BD
Une bande dessinée a un ou plusieurs auteurs, qui sont scénaristes ou/et dessinateurs
et/ou coloristes de l’ouvrage en question. Elle a un unique éditeur, un unique titre, un
unique ISBN, un unique format et un unique prix.
Les mangas sont des bandes dessinées particulières, qui n’ont pas de coloriste mais ont
un attribut supplémentaire, sens de lecture, qui vaut gauche droite ou droite gauche.
Un auteur a un nom, parfois un prénom, une ou plusieurs adresses, parfois une
thématique, et parfois il est sous contrat d’exclusivité avec un éditeur.
Un éditeur a un nom, une adresse et parfois a des auteurs sous contrats.
Les adresses sont constituées d’un numéro, d’un nom de rue, d’une ville et d’un pays.
213
Une modélisation EA possible comporte 6 entités : voir au tableau.
214
Une Modélisation Relationnelle
On en déduit un schéma de base schéma avec 11 tables : BD, BD pas Mangas, Mangas,
Adresses, Infos Auteur, Auteur Adresses, Scénaristes, Dessinateurs, Coloristes,
Editeurs, Sous Contrat.
Chaque schéma de table est en BCNF (Forme Normale de Boyce Codd).
⇒
215
BD :
ISBN
format
larg
prix
Ident edit
Manga
Domaine de Manga : {“Oui′′ , “N on′′ }.
La clé (primaire) est ISBN.
Dépendances Fonctionnelles : toutes celles de la forme ISBN → A, où A est tout autre
attribut que ISBN.
Ce schéma de table est en BCNF : les seules dépendances fonctionnelles significatives
sont celles à partir de la clé.
216
M AN GAS :
ISBN
Send Lecture
La clé (primaire) est ISBN.
Evidemment, cette table est en BCNF.
217
P AS M AN GAS :
#ISBN
Code de pas Manga
Ici, ISBN, la clé de BD, est une clé étrangere.
Code de pas Manga est un idéntifiant propre à ces bandes déssinnées qui ne sont pas des
Mangas (donc qui admettent un coloriste).
Evidemment, cette table est en BCNF.
218
Inf os Auteur :
Id Aut
nom
prenom
thematique
Dépendances Fonctionnelles F :
Id Aut → nom, Id Aut → prenom et Id Aut → thematique
Clé : Id Aut
Ce schéma de table est en BCNF.
219
Adresses :
Code Postal
Num Civique
rue
ville
pays
Pour simplifier, on supposera ici que le Code Postal permette de retrouver tous les
attributs, donc que c’est la clé.
Et nous avons alors la BCNF, car il n’y a pas de dépendance fonctionnelle (significative)
X → A où X ne soit pas la clé.
220
Auteur Adresses :
Id Aut
Code Postal
NB : Le fait qu’il faut les deux attributs appartiennent à la clé (primaire) est du à
l’hypothèse qu’un auteur peut avoir plusieurs adresses et aussi à l’hypothèse que deux
auteurs peuvent vivre à la même adresse. Cette dernière était dans la modélisation EA,
mais n’était pas explicite dans le texte décrivant la situation à modéliser.
Les seule dépendances étant celles banales, c’est évident qu’on a la BCNF.
221
Scenaristes :
Id Aut
ISBN
NB : A nouveau, le fait qu’il faut les deux attributs appartiennent à la clé (primaire) est
du à l’hypothèse qu’un auteur peut être scénariste de plusieurs BD, et une BD donnée
peut avoir plusieurs auteurs, donc, en particulier, plusieurs scénaristes.
A nouveau, la BCNF est évidente.
222
Dessinateurs :
Id Aut
ISBN
NB : A nouveau, le fait qu’il faut les deux attributs appartiennent à la clé (primaire) est
du à l’hypothèse qu’un auteur peut dessiner plusieurs BD, et une BD donnée peut avoir
plusieurs auteurs, donc, en particulier, plusieurs dessinateurs.
A nouveau, la BCNF est évidente.
223
Coloristes :
Id Aut
Code de pas Manga
Comme pour Scenaristes et Dessinateurs mais, attention, ici Code de pas Manga
remplaçe ISBN. Pourquoi ?
224
Inf os Editeur :
Id Ed
nom
prenom
Code Postal
On peut prendre Id Ed comme clé car un éditeur a une adresses (à la différence d’un
auteur).
Toujours la BCNF.
225
Sous Contrat :
Id Aut
Id Ed
On peut prendre Id Aut comme clé car on a dit que si un auteur a un contrat avec un
éditeur, alors c’est un contrat d’exclusivité.
Toujours la BCNF.
226
Observer qu on peut repérer pour quelle bd un auteur donné est seulement scénariste et
pour quelle autre est aussi dessinateur, par exemple.
Et on a exprimé aussi la contrainte que les mangas n’ont pas de coloriste.
227
On n’exprime pas les “parfois” :
– On n’a pas exprimé qu’un auteur a parfois une thématique (donc il peut aussi ne pas en
avoir) ;
– On n’a pas exprimé qu’un auteur a parfois un prénom.
Pour pallier ces problème, il faudrait admettre des valeurs nuls. Remarquer que le
modèle relationnel “propre” ne veut pas de valeurs nuls ! Alternative : à la place de
Inf os Auteur(Id Aut,nom, prenom,thematique),
3 tables : Inf os Base Auteur(Id Aut,nom), Inf os P ren Auteur(Id Aut, prenom) et
Inf os thematiques(Id Aut, thematique). Dans la deuxième table, seulement les auteurs
dont on connaı̂t le prénom, dans la troisième, seulement les auteurs ayant une thématique.
228
On n’a pas exprimé, non plus, que tout auteur a au moins une adresse.
229
Une Modélisation Objet
Une parmi les modélisations possibles crée un schéma avec 6 classes : BD,
Mangas,Pas Mangas (où Mangas et Pas Mangas sont des sous-classes de la classe BD)
Auteur, Editeur, Adresse,
⇒
230
class BD (key ISBN extent les_bd) {
attribute string titre;
attribute integer ISBN;
attribute struct dimensions{float long, float larg} format;
attribute float prix;
relationship Set <Auteur> a_scénariste inverse Auteur::scénariste_de;
relationship Set <Auteur> a_dessinateur inverse Auteur:: dessinateur_de;
relationship Editeur a_éditeur inverse Editeur édite
}
231
class Mangas extends BD (extent les_mangas)
{attribute enum directions{GD,DG} sense_lecture}
class Pas_Mangas extends BD (extent les_pas_mangas){
attribute string code_pas_manga;
relationship Set<Auteur> a_coloriste
inverse Auteur::coloriste_de
}
232
class Auteur (key Id_Aut extent les_auteurs) {
attribute integer Id_Aut
attribute string nom;
attribute string prénom;
attribute string thématique;
relationship Set<BD> scénariste_de inverse BD::a_scénariste
relationship Set<BD> dessinateur_de inverse BD::a_dessinateur
relationship Set<Pas_Mangas> coloriste_de inverse Pas_Mangas::a_colorist
relationship Set<Adresse> a_adresse inverse Adresse::adresse_de;
relationship Editeur contrat_avec_ed inverse Editeur contrat_avec_aut}
class Editeur (key Ident_edit extent les_editeurs) {
attribute integer Ident_edit
attribute string nom;
relationship Adresse éd_a_adresse inverse Adresse::adresse_de_éd;
relationship Set<Auteur> contrat_avec_aut inverse Auteur contrat_avec_ed;
relationship Set<BD> edite inverse BD a_éditeur}
233
class Adresse (key (Code_Postal) extent les_addresses) {
attribute string Code_Postal,
attribute integer num;
attribute string rue;
attribute string ville;
attribute string pays;
relationship Set<Editeur> adresse_de_éd inverse Editeur::éd_a_adresse;
relationship Set<Auteur> adresse_de inverse Auteur::a_adresse
}
234
On peut repérer pour quelle bd un auteur est seulement scénariste et pour quelle autre est
aussi dessinateur, par exemple.
Mais on n’a pas exprimé la contrainte qu’un auteur a forcement au moins une adresse
(notre déclaration permet qu’un auteur ait un ensemble vide d’adresses).
235
On n’exprime pas les “parfois”, non plus :
– on n’a pas exprimé qu’un auteur a parfois une thématique et qu’il a parfois un prénom
(défaut, déjà, de la modélisation relationnelle)
– on n’a pas exprimé qu’un auteur a parfois un contrat.
Cette difficulté à exprimer le“parfois” est lié au fait que :
ODL ne permet pas de faire la différence entre :
- la contrainte qu’un objet o d’une classe C1 est lié, par une relationship, à un nombre
indéterminé n d’objets de C2 (n ≥ 0)
- la contrainte qu’un objet o d’une classe C1 est lié, par une relationship, à un nombre n
d’objets de C2 où n ∈ {0, 1}.
Pourquoi ?
Bien sûr, comme pour le relationnel, l’implémentation pourra utiliser des valeurs nuls,
pour pallier ce problème.
236
Une modélisation semi-structurée
Un DTD que l’on peut écrire : ⇒
237
<!ELEMENT BD (bande_dessinnée+, auteur+,editeur+, adresse+)>
<!ELEMENT bande_dessinée (manga|pas-manga)>
<!ELEMENT pas_manga (titre,format,prix)>
<!ATTLIST pas_manga code_pas_manga ID #REQUIRED
ISBN PCDATA #REQUIRED a_scénariste IDREFS #REQUIRED
a_dessinateur IDREFS #REQUIRED a_coloriste IDREFS #IMPLIED
a_editeur IDREF #REQUIRED>
<!ELEMENT manga (titre,format,prix)>
<!ATTLIST manga ISBN ID #REQUIRED a_scénariste IDREFS #REQUIRED
a_dessinateur IDREFS #REQUIRED a_editeur IDREF #REQUIRED
sens_lecture (GD|DG) #REQUIRED>
<!ELEMENT titre PCDATA>
<!ELEMENT format (long,larg)>
<!ATTLIST format unité_mésure CDATA #REQUIRED>
<!ELEMENT prix PCDATA>
<!ATTLIST prix dévise CDATA #REQUIRED>
<!ELEMENT long PCDATA>
<!ELEMENT larg PCDATA>
238
<!ELEMENT auteur (nom,prenom?,thématique?)>
<!ATTLIST auteur Id_Aut ID #REQUIRED scenariste_de IDREFS #IMPLIED
dessinateur_de IDREFS #IMPLIED coloriste_de IDREFS #IMPLIED
contrat_avec_ed IDREF #IMPLIED a_adresse IDREFS #REQUIRED>
<!ELEMENT nom PCDATA>
<!ELEMENT prenom PCDATA>
<!ELEMENT thématique PCDATA>
<!ELEMENT adresse (numéro, rue, ville, pays)>
<!ATTLIST adresse code_postal ID #REQUIRED
adresse_de_auteur IDREFS #IMPLIED
adresse_de_editeur IDREFS #IMPLIED>
<!ELEMENT numéro PCDATA>
<!ELEMENT rue PCDATA>
<!ELEMENT ville PCDATA>
<!ELEMENT pays PCDATA>
<!ELEMENT editeur (nom,adresse)>
<!ATTLIST editeur Id_Ed ID #REQUIRED édite IDREFS #REQUIRED
contrat_avec_aut IDREFS #IMPLIED a_adresse IDREF #REQUIRED >
239
On exprime :
– Les mangas sont des BD ;
– La contrainte qu’un auteur a forcement au moins une adresse (on a le + !)
– La contrainte qu’une Manga n’a jamais de coloriste.
– Pour une bd un auteur est seulement scénariste et pour une autre est aussi dessinateur,
par exemple.
240
On exprime les “parfois” :
– Un auteur a parfois une thématique (fils thématique ? de auteur) ;
– Un auteur a parfois un prénom (prénom ?).
– Un auteur a parfois un contrat (L’attribut contrat avec ed de auteur est
optionnel)
N.B. La possibilité de déclarer balise ? dans le DTD permet d’exprimer qu’une
relation lie un individu x à 0 ou 1 individus, chose qui ni le relationnel ni l’objet
permettent de faire.
241
A-t-on exprimé la contrainte qu’un cible d’un lien a scénariste doit forcement être
un noeud auteur ? (Même question pour a dessinateur et a coloriste).
Non : on peut écrire un document xml où, pour une bd, a scénariste pointe à une
autre bd, par exemple, et le document sera validé !
En général, dans un DTD on ne peut pas spécifier la balise attendue pour la cible d’un
attribut de type IDREF ou IDREFS !
242