Discussion :

[funkyjul]

Bonjour,

Je fais appels à vos idées pour m'aider à résoudre un problème de modélisation qui me tarabuste sérieusement depuis un moment et je ne trouve pas LA solution idéale. Voici donc mon soucis:

Prenons 2 tables : PERSONNES et EVENEMENTS. Un événement à forcément un lien avec une personne, jusque là tout va bien.
Une personne peut avoir une ou plusieurs adresse(s), et il en va de même avec un événement. C'est sur ce point que je sèche!

Les adresses peuvent être de plusieurs types (adresse privée, adresse principale, adresse secondaire, adresse de livraison etc etc), raison pour laquelle j'ai créé une table TYPE_ADRESSE.

Dans un premier temps j'ai pensé créer 2 autres tables PERSONNE_ADRESSE et EVENEMENT_ADRESSE, chacune liée à la table TYPE_ADRESSE et bien sur soit à la table PERSONNES ou la table EVENEMENT.

Je pense que cela fonctionnerait mais conceptuellement je trouve ça tout simplement horrible car au final je me retrouverais avec 2 tables d'adresses quasi identiques avec comme simple différence la clef étrangère (une fois sur personnes et une fois sur événements).

Sachant qu'un événement n'a pas forcément d'adresse, et vise versa une personne n'en a pas forcément une non plus, mais que les deux peuvent en avoir plusieurs, comment pensez-vous que je devrais modéliser cela? J'ai pensé à pas mal de chose mais je n'arrive pas à trouver LA juste solution.

Dois-je intégrer la source de l'adresse dans ma table TYPE_ADRESSE? Dois-je créer une table PERSONNE_EVENEMENT? Dans ces deux cas je me retrouverais avec des clefs étrangères nulles. Ou alors dois-je garder mes deux tables PERSONNE_ADRESSE et EVENEMENT_ADRESSE? Bref, c'est un peu le flou total.

J'espère que vous avez plus ou moins saisi mon problème et qu'une bonne âme saura m'aider à m'extirper de cette situation.

D'avance merci

Julien

[Wazzouille]

Bonjour,

la méthode la plus facile est d'avoir 3 ou 4 tables

1) Personne
2) Événement
3) Adresse

Depuis personne vous aurez des foreign key vers la table adresse et depuis événement aussi.
Vous aurez des fk null mais qu'importe ?

Si vous voulez avec une précision sur le type d'adresse dont il s'agit, vous pouvez faire une table TypeAdresse reliée à la table Adresse si cela vous intéresse d'avoir toutes les adresses de livraison,...

Normalement vous ne devriez pas avoir de mise à jour sur le nom des type ou des adresses, donc vous pouvez carrément mettre un champ dans la table Adresse pour le type.

Cependant, cette solution n'est pas flexible au cas où vous devriez à l'avenir rajouter un lien d'une adresse à la table Evenement ou Personne

[escartefigue]

Vous pouvez modéliser comme suit :

MCD :


MLD :


Pour personne j'ai ajouté la date dans la relation à l'adresse, car une personne peut par exemple déménager, ou avoir une adresse provisoire (de vacances par exemple) pour une période
Il ne m'a pas semblé que la date soit utile pour un événement

Ainsi une même adresse peut être en lien avec une personne et un événement, si par exemple un événement est organisé chez une personne.
Vos associations de MCD deviennent des tables du MLD puisque les cardinalités maxi sont n de part et d'autres

l'association situer_pers porte un attribut TYPE_RES (type de résidence) qui permet de typer l'usage d'une adresse pour une personne


Edit : je me rends compte que j'avais copié/collé personne pour créer adresse en oubliant de corriger les attributs , du coup je viens de relivrer les modèles, c'est plus propre ainsi

[Artemus24]

Salut à tous.

Il faut commencer par donner les définitions !

Prenons 2 tables : PERSONNES et EVENEMENTS. Un événement à forcément un lien avec une personne, jusque là tout va bien.

Tout dépend si tu parles d'un lien direct ou d'un lien indirect.

L'exemple donné par Escartefigue est un lien indirect vis-à-vis des adresses.
Autrement dit, ce sont les adresses qui font la relation entre la personne et les événements.

