Discussion :

[laurentSc]

Cf. chapitre 13 (page 185) !

OK, mais je n'en suis qu'à la page 153 (chapitre 11)...

Puisqu'il y a plusieurs compagnies, pour éviter les graphies différentes entre plusieurs utilisateurs d'une même compagnie, la modélisation d'une classe "company" est intéressante (vous n'êtes pas à l'abri d'un changement de nom de compagnie)
Même raisonnement pour les business unit

Je pense qu'il n'y a pas de risque de graphie différente pour les compagnies comme pour les business units, vu que je récupère les données venant d'une autre bdd et que les utilisateurs n'ont pas un champ libre pour saisir le nom de la compagnie ou de la business unit ; c'est une liste déroulante dans laquelle ils doivent choisir un nom qui sera donc tout le temps le même. Etant donné cela, pas sûr de l'utilité de créer 2 tables supplémentaires. Qu'en pensez-vous ?

[fsmrel]

vous prenez comme exemple la rubrique sesa qui est en fait le seul cas où la question se pose

Il y a d’autres cas, à savoir la rubrique country (de la classe d’entités COUNTRY), la rubrique location (de la classe d’entités LOCATION), la rubrique appli_name (de la classe d’entités APPLICATION). Ces rubriques sont des identifiants alternatifs.

dans la classe ticket, j'ai laissé l'entitée num_ticket (renommée) qui est l'identifiant naturel)

Au sens de la théorie des ensembles, une entité est un élément d’une classe d’entités. A priori num_ticket n’est qu’une rubrique. Vous l’avez renommée, mais comment ? En id_ticket ? En tout cas, les valeurs de id_ticket sont calculées par ACCESS (du fait de COUNTER), dans ces conditions id_ticket est un identifiant artificiel. Accessoirement, si vous n’utilisez pas ACCESS, choisissez votre SGBD dans la fenêtre « Propriétés » de Looping.

Dans la classe license, je n'ai pas mis d'entitée sesa

C’est heureux ! Contrairement à ce qui se passe dans un MLD, dans un MCD une rubrique ne doit effectivement être présente qu’une fois (one fact, one place). C’est l’AGL qui se charge de déclarer les clés étrangères dans le MLD, donc les références, par exemple la clé étrangère {id_user} dans la table POSSEDER, établissant ainsi la connexion avec la table USER_TABLE.

Attention, sesa n’est pas une entité (attention à l’orthographe, le mot "entitée" n’existe pas…) mais une rubrique (synonyme d’attribut ou de propriété).

Cela dit, le MLD généré par Looping est la traduction fidèle de votre MCD.

[laurentSc]

2e fois que je découvre avec beaucoup de retard une réponse sur ce fil, car bien qu'étant abonné, pas reçu de mail...

Il y a d’autres cas

Je ne sais plus à quoi je pensais mais c'est sûr qu'il y a plusieurs identifiants alternatifs.

Vous l’avez renommée, mais comment ? En id_ticket ?

Non ! id_ticket, c'était l'ancien nom mais maintenant, j'ai créé un identifiant artificiel nommé id_ticket, et ai renommé l'ancienne clé primaire en num_ticket.

id_ticket => num_ticket
             id_ticket (new)

Accessoirement, si vous n’utilisez pas ACCESS, choisissez votre SGBD dans la fenêtre « Propriétés » de Looping.

ACCESS est visiblement la valeur par défaut. Je ne savais pas spécifier le SGBD. J'ai mis MySQL.

C’est heureux ! Contrairement à ce qui se passe dans un MLD, dans un MCD une rubrique ne doit effectivement être présente qu’une fois (one fact, one place).

Je disais ça car pour créer le MCD, je suis parti de l'existant à savoir les tables que j'avais créée dans MySQL_WorkBench et là, il y avait une colonne SESAdans la table licenseet idem dans la table user_table.

Mon nouveau MCD :

[fsmrel]

Bonsoir,

il y avait une colonne SESA dans la table license

Cette colonne est désormais à sa place, dans USER_TABLE, très bien. les entités-types sont dotées d’identifiants alternatifs, c’est très bien aussi, toutefois l’entité-type LICENSE en est dépourvue, elle va se sentir frustrée…

L’association POSSEDER est devenue entité-type associative (OWN) : quel intérêt ?

Cela dit, le MCD prend forme.

