Discussion :

[Leilou]

Bonjour,

Je voudrais savoir s'il est possible d'associer une occurrence d'une table A plusieurs fois à une même occurrence d'une table B en utilisant plusieurs clés étrangères dans A qui pointent sur le même champ dans B.

Exemple :
Un client peut avoir 1 ou 3 adresses : 1 communication,1 facturation, 1 livraison. Sachant que ces adresses peuvent être identiques, j'ai voulu créer une table adresse à part et faire 3 clés étrangères dans ma table client qui pourront référencer la même occurrence de adresse si besoin. Mais je ne sais pas si cela est correct.



client(id_client, nom, prenom, #id_adr_comm, #id_adr_fact, #id_adr_livr)
adresse(id_adr, libelle, cp, ville, complement, #id_client)

Désolée je n'ai pas eu le temps de faire un MCD propre avec un logiciel de modélisation J'espère que c'est compréhensible...

[fsmrel]

Bonsoir Leilou,

Un client peut avoir 1 ou 3 adresses

Mais dans votre diagramme, vos cardinalités sont 0,3 : il y a une contradiction. Est-ce bien 0,3 ou plutôt 1,3 ? Merci de préciser ce point.

Votre représentation souffre de deux maux...

— Vous avez introduit un cycle,
— Le bonhomme Null pointe le bout de son nez, puisque la cardinalité 0,3 signifie qu’un client peut avoir 0, 1, 2 ou 3 adresses.

Vous pouvez mettre en œuvre une 1ere variante, consistant à donc supprimer le cycle et interdire au bonhomme Null de se manifester :





Notez les clés alternatives (mickey <ak>) pour les tables COMMUNICATION, FACTURATION et LIVRAISON.

[Richard_35]

Bonjour Leilou et Fsmrel,

Je me permets de m'immiscer, Fsmrel...

Une autre variante qui permet de jouer sur le type d'adresse et d'éviter, ainsi, de créer une table par type d'adresse. En effet, à l'avenir, d'autres types pourraient être nécessaires.

[fsmrel]

Bonsoir Leilou et Richard,


Il est certain que si l’on a besoin un jour de plus de 3 types d’adresses, le diagramme de Richard sera préférable. Ainsi, mon ami Mokrane parlait de l’heuristique papoue à propos des sous-types :

Question : « Comment comptent les papous ? »

Réponse : « 1, 2, 3, beaucoup ».

Autrement dit, au-delà de trois sous-types, passer à une représentation à la Richard.

Je me souviens d’un concepteur au bord de la déprime parce qu’il avait modélisé un surtype affublé d’une quinzaine de sous-types, son MCD ressemblait à une toile d’araignée... Quand je lui ai raconté le coup de l’heuristique, ça n’est pas tombé dans l’oreille d’un sourd, il a donc passé un bon coup de plumeau, et tout content il m’a emmené conclure cette affaire au bistro du coin avec un bon malt écossais (ou un bon coup de cidre, je ne sais plus... En tout cas, adieu déprime !)

[ninouchou]

Bonjour à tous,
Si j’ai bien compris on veut modéliser l’information « cette adresse appartient à tel client et est de type type »

1) Si je me base sur la philosophie papoue, je peux modifier le schéma de Richard en supprimant la table type adresse et en mettant à la place l’attribut (type adresse) dans la table client_adresse en plus j’ai entendu dire que si une table ne contenait qu’un seul attribut et n’avait qu’une relation on devait la supprimer (je ne sais pas si ça ce vérifie).
Le nouvel attribut doit participer à la clé composée sinon on aurait vite un conflit de clé puisqu’une même adresse peut participer jusqu’à 3 fois à la relation affecter client (en modélisation je ne sais pas comment justifier ça, les papous auraient ils une idée)

2) Ou sinon deuxième solution on supprime la relation appartient et on met à la place 3 relations :
AdrFac (client 0,1-----1,1 adresse)
AdrLiv (client 0,1-----1,1 adresse)
AdrCom (client 0,1-----1,1 adresse)
On aura 3 références à la même table (ce n’est pas faux) mais pas de cycle.

