Discussion :

[Angelseb]

Bonjour, j'ai un petit problème de conception, au niveau du passage d'une agrégation du MCD vers le MLD (je n'ai jamais appris à le faire). Voici en gros ce que j'ai dans mon MCD :

entité OBJET - 1,N - association EMPORTER avec 1 attribut - 1,1 - ( entité VOYAGE - 1,N - association EFFECTUER - 1,N - entité PERSONNE )

- une personne peut effectuer un ou plusieurs voyage
- un voyage peut être effectuer par une ou plusieurs personnes
- un objet appartient à un couple voyageur - personne

merci d'avance

[fsmrel]

Bonjour Angelseb,

Vous avez écrit :

un objet appartient à un couple voyageur - personne

La règle est-elle bien la suivante :

Deux personnes différentes peuvent emporter le même objet, à condition que ce ne soit pas au cours du même voyage ?

Si cela est vrai, conceptuellement il existe une relation ternaire R entre les 3 entités-types Voyage, Personne et Objet. Mais, cette ternaire est contrainte par la CIF (contrainte d’intégrité fonctionnelle) :

Voyage X Objet -> Personne

Dans ces conditions, la représentation tabulaire est la suivante :

Personne (PersonneId, ...)

Voyage (VoyageId, ...)

Objet (ObjetId, ...)

R (VoyageId, ObjetId, PersonneId, ...)

En notant bien que, en conséquence de la CIF, l’attribut PersonneId ne fait partie de la clé de R.

[Angelseb]

Bonjour Angelseb,

La règle est-elle bien la suivante :

Deux personnes différentes peuvent emporter le même objet, à condition que ce ne soit pas au cours du même voyage ?

Le même objet peut être emporter par des personnes différentes, aussi bien lors de voyages différents, que lors du même voyage.

Par exemple, Denis et Florence voyagent ensemble, et emporte chacun dans leur paquetage du gel douche. Chacun pourra ensuite consulter les objets qu'il emporte dans son paquetage.

[fsmrel]

Denis et Florence voyagent ensemble, et emporte chacun dans leur paquetage du gel douche. Chacun pourra ensuite consulter les objets qu'il emporte dans son paquetage.

Très bien, donc ma CIF est sans objet et la relation R que j’ai évoquée dans mon message précédent prend l’allure suivante :

R (VoyageId, ObjetId, PersonneId, ...)

A noter que rien n’empêche que 2 personnes qui n’ont rien à voir entre elles puissent partager à tort le même objet (même remarque concernant la première version).

Voilà une contrainte sympathique à mettre en œuvre...

[Angelseb]

Je pense qu'on va reprendre du début car je commence à m'embrouiller

Le sujet : un programme PHP "voyages" permet à un voyageur d'ajouter les objets qu'il désire emmener avec lui dans son paquetage (un paquetage par personne et par voyage).

1) Le voyageur indique pour chaque objet saisi, sa fréquence d'utilisation : systématique (il sera par défaut dans son paquetage lorsqu'il saisit l'objet), et enfin optionnel. Pour le cas "optionnel", 2 solutions possibles : retenu et non retenu. En effet, le voyageur enregistre l'objet de fréquence optionnel, par défaut il n'est pas ajouté au paquetage du voyageur (objet de fréquence optionnel non retenu), il apparaît néanmoins en dessous des objets enregistrés dans son paquetage (les objets systématiques par ex.) et il décidera plus tard de cocher la case à côté de l'objet afin de l'ajouter à son paquetage. Ce sera devenu alors un objet de fréquence optionnel retenu.

J'ai juste modélisé ceci :
entité OBJET - 1,1 - association UTILISER - 1,N - entité FREQUENCE

L'entité FREQUENCE me permet de stocker les valeurs "systématique" et "optionnel" qui vont apparaitre dans une liste déroulante lors de la saisie des caractéristiques de l'objet.

Mais comment indiquer qu'un objet a été inclus dans le paquetage du voyageur? J'ai indiqué un début de réponse plus bas.

2) Ensuite, un utilisateur pourra consulter la base afin de voir la liste des objets saisis par un autre utilisateur, afin d'ajouter l'objet à son paquetage. Cela permet d'éviter des doublons (ex : gel douche de fréquence systématique) sauf si la fréquence d'utilisation est différente (certains peut-être trouverons que le gel douche est optionnel ) et le voyageur devra saisir alors l'objet avec la fréquence optionnel.


Je reprends mon bout de MCD :
entité OBJET - 1,N - association EMPORTER avec 1 attribut - 1,1 - ( entité VOYAGE - 1,N - association EFFECTUER - 1,N - entité PERSONNE )