Mais l'exemple d'Escartefigue est fausse car je ne voie nulle part la contrainte qui indique que l'adresse de l’événement est aussi celle de la personne.
Et comme définir la relation personne événements si justement, il n'y a pas des adresses ?

Une personne peut avoir une ou plusieurs adresse(s), et il en va de même avec un événement. C'est sur ce point que je sèche!

Je vais donner quelques définitions :

1) une personne possède plusieurs événements de 0 à N.
2) un évènement appartient à une et une seule personne.

3) une personne possède plusieurs adresses de 0 à N.
4) une adresse appartient à une et une seule personne.

Selon moi, la relation principale est celle entre personne et adresses. Maintenant, il faut qualifier les adresses !

Pour une adresse donnée, nous pouvons avoir :
--> une adresse de référence
--> une adresse fiscale
--> une adresse de résidence principale
--> une adresse de résidence secondaire
--> une adresse de livraison
--> une adresse de courrier
Et ce, pour la même personne.

Si ce sont à chaque fois des adresses différentes pour la même personne, alors mettre dans la table des adresses autant de ligne nécessaire.

La question que je me pose est comment qualifier l'adresse ?

Faut-il mettre à chaque fois toutes les qualifications, même si c'est toujours la même adresse ?
Non bien sûr car il y aura redondance d'informations.
Je pense que tu dois définir une qualification (ou adresse) de référence (ou par défaut) qui va servir quand tu ne trouves pas la qualification que tu cherches.
Par exemple, si l'adresse "fiscale" est présente, je prends cette adresse, sinon cela signifie que je ne trouve pas la qualification adresse "fiscale" et de ce fait, je prends nécessairement l'adresse de "référence".

Juste que là, nous avons deux tables :
--> table personne
--> table adresses qui est en relation avec la table personne par l'intermédiaire d'une clef étrangère.

Oui, mais comment définir la relation avec la table événements ? Il y a un manque.

Sachant qu'un événement n'a pas forcément d'adresse, et vise versa une personne n'en a pas forcément une non plus, ...

Ta phrase est nébuleuse, surtout avec le vice-versa.

Une personne n'en a pas forcément. Oui, mais de quoi ? D'une adresse ou d'un événement ? ou des deux?
Car si une personne n'a pas d'adresses, comment fais-tu pour lier l’événement à la personne, sinon par l'adresse, comme l'a fait Escartefigue ?
Si la personne n'a pas d’événements, cela ne pose aucun problème.

... mais que les deux peuvent en avoir plusieurs, ...

Là, je ne comprends plus du tout.

Plusieurs quoi ? Des adresses vis-à-vis des personnes et des événements ? Ou des événements vis-à-vis des personnes et des adresses ?

Selon ce que j'ai compris, les adresses sont associées à la personne !
Or ce que je ne comprends pas, c'est la relation définissant l’événement aux adresses ?

5) je pense que l’événement est associé à une adresse qui est en dépendance fonctionnelle au couple (personne ; adresses).
Le modèle d'Escartefigue ne montre pas cette dépendance.
Autrement dit, l'adresse des événements est nécessairement un sous-ensemble des adresses du couple (personne ; adresses).
La solution est de définir la dépendance fonctionnelle ! Oui mais comment faire ?

6) maintenant, il y a le cas où la personne ne possède aucune adresse. Ce cas me semble bizarre.
Ce qui revient à dire que la relation va se faire sur le couple (personne ; événements) sans passer par les adresses puisqu'elles n'existent pas.
C'est là que tout se complique !

comment pensez-vous que je devrais modéliser cela?

La solution que je propose est de créer une table association sur (personne ; adresses ; événements).

Donc la solution que je propose est la suivante :

Trois tables simples :
--> une table personne
--> une table adresses.
--> une table événements.

Une table association.
La dépendance fonctionnelle sur les adresses est résolue car les événements pointeront nécessairement sur les couples (personne ; adresses).

