Discussion :

[antoine2641]

Bonjour,

Je n'arrive pas à faire la différence entre ces deux schémas. (en pièce jointe)
Si quelqu'un peut m'expliquer ce serait sympa.

Merci d'avance,
Antoine

[Samuel_]

Je n'arrive pas à faire la différence entre ces deux schémas. (en pièce jointe)
Si quelqu'un peut m'expliquer ce serait sympa.

Pense à la modélisation que tu vas faire après !
Imagine ta BDD :

Dans le premier cas, tu aura les tables suivantes
UTILISATEUR; :
CD;
LOUE_CD;
DVD;
LOUE_DVD.
Tu différencie bien la location de CD de la location de DVD.

Dans le second cas tu aura :
UTILISATEUR;
CD;
DVD;
LOUE.
Ici tu ne différencie pas les CD des DVD. Tu ajoutera une "super-classe" qui sera mère de CD et DVD (Histoire de n'avoir qu'une référence dans la table LOUE).

Je ne sais pas si j'ai été assez clair ...

[Richard_35]

Bonjour Antoine2641,

Pour répondre précisément à ta question :

• dans le premier schéma, le concepteur a estimé que les associations "louer_film" et "louer_cd" sont porteuses d'attributs tellement différents qu'il lui a semblé judicieux de créer deux associations (donc, en final, deux tables associatives distinctes) ;
• dans le second schéma, le concepteur a estimé que l'association "louer" suffit (donc, en final, une seule table regroupant les attributs de toutes les locations).

Sur le fond, et sans connaître les règles de gestion, le second schéma semble le plus judicieux.

[antoine2641]

Merci pour vos réponses.

Si mes deux associations ont les mêmes attributs, il n'est pas utile de les séparer si j'ai bien compris.

Premier cas :
Je sépare mes deux associations.
Cela induit la création de deux tables (ayant le même rôle et les mêmes attributs).
Donc pas très utile au final.

Second cas :
Je n'ai qu'une association, donc une table. Donc c'est plus judicieux

J'ai bien compris ?

[Richard_35]

Merci pour vos réponses.

... croisées, avec Samuel_.

Second cas :
Je n'ai qu'une association, donc une table. Donc c'est plus judicieux

==> ça semble plus judicieux : sans connaître les règles de gestion, c'est difficile de se prononcer.

J'ai bien compris ?

==> c'est cela même.

[antoine2641]

... croisées, avec Samuel_.

Je vous remercie tout les deux bien sûr !

ça semble plus judicieux : sans connaître les règles de gestion, c'est difficile de se prononcer.

Qu'est ce que tu appelle "règles de gestion" ?
J'ai bien une petite idée, C'est quelque chose comme ça :

• Dans la première solution on pourra savoir la liste des locations de l'utilisateur cd et dvd confondus.

• Dans la seconde on pourra savoir la liste des locations de cd uniquement et la liste des location de dvd séparément.

[Richard_35]

Qu'est ce que tu appelle "règles de gestion" ?

==> elles proviennent de l'analyse que tu as dû effectuer avec l'utilisateur final.

Je te laisse étudier ces deux billets de CinePhil : 1 et 2.

[fsmrel]

Bonjour Antoine,

Je n'arrive pas à faire la différence entre ces deux schémas.

La différence est nette :

Dans le 1er cas, un utilisateur loue d’une part des films (indépendamment du support qui à l’occasion peut être un CD) et loue d’autre part des CD (indépendamment de leur contenu, qui peut par exemple être un logiciel, un jeu, voire même un film...) Pour l’utilisateur il n’y a aucun lien entre les films et les CD.

Dans le 2e cas, un utilisateur loue des films seulement s’ils sont sur CD (ou de façon équivalente : un utilisateur loue des CD seulement si des films sont enregistrés sur ces CD). Cette fois-ci, pour l’utilisateur il y a un lien entre les films et les CD (A noter accessoirement que selon votre MCD, pour cet utilisateur, le même CD peut contenir plusieurs films et le même film peut être sur plusieurs CD).

