Discussion :

[laurentSc]

Pour régler le problème, il faut aller au plus profond du paramétrage de Looping : dans la définition du nouveau type, il faut préciser : INT AUTO_INCREMENT UNSIGNED #INT UNSIGNED
De cette manière, Looping prendra ce qu'il y a derrière le # pour les FK.
Il est clair que ni vous ni personne ne pouvaient pas le deviner !

Bonjour,
comme vous le conseillez (ma boule de cristal ne l'avait pas trouvé ), j'ai mis INT AUTO_INCREMENT UNSIGNED #INT UNSIGNED dans les types pré-définis, mais les FK restent auto-incrémentées...

[laurentSc]

pour le point n°1, vous n'avez pas renseigné le script à associer à la contrainte (double clic sur la contrainte pour le vérifier)

Bien vu, car je ne l'ai pas fait, vu que Looping semble tout faire pour nous sauf que là, apparemment, non. Ne sachant pas le faire, j'ai regardé ce que vous aviez mis pour la contrainte que vous aviez mise. Je suis un peu désarçonné :

Code sql :

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

1
2
3
4
alter table TI_ticket
add constraint TICIF001
foreign key US_ident_RQ
references LI_license(US_ident)

- est-ce bien alter table TI_ticket alors que l'entité pivot est US_user ?
- La FK US_ident_RQ n'est pas référencée à LI_license(US_ident) mais à US_user(US_ident)
- j'aurais bien rajouté FOREIGN KEY(US_ident_own) REFERENCES US_user(US_ident).
- pas de mention de l'entité pivot (US_user) ?

Quand vous m'aurez répondu, j'espère être capable de créer les autres scripts.

pour le point n°2, vous avez renseigné un nom dans la case "nom logique" c'est ce nom qui est repris dans le DDL

Bien vu aussi, car au début, ne sachant pas à quoi correspondait ce nom logique, j'avais cru bon d'y mettre le même nom que celui de la classe d'entité et quand j'ai préfixé, j'ai oublié ce nom logique...

Pour que votre script de contrainte soit plus compréhensible, j'ai rajouté un libellé own qui va de l'association own à la classe US_user.

[escartefigue]

C'est curieux, car je viens de faire l'essai et ça fonctionne pour moi, aussi bien avec des asso devenant des tables que des FK héritées dans l'entité-type coté 1.

Par contre, j'ai trouvé un bug :

J'ai crée deux types
Pièce jointe 599543

J'attribue le premier type à l'identifiant de mon type d'entité, OK, j'ai bien le résultat attendu à la fois dans le type d'entité et dans l'association qui hérite de la colonne comme FK

Par contre, si je décide de remplacer dans le type d'entité le premier type par le deuxième, je n'y arrive pas, c'est systématiquement le premier qui revient
J'ai essayé de remplacer le type libre par un type counter et de refaire la manip inverse, rien n'y fait.
Deuxième tentative en inversant l'ordre des types libres prédéfinis :
Pièce jointe 599546

Et là, tout fonctionne

Etrange

[escartefigue]

Pour cette contrainte,

Bien vu, car je ne l'ai pas fait, vu que Looping semble tout faire pour nous sauf que là, apparemment, non. Ne sachant pas le faire, j'ai regardé ce que vous aviez mis pour la contrainte que vous aviez mise. Je suis un peu désarçonné :

Code sql :

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

1
2
3
4
alter table TI_ticket
add constraint TICIF001
foreign key US_ident_RQ
references LI_license(US_ident)

- est-ce bien alter table TI_ticket alors que l'entité pivot est US_user ?
- La FK US_ident_RQ n'est pas référencée à LI_license(US_ident) mais à US_user(US_ident)
- j'aurais bien rajouté FOREIGN KEY(US_ident_own) REFERENCES US_user(US_ident).
- pas de mention de l'entité pivot (US_user) ?

L'association (request) a une cardinalité maxi 1 coté [TICKET] l'identifiant du "requester" se trouve donc dans la table TICKET.
L'association (own) a également une cardinalité maxi 1 coté [LICENSE], l'identifiant du "owner" se trouve donc dans la table LICENSE.
Pour vérifier que le requester est possesseur d'une licence, il faut donc bien poser la contrainte sur la colonne TICKET.US_ident_RQ pour vérifier que sa valeur est trouvée dans la colonne LICENSE.US_ident

Même principe avec les autres contraintes de votre MCD

[laurentSc]

C'est curieux, car je viens de faire l'essai et ça fonctionne pour moi

J'ai fait l'essai sur mon PC perso (car pour mon appli, je travaille sur le PC pro), et là, ça fonctionne...Au pire, il faut le savoir et retirer cet AUTO_INCREMENT de toutes les FK...

Pour vérifier que le requester est possesseur d'une licence, il faut donc bien poser la contrainte sur la colonne TICKET.US_ident_RQ pour vérifier que sa valeur est trouvée dans la colonne LICENSE.US_ident

Ca serait pas plutôt la colonne LI_license.LI_ident ? Car au moins cette colonne existe...Non, après réflexion, ça n'a aucun sens mais ce que vous proposez n'est pas possible...

Si j'essaie sur une autre contrainte (celle tout en bas du MCD), ça donnerait :

Code sql :

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

1
2
3
4
alter table US_user
add constraint USCIF002
foreign key OZ_ident
references TI_ticket(TI_ident)

Est-ce correct ? Après réflexion, non plus et de surcroit, la contrainte me semble mal modélisée pour appliquer le commentaire ci-dessous. Comment feriez-vous ?

Commentaire pour cette contrainte : Seul un utilisateur demandeur d'un incident possède une organisation.

[escartefigue]

Ca serait pas plutôt la colonne LI_license.LI_ident ? Car au moins cette colonne existe...Non, après réflexion, ça n'a aucun sens mais ce que vous proposez n'est pas possible...

non non, si vous avez modélisé à l'identique de ma proposition, vous devez avoir le script suivant

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE LI_license(
   LI_ident INT AUTO_INCREMENT,
   US_ident INT NOT NULL,  <== ICI
   PRIMARY KEY(LI_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident)
);

On peut donc tout à faire faire référence à LI_license.US_ident, qui est la référence de l'utilisateur détenteur (own) de la licence.

pour appliquer le commentaire ci-dessous. Comment feriez-vous ?

Commentaire pour cette contrainte : Seul un utilisateur demandeur d'un incident possède une organisation.

Comme indiqué plus haut, ce n'est pas une contrainte. Vous ne connaissez l'organisation que si l'utilisateur a ouvert un ticket (c'est une conséquence du contenu de vos fichiers CSV). Mais rien n'interdit d'enregistrer l'organisation d'autres personnes en les saisissant par exemple. Ca serait même sans doute utile de connaître l'organisation de rattachement pour d'autres besoins que la gestion des tickets (la gestion des congés par exemple).

