Bonsoir,
hbx360, une partie qui reste à éclaircir...
Envoyé par
hbx360
Quand on dit qu’une adresse peut avoir 0 ou plusieurs clients est-ce que ça veut dire qu'à la même adresse on a plusieurs clients ?
Cela veut dire qu’à une adresse donnée, disons a1, à n’importe quel moment, peuvent résider 0 client, 1 ou 2 ou 3 ou N clients. La liste de ces clients peut évoluer dans le temps, du fait des changements d’adresse des clients, de la prise en compte de nouveaux clients, de leur suppression, etc.
Exemple, situation à la date t1
ADRESSE
idAdresse
a1
a2
a3
a4
a5
a6
a7
CLIENT
idClient idAdresse
c1 a5
c2 a2
c3 a1
c4 a2
c5 a6
c6 a5
c7 a2
c8 a6
c9 a4
Dans cet instantané pris à la date t1, on constate que seul le client c3 réside à l’adresse a1, 3 clients résident à l’adresse a2, aucun client ne réside à l’adresse a3, seul le client c9 réside à l’adresse a4, 2 clients résident à l’adresse a5, 2 clients résident à l’adresse a6, aucun client ne réside à l’adresse a7.
Envoyé par
hbx360
Ou bien cela veut-il dire que pour une infinité d'adresses on a une infinité de clients ?
Pour une infinité d’adresses, à la date t, on peut avoir 0 client, 1 client, 2 client, une infinité de clients (si tant est que le terme « infinité » ait ici un sens...) On sort du contexte de Merise et de celui du modèle relationnel de données pour entrer dans celui de la théorie des ensembles, voyez à cette occasion l’exemple de l’Hôtel de Hilbert, hôtel hébergeant une infinité de clients, tandis qu’arrive un car bourré d’une infinité de nouveaux clients à héberger eux aussi).
Envoyé par
hbx360
J'ai du mal avec ce type d'association à bien savoir quoi mettre
A propos des règles de gestion des données
L’essentiel est de commencer par rédiger les règles de gestion des données de telle sorte qu’elles répondent de façon précise à ce veut l’utilisateur. Dans l’élaboration des MCD, c’est l’étape déterminante, celle dans laquelle il ne faut pas se rater et où il faut donc consacrer un maximum de rigueur et de temps.
(U1) Si pour l’utilisateur, la règle de gestion est
Un client peut ne pas avoir d’adresse, et s’il en a une, c’est au plus une
alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 0,1 :
[CLIENT]----0,1----(RESIDER)----
(U2) Si pour l’utilisateur, la règle de gestion est
Un client réside à au moins et au plus une adresse
alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 1,1 :
[CLIENT]----1,1----(RESIDER)----
(U3) Si pour l’utilisateur, la règle de gestion est
Un client peut ne pas avoir d’adresse, mais il peut très bien en avoir plusieurs
alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 0,N :
[CLIENT]----0,N----(RESIDER)----
(U4) Si pour l’utilisateur, la règle de gestion est
Un client a au moins une adresse et au plus plusieurs
alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 1,N :
[CLIENT]----1,N----(RESIDER)----
En les adaptant, ces règles de gestion ont leur pendant concernant la patte connectant l’entité-type CLIENT et l’association RESIDER.
Ainsi, il ne doit y avoir aucune ambiguïté quant aux règles de gestion des données et chaque cardinalité portée par une patte d’association doit nécessairement être la conséquence d’une règle.
Je vous engage à lire ce qu’écrivent D. Nanci (RIP) et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), au chapitre 7 (« Modélisation conceptuelle des données », paragraphe « Les cardinalités d’une entité type dans une relation type », pages 104 et suivantes.
Envoyé par
hbx360
j'aurai tendance à mettre 1 adresse = 1 client et un client = 1 adresse ce qui obligerait à tout mettre dans la même entité
Remontez impérativement aux règles de gestion. Dans votre cas, l’une d’elles doit explicitement préciser qu’un client réside à au moins et au plus une adresse et une autre règle doit explicitement préciser qu’à une adresse réside au moins et au plus un client. Ce qui implique la représentation merisienne :
[CLIENT]----1,1----(RESIDER)----1,1----[ADRESSE]
En l’occurrence, il y a une magnifique bijection, et si mathématiquement parlant il n’y a pas de problème, dans le contexte des bases de données relationnelles on doit être particulièrement vigilant car la bijection est très sournoise
Passons en effet au stade relationnel. L’usage veut qu’on mette en oeuvre des clés étrangères pour assurer la cohérence des références entre les tables issues des objets du MCD (entités-types et associations). Dans le cas de la bijection, les clés étrangères sont aussi efficaces que des cautères sur des jambes de bois. Elles n’empêchent pas des infractions comme celle-ci-dessous, bien que selon les règles (le règlement...), le client c3 réside seulement à l’adresse a1, qu’à l’adresse a1 ne réside que le seul client c3, que le client c9 réside seulement à l’adresse a4, et qu’à l’adresse a4 ne réside que le seul client c9 :
CLIENT ADRESSE
+-----------+-----------+ +-----------+----------+
| idClient | idAdresse | | idAdresse | idClient |
|-----------+-----------| |-----------+----------|
| c3 | a1 | | a1 | c9 |
| c9 | a4 | | a4 | c3 |
+-----------+---- ------+ +-- --------+----------+
La table CLIENT est conforme au règlement, mais la table ADRESSE est pourrie de tuples délinquants.
Et voilà pourquoi, prudence oblige, l’usage en SQL est que la table CLIENT absorbe la table ADRESSE, même principe au stade MCD, les propriétés de l’entité-type ADRESSE sont évacuées dans l’entité-type CLIENT et cette entité-type ADRESSE disparaît du MCD. De loin ça ressemble à la fusion (coalescence) de deux trous noirs, à ceci près que la fusion d’entités-types ne donne quand même pas lieu à l’émission d’ondes gravitationnelles...
Dans le cadre du modèle relationnel de données, contrairement aux SGBD de type SQL, on n’éprouve aucunement le besoin pressant de fusionner les structures des tables (pardon, des variables relationnelles), la bijection ne pose pas de problème, il suffit de déclarer une contrainte remplaçant les clés étrangères inefficaces et bonnes pour la poubelle :
CONSTRAINT RESIDER_CHK01
CLIENT {idClient, idAdresse} = ADRESSE {idClient, idAdresse} ;
Pour en savoir un peu plus, voyez mon billet « Merise : cardinalités 1,1 ---- 1,1 => intégrité référentielle = cautère sur jambe de bois », ainsi que les commentaires qu’en fait CinePhil.
Envoyé par
hbx360
dans le même cours cité plus haut au chapitre 3 il met en cardinalité : personne 0,N possède 0,N adresse.
Je n’ai pas lu ce cours, mais les cardinalités mentionnées doivent être impliquées par les règles de gestion :
RGx - Un client peut avoir plusieurs adresses (et il est possible qu’il n’en ait aucune) ;
RGy - A une adresse donnée on peut avoir plusieurs clients (et il est possible qu’il n’y ait personne).
Partager