Modèle relationnel et schéma de base de données

Introduction

Dans cette leçon, on entre dans le cœur de la gestion des données du système d’information : la manière dont une organisation structure ses données pour pouvoir les stocker, les retrouver et les exploiter de façon fiable.

Après avoir vu, dans les leçons précédentes, le rôle global du système d’information, ses acteurs, son infrastructure et ses solutions applicatives, il faut maintenant comprendre comment les données sont organisées dans une base de données. Cette étape est essentielle, car un système d’information performant ne repose pas seulement sur des logiciels ou des réseaux : il repose aussi sur une structure de données cohérente.

L’objectif ici est centré sur un point précis du programme : structurer une base de données et surtout interpréter un schéma relationnel.

Autrement dit, il s’agit d’apprendre à lire la représentation d’une base de données pour répondre à des questions comme :

• quelles sont les tables ?
• quelles informations chaque table contient-elle ?
• quelle est la clé primaire de chaque table ?
• où se trouvent les clés étrangères ?
• comment les tables sont-elles liées ?
• la structure paraît-elle cohérente ?

Cette compétence est fondamentale, car avant d’écrire des requêtes ou de modifier des données, il faut d’abord comprendre l’architecture logique de la base.

Objectifs d’apprentissage

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

• situer le modèle relationnel dans la gestion des données du système d’information ;
• comprendre ce qu’est une base de données relationnelle ;
• identifier une relation dans un schéma relationnel ;
• repérer une clé primaire et expliquer son rôle ;
• repérer une clé étrangère et expliquer le lien entre deux relations ;
• lire et interpréter un schéma relationnel simple de gestion ;
• vérifier la cohérence générale d’une structuration relationnelle.

1. La gestion des données du système d’information

1.1 Pourquoi structurer les données ?

Dans une organisation, les données sont nombreuses :

• données sur les clients ;
• données sur les fournisseurs ;
• données sur les produits ;
• données sur les commandes ;
• données sur les salariés ;
• données sur les factures ;
• données sur les règlements.

Si ces données sont mal organisées, plusieurs difficultés apparaissent rapidement :

• doublons ;
• incohérences ;
• informations manquantes ;
• difficultés de recherche ;
• erreurs de mise à jour ;
• perte de fiabilité dans les traitements.

Structurer une base de données consiste donc à organiser les informations de manière logique pour permettre :

• une saisie cohérente ;
• un stockage ordonné ;
• une consultation rapide ;
• des traitements fiables ;
• une exploitation efficace par les applications de gestion.

1.2 La place des bases de données dans le système d’information

Une base de données n’est pas un simple fichier de stockage. Elle constitue un élément central du système d’information.

Elle permet de :

• centraliser les informations utiles ;
• partager les mêmes données entre plusieurs acteurs ;
• éviter la ressaisie inutile ;
• alimenter les processus de gestion ;
• sécuriser et fiabiliser les traitements.

Dans une entreprise, par exemple, une même base peut être utilisée pour :

• enregistrer les clients ;
• suivre les commandes ;
• générer les factures ;
• analyser les ventes.

Cela suppose que les données soient organisées selon une logique stable et compréhensible. C’est précisément le rôle du modèle relationnel.

2. Structurer et manipuler des données via les bases de données

Le programme distingue deux dimensions complémentaires :

• structurer une base de données ;
• manipuler les données qu’elle contient.

Dans cette leçon, nous nous concentrons sur la première étape : la structuration, à travers l’interprétation d’un schéma relationnel.

Pourquoi commencer par là ? Parce qu’on ne peut pas manipuler correctement des données si l’on ne comprend pas d’abord :

• où elles sont stockées ;
• comment elles sont regroupées ;
• comment les tables communiquent entre elles.

La lecture d’un schéma relationnel est donc un préalable indispensable à tout travail ultérieur sur une base de données.

3. Qu’est-ce qu’une base de données relationnelle ?

3.1 L’idée générale