[laurentSc]

toutefois l’entité-type LICENSE en est dépourvue, elle va se sentir frustrée…

Dans les fichiers CSV que je reçois (qui sont le résultat d'export d'une autre bdd), les licences sont identifiées par une colonne sesaid, sachant que s'il y a plusieurs utilisateurs qui possèdent une licence sur la même application, il y a plusieurs enregistrements (plusieurs lignes) dans le CSV, et si l'utilisateur possède plusieurs licences, il y a aussi une colonne application_name pour les distinguer, mais il n'y a pas d'information pour identifier la licence elle-même...

L’association POSSEDER est devenue entité-type associative (OWN) : quel intérêt ?

De prendre en compte cette remarque (post #57 de cette discussion) :

Attention : les types d'entité et les attributs sont nommés en anglais et les associations en français.
Les associations n-aires devenant des tables, vous aurez donc des objets nommés dans les deux langues.

Si le projet est franco-français, l'usage du français est préférable : plus simple pour tout le monde et limite les risque de percussion avec les mots réservés SQL. Si le projet est international, l'anglais est préférable (ou la langue locale éventuellement), mais en ce cas il faut nommer les associations dans la même langue.

J'ai choisi l'anglais, étant dans une multi-nationale.


J'ai découvert le concept de identifiant relatif (j'ai survolé le chapitre 12, sachant que les requêtes SQL de création des tables, je connais déjà, donc rapidement passé au chapitre 13) ; comme l'association own est n-aire, je l'ai décomposée avec Looping, et 2 identifiants relatifs sont apparus.

[Paprick]

Bonjour,

J'ai découvert le concept de identifiant relatif (j'ai survolé le chapitre 12, sachant que les requêtes SQL de création des tables, je connais déjà, donc rapidement passé au chapitre 13) ; comme l'association own est n-aire, je l'ai décomposée avec Looping, et 2 identifiants relatifs sont apparus.

Attention : il y a visiblement confusion dans ce que l'on appelle association n-aire !
On parle de n-aire en comparaison avec les binaires qui sont les associations classiques qui relient 2 classes d'entités (donc avec n=2) : la problématique n-aire apparait dès lors que n est supérieur à 2 (les fameuses tripattes en autres).
Une association basique avec des cardinalités multiples (0,n / 1,n) de part et d'autre n'est pas qualifiée de n-aire si n=2.

Quoi qu'il en soit, dans votre cas, la décomposition ne s'impose pas et alourdit le modèle pour rien.

[laurentSc]

Attention : il y a visiblement confusion dans ce que l'on appelle association n-aire !
On parle de n-aire en comparaison avec les binaires qui sont les associations classiques qui relient 2 classes d'entités (donc avec n=2) : la problématique n-aire apparait dès lors que n est supérieur à 2 (les fameuses tripattes en autres).
Une association basique avec des cardinalités multiples (0,n / 1,n) de part et d'autre n'est pas qualifiée de n-aire si n=2.

Voici ce que j'avais compris : qu'une association était n-aire dès qu'elle est multiple de part et d'autre...

On parle de n-aire en comparaison avec les binaires qui sont les associations classiques qui relient 2 classes d'entités (donc avec n=2)

De plus, cette phrase, j'ai du mal : quand vous dites donc avec n=2, le n n'a rien à voir avec le n des cardinalités multiples 0,n ou 1,n, n'est-ce pas ? n-aire, c'est quand il y a plus de 2 classes d'entités mises en relation ?

Quoi qu'il en soit, dans votre cas, la décomposition ne s'impose pas et alourdit le modèle pour rien.

Je crois avoir bien fait de conserver la version avant :

Améliorations potentielles de Looping :

- quand on fait ouvrir un document existant, proposer les documents ouverts récemment (ça n'obligerait pas systématiquement de naviguer pour accéder systématiquement au même emplacement (dans mon cas, l'explorateur de fichiers étant bien foutu (il me propose les dossiers récemment ouvert), ça me coûte un déplacement d'ascenseur puis 2 clics, le tout au lieu d'un seul clic))

