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.

[arnaudGo]

Merci d'être revenu sur le problème, car je n'avais pas vu que la solution que j'envisageais comportait un inconvénient : je ne pouvais pas retrouver le Client, la Commande ou la Facture concernés par une Observation donnée.

Votre proposition me paraît effectivement la plus normalisée.
Mes habitudes (peut-être mauvaises) me poussent cependant à envisager d'ajouter une clé primaire à la table ObservClient, ce qui donnerait :

ObservClient (ObservClientId, ClientId, ObservationId)

J'aime bien avoir un identifiant unique dans toutes mes tables, quel que soit leur contenu, ne serait-ce que pour la suppression d'une ligne, qui me paraît ainsi plus sécurisée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DELETE from ObservClient WHERE ObservClientid=x;

est plus précis.

[fsmrel]

Mes habitudes (peut-être mauvaises) me poussent cependant à envisager d'ajouter une clé primaire à la table ObservClient, ce qui donnerait :

ObservClient (ObservClientId, ClientId, ObservationId)

On dispose maintenant de trois clés candidates (je rappelle que la clé primaire n'est qu'un cas particulier de la clé candidate et ne figure plus dans la théorie des relations qu'à titre historique) au lieu des deux initiales, lesquelles sont par ailleurs clés étrangères et garantissent complètement l’intégrité de la table et de ses liens avec les autres. Je ne vois pas quelle valeur ajoutée offre ObservClientId, que ce soit au niveau conceptuel ou au niveau logique.

Par ailleurs, au niveau physique, ObservClientId nécessite la mise en œuvre d’un index supplémentaire, ce qui entraîne un surcoût dans les opérations de mise à jour, donc une pénalité quant aux performances au cours de ces opérations.

Et surtout, lors des traitements quels qu’ils soient, si vous avez l’habitude de procéder ainsi, au lieu d’être CPU bound (limités par la puissance CPU dont ils disposent), ces traitements auront vite tendance à être I/O bound (en attente de fin d’entrées/sorties au niveau des disques) et la puissance du processeur sera sous-exploitée. Voyez à ce sujet l’échange avec Igou77.

J'aime bien avoir un identifiant unique dans toutes mes tables, quel que soit leur contenu, ne serait-ce que pour la suppression d'une ligne, qui me paraît ainsi plus sécurisée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DELETE from ObservClient WHERE ObservClientid=x;

est plus précis.

Votre scrupule vous honore, mais ClientId, ObservationId offrent la même garantie de sécurité, les instructions qui suivent donnent exactement le même résultat que la précédente.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DELETE from ObservClient WHERE ClientId=x;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DELETE from ObservClient WHERE ObservationId=x;

En espérant ne pas vous choquer, au nom du rasoir d’Ockham, ObservClientid devrait disparaître.

[JPhi33]

Bonjour à tous,

Qu'entends-tu par "il n'est pas bon de mélanger tables et entités" ?

Ce que je voulais dire, c'est que tu commences ton message en parlant d'un MCD et que tu continues en parlant de tables. La notion de table relève d'une vision logique des données et non du niveau conceptuel auquel se situe le MCD.
Ce mélange de niveaux peut engendrer des confusions et des incompréhensions chez tes interlocuteurs (et pas uniquement sur ce forum).
Par exemple, s'il est vrai qu'une Entité du niveau conceptuel se traduit en une Table au niveau logique, la réciproque est fausse : une Table peut aussi être issue d'une Association. Heureusement, dans ton message le "mélange" se limitait au seul terme "MCD", le reste de la terminologie relevant du MLD ou du schéma relationnel.

Lorsque je modélise, j'ai souvent tendance à essayer de prendre du recul en "regroupant" les choses

Pour moi aussi c'est une démarche qui relève d'une bonne pratique mais qui doit être guidée par les normes de modélisation et par la sémantique des concepts.

Le cas des 3 associations "Annoter_xxx" (ou "Observation_xxx") que j'ai proposées est un très bon contre-exemple. La finalité étant de n'avoir qu'une seule table Observation, on pourrait être tenté par la démarche rétro-conceptuelle suivante :

Puisque je dois n'avoir qu'une table Observation, il me faut une seule association Observation. Pour cela, il faut une seule entité associée avec Groupe. Conclusion : je dois généraliser les 3 entités Client, Commande et Facture en (par exemple) "Objet_Observé".

Ce qui, évidemment, serait une erreur conceptuelle grave car on peut pas dire que ces 3 entités sont des spécialisations d'une même sur-entité.

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]