Une base de données relationnelle organise les données sous forme de relations.

Dans la pratique, une relation est représentée par une table.

Chaque table contient :

• des colonnes : elles représentent les caractéristiques des données ;
• des lignes : elles représentent les enregistrements.

3.2 Exemple simple

Prenons une table CLIENT.

| IdClient | NomClient | Ville | |---|---|---| | C001 | Martin SA | Lyon | | C002 | Dupont SARL | Lille | | C003 | Nova Conseil | Paris |

Dans cette table :

• IdClient, NomClient, Ville sont des colonnes ;
• chaque ligne correspond à un client.

Autre table : COMMANDE.

| NumCommande | DateCommande | IdClient | |---|---|---| | 1001 | 05/01/2026 | C001 | | 1002 | 07/01/2026 | C003 | | 1003 | 08/01/2026 | C001 |

Cette deuxième table permet d’enregistrer les commandes. On voit déjà apparaître un lien avec la table CLIENT grâce à IdClient.

4. La notion de relation

4.1 Définition opérationnelle

Dans le cadre du modèle relationnel, une relation correspond à une structure de données homogène décrivant un ensemble d’objets de même nature.

Exemples :

• une relation CLIENT ;
• une relation PRODUIT ;
• une relation FACTURE ;
• une relation SALARIÉ.

Chaque relation regroupe des informations portant sur un même sujet.

4.2 Pourquoi séparer les données en plusieurs relations ?

On pourrait être tenté de tout mettre dans une seule grande table. Mais ce serait une mauvaise solution.

Par exemple, si on mélange clients, commandes et produits dans une seule table, on répète souvent les mêmes informations :

• le nom du client est répété à chaque commande ;
• la ville du client est répétée ;
• le libellé du produit est répété à chaque vente.

Cette répétition pose plusieurs problèmes :

• risque d’erreur lors de la saisie ;
• difficulté de mise à jour ;
• incohérences possibles ;
• surcharge inutile.

Le modèle relationnel cherche au contraire à répartir les données dans plusieurs relations bien définies, puis à les relier entre elles.

4.3 Comment reconnaître une relation dans un schéma relationnel ?

Dans un schéma relationnel, chaque relation est généralement présentée sous la forme :

NOM_RELATION (attribut1, attribut2, attribut3, ...)

Exemple :

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

Le nom avant les parenthèses désigne la relation. Les éléments entre parenthèses sont les attributs.

5. Les attributs d’une relation

5.1 Définition

Un attribut est une donnée élémentaire décrivant les objets représentés dans une relation.

Exemples dans CLIENT :

• IdClient ;
• NomClient ;
• Ville.

5.2 Rôle des attributs

Les attributs permettent de caractériser chaque enregistrement.

Par exemple, pour un client, on peut avoir :

• un identifiant ;
• une raison sociale ;
• une adresse ;
• une ville ;
• un code postal.

Le choix des attributs est important :

• s’il manque un attribut utile, l’information sera incomplète ;
• s’il y a trop d’attributs mal choisis, la structure devient lourde et confuse.

5.3 Lecture dans un schéma relationnel

Quand on lit un schéma relationnel, il faut se poser systématiquement les questions suivantes :

• quel est le sujet de la relation ?
• quels attributs décrivent ce sujet ?
• certains attributs servent-ils à identifier la ligne ?
• certains attributs créent-ils un lien avec une autre relation ?

6. La clé primaire

6.1 Définition

La clé primaire est l’attribut, ou l’ensemble d’attributs, qui permet d’identifier de manière unique chaque ligne d’une relation.

Autrement dit, deux lignes différentes ne peuvent pas avoir la même valeur de clé primaire.

6.2 Pourquoi la clé primaire est-elle indispensable ?

Sans clé primaire, il devient difficile de distinguer avec certitude deux enregistrements.

Par exemple, dans une table client, le nom ne suffit pas toujours :

• deux clients peuvent avoir le même nom ;
• un nom peut changer ;
• l’orthographe peut varier.

