Normalisation et adaptation d’un schéma relationnel

Introduction

Dans la leçon précédente, nous avons appris à interpréter un schéma relationnel : repérer les relations, les clés primaires, les clés étrangères et les dépendances fonctionnelles. Cette base est indispensable, car un schéma relationnel ne doit pas seulement être lisible : il doit aussi être correct au regard du modèle relationnel et adaptable lorsque les règles de gestion évoluent.

Cette leçon est donc centrée sur deux compétences essentielles :

• vérifier les règles du modèle relationnel ;
• adapter un schéma relationnel au changement d’une règle de gestion.

Autrement dit, il ne s’agit plus seulement de lire une base de données, mais de juger si sa structure est saine, cohérente, sans redondances inutiles, et capable d’évoluer sans provoquer d’anomalies.

Objectifs d’apprentissage

À l’issue de cette leçon, vous devrez être capable de :

• rappeler le rôle de la structuration des données dans le système d’information ;
• vérifier qu’un schéma respecte les principales règles du modèle relationnel ;
• comprendre pourquoi la normalisation est nécessaire ;
• apprécier si un schéma est cohérent jusqu’à la troisième forme normale (3FN) ;
• repérer les défauts de conception : redondances, anomalies de mise à jour, dépendances mal placées ;
• adapter un schéma relationnel lorsqu’une règle de gestion change.

1. La place de cette compétence dans la gestion des données du système d’information

La base de données n’est pas un simple stockage passif. Dans un système d’information de gestion, elle constitue une structure organisée de données destinée à soutenir les processus de l’organisation : ventes, achats, ressources humaines, facturation, suivi client, etc.

Quand la base est mal conçue, les conséquences sont immédiates :

• informations dupliquées ;
• incohérences entre plusieurs enregistrements ;
• difficulté de mise à jour ;
• erreurs dans les traitements ;
• perte de fiabilité du système d’information.

À l’inverse, une base bien structurée permet :

• une meilleure qualité de l’information ;
• une réduction des redondances ;
• une maintenance plus simple ;
• une meilleure adaptation aux évolutions de l’organisation.

La compétence « Structurer et manipuler des données via les bases de données » suppose donc d’aller au-delà du simple usage d’un SGBDR. Il faut savoir concevoir, contrôler et faire évoluer la structure.

2. Rappel : qu’est-ce qu’un schéma relationnel ?

Un schéma relationnel décrit l’organisation logique d’une base de données relationnelle.

Il précise notamment :

• les relations (souvent assimilées aux tables) ;
• les attributs de chaque relation ;
• les clés primaires ;
• les clés étrangères ;
• parfois, implicitement ou explicitement, les dépendances fonctionnelles.

Exemple simple

On veut gérer des commandes clients.

Schéma initial :

• CLIENT(NumClient, NomClient, Ville)
• COMMANDE(NumCommande, DateCommande, NumClient)

Ici :

• NumClient est la clé primaire de CLIENT ;
• NumCommande est la clé primaire de COMMANDE ;
• NumClient dans COMMANDE est une clé étrangère vers CLIENT.

Ce schéma semble simple, mais la vraie question est : est-il correctement structuré ?

3. Vérifier les règles du modèle relationnel

Vérifier les règles du modèle relationnel consiste à s’assurer que la structure proposée est compatible avec les principes fondamentaux d’une base de données relationnelle.

3.1 Une relation représente un ensemble de données homogènes

Chaque relation doit correspondre à un type d’objet de gestion ou à une association cohérente.

Exemples :

• une relation CLIENT pour les clients ;
• une relation PRODUIT pour les produits ;
• une relation FACTURE pour les factures.

Une relation mal conçue mélange souvent plusieurs réalités différentes.

Mauvais exemple

• GESTION(NumClient, NomClient, NumProduit, LibelleProduit, DateCommande)

Cette relation mélange :

• les clients ;
• les produits ;
• les commandes.

Le problème n’est pas seulement esthétique. Cela crée des répétitions massives et rend la maintenance difficile.

3.2 Chaque occurrence doit être identifiable de manière unique

Une relation doit posséder une clé primaire permettant d’identifier sans ambiguïté chaque ligne.

Pourquoi ?

Sans identifiant unique :

• on ne sait pas distinguer deux occurrences proches ;
• les mises à jour deviennent risquées ;
• les liens avec d’autres relations sont fragiles.