Mais que ce passe-t-il s'il nous manque quelque chose ?
Par exemple, il n'y a pas d’événements ? Ou pas d'adresses ?
--> S'il n'y a pas d'adresses, alors la colonne adresses de la table association sera à null.
--> S'il n'y a pas d’événements, alors la colonne événements de la table association sera à null.
Par contre, la personne sera toujours présente.
Mais tu auras nécessaire ces trois cas de figures :
--> (personne ; adresses ; événements)
--> (personne ; adresses ; NULL)
--> (personne ; NULL ; événements)

En regardant de plus près, c'est comme si tu combinais trois tables en une seule.
Autrement dit, si tu n'aimes pas les null car cela ne fait pas propre, tu peux éclater ta table association en trois autres tables.

Donc au total, cela te fait six tables, qui sont :

a) table personne.
b) table adresses.
c) table événements.

d) table assoc 1 (personne ; adresses)
e) table assoc 2 (personne ; événements)
f) table assoc 3 (événements ; adresses) sachant qu'elle est en dépendance fonctionnelle sur la table assoc 1 (personne ; adresses).

La dépendance fonctionne est de définir l'adresse d'un événement si et seulement si l'adresse est déjà en relation avec la personne.

Avec ce modèle, tu gardes toute la souplesse que tu désires obtenir.

Je pense aussi que tu dois introduire la colonne date. Mais c'est là que tout va se compliquer.
En effet, comme le fait remarquer Escartefigue et à juste titre, ton modèle doit aussi évoluer en fonction du temps.
Si tu changes une adresse, pour cause de déménagement de la personne, il faut faire en sorte de ne pas se retrouver sur un événement qui va encore pointer sur l'ancienne adresse.

@+

[funkyjul]

Bonsoir,

WOW, tout d'abord un grand merci pour vos réponses. Je suis impressionné par votre esprit d'analyse et surtout vos réponses! Je tâcherai ici d'éclaircir au maximum ma demande car je me rends compte que je n'ai pas été suffisamment clair.

Escartefigue ton schéma est très bien et je t'en remercie également. Somme toute je devrais ajouter encore la notion de type d'adresse car pour une personne ou un événement il peut exister plusieurs adresse de type différent et sauf erreur ton modèle ne me le permet pas. De plus il existe également un lien entre un événement et une personne, à savoir qu'un événement est forcément lié à une personne et une seule.

Je ne suis malheureusement pas un super expert, raison pour laquelle je vais tenter au mieux de commenter la réponse de Artemus24.

Je vais donner quelques définitions :

1) une personne possède plusieurs événements de 0 à N.
2) un évènement appartient à une et une seule personne.
3) une personne possède plusieurs adresses de 0 à N.
4) une adresse appartient à une et une seule personne.

Oui tu as tout juste avec la précision suivante... les 3 premières définitions que tu indiques sont correctes. Quant à la 4ème, je dirais oui, mais! Une adresse appartient effectivement à une et une seule personne mais de par la relation entre les personnes et les événements, une adresse peut appartenir à un événement et à une personne.

Pour une adresse donnée, nous pouvons avoir :
--> une adresse de référence
--> une adresse fiscale
--> une adresse de résidence principale
--> une adresse de résidence secondaire
--> une adresse de livraison
--> une adresse de courrier
Et ce, pour la même personne.

Effectivement une personne peut avoir potentiellement une multitude d'adresses.

Je pense que tu dois définir une qualification (ou adresse) de référence (ou par défaut) qui va servir quand tu ne trouves pas la qualification que tu cherches.
Par exemple, si l'adresse "fiscale" est présente, je prends cette adresse, sinon cela signifie que je ne trouve pas la qualification adresse "fiscale" et de ce fait, je prends nécessairement l'adresse de "référence".

Là encore je suis complètement en phase avec toi. Raison pour laquelle j'avais pensé à introduire la table TypeAdresse qui comporterait, entre autre, le type "Adresse Principale" qui ferait office de référence.

Juste que là, nous avons deux tables :
--> table personne
--> table adresses qui est en relation avec la table personne par l'intermédiaire d'une clef étrangère.

Oui on a cette liaison, comme on a la liaison entre une personne et un événement (dans la table évènement ou trouve une clef étrangère personne_id qui la lie avec la table personne)