[laurentSc]

non non, si vous avez modélisé à l'identique de ma proposition, vous devez avoir le script suivant

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE LI_license(
   LI_ident INT AUTO_INCREMENT,
   US_ident INT NOT NULL,  <== ICI
   PRIMARY KEY(LI_ident),
   FOREIGN KEY(US_ident) REFERENCES US_user(US_ident)
);

On peut donc tout à faire faire référence à LI_license.US_ident, qui est la référence de l'utilisateur détenteur (own) de la licence.

En effet, du reste, si on en juge mon MCD (cf post #82) (j'ai rajouté le libellé own dans un lien) :

Code sql :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE LI_license(
   LI_ident INT AUTO_INCREMENT,
   id_platform INT UNSIGNED NOT NULL,
   id_application INT UNSIGNED NOT NULL,
   US_ident_own INT UNSIGNED NOT NULL,
   PRIMARY KEY(LI_ident),
   FOREIGN KEY(id_platform, id_application) REFERENCES AP_application(id_platform, id_application),
   FOREIGN KEY(US_ident_own) REFERENCES US_user(US_ident)
);

donc, on peut faire :

Code sql :

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

1
2
3
4
alter table TI_ticket
add constraint TICIF001
foreign key US_ident_RQ
references LI_license(US_ident_own)

Comme indiqué plus haut, ce n'est pas une contrainte. Vous ne connaissez l'organisation que si l'utilisateur a ouvert un ticket (c'est une conséquence du contenu de vos fichiers CSV).

