Discussion :

[Antonitzer]

Bonjour tout le monde,

Depuis peu mon entreprise (une SSII) m'a mise sur ce projet d'automatisation, en soit le projet est simple je dois créer un système qui tri, répertorie et gère les mails (de demande de support).

Je me suis donc penché sur une méthode MERISE pour sa conception, et là je bloque à la mise au point du MCD...

Pour ceux qui accepterons de m'aider je vais vous décrire comment fonctionne le processus de gestion des demandes supports, donc ça risque d'être un peu long :

Nous entreprise vend 3 logiciels différents, un client possède donc forcément 1 à 3 de ces logiciels
Un client nous envoie une demande de support au service client, il remplie une fiche de suivie (.doc). Cette fiche contient les informations suivantes :

-un titre : titre
-La date d'émission de la fiche = date (JJ/MM/AAAA)
-heure d'émission de la fiche = heure (HH:MM:SS)
-le nom du client = nomClient
-un numéro de fiche = nFiche
-le logiciel = logiciel {PARK,WMS,TMS}
-le type = type {FM,FA,FQ} <=> (modification, anomalie, question)
-le niveau d'urgence = {1,2,3,4} = urgence
-une description (c'est dans ce champ que le client explique son problème) = description
-Analyse = analyse (interprétation technique du problème rédigé par notre support technique s'il y a lieu d'en faire un )
-proposition de devis = propositionDevis (s'il y a lieu d'en faire un
-un identifiant qui est crée à partir des informations "nom du client", "numéro de fiche", "type", "titre" et "date" ce qui donne : idFiche = nomClient_nFiche_type_titre_dateEtHeure.

Vu qu'il s'agit d'un fichier .doc on retrouve une fiche de suivie en cherchant dans l'explorateur le fichier "nomClient_nFiche_type_titre_dateEtHeure.doc"

Pour l'analyse, ce qui identifie de façon unique une fiche de notre côté est l'association de "nomClient" avec "nFiche" les autres informations ne servant qu'a donner des informations supplémentaire sur ladite fiche, sachant que le numéro d'une fiche est saisie par le client mais le clients ne traitant qu'avec nous pour ces demandes de supports nous avons alors chaque numéro de fiches "chez eux" correspond à ce numéro de fiches chez nous.

Maintenant moi je dois rajouter l’émetteur de la demande, soit l'interlocuteur sachant qu'un interlocuteur appartient forcément à une entreprise ET à une seule seulement mais une entreprise peut avoir plusieurs interlocuteur avec nous...


Lorsque cette fiche de suivie arrive chez nous, elle peut prendre chronologiquement ces différent statut de traitement qui sont : {Non lu; Étude; attente validation client; en cours de dev; clôturé}. et peut subir une modification du champ "type" par nos propre soins.

Sauf qu'il y aussi certaines contraintes de réalisations qui ferons apparaitre ou non certains champs qui sont :
SI "type" est différent de "FM" alors le champ "propositionDevis" est inexistant (ou vide) et la fiche ne passera pas par le statut "attente de validation client" mais directement de "Étude" à "en cours de dev""

voilà, je sais que c'est un peu long mais un petit coup de main sur une MCD me permettrais de me débloquer.

Merci d'avance

[fsmrel]

Bonjour Antonitzer,


On va essayer de vous aider en fonction de nos disponibilités (disons, du soleil qui incite au farniente...) Ah ! quand j’étais en SSII, Internet n’existait pas, on devait se d... seuls


Une 1re remarque. Vous écrivez :

Un identifiant qui est créé à partir des informations "nom du client", "numéro de fiche", "type", "titre" et "date" ce qui donne : idFiche = nomClient_nFiche_type_titre_dateEtHeure.

Le terrain est miné

Un identifiant doit être non significatif, et pour la n+1 ième fois, je répète l’avertissement d’Yves Tabourier : (De l’autre côté de MERISE, page 80), et c’est une règle d’or trop souvent méconnue, hélas ! :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Et ce qu’a écrit Y. Tabourier, je l’ai souvent constaté, c'est-à-dire que j’ai vu des applications devant être complètement réécrites car prises dans le béton avec ce genre d’affaire...

[fsmrel]

Bonsoir Antonitzer,


Pour modéliser, vous pouvez déjà mettre en évidence les entités-types de votre système :

CLIENT ;

CONTACT (les personnes chez les clients avec lesquelles vous êtes en contact pour les suivis) ;

PRODUIT (vos logiciels, lesquels sont 3 aujourd’hui, mais demain pourront être nombreux ^^) ;

FICHE_SUIVI (le cœur du modèle) ;

ANALYSE (les comptes-rendus de vos techniciens).

Sans oublier ce qu’on appelle souvent les « petites tables de codes » du genre :

TYPE_FICHE (prenant les valeurs telles que « question », « anomalie », ...)

STATUT (« Non lu », « Étude », « attente validation client », ...)

Dans un 2e temps, vous mettez en évidence les liens entre les entités-types :

Un client a au moins un contact et un contact appartient à au moins un et au plus un client ;

Un contact a pu vous transmettre de 0 à N fiches, tandis qu’une fiche a été transmise par un et un seul contact ;

Un produit peut concerner plusieurs fiches, tandis qu’une fiche concerne un et un seul produit ;

Une fiche peut faire l’objet d’une analyse et un analyse concerna au moins une et au plus une fiche.

Une fiche de type « FM » fait l’objet d’un devis et un devis concerne un et une seule fiche de ce type.

A cette occasion, vous pouvez spécialiser les fiches (par héritage) en fiches de type FM et fiches de type non FM. Cela peut vous surprendre si vous n’avez pas déjà utilisé l’héritage, mais on pourra en reparler, je vous laisse d’abord commencer à élaborer un MCD (en effet nous sommes dans le forum Merise...)

Si vous n’avez pas d’outil de modélisation, vous pouvez utiliser PowerAMC gratuitement pendant une quinzaine de jours, mais ensuite il faut payer une licence (de l’ordre de $7500, car la version à $3300 ne permet pas de réaliser des MCD ! ) Il y a aussi WinDesign, plus musclé et sans doute moins cher.

Par contre, dans les gratuits, Open ModelSphere (OMS) et DB-MAIN vous permettent de produire des MCD . L’ennui avec OMS, c’est que la production d’un MLD complet (à des fins de génération des scripts SQL de création des tables) est une galère épouvantable quand on n’en fait pas tous les jours. De son côté, DB-MAIN est plus puissant (y-compris que PowerAMC) et la production du MLD est on ne peut plus simple, mais la prise en main initiale de cet AGL surprend...


Si vous n’avez pas d’état d’âme à court-circuiter l’étape MCD, alors MySQL Workbench (gratuit) est votre ami.

[Antonitzer]

Tout d'abord merci beaucoup fsmrel pour le warning ainsi que pour ton aide, je me suis donc appuyé sur ce que tu m'as dit pour faire le mcd que je propose ici :



Je sais qu'il me manque la création de "FICHE_NON_FM" héritée de FICHE_SUIVIE le problème est que je ne sais pas ce que je peux mettre dedans étant donné qu'une fiche non fm ne contient ni analyse ni devis...

Ensuite je ne vois pas non plus comment interpréter en terme de modélisation mon association à trois branches entre FICHE_SUIVIE, TYPE_FICHE et STATUT, et je me pose aussi la question de la propriété urgence : ne devrais-je pas aussi créer un petite tables URGENCE ?

Enfin je me doute que cette ébauche de MCD doit encore contenir beaucoup d'érreur, n'hésites pas à me dire où je dois le corriger...

Merci encore pour ton aide

PS : je sais que la relation transmet de devrait pas être porteuses d'informations sauf que je ne vois pas vraiment où je dois placer ces attributs, si je dois créer une autre table...

[fsmrel]

Bonsoir Antonitzer,


Pour un 1er MCD, c’est pas mal, comme dit l’autre, vous êtes sur la bonne voie


Remarques d’usage :


Je ne sais pas pourquoi, mais les merisiens pur jus n’aiment pas qu’une association à cardinalité maximum 1 soit porteuse d’attributs, à l’instar de l’association TRANSMET. Pour ma part, ça ne me dérange aucunement, je dirais même que ça améliore la vision sémantique du sujet traité. Soit vous laissez en l’état (et PowerAMC se chargera d’expédier ces attributs dans la table FICHE_SUIVIE lors du passage au MLD (modèle logique des données), soit, dans votre MCD, vous les rapatriez dans l’entité-type FICHE_SUIVIE : vous faites comme vous le sentez.

La patte connectant l’entité-type FICHE_SUIVIE et l’association RAPPORTE est porteuse d’une cardinalité 1,1, mais selon votre exposé initial, ça serait plutôt 0,1 (« interprétation technique du problème rédigé par notre support technique s'il y a lieu d'en faire un »), voire 0,N si une fiche suivie peut faire l’objet de plus d’un rapport.

La patte connectant l’entité-type ANALYSE_CJM et l’association RAPPORTE est porteuse d’une cardinalité 1,N, ce qui signifie qu’un rapport fait référence à au moins une fiche et au plus plusieurs. Confirmez-vous ?

L’association FAIT_OBJET sous-entend que les statuts et les types de fiches dépendent les uns des autres. Si ces concepts sont indépendants, alors il y a une 1re association entre FICHE_SUIVIE et TYPE_FICHE et une 2e association entre FICHE_SUIVIE et STATUT.


Cas du niveau d’urgence des fiches (valeurs possibles)

Cliquer sur l’entité-type FICHE_SUIVIE, ce qui ouvre la fenêtre « Propriétés de l’entité ». Utiliser l’onglet « Attributs »et par un clic droit sur la ligne qui va bien, sélectionner l’attribut « Urgence ».



Par un double-clic sur cette ligne, on provoque l’ouverture de la fenêtre « Propriétés de l’attribut » :




On utilise alors l’onglet « Contrôles standards » et on valorise les valeurs Minimum et Maximum :



Au niveau SQL, cela générera une contrainte imposant que les valeurs du niveau d’urgence soient comprises entre 1 et 4. Mais quel est votre SGBD ? Si c’est MySQL, manque de chance, il ne contrôle rien du tout...


Cas de types de fiches

Vous avez 3 possibilités : modification, anomalie, question. Mais comme (si j’ai bien compris) une modification doit faire l’objet d’un devis, le type de fiche « modification » fait l’objet dans le MCD du sous-type FICHE_FM : il a son pendant, appelons-le par exemple FICHE_NON_FM, le seul désormais à être concerné par les types de fiche « anomalie » et « question » : l’entité-type TYPE_FICHE n’est plus à associer à FICHE_SUIVIE mais à FICHE_NON_FM et on y trouvera seulement les valeurs « anomalie » et « question ». Vous pouvez aussi faire disparaître TYPE_FICHE et procéder comme avec les urgences, en donnant la liste des valeurs que devra prendre l’attribut TypeFicheLibelle rapatrié dans l’entité-type FICHE_NON_FM (attribut que vous avez nommé « Type », mais il y a un risque de conflit avec les mots réservés du langage SQL), et attention quand même si un jour vous avez à ajouter des valeurs :




Cas de l’identifiant « nomClient_nFiche_type_titre_dateEtHeure »

S’il s’agit du nom d’un fichier, cela ne pose pas de problème de définir un attribut ad-hoc (appelons-le par exemple NomFichierDoc) dans l’en-tête de l’entité-type FICHE_SUIVIE.


Ci-joint un MCD que j’avais concocté en même temps que je répondais à votre 1er message :




Particularités :

— Certains attributs sont accompagnés du mickey <ai> : de même que <pi> est l’abréviation de primary identifier, <ai> est l’abréviation de alternate identifier : outre l’identifiant, un attribut (ou un sous-ensemble d’attributs) peut être contraint à unicité, c’est le cas du SIRET des entreprises, des numéros de fiche, des numéros de devis, etc., mais non contraints à l’invariance et à la non signification. Pour mettre en œuvre un identifiant alternatif, voyez la discussion avec minosys, où l’attribut CIN (carte nationale d’identité) est identifiant alternatif.

La patte connectant l’entité-type ANALYSE et l’association FIC_ANA est porteuse d’une cardinalité 1,1 mise entre parenthèses : selon les conventions propres à PowerAMC, cela signifie que l’entité-type ANALYSE est identifiée relativement à FICHE_SUIVIE, c'est-à-dire hérite de l’identifiant de cette dernière :



Si pour une fiche on pouvait avoir plusieurs analyses, alors l’identifiant d’ANALYSE serait la paire {FicheId, AnalyseId} car {FicheId} ne suffirait pas pour garantir l’unicité (voyez à ce sujet l’histoire des communes composées de quartiers) :



Mais bien sûr, si la règle de gestion est qu’une analyse peut concerner plusieurs fiches, ce que je viens d’écrire ne vaut plus.


A suivre, tant qu'on n'a pas atteint le stade SQL, courage !


P.-S. Evitez les espaces dans les noms des objets, sinon vous aurez des problèmes avec SQL...

Et n’oubliez pas de voter quand une réponse a pu vous aider...

[Antonitzer]

Bonsoir Antonitzer,


Pour un 1er MCD, c’est pas mal, comme dit l’autre, vous êtes sur la bonne voie


Remarques d’usage :

Je ne sais pas pourquoi, mais les merisiens pur jus n’aiment pas qu’une association à cardinalité maximum 1 soit porteuse d’attributs, à l’instar de l’association TRANSMET. Pour ma part, ça ne me dérange aucunement, je dirais même que ça améliore la vision sémantique du sujet traité. Soit vous laissez en l’état (et PowerAMC se chargera d’expédier ces attributs dans la table FICHE_SUIVIE lors du passage au MLD (modèle logique des données), soit, dans votre MCD, vous les rapatriez dans l’entité-type FICHE_SUIVIE : vous faites comme vous le sentez.

J'avais remarqué cela aussi mais vu que je suis débutant je vais jouer le jeu jusqu'au bout en le faisant bien.

La patte connectant l’entité-type FICHE_SUIVIE et l’association RAPPORTE est porteuse d’une cardinalité 1,1, mais selon votre exposé initial, ça serait plutôt 0,1 (« interprétation technique du problème rédigé par notre support technique s'il y a lieu d'en faire un »), voire 0,N si une fiche suivie peut faire l’objet de plus d’un rapport.

C'est exact, une erreur de saisie de ma part, chose corrigée. Cependant il peut arriver qu'après une première analyse le client apporte de nouvelles informations qui conduisent donc à une autre analyse (ou complément d’analyse) et disons que ceci peut arriver plusieurs (N) fois. Dans ce cas ces analyses se télescopent or placer une cardinalité 0,N entre FICHE_SUIVI et l'association FIC_ANA ne traduirais pas ce lien donc je vais réfléchir à un autre moyen pour modéliser ces possibilités; peut-être avec un système de création itératif de complément de fiches ...

La patte connectant l’entité-type ANALYSE_CJM et l’association RAPPORTE est porteuse d’une cardinalité 1,N, ce qui signifie qu’un rapport fait référence à au moins une fiche et au plus plusieurs. Confirmez-vous ?

Alors là c'est plus délicat pour en décider... En faite l'un des problèmes qui nous ont conduit à développer ce module est la redondance de certaines demandes (modifications, anomalies ou questions) de la part des clients. Cela peut aller de 2 clients différents, en passant par deux contact d'un même client (dû souvent à des changement de postes temporaires...) jusqu'à la même personne (sans doute un oubli de sa part...) qui nous fassent la même demande.

Disons que dans le cas logique et théorique deux fiches d'un même client ne peuvent faire l'objet d'une même analyse cependant vu les cas d'usages; pouvoir faire rapidement un renvoi à un client sur une de ses fiches (ou celles d'un autre client tant que ce n'était pas une demande de modification) déjà traitée nous feraient gagner beaucoup de temps, surtout que, comme je le dis plus haut, cela fait partie du projet d'amélioration du SI actuel...

Je vois déjà le système de FAQ pointer le bout de son nez... mais le problème est que considérer qu'une demande est redondante est affaire d'interprétation selon le contenu du champ Description dans FICHE_SUIVI or ce champ étant "libre" de saisie si je puis dire ainsi il y a une infinité de façon de demander la même chose donc informatiser cette interprétation est un vrai gageure. Cela va donc dire que je passerais par un système de moteur de recherche qui relève des mots clés dans Description de la fiche entrante faire des comparaisons puis des propositions avec ce qu'il y a en mémoire... Ouaaaa je sens que ma BDD va exploser si je pars la dedans...
Une idée pour répondre à ce problème ? ou je dois laisser tomber et dire aux gens qu'il vont devoir renforcer leur mémoire ?

L’association FAIT_OBJET sous-entend que les statuts et les types de fiches dépendent les uns des autres. Si ces concepts sont indépendants, alors il y a une 1re association entre FICHE_SUIVIE et TYPE_FICHE et une 2e association entre FICHE_SUIVIE et STATUT.

Ils sont indépendants, j'ai procédé à la modification.

Cas du niveau d’urgence des fiches (valeurs possibles)

Cliquer sur l’entité-type FICHE_SUIVIE, ce qui ouvre la fenêtre « Propriétés de l’entité ». Utiliser l’onglet « Attributs »et par un clic droit sur la ligne qui va bien, sélectionner l’attribut « Urgence ».



Par un double-clic sur cette ligne, on provoque l’ouverture de la fenêtre « Propriétés de l’attribut » :




On utilise alors l’onglet « Contrôles standards » et on valorise les valeurs Minimum et Maximum :

C'est fait, merci

Au niveau SQL, cela générera une contrainte imposant que les valeurs du niveau d’urgence soient comprises entre 1 et 4. Mais quel est votre SGBD ? Si c’est MySQL, manque de chance, il ne contrôle rien du tout...

En faite je travail sur une plateforme de dev qui s'appelle Magic xpa (compatible avec les principales BDD). Nous travaillons sur Oracle mais c'est Magic xpa qui se charge de générer la BDD de manière approprié à la BDD sur laquelle je travail. C'est pourquoi mon travail sur la conceptualisation de la BDD s'arrêtera au MPD qui prend en compte la type et la longueur des caractères, mais je ne tiens pas compte de la base de données destinée.

Cas de types de fiches

Vous avez 3 possibilités : modification, anomalie, question. Mais comme (si j’ai bien compris) une modification doit faire l’objet d’un devis, le type de fiche « modification » fait l’objet dans le MCD du sous-type FICHE_FM : il a son pendant, appelons-le par exemple FICHE_NON_FM, le seul désormais à être concerné par les types de fiche « anomalie » et « question » : l’entité-type TYPE_FICHE n’est plus à associer à FICHE_SUIVIE mais à FICHE_NON_FM et on y trouvera seulement les valeurs « anomalie » et « question ». Vous pouvez aussi faire disparaître TYPE_FICHE et procéder comme avec les urgences, en donnant la liste des valeurs que devra prendre l’attribut TypeFicheLibelle rapatrié dans l’entité-type FICHE_NON_FM (attribut que vous avez nommé « Type », mais il y a un risque de conflit avec les mots réservés du langage SQL), et attention quand même si un jour vous avez à ajouter des valeurs :




Cas de l’identifiant « nomClient_nFiche_type_titre_dateEtHeure »

S’il s’agit du nom d’un fichier, cela ne pose pas de problème de définir un attribut ad-hoc (appelons-le par exemple NomFichierDoc) dans l’en-tête de l’entité-type FICHE_SUIVIE.


Ci-joint un MCD que j’avais concocté en même temps que je répondais à votre 1er message :

Si je comprend bien c'est une forme de "résolution à la booléenne"^^; si ma fiche ne contient pas de TypeFiche, par opposition à l’ensemble "anomalie union question" qui en contiennent un c'est forcément une modification, c'est ça non ?

Particularités :

— Certains attributs sont accompagnés du mickey <ai> : de même que <pi> est l’abréviation de primary identifier, <ai> est l’abréviation de alternate identifier : outre l’identifiant, un attribut (ou un sous-ensemble d’attributs) peut être contraint à unicité, c’est le cas du SIRET des entreprises, des numéros de fiche, des numéros de devis, etc., mais non contraints à l’invariance et à la non signification. Pour mettre en œuvre un identifiant alternatif, voyez la discussion avec minosys, où l’attribut CIN (carte nationale d’identité) est identifiant alternatif.

La patte connectant l’entité-type ANALYSE et l’association FIC_ANA est porteuse d’une cardinalité 1,1 mise entre parenthèses : selon les conventions propres à PowerAMC, cela signifie que l’entité-type ANALYSE est identifiée relativement à FICHE_SUIVIE, c'est-à-dire hérite de l’identifiant de cette dernière :



Si pour une fiche on pouvait avoir plusieurs analyses, alors l’identifiant d’ANALYSE serait la paire {FicheId, AnalyseId} car {FicheId} ne suffirait pas pour garantir l’unicité (voyez à ce sujet l’histoire des communes composées de quartiers) :

Je dois avoir encore un manque de vocabulaire, je voudrais vérifier certaines choses histoire de ne pas m'embrouiller :
_quelle est la différent entre un attribut <pi> et un identifiant si ce n'est pas la même chose ?
_l'attribut <ai> , à quoi cela sert-il réellement si j'ai déja ce qu'il me faut pour identifier mes instances ??
_(Ayant regarder vos liens) je ne comprend pas l'intérêt de créer des index...

Mais bien sûr, si la règle de gestion est qu’une analyse peut concerner plusieurs fiches, ce que je viens d’écrire ne vaut plus.

A voir, il faut que je trouve une solution pour gérer ces situation de travail explicité plus haut...

A suivre, tant qu'on n'a pas atteint le stade SQL, courage !

Etant donné que j'ai compris votre MCD et que je suis tout à fais d'accord avec lui je continue donc mes réflexions à partir de celui là...j'ai donc procédé aux modif ne l'ai pas posté ici...

Merci encore pour toute cette aide

Dernière question, lorsque je vais devoir prendre en compte mes traitement comment cela va influencer ma BDD ? Ou-est ce que les données crées liées aux traitement ne sont que des temp ?

P.-S. Evitez les espaces dans les noms des objets, sinon vous aurez des problèmes avec SQL...

Et n’oubliez pas de voter quand une réponse a pu vous aider...

[fsmrel]

Bonsoir Antonitzer,

Dans ce cas ces analyses se télescopent

C'est-à-dire ?

le problème est que considérer qu'une demande est redondante est affaire d'interprétation selon le contenu du champ Description dans FICHE_SUIVI or ce champ étant "libre" de saisie si je puis dire ainsi il y a une infinité de façon de demander la même chose

De fait, et cela relève de l’organisation. Un bon problème pour archivistes... Pour ma part, ne connaissant pas le domaine, je ne peux que rester silencieux...

si ma fiche ne contient pas de TypeFiche, par opposition à l’ensemble "anomalie union question" qui en contiennent un c'est forcément une modification, c'est ça non ?

En quelque sorte...
En dépit de la contrainte de partitionnement (exclusion et totalité) portée par la lunule, selon laquelle une fiche est soit une fiche de modification, soit une fiche d’anomalie/question, un problème pourrait se poser :
fiche contenant des données dans la table FICHE_SUIVI, mais sans rien dans les tables FICHE_MODIFICATION et FICHE_NON_MODIFICATION...

quelle est la différence entre un attribut <pi> et un identifiant si ce n'est pas la même chose ?

Comme je l’ai déjà signalé, « <pi> » (abréviation de primary identifier) n’est qu’un mickey pour signifier que l’attribut concerné participe est identifiant. C’est la façon de PowerAMC de faire des mickeys, mais les autres AGL ont leurs propres façons de faire.

l'attribut <ai>, à quoi cela sert-il réellement si j'ai déjà ce qu'il me faut pour identifier mes instances ??

Ça sert à garantir l’unicité. Supposez que vous ayez besoin du numéro SIRET de vos clients (j’ai déjà évoqué le SIRET dans un message précédent). Comme deux clients ne peuvent pas avoir le même SIRET, on blinde la base de données en déclarant l’attribut SIRET comme identifiant alternatif. Si on ne le fait pas, on a toutes les chances de voir un jour des clients avec le même SIRET dans la table CLIENT, ça ferait désordre.

je ne comprends pas l'intérêt de créer des index

Hum... Je n’ai pas vu que j’ai parlé des index : un index n’est pas un objet dont on parle au niveau conceptuel, mais au niveau physique, comme ici ...

lorsque je vais devoir prendre en compte mes traitement comment cela va influencer ma BDD ? Ou est-ce que les données crées liées au traitement ne sont que des temp ?

Vous serez confronté au problème du prototypage des performances, vous devrez identifier les requêtes SQL qui reviendront le plus souvent, et cette fois-ci, vous devrez avoir une certaine connaissance des index, ou plutôt du rôle qui leur est imparti dans la performance des traitements, mais sans avoir à plonger bien sûr dans l’étude de ce qui se passe sous le capot, à moins que vous n'y preniez goût.

[Antonitzer]

Bonsoir Antonitzer,

C'est-à-dire ?

Je veux dire par là qu'une analyse viendra forcément en complément d'une autre.

Exemple tout simple : Un artisan ébéniste reçoit une commande d'un client qui demande une table d’extérieur pour 6 personnes d'un jaune clair. Il répond avec l'analyse et la proposition de devis :

analyse1 : fabrication d'une table résistante à l'environnement extérieur pour 6 personnes d'une gamme de couleur jaune clair
Devis1 : table en bois avec vernis qui accepte les agressions extérieur d'une dimension de 5m x 1,20 d'une couleur au choix (jaune1,jaune2,...)

le client : "je suis d'accord et je choisi la couleur jaune2
Nous
-analyse2 :fabrication d'une table résistante à l'environnement extérieur pour 6 personnes d'une gamme de couleur jaune2.
-Devis2 : table en bois avec vernis qui acceptes les agressions extérieur d'une dimension de 5m x 1,20 d'une couleur jaune2.
-montant : x1

le client répond : "d'accord pour le devis, sauf que j'ai oublié de dire que je veux qu'elle fasse aussi 1,30m de hauteur."

analyse3 : analyse1 + " et qui doit mesurer un hauteur de 1,30m."
Devis3 : table en bois avec vernis qui acceptes les agressions extérieur d'une dimension de 5m x 1,20 d'une couleur jaune2 et de taille 1,30m
montant : x2

puis enfin le client accepte...

On a donc le client qui complète sa demande, or si cela n'est pas clairement identifié et traité dans le programme à chaque fois que le client veut répondre il crée une nouvelle fiche, alors que nous on répond à chaque fois sur l'ensemble de la demande ce qui crée une incohérence.

De fait, et cela relève de l’organisation. Un bon problème pour archivistes... Pour ma part, ne connaissant pas le domaine, je ne peux que rester silencieux...

Je ne vais pas trop me prendre la tête la dessus, je vais créer un table FAQ qui récupère les données idFiche,ProduitId,Titre,Description,TypeFicheId, + un champ texte "Solution" que je vais créer dans la table FICHE_NON_MODIFICATION qu'un technicien pourra remplir.
Ensuite je crée un bouton "exporter FAQ" sur l'écran pour qu'à son bon vouloir le technicien puisse exporter la fiche sur la FAQ une fois la fiche cloturée. Cela va modifier quelques peut les méthodes de travail mais bon ça devait forcément arriver quand on touche au SI...

Je remarque d'ailleurs que ma TABLE "FICHE_MODIFICATION" ne contient pas de champ texte permettant au technicien d'écrire la proposition de devis (DevisProposition), je vais rajouter ça

En quelque sorte...
En dépit de la contrainte de partitionnement (exclusion et totalité) portée par la lunule, selon laquelle une fiche est soit une fiche de modification, soit une fiche d’anomalie/question, un problème pourrait se poser :
fiche contenant des données dans la table FICHE_SUIVI, mais sans rien dans les tables FICHE_MODIFICATION et FICHE_NON_MODIFICATION...

La je ne comprend pas, si mes sous-fiches héritent de ma table FICHE_SUIVI elles contiennent a fortiori les attributs de cette table. Ensuite c'est à moi d'organiser mon traitement pour faire en sorte que si ma fiche détectée est une FM alors on écrit dans la table FICHE_MODIFICATION sinon dans la table FICHE_NON_MODIFICATION.

Comme je l’ai déjà signalé, « <pi> » (abréviation de primary identifier) n’est qu’un mickey pour signifier que l’attribut concerné participe est identifiant. C’est la façon de PowerAMC de faire des mickeys, mais les autres AGL ont leurs propres façons de faire.

Ça sert à garantir l’unicité. Supposez que vous ayez besoin du numéro SIRET de vos clients (j’ai déjà évoqué le SIRET dans un message précédent). Comme deux clients ne peuvent pas avoir le même SIRET, on blinde la base de données en déclarant l’attribut SIRET comme identifiant alternatif. Si on ne le fait pas, on a toutes les chances de voir un jour des clients avec le même SIRET dans la table CLIENT, ça ferait désordre.

D'accord je pense mieux comprendre, disons que c'est par conséquence de la nature de l'info qu'il renferme (le SIRET est unique à chaque entreprise) qu'il est un identifiant, car vu qu'il a la contrainte d'unicité comme un identifiant MAIS qu'il est significatif on en fait un identifiant alternatif, ok merci

Mais pour bien être sur, si dans ma table j'ai (hors mis d'autres attributs) : b<pi>, c<ai1> et d<ai2> on est bien d'accord qu'un ensemble {b,c} ou {b,d} est suffisant pour identifier mon élément ? Nul besoin d'un triplet {b,c,d} ?

Hum... Je n’ai pas vu que j’ai parlé des index : un index n’est pas un objet dont on parle au niveau conceptuel, mais au niveau physique, comme ici ...

Je sais que vous ne m'en avez pas parlé mais en allant jeter un œil sur les liens que vous m'avez donné, ça parle d'index donc je m'y suis intéressé pour le jour ou ça arrivera car apparemment c'est incontournable.
Je crois avoir compris ce que c'est; c'est pour localiser ou se trouve un enregistrement dans ma table, comme une sorte de numérotation sauf que vu que ce n'est pas forcément "1,2,3..." on n'emploi pas le terme numérotation.

Le problème que j'avais avec la notion d'index c'était la confusion avec l'identifiant (oui je sais maintenant avec le recul c'est très bête) mais comme à un endroit donné de ma table il ne peut y avoir qu'un seul enregistrement j'ai fait l'amalgame. Mais je comprend bien maintenant que si on ajoute un nouvel enregistrements dans la table l'association indexA-enregitrementE change.

Vous serez confronté au problème du prototypage des performances, vous devrez identifier les requêtes SQL qui reviendront le plus souvent, et cette fois-ci, vous devrez avoir une certaine connaissance des index, ou plutôt du rôle qui leur est imparti dans la performance des traitements, mais sans avoir à plonger bien sûr dans l’étude de ce qui se passe sous le capot, à moins que vous n'y preniez goût.

Ok ça je pense que je le verrais une fois que j'aurais finalisé ma BDD, que j'aurai vu tout mes traitements et fait toutes mes vues...

Maintenant que je commence à penser aux traitements je remarque que j'ai oublié des choses importantes dans ma BDD actuelle. En faite lorsqu'une fiche arrive dans notre logiciel (fiche qui sera saisie depuis un formulaire HTML/PHP sur notre site web) elle s'ajoute à l'ensemble des fiches présentes. Tous les utilisateurs ont une visibilité sur ces fiches via un tableau qui les liste et chacun pioche/réserve les fiches dans cette liste et les traitent. Il faut donc pouvoir avoir une traçabilité sur le technicien qui a suivi une fiche...

C'est là qu'une question me vient; si une fiche est suivie par plusieurs personnes de manière successive alors il va falloir que je mette en place un système d'historisation n'est-ce pas ?

Très bien donc avant de poster un nouveau mcd je vais créer mes tables UTILISATEURS, FAQ, ajouter mes champs DevisProposition et Solution puis réfléchir à ce problème d'historisation (s'il a lieu de se faire maintenant ?).

Merci encore pour l'aide

[Antonitzer]

J'ai fais deux propositions pour le MCD avec la FAQ et les utilisateurs. La seule différence entre les deux est que je me demande si l’association a trois pattes est possible ici. Cependant quand je pense au MLD un problème me chagrine étant donné mes cardinalité au niveau de mon association entre FAQ et FICHE_SUIVI lors du MLD c'est la table FICHE_SUIVI qui va prendre les identifiants de la FAQ, ce qui ne me paraît pas être de bon sens...

Pour mon analyse est "La FAQ peut contenir entre 0 et plusieurs FICHE_SUIVI mais une FICHE_SUIVI ne peut appartenir au plus qu'une seule fois à la FAQ"

Je pense un peu d’où vient le problème, l’existence de la table FAQ évoque qu'il peut y avoir plusieurs FAQ alors que je n'en veux qu'une seule, comment modéliser cela ?

Concernant les cardinalité sur l'association entre CLIENT et FAQ j'ai fait l'analyse "Un client peut consulter de 0 à plusieurs fiches sur la FAQ et une fiche peut être consultée par 0 ou plusieurs clients.
Ensuite il y a certaines règle qu'il faut que je mette en place qui sont :
_Une fiche ne peut appartenir à la FAQ que si sont statut est "clôturé".
_Une fiche de type anomalie ou question peut être consulté par tous les clients.
_Une fiche de type modification ne peut être consulté que par le client qui en a fait la commande.

Est-ce que ces règles impact mon MCD ??

Merci encore pour tout cette aide

[fsmrel]

Bonsoir Antonitzer,

La seule différence entre les deux est que je me demande si l’association à trois pattes est possible ici.

Revenons à la définition de la participation des occurrences (instances) d’une entité-type à une association :

Dans le cas du 1er MCD, la patte connectant l’entité-type FICHE_SUIVI et l’association FIC_CLI_FAQ est porteuse d’une cardinalité 0,1, ce qui signifie qu’une occurrence F1 de l’entité-type participe facultativement à l’association, et si elle y participe, c’est au plus une fois.

La patte connectant l’entité-type CLIENT et l’association FIC_CLI_FAQ est porteuse d’une cardinalité 0,N, ce qui signifie qu’une occurrence C1 de l’entité-type participe facultativement à l’association, et si elle y participe, ça peut être plus d’une fois.

La patte connectant l’entité-type FAQ et l’association FIC_CLI_FAQ est porteuse d’une cardinalité 0,N, ce qui signifie qu’une occurrence Q1 de l’entité-type participe facultativement à l’association, et si elle y participe, ça peut être plus d’une fois.

Tout ceci revient à dire que par cette association, la fiche F1 fait référence à un seul client (par exemple C1) et une seule FAQ (par exemple Q1). En revanche, par cette association, le client C1 peut faire référence aux fiches F1, F2, etc., ainsi qu’aux FAQ Q1, Q2, etc. De la même façon, la FAQ Q1 peut faire référence aux fiches F1, F2, etc., ainsi qu’aux clients C1, C2, etc.

Exemple :

Code :

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

1
2
3
4
5
6
7
Fiche    Client    FAQ
F1       C5        Q4
F4       C8        Q4
F9       C8        Q4
F10      C3        Q4
F45      C5        Q2
...      ...       ...

Où l’on observe que si une fiche participe à l’association c’est bien au plus une fois, contrairement aux FAQ et aux clients.

La ternaire FIC_CLI_FAQ ne semble pas s’imposer...

Quand je pense au MLD un problème me chagrine étant donné mes cardinalité au niveau de mon association entre FAQ et FICHE_SUIVI lors du MLD c'est la table FICHE_SUIVI qui va prendre les identifiants de la FAQ, ce qui ne me paraît pas être de bon sens...

Nuance. La table FICHE_SUIVI ne « prend » pas d’identifiant de FAQ, elle conserve sa valeur de clé primaire (son identifiant propre), mais en plus elle fait référence à la valeur de la clé primaire d’une FAQ donnée :

FICHE_SUIVI

Code :

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

1
2
3
4
5
6
7
IdFiche    idFaq
F1         Q4
F4         Q4
F9         Q4
F10        Q4
F45        Q2
...        ...

l’existence de la table FAQ évoque qu'il peut y avoir plusieurs FAQ alors que je n'en veux qu'une seule, comment modéliser cela ?

Une seule ligne pour la table FAQ ?? Si c’est bien cela, il suffit d’ajouter une contrainte comme quoi la clé primaire ne peut prendre qu’une seule valeur, par exemple la valeur 1...

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE FAQ 
(
   idFaq                INT               NOT NULL,
   ...
   CONSTRAINT FAQ_PK PRIMARY KEY (idFaq),
   CONSTRAINT FAQ_CHK CHECK (idFaq = 1)   
) ;

mon analyse est "La FAQ peut contenir entre 0 et plusieurs FICHE_SUIVI mais une FICHE_SUIVI ne peut appartenir au plus qu'une seule fois à la FAQ"

Avec la contrainte précédente, par le jeu des clés étrangères, toutes les fiches ne pourront faire référence qu’à la seule FAQ définie au moyen de la table ci-dessus, et limitée à une seule ligne...

Une fiche ne peut appartenir à la FAQ que si son statut est "clôturé".

Cela revient à un problème de droit d’accès à la FAQ en fonction de son statut : les requêtes de consultation dans lesquelles la FAQ est impliquée devront comporter une condition du genre WHERE STATUT = « clos ».

Une fiche de type modification ne peut être consultée que par le client qui en a fait la commande.

Même principe, en filtrant par jointure des tables FICHE_MODIFICATION, FICHE_SUIVI, CONTACT et CLIENT. Si le résultat de la jointure n’est pas « vide », cela veut dire que la fiche concerne le client en question et lui seul.

Est-ce que ces règles impactent mon MCD ?

Normalement, non.

[Antonitzer]

Une seule ligne pour la table FAQ ?? Si c’est bien cela, il suffit d’ajouter une contrainte comme quoi la clé primaire ne peut prendre qu’une seule valeur, par exemple la valeur 1...

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE FAQ 
(
   idFaq                INT               NOT NULL,
   ...
   CONSTRAINT FAQ_PK PRIMARY KEY (idFaq),
   CONSTRAINT FAQ_CHK CHECK (idFaq = 1)   
) ;

Avec la contrainte précédente, par le jeu des clés étrangères, toutes les fiches ne pourront faire référence qu’à la seule FAQ définie au moyen de la table ci-dessus, et limitée à une seule ligne...

Non méa culpa j'ai dis un bêtise, cela est incohérent, je vais expliquer ce que je veux mettre en place...

En faite je veux qu'une fiche qui porte le statut "clos" PUISSE être envoyé dans dans la FAQ ( là je parle du site web ) qui donc contient plusieurs instances (Q1,Q2...) de la table FAQ. Là ou je me suis mal exprimée c'est qu'une fiche, si elle est exporté sur la FAQ déclenchera un enregistrement sur celle-ci, une nouvelle instance de la table FAQ.
En conclusion une fiche F3 PEUT faire référence à une FAQ Q1 et au plus à une seul. De l'autre côté une FAQ Q2 fait forcément référence à une fiche F6 (logique vu qu'il faut avoir eu au préalable une fiche pour donner cette Q2).

Si on peut ici parler d'une injection de l'ensemble FAQ {Q1,Q2,Q3...} dans l'ensemble FICHE_SUIVI {F1,F2,F3...} ?? Alors c'est ça et je crois comprendre pourquoi c'est donc la fiche qui va porter l'identifiant (en tant que référence j'ai bien compris) de la FAQ...

Quand à la relation FAQ avec CLIENT, cela est similaire à la relation CLIENT avec FICHE_SUIVI (par bon sens j'entend bien). Car un client peut emmètre plusieurs fiches (comme nous l'avons vu au début) et chacune de ces fiches peuvent faire l'objet d'une FAQ et d'une seul donc plusieurs FAQ peuvent faire référence à un même client.

Je ne pense que cette fois nous pouvons parler de surjection de FAQ dans CLIENT car cela sous-entendrais qu'un client possède au moins une FAQ ce qui n'est pas forcément le cas.

Ce qui donnerai :

Fiche	client	faq
F1	C3	Q3
F3	C3	Q5
F6	C4	Q7
F8	C5	Q9
F10	C5	Q11

Donc maintenant vu qu'a priori, à partir d'un FAQ Q1 je peut savoir à quel FICHE_SUIVI elle faire référence, fiche qui forcément été émise par au plus un CONTACT travaillant chez au plus un CLIENT je peux savoir à quel client cette FAQ est associé donc inutile de créer une association entre mes table CLIENT et FAQ ?

Autre question :
Étant donné que le TypeFicheId d'une fiche est à prendre en compte sur la FAQ pour ces histoires de visibilité, ma table FAQ ne devrait-elle pas plutôt être associé à FICHE_MODIFICATION et/ou à FICHE_NON_MODIFICATION ? Sinon comment récupérer l'information sur le type de ma fiche vu que FICHE_SUIVI ne contient pas cette information ?

Cela revient à un problème de droit d’accès à la FAQ en fonction de son statut : les requêtes de consultation dans lesquelles la FAQ est impliquée devront comporter une condition du genre WHERE STATUT = « clos ».

D'accord donc cela sera à voir au niveau des traitements...

Nuance. La table FICHE_SUIVI ne « prend » pas d’identifiant de FAQ, elle conserve sa valeur de clé primaire (son identifiant propre), mais en plus elle fait référence à la valeur de la clé primaire d’une FAQ donnée :

Très bien, mais donc par "fait réference" on entend bien que ce champ de référence peut-être vide ? (une fiche n'étant pas forcément exportée en FAQ)

Même principe, en filtrant par jointure des tables FICHE_MODIFICATION, FICHE_SUIVI, CONTACT et CLIENT. Si le résultat de la jointure n’est pas « vide », cela veut dire que la fiche concerne le client en question et lui seul.

Mais y-a t'il obligation de faire une jointure avec la table CONTACT ? car dans le cas de la consultation de la FAQ pour un client donné (un client peut avoir plusieurs contacts) un contact peut très bien consulter une "ancienne" FICHE_MODIFICATION émise par un de ses collègues.

Merci pour ton aide !!

[Antonitzer]

Voila ce que j'obtiens sur la vérification de mes MCD et MLD (MLD respectivement généré à partir du MCD...)


LE MCD




En ce qui concerne l'absence d'association sur FICHE_MODIFICATION; comme mentionné plus haut, il est possible que cela soit corrigé grâce à une association avec FAQ...qu'est-ce que vous en pensez ?
(Je suis choqué qu'il me mentionne un manque d'identifiant sur ANALYSE alors que j'ai bien coché que c'est un identifiant dans la propriété du lien d'association.. )

LE MLD





Par contre pour tous ces problèmes de vérification du MLD je n'ai pas vraiment d'idées car je ne comprend pas vraiment ce qu'ils signifient...pourriez-vous m'aider la dessus ?


Vu les problèmes causés par ANALYSE je me demande si ce ne serait pas mieux de créer un attribut FicheSuiviAnalyse dans FICHE_SUIVI et supprimer ANALYSE ?

D'ou vient ce FIC_ANA2 d'ailleurs ?

Encore merci

[fsmrel]

Bonsoir Antonitzer,

une FAQ Q2 fait forcément référence à une fiche F6

Ainsi, la FAQ Q2 n’existe que parce qu’il existe d’abord une fiche, F6 en l’occurrence, celle-ci ayant servi pour créer Q2 : la règle est donc : une FAQ a pour origine une et une seule fiche (avec la contrainte que celle-ci soit close). Dans l’autre sens, F6 ne peut engendrer qu’une FAQ, en l’occurrence Q2. S’il en est ainsi, on a bien une injection :

[FICHE_SUIVI]--0,1--------(Fiche Engendrer FAQ)--------1,1--[FAQ]

Notez la cardinalité 0,1 : dans votre MCD il faut remplacer 0,N par 0,1.


Comme un client peut être à l’origine de plusieurs fiches, il peut donc être à l’origine de plusieurs FAQ.

Ce qui donnerait :

Fiche	client	faq
F1	C3	Q3
F3	C3	Q5
F6	C4	Q7
F8	C5	Q9
F10	C5	Q11

Oui.

Inutile de créer une association entre mes table CLIENT et FAQ ?

Bien sûr que c’est inutile, du fait de la transitivité, via la fiche et le contact, on sait quel est le client qui est à la source de la FAQ. Si donc un client ne peut consulter que les FAQ dont il est à l’origine, pas de problème.

Le TypeFicheId d'une fiche est à prendre en compte sur la FAQ.

On sait déterminer le type de la fiche :

1) Si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_MODIFICATION n’est pas vide, la fiche est de type modification.

2) Si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_NON_MODIFICATION n’est pas vide, la fiche est de type question/anomalie.

3) Si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_MODIFICATION n’est pas vide et si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_NON_MODIFICATION n’est pas vide non plus, alors il y a un bug, une m... dans la base, mais on sait éviter cela au moyen d’un trigger.

4) Si le résultat est vide, il est temps de mettre à jour la table incomplète (FICHE_MODIFICATION ou FICHE_NON_MODIFICATION)...

Maintenant on accroche sa ceinture. Pour parvenir à nos fins, il y a (au moins) deux solutions en SQL (J’utilise ici MS SQL Server). Une 3e solution consisterait à intercepter des mises à jour de vue au moyen de triggers, mas je ne voudrais pas trop vous traumatiser, et puis les triggers sur les vues ça ne fonctionne pas avec tous les SGBD (au moins MySQL)...

La 1re solution consiste à définir une fonction permettant de mettre à jour une colonne qui est fonction du reste.

(a) On crée d’abord la table FICHE_SUIVI ainsi :

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE FICHE_SUIVI
(
        FicheId            INT              NOT NULL
      , Description        VARCHAR(64)      NOT NULL 
    , CONSTRAINT FICHE_SUIVI_PK PRIMARY KEY (FicheId)            
) ;

(b) Puis les tables FICHE_MODIFICATION et FICHE_NON_MODIFICATION :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE FICHE_MODIFICATION
(
        FicheId            INT              NOT NULL
      , DevisProposition   VARCHAR(64)      NOT NULL
    , CONSTRAINT FICHE_MODIFICATION_PK PRIMARY KEY (FicheId)  
    , CONSTRAINT FICHE_MODIFICATION_FICHE_FK FOREIGN KEY (FicheId)
          REFERENCES FICHE_SUIVI (FicheId)  
) ;

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE FICHE_NON_MODIFICATION
(
        FicheId            INT              NOT NULL
      , TypeFicheLibelle   VARCHAR(64)      NOT NULL
    , CONSTRAINT FICHE_NON_MODIFICATION_PK PRIMARY KEY (FicheId)  
    , CONSTRAINT FICHE_NON_MODIFICATION_CHK01 CHECK (TypeFicheLibelle IN ('question', 'anomalie'))
    , CONSTRAINT FICHE_NON_MODIFICATION_FICHE_FK FOREIGN KEY (FicheId)
          REFERENCES FICHE_SUIVI (FicheId)  
) ;

(c) On créée ensuite une fonction qui permettra de valoriser le contenu d’une colonne TypeFiche (définie un peu plus loin, cf. point (d)). Si on insère une ligne dans la table FICHE_MODIFICATION, alors la colonne TypeFiche prendra la valeur 'modification', si c’est dans la table FICHE_NON_MODIFICATION, alors la colonne TypeFiche prendra la valeur qui est celle de la colonne TypeFicheLibelle de la table FICHE_NON_MODIFICATION. L’argument de la fonction est défini par la colonne TypeId de la table FICHE_SUIVI.

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE FUNCTION TypeFicheFonction(@a VARCHAR(16))
RETURNS VARCHAR(16)
AS
BEGIN
    DECLARE @R AS VARCHAR(16)
 
    SET @R = (SELECT COUNT(*) 
              FROM  FICHE_MODIFICATION
              WHERE FicheId = @a)
    IF @R > 0 
        BEGIN
            SET @R = 'modification'
        END
    ELSE
        BEGIN
            SET @R = (SELECT TypeFicheLibelle 
                      FROM   FICHE_NON_MODIFICATION
                      WHERE FicheId = @a)                 
        END   
 
    RETURN @R
END ;

(d) Table FICHE_SUIVI : on ajoute une colonne TypeFiche, dont la valeur sera calculée par la fonction TypeFicheFonction définie au point (c).

Code SQL :

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

ALTER TABLE FICHE_SUIVI ADD TypeFiche AS dbo.TypeFicheFonction (FicheId) ;

Partant de là, pas de problème pour ajouter des fiches :

Code SQL :

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

1
2
3
4
5
INSERT INTO FICHE_SUIVI (FicheId, Description) VALUES (1, 'fiche 1') ;
INSERT INTO FICHE_SUIVI (FicheId, Description) VALUES (2, 'fiche 2') ;
 
INSERT INTO FICHE_MODIFICATION (FicheId, DevisProposition) VALUES (1, 'devis 1') ;
INSERT INTO FICHE_NON_MODIFICATION (FicheId, TypeFicheLibelle) VALUES (2, 'question') ;

Au résultat :

Code SQL :

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

 SELECT * FROM FICHE_SUIVI ;

=>

Code :

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

1
2
3
4
FicheId    Description    TypeFiche
-------    -----------    ---------
      1    fiche 1        modification
      2    fiche 2        question

Une 2e solution consiste à définir la colonne TypeFiche « en dur » dans l’en-tête de la table FICHE_SUIVI (je vous vois respirer à nouveau...), mais au lieu d’une fonction on se servira d’un trigger...

(a) Définition de la table FICHE_SUIVI, dans laquelle on fournit les valeurs possibles pour la colonne TypeFiche :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE FICHE_SUIVI
(
        FicheId            INT              NOT NULL
      , Description        VARCHAR(64)      NOT NULL 
      , TypeFiche          CHAR(1)          NOT NULL
    , CONSTRAINT FICHE_SUIVI_PK PRIMARY KEY (FicheId)
    , CONSTRAINT FICHE_SUIVI_CHK01 CHECK (TypeFiche IN ('m', 'a', 'q'))
) ;

(b) Tables FICHE_MODIFICATION et FICHE_NON_MODIFICATION :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE FICHE_MODIFICATION
(
        FicheId            INT              NOT NULL
      , DevisProposition   VARCHAR(64)      NOT NULL
    , CONSTRAINT FICHE_MODIFICATION_PK PRIMARY KEY (FicheId)  
    , CONSTRAINT FICHE_MODIFICATION_FICHE_FK FOREIGN KEY (FicheId)
          REFERENCES FICHE_SUIVI (FicheId)  
) ;

Code SQL :

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

1
2
3
4
5
6
7
 CREATE TABLE FICHE_NON_MODIFICATION
(
        FicheId            INT              NOT NULL
    , CONSTRAINT FICHE_NON_MODIFICATION_PK PRIMARY KEY (FicheId)  
    , CONSTRAINT FICHE_NON_MODIFICATION_FICHE_FK FOREIGN KEY (FicheId)
          REFERENCES FICHE_SUIVI (FicheId)  
) ;

(c) Mise en œuvre d’un trigger (MS SQL Server dans l’exemple, je rappelle, donc à réécrire si Oracle ou MySQL) vérifiant que lorsqu’on ajoute une ligne dans la table FICHE_MODIFICATION, la colonne TypeFiche (table FICHE_SUIVI) est bien égale à 'm'. Même principe pour la table FICHE_NON_MODIFICATION, c'est-à-dire définition d’un trigger idoine.

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 CREATE TRIGGER FICHE_MODIFICATION_TR ON FICHE_MODIFICATION INSTEAD OF INSERT 
AS
DECLARE @N INT
 
SET @N = (SELECT COUNT(*) 
          FROM FICHE_SUIVI AS x JOIN INSERTED AS y ON x.FicheId = y.FicheId 
          WHERE x.TypeFiche = 'm')
IF @N = 0 
    BEGIN
        RAISERROR ('Table des modifications : incompatibilité avec le type de fiche...',15,1)
    END
ELSE
    BEGIN
        INSERT INTO FICHE_MODIFICATION 
            SELECT * FROM INSERTED ;
    END ;

(d) Les ajouts :

Code SQL :

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

1
2
3
4
5
INSERT INTO FICHE_SUIVI (FicheId, Description, TypeFiche) VALUES (1, 'fiche 1', 'm') ;
INSERT INTO FICHE_SUIVI (FicheId, Description, TypeFiche) VALUES (2, 'fiche 2', 'q') ;
 
INSERT INTO FICHE_MODIFICATION (FicheId, DevisProposition) VALUES (1, 'devis 1') ;
INSERT INTO FICHE_NON_MODIFICATION (FicheId) VALUES (2) ;

A vous de choisir...

Je regarderai le MLD un peu plus tard...

[fsmrel]

Bonsoir Antonitzer,


AMC vous inflige deux warnings :




Le 1er n’a pas lieu d’être, puisque l’entité-type ANALYSE hérite par définition de celui de l’entité-type FICHE_SUIVI : ignorez-le

Le 2e attire seulement votre attention sur le fait que l’entité-type FICHE_MODIFICATION n’entretient pas de relation avec une quelconque autre entité-type que son surtype FICHE_SUIVI, donc il n'y a aucun problème. Vous aurez noté qu'AMC reste muet au sujet de FICHE_NON_MODIFICATION puisque pour cette entité-type il existe un lien avec TYPE_FICHE.


Concernant le MLD : laissez tomber, court-cirtuitez-le, passez directement à la génération du MPD à partir du MCD. Vous constaterez que du fait de l’injection qui est la conséquence des cardinalités 0,1/1,1 portées par l’association FIC_ANA, AMC aura créé un cycle entre les tables FICHE_SUIVI et ANALYSE :


Or la flèche du bas, qui va dans le sens FICHE_SUIVI -> ANALYSE n’a rien à faire ici, sinon pour ficher la patouille, elle doit disparaître. Rien de plus simple : vous sélectionnez cette flèche par un clic droit à la souris, et vous la supprimez. D’office, AMC supprime alors l’attribut ANA_ficheId dans l’en-tête de FICHE_SUIVI (attribut matérialisant le cycle), donc tout rentre dans l’ordre :




Procédez à la vérification du MPD, on regardera les avertissements qu’AMC aura générés...


Courage, on les aura !

[Antonitzer]

Bonjour fsmrel,

Désolé de ne répondre que maintenant mais je voulais d'abord bien comprendre les deux solutions que vous me proposiez pour gérer le TypeFicheId et je devais aussi commencer à travailler sur les différents processus de traitements et mes écrans pour avancer... Revenons donc à nos moutons...

Bien sûr que c’est inutile, du fait de la transitivité, via la fiche et le contact, on sait quel est le client qui est à la source de la FAQ. Si donc un client ne peut consulter que les FAQ dont il est à l’origine, pas de problème.

Ah ici justement ce n'est exactement le cas car un client peut consulter toutes ses FAQ (modification, anomalie, question) MAIS il peut aussi consulter les FAQ de type "anomalie" ou "question" des autres clients.


On sait déterminer le type de la fiche :

1) Si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_MODIFICATION n’est pas vide, la fiche est de type modification.