Ta phrase est nébuleuse, surtout avec le vice-versa.

Une personne n'en a pas forcément. Oui, mais de quoi ? D'une adresse ou d'un événement ? ou des deux?

Pardon pour cela. Je voulais dire ici qu'une personne peut ne pas avoir d'adresse comme elle peut ne pas avoir d'événement. Je lie les événements directement par une clef étrangère sur les personnes. Je me réfère aux règle 1 et 2 que tu énumères en début de message.

Car si une personne n'a pas d'adresses, comment fais-tu pour lier l’événement à la personne, sinon par l'adresse, comme l'a fait Escartefigue ?

C'est justement un de mes problème, une personne peut ne pas saisir d'adresse, et sur ce point j'y tiens. Tout mon problème réside ici. J'aimerais pouvoir lier un événement à 0 ou N adresse au même titre qu'une personne à 0 ou N adresse, tout en sachant qu'un événement sera forcément lié à une personne.

5) je pense que l’événement est associé à une adresse qui est en dépendance fonctionnelle au couple (personne ; adresses).
Le modèle d'Escartefigue ne montre pas cette dépendance.
Autrement dit, l'adresse des événements est nécessairement un sous-ensemble des adresses du couple (personne ; adresses).

Justement ce n'est pas le cas! L'adresse d'un événement n'est pas un sous-ensemble du coupe (personne;adresse) car la personne peut ne pas avoir d'adresse! L'événement doit rester lié à une personne, certes, mais la personne peut ne pas avoir d'adresse alors que l'événement lui en a une.

6) maintenant, il y a le cas où la personne ne possède aucune adresse. Ce cas me semble bizarre.

Oui c'est effectivement étrange mais c'est malheureusement un cas possible.

Ce qui revient à dire que la relation va se faire sur le couple (personne ; événements) sans passer par les adresses puisqu'elles n'existent pas.
C'est là que tout se complique !

Oui c'est compliqué, du moins pour moi en tout cas!

La solution que je propose est de créer une table association sur (personne ; adresses ; événements).

Donc la solution que je propose est la suivante :

Trois tables simples :
--> une table personne
--> une table adresses.
--> une table événements.

Une table association.
La dépendance fonctionnelle sur les adresses est résolue car les événements pointeront nécessairement sur les couples (personne ; adresses).

Mais que ce passe-t-il s'il nous manque quelque chose ?
Par exemple, il n'y a pas d’événements ? Ou pas d'adresses ?
--> S'il n'y a pas d'adresses, alors la colonne adresses de la table association sera à null.
--> S'il n'y a pas d’événements, alors la colonne événements de la table association sera à null.
Par contre, la personne sera toujours présente.
Mais tu auras nécessaire ces trois cas de figures :
--> (personne ; adresses ; événements)
--> (personne ; adresses ; NULL)
--> (personne ; NULL ; événements)

Si je comprends bien ta solution je pense que cette dernière pourrait me convenir! Par contre je devrais ajouter encore la notion de type d'adresse dans ton modèle, ce qui multiplierais le nombre d'enregistrement dans la table association.

En regardant de plus près, c'est comme si tu combinais trois tables en une seule.
Autrement dit, si tu n'aimes pas les null car cela ne fait pas propre, tu peux éclater ta table association en trois autres tables.

C'est pas que j'aime pas les null, je recherche la solution la plus simple afin d'optimiser mon modèle. Cette problématique fait partie d'une schéma assez conséquent sur lequel reposera un site web. Il faut donc que je trouve le meilleur modèle!

Donc au total, cela te fait six tables, qui sont :
a) table personne.
b) table adresses.
c) table événements.

d) table assoc 1 (personne ; adresses)
e) table assoc 2 (personne ; événements)
f) table assoc 3 (événements ; adresses) sachant qu'elle est en dépendance fonctionnelle sur la table assoc 1 (personne ; adresses).

La dépendance fonctionne est de définir l'adresse d'un événement si et seulement si l'adresse est déjà en relation avec la personne.

Avec ce modèle, tu gardes toute la souplesse que tu désires obtenir.

Oui aussi, mais le précédent ne répond-il pas déjà à ma demande? Il me parait tout de même bien moins complexe.

