Discussion :

[fsmrel]

Je vois comme intérêt la réduction du nombre d'associations vers la classe application. Dans votre exemple il y a bien OWN mais aussi LIC_APP, n'est-ce pas ?

Pour reprendre la figure (a) : il y a deux associations, LIC_APP et LIC_ERR. Dans la figure (d) elles sont fondues en une seule association, LIC_APP qui littéralement pourrait s’appeler LIC_APP_OU_ERR…

Dans mon modèle, j'ai dupliqué ces 2 associations. Pour les licences, pour OWN, il y avait own et own_error, et pour LIC_APP, concern_l et concern_le(et idem pour les tickets).

Ces associations y sont légitimes et légales.

Par contre, je ne pense pas factoriser des attributs car dans le cas d'erreur (ici license_error), il ne faut rien écrire.

Je ne sais ce que vous entendez par « il ne faut rien écrire ». Quoi qu’il en soit, si les attributs activate_date et activate_date sont concernés, alors ils ne doivent pas être présents dans LICENSE_ERROR.

c'est loin d'être fini

Courage ! Nif-Nif construisit plutôt vite

Le sage et prévoyant Naf-Naf construisit certes moins vite, mais en beaucoup plus solide…

Heureusement pour Naf-Naf et ses frères, car gare au vilain méchant qui rôde…

 
 

[laurentSc]

Merci pour l'humour

Ces associations y sont légitimes et légales.

Qu'est-ce que vous voulez dire ?

Je ne sais ce que vous entendez par « il ne faut rien écrire ». Quoi qu’il en soit, si les attributs activate_date et activate_date sont concernés, alors ils ne doivent pas être présents dans LICENSE_ERROR.

En fait, c'est dans LICENSE_VALIDEE qu'il ne faut pas faire d'INSERT ou de UPDATE. Mais mon code est fait tel que quelle que soit la situation, je fais un INSERT ou UPDATE. Par contre, si erreur détectée, je le fais dans LICENSE_ERROR au lieu de LICENSE_VALIDEE. C'est pourquoi j'ai choisi que ces 2 tables ont une structure identique. Par contre, on ne fait jamais de SELECT sur LICENSE_ERROR, donc peu importe son contenu...

[escartefigue]

Bonjour Laurent, bonjour François

Je vois que les règles de gestion on bien évolué depuis ma dernière réponse, les fondations semblent désormais stables et c'est bien l'essentiel

@Laurent : je comprends la réticence à faire évoluer le code existant, mais c'est bien la meilleure des choses à faire dans la mesure du possible. Avec un modèle de données fiabilisé, les évolutions futures seront plus simples, plus fiables et plus performantes au bénéfice des utilisateurs et des équipes de développement

[fsmrel]

Bonjour,

Qu'est-ce que vous voulez dire ?

Je dis que l’existence dans la figure (a)des deux associations OWN et OWN_ERROR, et leur mise en oeuvre est tout à fait possible par rapport à la modélisation conceptuelle traditionnelle selon Merise (à laquelle Paprick adhère), en conséquence de quoi ces deux associations sont donc légales. Quand je dis que ces associations sont légitimes, cela veut dire qu’il y a d’autres façons de modéliser, comme dans le cas des autres figures, sachant que la mise en oeuvre de la factorisation est plus intéressante, plus puissante (cf. figure (d)), mais que rien ne vous empêche de choisir la modélisation décrite dans la figure (a).

En fait, c'est dans LICENSE_VALIDEE qu'il ne faut pas faire d'INSERT ou de UPDATE. Mais mon code est fait tel que quelle que soit la situation, je fais un INSERT ou UPDATE. Par contre, si erreur détectée, je le fais dans LICENSE_ERROR au lieu de LICENSE_VALIDEE. C'est pourquoi j'ai choisi que ces 2 tables ont une structure identique. Par contre, on ne fait jamais de SELECT sur LICENSE_ERROR, donc peu importe son contenu...

Qu’est-ce que LICENSE_VALIDEE ? On ne voit pas cette classe dans votre MCD qui comporte plutôt la classe LICENSE. En tout cas, quand vous écrivez que « c'est dans LICENSE_VALIDEE qu'il ne faut pas faire d'INSERT ou d’UPDATE », on est en droit d’interpréter cette affirmation comme quoi LICENSE_VALIDEE sera toujours vide, donc qu’elle n’a a priori aucun intérêt, auquel cas son existence est à remettre en cause, elle devrait disparaître. Sinon, merci de reformuler, d’expliquer dans quelles circonstances la table SQL correspondante est mise à jour et exploitée : quand pas d’erreur détectée ?

