I-2.2.1. Règles de nommage
par
, 01/04/2020 à 11h05 (289 Affichages)
1. Noms des tablesAPL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.
■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■
- Noms des tables
- Initiales de l’application
- Nommage des tables
- Noms des données
- Normalisation sémantique et syntaxique
- Tables de références
- Variables
- Clés primaires et clés étrangères
- Références croisées TABLES/ATTRIBUTS
- Discussion « Modélisation des tables et des vues »
- Noms des programmes
- Écrans, états, shells, sql, sed, files
■ Initiales de l’application
Il est judicieux d’associer à l’application un ou deux caractères (initiale(s) de l’application) qui participerons au nommage de certaines tables. Quand on développe plusieurs BDD, cela permet de se créer des environnements distincts et de maitriser ses copier-coller d'une BDD vers l'autre.
Spécificité Informix : Concernant les noms de tables, une exception concerne la table « sysmenuitems » (12 caractères) qui est l’une des deux tables du system catalog que le SGBD Informix ajoute dès lors que l’on utilise le système de menus du SGBD. Les deux tables « sysmenuitems » et « sysmenus » sont manipulables comme les tables de données de la BDD.
APL-AML limite de préférence les noms de table entre deux et cinq caractères maximum. Autant faire court car on va les utiliser dans toute l’application (écrans, états, requêtes SQL). Autant faire court car on va les utiliser dans toute l’application (écrans, états, requêtes sql).
Il est ainsi facile de nommer la plupart de ses tables par la concaténation de l’initiale ou les initiales de l’entité avec l’initiale ou des initiales de l’application.
Exemple :
Les noms de views peuvent être plus longs sans toutefois dépasser 10 caractères.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 Application : « ec » pour examens-concours Entité : « p » pour personnes, « c » pour candidatures, etc. Tables : « pec », « cec », etc.
Suffixer les noms de tables synonymes par « _bis », « _ter » afin de les distinguer des tables originales.
■ Nommage des tables
Examens-concours
NB : Voir le Billet « AGL minimaliste » pour une liste des tables.
2. Noms des données
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 ┌────────────┬──────────┬──────────┬──────────┬──────────┬─────────────────────┐ │ TABLES │ COLONNES │ RANGÉES │SYNONYMES │ VUES │ NOMS │ └────────────┴──────────┴──────────┴──────────┴──────────┴─────────────────────┘
■ Normalisation sémantique et syntaxique
Pour le RAD, l’efficacité est assujettie à un vocabulaire réduit basé sur des mots clés courts mais significatifs. Le RAD abrège facilement les noms de données, chaque abréviation devant être rapidement compréhensible. Décrites avec souplesse, cinq règles codifient une normalisation sémantique et syntaxique :
- Prendre l’abréviation usuelle quand elle existe,
- Prendre les 3, 4 ou 5 premières lettres du mot,
- Si la dernière lettre du mot est une voyelle, prendre la première lettre du mot et la dernière syllabe,
- Si la dernière lettre du mot est une consonne, prendre la première syllabe et la dernière consonne,
- Utiliser des abréviations spécifiques.
Abréger les noms de données est un héritage de l'informatique à cartes perforées qui n'a plus lieu d'être compte tenu de la puissance des ordinateurs et de la sophistication des éditeurs. L'économie de caractères se traduit par un effort de mémorisation et d’interprétation.
Si toutefois il s'avère nécessaire d'abréger certains noms de données, les règles que propose le RAD et que l'on pratique le plus souvent sans le savoir peuvent convenir. Mais objectivement, quel avantage y a-t-il à définir des mots clés du genre "tx" pour "taux", "ab" pour "abrégé", "typ" pour "type", etc. Certainement pas celui de la lisibilité des programmes.
Informix limite les noms de données à 20 caractères. L’idéal, c’est qu’ils soient explicites tout en étant le plus courts possible en évitant les abréviations.
Dans l’exemple ci-dessous, extrait de la BDD Examens-Concours, on reconnaît dans quelques noms de données les deux caractères « ec » (initiale(s) de l’application) qui participent au nommage de certaines tables de la BDD.
Exemple de noms de données avec trois tables « jury ».
NB : L’annexe «Ex&Co Sql CREATE_BDD » recense l’intégralité des noms de données de la BDD.
Une autre forme de nommage
Les développeurs de l’application nationale ont fait le choix d’un nommage des tables et des données sous la forme « XXX_XXX ». Ce choix est sans doute original et pratique mais pas toujours très explicite. Confronté à l’utilisation de cette BDD, j’ai dû commenter chaque nom de donnée à partir du dictionnaire des données de l’application.
Cette forme de nommage qui satisfait sans doute un besoin irrépressible de tout maitriser ne se traduit pas hélas par une meilleure lisibilité des programmes et encore moins par une meilleure compréhension.
Une autre table de cette même BDD nationale mais non commentée montre la difficulté à lire ce choix de nommage. L’effort de compréhension génère fatalement une fatigue mentale qui se traduit par une perte de temps.
NB : Durant toute ma carrière, le besoin de calibrer mes noms de données ne m’est jamais venu à l’esprit et si je n’ai pas ressenti ce besoin, c’est que la démarche ne s’imposait pas. Par contre, pour comprendre cette application nationale, j’ai nettement ressenti le besoin de créer un Dictionnaire des Données « papier », lequel a révélé des noms de données identiques référencés dans plusieurs tables avec un type et/ou une longueur différente(s).
■ Tables de références
Toutes les tables de références (Communes, Départements, Nomenclature, etc.) possèdent une clé primaire (un code ou un numéro), parfois un type et toujours un libellé. APL-AML privilégie donc les attributs les plus courants en les codifiant par leur initiale suivie du nom de leur table référente.
Les attributs retenus et leurs initiales sont les suivants :
Les noms de données sont donc constitués très simplement du nom de leur table référente préfixé par la lettre mnémonique, "C" pour Code, "N" pour Numéro, "T" pour Type, "L" pour Libellé et "M" pour Mnémonique.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 ┌────────────┬────┬────────────────────────────────────────────────────────────┐ │ Numéro │ n_ │ l'attribut "n_cec" se lit "Numéro de la table cec", │ │ Code │ c_ │ l'attribut "c_ec" se lit "Code de la table ec", etc. │ │ Type │ t_ │ │ │ Session │ s_ │ ─> (exception concours) │ │ Libellé │ l_ │ │ │ Date │ d_ │ │ │ Mnémonique │ m_ │ │ └────────────┴────┴────────────────────────────────────────────────────────────┘
Ainsi, une table des communes nommée "cm" aura entre autre pour noms de données :
Comme pour toute règle, il peut y avoir des exceptions, la table des codes postaux par exemple :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 cm.c_cm, (code commune de la table cm) cm.t_cm, (type commune d la table cm) cm.l_cm, (libellé commune de la table cm
Sans en abuser, rien n'interdit d'étendre le principe. (exemple : « s_ » pour session)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 cp.n_cp, (numéro de code postal de la table cp) cp.c_cm, (code commune de la table cm) cp.l_ld, (libellé lieu distribué de la table cp)
À signaler que dans les programmes, les noms de données gagnent à être renommés de la façon suivante :
Dans les programmes, les noms de données sont impérativement préfixés du nom de la table à laquelle ils appartiennent (règle SQL). Cela se pratique depuis que le COBOL existe, les données de chaque fichier en « FILE SECTION » étaient préfixées de l’étiquette logique associée à leur fichier.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 select cm.c_cm cm_c_cm, cm.t_cm cm_t_cm, cm.l_cm cm_l_cm, cp.n_cp cp_n_cp, cp.l_ld cp_l_ld from cm, cp where cm.c_cm = cp.c_cm
À tout endroit d'un programme on sait quelles données l'on manipule. Les erreurs éventuelles sur les noms de données sont essentiellement des erreurs de saisie facilement repérables.
■ Variables
Les variables d'un programme gagnent également à être préfixées, les préfixes classiques étant :
Pour une table « TA_ » :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 « P_ » pour Paramètre « V_ » pour Variable « CTR_ » pour Compteur « NBR_ » pour Nombre
■ Clés primaires et clés étrangères
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 « I_TA » pour Indice courant « J_TA » pour Indice borne des items renseignés « K_TA » pour indice borne de la table
Dans les modèles de données relationnels, la clé primaire est un attribut dont le contenu est différent pour chaque enregistrement de la table, ce qui permet de retrouver un et un seul enregistrement (exemple : cm.c_cm).
Une clé étrangère est un attribut qui contient une référence à une donnée connexe - dans les faits la valeur de la clé primaire de la donnée connexe. Le nom d’une clé étrangère (exemple : cp.c_cm) doit être rigoureusement identique à celui de la clé primaire de la donnée connexe (exemple : cm.c_cm). Leurs caractéristiques (typologie, longueur) se doivent d’être également identiques.
Pédagogiquement et/ou conceptuellement, on préfixe ou on suffixe souvent dans les entités d’un MCD, une clé primaire (un attribut de l’entité) par « id_ » ou « _id », pour identifiant. Dans le monde réel, ce préfixe « id_ » ou ce suffixe « _id » n’a pas d’intérêt pour trois raisons :
- Les clés primaires font l’objet de créations d’index, indépendamment de la création des tables.
- Une clé primaire est un attribut comme un autre et son nom n’a pas à être pollué par un préfixe indiquant sa fonction. Les développements se réalisent parfaitement sans qu’il soit nécessaire de surajouter de l’information inutile.
- Une clé primaire pour une table peut souvent être une clé étrangère pour une autre. Les deux clés, primaire et étrangère sont sensées avoir le même nom et forment ce que l’on appelle le domaine pivot qui permet le rapprochement des deux tables. Il s’en suit que la clé étrangère préfixée « id_ » prête à confusion en laissant supposer qu’il s’agit d’une clé primaire de la table connexe.
Index
Pour indexer les tables, il n’existe pas seulement des attributs faisant office de clés primaires, on peut avoir besoin de créer d’autres types d’index :
- pour permettre d’accéder aux informations de la table dans un certain ordre,
- ou pour garantir une unicité des items, différente de celle garantie par la clé primaire.
La règle de nommage des index adoptée est la suivante :
EXEMPLE :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 Les noms d'index sont constitués du nom de leur table suivi d'un suffixe qui dépend de leur fonction : ┌────────────────────────────────────────────┬──────────────────┬──────────────┐ │Fonctions │Règle │Exemple │ ├────────────────────────────────────────────┼──────────────────┼──────────────┤ │Accès aux informations dans un certain ordre│nom─table_tri │cea_tri │ │Garantie de l'unicité des items │nom─table_cle │cea_cle │ │Accès direct aux items │nom─table_attribut│cea_n_cec │ └────────────────────────────────────────────┴──────────────────┴──────────────┘
Mais il faut parfois s’arranger avec les exceptions... ea_cle et ea_cts_geo sont deux index garantissant chacun leur unicité :
■ Références croisées TABLES/ATTRIBUTS
Les tables système complétées par une table des noms d’attributs en clair permettent de réaliser un tableau avec pour chaque table ses attributs recensés dans les autres tables. Le même attribut pouvant être référencé dans plusieurs tables avec un type et/ou une longueur différente(s), un "!" repère ces incohérences.
L’extrait d’un tel document pour une table « a_nex » d’une BDD nationale est proposé dans le Billet « Environnement de Développement Intégré (EDI) ».
■ Discussion « Modélisation des tables et des vues »
De cette discussion à laquelle j’ai participé je retiens l’exemple de view proposé par Cinephil que j’ai adapté à mon univers :
(discussion « normalisation du concepteur et du développeur : nommage , entre nécessité et dogmatisme »)
Exemple de view proposée par CinePhil :
L’exemple de view de CinéPhil adapté à mon univers, ça donne ça :
Ces petites statistiques (Word) révèlent que ma façon de travailler réduit de presque la moitié le nombre de caractères saisis. Mais le plus important - difficilement quantifiable - c’est l’absence de charge mentale liée à ma méthode de nommage.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 ┌─────────────────────┬──────────┬────────────────────────────────┐ │ Statistiques │ CinéPhil │ IFA2377 │ ├─────────────────────┼──────────┼──────────┬──────────┬──────────┤ │ Mots │ 147 │ 137 │ - 10 │ │ │ Espaces non compris │ 1528 │ 869 │ - 659 │ 56,87 % │ │ Espace compris │ 1677 │ 1736 │ + 59 │ │ │ Lignes │ 46 │ 70 │ + 24 │ │ └─────────────────────┴──────────┴──────────┴──────────┴──────────┘
Saisie deux fois plus importante, préfixes, renommage de noms concaténés mais avec initiales majuscules pour réduire le nombre de caractères (cd.cdt_id_diplome_ensfea cdtIdDiplomeEnsfea) et parfois différents de l’original (d.dpl_code cdtCodeDiplomeEnsfea), suffixes, alias, sont autant de sollicitations insidieuses qui se traduisent par une charge mentale réductrice de performance.
3. Noms des programmes (éditions, écrans), des shells, des sql
■ Écrans, états, shells, sql, sed, files
Afin de standardiser les outils « AGL » (éditions et écrans listant le contenu des dossiers), le nom de chaque composant d’une fonctionnalité est limité à 10 caractères maximum.
Tout ce qui participe à la réalisation d’une fonctionnalité (Unité de Traitement) porte le même nom. Seuls changent les suffixes qui identifient la nature de chaque composant en même temps que son dossier d’hébergement.
Fonctionnalité Suffixe Dossier Nature du composant Nom_UT .per
.frm
.ace
.shell
.sql
.sed
.file../per
../frm
../ace
../shell
../sql
../sql
../fileÉcran (source)
Écran (exécutable)
Édition
Shell
Requête
Éditeur batch
Formulaire
NB :
- Les shells ne nécessitent pas de suffixes mais sont bien hébergés dans un dossier qui leur est propre : ../shell
- sql et sed sont hébergés dans le même dossier « ../sql »
- Il peut être nécessaire de diviser certains dossiers par grandes fonctionnalités afin d’en mieux maitriser la gestion. Ces dossiers sont alors suffixés par un code mnémonique pertinent. Les composants ne sont pas eux-mêmes suffixés par ce code mnémonique.
Exemple Ex&Co :
../ace_1 (Dossier des éditions concernant l’admissibilité)
../ace_2 (Dossier des éditions concernant l’admission)
../ace_mj (Dossier des éditions concernant les membres du jury)
Exemple OSMOSE :
../per_A (Dossier des écrans sources personnels Administratifs)
../per_E (Dossier des écrans sources personnels Enseignants)
../shell_0 (Dossier des shells concernant l’année scolaire en cours)
../shell_1 (Dossier des shells concernant l’année scolaire - 1)
../shell_9 (Dossier des shells concernant l’année scolaire + 1, lire neuf comme nouveau)
NB : Le Billet "AGL minimaliste" propose une arborescence des développements, une liste d'écrans et une liste d'états.
Les bonnes pratiques de programmation
▲ I-2.1.5. L’espace de travail improvisé du développeur APL-AML
► I-2.2.1. Règles de nommage
▼ I-2.2.2. Règles de développement