On utilise donc un identifiant stable, comme IdClient.

La clé primaire garantit :

• l’unicité des enregistrements ;
• la possibilité de retrouver précisément une ligne ;
• la possibilité de créer des liens fiables avec d’autres relations.

6.3 Exemples

• Dans CLIENT (IdClient, NomClient, Ville), la clé primaire peut être IdClient.
• Dans PRODUIT (RefProduit, Libellé, PrixUnitaire), la clé primaire peut être RefProduit.
• Dans FACTURE (NumFacture, DateFacture, IdClient), la clé primaire peut être NumFacture.

6.4 Comment repérer la clé primaire dans un schéma relationnel ?

Selon les conventions, elle peut être :

• soulignée ;
• précédée d’un symbole particulier ;
• mentionnée explicitement dans une légende.

Exemple d’écriture :

• CLIENT (**IdClient**, NomClient, Ville)
• COMMANDE (**NumCommande**, DateCommande, IdClient)

6.5 Ce qu’il faut vérifier

Quand vous identifiez une clé primaire, demandez-vous :

• permet-elle vraiment d’identifier une seule ligne ?
• sa valeur est-elle stable ?
• évite-t-on les doublons ?

7. La clé étrangère

7.1 Définition

Une clé étrangère est un attribut d’une relation qui fait référence à la clé primaire d’une autre relation.

Elle sert à relier les tables entre elles.

7.2 Exemple simple

On reprend :

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

Dans CLIENT, IdClient est la clé primaire. Dans COMMANDE, IdClient est une clé étrangère.

Pourquoi ? Parce qu’elle renvoie au client qui a passé la commande.

7.3 Rôle de la clé étrangère

La clé étrangère permet de :

• relier logiquement les données ;
• éviter de recopier inutilement toutes les informations du client dans la commande ;
• garantir la cohérence entre les tables.

Au lieu d’écrire dans chaque commande le nom, la ville et tous les détails du client, on stocke seulement son identifiant.

7.4 Lecture pratique

Quand vous voyez un attribut portant le même nom qu’une clé primaire d’une autre table, il faut vous demander s’il s’agit d’une clé étrangère.

Exemple :

• IdClient dans COMMANDE
• RefProduit dans LIGNE_COMMANDE
• NumCommande dans LIGNE_COMMANDE

7.5 Pourquoi c’est essentiel ?

Sans clé étrangère, les relations seraient isolées. Or la valeur d’une base de données relationnelle vient précisément de sa capacité à reconstituer des liens :

• un client passe plusieurs commandes ;
• une commande contient plusieurs lignes ;
• une ligne concerne un produit.

8. Interpréter un schéma relationnel

8.1 Méthode générale de lecture

Pour interpréter un schéma relationnel, il faut adopter une méthode rigoureuse.

Étape 1 : repérer les relations

Identifier chaque table du schéma.

Exemple :

• CLIENT
• COMMANDE
• PRODUIT
• LIGNE_COMMANDE

Étape 2 : lister les attributs de chaque relation

Pour chaque relation, relever les attributs.

Exemple :

• CLIENT (IdClient, NomClient, Ville)
• COMMANDE (NumCommande, DateCommande, IdClient)
• PRODUIT (RefProduit, LibelléProduit, PrixUnitaire)
• LIGNE_COMMANDE (NumCommande, RefProduit, Quantité)

Étape 3 : repérer les clés primaires

Chercher l’attribut qui identifie chaque ligne.

• CLIENT → IdClient
• COMMANDE → NumCommande
• PRODUIT → RefProduit

Pour LIGNE_COMMANDE, il peut s’agir d’une clé composée :

• NumCommande + RefProduit

Cela signifie qu’une ligne est identifiée par la combinaison de ces deux attributs.

Étape 4 : repérer les clés étrangères

Chercher quels attributs renvoient à une autre relation.