OK, ce n'est pas une contrainte, mais comme je le précise ci-dessous, je souhaite respecter le cahier des charges. Comment modifieriez-vous le MCD pour cela ?

Mais rien n'interdit d'enregistrer l'organisation d'autres personnes en les saisissant par exemple. Ca serait même sans doute utile de connaître l'organisation de rattachement pour d'autres besoins que la gestion des tickets (la gestion des congés par exemple).

Sans doute, mais je voudrais me conformer au cahier des charges qui stipule seul un utilisateur qui est demandeur d'un incident peut posséder une licence.

[escartefigue]

Vu que les CSV ne contiennent pas l'information, il n'y a pas de risque, mais si on veut ceinture, bretelles, airbag et assurance vie, on créera un trigger pour ce besoin, ce n'est pas du ressort du MCD

Par ailleurs cette règle du cahier des charges est plus qu'étonnante. Quel rapport y a -t- il entre l'ouverture d'un ticket et la possession d'une licence ?
Cette règle impose d'ouvrir un incident avant d'avoir une licence, ça n'a aucun sens

À la limite, si le ticket concerne un produit sous licence, la règle devrait être à mon sens : seul l'utilisateur qui utilise le produit (et donc possède la licence) peut ouvrir un ticket qui concerne cette licence.
Cette règle là je la comprendrais

[laurentSc]

Oups, je me suis trompé en faisant un copier-coller ; au post #87, j'ai mis votre commentaire pour la contrainte que vous avez créée. Pour celle que je souhaite faire, c'est Seul un utilisateur demandeur d'un incident possède une organisation.

[laurentSc]

Bonsoir,

j'avoue être un peu perdu avec les contraintes. Pas sûr du tout de les avoir placer sur les bonnes associations et les bonnes classes d'entités.

Les règles que je voudrais modéliser sont :

1- un propriétaire de licence possède 0 ou 1 adresse email.

2- un propriétaire de licence travaille dans une et une seule compagnie.

3- un "requester" de ticket appartient à une organisation.

Pour la règle 1, j'ai fait la contrainte d'inclusion allant de l'association is_joinable_at vers own et portant sur la classe d'entité EM_mail.

Pour la règle 2, j'ai fait la contrainte d'inclusion allant de l'association work_at vers own et portant sur la classe d'entité US_user.

Pour la règle 3, j'ai fait la contrainte d'inclusion allant de l'association request vers include et portant sur la classe d'entité US_user.

Avant d'écrire les scripts de ces contraintes, je voudrais déjà être sûr de celles-ci. Déjà, pour la n°3, vous me disiez post #86 que ce n'était pas une contrainte. La chose sûre, c'est la règle mais comment la modéliser ? Aidez-moi à modéliser ces 3 règles, SVP.

Comme j'ai encore un peu modifié mon MCD, voici la dernière version :

[escartefigue]

Bonjour,

Bonsoir,

j'avoue être un peu perdu avec les contraintes. Pas sûr du tout de les avoir placer sur les bonnes associations et les bonnes classes d'entités.

Les règles que je voudrais modéliser sont :

1- un propriétaire de licence possède 0 ou 1 adresse email.

2- un propriétaire de licence travaille dans une et une seule compagnie.

3- un "requester" de ticket appartient à une organisation.

Pour la première règle, puisque l'adresse courriel est facultative (mini zéro) alors ce n'est pas une contrainte, la cardinalité 0,1 est suffisante pour satisfaire la règle de gestion.

Pour la deuxième règle, un propriétaire de licence est un user, or, le user est en lien 1,1 avec la compagnie, c'est suffisant pour vérifier cette règle

Pour la troisième règle, même combat.

Concernant la nomenclature des attributs, vous avez adopté en partie ma norme (préfixe associé à chaque type d'entité et asso, qu'on retrouve en préfixe des attributs), mais c'est inégal : seuls certains identifiants l'utilisent.
Par exemple US_ident et TI_ident, mais id_company et id_application...
Cette norme n'a d'intérêt que si elle est systématiquement utilisée, elle facilite les études d'impact et la compréhension des requêtes.
Cela étant, dans un contexte d'entreprise, le plus souvent, d'autres normes s'imposent.

[fsmrel]

Bonsoir,

je voudrais me conformer au cahier des charges qui stipule seul un utilisateur qui est demandeur d'un incident peut posséder une licence.