3) J’aurais aussi une question, si je décidais de garder le schéma de Leilou et de n’avoir que 2 tables client et adresse et si je gardais la relation appartient et je rajoutais un attribut (type) dans cette relation, quelles seraient les cardinalités ? 1,3---1,3 ou bien 1,3---1,1 car une même adresse peut participer jusqu’à 3 fois à la relation appartient mais ça sera toujours avec le même client. Que dit Merise à ce sujet ? et pour le problème de conflit de clé on mettra l’attribut type plus l’id client plus l’id adresse.

[Richard_35]

Bonjour Ninouchou,

Point 1) :

... en mettant à la place l’attribut (type adresse) dans la table client_adresse...

==> et, à l'avenir, si un autre type d'adresse est nécessaire, il faudra modifier le code ou les attributs pour n'accepter, en saisie que les types d'adresse permis. La table Type Adresse permet de s'affranchir de se contrôle.

... j’ai entendu dire que si une table ne contenait qu’un seul attribut et n’avait qu’une relation on devait la supprimer (je ne sais pas si ça ce vérifie)...

==> ne devrions-nous pas nous méfier de ce nous entendons dire ?... Dans une application, il y a beaucoup de tables qui contiennent, uniquement, une clé primaire et un seul attribut (devises, unités de volume, etc...). Cette table Type Adresse contiendra, au minimum, le libellé du type d'adresse concerné, et ce n'est déjà pas si mal... sinon, où placerais-tu le libellé "adresse commerciale", "adresse de facturation", etc... ?

Point 2) :

AdrFac (client 0,1-----1,1 adresse)
AdrLiv (client 0,1-----1,1 adresse)
AdrCom (client 0,1-----1,1 adresse)

==> à l'avenir, si un autre type d'adresse est nécessaire, alors il faudra créer une autre table.

Point 3) :

... je rajoutais un attribut (type) dans cette relation...

==> même combat : à l'avenir, si un autre type d'adresse est nécessaire, il faudra modifier le code ou les attributs pour n'accepter, en saisie que les types d'adresse permis.

... quelles seraient les cardinalités ? 1,3---1,3 ou bien 1,3---1,1...

==> 1,3---1,3 : s'apparente à 1,n---1,n, donc, une table associative est nécessaire.

... et pour le problème de conflit de clé on mettra l’attribut type plus l’id client plus l’id adresse.

==> tant de contournements sont-ils nécessaires ?...

[ninouchou]

Bonjour Richard_35,

1) Je dois avouer que c'est convaincant pour le cas du type d’adresse mais pour le cas de la date, prenons un exemple : on a une entité Employe et une entité Projet et on veut modéliser les informations suivantes : la date d’affectation d’un projet à un employé et la date de fin de projet. Si je veux mettre ça dans une relation quadraire EstChargé avec deux arcs qui sortent de l'entité Date. Je ne suis pas obligée de créer les dates à l’avance comme des types d’adresses et en plus j’aurai les informations répétées dans l’entité Date et la relation EstChargé et si je mets la date comme clé dans l’entité Date, cette entité ne me sert plus à rien.

2) Une question dans le même thème : doit-on supprimer une sous-classe dans un diagramme de classe si elle n’a pas d’attribut ou de relation supplémentaire ? Je suis d’avis qu’on la garde car je voie une spécialisation comme une relation avec une autre classe qui s’appellerait type, on pourrait dire qu’une spécialisation porte déjà une information (une sémantique) et si on supprime une sous-classe on doit sauvegarder l’information de type quelquepart, dans une relation, un attribut,….

[Richard_35]

Bonjour Ninouchou,

Point 1) :