Exemple

Dans la relation :

• SALARIE(Matricule, Nom, Prenom, Service)

Matricule est une bonne clé primaire, car elle identifie un salarié de façon unique.

En revanche, choisir (Nom, Prenom) serait dangereux : plusieurs salariés peuvent porter les mêmes nom et prénom.

3.3 Les attributs doivent être atomiques

Dans le modèle relationnel, un attribut doit contenir une valeur élémentaire et non une liste ou un groupe de valeurs.

Mauvais exemple

• CLIENT(NumClient, NomClient, Telephones)

Si Telephones contient :

• « 01 45 00 00 00 / 06 11 22 33 44 »

alors l’attribut n’est pas atomique.

Pourquoi est-ce un problème ?

Parce qu’on ne peut pas manipuler correctement une liste dans une cellule relationnelle :

• recherche difficile ;
• tri impossible de manière fiable ;
• mise à jour imprécise ;
• violation de la logique relationnelle.

3.4 Les attributs d’une relation décrivent la clé, toute la clé, rien que la clé

Cette idée est au cœur de la normalisation.

Dans une relation, les attributs non clés doivent dépendre correctement de la clé primaire :

• pas seulement d’une partie de la clé ;
• pas d’un autre attribut non clé.

C’est ce qui permet d’éviter les anomalies.

3.5 Les liens entre relations doivent être cohérents

Les clés étrangères assurent la cohérence entre les relations.

Exemple :

• CLIENT(NumClient, NomClient)
• COMMANDE(NumCommande, DateCommande, NumClient)

Ici, NumClient dans COMMANDE doit correspondre à une valeur existante dans CLIENT.

Cette logique garantit l’intégrité référentielle. Même si sa mise en œuvre technique sera surtout exploitée lors de la manipulation des données, sa vérification commence dès la conception du schéma.

4. Pourquoi normaliser un schéma relationnel ?

La normalisation est une méthode de structuration qui vise à produire un schéma :

• sans redondances inutiles ;
• sans anomalies de mise à jour ;
• plus cohérent avec les règles de gestion.

4.1 Les problèmes d’un schéma non normalisé

Un schéma mal normalisé crée trois grands types d’anomalies.

A. Anomalie d’insertion

On ne peut pas enregistrer une information sans en créer une autre artificiellement.

Exemple : si les données client et commande sont dans une seule relation, on ne peut pas enregistrer un nouveau client tant qu’il n’a pas passé de commande.

B. Anomalie de mise à jour

Une information répétée à plusieurs endroits doit être modifiée partout.

Exemple : si la ville du client est répétée sur chaque commande, un changement d’adresse impose plusieurs mises à jour.

C. Anomalie de suppression

La suppression d’une ligne fait disparaître involontairement une autre information utile.

Exemple : supprimer la dernière commande d’un client peut faire disparaître aussi la fiche du client.

4.2 La logique de la normalisation

Normaliser, c’est décomposer intelligemment les relations pour que chaque donnée soit stockée au bon endroit.

Le but n’est pas de multiplier les tables sans raison. Le but est de faire en sorte que :

• chaque relation ait un sens clair ;
• chaque attribut soit à sa place ;
• les dépendances fonctionnelles soient respectées.

5. Les dépendances fonctionnelles : base du raisonnement

Pour apprécier la normalisation, il faut raisonner à partir des dépendances fonctionnelles.

Une dépendance fonctionnelle signifie qu’une donnée détermine une autre.

Notation :

• A -> B

signifie : si l’on connaît A, alors on connaît B de manière unique.

Exemple

Dans une relation CLIENT :

• NumClient -> NomClient, Ville

Cela signifie qu’un numéro de client détermine son nom et sa ville.

Exemple avec clé composée

Dans une relation LIGNE_COMMANDE :

• (NumCommande, RefProduit) -> Quantite

La quantité commandée dépend du couple :

• numéro de commande ;
• référence produit.

Elle ne dépend ni du seul numéro de commande, ni de la seule référence produit.

6. Apprécier la normalisation jusqu’à la troisième forme normale

Le programme précise que la normalisation est étudiée jusqu’à la troisième forme normale, sans exiger de distinguer formellement 1FN, 2FN et 3FN dans tous les détails. En pratique, il faut surtout être capable de dire si un schéma est normalisé ou non, et de le justifier.