• COMMANDE.IdClient → renvoie à CLIENT.IdClient
• LIGNE_COMMANDE.NumCommande → renvoie à COMMANDE.NumCommande
• LIGNE_COMMANDE.RefProduit → renvoie à PRODUIT.RefProduit

Étape 5 : comprendre le sens des liens

Il faut ensuite traduire les liens en langage de gestion.

• une commande est passée par un client ;
• une ligne de commande appartient à une commande ;
• une ligne de commande concerne un produit.

8.2 Exemple complet commenté

Considérons le schéma suivant :

• CLIENT (IdClient, NomClient, Ville)
• COMMANDE (NumCommande, DateCommande, IdClient)
• PRODUIT (RefProduit, LibelléProduit, PrixUnitaire)
• LIGNE_COMMANDE (NumCommande, RefProduit, Quantité)

Interprétation

Relation CLIENT

• contient les informations sur les clients ;
• IdClient identifie chaque client.

Relation COMMANDE

• contient les commandes ;
• NumCommande identifie chaque commande ;
• IdClient indique quel client a passé la commande.

Relation PRODUIT

• contient les produits ;
• RefProduit identifie chaque produit.

Relation LIGNE_COMMANDE

• contient le détail des produits commandés ;
• NumCommande et RefProduit forment ensemble l’identifiant de la ligne ;
• Quantité précise la quantité commandée.

Ce que le schéma permet de comprendre

Grâce à ce schéma, on peut répondre à des questions de gestion comme :

• quels produits figurent dans une commande ?
• quel client a passé telle commande ?
• combien d’unités d’un produit ont été commandées ?

On voit bien ici l’intérêt du modèle relationnel : chaque donnée est stockée à l’endroit le plus logique, puis reliée aux autres.

9. Les clés composées

9.1 Définition

Une clé composée est une clé primaire formée de plusieurs attributs.

Aucun de ces attributs, pris isolément, ne suffit à identifier de manière unique une ligne. C’est leur combinaison qui joue ce rôle.

9.2 Exemple

Dans LIGNE_COMMANDE (NumCommande, RefProduit, Quantité) :

• NumCommande seul ne suffit pas, car une commande peut contenir plusieurs produits ;
• RefProduit seul ne suffit pas, car un produit peut apparaître dans plusieurs commandes ;
• NumCommande + RefProduit permet d’identifier une ligne précise.

9.3 Intérêt

Les clés composées apparaissent souvent dans les tables qui servent à représenter une association entre deux relations.

C’est très fréquent dans les bases de données de gestion.

10. Lecture logique d’un schéma relationnel de gestion

Pour bien interpréter un schéma relationnel, il faut aller au-delà de la simple reconnaissance visuelle. Il faut comprendre la logique métier.

10.1 Exemple : gestion commerciale

Schéma :

• CLIENT (IdClient, NomClient, Ville)
• COMMANDE (NumCommande, DateCommande, IdClient)
• PRODUIT (RefProduit, LibelléProduit, PrixUnitaire)
• LIGNE_COMMANDE (NumCommande, RefProduit, Quantité)

10.2 Traduction métier

Ce schéma décrit une activité de vente :

• l’entreprise gère des clients ;
• les clients passent des commandes ;
• les commandes comportent des produits ;
• chaque ligne de commande précise une quantité.

10.3 Ce qu’il faut savoir dire à l’oral ou à l’écrit

Quand on vous demande d’interpréter un schéma relationnel, il ne suffit pas de dire :

• « il y a quatre tables » ;
• « telle colonne est une clé primaire ».

Il faut aussi expliquer :

• ce que représente chaque relation ;
• le rôle de chaque clé ;
• le sens des liens entre les relations.

Une bonne interprétation est donc à la fois :

• technique ;
• fonctionnelle.

11. Erreurs fréquentes dans l’interprétation d’un schéma relationnel

11.1 Confondre table et ligne

Une relation n’est pas une ligne. C’est l’ensemble structuré qui contient toutes les lignes d’un même type.