Quand vous écrivez : « Par contre, on ne fait jamais de SELECT sur LICENSE_ERROR, donc peu importe son contenu… », cela veut dire que cette classe est inutile, elle doit donc disparaître.

[escartefigue]

Sauf contrainte réglementaire (à préciser pour notre compréhension), je suis d'accord avec ce qui suit

Quand vous écrivez : « Par contre, on ne fait jamais de SELECT sur LICENSE_ERROR, donc peu importe son contenu… », cela veut dire que cette classe est inutile, elle doit donc disparaître.

Je pensais le MCD stabilisé (cf. ma réponse précédente) mais ce n'est pas tout à fait le cas.
@LaurentSC : la chasse aux synonymes est une étape importante, ils sont source de confusion, il faut les éliminer.
Si la bonne terminologie est "LICENCE_VALIDEE" ne retenez que ce terme et évacuez "LICENCE" (tout court) du discours.
Ce faisant, vu que vous optez pour des noms anglais "VALID LICENSE" est à utiliser plutôt que "LICENSE VALIDEE" soit un nom écrit à l'anglaise avec un adjectif en français

[laurentSc]

Qu’est-ce que LICENSE_VALIDEE ?

C'est du franglais mais j'ai récupéré ce terme que vous avez utilisé dans la figure (C) du post #17. Mais exact, ce terme n'est pas présent dans mon modèle du post #18 (ma dernière version). Je ne vais donc plus utiliser ce terme.

En tout cas, quand vous écrivez que « c'est dans LICENSE_VALIDEE qu'il ne faut pas faire d'INSERT ou d’UPDATE », on est en droit d’interpréter cette affirmation comme quoi LICENSE_VALIDEE sera toujours vide, donc qu’elle n’a a priori aucun intérêt, auquel cas son existence est à remettre en cause, elle devrait disparaître. Sinon, merci de reformuler, d’expliquer dans quelles circonstances la table SQL correspondante est mise à jour et exploitée : quand pas d’erreur détectée ?

Je n'ai visiblement pas été clair. Dans mes explications, je vais utiliser le modèle du post #18, qui est la version actuelle du modèle. Dans ce modèle, il y a une partie "ticket" et une partie "license". Dans mes explications, je vais me restreindre à la partie "license".
Il y a donc 2 classes, license et license_error, à la structure identique.
Quand j'analyse un fichier CSV que je viens de recevoir, de 2 choses l'une : soit toutes les informations sont correctes, soit une ou des erreurs est(sont) détectée(s).
Si aucune erreur, écriture (INSERT ou UPDATE) dans license.
Si au moins une erreur est détectée, écriture dans license_error.
Je reconnais que la table license_error n'a pas beaucoup de raison d'être, vu qu'on ne fait jamais de SELECT dessus. Elle est là pour que le code ne plante pas, car même si une erreur a été détectée, je fais quand même un INSERT ou UPDATE, mais il ne faut pas écrire dans license (ne pas polluer cette table avec des données erronées).

J'ai une autre question sur la partie "ticket" mais pour plus tard...

[isabelle.letrong]

fsmrl
En notant que MySQL est à la traîne et ne permet pas qu’un trigger porte sur une vue . A défaut, pour effectuer des inserts et des updates sur une vue, changer de SGBD.

En fait dans l'environnement MySQL je me suis affranchie de ces limites en interdisant toute mise à jour aux clients 'externes' (en particulier aux clients PHP). Les mise à jour ne se font que par des routines stockées, propriétés du seul utilisateur, hormis root, ayant l'accès en maj. Lorsqu'un client(php...) appelle une routine stockée il hérite des droits de mise à jour, mais dans le cadre strictement défini, testé et cadré des routines stockées exécutables. Ces routines sont développées par un sachant relationnel qui n'a pas peur des unions et jointures et qui peut se passer des vues. Une approche tellement plus sécurisante....