2) Si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_NON_MODIFICATION n’est pas vide, la fiche est de type question/anomalie.

3) Si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_MODIFICATION n’est pas vide et si le résultat de la jointure des tables FICHE_SUIVI et de FICHE_NON_MODIFICATION n’est pas vide non plus, alors il y a un bug, une m... dans la base, mais on sait éviter cela au moyen d’un trigger.

4) Si le résultat est vide, il est temps de mettre à jour la table incomplète (FICHE_MODIFICATION ou FICHE_NON_MODIFICATION)...

Maintenant on accroche sa ceinture. Pour parvenir à nos fins, il y a (au moins) deux solutions en SQL (J’utilise ici MS SQL Server). Une 3e solution consisterait à intercepter des mises à jour de vue au moyen de triggers, mas je ne voudrais pas trop vous traumatiser, et puis les triggers sur les vues ça ne fonctionne pas avec tous les SGBD (au moins MySQL)...

Eh bien avec certes beaucoup de mal et de temps j'ai compris les deux solutions que vous me proposez (oui comme vous l'avez bien suggéré j'ai beaucoup plus facilement compris la seconde que la première), je vais en tenir compte lors de l'implémentation...

Je vais devoir aussi créer une nouvelle table qui gère les appels téléphoniques maintenant. De plus, prendre en considération que lorsqu'un client appel, son appel peut donner lieu à la création d'une fiche que nous saisissons manuellement. Je reviendrai prochainement avec cette nouvelle table

