Discussion :

[sywave]

Bonjour,
je suis en train de modéliser une système dont je vous donne un extrait dans l'image ci joint.
Dans cet extrait de MCD, 3 entités et 2 associations. J'essaie d'y stocker des informations sur des clients et des agences. L'extrait montre plus particulièrement la façon de stocker l'information d'adresse pour les clients et les agences. Je souhaite stocker toutes les adresses dans la même table (que ce soit des adresses client ou des adresses d'agence)

Les entités ne m'intéresse pas particulièrement toutefois :
- L'entité Adresse permet de stocker des adresses.
- L'entité Client permet de stocker les informations des clients.
- L'entité Agence permet de stocker des renseignements sur des agences ou commerces

Ce qui m'interesse beaucoup plus, ce sont les deux associations.
L'association Habiter (entre Adresse et Client) est classique : un client habite à une et une seule adresse mais à une adresse peux correspondre plusieurs clients (le mari, la femme et pourquoi pas les enfants et les poissons rouges ^^.
C'est la seconde qui me pose problème. L'association Situer entre Agence et Adresse. Une agence est située à une et une seule adresse d'où ma cardinalité 1,1 du côté Agence. Par contre, à une adresse peut correspondre une agence mais bien souvent aucune agence d'où ma cardinalité 0,1.

Jusque là, tout peut paraitre normal. Lorsqu'on passe du MCD au MLD, on obtient ceci pour les tables Agence et Adresse :
Agence (AGE_id, AGE_nom, #ADR_id)
Adresse (ADR_id, ADR_num, ADR_rue, ADR_cp, ADR_ville, #AGE_id)
(le # signifie une clé étrangère)

Mon problème se pose à ce niveau. En effet, la clé étrangère #ADR_id dans la table Agence me semble tout à fait correct. On fait bien référence à une adresse dans la table Agence pour pouvoir la situer. Par contre, la clé étrangère #AGE_id (possiblement NULL) dans la table Adresse me semble inutile voire même dangereuse dans le sens où si elle est renseignée, il faut être bien sûr que l'agence correspondant soit bien située à la bonne adresse.

Bref, ce que j'aurais souhaité :
Agence (AGE_id, AGE_nom, #ADR_id)
Adresse (ADR_id, ADR_num, ADR_rue, ADR_cp, ADR_ville)
(le # signifie une clé étrangère)

Le plus simple pour obtenir ceci est de mettre une cardinalité 1,N à place du 0,1. Dans ce cas, j'obtiens le MLD voulu mais cela ne reflète plus la réalité.

Y-a-t-il une solution à ce problème ?

Cordialement

[tse_jc]

Bonjour et bonne année

Votre deuxième proposition de modèle est la bonne dans le contexte ennoncé. Rappel:

Agence (AGE_id, AGE_nom, #ADR_id)
Adresse (ADR_id, ADR_num, ADR_rue, ADR_cp, ADR_ville)

C'est à dire qu'une adresse peut soit correspondre à l'adresse d'une agence soit à celle d'un client, soit être orpheline (cas d'une création d'adresse en vue d'être affecté à une agence ou à un client ou cas d'un changement d'adresse d'un client ou d'une agence dans un contexte où il est conservé un historique des adresses pour chaque entité en relation).

Le souci est de pouvoir préserver l'intégrité référentielle si votre modèle relationnel est conservé ainsi. En effet cela oblige à définir l'adresse préalablement à la création d'une agence. Or si vous êtes dans un contexte de production où l'adresse d'une agence peut ne pas être connu, cela vous oblige à passer par une table de jonction modélisant cette relation : agenc_addr(AGEN_id,ADR_id) où AGEN_id et ADR_id composent alors la clé primaire de cette entité.

[sywave]

Merci pour la réponse et bonne année effectivement

Tout à fait d'accord sur le MLD correspondant à la solution mais comment cela se modélise-t-il sur le MCD et notamment pour les cardinalités de l'association situer entre agence et adresse ?

Si l'on suit les règles de passage d'un MCD au MLD, il me semble (mais je peux me tromper) que je n'ai pas trop le choix et que je doive mettre du 1,1 - 1,N. Et ceci ne reflète plus la réalité...

J'ai peut être raté qqchose ??!!

Sinon, non ce n'est pas dans un contexte de production... Ouf !

[fsmrel]

Bonsoir sywave,


Depuis que Merise existe, la règle en cause pour passer du MCD au MLD est défectueuse...

Par contre, en utilisant par exemple la notation Entité/Association de l’AGL PowerAMC, à partir du MCD :



Par dérivation, on obtient le MLD (correct) :





Autrement dit, si votre AGL de modélisation ne sait pas faire, alors vous supprimerez manuellement la colonne parasite dans la table ADRESSE, cause d’un cycle qui n’a rien à faire ici. Vous n’allez quand même pas modifier une règle de gestion de données à cause de la carence d’un outil de modélisation ou de la façon parfois fort étrange dont ceux qui ont fait Merise perçoivent la théorie relationnelle...

[sywave]

Merci de vos réponses !