Je n'ai pas compris cette notation. J'en suis peut-être à l'origine car je n'ai pas expliqué ma propre notation. La voici :

[ Entité ]--x,y----( Association )----z,t--[ Entité ]
Les cardinalités x, y, z, t peuvent valoir 0 ou 1 ou n.

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).
[...]
J'aimerais bien avoir votre opinion ainsi que celle de JPhi33.

Avec cette proposition on abandonne clairement l'idée qu'une observation est une association entre un Groupe et un Client (resp. Commande, Facture) au profit d'une entité Observation_Client (resp. Observation_Commande, Observation_Facture).

Pourquoi pas. Ceci introduit un concept nouveau dans la modélisation (peut-être non identifié au départ) mais, au moins, il permet la généralisation tant attendue par arnaudGo.

La modélisation serait :




JPhi33

[fsmrel]

Bonsoir,

on abandonne clairement l'idée qu'une observation est une association entre un Groupe et un Client (resp. Commande, Facture) au profit d'une entité Observation_Client (resp. Observation_Commande, Observation_Facture).

C'est effectivement très clair. Comme je l'ai fait observer, au lieu de matérialiser la chose, on aurait pu au niveau tabulaire en passer par une vue d'union, mais si arnaudGo se sent plus à l'aise avec une entité-type Observation, pourquoi pas...

Ceci introduit un concept nouveau dans la modélisation (peut-être non identifié au départ) mais, au moins, il permet la généralisation tant attendue par arnaudGo

Cette généralisation est de fait la conséquence logique du choix d'arnaudGo.

[JPhi33]

Bonjour,

Un dernier point qui ne m'est venu qu'après avoir rédigé mon dernier message (avec l'exemple Client à transposer à Commande et Facture).

Dans la première modélisation (associations entre Groupe et Client), un groupe est limité à 1 observation par client.
Dans la seconde modélisation (entité Observation), un groupe peut rédiger autant d'observations qu'il souhaite sur un même client.

Je n'ai aucune idée sur les avantages ou les inconvénients fonctionnels que cela peut induire, mais il faudra certainement qu'arnaudGo tienne compte de cette différence pour le fonctionnement de l'applicatif et avant cela, pour le choix du type de modèle.


JPhi33

[arnaudGo]

Merci à vous 2 pour vos réflexions, on sent qu'il y a de la maîtrise du sujet pour l'un comme pour l'autre !

Je pense à une nouvelle solution :
Ma table Observations se compose de :
idObservation (clé primaire)
idGroupe
idUtilisateur
NumeroTable
idEnregistrementObjet
Observation

NumeroTable est un numéro unique par lequel je désigne une table, exemple :
Client = 1
Commande = 2
Facture = 3

idEnregistrementObjet est l'identifiant unique de l'enregistrement faisant l'objet de l'observation dans la table pointée par NumeroTable.

idUtilisateur identifie l'utilisateur ayant saisi l'observation, idGroupe étant son identifiant de groupe. On conserve les deux car l'utilisateur est susceptible de changer de groupe.

Je suis conscient que c'est très artificiel, et peut-être pas trop conforme aux "règles de l'art" mais mon besoin est finalement assez léger, je n'ai pas 250 tables à "observer".
Il me suffit de documenter correctement pour que la correspondance NumeroTable/Table soit clairement établie.