Nous allons néanmoins présenter progressivement la logique.

6.1 Première exigence : des attributs atomiques et une structure relationnelle correcte

Un schéma ne peut pas être considéré comme normalisé si des attributs contiennent :

• des listes ;
• des groupes répétés ;
• des valeurs multiples dans une même cellule.

Exemple non satisfaisant

• ETUDIANT(NumEtudiant, Nom, Prenom, NotesUE)

Si NotesUE contient plusieurs notes, l’attribut n’est pas atomique.

Correction possible

• ETUDIANT(NumEtudiant, Nom, Prenom)
• RESULTAT(NumEtudiant, CodeUE, Note)

Ici, chaque donnée est élémentaire.

6.2 Deuxième exigence : pas de dépendance partielle à une clé composée

Lorsqu’une relation a une clé primaire composée, aucun attribut non clé ne doit dépendre seulement d’une partie de cette clé.

Exemple

Relation :

• INSCRIPTION(NumEtudiant, CodeUE, NomEtudiant, LibelleUE, Note)

Supposons les dépendances suivantes :

• NumEtudiant -> NomEtudiant
• CodeUE -> LibelleUE
• (NumEtudiant, CodeUE) -> Note

Le problème est clair :

• NomEtudiant dépend seulement de NumEtudiant ;
• LibelleUE dépend seulement de CodeUE.

Ils ne dépendent donc pas de toute la clé composée (NumEtudiant, CodeUE).

Conséquence

La relation n’est pas correctement normalisée.

Décomposition correcte

• ETUDIANT(NumEtudiant, NomEtudiant)
• UE(CodeUE, LibelleUE)
• INSCRIPTION(NumEtudiant, CodeUE, Note)

Cette décomposition supprime les dépendances partielles.

6.3 Troisième exigence : pas de dépendance transitive

Une dépendance transitive apparaît lorsqu’un attribut non clé dépend d’un autre attribut non clé, lui-même dépendant de la clé.

Exemple

• SALARIE(Matricule, NomSalarie, CodeService, NomService)

Dépendances :

• Matricule -> NomSalarie, CodeService
• CodeService -> NomService

Donc indirectement :

• Matricule -> NomService

Mais NomService ne dépend pas directement du salarié : il dépend du service.

Pourquoi est-ce gênant ?

Parce que le nom du service sera répété pour tous les salariés du même service.

Décomposition correcte

• SERVICE(CodeService, NomService)
• SALARIE(Matricule, NomSalarie, CodeService)

On supprime ainsi la dépendance transitive.

7. Méthode pratique pour vérifier un schéma relationnel

Voici une méthode simple et rigoureuse.

Étape 1 : identifier la clé primaire de chaque relation

Il faut d’abord savoir ce qui identifie une occurrence.

Questions à se poser :

• quelle est la clé primaire ?
• est-elle simple ou composée ?
• identifie-t-elle vraiment chaque ligne ?

Étape 2 : lister les dépendances fonctionnelles utiles

Pour chaque relation, repérez :

• ce que la clé détermine ;
• si certains attributs dépendent seulement d’une partie de la clé ;
• si certains attributs dépendent d’autres attributs non clés.

Étape 3 : repérer les redondances

Si une information est répétée dans de nombreuses lignes, demandez-vous :

• dépend-elle vraiment de la clé de la relation ?
• ne devrait-elle pas être placée dans une autre relation ?

Étape 4 : rechercher les anomalies possibles

Posez-vous trois questions :

• peut-on insérer une information indépendamment ?
• une mise à jour imposera-t-elle plusieurs modifications ?
• une suppression risque-t-elle d’effacer une information utile ?

Étape 5 : proposer une décomposition

Si le schéma n’est pas satisfaisant :

• créer des relations distinctes pour les entités stables ;
• conserver les associations nécessaires via les clés étrangères ;
• vérifier que la nouvelle structure respecte mieux les dépendances fonctionnelles.

8. Étude complète d’un exemple de normalisation

Prenons une relation unique issue d’une conception trop intuitive.

Schéma initial

• VENTE(NumCommande, DateCommande, NumClient, NomClient, VilleClient, RefProduit, LibelleProduit, PrixUnitaire, Quantite)

Dépendances fonctionnelles supposées

• NumCommande -> DateCommande, NumClient
• NumClient -> NomClient, VilleClient
• RefProduit -> LibelleProduit, PrixUnitaire
• (NumCommande, RefProduit) -> Quantite