Selon votre règle, il faut d’abord être demandeur d’un incident pour avoir le droit de posséder une licence : c’est étrange et contradictoire avec la contrainte d’inclusion figurant dans votre MCD, selon laquelle une demande n’est possible qu’à la condition que l’utilisateur concerné possède une licence…

A mon sens, c'est votre MCD qui est conforme à la logique… Qu’en est-il ?

[escartefigue]

Bonsoir François

Selon votre règle, il faut d’abord être demandeur d’un incident pour avoir le droit de posséder une licence : c’est étrange et contradictoire avec la contrainte d’inclusion figurant dans votre MCD, selon laquelle une demande n’est possible qu’à la condition que l’utilisateur concerné possède une licence…

A mon sens, c'est votre MCD qui est conforme à la logique… Qu’en est-il ?

Nous sommes d'accord :

Cette règle impose d'ouvrir un incident avant d'avoir une licence, ça n'a aucun sens

À la limite, si le ticket concerne un produit sous licence, la règle devrait être à mon sens : seul l'utilisateur qui utilise le produit (et donc possède la licence) peut ouvrir un ticket qui concerne cette licence.
Cette règle là je la comprendrais

[laurentSc]

Désolé, Roland Garros m'a empêché de répondre. On verra demain matin...

[laurentSc]

Qu’en est-il ?

erreur de copier-coller, comme je dis au post #89. D'ailleurs, cette règle bizarre, c'est escartefigue qui l'a écrite dans le commentaire de la contrainte...

la contrainte d’inclusion figurant dans votre MCD, selon laquelle une demande n’est possible qu’à la condition que l’utilisateur concerné possède une licence…

C'est exact, mais débutant pour les MCD, j'aimerais comprendre la logique qui vous conduit à cette déduction.

Vu ce qu'écrit escartefigue au post #91, y a pas besoin de contraintes supplémentaires, donc voici mon MCD corrigé avec le bon nommage des attributs :

Il me reste à déterminer les requêtes SQL SELECT qui répondent à :

• liste des propriétaires de licence
• compagnie du propriétaire de licence XYZ
• organisation du requester de ticket TARTEMPION
• etc

y a-t-il autre chose à faire entre la mise au point du MCD et la génération des requêtes SQL ?

[fsmrel]

Bonsoir,

Nous sommes d'accord

Capitaine, je viens de lire en diagonale cette longue discussion à laquelle j’avais commencé à participer, avant de passer à autre chose. Effectivement nous sommes d’accord sur la règle selon laquelle pour faire une demande il faut avoir une licence, ce que tu avais déjà écrit. Cette relecture (ce pensum) montre incidemment que tu as une patience d’ange…

Une petite remarque au passage concernant les contraintes d’inclusion : depuis la naissance de Merise une CIF est une CIF et c’est tout, il n’y a pas de « CIF de type inclusion », seulement des contraintes d’inclusion (relis le bouquin de référence de D. Nanci et B. Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001)).

Bon courage !

[laurentSc]

tu as une patience d’ange…

Certes et j'apprécie beaucoup l'aide de escartefigue car il y a quelques semaines, je n'y connaissais rien aux MCDs et grâce à son aide (et celle d'autres aussi), j'apprend beaucoup.

la contrainte d’inclusion figurant dans votre MCD, selon laquelle une demande n’est possible qu’à la condition que l’utilisateur concerné possède une licence…

mais débutant pour les MCD, j'aimerais comprendre la logique qui vous conduit à cette déduction.

Pour apprendre encore davantage, pourriez-vous répondre ?

[fsmrel]

Bonsoir,


Belle demi-finale hier soir à Roland Garros !


Laurent, dans un MCD on modélise la finalité, le QUOI, mais pas le COMMENT. En l’occurrence, si j’ai bien compris, il est possible qu’on ne connaisse les utilisateurs qu’une fois connus les tickets, ou a tout le moins quels sont les utilisateurs possédant une licence, cf. le post #62 :

« Je traite 2 sortes de fichiers CSV : les CSV "licenses" et les CSV "tickets". Les license_owner proviennent des CSV "licenses" alors que les customer et les submitter proviennent des CSV "tickets" ».