J'ai donc fais ici une agrégation et non pas une ternaire, d'où les parenthèses pour le couple VOYAGE - PERSONNE. Alors là je me pose une question : est-ce que c'est en réalité une relation ternaire et non pas une agrégation, en effet, j'ai dis qu'un objet correspondait à un couple unique (VOYAGE - PERSONNE) : relation 1,1 entre l'association EMPORTER et l'association EFFECTUER. Comme un objet peut être emporter par des personnes différentes, pour le même voyage ou des voyages différents, il serait peut être plus correct d'avoir ceci :

OBJET (idObjet,...)
VOYAGE (idVoyage,...)
PERSONNE (idPersonne,...)
R (idObjet, idVoyage, idPersonne)

Pour répondre à ma question plus haut 1), je serai tenté d'ajouter l'attribut "retenu" dans la relation R, 0 pour un objet systématique donc inclus directement dans le paquetage, 1 pour un objet optionnel non retenu, et 2 pour objet optionnel retenu.

Merci d'avance pour vos réponses et si jamais je n'ai pas été assez clair, n'hésitez pas à me reposer des questions!

[fsmrel]

Cela dit, quand vous dites
il serait peut être plus correct d'avoir ceci :
OBJET (idObjet,...)
VOYAGE (idVoyage,...)
PERSONNE (idPersonne,...)
R (idObjet, idVoyage, idPersonne)

C’est ce qu’on a obtenu à ce stade, au vu des messages précédents.

Je reprends mon bout de MCD :
entité OBJET - 1,N - association EMPORTER avec 1 attribut - 1,1 - ( entité VOYAGE - 1,N - association EFFECTUER - 1,N - entité PERSONNE )

Au niveau relationnel, ceci se traduit par le prédicat :

Un objet O est emporté lors du voyage V par la personne P.

Au niveau Merise, on arrive à la même chose.

Le tout se résume à l’association R déjà évoquée :

R (VoyageId, ObjetId, Personne Id, ...)

Maintenant, concernant l’attribut "Retenu", il fait partie de R à condition de respecter les conditions suivantes :

Dépendre d’un voyage et d’un objet et d’une personne. S’il ne dépend que d’une partie de ces éléments, alors il faut revoir la question, sinon on enfreindrait la 2e forme normale (un attribut ne peut pas dépendre que d’une partie de la clé de R, justement composée des 3 attributs VoyageId, ObjetId, PersonneId).


Une observation : Vous écrivez :

j'ai dis qu'un objet correspondait à un couple unique (VOYAGE - PERSONNE)

Ceci demande certaines précisions. En effet, au 1er degré et en termes de dépendances fonctionnelles (DF), cela se traduit ainsi :

ObjetId -> {VoyageId, Personne Id} qui signifie qu’un objet détermine fonctionnellement un voyage ET une personne et qui s’écrit encore (règle de décomposition) :

ObjetId -> VoyageId
ObjetId -> Personne Id

En conséquence, l’association R devient étrangement celle-ci : R ( ObjetId , Personne Id, VoyageId...). En effet, le triplet d’attributs ne peut pas être clé, du fait des dépendances fonctionnelles.

Le système de tables serait alors le suivant :

Personne (PersonneId, ...)
Voyage (VoyageId, ...)
PsnVoyage (Personne Id, VoyageId, ...)
Objet (ObjetId, ...)
R ( ObjetId , Personne Id, VoyageId, Retenu,...)

Au niveau relationnel, le couple {Personne Id, VoyageId} de R est clé étrangère et référence à ce sujet la table PsnVoyage.
Cette représentation est contradictoire avec le fait que deux personnes peuvent partager un objet (auquel cas la DF : ObjetId -> Personne Id ne tient plus), mais je souhaitais mettre en évidence les conséquences de l’énoncé que j’ai cité, pris au 1er degré.

Autre remarque :

A supposer que les DF ne tiennent plus et donc que R redevienne :

R (idObjet, idVoyage, idPersonne)

La mise en oeuvre de la table PsnVoyage est intéressante, car elle permet de définir les couples {Personne, Voyage} légaux, indépendamment des objets. De la même façon, on pourrait mettre en œuvre une table PsnObjet permettant de définir les couples légaux {Personne, Objet} indépendamment des voyages. R serait alors une association entre PsnVoyage et PsnObjet, moins sujette à erreurs de mise à jour.

En pièce jointe, le DDL correspondant, à titre de curiosité.