Discussion :

[laurentSc]

Bonsoir,

ça fait 50 ans que je suis sur ce MCD et j'aimerais bien finir avec une version sur laquelle tout le monde sera d'accord. Au vu des dernières remarques, j'ai créé une dernière version avec une seule classe d'entité US_user. Par contre, comme il existe 3 types de users, on a des clés étrangères nullables. Merci de me dire ce que vous en pensez et qu'on en finisse...

[fsmrel]

Bonsoir Laurent,

j'aimerais bien finir avec une version sur laquelle tout le monde sera d'accord.

Le temps ne fait rien à l’affaire…

Votre dernier MCD n’aucun effet quant à ce que j’ai écrit dans le post #112. Je reprends … Considérons le cas du ticket 314116 : celui-ci fait nécessairement référence à une licence (conséquence de la cardinalité 1,1 portée par la patte d’association connectant TI_ticket et CONCERNS), or cette licence fait nécessairement référence à un utilisateur (conséquence de la cardinalité 1,1 portée par la patte connectant LI_license et OWN), et cet utilisateur appartient à US_user. Supposons qu’il s’agisse de l’utilisateur Raoul. Ce ticket 314116 fait par ailleurs référence à un utilisateur appartenant lui aussi à US_user (conséquence de la cardinalité 1,1 portée par la patte connectant TI_ticket et REQUEST) et qui peut être Paul. Ainsi, Raoul, et Paul sont tous les deux concernés par le même ticket, et selon le MCD, rien ne s’ oppose.

Puisque c’est soit Raoul soit Paul à qui appartient le ticket 314116, mais pas les deux à la fois, la cardinalité 1,1 portée par la patte d’association connectant TI_ticket et CONCERNS ainsi que la cardinalité 1,1 portée par la patte connectant TI_ticket et REQUEST sont à remplacer par 0,1. En plus il y a une contrainte d’exclusion à prévoir. Supposons que REQUEST concerne exclusivement les utilisateurs n’ayant pas de licence, la portée de la contrainte d’exclusion est alors composée des associations REQUEST et OWN (avec US_user comme pivot). Au stade SQL, cela fera l’objet d’un trigger.

[laurentSc]

Votre dernier MCD n’aucun effet quant à ce que j’ai écrit dans le post #112.

Je crois avoir eu raison pour générer le MCD du post #121 de créer une 2e version et de conserver celui du post #113...

Je constate aussi qu'à une heure avancée de la nuit, vous avez pu faire une remarque pertinente, ce dont je serais incapable...