11.2 Confondre clé primaire et attribut ordinaire

Tous les attributs ne jouent pas le même rôle. La clé primaire sert à identifier. Un simple libellé ne remplit pas forcément cette fonction.

11.3 Ne pas repérer les liens entre les relations

Lire chaque table isolément n’est pas suffisant. Il faut comprendre les relations entre elles.

11.4 Croire qu’un même nom d’attribut garantit automatiquement un lien

Souvent, c’est un indice fort, mais il faut vérifier le contexte logique :

• l’attribut renvoie-t-il bien à la clé primaire d’une autre relation ?
• le lien a-t-il un sens métier ?

11.5 Oublier la logique de gestion

Un schéma relationnel n’est pas seulement une structure informatique. Il traduit une organisation des données au service d’un besoin de gestion.

12. Étude guidée : interpréter pas à pas un schéma relationnel

Prenons le schéma suivant :

• FOURNISSEUR (IdFournisseur, RaisonSociale, Ville)
• ARTICLE (RefArticle, Désignation, PrixAchat)
• APPROVISIONNEMENT (NumAppro, DateAppro, IdFournisseur)
• LIGNE_APPRO (NumAppro, RefArticle, Quantité)

12.1 Identifier les relations

Il y a quatre relations :

• FOURNISSEUR
• ARTICLE
• APPROVISIONNEMENT
• LIGNE_APPRO

12.2 Identifier les clés primaires

• FOURNISSEUR → IdFournisseur
• ARTICLE → RefArticle
• APPROVISIONNEMENT → NumAppro
• LIGNE_APPRO → NumAppro + RefArticle

12.3 Identifier les clés étrangères

• APPROVISIONNEMENT.IdFournisseur renvoie à FOURNISSEUR.IdFournisseur
• LIGNE_APPRO.NumAppro renvoie à APPROVISIONNEMENT.NumAppro
• LIGNE_APPRO.RefArticle renvoie à ARTICLE.RefArticle

12.4 Interprétation métier

• un fournisseur peut être à l’origine de plusieurs approvisionnements ;
• un approvisionnement est lié à un fournisseur ;
• un approvisionnement comporte plusieurs lignes ;
• chaque ligne concerne un article et une quantité.

12.5 Conclusion de lecture

Le schéma décrit une gestion des achats ou des approvisionnements. Il sépare correctement :

• les données sur les fournisseurs ;
• les données sur les articles ;
• les opérations d’approvisionnement ;
• le détail des articles reçus.

13. Comment vérifier la cohérence d’un schéma relationnel ?

Même si le programme de cette leçon se limite à interpréter un schéma relationnel, il est utile de savoir quels réflexes adopter pour juger rapidement sa cohérence.

13.1 Vérifier que chaque relation a un rôle clair

Chaque relation doit correspondre à un objet ou à un événement identifiable de gestion.

Exemples cohérents :

• client ;
• commande ;
• produit ;
• facture.

Si une relation mélange plusieurs sujets différents, c’est souvent un mauvais signe.

13.2 Vérifier la présence d’une clé primaire

Chaque relation doit pouvoir identifier ses lignes.

Sans clé primaire, la fiabilité de la structure est compromise.

13.3 Vérifier la cohérence des clés étrangères

Une clé étrangère doit renvoyer à une clé primaire logique.

Exemple :

• IdClient dans COMMANDE renvoie à CLIENT.IdClient.

13.4 Vérifier que les liens ont un sens métier

Le lien ne doit pas être seulement technique. Il doit traduire une réalité de gestion.

Exemple :

• une commande liée à un client : oui ;
• une commande liée directement à une ville : structurellement, ce serait douteux si la ville n’est qu’une information du client.

14. Cas pratique simple

Énoncé

On vous donne le schéma relationnel suivant :

• SALARIÉ (Matricule, Nom, Service)
• PROJET (CodeProjet, LibelléProjet, Budget)
• AFFECTATION (Matricule, CodeProjet, NbHeures)