Merci encore pour toute cette aide

[Antonitzer]

Concernant le MLD : laissez tomber, court-cirtuitez-le, passez directement à la génération du MPD à partir du MCD. Vous constaterez que du fait de l’injection qui est la conséquence des cardinalités 0,1/1,1 portées par l’association FIC_ANA, AMC aura créé un cycle entre les tables FICHE_SUIVI et ANALYSE :

En effet voici mon MPD (généré pour Oracle 11g) qui ne contient que cet avertissement, qui d'après mes recherches est un "conseil" de PowerAMC

Courage, on les aura !

Je ne lâche pas, je ne lâche pas...

[Antonitzer]

Voilà le nouveau MCD et MPD de ma BDD avec cette fois la prise en compte des appels téléphoniques. Lors de la vérification j'ai obtenu le même avertissement, normal.

LE MCD




et le MPD

[fsmrel]

Bonjour Antonitzer,


Une remarque concernant le type des données.

En l’état du MCD et du MPD, les attributs de type numérique donnent lieu au type NUMBER dans le cas d’Oracle. Si vous avez besoin un jour de savoir quel est l’encombrement en mémoire que cela représente, voyez la discussion ici.

Je ne suis pas spécialiste d’Oracle, mais pour des attributs tels que le nom des personnes, le type CLOB (Character Large Object) me paraît luxueux : VARCHAR (ou VARCHAR2) serait peut-être plus approprié (question à poser sur le forum Oracle).