J'ai remis la contrainte d'inclusion entre request et own (un "requester" de ticket est nécessairement propriétaire de licence sur l'application concernée par le ticket). Ce MCD convient-il ?

[fsmrel]

J'ai remis la contrainte d'inclusion entre request et own (un "requester" de ticket est nécessairement propriétaire de licence sur l'application concernée par le ticket).

Autrement dit, en relation avec les exemples que j’ai utilisés précédemment, Paul n’étant propriétaire d’aucune licence, il n’a pas le droit cette fois-ci de faire la moindre demande de ticket (association REQUEST). Seul Raoul peut le faire parce qu’il a une licence. C’est bien ça ?

Tournez manège…

[laurentSc]

Bonne question...J'avoue avoir toujours fait cette hypothèse alors que c'est pas sûr. Je viens donc d'en demander confirmation. Je vous dirai quand j'en saurai plus.

[laurentSc]

Merci pour la question car dans ma tête, la réponse était oui alors que c'est non : un "requester" de ticket ne possède pas forcément de licence. J'ai donc supprimé la contrainte et le MCD devient :



Cela va-t-il comme ça ?

[fsmrel]

Ça va mieux comme ça, la contrainte a dégagé, voilà qui est une bonne chose.

Il n’en demeure pas moins que Raoul et Paul peuvent continuer à être propriétaires en même temps du ticket 31411. Pour empêcher cela, avec Looping, prévoir une contrainte d’exclusion entre CONCERNS et REQUEST. Au niveau SQL, plutôt qu’en passer par un trigger, se simplifier la vie et utiliser une contrainte CHECK pour s’assurer de l’exclusion :

Au nommage près des choses :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE TICKET(
   ticketId INT,
   ticketNum INT NOT NULL,
   licenceId INT,
   requestUserId INT,
   CONSTRAINT TICKET_PK PRIMARY KEY(ticketId),
   CONSTRAINT TICKET_AK UNIQUE(ticketNum)
    ,  CONSTRAINT REQUEST_TICKET_USER_FK FOREIGN KEY(requestUserId) REFERENCES UST_user_ticket(userId)
    ,  CONSTRAINT TICKET_LICENCE_FK FOREIGN KEY(licenceId) REFERENCES LICENCE(licenceId)
     , CONSTRAINT THE_EXCLUSION CHECK (licenceid is not null and requestUserId is null or licenceid is null and requestUserId is not null)  
);

La contrainte peut être prise en compte avec Looping (outil Règle avec ADD CONSTRAINT THE_EXCLUSION).

[laurentSc]

J'étais en train de modifier mon MCD pour ajouter cette contrainte CHECK mais j'ai un doute car la contrainte d'exclusion, ça serait pas plutôt entre les associations request et own ? De plus, vous excluez LI_ident et US_ident_RQ. Mais ces 2 identifiants n'ont aucun rapport vu que le premier concerne la classe LI_license et le second l'utilisateur "requester" du ticket. Je suis perdu. Vous pouvez m'éclairer ?

[fsmrel]

j'ai un doute car la contrainte d'exclusion, ça serait pas plutôt entre les associations requestet own ?

On va dire que c’est vrai dans le cas du MCD dans lequel vous avez fondu dans US_user les sous-types USL_user_license et UST_user_ticket (cf. le post #121), et comme je l’ai fait dans le post #122.

Mais avec les sous-types USL_user_license et UST_user_ticket, si on se réfère à la définition fournie par le groupe 135 de l’Afcet (qui définissait les normes des MCD avant que l’Afcet ne disparaisse), ça commence à devenir problématique.

Voici la définition officielle :

Si les associations (relations) concernées sont REQUEST et OWN, et constituent donc la portée de la contrainte, elles doivent avoir un pivot en commun, mais quel serait-il ? Je vous laisse répondre à cette question. Si on décide que la portée est constituée de la paire REQUEST, CONCERNS, quel en est le pivot ? Y en n’a pas… On sent que l’entité-type LI_license a un rôle à jouer, mais au vu de la définition de l’afcet, on ne sait pas trop comment accommoder cette cuisine. Quoi qu’il en soit, si vous préférez représenter une exclusion entre REQUEST et OWN, non pas pour des raisons techniques mais sémantiques et documentaires, faites-le. En tout cas cela n’a aucune incidence sur le MLD et le code SQL.

De plus, vous excluez LI_ident et US_ident_RQ. Mais ces 2 identifiants n'ont aucun rapport vu que le premier concerne la classe LI_license et le second l'utilisateur "requester" du ticket. Je suis perdu. Vous pouvez m'éclairer ?

Comme on en arrive au code SQL, les choses deviennent sérieuses

A ce stade, ne raisonnez plus en termes d’identifiants. Observez que dans le CREATE TABLE que j’ai proposé (incomplet, mais suffisant pour notre problème), vous avez les deux colonnes licenceId et requestUserId qui certes n’ont rien en commun, mais observez bien ceci :

Si la colonne licenceId de la table TICKET contient une valeur (par exemple 1), c’est que la colonne licenceId de la table LICENCE contient nécessairement cette valeur (en effet {licenceId} est clé primaire de la table LICENCE tandis que dans la table TICKET {licenceId} est clé étrangère référençant LICENCE). Mais puisque dans la table TICKET la colonne licenceId contient une valeur, la colonne requestUserId y est obligatoirement marquée nulle, sinon le fameux ticket 314116 ferait obligatoirement référence à la fois à une licence (appartenant on va dire à Raoul) et à un utilisateur possiblement sans licence (on va dire Paul) : la règle de gestion voulant que Raoul et Paul ne puissent pas être propriétaires tous les deux du ticket pourrait ainsi être violée !



De la même façon, si la colonne requestUserId de la table TICKET contient une valeur (par exemple 1), c’est que la colonne userId de la table UST_user_ticket contient nécessairement cette valeur (en effet {userId} est clé primaire de la table UST_user_ticket tandis que dans la table TICKET {requestUserId} est clé étrangère référençant UST_user_ticket). Mais puisque dans la table TICKET la colonne requestUserId contient une valeur, la colonne licenceId y est obligatoirement marquée nulle, sinon le fameux ticket 314116 ferait là aussi obligatoirement référence à la fois à une licence (appartenant on va dire là aussi à Raoul) et à un utilisateur possiblement sans licence (Paul, une fois de plus) : la règle de gestion voulant que Raoul et Paul ne puissent pas être propriétaires tous les deux du ticket pourrait à nouveau être violée !


Moralité, si dans la table TICKET une des deux colonnes licenceId ou requestUserId contient une valeur, l’autre doit nécessairement être marquée nulle pour que la règle de gestion soit respectée. CQFD.

N.B. Dans la contrainte que j’ai proposée, les deux colonnes ne peuvent pas être toutes deux marquées nulles en même temps. Laurent, à vous de préciser si la règle de gestion confirme ou infirme cette situation.

[laurentSc]

Merci, François, pour vos nouvelles réponses (dans les 2 discussions).

Les lire m'a de nouveau fait réfléchir et à mon avis, le MCD ne respecte pas les règles de gestion et en particulier, l'association concerns reliée aux classes d'entités LI_license et TI_ticket n'a aucune raison d'être : un ticket concerne une application (nommée product_name dans PR_product) et pas une licence.

Du coup, le MCD suivant me paraît plus fidèle à la réalité et plus de contrainte...Désolé de vous avoir fait longtemps réfléchir sur une fausse piste, révélatrice de mon manque d'expérience.



Qu'en pensez-vous ?

[fsmrel]

Bonjour Laurent,

L'association concerns reliée aux classes d'entités LI_license et TI_ticket n'a aucune raison d'être : un ticket concerne une application (nommée product_name dans PR_product) et pas une licence.

Soit. Néanmoins un ticket ne peut pas être orphelin de son demandeur (sauf à croire à la génération spontanée…), en conséquence la cardinalité portée par la patte d’association connectant l’entité-type TI_ticket et l’association REQUEST doit redevenir 1,1 (on fait de l'accordéon)


Un de ces quatre matins, il faudra que vous fournissiez la liste a peu près stabilisée des règles de gestion. Je ne parle pas ici de celles qui s’appliquent attributs des entités-types (rubriques des classes d’entités), mais plutôt aux associations, lesquelles font parfois l’objet de longs débats…

Exemple de règles :

RG001 - Une plate-forme possède de 0 à N applications.
RG002 - Une application appartient à au moins et au plus une plate-forme.
RG003 - Une application est concernée par 0 à N licences.
RG004 - Une licence concerne une et une seule application.

etc.

Chaque association doit faire l’objet d’une règle de gestion.


Certaines règles de gestion attirent l’attention et méritent des explications. Ainsi en va-t-il évidemment de l’association matching_license_ticket : à vous lire, un produit peut être autonome, sans lien avec quelque application que ce soit . Est-ce parce qu’un produit peut être purement « local », autonome, vivre tranquillement sa vie, en dehors de toute plate-forme ? En passant, pourquoi l’injection du mot « license » dans le nom de l’association ? Qu’est-ce que cela cache ?

[laurentSc]

Un de ces quatre matins, il faudra que vous fournissiez la liste a peu près stabilisée des règles de gestion. Je ne parle pas ici de celles qui s’appliquent attributs des entités-types (rubriques des classes d’entités), mais plutôt aux associations, lesquelles font parfois l’objet de longs débats…

Il faudra que j'y songe. Elles ne sont pas formalisées et je les ai dans la tête après moult discussions avec le demandeur...

à vous lire, un produit peut être autonome, sans lien avec quelque application que ce soit

J'ai dit ça où ? Je trouve pas...

Est-ce parce qu’un produit peut être purement « local », autonome, vivre tranquillement sa vie, en dehors de toute plate-forme ?

Non, mais si la notion de plate-forme est utilisée dans les fichiers CSV "licences", elle n'existe pas dans les fichiers CSV "ticket". C'est pour ça que les produits semblent autonomes.

En passant, pourquoi l’injection du mot « license » dans le nom de l’association ? Qu’est-ce que cela cache ?

Le nom de l'association est matching_license_ticket. En fait, dans les fichiers CSV license, on a la colonne applicationname et dans les fichiers CSV ticket la colonne productname. Il s'agit en fait de la même chose avec un orthographe différent, d'où la table de correspondance.

EDIT : j'ai modifié la cardinalité qui repasse à 1,1

[escartefigue]

J'ai dit ça où ? Je trouve pas...

C'est la conséquence directe de la cardinalité minimale zéro du produit vers l'application
Cette cardinalité sous-entend la règle de gestion suivante (notez l'utilisation d'un identifiant de règle, j'ai choisi arbitrairement R025 ici, c'est bien pratique pour échanger sur celles-ci)
R025 : un produit peut correspondre à zéro ou une application

Non, mais si la notion de plate-forme est utilisée dans les fichiers CSV "licences", elle n'existe pas dans les fichiers CSV "ticket". C'est pour ça que les produits semblent autonomes.

Ils ne le semblent pas seulement, il le sont de fait : ce MCD en l'état produira un script autorisant un produit à n'avoir aucune plate-forme
Soit c'est acceptable, même de façon temporaire, et tout va bien, soit ça ne l'est pas et il faut produire un autre modèle.
À ce stade, on se fiche que l'information soit issue d'un fichier CSV, d'une saisie ou de tout autre source, ce qui compte c'est d'établir le caractère obligatoire ou pas du lien entre un produit et une plate-forme à un instant "t".
Quand et comment l'information arrive est du ressort du traitement.

Une éventualité : les produits associés à une application sont d'un certain type, les produits autonomes sont d'un autre type. En ce cas, on peut rendre l'association obligatoire seulement pour les premiers et facultative ou absente pour les autres.

[laurentSc]

Bonsoir,

en fait, même s'il est probable que les produits appartiennent à une plateforme (chez nous, une plateforme est un ensemble de plusieurs applications (ou produits) ), on ne dispose pas de cette information, d'où l'hypothèse que je fait avec le MCD : un produit n'appartient pas à une plateforme. Ai-je pris une bonne décision ?

[escartefigue]

Dans ma compréhension, une plate-forme est une instance d'un environnement (test, recette, prod...) hébergeant des éléments logiciels et un jeu de données

Par exemple :

• PF1 est la plate forme de prod, hébergeant les applications A1, A2 et A3
• PF2 est la plate-forme de tests unitaire 1, hébergeant les applications A1, A2, A3 et A4 et chargée avec un échantillon de la prod en date du 25 avril 2021
• PF3 est la plate-forme de recette 1, elle héberge les applications A2 et A3, elle est chargée avec un échantillon de la prod en date du 2 mai 2021
• PF4 est la plate-forme de recette 2, elle héberge les applications A2 et A3, elle est chargée avec une recopie de la recette 1 en date du 30 mai 2021
• PF5 est la plate-forme de pré-prod, elle héberge les applications A1, A2 et A3, elle est chargée avec une copie intégrale de la prod en date du 20 juin 2021
• etc.

C'est bien le cas ?
Dans l'affirmative, une appli peut être déployée sur zéro à plusieurs plates-formes

Ensuite, une application possède des versions, n'avez-vous pas besoin de connaître les versions installées sur les différentes plates-formes, voire éventuellement l'historique du déploiement de ces versions ?

Enfin, vu que produit et applications sont synonymes (on connait le nom de l'appli, du produit, ou les deux, on peut simplifier le modèle en ne créant qu'un seul type d'entité.
Soit on a deux attributs nom_produit et nom_appli tous deux "nullables" (et on vérifiera par une contrainte check que au plus l'un des deux est "null")
Soit on enregistre des lignes application de type "P" (produit) et de type "A" (application) et on établit une association reflexive de l'association avec elle-même en vérifiant que le lien ne peut concerner que des lignes de types différents.

MCD correspondant à la deuxième solution :

Pièce jointe 600403


Exemple de contenu :

AP_ident	AP_nom	AP_type	AP_ident_lie
100	Appli1	A	null
132	Prod4	P	null
171	Prod2	P	205
205	Appli6	A	171

[laurentSc]

Dans ma compréhension, une plate-forme est une instance d'un environnement (test, recette, prod...) hébergeant des éléments logiciels et un jeu de données

Par exemple :

• PF1 est la plate forme de prod, hébergeant les applications A1, A2 et A3
• PF2 est la plate-forme de tests unitaire 1, hébergeant les applications A1, A2, A3 et A4 et chargée avec un échantillon de la prod en date du 25 avril 2021
• PF3 est la plate-forme de recette 1, elle héberge les applications A2 et A3, elle est chargée avec un échantillon de la prod en date du 2 mai 2021
• PF4 est la plate-forme de recette 2, elle héberge les applications A2 et A3, elle est chargée avec une recopie de la recette 1 en date du 30 mai 2021
• PF5 est la plate-forme de pré-prod, elle héberge les applications A1, A2 et A3, elle est chargée avec une copie intégrale de la prod en date du 20 juin 2021
• etc.

C'est bien le cas ?

A mon sens, une application appartient à une et une seule plate-forme. Mais comme pas sûr de moi, j'ai posé la question...

Si ma compréhension est la bonne, votre MCD devient :


J'ai pas mis AP_code et PL_code car j'ai pas compris ce que c'est.

Cardinalité 0,1 pour la patte reliant AP_application à belongs_to_p car si on a affaire à un produit, il n'appartient pas à une plate-forme (c'est l'hypothèse que je fais, comme on a aucune information dans ce cas)

J'ai adapté votre tableau exemple de contenu :

AP_ident	AP_name	AP_type	AP_ident_bind
100	Appli1	A	null
132	Prod4	P	null
171	Prod2	P	205
205	Appli6	A	171

EDIT : je viens d'avoir l'explication pour les plate-formes :

Ici, un « product » dans les tickets est totalement équivalent aux applications côté licences. La table de correspondance n’est là que pour palier aux différences d’appellation (ex: pour la même application j’ai déjà vu AUTOCAD, AutoCAD, Autodesk AutoCAD, AutoCAD 2D, etc…).

Et il y a une utilisation différente du terme plateforme de celle que tu connais : celle utilisée dans ARM (source pour le csv des licences) est un regroupement d’applications. Par exemple Symphony, PDM, Tempo, Tango et feu Genesis sont regroupées sous une même plateforme car elles sont gérées par les mêmes équipes et ont à la fois une fonction comme un fonctionnement similaires 😉

C’est donc un attribut d’une application au sens qu’une application n’appartient qu’à une et une seule plateforme et une plateforme regroupe une à plusieurs applications.

Ca valide donc mon MCD, non ?

[fsmrel]

J'ai dit ça où ? Je trouve pas.

Vous l’avez dit sous forme graphique plutôt que textuelle…

si la notion de plate-forme est utilisée dans les fichiers CSV "licences", elle n'existe pas dans les fichiers CSV "ticket". C'est pour ça que les produits semblent autonomes.

Je rappelle ce que j’ai écrit dans le post #98 :

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

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.

Mais voilà que vous revenez à vos vieux démons, les fichiers CSV, qui n’ont rien à voir avec le QUOI et sèment la pollution dans votre MCD.

Quand vous dites que « C'est pour ça que les produits semblent autonomes », il y a de quoi douter de leur modélisation.

Le nom de l'association est matching_license_ticket. En fait, dans les fichiers CSV license, on a la colonne applicationname et dans les fichiers CSV ticket la colonne productname. Il s'agit en fait de la même chose avec un orthographe différent, d'où la table de correspondance.

Encore l’influence de vos vieux démons… On ne peut que douter de ce que vous écrivez. Formulez clairement les règles de gestion en cause, en ne tenant compte que du QUOI alors que manifestement le COMMENT, hélas ! est votre guide…

j'ai modifié la cardinalité qui repasse à 1,1

Quelle association ? Quelle patte ?

[escartefigue]

Le MCD avec association reflexive que j'avais proposé précédemment n'est pas la solution la plus simple.
Dans la plupart des cas, il me semble qu'une seule entité-type avec deux attributs nom_appli et nom_produit devrait suffire (en vérifiant comme dit plus haut que seul l'un des deux au plus est "null").

J'ai mis des attributs code pour les produits et les applications, car, le plus souvent, on préfère manipuler des codes (courts) que des libellés (possiblement longs et donc fastidieux à saisir) : l'application demande de saisir un code ou de le choisir dans une liste et elle récupère automatiquement le libellé correspondant.
Exemple typique, les tables de typologie telles que les pays, les devises, les unités de mesure.

[laurentSc]

Merci fsmrel et escartefigue pour vos messages. Je les vois très tard et j'ai pas les idées claires à cette heure-là ! On verra demain matin.

[fsmrel]

Merci fsmrel et escartefigue pour vos messages. Je les vois très tard et j'ai pas les idées claires à cette heure-là ! On verra demain matin.

Bonne nuit, Laurent ! Et la nuit porte conseil...