... mais pour le cas de la date, prenons un exemple : on a une entité Employe et une entité Projet et on veut modéliser les informations suivantes : la date d’affectation d’un projet à un employé et la date de fin de projet. Si je veux mettre ça dans une relation quadraire EstChargé avec deux arcs qui sortent de l'entité Date. Je ne suis pas obligée de créer les dates à l’avance comme des types d’adresses et en plus j’aurai les informations répétées dans l’entité Date et la relation EstChargé et si je mets la date comme clé dans l’entité Date, cette entité ne me sert plus à rien.

==> c'est, effectivement, un autre sujet.
Il y a deux écoles : ceux qui pensent qu'il faut créer une entité "Date" et les autres. Personnellement, je fais partie de la seconde catégorie. Donc :



Point 2) :

2) Une question dans le même thème : doit-on supprimer une sous-classe dans un diagramme de classe si elle n’a pas d’attribut ou de relation supplémentaire ? Je suis d’avis qu’on la garde car je voie une spécialisation comme une relation avec une autre classe qui s’appellerait type, on pourrait dire qu’une spécialisation porte déjà une information (une sémantique) et si on supprime une sous-classe on doit sauvegarder l’information de type quelque part, dans une relation, un attribut,….

==> n'étant pas "merisien de naissance", je ne comprends pas cette sémantique et ne peux donc pas répondre à ta question. D'autres s'en chargeront sûrement.

[ninouchou]

Merci Richard et une dernière chose,

Si nous avions à la place d’Employe : Chauffeur et à la place de Projet : Voiture et si nous avions à modéliser la relation : ce chauffeur a conduit cette voiture à cette date.

Si je choisis cette solution :

Il y a deux écoles : ceux qui pensent qu'il faut créer une entité "Date" et les autres. Personnellement, je fais partie de la seconde catégorie.

La clé de la relation Conduit étant la concaténation entre la clé de l’entité Chauffeur et celle de l’entité Voiture. Et comme je peux avoir plusieurs fois la même combinaison (chauffeur, voiture), j’aurais des problèmes de conflits de clés. Je peux ajouter la date dans la clé composée mais dans le schéma entité-association comment je modélise cela ?

[Richard_35]

Bonjour Ninouchou,

Si nous avions à la place d’Employe : Chauffeur et à la place de Projet : Voiture et si nous avions à modéliser la relation : ce chauffeur a conduit cette voiture à cette date.

==> le travail sur les dates donne toujours lieu à des débats épineux... a fortiori, le travail sur les périodes...

D'autre part, tout ne peut pas être forcément résolu en base de données : il y a, souvent, un travail de contrôle à coder, si possible dans un trigger.

Suggestion :





Etude des cas possibles :




Nous remarquons que, seuls les cas 1, 5, 8 et 9 sont acceptables en saisie de période : l'idéal serait de créer un trigger qui effectuerait ce contrôle.

Je te laisse la main...

[MacFly58]

Bonjour,

ninouchou :

La clé de la relation Conduit étant la concaténation entre la clé de l’entité Chauffeur et celle de l’entité Voiture. Et comme je peux avoir plusieurs fois la même combinaison (chauffeur, voiture), j’aurais des problèmes de conflits de clés. Je peux ajouter la date dans la clé composée mais dans le schéma entité-association comment je modélise cela ?

La seule solution acceptable pour modéliser cela est de créer une entité-type Date dans le MCD. Cette entité-type ne deviendra pas une table dans le MLD, et l'association-type dans le MCD possèdera un identifiant correct.
Notez que Date n'est pas une vraie entité-type pour ce cas très courant, mais juste un type (de date). En effet, sémantiquement, une date n'est pas une entité. Il s'agit donc d'une astuce utilisée avec Merise pour pallier une lacune de Merise. Ce n'est pas l'idéal, mais on a pas mieux en magasin. On se retrouve quand même avec une MCD aisément compréhensible et avec une MLD juste, ce qui est l'esentiel.

[fsmrel]

C'est un plaisir de vous revoir MacFly !

Coïncidence, je viens de traiter de cette fichue entité-type DATE

Voyez ici.