Un retour sur les cycles :

J’ai précisé dans mon précédent message qu’il fallait supprimer (dans le MPD) le lien inutile (en fait nuisible) qui va dans le sens FICHE_SUIVI -> ANALYSE (FK_ANALYSE_FIC_ANA2_FICHE_SU chez vous).


Table FAQ :

Que vient faire l’attribut FaqProduitNom ? Si l’attribut FicheId de la table FAQ fait référence à la fiche qui a donné lieu à la FAQ, alors par transitivité on sait quel est le produit concerné : dans ces conditions, l’attribut FaqProduitNom de la table FAQ représente une redondance et doit disparaître.

Sauf pour motif à développer :

— Pour la même raison, l’attribut FaqTypeFiche de la table FAQ représente une redondance et doit disparaître.

— Pour la même raison, l’attribut FaqClientId de la table FAQ représente une redondance et doit disparaître.

— De la même façon, l’attribut FaqId de la table FICHE_SUIVI représente une redondance et doit disparaître.


Tables FICHE_MODIFICATION et FICHE_NON_MODIFICATION :

AMC a recopié tous les attributs de la table FICHE_SUIV : pour une redondance c’est une belle redondance ! (une belle sonnerie, comme chantait Boby Lapointe). Pour éviter cela, dans le MCD, cliquer sur la lunule de l’héritage de FICHE_SUIVI et choisir l’onglet « Génération » pour ne récupérer que le strict nécessaire :




