Discussion :

[Paprick]

Bonjour,
Une petite question annexe : quelle configuration utilisez-vous sur votre ordi ? Version Windows, option affichage, zoom, taille caractères, ... ?
Je trouve en effet que les textes prennent beaucoup de place (et débordent parfois) dans les classes d'entités et associations.

[laurentSc]

Je réponds comme je peux et si ça suffit pas, merci de me dire quelles indications en plus et comment les obtenir.

ordi : portable Lenovo

OS : Windows10

affichage :
taille du texte : 125%
résolution écran : 1920 x 1080

Voilà. Autre chose ?

[Paprick]

Ok, je pense que le problème vient des 125% pour la taille du texte.
C'est tout de même bizarre car j'ai fait le test sur ma machine également en Windows 10, et je n'ai pas le problème.
Quelle version de Looping utilisez-vous ?

[laurentSc]

Je me suis mis en taille du texte à 100% même si avant c'était à 125% (recommandé qu'ils disent) et voici les nouvelles copies d'écran :



A noter que quand ça dépassait, ça ne dépassait que sur l'image "copie d'écran" mais pas sur l'écran lui-même !
Pour faire une copie d'écran, je clique sur un bouton de Looping exporter vers le presse-papier puis je colle le résultat dans GIMP et je l'exporte au format png.

Ma version de Looping : 3.0

Au passage, j'ai déplacé les tables location et country. C'est bien plus esthétique et lisible...

[Paprick]

C'est guère mieux...
Il faut fermer Looping et le relancer pour qu'il prenne en compte la modif de taille de caractères à 100% au lieu de 125%.
Profitez-en pour passer à la 3.1 !

[laurentSc]

Voici ce que ça donne avec la version 3.1 (comme mon PC pro refuse le téléchargement, je télécharge sur mon PC perso (Windows 10 aussi) puis je transfère le fichier).

[Paprick]

Voici ce que ça donne avec la version 3.1 (comme mon PC pro refuse le téléchargement, je télécharge sur mon PC perso (Windows 10 aussi) puis je transfère le fichier).

Ce n'est pas la 3.1 et, à mon avis, vous êtes toujours à 125% .

[laurentSc]

Cette fois, je suis sûr que c'est la 3.1 car je peux déplacer le modèle entier en faisant un clic droit et avant je ne pouvais pas et pour être sûr que l'ordi a pris en compte le passage de la taille du texte à 100%, j'ai redémarré l'ordi.






EDIT : je vois bel et bien une différence donc le reboot de l'ordi semblait nécessaire...

[escartefigue]

Bonjour Laurentsc,

C'est bien la V3.1 de Looping, reconnaissable au fait que, par défaut, les associations n-aires comme par exemple "posseder" sont bicolores, ce n'était pas le cas avec la version 3.0

Attention au typage de vos identifiants primaires : appli_name n'est pas un bon choix de type pour une PK (sauf si vous êtes absolument certain de la stabilité des valeurs sur le long terme et que ces valeurs sont concises)

[laurentSc]

C'est bien la V3.1 de Looping, reconnaissable au fait que, par défaut, les associations n-aires comme par exemple "posseder" sont bicolores, ce n'était pas le cas avec la version 3.0

C'est pas les clés étrangères qui sont d'une autre couleur ? Ca semble être le cas dans toutes les tables...

Attention au typage de vos identifiants primaires : appli_name n'est pas un bon choix de type pour une PK (sauf si vous êtes absolument certain de la stabilité des valeurs sur le long terme et que ces valeurs sont concises)

J'avais fait l'hypothèse de la pérennité de cette rubrique, mais pour en être sûr, je poserai la question à mon "client" (mon manager).
Pour la question de la concision, ces noms, bien que pas à rallonge, sont un peu plus longs qu'un entier auto-incrémenté. C'est important ?

vos identifiants primaires

Je connaissais les identifiants et les clés primaires, mais ça, jamais vu. Ca vient de sortir ?

[laurentSc]

Cette question de la concision de l'identifiant est importante car j'ai souvent fait le choix d'une rubrique bien plus longue qu'un entier :
- appli_name : varchar(50)
- location : varchar(40)
- country : varchar(50)

[Paprick]

Cette question de la concision de l'identifiant est importante car j'ai souvent pas le choix d'une rubrique bien plus longue qu'un entier :
- appli_name : varchar(50)
- location : varchar(40)
- country : varchar(50)

