1.1Créer l'analyse : fichiers, rubriques & liaisons
L'essentiel en 30 secondes
- Une entité métier = un fichier : Client, Produit, Commande deviennent des fichiers de l'analyse, chacun ne mélangeant qu'un seul concept.
- Le type d'une rubrique est capital : une date en type date, un montant en monétaire — jamais tout en texte, sinon tris, calculs et contrôles deviennent faux.
- Ne jamais répéter une information : le nom du client vit dans le seul fichier Client ; les commandes s'y réfèrent par une liaison (clé étrangère).
Mini-cas filé — Yacine dessine l'analyse de son application de négoce
Yacine est développeur WinDev dans une PME de négoce de matériel électrique à Oran. Il doit livrer une application de gestion (clients, produits, commandes, factures, stocks). Il commence par lister les « choses » du métier : un Client, un Produit (câble, disjoncteur, tableau…), une Commande et ses lignes. Il en fait un fichier par entité. Il décrit ensuite les rubriques avec le bon type : Nom en texte, PrixUnitaireHT en monétaire, DateCommande en date — pas tout en texte. Il donne à chaque fichier une clé primaire (identifiant automatique). Enfin il trace la liaison : un Client a plusieurs Commandes, une Commande appartient à un seul Client. Il s'apprête à recopier le nom du client dans chaque commande, puis se ravise : cette information doit vivre une seule fois, dans le fichier Client. Yacine a construit la fondation de son application : une analyse cohérente, sans doublon.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 1.1.
1. Des entités aux fichiers
La démarche d'analyse est toujours la même. D'abord identifier les ENTITÉS du métier : les « choses » que l'application manipule (le Client, le Produit, la Commande). Chaque entité devient un FICHIER. Yacine crée ainsi les fichiers Client, Produit, Commande et LigneCommande.
Règle simple : une entité = un fichier. On ne mélange jamais deux concepts dans un même fichier — le produit et la commande sont deux choses distinctes, donc deux fichiers.
2. Des rubriques bien typées
On décrit ensuite les RUBRIQUES de chaque fichier : les informations élémentaires (Nom, Ville, PrixUnitaireHT, DateCommande). Pour chacune, on choisit un NOM clair, un TYPE adapté et une TAILLE.
Le choix du type est capital : une date se stocke en type date (pas en texte), un montant en monétaire (pour calculer, trier, totaliser). Tout mettre en texte rend les tris faux, les calculs impossibles et les contrôles inopérants.
3. Clés primaires et liaisons
Chaque fichier a besoin d'une CLÉ PRIMAIRE : l'identifiant unique de chaque enregistrement. En pratique, on utilise très souvent un identifiant automatique généré par le moteur — simple, stable et fiable.
Enfin, on trace les LIAISONS, qui traduisent les règles métier. La plus courante est le un-à-plusieurs (1,n) : un Client a plusieurs Commandes. Le fichier côté « plusieurs » (Commande) porte une rubrique pointant vers la clé de l'autre : c'est la clé étrangère. Les règles d'intégrité décident enfin du comportement à la suppression (interdire ou supprimer en cascade) pour protéger la cohérence.
🔎 Exemple concret — 🔎 Exemple concret — L'analyse « NegoceElec »
Le squelette de données que Yacine dessine dans l'éditeur d'analyses :
// Analyse "NegoceElec" — extrait
Client : IDClient (identifiant automatique), Nom, Ville, Telephone
Produit : IDProduit (auto), Libelle, Famille, PrixUnitaireHT (monétaire)
Commande : IDCommande (auto), IDClient (clé étrangère), DateCommande (date)
LigneCommande : IDLigne (auto), IDCommande, IDProduit, Quantite (entier), PrixHT
Liaison : Client (1) ──── (n) Commande // un client a plusieurs commandes
Règle d'intégrité : supprimer un client ayant des commandes → interditLecture : Yacine type chaque rubrique (monétaire, date, entier) et relie Commande à Client par la clé IDClient, sans recopier le nom.
Réflexe : une entité = un fichier ; une information = un seul endroit ; le reste passe par la liaison.
Vocabulaire de la section
- Entité → Fichier
- Chaque « chose » du métier (Client, Produit, Commande) devient un fichier de l'analyse ; une entité = un fichier, sans mélanger les concepts.
Exemple simple : Yacine crée un fichier Client, un fichier Produit et un fichier Commande.
Ce que ce n'est pas : tout ranger dans un seul fichier « Divers » qui mélange clients et produits.
Réflexe : un concept métier → un fichier.
- Rubrique et type
- Information élémentaire d'un fichier (Nom, Prix, Date), déclarée avec un nom clair, un type adapté et une taille raisonnable.
Exemple simple : Yacine stocke PrixUnitaireHT en monétaire et DateCommande en date.
Ce que ce n'est pas : stocker un prix et une date en texte, puis tenter de calculer ou de trier.
Réflexe : type correct → calculs et tris justes.
- Clé primaire
- Rubrique identifiant chaque enregistrement de façon unique et stable ; en pratique, un identifiant automatique généré par le moteur.
Exemple simple : Yacine donne au fichier Client un IDClient en identifiant automatique.
Ce que ce n'est pas : utiliser un code métier qui change (e-mail, code client renuméroté) comme clé.
Réflexe : clé primaire → identifiant automatique.
- Liaison 1,n (un à plusieurs)
- Relation la plus courante : un Client a PLUSIEURS Commandes, une Commande appartient à UN SEUL Client ; le côté « plusieurs » porte la clé étrangère.
Exemple simple : La liaison Client (1,n) Commande via IDClient porte la règle métier de Yacine.
Ce que ce n'est pas : recopier le nom du client dans chaque commande au lieu de lier.
Réflexe : deux fichiers liés → une clé étrangère, pas une recopie.
- Règle d'intégrité
- Comportement du moteur quand on supprime ou modifie un enregistrement lié (interdire, supprimer en cascade), pour protéger la cohérence.
Exemple simple : Yacine interdit la suppression d'un client qui a encore des commandes.
Ce que ce n'est pas : laisser supprimer un client et laisser des commandes orphelines.
Réflexe : suppression liée → une règle d'intégrité.
En pratique — En pratique — Construire l'analyse Client / Commande
- Listez les ENTITÉS du métier et créez un FICHIER pour chacune (Client, Produit, Commande, LigneCommande).
- Décrivez les RUBRIQUES avec le bon TYPE (texte pour un nom, date pour une date, monétaire pour un prix) et une taille raisonnable.
- Donnez à chaque fichier une CLÉ PRIMAIRE (identifiant automatique de préférence).
- Tracez les LIAISONS selon les règles métier (un Client → plusieurs Commandes), définissez les RÈGLES D'INTÉGRITÉ, puis GÉNÉREZ l'analyse.
Script pas-à-pas — dessiner l'analyse comme Yacine (5 min)
1) Listez les entités du négoce (Client, Produit, Commande, LigneCommande) et créez un fichier par entité. 2) Décrivez les rubriques avec le bon type (Nom en texte, PrixUnitaireHT en monétaire, DateCommande en date). 3) Ajoutez une clé primaire par fichier (identifiant automatique). 4) Tracez la liaison Client (1) → Commande (n) avec IDClient comme clé étrangère, sans recopier le nom du client. 5) Réglez les règles d'intégrité puis générez l'analyse.
Gardez cette analyse : elle alimentera les fenêtres (1.2), le WLangage (1.3), les champs liés (1.4) et le RAD (1.5).
Modèle copier-coller — la check-list d'analyse de Yacine
[ ] Un fichier par entité métier (Client, Produit, Commande…)
[ ] Rubriques nommées clairement et bien TYPÉES (date, monétaire…)
[ ] Une clé primaire par fichier (identifiant automatique de préférence)
[ ] Aucune information répétée d'un fichier à l'autre
[ ] Liaisons tracées (Client 1,n Commande via clé étrangère)
[ ] Règles d'intégrité décidées (suppression interdite / en cascade)
[ ] Analyse généréePetite structure
Yacine démarre avec trois fichiers (Client, Produit, Commande) et garde malgré tout une clé primaire et une liaison propres.
Lignes de commande
Pour gérer plusieurs produits par commande, Yacine ajoute LigneCommande, relié à la fois à Commande et à Produit.
Clé métier
Quand la direction impose une référence produit officielle, Yacine la garde en rubrique indexée mais conserve l'identifiant automatique comme clé primaire.
Intégrité stricte
Sur les stocks, Yacine interdit la suppression d'un produit encore référencé dans une ligne de commande.
✓ Bonnes pratiques
- Un fichier par entité métier, sans mélanger les concepts.
- Toujours typer les rubriques (date, monétaire, entier).
- Stocker chaque information une seule fois et la relier par une liaison.
✗ Pièges fréquents
- Recopier une donnée (nom du client) dans plusieurs fichiers.
- Tout mettre en texte : tris faux et calculs impossibles.
- Choisir une clé primaire instable (code métier qui change).
Points clés à retenir
- Démarche : identifier les ENTITÉS (→ fichiers), décrire les RUBRIQUES (nom + type + taille), définir la CLÉ PRIMAIRE, tracer les LIAISONS, puis GÉNÉRER l'analyse.
- Le choix du TYPE est capital : une date en date, un montant en monétaire — jamais en texte.
- La liaison la plus fréquente est le un-à-plusieurs (1,n) ; le côté « plusieurs » porte la clé étrangère et les règles d'intégrité protègent la cohérence.
- Principe fondamental : ne JAMAIS répéter une information ; on s'y réfère par la liaison.
Défi 48h — appliquez demain
Prenez un domaine que vous connaissez (ou le négoce de Yacine) et dessinez son analyse : listez les entités, créez un fichier pour chacune, typez les rubriques, ajoutez une clé primaire et tracez au moins une liaison 1,n. Écrivez en une phrase pourquoi on ne recopie jamais une information d'un fichier à l'autre.
- Je peux transformer les entités métier en fichiers d'analyse.
- Je sais typer les rubriques et choisir une clé primaire.
- Je sais tracer une liaison 1,n sans répéter d'information.
Questions fréquentes
Pourquoi ne faut-il pas répéter une information dans plusieurs fichiers ?
Parce que toute donnée répétée finit par diverger : modifiée à un endroit et pas à l'autre, elle produit des incohérences, des totaux faux et des bugs difficiles à corriger. Si le nom d'un client est stocké dans Client ET recopié dans chaque Commande, un changement de nom impose de tout mettre à jour partout — et un oubli affiche deux noms différents pour le même client. Le rôle des liaisons est précisément d'éviter cette duplication : l'information vit une seule fois, les autres fichiers s'y réfèrent par la clé.
Faut-il une clé automatique ou une clé « métier » ?
Privilégiez presque toujours l'identifiant automatique : il est unique par construction, stable (aucune signification métier, donc aucune raison de changer) et performant pour les index et les jointures. Les clés « métier » (code client, e-mail, référence) semblent pratiques mais changent, peuvent se dupliquer ou manquer à la création — et modifier une clé primaire oblige à répercuter le changement dans tous les fichiers liés. Pour Yacine, l'identifiant automatique est la clé par défaut.
Quel principe fondamental respecte-t-on en créant une analyse ?