On ne lâche rien ^^

[Antonitzer]

Je ne suis pas spécialiste d’Oracle, mais pour des attributs tels que le nom des personnes, le type CLOB (Character Large Object) me paraît luxueux : VARCHAR (ou VARCHAR2) serait peut-être plus approprié (question à poser sur le forum Oracle).

Je pense que AMC à choisi automatiquement ce type car je ne pouvais pas agir sur les longueurs au niveau du MCD. Je penserai à les modifier une fois que je générerai mon MPD final, sinon à chaque nouvelle génération je vais devoir le refaire...

— Pour la même raison, l’attribut FaqTypeFiche de la table FAQ représente une redondance et doit disparaître.

— Pour la même raison, l’attribut FaqClientId de la table FAQ représente une redondance et doit disparaître.

Dans ce cas je dois retirer aussi de ma table FAQ les attributs FaqTitre (qui prend la valeur de FicheTitre de FICHE_SUIVI) , FaqDescription ('' FicheDescription ''), FaqSolution ( '' Solution de FICHE_NON_MODIFICATION) pour les mêmes raisons non ?

D'ailleurs j'en viens a me demander si je ne devrais pas avoir les mêmes cardinalités entre l'association FAQ et FICHE_SUIVI que FAQ et ANALYSE ?

— De la même façon, l’attribut FaqId de la table FICHE_SUIVI représente une redondance et doit disparaître.