Questions

1. Quelles sont les relations ?
2. Quelles sont les clés primaires ?
3. Quelles sont les clés étrangères ?
4. Que représente la relation AFFECTATION ?

Correction

1. Relations

Les relations sont :

• SALARIÉ
• PROJET
• AFFECTATION

2. Clés primaires

• SALARIÉ → Matricule
• PROJET → CodeProjet
• AFFECTATION → Matricule + CodeProjet

3. Clés étrangères

• AFFECTATION.Matricule renvoie à SALARIÉ.Matricule
• AFFECTATION.CodeProjet renvoie à PROJET.CodeProjet

4. Sens de AFFECTATION

La relation AFFECTATION indique qu’un salarié est affecté à un projet, avec un nombre d’heures.

Elle sert donc à représenter le lien entre les salariés et les projets.

15. Méthode express pour réussir l’interprétation d’un schéma relationnel

Voici une méthode courte à appliquer systématiquement.

15.1 Lire le nom des relations

Demandez-vous : de quoi parle chaque table ?

15.2 Repérer l’identifiant de chaque relation

Cherchez la clé primaire.

15.3 Rechercher les attributs repris dans d’autres relations

Ils signalent souvent des clés étrangères.

15.4 Reformuler les liens en français courant

Exemples :

• une commande appartient à un client ;
• une ligne de commande concerne un produit ;
• une affectation relie un salarié à un projet.

15.5 Vérifier la cohérence globale

Le schéma doit raconter une logique de gestion claire.

16. Pourquoi cette compétence est essentielle en DCG ?

Dans les métiers de la gestion, de la comptabilité et du contrôle, on travaille de plus en plus avec des outils numériques qui reposent sur des bases de données.

Savoir interpréter un schéma relationnel permet de :

• comprendre d’où viennent les données ;
• mieux dialoguer avec les équipes informatiques ;
• repérer la logique d’un progiciel ;
• préparer l’extraction et l’analyse des informations ;
• sécuriser les traitements de gestion.

Par exemple, lorsqu’un utilisateur constate une incohérence dans un état ou un tableau de bord, comprendre la structure relationnelle aide à identifier :

• la table source ;
• le lien manquant ou erroné ;
• l’origine possible du problème.

Cette compétence n’est donc pas réservée aux informaticiens. Elle fait partie de la culture numérique attendue d’un étudiant en DCG.

Résumé

Le modèle relationnel organise les données d’une base sous forme de relations, c’est-à-dire de tables.

Pour interpréter un schéma relationnel, il faut savoir :

• repérer les relations ;
• identifier les attributs ;
• reconnaître la clé primaire, qui identifie chaque ligne de manière unique ;
• reconnaître la clé étrangère, qui relie une relation à une autre ;
• comprendre la logique métier portée par la structure.

Un schéma relationnel bien lu permet de comprendre comment une organisation structure ses données pour alimenter ses traitements de gestion.

Mémo

À retenir absolument

• Une relation = une table du modèle relationnel.
• Un attribut = une colonne.
• Une clé primaire identifie de façon unique chaque ligne.
• Une clé étrangère crée un lien avec une autre relation.
• Interpréter un schéma relationnel, c’est lire à la fois la structure technique et le sens de gestion.

Réflexe de lecture

Pour chaque relation, poser 4 questions :

1. Quel objet de gestion représente-t-elle ?
2. Quelle est sa clé primaire ?
3. Contient-elle une clé étrangère ?
4. Quel lien établit-elle avec les autres relations ?

Auto-vérification rapide

Essayez de répondre sans relire :

• Quelle différence entre une relation et un attribut ?
• Pourquoi une clé primaire est-elle indispensable ?
• À quoi sert une clé étrangère ?
• Comment interpréter une table d’association comme LIGNE_COMMANDE ou AFFECTATION ?

Si vous savez répondre clairement à ces quatre questions, vous maîtrisez l’essentiel de cette leçon.