- un peu plus lourd (j'imagine) : intégrer une historisation qui permettrait de recharger la version N-1, N-2, etc.

[Paprick]

Bonsoir,

De plus, cette phrase, j'ai du mal : quand vous dites donc avec n=2, le n n'a rien à voir avec le n des cardinalités multiples 0,n ou 1,n, n'est-ce pas ? n-aire, c'est quand il y a plus de 2 classes d'entités mises en relation ?

Effectivement, quand je parle de n-aire avec n=2, c'est l'équivalent de 2-aire (binaire) : rien à voir donc avec le n des cardinalités.

Améliorations potentielles de Looping :
- quand on fait ouvrir un document existant, proposer les documents ouverts récemment (ça n'obligerait pas systématiquement de naviguer pour accéder systématiquement au même emplacement (dans mon cas, l'explorateur de fichiers étant bien foutu (il me propose les dossiers récemment ouvert), ça me coûte un déplacement d'ascenseur puis 2 clics, le tout au lieu d'un seul clic))

En cliquant sur le bouton du menu général (le "L" dans le rond en faut à gauche), les documents récents sont proposés :

- un peu plus lourd (j'imagine) : intégrer une historisation qui permettrait de recharger la version N-1, N-2, etc.

Les copies N-1, N-2, ... N-9 sont être conservées dans dans les fichiers avec extension lo1, lo2, ... lo9 : pour cela, il suffit de paramétrer "Nb copies sauvegarde" dans les options générales des propriétés (1 par défaut).

[laurentSc]

Effectivement, quand je parle de n-aire avec n=2, c'est l'équivalent de 2-aire (binaire) : rien à voir donc avec le n des cardinalités.

En cliquant sur le bouton du menu général (le "L" dans le rond en faut à gauche), les documents récents sont proposés

je passe jamais par là (même pas vrai car pour faire enregistrer sous, j'ai bien été obligé...), donc pas vu...

Les copies N-1, N-2, ... N-9 sont être conservées dans dans les fichiers avec extension lo1, lo2, ... lo9 : pour cela, il suffit de paramétrer "Nb copies sauvegarde" dans les options générales des propriétés (1 par défaut).

Bravo, vous avez pensé à tout. Mais j'ai pas trouvé où sont les propriétés

[Paprick]

Bravo, vous avez pensé à tout. Mais j'ai pas trouvé où sont les propriétés

Cochez la case "Propriétés" en haut à droite : la fenêtre avec toutes les options apparait et vous trouverez celle sur les sauvegardes tout en bas.

[laurentSc]

Le souci est que je ne vois pas de case propriétés

[laurentSc]

Mes lunettes ne doivent pas suffire car le bouton est bien présent sur ma copie d'écran !

Du coup, j'ai passé à 5 le nombre de sauvegardes mais quand j'affiche les documents récents, bien que pour tester, j'ai crée une petite modification de mon modèle et l'ai sauvegardé, je ne vois pas de fichier .lo1...

[Paprick]

Du coup, j'ai passé à 5 le nombre de sauvegardes mais quand j'affiche les documents récents, bien que pour tester, j'ai crée une petite modification de mon modèle et l'ai sauvegardé, je ne vois pas de fichier .lo1...

Les fichiers de sauvegarde n'apparaissent pas dans les documents récents où ne sont proposés que des .loo.
Si vous voulez récupérer une ancienne version automatique du modèle (ce qui reste une opération exceptionnelle), il faut passer par "Ouvrir".

[laurentSc]

C'est peut-être exceptionnel, mais si on veut tester une modif du modèle, puis que jugeant que c'est pas bon, on veut revenir en arrière, on est dans ce cas et pas sûr que ça soit si exceptionnel que ça.

En tout cas, les fichiers d'extension lo1, lo2,... ont bien été créés mais si je fais "ouvrir un document existant", ils ne sont pas proposés, alors qu'ils sont bien visibles dans l'explorateur de fichiers...

Mais bon, j'ai pas fini sur mon MCD, mais il me semble que cette discussion a bien évolué depuis le début, qu'il est préférable de la clore et d'en créer une nouvelle si nécessaire.

En tous cas, super content d'avoir découvert votre logiciel Paprick.

[Paprick]

En tout cas, les fichiers d'extension lo1, lo2,... ont bien été créés mais si je fais "ouvrir un document existant", ils ne sont pas proposés, alors qu'ils sont bien visibles dans l'explorateur de fichiers...

Normal, Looping propose par défaut l'ouverture de "*.loo" : il suffit de demander l'extension en "*.lo*".