Analyse

La relation mélange :

• les commandes ;
• les clients ;
• les produits ;
• les lignes de commande.

Cela entraîne des répétitions :

• le nom du client est répété pour chaque ligne de commande ;
• la ville du client aussi ;
• le libellé du produit et son prix sont répétés dans chaque commande où il apparaît.

Anomalies

• mise à jour : si un produit change de libellé, il faut modifier plusieurs lignes ;
• insertion : impossible d’ajouter un produit sans commande ;
• suppression : supprimer la dernière ligne d’un produit peut faire disparaître l’information produit.

Décomposition proposée

• CLIENT(NumClient, NomClient, VilleClient)
• PRODUIT(RefProduit, LibelleProduit, PrixUnitaire)
• COMMANDE(NumCommande, DateCommande, NumClient)
• LIGNE_COMMANDE(NumCommande, RefProduit, Quantite)

Pourquoi cette solution est meilleure

• les données client sont stockées une seule fois ;
• les données produit sont stockées une seule fois ;
• la commande contient ses informations propres ;
• la ligne de commande gère l’association entre commande et produit.

On obtient un schéma cohérent, plus proche des objets de gestion réels.

9. Adapter un schéma relationnel au changement d’une règle de gestion

C’est la seconde grande compétence de la leçon.

Un schéma n’est jamais figé. Les règles de gestion évoluent avec l’organisation. Une base de données doit donc pouvoir être adaptée sans perdre sa cohérence.

9.1 Qu’est-ce qu’une règle de gestion ?

Une règle de gestion est une contrainte ou un principe qui décrit le fonctionnement de l’organisation.

Exemples :

• un client peut passer plusieurs commandes ;
• une commande comporte une ou plusieurs lignes ;
• un salarié appartient à un seul service ;
• un produit peut être fourni par plusieurs fournisseurs.

Quand une règle change, le schéma doit parfois être modifié.

9.2 Pourquoi une adaptation est-elle nécessaire ?

Parce qu’un schéma relationnel traduit les règles de gestion en structure de données.

Si les règles changent mais que le schéma ne change pas :

• la base ne représente plus correctement la réalité ;
• les traitements deviennent faux ;
• les données perdent en fiabilité.

10. Méthode pour adapter un schéma relationnel

Étape 1 : identifier précisément la nouvelle règle de gestion

Il faut d’abord comparer :

• l’ancienne règle ;
• la nouvelle règle.

Exemple :

• ancienne règle : « un produit est fourni par un seul fournisseur » ;
• nouvelle règle : « un produit peut être fourni par plusieurs fournisseurs ».

Ce changement n’est pas mineur : il modifie la cardinalité de la relation.

Étape 2 : repérer les relations et attributs impactés

La nouvelle règle peut affecter :

• une clé primaire ;
• une clé étrangère ;
• une relation entière ;
• la nécessité de créer une nouvelle relation.

Étape 3 : vérifier si la structure actuelle devient incohérente

On se demande :

• la relation actuelle permet-elle encore de représenter correctement la réalité ?
• crée-t-elle maintenant des répétitions ou des impossibilités ?

Étape 4 : modifier le schéma

Les adaptations les plus fréquentes sont :

• ajout d’une relation ;
• déplacement d’un attribut ;
• modification d’une clé ;
• remplacement d’un lien direct par une relation d’association.

Étape 5 : revérifier la cohérence relationnelle

Après adaptation, il faut à nouveau contrôler :

• les clés primaires ;
• les clés étrangères ;
• les dépendances fonctionnelles ;
• la normalisation.

11. Cas d’adaptation n°1 : passage d’une relation 1,N à une relation N,N

Situation initiale

Règle de gestion :

• « Un produit est fourni par un seul fournisseur. »

Schéma :

• FOURNISSEUR(NumFournisseur, NomFournisseur)
• PRODUIT(RefProduit, LibelleProduit, NumFournisseur)

Ici, NumFournisseur dans PRODUIT suffit.

Nouvelle règle de gestion

• « Un produit peut être fourni par plusieurs fournisseurs. »

Le schéma initial ne convient plus, car un seul attribut NumFournisseur dans PRODUIT ne permet qu’un seul fournisseur par produit.

Adaptation

Il faut créer une relation d’association :