Pour moi, les VARCHAR ne respectent pas la règle de "Formalisme" (page 135) et doivent être bannis du rôle d'identifiant (sans parler des problèmes de performances qu'ils poseraient ensuite).

[laurentSc]

J'avais bien lu cette règle sur le formalisme (j'ai atteint la page 150), mais je ne pense pas être dans le cas traité avec un exemple : les noms ne sont pas saisis par un utilisateur, mais proviennent d'une autre base de données (dont le contenu est exporté dans le format CSV). Donc je pense qu'il n'y a pas de risque.
Pour ce qui est de la performance, certes, mais avec la puissance des machines actuelles, ce qu'ont obtient avec des varchar semble suffisant.

[escartefigue]

Le fait que les noms soient issus d'une autre base de données est justement un risque supplémentaire d'instabilité.
Tout référentiel externe peut faire l'objet de modification de structure ou de contenu.
Et même dans un référentiel interne, les libellés sont rarement des valeurs stables.
Attention donc.

De plus, du varchar(50) c'est 52 octets (2 octets pour la longueur), soit, pour un processeur 64 bits, 7 cycles CPU rien que pour manipuler l'identifiant.
Alors qu'un integer c'est 4 octets et un big integer c'est 8 octets, soit un seul cycle CPU.

Plus encore, le char et le varchar sont sensibles à la collation, la même valeur peut donc être interprétée différemment si la collation n'est pas la même.

Enfin, le varchar présente certains inconvénients techniques nuisibles aux performances (besoin d'alignement sur longueur fixe pour certaines opérations, déplacement des pages data et index en cas de MàJ de la longueur).

[laurentSc]

Je n'ai pas pu répondre avant n'étant pas disponible, mais vous m'avez convaincu et j'en ai tenu compte dans mon MCD (et donc dans le MLD généré par Looping) (où tous les identifiants sont des entiers non significatifs)

[fsmrel]

Bonsoir,


N’oubliez pas (comme je l’ai précisé par exemple dans le post #23) que les clés naturelles (identifiants naturels du MCD), devenues alternatives, doivent être déclarées. Exemple :

A défaut, gare aux doublons…

[escartefigue]

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 évntuellement), mais en ce cas il faut nommer les associations dans la même langue.

La "business unit" est peut-être fonction de la compagnie ?
Auquel cas le modèle serait
[UTILISATEUR] 0,1 --- affecter --- 0,n [BUSINESS_UNIT] 1,1(R) --- rattacher --- 1,n [COMPANY]

[laurentSc]

les clés naturelles (identifiants naturels du MCD), devenues alternatives, doivent être déclarées.

fsmrel, vous prenez comme exemple la rubrique sesa qui est en fait le seul cas où la question se pose (dans tous les autres cas, la clé devenue alternative est restée (par exemple, dans la classe ticket, j'ai laissé l'entitée num_ticket (renommée) qui est l'identifiant naturel)). Dans la classe license, je n'ai pas mis d'entitée sesa ; il y a un lien avec la table user_table donc dans le MLD, il y a une table associative ownavec la rubrique id_user et dans la table user_table, il y a une entitée sesa, donc l'information existe bien. C'est bon comme ça ?

Escartefigue, merci pour votre remarque, j'ai tout mis en anglais (je suis dans une multi-nationale et rien ne dit que les utilisateurs seront tous français).

La "business unit" est peut-être fonction de la compagnie ?

Même s'il y a plusieurs compagnies, ce sont en fait toutes des filiales du groupe principal, et donc la business unit est la même pour tous. J'en demanderai quand même confirmation.

Cela dit, je n'ai pas compris votre dernière remarque :

Auquel cas le modèle serait
[UTILISATEUR] 0,1 --- affecter --- 0,n [BUSINESS_UNIT] 1,1(R) --- rattacher --- 1,n [COMPANY]

Si je fais un copier-coller, il n'y a plus les sauts de ligne qu'il y avait chez vous. C'est juste comme ça ? En gros, vous rajoutez une classe BUSINESS_UNIT (Connais pas encore la notation (R)).

[escartefigue]

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
Reste à vérifier si la BU dépend ou pas de la compagnie.

La notation (R) symbolise l'identification relative.
J'avais supposé que les B.U. étaient une entité-type faible de la compagnie (un sous-ensemble de celle-ci), d'où cette symbolique.

[Paprick]

La notation (R) symbolise l'identification relative.
J'avais supposé que les B.U. étaient une entité-type faible de la compagnie (un sous-ensemble de celle-ci), d'où cette symbolique.

Cf. chapitre 13 (page 185) !