laurentSc
En fait, j'ai mis à jour la bdd hier, et j'ai passé toute la journée à modifier le code PHP qui gère la bdd (et c'est loin d'être fini...).

PDO exige quand même des échanges bien verbeux, il n'y a par ailleurs pas de réel contrôle sur le code SQL qui est vu comme une chaine de caractères.
N'en déplaise aux amateurs d'ORM, on a quand même tellement intérêt à coder les règles de mise à jour des données sur le SGBD...

[fsmrel]

Bonjour,

Je reconnais que la table license_error n'a pas beaucoup de raison d'être, vu qu'on ne fait jamais de SELECT dessus. Elle est là pour que le code ne plante pas, car même si une erreur a été détectée, je fais quand même un INSERT ou UPDATE, mais il ne faut pas écrire dans license (ne pas polluer cette table avec des données erronées).

Du strict point de vue de la modélisation, l’existence de la classe LICENSE_ERROR n’est pas choquante. S’il se trouve qu’à son tour, c’est-à-dire au stade SQL, la table LICENSE_ERROR ne fera l’objet d’aucun SELECT, après tout le modèle n’étant pas concerné, gardons les choses comme ça, va pour le MCD du post #18.

[laurentSc]

Merci de me conforter dans mon choix de modèle. Même si j'ai simplifié la bdd (y a une table en moins), le code est plus complexe (par exemple, avant un simple SELECT sur cette table est devenu un SELECT avec 2 jointures...). Ca fait 2 jours, que je m'échine à écrire le code PHP pour gérer cette bdd, donc pas envie de revenir en arrière...

[escartefigue]

Si le contenu de la table LICENSE_ERROR n'est jamais utilisé, afin de ne pas modifier le code existant dans les traitements, on pourrait remplacer les ordres INSERT sur cette table par du code mort au moyen d'un TRIGGERde type INSTEAD OFF, la table resterait donc vide malgré les ordres INSERT...

... Malheureusement MYSQL ne connaît pas ce type de TRIGGER

[fsmrel]

le code est plus complexe (par exemple, avant un simple SELECT sur cette table est devenu un SELECT avec 2 jointures...).

