Discussion :

[arnaudGo]

Bonjour,

J'ai un problème dans la conception de mon MCD, pour lequel je n'arrive pas à trouver une solution élégante et propre :

Dans le projet que je développe, les utilisateurs souhaitent de manière très classique pouvoir saisir des observations (texte libre) concernant les enregistrements de diverses tables. A la base, ça donnerait :

Table Client : champ "observations"
Table Commande : champ "observations"
Table Facture : champ "observations"

Mes utilisateurs sont répartis dans des groupes d'habilitation, c'est à dire une table Groupes. Je souhaite faire en sorte que les observations saisies par l'utilisateur d'un groupe ne soient visibles que par les utilisateurs du même groupe.

Evidemment, je n'ai pas envie de créer un champ par groupe et par table du style "observationsAdmin", "observationsGrouillotDeBase", etc...

Je n'aime pas non plus le principe d'avoir un champ "observations" dans chaque table.

Je pense donc à une table Observations, qui contiendrait l'observation, l'identifiant du groupe, et l'identifiant de l'enregistrement concerné dans la table concernée.

C'est là que je bloque : comment identifier qu'une observation concerne l'enregistrement n°x d'une table y ?

J'en suis arrivé à envisager de créer dans la table Observations les champs FK_id_Client, FK_id_Facture, FK_id_Commande, qui seraient remplis ou non selon la table concernée par l'observation. Mais franchement, je n'aime pas ce principe non plus.

Est-ce que ça inspirerait quelqu'un ? Merci d'avance...

[JPhi33]

Bonjour,

J'en suis arrivé à envisager de créer dans la table Observations les champs FK_id_Client, FK_id_Facture, FK_id_Commande, qui seraient remplis ou non selon la table concernée par l'observation. Mais franchement, je n'aime pas ce principe non plus.

C'est donc qu'il te faut une table observation par table "observée" (Client, Commande, Facture).