Je pense aussi que tu dois introduire la colonne date. Mais c'est là que tout va se compliquer.
En effet, comme le fait remarquer Escartefigue et à juste titre, ton modèle doit aussi évoluer en fonction du temps.
Si tu changes une adresse, pour cause de déménagement de la personne, il faut faire en sorte de ne pas se retrouver sur un événement qui va encore pointer sur l'ancienne adresse.

Sur ce coup là je dois dire : Bien joué! Ce coup là je ne l'avais pas vu venir! Merci encore pour cette remarque extrêmement pertinente.

Voilà, j'espère qu'avec tout cela vous pourrez vous faire une idée plus précise de mon problème. Je pense que là nous ne sommes pas loin de LA solution qui me conviendrait, et, si vous le voulez bien, je serais ravis de voir vos dernières propositions.

Quoi qu'i en soit je vous remercie une fois de plus car vos explications et schémas sont vraiment au top.

Julien

[Artemus24]

Salut funkyjul.

Je ne suis pas du tout un expert. Le seul expert en ce domaine est le grand FSMREL qui répond à ce genre de question dans le forum consacré à Merise.

Justement ce n'est pas le cas! L'adresse d'un événement n'est pas un sous-ensemble du coupe (personne;adresse) car la personne peut ne pas avoir d'adresse! L'événement doit rester lié à une personne, certes, mais la personne peut ne pas avoir d'adresse alors que l'événement lui en a une.

Désolé, je n'avais pas compris cela en ces termes.
J'ai pensé à tort que la personne était l'organisateur de l'événement, et que cet événement se faisait obligatoirement chez lui. J'ai un peu trop extrapolé.

Si je comprends bien ta solution je pense que cette dernière pourrait me convenir! Par contre je devrais ajouter encore la notion de type d'adresse dans ton modèle, ce qui multiplierais le nombre d'enregistrement dans la table association.

Reprenons. Il y a trois tables de bases, qui sont : personne, événement et adresse.

La difficulté réside donc sur la table des adresses. Que mettre dedans ? Je veux dire comment traiter le cas où l'adresse est une personne ou un événement ?
L'idée qui me vient à l'esprit dans ce cas précis est d'avoir trois tables :
--> une table adresse qui contient ce qui est commun au traitement soit de la personne ou soit de l'événements.
--> une table spécifique à la relation personne - adresse.
--> une table spécifique à la relation événement - adresse.
C'est si j'ai bien compris, l'idée qui te parait inapproprié à ton problème.

Pourquoi cette organisation en trois tables (une principale et deux spécifiques) ? La principale raison est d'optimiser la volumétrie.
Imagine que la ligne soit remplie à 50% pour le cas de la personne et les 50% restant pour le cas de l'événement. Tu as une perte énorme.
La solution est de séparer le commun du spécifique, mais si tu n'as pas ce genre de problème, il est inutile de faire cette séparation.

Maintenant, si tu ne veux pas mélanger les adresses personnes d'avec les adresses événements, tu peux ne pas mettre la même clef primaire.
Genre, un code sur un caractère pour dire si c'est une personne 'P' ou un événement 'E'.

Pour la colonne "type", elle sera remplie pour les adresses personnes.
Mon idée est de créer un type par défaut, celui que tu as systématiquement présent dans ta table des adresses. Si tu as aucune adresse, autant ne rien mettre.
La notion de type d'adresse est une colonne qui sera dans la table des adresses.
Ainsi en cherchant le type "fiscalité", si tu ne le trouves pas, tu cherches l'adresse par "défaut", et si tu ne le trouves pas, tu n'as aucune adresse pour cette personne.
Ce qui nécessite de faire un traitement à part pour extraire là ou les adresses d'une personne.
Mais avec cette avantage, il n'est pas besoin de créer une table relation entre la personne et les adresses, en associant à cela, le type d'adresse.

Dans ton idée, tu voulais pour une adresse donnée, donc unique pour un client, dupliquer cette adresse autant de fois, qu'il y a de types différents. Est-ce bien cela ?