De quelle table s’agit-il ? Il faudrait que vous nous montriez (en SQL pur) la requête SELECT qui vous tracasse, avec ses jointures. Quant à la complexité, n’oubliez pas qu’on peut l’encapsuler dans une vue (cf. le post #12).

[laurentSc]

De quelle table s’agit-il ? Il faudrait que vous nous montriez (en SQL pur) la requête SELECT qui vous tracasse, avec ses jointures. Quant à la complexité, n’oubliez pas qu’on peut l’encapsuler dans une vue (cf. le post #12).

La table supprimée n'est décrite nulle part, et pas motivé pour le faire.
Par contre, la requête, même si j'ai passé du temps à la mettre au point ne me semble pas finalement si complexe que ça...Elle est décrite au post #6 de cette discussion : https://www.developpez.net/forums/d2.../#post11727956.

[laurentSc]

Je poursuis cette discussion, mise en veilleuse, car je fais encore évoluer le MCD donc il s'agit de finaliser cette étape avant de se pencher sur la réalisation physique de la bdd et des requêtes SQL.


Ayant lu les remarques de isabelle.letrong dans une autre discussion :

Le problème n'est pas d'alourdir le modèle (vous n'avez peut-être pas idée de la puissance d'un moteur relationnel et de la puissance de l'algèbre relationnelle) mais de traduire dans le modèle les règles applicables.
Par exemple, je comprends que 'company' soit celle d'un custumer, mais est-elle aussi toujours celle d'un user 'submitter'. En d'autre termes, company a-t-il bien place dans le user ? Non, s'il est uniquement une donnée liée à un custumer. Et par ailleurs comment ferez vous dès que vous allez chercher à savoir le nombre de tickets émis par une 'company' (SNCF, S.N.C.F, ...)
Remplir des tables avec une liste de colonnes pouvant être null, sous-couvert de faire un modèle léger, est une aberration vis à vis du modèle relationnel et vous posera des problèmes, sur le plan des performances et dès que vous voudrez faire évoluer l'application ...

J'ai décidé de "splitter" la classe user_table car beaucoup de ses attributs étaient nullables vu que cette classe couvraient de nombreux cas. Et j'ai utilisé le concept de héritage des classes d'entité (je ne le connaissais pas, mais c'est simple). Du coup, une classe mère user_table et 3 classes filles license_owner, customer et submitter.

Dans le cas standard (données à traiter non erronées), ça donne ce MCD :
Mais quand les données sont erronées, il ne faut pas écrire dans les classes license ou ticket. Le mécanisme utilisé est alors d'écrire dans une classe license_error ou ticket_error. J'ai donc créé des classes supplémentaires et du coup, ça donne ce MCD :

Qu'est-ce que ça vaut ?

[isabelle.letrong]

Qu'est-ce que ça vaut ?

Juste une remarque rapide sans avoir examiner attentivement le nouveau modèle : Les héritages de user_table par customer et submitter ne sont pas XT car non exclusifs (Si j'ai bien compris un submitter peut être customer...).

[escartefigue]

@Laurent : j'ai beaucoup de mal à déchiffrer le MCD, les symboles et textes sont trop petits et le zoom est inopérant
il faudrait découper le modèle en sous-ensembles pour en faciliter la lecture

Merci

[laurentSc]

J'espère que c'est plus lisible comme cela :
J'ai retiré les classes erreur car elle complique beaucoup le modèle et je pense pouvoir m'en passer...

Les héritages de user_table par customer et submitter ne sont pas XT car non exclusifs (Si j'ai bien compris un submitter peut être customer...).

Pris en compte. Exact, le submitter est souvent aussi le customer.

Une question au niveau des requêtes SQL ; j'imagine que par exemple si on doit insérer un nouveau customer, on fait d'abord un INSERT dans la classe mère (user_table) ; on récupère l'ID (lastInsertId ), puis on fait un INSERT dans la classe customer et notamment dans la clé étrangère id_user qui pointe vers user_table, on insère le ID qu'on vient de récupérer. C'est bien ça ?

id_customer et id_submitter ne doivent pas être auto-incrémentée car elles héritent de l'id_user. Du reste pour une meilleur compréhension vous pourriez appeler ces colonnes 'id_user'.

J'ai retiré l'auto-incrémentation des 3 classes fille et seulement laissé l'auto-incrémentation de id_user dans la classe mère. Par contre, pas convaincu de l'intérêt de renommer ces propriétés id_user car dans ce cas-là, on aurait une propriété id_user dans 4 classes et ça risque de nuire à la clarté.

Pour 'country', vous devriez utiliser la codification ISO 3166-1 alpha-3 (pas en tant qu'identifiant où il convient de rester sur un entier auto-incrémenté mais comme attribut ayant une propriété d'unicité).

Si je laisse les noms de pays dans l'attribut country de la classe country plutôt que d'utiliser un codage, ça reste beaucoup plus lisible. Pas besoin de déchiffrer le codage...

L'association 'licence_owner' avec le 'user_(table)' ne devrait-elle pas être plutôt avec le 'customer' ?

Je ne pense pas car même si un customer est toujours aussi un license_owner, les attributs sont différents.

[escartefigue]

Bonsoir,

entité-type "application"
"platform" et "platform owner" sont probablement à positionner dans une autre entité-type en association 0,n ou 1,n avec "application", on évitera ainsi les redondances et les graphies différentes, sources d'erreur
Il en va sans doute de même avec "publisher". S'il s'agit de l'éditeur de l'application, un éditeur pouvant publier plusieurs applications on modélisera [EDITEUR] 1,n --- (publier) --- 1,1 [APPLICATION]
Je vous laisse le soin de traduire les noms en anglais


entités-type "user_table", "client" et "submiter"
Si j'ai bien compris les explications qui précèdent parmi les utilisateurs, certains ont besoin d'ouvrir des tickets, ce sont les "clients" (customer)
Parfois, ces clients n'ouvrent pas eux-mêmes le ticket mais le font ouvrir par un tiers, disons le "déclarant" (submiter)
Pour que le ticket soit associé à un bénéficiaire et un déclarant, il n'est pas nécessaire de créer deux types d'entité, il suffit de créer deux associations, par exemple (demander) et (declarer), entre [USER] et [TICKET]
Si toutefois les sous-types sont utiles pour d'autres utilisations (attributs spécifiques, autres asso spécifiques...) alors il faut ne positionner qu'un seul symbole héritage (le triangle) et attacher les deux sous-types à ce symbole.
C'est ce qui permettra de spécifier le type de contrainte, s'il y en a (partition, exclusion, totalité)

Voici ce que ça donne au niveau conceptuel avec Looping si l'héritage n'est pas nécessaire :

Pièce jointe 599054
Note : je n'ai pas mis de contrainte entre les deux assos, ce faisant, "customer" et "submiter" peuvent librement être la même personne ou pas
S'il faut contrôler que ce sont des personnes différentes, il suffira d'ajouter une contrainte X entre ces deux assos.
La cardinalité minimale de 1 de "ticket" vers chacune des deux assos, fait que l'un et l'autre sont "not null"

J'ai donné un nom au rôle des "pattes" de l'asso coté [USER] de sorte à bien identifier ce rôle au niveau des FK de la table TICKET, on retrouve ces suffixes dans le script (US_ident_ES et US_ident_RQ) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE US_user(
   US_ident INT AUTO_INCREMENT,
   PRIMARY KEY(US_ident)
);
 
CREATE TABLE TI_ticket(
   TI_ident INT AUTO_INCREMENT,
   US_ident_ES INT NOT NULL,
   US_ident_RQ INT NOT NULL,
   PRIMARY KEY(TI_ident),
   FOREIGN KEY(US_ident_ES) REFERENCES US_user(US_ident),
   FOREIGN KEY(US_ident_RQ) REFERENCES US_user(US_ident)
);

first_name et last_name : revoir leur longueur à la baisse, 255 c'est beaucoup trop



entité-type "location"
S'il s'agit d'une adresse, alors il est recommandé de suivre la norme postale prévue non seulement pour les adresses françaises mais également étrangères.
Cette norme prévoit de mémoire 6 à 7 lignes de 38 caractères (norme accessible gratuitement sur le web).
Pour faciliter la gestion, éviter les erreurs et les redondances, il est préférable de modéliser

[ADRESSE] 1,1 --- (situer) --- 1,n [VILLE] 1,1 --- (localiser) --- 0,n [PAYS]



entité-type "country"
Pour la plupart des codes (pays, unités de mesure, devises etc.) il existe une norme ISO, pratique car internationale et exhaustive.
Vous pouvez ici appliquer la norme ISO 3166 qui propose 3 codes pays (vous pouvez n'en retenir qu'un seul), alpha 2, alpha 3 et num 3.
L'usage le plus courant étant l'alpha 3. Chaque pays sera stocké avec un identifiant technique, un code (ex le code alpha 3), un libellé et éventuellement une date de début et de fin de validité



entité-type "ticket"
"assign_group" fait certainement référence à une équipe compétente pour traiter le ticket, là aussi il faut externaliser cette notion car un groupe aura à traiter plein de tickets, la redondance et les incohérences vous guettent donc !
Il faut établir [TICKET] 0,x --- (attribute) --- 0,n [TEAM]
Les attributs de type varchar dont la longueur maximale n'excède pas une vingtaine de caractères gagnent à être déclarés en char fixe.
En effet, d'une part le varchar ajoute 1 à 3 octets pour stocker la longueur, d'autre part il provoque des déplacements des lignes dans les tablespaces et indexspace en cas de modification de la longueur (ce qui prend du temps et fragmente les espaces) tout ça pour un gain marginal d'espace.

[laurentSc]

Bonsoir,

j'ai bien noté vos différentes propositions.

Tout d'abord, pour bien les prendre en compte, je vais demander demain des précisions sur la définition des attributs platform, platformowner, publisher et assigned group car pour moi, pour le moment, ce sont juste des colonnes de fichiers CSV mais j'ignore quasiment ce qu'elles représentent...

entités-type "user_table", "client" et "submiter"
Si j'ai bien compris les explications qui précèdent parmi les utilisateurs, certains ont besoin d'ouvrir des tickets, ce sont les "clients" (customer)
Parfois, ces clients n'ouvrent pas eux-mêmes le ticket mais le font ouvrir par un tiers, disons le "déclarant" (submiter)
Pour que le ticket soit associé à un bénéficiaire et un déclarant, il n'est pas nécessaire de créer deux types d'entité, il suffit de créer deux associations, par exemple (demander) et (declarer), entre [USER] et [TICKET]
Si toutefois les sous-types sont utiles pour d'autres utilisations (attributs spécifiques, autres asso spécifiques...) alors il faut ne positionner qu'un seul symbole héritage (le triangle) et attacher les deux sous-types à ce symbole.
C'est ce qui permettra de spécifier le type de contrainte, s'il y en a (partition, exclusion, totalité)

Comme les classes customer et submitter n'ont pas les mêmes propriétés, il reste utile de les conserver. Par contre, je ne suis pas sur de comprendre comment avoir un seul symbole d'héritage. J'ai produit un MCD modifié avec la façon dont j'ai compris (et comme en plus de customer et submitter, il y a aussi license_owner qui hérite de user_table, je lui ai fait subir le même sort).

entité-type "location"
S'il s'agit d'une adresse, alors il est recommandé de suivre la norme postale prévue non seulement pour les adresses françaises mais également étrangères.
Cette norme prévoit de mémoire 6 à 7 lignes de 38 caractères (norme accessible gratuitement sur le web).
Pour faciliter la gestion, éviter les erreurs et les redondances, il est préférable de modéliser

[ADRESSE] 1,1 --- (situer) --- 1,n [VILLE] 1,1 --- (localiser) --- 0,n [PAYS]

La plupart du temps, on a pas une adresse complète mais juste le nom d'un site (exemple : DEU - Marktheidenfeld), donc je pense laisser le type VARCHAR(40).

entité-type "country"
Pour la plupart des codes (pays, unités de mesure, devises etc.) il existe une norme ISO, pratique car internationale et exhaustive.
Vous pouvez ici appliquer la norme ISO 3166 qui propose 3 codes pays (vous pouvez n'en retenir qu'un seul), alpha 2, alpha 3 et num 3.
L'usage le plus courant étant l'alpha 3. Chaque pays sera stocké avec un identifiant technique, un code (ex le code alpha 3), un libellé et éventuellement une date de début et de fin de validité

OK, je regarderai.

Voici le MCD corrigé :

[laurentSc]

Tout d'abord, pour bien les prendre en compte, je vais demander demain des précisions sur la définition des attributs platform, platformowner, publisher et assigned group car pour moi, pour le moment, ce sont juste des colonnes de fichiers CSV mais j'ignore quasiment ce qu'elles représentent...

platform, platformowner : les applications sont regroupées en plateformes (platform) et une personne est désignée comme responsable (platformowner ). Donc en théorie, on pourrait créer une table platform qui contiendrait ces 2 attributs et la relier à la table application. Mais la conséquence serait une complexité un peu supérieure du modèle, donc des requêtes SQL plus complexes pour pas grand chose : les données étant issues d'une autre bdd (dont on fait un export au format CSV, puis qu'on récupère dans l'outil que je développe), ces données sont déjà contrôlées donc aucun risque d'erreur de saisie. Donc je pense ne pas créer de classe platform.

publisher : c'est celui qui a créé l'application, donc sa place est bien dans la classe application.

assigned_group : cet attribut concerne les tickets. Il s'agit du groupe de personnes en charge de traiter le ticket. Certes, on pourrait créer une classe assigned_group et y mettre cet attribut, mais à part faire plaisir aux puristes, on y gagnerait que de la complexité. Je pense donc le laisser dans la classe ticket.

Etant donné tout cela, je ne pense pas changer le MCD du post précédent. Qu'en pensez-vous ?

[isabelle.letrong]

Quelques questions/remarques en réaction au dernier MCD

• Faut-il être owner d'une licence pour (faire)déposer un ticket (en tant que customer...) ? Question pour valider l'intérêt de l'association concern_t...

• En remarque si héritage il n'est pas possible que id_user, id_customer et id_submitter n'aient pas le même format (on ne peut pas mixer INT et SMALINT du fait des foreign keys). Au passage, il est bien que les entiers auto-incrémentés soit non signés, histoire de ne pas perdre la moitié des clés.....

• L'entité licence_owner me semble bizarre. Lorsque l'on regarde les attributs:
  
  - email devrait être une propriété multi-valuée de user_table (Externalisation par exemple d'une entité coordonnnées, en association avec user_table)
  - company et buunitname devraient probablement également être sortis de cette entité)
  - Finalement license_owner se transformerait donc en association entre license et customer