Les conséquences sur la base de données ne sont pas anodines et il y a intérêt à ne pas rater la modélisation conceptuelle qui en est la matrice, volens nolens. Pour illustrer, passons à l’exemple des consultants indépendants, spécialisés dans les SGBD : les consultants sont compétents pour certains SGBD et conseillent leurs clients :




Sous forme de prédicats :

(P1) Le consultant X maîtrise le SGBD Y.

(P2) Le consultant X conseille le client Y.

Des faits (sous forme tabulaire, clés soulignées) :

CONSULTANT                           SGBD                     CLIENT
ConsultantId    ConsultantNom        SgbdId    SgbdNom        ClientId    ClientNom
 
           1    Albert                    1    DB2                   1    Ets Naudin
           2    Bernard                   2    SQL Server            2    Volfoni Frères
           3    Carole                    3    PostgreSQL            3    Dugoineau
           4    Denis                     4    IMS/DB                4    Dupond & Dupont
           5    Emile                     5    Oracle                5    Lampion et Cie
           6    Fred                      6    MySQL 

MAITRISER              
ConsultantId    SgbdId 
 
           1         2  
           1         5 
           1         6 
           2         1 
           2         3 
           2         4 
           2         5 
           3         1
           3         4
           5         3
           6         6 

CONSEILLER
ConsultantId    ClientId
 
           1           1
           1           2
           1           4
           2           2
           2           3
           3           4
           4           5
           6           2 

Passons à la représentation sous forme d’association ternaire.

Les consultants ont pour mission de booster les SGBD chez leurs clients :




Sous forme de prédicat :

(P3) Le consultant X conseille le client Y pour le SGBD Z.

Vous noterez que le prédicat (P3) n’est pas la conjonction (pas plus que la disjonction) des prédicats (P1) et (P2).

Pour compléter les faits :

OPTIMISER
ConsultantId    ClientId    SgbdId
 
           1           1         2       Albert booste SQL Server chez les Ets Naudin
           1           1         5       Albert booste aussi Oracle chez les Ets Naudin
           1           2         2       Albert booste SQL Server chez Volfoni Frères
           2           3         1       Bernard booste DB2 chez Dugoineau
           3           4         4       Carole booste IMS/DB chez Dupond & Dupont 
           6           2         6       Fred booste MySQL chez Volfoni Frères 

Maintenant, comment savoir qu’Albert maîtrise Oracle ? Que Denis conseille Lampion et Cie ? Qu’Emile maîtrise PostgreSQL ? Etc.

Vous me direz qu’il suffit de faire intervenir le bonhomme Null pour compléter OPTIMISER :

OPTIMISER
ConsultantId    ClientId    SgbdId
         ...         ...       ...  
           1        Null         5       Albert maîtrise Oracle, mais ne le booste chez personne
           4           5      Null       Denis conseille Lampion et Cie, mais n’y booste rien
           5        Null         3       Emile maîtrise PostgreSQL, mais ne le booste chez personne

Le hic est qu’au niveau SQL, le triplet {ConsultantId, ClientId, SgbdId} constitue la clé primaire de la table OPTIMISER et donc Null n’a pas le droit de s’y faufiler... En outre, cela reviendrait au niveau du Merise à violer la règle selon laquelle chaque occurrence d’association est obligatoirement rattachée à une occurrence d’entité-type pour chaque patte d’association.

On pourrait rétorquer qu’il n’y a qu’à se passer de clé primaire, mais cette fois-ci je martèlerai qu’il y a des coups de pied occultes qui se perdent...

En fait, un MCD adéquat pourrait être le suivant :



Les flèches rouges symbolisent des contraintes d’inclusion :

— Un consultant ne peut optimiser un SGBD chez un client que s’il le maîtrise (le SGBD ),
— Un consultant ne peut optimiser un SGBD chez un client que si celui-ci fait partie de ceux qu’il conseille.

Bref, les différences entre les différents schémas sont très importantes et, je le répète, dès le stade MCD il ne faut pas rater son coup, votre question initiale n'était pas sans intérêt...