Discussion :

[fsmrel]

Bonjour Antonitzer,


J’ai été bien occupé, aussi je ne réponds qu’au dernier point, je regarderai le reste plus tard.

dans l'exemple ci-dessus à l'enregistrement 2 et 4 nous retrouvons (Cl1,Fn8) or pour un client donné le FicheNo doit être unique.

Selon le MPD (conséquence du MCD), la table FICHE SUIVI a deux clés : {FicheId} qui est clé primaire et {FicheNo} qui est clé alternative : dans les deux cas c’est la règle d’unicité qui est à respecter, c'est-à-dire qu’à une valeur de FicheId correspond une seule valeur de FicheNo et une seule valeur de ContactId (donc de ClientId par ricochet dans la table CONTACT), et de la même façon, à une valeur de FicheNo correspond une seule valeur de FicheId et bien sûr une seule valeur de ContactId.

Par contre, dans votre 2e exemple, Pour FicheNo = "Fn6" il y a deux valeurs de FicheId, "Fi3" et "Fi6" (et Fn6 est en plus partagée par les clients CL1 et CL2) : il y a donc contradiction avec ce qui est modélisé.

=> Quelle est la véritable règle du jeu, à graver dans le marbre ?

[Antonitzer]

C'est une erreur de ma part de ne pas l'avoir mentionné plus tôt...

En faite pour comprendre ce qui ce passe il faut essayer de se mettre dans la peau du client. Explication illustré avec le schéma ci-contre et l'exemple :

Pour le client 1, lorsque le contact 111 fait une demande de fiche, cette demande remonte dans leur centrale (donc niveau Client) qui attribue un numéro à la fiche et nous l'envoi, d'où le faite que deux contacts de la même entreprise ne peuvent pas emmètre deux numéros de fiches identiques même s'ils ne travaillent pas dans la même agence.
Le système de gestion des numéro de fiches est des plus basiques. Le numéro de la nouvelle fiche émise s'incrémente de 1 depuis la dernière.
Donc pour en rester sur le client 1. Chronologiquement parlant si le contact 111 a émit la fiche No1 puis le contact 121 a émis la fiche No2 puis le contact 111 a émit la fiche No3

Conclusion
Si le Client 1 émet la fiche 230 c'est parce qu'il a déjà émis les fiches 1,2...229.
Pareil pour le client 2; s'il émet la fiche 140 c'est parce qu'il a déjà émis les fiches 1,2...139.

Donc il existerai la fiche numéro 120 du client 1 et aussi la fiche numéro 120 du client 2

Cela à bien sur du sens pour chaque client car de son côté les choses sont très clair mais chez nous il faut évidemment distinguer la fiche 120 du client 1 et la fiche 120 du client 2.



Vous voyez ou je veux en venir ?

PS : Pour les agences, on m'a mentionné aujourd'hui que ce serait bien que je les prennent en compte. Donc normalement cela ne devrai impacter que sur mes tables CLIENT et CONTACT, heureusement...

[fsmrel]

Bonjour Antonitzer,

Chez nous il faut évidemment distinguer la fiche 120 du client 1 et la fiche 120 du client 2.

D’accord. En conséquence, dans l’entité-type FICHE_SUIVI, l’attribut FicheNo ne fait plus l’objet d’un identifiant alternatif (donc même chose au niveau tabulaire : l’attribut FicheNo ne fait pas l’objet d’une clé alternative). Toutefois, vous avez énoncé la règle (ou contrainte suivante) :

Pour un client donné le FicheNo doit être unique.

Pour garantir cette règle, il y a deux solutions : soit on met en œuvre des triggers, soit on passe par la mise en œuvre de l’identification relative. A toutes fins utiles, je signale que les triggers ne sont pas portables d’un SGBD à l’autre (par exemple entre Oracle et SQL Server) : on se rend prisonnier du SGBD et en outre ça n’est pas toujours facile à programmer et à mettre en oeuvre : quand on peut s'en passer c'est une bonne chose.

D’un autre côté, l’identification de CONTACT relativement à CLIENT a pour mission ici de propager l’identifiant {ClientId} du client jusqu’à FICHE_SUIVI, via FIC_CON. En outre, pour savoir à quel client correspond tel FicheNo, on ajoute une association FIC_CLI entre FICHE_SUIVI et CLIENT. Il faut maintenant prendre conscience qu’on peut atteindre FICHE_SUIVI par deux chemins : il y a là une contrainte de chemin à résoudre au niveau MLD.

MCD





Suite à dérivation, dans le MLD produit, la table FICHE_SUIVI est affublée de deux colonnes ClientId : on fait le ménage à la main, on n’en garde qu’une pour être sûr que le client est bien le même, que l’on emprunte le chemin allant directement de FICHE_SUIVI à CLIENT ou bien le chemin passant par CONTACT.

MLD



Vous observerez que la table possède deux clés : {FicheId} qui est clé primaire (symbolisée par <pk>) et la paire {ClientId, FicheNo} qui est clé alternative, (symbolisée par <ak1>). L’attribut ClientId appartient aux deux clés étrangères : <fk1> référençant CONTACT et <fk4> référençant CLIENT.



On parlera ensuite des agences, mais il ne devrait pas y avoir de loup en ce qui les concerne. Il faudra aussi que l’on reparle des analyses.

[Antonitzer]

Merci pour le coup de main j'ai procédé à la modif. Bon j'avoue que je l'avais faite en amont mais content de voir que je ne me suis pas trompé.

Maintenant je dois attendre d'avoir accès à la base CLIENT déjà existante pour la compléter au niveau du. Rien de bien méchant ça va être l'histoire de rajouter quelques attributs normalement, rien de plus...