Je remonte au niveau MCD (il n'est jamais bon de mélanger tables et entités). Exemple pour les clients :

[ Groupe ]--0,n----( Annoter_Client )----0,n--[ Client ]

L'association Annoter_Client contient une propriété "observation_client". Lorsqu'on dérive le MCD en MLD, cette association devient une table ayant pour identifiant {id_groupe, id_client} et pour attribut "observation_client".

Tu aurais ainsi 3 tables issues de 3 associations Annoter_xxx :

[ Groupe ]--0,n----( Annoter_Client )----0,n--[ Client ]
[ Groupe ]--0,n----( Annoter_Comm )----0,n--[ Commande]
[ Groupe ]--0,n----( Annoter_Factu )----0,n--[ Facture]

L'inconvénient de ce modèle est l'obligation d'ajouter une association pour chaque nouvelle entité que l'on souhaire annoter (observer).


JPhi33

[arnaudGo]

Merci pour tes explications JPhi33 :

Qu'entends-tu par "il n'est pas bon de mélanger tables et entités" ? Veux-tu dire que je ne dois pas considérer qu'une "observation" concernant une commande n'est pas la même chose qu'une "observation" concernant un client ?

Lorsque je modélise, j'ai souvent tendance à essayer de prendre du recul en "regroupant" les choses : par exemple un client (physique) et un employé sont deux "personnes" qui auront les mêmes propriétés (nom, prénom, adresse, ...), je les distingue ensuite par des propriétés particulières, ou la présence ou non de relations avec d'autres entités.

Dans le même esprit, c'est pour cela que j'ai regroupé mes "observations" dans une seule table.

Penses-tu que c'est une mauvaise démarche ?

D'autre part, si pour des raisons pratiques je pars quand même sur la solution d'une table Observations avec plusieurs clés étrangères (FK_id_client, ...), quels inconvénients cela pose-t-il ?

Merci !

[fsmrel]

Bonjour,

C'est donc qu'il te faut une table observation par table "observée" (Client, Commande, Facture).

C’est effectivement difficilement contournable, mais d’expérience, cela fonctionne bien.
Maintenant, il existe des alternatives à la représentation proposée (voir le commentaire à suivre) :

[ Groupe ]--0,n----( Annoter_Client )----0,n--[ Client ]

Je n'aime pas non plus le principe d'avoir un champ "observations" dans chaque table.

Dans la mesure où, par exemple, un client peut l’objet de plus d’une observation, en première approche, vous n’échapperez pas à la mise en œuvre d’une entité-type Observation_client, identifiée relativement à Client. Même chose pour les factures et commandes.

Maintenant, supposons qu’un utilisateur fasse partie seulement d’un groupe. Dans ces conditions, l’entité-type Observation_client peut être transformée en association-type entre Utilisateur et Client : Chaque observation (ou annotation) détermine fonctionnellement un groupe transitivement par le biais de l’utilisateur auteur de l’observation.

[Client]--0,n---(Annoter_Client)---0,n--[Utilisateur]--1,1---(Appartenir)---1,n--[Groupe]

Si les utilisateurs peuvent partie de plusieurs groupes, on établit la relation Annoter client entre Client et l’association-type Appartenir :

[Utilisateur]--1,n---(Appartenir)---1,n--[Groupe]

[Client]--0,n---(Annoter_Client)---0,n--(Appartenir)

Si cela pose un problème métaphysique de mettre en relation les deux associations-types Appartenir et Annoter_Client, vous pouvez en passer par l’agrégation des entités-types Utilisateur, Groupe et de l’association-type Appartenir.

[fsmrel]

si pour des raisons pratiques je pars quand même sur la solution d'une table Observations avec plusieurs clés étrangères (FK_id_client, ...), quels inconvénients cela pose-t-il ?

Si votre table Observations comporte N attributs FK_id_client, FK_id_Commande, FK_id_Facture, etc. issus d’autant d’entités-types sujettes à observations (Client, Commande, Facture, etc.), étant donné que les relations dont elles sont issues sont exclusives, ces attributs seront N-1 fois truffés de valeurs nulles. Et là, ça n’est pas bon du tout. Un des enjeux majeurs de la modélisation (au niveau relationnel en tous cas) est justement d’éviter cette situation, car lors des traitements, les résultats produits par les opérateurs relationnels et autres peuvent ne pas être ceux auxquels on s’attend.

[arnaudGo]

Merci fsmrel pour votre réflexion sur mon problème.

Mes utilisateurs ne feront partie que d'un groupe à un moment donné.

Mais ce groupe peut changer dans le temps, or je veux qu'une observation conserve l'information concernant le groupe auquel appartient l'utilisateur au moment où elle est écrite. Je ne peux donc pas utiliser la transitivité pour déterminer le groupe lié à une observation.

En considérant une solution du type :

[Groupe]--0,n---(Annoter_Client)---0,n--[Client]

je vais générer une association entre chaque table à "observer" et ma table Groupe.

Or, pour faciliter la création d'écrans et de requêtes, j'aimerais rassembler toutes les observations dans une même table.



Après réflexion, je pense me tourner vers un schéma de ce type, plus propre :

[Client]--0,1----1,1--(Observation)--0,n----1,1--[Detail_observation]

[Commande]--0,1----1,1--(Observation)--0,n----1,1--[Detail_observation]

[Facture]--0,1----1,1--(Observation)--0,n----1,1--[Detail_observation]

et

[Groupe]--0,n----1,1--[Detail_observation]

Ma table Client (ou ma table Facture, Commande, ...) contient une clé étrangère pointant vers Observation, qui elle contient n Detail_observation. Enfin, chaque Detail_observation est écrit par un et un seul Groupe.

Je pense que ce schéma répond bien à mon besoin. Merci pour votre aide.

[fsmrel]

pour faciliter la création d'écrans et de requêtes, j'aimerais rassembler toutes les observations dans une même table.

Pour rassembler toutes les observations, il est préférable d’en passer par une table virtuelle, c'est-à-dire une vue, qui soit l’union (au sens relationnel) des observations relatives aux clients, commandes, etc. Je suggère que vous ne touchiez pas à la structure des tables de base au motif qu’il s’agit de simplifier les traitements. Si vous touchez à cette structure, cela vous conduira à violer les règles de la normalisation.

Disons qu’au niveau tabulaire, vous pourriez avoir la structure de base suivante concernant les relations entre les observations et les clients (même principe pour Commande, etc.) :

Client (ClientId, ...)

Observation (ObservId, ...)

ObservClient (ObservId, ClientId, ...)

Structure dans laquelle les clés primaires sont soulignées. Concernant la table ObservClient, l’attribut ObservId est aussi clé étrangère par référence à Observation et l’attribut ClientId est non seulement clé étrangère par référence à Client, mais aussi clé alternative (en SQL : Unique). On peut aussi préférer que ce soit ClientId qui y soit clé primaire, auquel cas c’est ObservId qui devient clé alternative. Je n’ai pas d’état d’âme, sinon que la première proposition va plus dans le sens de la généralisation (au sens généralisation/spécialisation).

Ma table Client (ou ma table Facture, Commande, ...) contient une clé étrangère pointant vers Observation

Dans la suggestion que je viens de faire, les rôles sont inversés (toujours en vertu du principe de rejet des valeurs nulles...)



J'aimerais bien avoir votre opinion ainsi que celle de JPhi33.