Bonjour,
Envoyé par
ricounet_paris
En ce qui concerne les warnings, j'en ai encore un, dont voici le texte :
"possede_civ : Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle."
Open ModelSphere a injecté dans le MCD un concept UML, celui de navigabilité. Pour vous débarrasser de cette scorie, côté CLIENT vous cochez la case Navigabilité :
Navigabilite_01.jpg)
Navigabilite_02.jpg)
Et du côté CIVILITE vous décochez la case.
Association-type Possede_email :
Depuis que Merise existe, les pattes connectant les entités-types par le biais d’une association-type de dimension 3 ou plus sont porteuses de cardinalités maximales N. Le grand Yves Tabourier use d’un euphémisme pour évoquer le « Manque d’intérêt des cardinalités maximum à 1 pour les relations à plus de deux pattes » (cf. page 88 in De l’autre côté de MERISE. Les Éditions d’organisation, 1986).
La règle est de casser la ternaire Possede_email en deux binaires :
ternaire_et_1,1.jpg)
Association-type Possede_telephone : Même principe.
Envoyé par
ricounet_paris
Sur mon MCD, je ne sais pas si je dois mettre le type en attribut d'une relation ou bien créer une entité type (type téléphone, type adresse...) en relation avec l'entité concernée.
Les deux façons de procéder sont possibles. Il est néanmoins dans l’usage de définir une entité-type Type_Adresse.
Envoyé par
ricounet_paris
J'ai quand même un doute sur les cardinalités des types. J'ai mis 1,n pour ne pas que ce soit restrictif car s'il y a plusieurs adresses (par exemple), il y aura plusieurs types. Mais comme une adresse ne peut pas avoir plusieurs types en même temps, j'hésite avec 1,1.
Selon votre MCD, l’association-type PossedeAdr est une ternaire dont toutes les pattes sont porteuses d’une cardinalité maximale N. Lors du passage au MLD, cette association-type fera l’objet d’une table ayant la structure suivante :
1
2
3
4
| PossedeAdr {IdClient, IdAdresse, IdTypeAdresse}
PRIMARY KEY {IdClient, IdAdresse, IdTypeAdresse}
FOREIGN KEY {IdClient} REFERENCES CLIENT {IdClient}
Etc. |
Autrement dit, le client c1 pourra avoir une adresse a1 ayant les types t1, t2, ..., tn et l’adresse a1 pourra appartenir simultanément aux clients c1 et c2.
Étant donné que vous tenez à ce qu’une adresse soit d’un seul type, la ternaire doit être cassée pour devenir une binaire associant CLIENT et ADRESSE, tandis qu’on définit une association-type ATypeAdr entre ADRESSE et TYPE_ADRESSE, comme dans le cas des courriels (emails).
Mais pourquoi tenez-vous à ce qu’une adresse ne soit que d’un seul type ? Si deux clients peuvent cohabiter à la même adresse, ça peut être pour des motifs différents.
Vous pourriez à nouveau suivre le conseil d’Yves Tabourier :
« ...La fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques. »
=>
Adresse.jpg)
Selon cette représentation, si deux clients habitent à la même adresse, dans la base de données on aura des adresses qui seront des jumelles parfaites, mais distinguées par leur identifiant.
Dans cette vision des choses, ADRESSE peut être considérée comme une entité-type faible, c'est-à-dire comme une propriété (multivaluée) de CLIENT, ce qui conduit à identifier ADRESSE relativement à CLIENT (cardinalité 1,1 entre ADRESSE et Resider soulignée) :
AdresseRelative.jpg)
Au niveau logique :
1
2
3
4
| Resider {IdClient, IdAdresse}
PRIMARY KEY {IdClient, IdAdresse}
FOREIGN KEY {IdClient} REFERENCES CLIENT {IdClient}
FOREIGN KEY { IdAdresse} REFERENCES ADRESSE { IdAdresse} |
inscription (souple) de clients
Répondre avec citation
Partager