En attendant j'ai pas mal travaillé le fonctionnement de mon appli, mes écran, mes programmes, ça va encore être amener à bouger, à modifier ma BDD je sais bien j'ai de quoi commencer le dev...



Par contre pour formaliser ça et l'expliquer ca va être très compliqué parce que le dev dépend à la fois des fonctionnalités, du processus de traitement d'une fiche (au niveau organisationnel) mais aussi des utilisateurs de ces programmes.

Par exemple j'ai un même programme qui peut être utilisé soit pas nous soit par un client.
C'est un programme qui liste toutes les fiches de suivis et permet aussi de faire quelques actions comme l'export en FAQ par exemple.

Or si le programme est utilisé par le client, il ne doit pas pouvoir faire d'export en FAQ et il ne doit voir que ses fiches alors que si c'est un utilisateur de mon entreprise l'export est possible et toutes les fiches, quels que soit le client, sont visible.

Donc je pense que le mieux serait d’implémenter un mode "utilisateur" et un mode "client" dans ce programme afin d'éviter de créer deux programmes similaires.

Et cela va de même pour d'autres Programmes...

Mais pour faire apparaître tout cela sur mes MCC, MCT, MOT je crois que ça va être galère...

Merci encore pour l'aide

[fsmrel]

Bonsoir Antonitzer,

J'ai procédé à la modif. Bon j'avoue que je l'avais faite en amont mais content de voir que je ne me suis pas trompé.

Il y a quand même un bémol ! Pour résoudre le problème de l’affectation d’une fiche à un seul client, je répète qu’il faut identifier CONTACT relativement à CLIENT. En effet, en procédant ainsi, au niveau tabulaire, FICHE_SUIVI sera dotée d’une clé étrangère {ClientId, ContactId} référençant la table CONTACT, en plus de la clé étrangère {ClientId} référençant la table CLIENT.

Si l’on ne procède pas ainsi, c'est-à-dire si l’on n’identifie pas CONTACT relativement à CLIENT, on peut parfaitement se retrouver dans la situation suivante :

Table FICHE_SUIVI

Code :

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

1
2
FicheId      Clientid    ContactId    FicheNo
      1             2            4        111

Table CONTACT

Code :

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

1
2
 Clientid    ContactId    
        1            4

Où la clé primaire de CONTACT est le singleton {ContactId}, ce qui a pour conséquence que rien n’interdit que la fiche 111 appartienne à la fois au client 2 (référence directe) et (via CONTACT) au client 1.

En revanche, si la clé primaire de CONTACT est la paire {ClientId, ContactId}, la valeur de la clé étrangère {ClientId, ContactId} ci-dessous n’est autorisée que s’il existe une valeur <2, 4> pour la clé primaire de la table CONTACT : si dans la table FICHE_SUIVI, ClientId a la valeur 2, alors via CONTACT, il ne sera jamais possible de faire référence à un autre client que 2.

Code :

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

1
2
FicheId    ClientId    ContactId    FicheNo
      1           2            4        111

Table CONTACT

Code :

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

1
2
3
 Clientid    ContactId    
        1            4
        2            4

Où 4 représente le 4e contact (disons Albert) chez le client 1 ainsi que le 4e contact disons (René) chez le client 2.

je sais, l'exercice peut paraître subtil, mais c'est une façon d'assurer les contraintes de chemin et d'éviter les triggers.


N.B. Comme je vous l’ai déjà signalé, pour gagner du temps, passez directement du MCD au MPD (d’autant plus que la notation Barker est particulièrement ch... pénible à suivre). Avec le MPD (qui en réalité est encore un MLD, au moins du point de vue de la représentation graphique), on sait déjà quelle sera la structure précise des tables SQL.

[Antonitzer]

Bonjour fsmrel,

Is it any good now ?

[fsmrel]

Bonjour Antonitzer,

Is it any good now?

J’y vois plus clair, mais y a encore quelques bricoles qui traînent...


C’est d’accord pour les relations entre FICHE_SUIVI, CONTACT et CLIENT.


Il y a des scories qui traînent dans FICHE_MODIFICATION, FICHE_NON_MODIFICATION et ANALYSE, à savoir l’attribut ClientId qui doit dégager, puisqu’il est déterminé par Ficheid.


Sauf explication à préciser, le cycle entre FICHE_SUIVI et FAQ doit être rompu : qu’une FAQ fasse référence à une fiche, oui, mais à l’inverse le lien ayant pour cible FAQ doit être supprimé (clic droit sur le lien pour le sélectionner, puis touche SUPPR).

Si vous pouviez bouger quelques liens pour éclaircir encore, ça serai pas mal. Dans le même sens, il faudrait ne pas faire apparaître le nom des contraintes FK_xxx (Barre de menu > Outils> Préférences d’affichage > Contenu > Référence > Aucun).


Vous avez défini une clé candidate pour le mot de passe des contacts, mais quelle utilité ? Par exemple, peut-être avons-nous le même chez DVP, allez savoir...


On finira bien par y arriver... ^^

[Antonitzer]

Bonjour fsmrel,

En effet un mot de passe peut être le même chez deux personnes différentes, j'ai donc retiré la clé. J'ai aussi cassé le cycle FAQ-FICHE-SUIVI et on y voit maintenant un peu plus claire.
Y'a t-il de nouveaux éléments à modifier ?



Je les aurais, je les aurais... merci pour l'aide

[fsmrel]

Bonjour Antonitzer,


Ça s’aère ! Ça s’aère ! Mais il reste les scories dans FICHE_MODIFICATION, FICHE_NON_MODIFICATION et ANALYSE...

[Antonitzer]

Est-ce mieux ?

[fsmrel]

C'est bon !