• FOURNISSEUR(NumFournisseur, NomFournisseur)
• PRODUIT(RefProduit, LibelleProduit)
• FOURNIR(NumFournisseur, RefProduit)

Pourquoi ?

Parce qu’on passe d’une relation 1,N à une relation N,N.

Si l’on avait tenté de conserver plusieurs fournisseurs dans un seul attribut, on aurait violé l’atomicité et la logique relationnelle.

12. Cas d’adaptation n°2 : déplacement d’un attribut devenu indépendant

Situation initiale

• SALARIE(Matricule, NomSalarie, CodeService, NomService)

Tant que l’on ne s’interroge pas, on peut croire ce schéma acceptable.

Nouvelle analyse de la règle de gestion

On précise :

• « Un service possède un code et un nom propres, indépendants des salariés qui y sont affectés. »

Cette règle révèle que NomService dépend de CodeService, pas du salarié.

Adaptation

• SERVICE(CodeService, NomService)
• SALARIE(Matricule, NomSalarie, CodeService)

Intérêt

On isole une entité de gestion autonome.

13. Cas d’adaptation n°3 : ajout d’une nouvelle règle sur les coordonnées multiples

Situation initiale

• CLIENT(NumClient, NomClient, Telephone)

Nouvelle règle de gestion

• « Un client peut avoir plusieurs numéros de téléphone. »

Le schéma initial n’est plus adapté.

Mauvaise solution

Conserver un seul attribut Telephone contenant plusieurs valeurs.

Bonne solution

• CLIENT(NumClient, NomClient)
• TELEPHONE_CLIENT(NumClient, Telephone)

Selon le contexte, la clé primaire de TELEPHONE_CLIENT peut être composée de (NumClient, Telephone).

Pourquoi cette solution est correcte

• chaque numéro devient une donnée atomique ;
• la pluralité est gérée relationnellement ;
• la structure reste cohérente.

14. Cas d’adaptation n°4 : apparition d’un nouvel objet de gestion

Situation initiale

• COMMANDE(NumCommande, DateCommande, NumClient, NomClient)

Nouvelle règle de gestion

• « Le client possède désormais un niveau de fidélité et une date d’adhésion au programme relationnel. »

Ce changement peut révéler que le client doit être traité comme une entité autonome, si ce n’était pas déjà fait.

Adaptation

• CLIENT(NumClient, NomClient, NiveauFidelite, DateAdhesion)
• COMMANDE(NumCommande, DateCommande, NumClient)

Logique

Dès qu’un ensemble d’attributs décrit un objet de gestion stable, il devient souvent pertinent d’en faire une relation propre.

15. Comment justifier qu’un schéma doit être modifié ?

Dans un devoir ou une étude de cas, il ne suffit pas de proposer une nouvelle structure. Il faut justifier.

Une bonne justification repose sur quatre idées.

15.1 La nouvelle règle de gestion n’est plus représentable correctement

Exemple :

Le schéma initial suppose un seul fournisseur par produit. La nouvelle règle autorise plusieurs fournisseurs. Il faut donc remplacer l’attribut NumFournisseur dans PRODUIT par une relation d’association.

15.2 Le schéma actuel crée une redondance ou une anomalie

Exemple :

Le nom du service est répété pour chaque salarié. Cela crée un risque d’incohérence en cas de changement de libellé du service.

15.3 Une dépendance fonctionnelle n’est pas respectée

Exemple :

NomService dépend de CodeService et non de Matricule. L’attribut doit donc être déplacé dans une relation SERVICE.

15.4 La nouvelle structure améliore la cohérence du modèle relationnel

Exemple :

La décomposition permet de respecter l’atomicité, d’éviter les dépendances transitives et de faciliter les mises à jour.

16. Étude guidée complète

Prenons un cas plus riche.

Schéma proposé

• INSCRIPTION(NumEtudiant, NomEtudiant, CodeFormation, LibelleFormation, DateInscription, NomResponsableFormation)

Règles de gestion implicites

• un étudiant est identifié par NumEtudiant ;
• une formation est identifiée par CodeFormation ;
• une inscription relie un étudiant à une formation à une date donnée ;
• chaque formation a un libellé et un responsable.

Étape 1 : identifier le problème

La relation mélange :

• l’étudiant ;
• la formation ;
• l’inscription.

Étape 2 : dépendances fonctionnelles

