9 Une Etude de Cas

9
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.
208
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.
209
Une Modèlisation Relationnelle
Une parmi les modèlisations possibles crée un schéma avec 9 tables : BD pas Mangas,
Mangas, Editeur, Infos Auteur, Auteur Adresses, Auteur Oeuvres Pas Mangas
Auteur Oeuvres Mangas, Contrats.
Chaque schéma de table est en BCNF (Forme Normale de Boyce Codd).
⇒
210
BD pas M angas :
titre
ISBN
long
larg
prix
Idente dit
Dépendances Fonctionnelles F :
{ISBN → titre, long, larg, prix, Ident edit}
Clé : ISBN
Ce schéma de table est en BCNF : les seules dépendances fonctionnelles significatives
sont celles à partir de la clé.
211
Editeur
Ident edit
Nom edit
num rue ed
rue ed
ville ed
pays ed
Dépendances Fonctionnelles F :
{Ident edit → N om edit, num rue ed, rue ed, ville ed, pays ed}
Clé : Ident edit.
Ce schéma de table est en BCNF.
212
Inf os Auteur :
NSS
nom
prenom
thematique
Dépendances Fonctionnelles F : {N SS → nom, prenom, thematique}
Clé : NSS
Ce schéma de table est en BCNF.
213
M angas : même table que pour BD pas Mangas, avec, en plus, l’attribut
sens de lecture, dont le domaine est {“GD ′′ , “DG′′ } (de gauche à droite, de droite à
gauche).
Dépendances Fonctionnelles F : les mêmes que pour BD pas Mangas, plus
ISBN → sens de lecture.
Clé : ISBN
Ce schéma de table est en BCNF.
214
Inf os Auteur :
NSS
nom
prenom
thematique
Dépendances Fonctionnelles F : {N SS → nom, prenom, thematique}
Clé : NSS
Ce schéma de table est en BCNF.
215
Auteur Adresses :
NSS
num rue aut
rue aut
ville aut
pays aut
Dépendances Fonctionnelles F : seulement la dépéndance banale :
N SS, num rue aut, rue aut, ville aut, pays aut → N SS, num rue aut, rue aut, ville aut,
Clé : {N SS, num rue aut, rue aut, ville au, pays aut}.
Ce schéma de table est en BCNF.
NB : Le fait qu’il faut tous les attributs dans la clé est du à l’hypothèse qu’un auteur peut
avoir plusieurs adresses, au fait que 2 adresses distinctes peuvent contenir le même
numéro, où la même rue, où la même ville, ou le même pays (mais pas coincider sur
tout), et, enfin, à l’hypothèse (implicite) que deux auteurs peuvent vivre à la même
adresse.
216
Auteur Oeuvres P as M angas :
NSS
ISBN
scen
col
dessin
où le domaine est le même pour les attributs scen, col et dessin : l’ensemble des booléens
{True, False} (l’auteur est scénariste ou pas, coloriste ou pas, déssinateur ou pas, pour la
bd en question).
Dépendances Fonctionnelles F : {N SS, ISBN → N SS, ISBN, scen, col, dessin}
Clé : {N SS, ISBN }.
Ce schéma de table est en BCNF.
NB : il faut les 2 attributs dans la clé, car un auteur peut avoir réalisé plusieurs oeuvres,
et une oeuvre peut avoir plusieurs auteurs. Et puis, un auteur donné peut être juste
scénariste pour une bande déssinnée, mais scénariste et déssinateur pour une autre, etc.
217
Auteur Oeuvres M angas :
NSS
ISBN
scen
dessin
où le domaine est le même pour les attributs scen, dessin : l’ensemble des booléens
{True, False} (l’auteur est scénariste ou pas, déssinateur ou pas, pour la manga en
question).
Dépendances Fonctionnelles F : {N SS, ISBN → N SS, ISBN, scen, dessin}
Clé : {N SS, ISBN }.
Ce schéma de table est en BCNF.
NB : On a juste enlévé col de la table Auteur Ouvres P as M angas. Mais il faudrait
de quelque façon séparer les ISBN des mangas des ISBN des pas mangas... Passons.
218
Contrats :
NSS
Ident ed
Dépendances Fonctionnelles F : {N SS ⇒ Ident ed} car un auteur est sous contrat
exclusivement avec un éditeur (tandis qu’un éditeur peut avoir plusieurs auteurs sous
contrat).
Clé : {N SS}.
Ce schéma de table est en BCNF.
219
On n’a pas exprimé la contrainte qu’un auteur a forcement au moins une adresse, sauf si
on pose la contrainte (naturelle) :
πN SS (Inf os Auteur) = πN SS (Auteur Adresses)
=
πN SS (πN SS (Auteur Oeuvres P as M angas) ∪ πN SS (Auteur Oeuvres P as M angas))
N.B. Grâce à la table Auteur Oeuvres P as M angas, on peut reperer pour quelle bd
un auteur est seulement scénariste et pour quelle autre est aussi déssinateur, par exemple,
et idem pour Auteur Oeuvres M angas. Et on a exprimé aussi la contrainte que les
mangas n’ont pas de coloriste.
220
On n’exprime pas les “parfois”, non plus :
– 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 nulls. Remarquer que le
modèle relationnel “propre” ne veut pas de valeurs nuls ! Cette limite est vraiment
intrinséque au modèle relationnel.
221
N.B. Si jamais on pose aussi les contraintes :
πIden edit (BD pas M angas) ⊆ πIden edit (Contrats)
et
πIden edit (BD pas M angas) ⊆ πIden edit (Contrats)
on n’exprimera pas non plus la contrainte qu’un éditeur a parfois un contrat avec un
auteur (donc il peut ne pas en avoir).
Problème analogue si on pose :
πN SS (Auteur Oeuvres pas M angas) ⊆ πN SS (Contrats)
et
πN SS (Auteur Oeuvre M angas) ⊆ πN SS (Contrats)
222
Une Modèlisation Objet
Une parmi les modèlisations possibles crée un schéma avec 5 classes : BD, Auteur,
Editeur, Adresse, Mangas, où Mangas est une sous-classe de la classe BD.
NB : pas de correspondance exacte avec les tables relationnelles (mais on aurait pu faire
autrement, et ne pas utiliser de sous-classes, par exemple).
⇒
223
class BD (key ISBN extent les_bd) {
attribute string titre;
attribute integer ISBN;
attribute format struct dimensions{float long, float larg} format;
attribute float prix;
relationship <Auteur> a_scénariste inverse Auteur::scénariste_de;
relationship <Auteur> a_déssinateur inverse Auteur::scénariste_de;
relationship <Auteur> a_coloriste inverse Auteur::coloriste_de;
relationship Editeur a_éditeur inverse Editeur édite}
class Mangas extends BD (extent les_mangas)
attribute enum directions{GD,DG} sense_lecture
224
class Auteur (key NSS extent les_auteurs) {
attribute integer NSS
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> déssinateur _de inverse BD::a_déssinateur
relationship Set<BD> coloriste_de inverse BD::a_coloriste
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}
225
class Adresse (key (num, rue, ville, pays) extent les_addresses) {
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;
relationship Set<Auteur> contrat_avec_aut inverse Auteur contrat_avec_ed}
226
On n’a pas exprimé :
1. La contrainte qu’un auteur a forcement au moins une adresse (notre déclaration
permet qu’un auteur ait un ensemble vide d’adresses ; pourquoi ?).
2. La contrainte qu’une Manga n’a jamais de coloriste (à cause de la relation de
sous-classe ; mais on aurait pu l’éviter).
N.B. On peut reperer pour quelle bd un auteur est seulement scénariste et pour quelle
autre est aussi déssinateur, par exemple.
227
On n’exprime pas les “parfois”, non plus :
– on n’a pas exprimé qu’un auteur a parfois une thématique (comme pour le relationnel).
– on n’a pas exprimé qu’un auteur a parfois un prénom (comme pour le relationnel).
– on n’a pas exprimé qu’un auteur a parfois un contrat.
Comme pour le relationnel, cette mauvaise gestion des “parfois” est intrinséque :
ODL ne permet pas de faire la différence entre :
- la contrainte qu’un objet o d’une classe C1 est lié à un nombre indeterminé n d’objets
de C2 (n ≥ 0)
- la contrainte qu’un objet o d’une classe C1 est lié à un nombre n d’objets de C2 où
n ∈ {0, 1}.
Pourquoi ?
228
Une modèlisation semi-structurée
Un DTD que l’on peut écrire : ⇒
229
<!ELEMENT (bande_dessinnée)+, auteur+,editeur+>
<!ELEMENT bande_dessinée (manga|pas-manga)>
<!ELEMENT pas_manga (titre,format,prix)>
<!ATTLIST pas_manga ISBN ID #REQUIRED a_scénariste IDREF #REQUIRED
a_déssinateur IDREF #REQUIRED a_coloriste IDREF #IMPLIED
a_editeur IDREF #REQUIRED>
<!ELEMENT manga (titre,format,prix)>
<!ATTLIST ISBN ID #REQUIRED a_scénariste IDREF #REQUIRED
a_déssinateur IDREF #REQUIRED a_editeur IDREF #REQUIRED
sens_lecture (GD|DG)>
<!ELEMENT titre PCDATA>
<!ELEMENT titre CDATA>
<!ELEMENT format (long,larg)>
<!ATTLIST format unité_més CDATA #REQUIRED>
<!ELEMENT prix CDATA>
<!ATTLIST prix dévise CDATA #REQUIRED>
<!ELEMENT long CDATA>
230
<!ELEMENT larg CDATA>
<!ELEMENT auteur (nom,prenom?, (adresse)+,thématique?)>
<!ATTLIST auteur NSS_aut ID #REQUIRED réalise IDREFS #REQUIRED
contrat_avec_ed IDREF #IMPLIED>
<!ELEMENT nom PCDATA>
<!ELEMENT prenom PCDATA>
<!ELEMENT thématique PCDATA>
<!ELEMENT adresse (numéro, rue, ville, pays)>
<!ELEMENT numéro CDATA>
<!ELEMENT rue PCDATA>
<!ELEMENT ville PCDATA>
<!ELEMENT pays PCDATA>
<!ELEMENT editeur (nom,adresse)>
<!ATTLIST editeur NSS_ed ID #REQUIRED édite IDREFS #REQUIRED
contrat_avec_aut IDREFS #IMPLIED>
231
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 déssinateur,
par exemple.
232
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.
233
At-on exprimé la contrainte qu’un cible d’un lien a scénariste doit forcement être
un noeud auteur ? (Même question pour a déssinateur 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 !
En XML-schéma non plus, d’ailleurs.
234