FaqId est présent dans FICHE_SUIVI à cause du lien FK_FICHE_SU_FIC_FAQ_FAQ, dois-je aussi supprimer ce lien ?

En attendant voici mes nouveaux MCD et MPD. De nouveaux attributs (ContactIdConnexion et ContactMotDePasse) ont fait leurs apparition dans CONTACT, ce sont les deux informations qui seront nécessaire à chaque contact pour s'identifier sur le site pour avoir accès à la FAQ ou au formulaire de fiche de suivie à remplir. Par précaution je les aient mis aussi en clé alternative.

Non non ca va je tiens !!

[Antonitzer]

Arrrrggggg rebonjour fmsrel,

Je crois avoir détécté un dysfonctionnement dans ma BDD, c'est au niveau des numéro de fiches et des clients, je m'explique :
Nous avions vu qu'un client peut avoir de 1 à plusieurs contact et que ces contacts peuvent emmètre plusieurs fiche_suivi portant chacune un numéro (FicheNo).

En vrai je veux que le numéro des fiches est unique par rapport au client, or ici il l'est par rapport au contact comme ça m'a l'air d'être le cas ici, j'illustre ce que je dis :

Actuellement on a :

ClientId	ContactId	FicheId	FicheNo
Cl1	Co13	Fi4	Fn6
Cl1	Co13	Fi5	Fn8
Cl2	Co22	Fi8	Fn6
Cl1	Co12	Fi9	Fn8

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

De la sorte il faudrait

ClientId	ContactId	FicheId	FicheNo
Cl1	Co13	Fi3	Fn6
Cl2	Co23	Fi6	Fn6
Cl1	Co13	Fi2	Fn5
Cl1	Co12	Fi9	Fn8

qui serait juste.

Avez-vous la solution pour corriger ce problème ?

Merci pour votre aide