• NumEtudiant -> NomEtudiant
• CodeFormation -> LibelleFormation, NomResponsableFormation
• (NumEtudiant, CodeFormation) -> DateInscription

Étape 3 : diagnostic

NomEtudiant dépend seulement de NumEtudiant.

LibelleFormation et NomResponsableFormation dépendent seulement de CodeFormation.

Donc la relation n’est pas correctement normalisée.

Étape 4 : décomposition

• ETUDIANT(NumEtudiant, NomEtudiant)
• FORMATION(CodeFormation, LibelleFormation, NomResponsableFormation)
• INSCRIPTION(NumEtudiant, CodeFormation, DateInscription)

Étape 5 : nouvelle règle de gestion

On ajoute :

• « Une formation peut avoir plusieurs responsables selon les années. »

Le schéma FORMATION devient insuffisant si NomResponsableFormation dépend aussi d’une année.

Nouvelle adaptation

• FORMATION(CodeFormation, LibelleFormation)
• RESPONSABILITE_FORMATION(CodeFormation, Annee, NomResponsableFormation)

On voit ici que l’évolution des règles de gestion entraîne une évolution du schéma.

17. Erreurs fréquentes à éviter

17.1 Confondre table pratique et relation bien conçue

Une table unique peut sembler plus simple au départ, mais elle devient vite ingérable. La simplicité apparente n’est pas une bonne conception.

17.2 Multiplier les attributs répétitifs

Exemple :

• Telephone1, Telephone2, Telephone3

Cette solution est souvent le signe qu’une pluralité de valeurs n’a pas été correctement modélisée.

17.3 Laisser dans une relation des attributs qui dépendent d’autre chose que de la clé

C’est le cœur des problèmes de normalisation.

17.4 Adapter sans revérifier les clés

Quand une règle change, il faut toujours se demander :

• la clé primaire reste-t-elle pertinente ?
• faut-il une clé composée ?
• faut-il créer une relation d’association ?

18. Mémo de méthode

Pour vérifier un schéma relationnel

1. Identifier chaque relation.
2. Repérer la clé primaire.
3. Vérifier que les attributs sont atomiques.
4. Rechercher les dépendances fonctionnelles.
5. Vérifier que les attributs non clés dépendent de la clé, de toute la clé, et pas d’un autre attribut non clé.
6. Détecter les redondances et anomalies.

Pour adapter un schéma à une nouvelle règle de gestion

1. Reformuler précisément la nouvelle règle.
2. Identifier les relations impactées.
3. Vérifier si le schéma actuel permet encore de représenter la réalité.
4. Modifier la structure : ajout, suppression, décomposition ou nouvelle relation d’association.
5. Revérifier la cohérence du modèle relationnel.

19. Points à retenir

• La structuration des données est une composante essentielle de la gestion des données du système d’information.
• Dans une base de données relationnelle, un schéma doit respecter les règles du modèle relationnel.
• Une relation doit être cohérente, ses occurrences doivent être identifiables, et ses attributs doivent être atomiques.
• La normalisation vise à réduire les redondances et à éviter les anomalies d’insertion, de mise à jour et de suppression.
• Pour apprécier un schéma jusqu’à la troisième forme normale, il faut raisonner à partir des dépendances fonctionnelles.
• Un attribut non clé ne doit pas dépendre seulement d’une partie d’une clé composée, ni d’un autre attribut non clé.
• Quand une règle de gestion change, le schéma relationnel doit parfois être adapté : ajout d’une relation, déplacement d’un attribut, création d’une relation d’association, modification de clé.
• Un bon schéma est un schéma fidèle à la réalité de gestion, cohérent, évolutif et maintenable.

Conclusion

Structurer une base de données ne consiste pas seulement à créer des tables. Il faut construire un schéma relationnel qui reflète correctement les objets de gestion et leurs liens. La vérification des règles du modèle relationnel et l’appréciation de la normalisation permettent d’éviter de nombreux dysfonctionnements futurs.

L’enjeu est très concret : une mauvaise structure produit de mauvaises données, et de mauvaises données dégradent tout le système d’information. À l’inverse, une structure bien pensée facilite les requêtes, les mises à jour, les contrôles et l’évolution du système.

Dans la suite logique du programme, cette maîtrise de la structure relationnelle servira directement à la manipulation des données, notamment pour écrire des requêtes fiables et pertinentes dans un SGBDR.