Et que faire de la colonne "type" pour les adresses événements ?
En admettant que le type sera toujours le même, autant admettre pour ce cas de figue la valeur NULL.
Cette information sera redondante avec la colonne code positionnée à 'E' comme événement.
Je suppose que tu as une et une seule adresse pour un événement.

Voici le découpage :
a) la relation personne - événement est du genre foreign key : pas de table associative.
De 0 à N événements sont rattachés à une et une seule personne.

b) la relation personne - adresse est maintenant du genre foreign key : pas de table associative.
De 0 à N adresses sont rattachés à une et une seule personne.
L'utilité de faire une table association, reposait comme je l'ai cru à tort, qu'il fallait définir une dépendance fonctionne sur les adresses.

c) la relation événement - adresse est du genre aussi foreign key : pas de table associative.
D'après tes nouvelles explications, ce ne sont pas les mêmes adresses que pour la personne.
Il n'y a plus la nécessité de faire une dépendance fonctionnelle.
Donc de 0 à 1 adresse pour un événement.

Ce qui change, c'est la table adresse qui aura deux enfants, l'une via personne et l'autre via événements et le tout par une foreign key.
Elle sera composé du code 'P' ou 'E' et d'un identificateur de type "auto incrément".

Après toutes ces pérégrination, on revient alors à la solution d'Escartefigue !

@+

[escartefigue]

Escartefigue ton schéma est très bien et je t'en remercie également. Somme toute je devrais ajouter encore la notion de type d'adresse car pour une personne ou un événement il peut exister plusieurs adresse de type différent et sauf erreur ton modèle ne me le permet pas.

Si, le modèle tel que présenté permet bien d'avoir plusieurs types d'adresse, je n'ai pas modélisé d'entité-type "type-adresse" car ce n'était pas le sujet, mais c'est ce que l'on fait le plus souvent, pour ne pas dire toujours, dès que l'on modélise les adresses.

De plus il existe également un lien entre un événement et une personne, à savoir qu'un événement est forcément lié à une personne et une seule.

Une adresse appartient effectivement à une et une seule personne mais de par la relation entre les personnes et les événements, une adresse peut appartenir à un événement et à une personne

Ces règles de gestions sont fondamentales, le problème c'est qu'elles sont dispersées dans votre énoncé, et du coup on a un peu de mal à en vérifier l'exhaustivité.
La bonne façon de procéder est de faire une liste des règles de gestion et de les identifier, comme par exemple :
R01 : une personne peut avoir de zéro à plusieurs adresses
R02 : une adresse est liée à zéro à plusieurs personnes
R03 : une personne peut être liée à zéro à plusieurs évènements
R04 : une événement est lié à une et une seule personne
etc...
En vérifiant que chaque patte - chaque lien entre une entité type (un rectangle) et une association (un ovale)- du modèle a bien sa règle de gestion expliquée

La notion d'adresse par défaut évoquée plus haut, n'est pas impactante pour le modèle de données, il s'agit d'une solution de type traitement qui est applicable (et très souvent appliquée) avec le modèle tel que proposé.

Ensuite, je vous propose de demander à un administrateur de déplacer votre sujet dans le bon forum, à savoir le forum modélisation qui est ici :
http://www.developpez.net/forums/f25...thodes/merise/

[funkyjul]

Bonjour,

Premièrement je m'excuse de ne vous avoir pas répondu plus tôt (petits soucis d'organisation.. mais bon ce n'est pas le sujet.)

Je vous remercie infiniment pour votre aide, vos remarques et vos suggestions. Il est vrai que mon énoncé de base était vraiment mal foutu et je vous trouve bien courageux de m'avoir aidé sur ce coup là!

Au final vous avez très bien cerné mon soucis et les règles établies par escartefigue sont exactes. Lors de mon prochain message je ne manquerai pas de poser mon problème ainsi, ça sera bien plus clair et plus facile pour tout le monde!

La solution que j'ai finalement adoptée et d'avoir, comme proposé au tout début, deux tables de liaison (Adresse_evenement et Adresse_Personne). Ainsi je gardes toutes la souplesse désirée dans la gestion de mes adresses!

Encore 1000 merci, mon problème est maintenant résolu, place au suivant!!

Julien