1.1Creating the analysis: files, items & relationships
The essentials in 30 seconds
- A business entity = a file: Client, Produit and Commande become files in the analysis, each mixing only a single concept.
- An item's type is crucial: a date as a date type, an amount as currency — never everything as text, otherwise sorting, calculations and checks become wrong.
- Never repeat information: the customer name lives in the Client file only; orders refer to it through a relationship (foreign key).
Running mini-case — Yacine designs the analysis for his trading application
Yacine is a WinDev developer at an electrical equipment trading SME in Oran. He must deliver a management application (customers, products, orders, invoices, stock). He starts by listing the “things” of the business: a Client, a Produit (cable, circuit breaker, panel…), a Commande and its lines. He turns each into a file, one per entity. He then describes the items with the right type: Nom as text, PrixUnitaireHT as currency, DateCommande as date — not everything as text. He gives each file a primary key (automatic identifier). Finally he draws the relationship: a Client has several Commandes, a Commande belongs to a single Client. He is about to copy the customer name into each order, then changes his mind: this information must live only once, in the Client file. Yacine has built the foundation of his application: a coherent analysis with no duplication.
Standalone case for this section: it returns in the course, diagram, script and 48h challenge of section 1.1.
1. From entities to files
The analysis process is always the same. First identify the ENTITIES of the business: the “things” the application handles (the Client, the Produit, the Commande). Each entity becomes a FILE. Yacine thus creates the Client, Produit, Commande and LigneCommande files.
Simple rule: one entity = one file. Two concepts are never mixed in the same file — product and order are two distinct things, therefore two files.
2. Well-typed items
Next we describe the ITEMS of each file: the elementary pieces of information (Nom, Ville, PrixUnitaireHT, DateCommande). For each one, we choose a clear NAME, a suitable TYPE and a SIZE.
The choice of type is crucial: a date is stored as a date type (not as text), an amount as currency (to calculate, sort, total). Putting everything as text makes sorting wrong, calculations impossible and checks ineffective.
3. Primary keys and relationships
Each file needs a PRIMARY KEY: the unique identifier of each record. In practice, an automatic identifier generated by the engine is very often used — simple, stable and reliable.
Finally, we draw the RELATIONSHIPS, which express the business rules. The most common is one-to-many (1,n): a Client has several Commandes. The file on the “many” side (Commande) carries an item pointing to the other's key: this is the foreign key. Integrity rules then decide the behavior on deletion (forbid or cascade delete) to protect consistency.
🔎 Concrete example — 🔎 Concrete example — The “NegoceElec” analysis
The data skeleton Yacine draws in the analysis editor:
// 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 → interditReading: Yacine types each item (currency, date, integer) and links Commande to Client through the IDClient key, without copying the name.
Reflex: one entity = one file; one piece of information = one place; the rest goes through the relationship.
Section vocabulary
- Entity → File
- Each “thing” of the business (Client, Produit, Commande) becomes a file in the analysis; one entity = one file, without mixing concepts.
Simple example: Yacine creates a Client file, a Produit file and a Commande file.
What it is not: putting everything into a single “Misc” file that mixes customers and products.
Reflex: a business concept → a file.
- Item and type
- Elementary information of a file (Nom, Prix, Date), declared with a clear name, a suitable type and a reasonable size.
Simple example: Yacine stores PrixUnitaireHT as currency and DateCommande as date.
What it is not: storing a price and a date as text, then trying to calculate or sort.
Reflex: correct type → correct calculations and sorting.
- Primary key
- Item identifying each record uniquely and stably; in practice, an automatic identifier generated by the engine.
Simple example: Yacine gives the Client file an IDClient as automatic identifier.
What it is not: using a business code that changes (e-mail, renumbered customer code) as a key.
Reflex: primary key → automatic identifier.
- 1,n relationship (one-to-many)
- Most common relation: a Client has SEVERAL Commandes, a Commande belongs to a SINGLE Client; the “many” side carries the foreign key.
Simple example: The Client (1,n) Commande relationship via IDClient carries Yacine's business rule.
What it is not: copying the customer name into each order instead of linking.
Reflex: two linked files → a foreign key, not a copy.
- Integrity rule
- Engine behavior when deleting or modifying a linked record (forbid, cascade delete), to protect consistency.
Simple example: Yacine forbids deleting a customer who still has orders.
What it is not: allowing a customer to be deleted while leaving orphan orders.
Reflex: linked deletion → an integrity rule.
In practice — In practice — Building the Client / Commande analysis
- List the business ENTITIES and create a FILE for each one (Client, Produit, Commande, LigneCommande).
- Describe the ITEMS with the right TYPE (text for a name, date for a date, currency for a price) and a reasonable size.
- Give each file a PRIMARY KEY (automatic identifier preferably).
- Draw the RELATIONSHIPS according to business rules (a Client → several Commandes), define the INTEGRITY RULES, then GENERATE the analysis.
Step-by-step script — drawing the analysis like Yacine (5 min)
1) List the trading entities (Client, Produit, Commande, LigneCommande) and create one file per entity. 2) Describe the items with the right type (Nom as text, PrixUnitaireHT as currency, DateCommande as date). 3) Add a primary key to each file (automatic identifier). 4) Draw the Client (1) → Commande (n) relationship with IDClient as foreign key, without copying the customer name. 5) Set the integrity rules then generate the analysis.
Keep this analysis: it will feed the windows (1.2), the WLangage (1.3), the linked controls (1.4) and the RAD (1.5).
Copy-paste template — Yacine's analysis checklist
[ ] One file per business entity (Client, Produit, Commande…)
[ ] Items clearly named and well TYPED (date, currency…)
[ ] One primary key per file (automatic identifier preferably)
[ ] No information repeated from one file to another
[ ] Relationships drawn (Client 1,n Commande via foreign key)
[ ] Integrity rules decided (deletion forbidden / cascade)
[ ] Analysis generatedSmall structure
Yacine starts with three files (Client, Produit, Commande) and still keeps a clean primary key and relationship.
Order lines
To handle several products per order, Yacine adds LigneCommande, linked to both Commande and Produit.
Business key
When management imposes an official product reference, Yacine keeps it as an indexed item but keeps the automatic identifier as primary key.
Strict integrity
On stock, Yacine forbids deleting a product still referenced in an order line.
✓ Best practices
- One file per business entity, without mixing concepts.
- Always type the items (date, currency, integer).
- Store each piece of information only once and link it through a relationship.
✗ Common pitfalls
- Copying data (customer name) into several files.
- Putting everything as text: wrong sorting and impossible calculations.
- Choosing an unstable primary key (business code that changes).
Key takeaways
- Process: identify the ENTITIES (→ files), describe the ITEMS (name + type + size), define the PRIMARY KEY, draw the RELATIONSHIPS, then GENERATE the analysis.
- The choice of TYPE is crucial: a date as date, an amount as currency — never as text.
- The most frequent relationship is one-to-many (1,n); the “many” side carries the foreign key and integrity rules protect consistency.
- Fundamental principle: NEVER repeat information; refer to it through the relationship.
48h challenge — apply it tomorrow
Take a domain you know (or Yacine's trading business) and draw its analysis: list the entities, create a file for each, type the items, add a primary key and draw at least one 1,n relationship. Write in one sentence why information is never copied from one file to another.
- I can turn business entities into analysis files.
- I know how to type items and choose a primary key.
- I know how to draw a 1,n relationship without repeating information.
Frequently asked questions
Why should information not be repeated across several files?
Because any repeated data eventually diverges: changed in one place and not the other, it produces inconsistencies, wrong totals and bugs that are hard to fix. If a customer's name is stored in Client AND copied into each Commande, a name change requires updating everything everywhere — and one oversight displays two different names for the same customer. The role of relationships is precisely to avoid this duplication: the information lives only once, and the other files refer to it by key.
Should I use an automatic key or a “business” key?
Almost always favor the automatic identifier: it is unique by construction, stable (no business meaning, hence no reason to change) and efficient for indexes and joins. “Business” keys (customer code, e-mail, reference) seem convenient but change, may be duplicated or missing at creation — and modifying a primary key forces you to propagate the change to all linked files. For Yacine, the automatic identifier is the default key.
Which fundamental principle is respected when creating an analysis?