Autrement dit, sachez que quand on modélise, on met de côté ce genre de considération bassement matérielle, le COMMENT ne doit avoir aucune incidence sur le MCD, c’est-à-dire provoquer la remise en cause de la finalité. Restons sur la dunette plutôt qu’à trier des CSV dans la soute.

débutant pour les MCD, j'aimerais comprendre la logique qui vous conduit à cette déduction.

C’est la logique du bon sens… C’est celle-là même qui par exemple me conduit à dire qu’on doit prendre au plus tôt une assurance pour sa voiture. Je n’arrive pas à croire qu’un assureur vienne me dire : « Vous n’avez pas d’assurance mais pas de problème, vous pouvez très bien venir vous assurer chez nous après avoir eu un accident, on vous indemnisera… ». Ainsi, à son tour, la contrainte d’inclusion ayant pour portée (source) TICKET et pour cible LICENCE est manifestement correcte.

Dans l’image qui suit (extraite du rapport AFCET « Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information » (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris. »), c’est encore le bon sens qui prévaut et conduit à dire qu’un enseignant ne peut enseigner une matière que s’il en a la capacité :

Plus ergonomique, dans le style de Looping :

Seul un utilisateur demandeur d'un incident possède une organisation

Qu’est-ce qu’une organisation ?


Je note que dans votre MCD, la patte d’association connectant l’entité-type EM_mail et l’association is_joinable_at est porteuse d’une cardinalité 0,1 : Quel intérêt, quelle finalité d’avoir des courriels orphelins ?

[laurentSc]

Belle demi-finale hier soir à Roland Garros !

Certes, un vrai régal (la finale sera belle aussi), mais aujourd'hui, même si moins beau tennis, cocorico car 3 français ont remporté le tournoi (homme junior (un français de 17 ans), et double senior hommes (39 ans et 30 ans)).

dans un MCD on modélise la finalité, le QUOI, mais pas le COMMENT.

Bien noté.

En l’occurrence, si j’ai bien compris, il est possible qu’on ne connaisse les utilisateurs qu’une fois connus les tickets, ou a tout le moins quels sont les utilisateurs possédant une licence, cf. le post #62

J'ai pas compris ce que vous avez compris...

Ainsi, à son tour, la contrainte d’inclusion ayant pour portée (source) TICKET et pour cible LICENCE est manifestement correcte.

Faut espérer, comme c'est escartefigue qui l'a proposée . Mais ça m'aide à comprendre ce qu'est une contrainte.

Plus ergonomique, dans le style de Looping :

Tout à fait, plus ergonomique et on est habitué à ce formalisme...

Qu’est-ce qu’une organisation ?

Moi, ça me parlait car je suis habitué, mais je ne parviens à la définir...Je mène l'enquête et quand j'aurai la réponse, je la communiquerai.

Je note que dans votre MCD, la patte d’association connectant l’entité-type EM_mail et l’association is_joinable_at est porteuse d’une cardinalité 0,1 : Quel intérêt, quelle finalité d’avoir des courriels orphelins ?

C'est le résultat d'une erreur de modélisation ; je l'ai remplacée par 1,1.

Post #91 :

Pour la deuxième règle, un propriétaire de licence est un user, or, le user est en lien 1,1 avec la compagnie, c'est suffisant pour vérifier cette règle

Les submitters ou les requesters de ticket sont aussi des users, mais pour ces users-là, on ne connait pas la company. La solution, pour la classe US_user est-elle dans son SQL de création de mettre CO_ident INT UNSIGNED plutôt que CO_ident INT UNSIGNED NOT NULL ?

[escartefigue]

Bonjour Laurent,

Je ne réponds que très partiellement faute de temps, mais sur le dernier point

Les submitters ou les requesters de ticket sont aussi des users, mais pour ces users-là, on ne connait pas la company. La solution, pour la classe US_user est-elle dans son SQL de création de mettre CO_ident INT UNSIGNED plutôt que CO_ident INT UNSIGNED NOT NULL ?

Au niveau SQL oui, mais c'est bel est bien le MCD, grâce aux cardinalités des associations qui produit ce résultat. Il n'est pas nécessaire d'intervenir dans le script SQL pour y parvenir.
Et comme les cardinalités sont le reflet exact des règles de gestion, c'est tout bon