Mises à jour, intégrité référentielle et exportation des données

Introduction

Dans les leçons précédentes, nous avons vu comment interpréter un schéma relationnel, vérifier sa cohérence, puis interroger une base de données avec des requêtes SQL d’extraction. Cette étape est essentielle, mais elle ne suffit pas dans un contexte réel de gestion. Une base de données n’est pas seulement consultée : elle est aussi alimentée, corrigée, mise à jour et exploitée pour produire des informations utiles aux utilisateurs.

Cette leçon porte donc sur trois idées centrales :

1. modifier les données d’une base à l’aide de requêtes de mise à jour ;
2. préserver la cohérence des données grâce à la contrainte d’intégrité référentielle ;
3. extraire et exporter les données utiles à la gestion.

Autrement dit, on passe d’une logique de simple lecture à une logique de pilotage fiable des données.

Objectifs d’apprentissage

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

• comprendre la place des mises à jour dans la gestion des données du système d’information ;
• identifier les situations où une requête de modification est nécessaire ;
• écrire des requêtes de mise à jour de données ;
• comprendre la notion de contrainte d’intégrité référentielle ;
• expliquer pourquoi cette contrainte est indispensable à la fiabilité d’une base relationnelle ;
• extraire des informations d’une base de données en vue d’un usage de gestion ;
• comprendre la logique d’exportation des données vers d’autres outils.

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

Dans un système d’information, les données ne sont pas figées. Elles évoluent en permanence :

• un nouveau client est créé ;
• une adresse est corrigée ;
• un produit n’est plus commercialisé ;
• une commande change de statut ;
• une liste de données doit être transmise à un autre outil.

La gestion des données du système d’information consiste donc à assurer plusieurs fonctions complémentaires :

• stocker les données ;
• organiser ces données dans une structure cohérente ;
• les manipuler selon les besoins de l’organisation ;
• les contrôler pour préserver leur qualité ;
• les exploiter pour produire de l’information utile.

Dans le cadre d’une base de données relationnelle, cette gestion repose notamment sur :

• les tables ;
• les relations entre tables ;
• les requêtes SQL ;
• les contraintes qui empêchent certaines incohérences.

Une base de données de gestion doit répondre à une exigence forte : fournir une information exacte, cohérente et exploitable. C’est précisément la raison pour laquelle les requêtes de modification ne doivent jamais être vues comme de simples opérations techniques. Elles ont un impact direct sur la qualité de l’information produite.

2. Gérer des données du système d’information : de la consultation à l’action

Jusqu’ici, les requêtes étudiées servaient surtout à consulter les données. On demandait par exemple :

• quels clients ont commandé en janvier ;
• quels produits dépassent un certain prix ;
• quel est le chiffre d’affaires par client.

Mais gérer des données du système d’information, c’est aussi agir sur les données elles-mêmes.

On distingue alors deux grands usages du SQL :

• les requêtes d’extraction, qui lisent les données ;
• les requêtes de mise à jour, qui modifient le contenu des tables.

Les requêtes de mise à jour sont plus sensibles, car elles transforment l’état de la base. Une erreur peut avoir des conséquences importantes :

• modification involontaire d’un grand nombre d’enregistrements ;
• suppression de données encore utiles ;
• création d’incohérences entre tables ;
• perte de fiabilité des traitements ultérieurs.

C’est pourquoi il faut toujours raisonner avant d’écrire une requête de modification :

1. Quelle donnée doit changer ?
2. Dans quelle table ?
3. Selon quel critère ?
4. Avec quelles conséquences sur les autres tables ?

3. Manipuler des données d’une base de données

3.1 Deux familles d’actions sur les données

Manipuler des données dans une base relationnelle consiste notamment à :

• ajouter de nouvelles lignes ;
• modifier des lignes existantes ;
• supprimer certaines lignes ;
• extraire des données pour les exploiter.

Dans cette leçon, l’accent porte surtout sur :

• les requêtes de mise à jour de données ;
• la compréhension de la contrainte d’intégrité référentielle ;
• l’extraction de données en vue d’une exportation.

3.2 Exemple de base de données

Prenons une base simple de gestion commerciale avec trois tables :

• Client (IdClient, NomClient, Ville)
• Commande (IdCommande, DateCommande, IdClient, Statut)
• LigneCommande (IdCommande, IdProduit, Quantite)

Dans cet exemple :

• IdClient est la clé primaire de Client ;
• IdCommande est la clé primaire de Commande ;
• IdClient dans Commande est une clé étrangère vers Client ;
• IdCommande dans LigneCommande est une clé étrangère vers Commande.

Cette structure permet d’illustrer les enjeux des modifications : changer ou supprimer une donnée dans une table peut avoir des effets sur les autres.

4. Écrire des requêtes de mise à jour de données

Dans le cadre du programme, les requêtes de mise à jour portent sur les données des tables et non sur la structure de la base.

Les principales opérations de mise à jour sont :

• INSERT : ajouter un enregistrement ;
• UPDATE : modifier un ou plusieurs enregistrements ;
• DELETE : supprimer un ou plusieurs enregistrements.

5. Ajouter des données avec INSERT

5.1 Principe

La requête INSERT sert à insérer une nouvelle ligne dans une table.

5.2 Syntaxe générale

INSERT INTO NomTable (colonne1, colonne2, colonne3)
VALUES (valeur1, valeur2, valeur3);

5.3 Exemple simple

Ajout d’un client :

INSERT INTO Client (IdClient, NomClient, Ville)
VALUES (101, 'Société Durand', 'Lyon');

5.4 Pourquoi préciser les colonnes ?

Préciser les colonnes est une bonne pratique, car cela permet :

• d’éviter les erreurs si l’ordre des champs est mal connu ;
• de mieux lire la requête ;
• de sécuriser l’insertion.

5.5 Exemple de gestion

Une entreprise ouvre un nouveau compte client dans sa base. L’ajout doit être fait avant toute saisie de commande. Si le client n’existe pas dans la table Client, la commande qui s’y rattache ne pourra pas être correctement enregistrée.

5.6 Point de vigilance

Une insertion n’est valide que si :

• la clé primaire est correcte ;
• les valeurs respectent les types attendus ;
• les éventuelles clés étrangères correspondent à des valeurs existantes.

6. Modifier des données avec UPDATE

6.1 Principe

La requête UPDATE sert à modifier des données déjà présentes dans une table.

6.2 Syntaxe générale

UPDATE NomTable
SET colonne1 = valeur1, colonne2 = valeur2
WHERE condition;

6.3 Exemple simple

Un client a changé de ville :

UPDATE Client
SET Ville = 'Marseille'
WHERE IdClient = 101;

6.4 Rôle essentiel du WHERE

Le WHERE est capital. Sans lui, la requête modifie toutes les lignes de la table.

Exemple dangereux :

UPDATE Client
SET Ville = 'Marseille';

Cette requête attribuerait la ville Marseille à tous les clients.

6.5 Exemple de mise à jour multiple

Mettre à jour le statut de toutes les commandes expédiées :

UPDATE Commande
SET Statut = 'Expédiée'
WHERE Statut = 'Préparée';

6.6 Exemple de gestion

Dans une organisation, les statuts de commande évoluent au fil du processus. Une mise à jour permet de refléter l’état réel de l’activité. Sans cela, les tableaux de suivi et les extractions seraient faux.

6.7 Méthode recommandée avant un UPDATE

Avant de lancer une mise à jour, il est prudent de :

1. écrire d’abord une requête SELECT avec le même WHERE ;
2. vérifier les lignes concernées ;
3. seulement ensuite exécuter le UPDATE.

Exemple :

SELECT *
FROM Commande
WHERE Statut = 'Préparée';

Puis :

UPDATE Commande
SET Statut = 'Expédiée'
WHERE Statut = 'Préparée';

Cette démarche limite fortement les erreurs.

7. Supprimer des données avec DELETE

7.1 Principe

La requête DELETE sert à supprimer une ou plusieurs lignes d’une table.

7.2 Syntaxe générale

DELETE FROM NomTable
WHERE condition;

7.3 Exemple simple

Suppression d’un client test :

DELETE FROM Client
WHERE IdClient = 999;

7.4 Danger d’une suppression sans condition

DELETE FROM Client;

Cette requête supprime tous les clients de la table.

7.5 Pourquoi la suppression est-elle plus sensible ?

Parce qu’une suppression peut casser la cohérence de la base si d’autres tables dépendent de l’enregistrement supprimé.

Exemple :

• si on supprime un client ;
• alors que des commandes lui sont rattachées ;
• on crée un problème de cohérence si la base ne gère pas correctement les liens entre tables.

C’est ici qu’intervient la contrainte d’intégrité référentielle.

8. Comprendre la notion de contrainte d’intégrité référentielle

8.1 Définition

La contrainte d’intégrité référentielle garantit la cohérence des relations entre tables.

Concrètement, lorsqu’une table contient une clé étrangère, la valeur de cette clé doit correspondre à une valeur existante de la clé primaire dans la table référencée.

8.2 Exemple fondamental

Dans la table Commande, le champ IdClient renvoie à la table Client.

Cela signifie que :

• une commande ne peut pas être rattachée à un client inexistant ;
• la base doit empêcher la création d’une référence incohérente.

Exemple invalide :

INSERT INTO Commande (IdCommande, DateCommande, IdClient, Statut)
VALUES (5001, '2025-04-10', 9999, 'Enregistrée');

Si le client 9999 n’existe pas dans la table Client, cette insertion doit être refusée.

8.3 Pourquoi cette contrainte est-elle indispensable ?

Sans intégrité référentielle, une base de données pourrait contenir :

• des commandes sans client réel ;
• des lignes de commande sans commande existante ;
• des données isolées, appelées parfois enregistrements orphelins.

Or une base de données de gestion doit représenter fidèlement la réalité de l’organisation.

8.4 Ce que protège l’intégrité référentielle

Elle protège la base contre trois types d’anomalies :

• insertion incohérente : ajout d’une clé étrangère sans référence valide ;
• mise à jour incohérente : modification d’une clé étrangère vers une valeur inexistante ;
• suppression problématique : suppression d’un enregistrement encore référencé ailleurs.

9. Intégrité référentielle et opérations de mise à jour

9.1 Cas d’une insertion

Si l’on ajoute une commande, le client doit déjà exister.

Logique métier : on ne peut pas enregistrer une commande pour un client inconnu.

9.2 Cas d’une modification

Si l’on modifie le IdClient d’une commande, la nouvelle valeur doit correspondre à un client réel.

Exemple :

UPDATE Commande
SET IdClient = 205
WHERE IdCommande = 5001;

Cette requête n’est acceptable que si le client 205 existe.

9.3 Cas d’une suppression

Supposons qu’un client possède plusieurs commandes. Si l’on tente de supprimer ce client, la base peut :

• refuser la suppression ;
• ou appliquer une règle spécifique prévue dans le système.

Dans le cadre de cette leçon, l’essentiel est de comprendre le principe :

on ne doit pas laisser subsister des données incohérentes entre tables liées.

9.4 Vision de gestion

L’intégrité référentielle n’est pas qu’un mécanisme technique. Elle traduit une exigence de gestion :

• une facture doit concerner un client existant ;
• une ligne de commande doit appartenir à une commande réelle ;
• un règlement doit être rattaché à une opération valide.

La qualité de l’information dépend donc directement du respect de ces liens.

10. Méthode pour identifier une requête de mise à jour adaptée

Dans une situation de gestion, il ne suffit pas de savoir écrire INSERT, UPDATE ou DELETE. Il faut d’abord identifier la nature de l’action à réaliser.

10.1 Étape 1 : analyser le besoin

Exemples de besoins :

• créer un nouveau fournisseur ;
• corriger une adresse erronée ;
• supprimer un enregistrement de test ;
• changer le statut d’un dossier.

10.2 Étape 2 : repérer la table concernée

On doit savoir où se trouve la donnée.

Exemple :

• l’adresse d’un client est dans Client ;
• le statut d’une commande est dans Commande.

10.3 Étape 3 : choisir le type de requête

• donnée inexistante à ajouter → INSERT
• donnée existante à corriger → UPDATE
• donnée à retirer → DELETE

10.4 Étape 4 : vérifier les conséquences relationnelles

Avant de modifier ou supprimer, il faut se demander :

• cette ligne est-elle liée à d’autres tables ?
• vais-je violer une contrainte d’intégrité référentielle ?

10.5 Étape 5 : sécuriser l’opération

Bonnes pratiques :

• tester d’abord avec un SELECT ;
• cibler précisément avec un WHERE ;
• éviter les critères trop larges ;
• vérifier les clés étrangères.

11. Extraire des informations d’une base de données

Même si cette leçon porte principalement sur les mises à jour, elle couvre aussi l’idée d’extraire des informations d’une base de données. Cette extraction est indispensable pour produire des listes, des états ou des fichiers réutilisables.

11.1 Pourquoi extraire ?

L’extraction permet de transformer les données stockées en information utile à la gestion.

Exemples :

• liste des clients d’une région ;
• commandes en attente ;
• catalogue produits ;
• données nécessaires à un traitement dans un tableur.

11.2 Lien avec les leçons précédentes

Comme vu dans les leçons 161 et 162, l’extraction repose sur des requêtes SELECT, avec éventuellement :

• sélection de colonnes ;
• filtres ;
• jointures ;
• tris ;
• regroupements.

Dans la présente leçon, l’idée centrale n’est pas de refaire toute la syntaxe, mais de comprendre que l’extraction est souvent l’étape préalable à une exportation.

11.3 Exemple d’extraction simple

SELECT IdClient, NomClient, Ville
FROM Client
WHERE Ville = 'Lyon'
ORDER BY NomClient;

Cette requête produit une liste exploitable des clients lyonnais.

11.4 Exemple avec jointure

SELECT C.IdCommande, C.DateCommande, Cl.NomClient, C.Statut
FROM Commande C
INNER JOIN Client Cl ON C.IdClient = Cl.IdClient
WHERE C.Statut = 'Enregistrée';

On obtient ici une information de gestion plus riche, car on relie les commandes à leurs clients.

12. Exporter les données utiles à la gestion

12.1 Qu’est-ce qu’une exportation ?

Exporter des données consiste à sortir le résultat d’une extraction de la base de données pour l’utiliser dans un autre environnement :

• tableur ;
• outil de reporting ;
• application métier ;
• fichier d’échange.

12.2 Pourquoi exporter ?

L’exportation répond à des besoins fréquents :

• réaliser un traitement complémentaire ;
• partager une liste avec un autre service ;
• alimenter un tableau de bord ;
• archiver un état à une date donnée.

12.3 Différence entre extraction et exportation

• Extraction : on sélectionne les données dans la base.
• Exportation : on transfère le résultat dans un autre support.

L’exportation est donc généralement postérieure à l’extraction.

12.4 Pourquoi faut-il être sélectif ?

Exporter ne signifie pas tout sortir. Il faut au contraire n’exporter que les données utiles.

Cela permet :

• d’éviter les fichiers trop volumineux ;
• de limiter les erreurs d’interprétation ;
• de mieux cibler le besoin de gestion ;
• de préserver la lisibilité des traitements.

12.5 Exemple de logique d’exportation

Besoin : transmettre au service commercial la liste des commandes en attente.

Étapes :

1. écrire une requête d’extraction ;
2. vérifier les colonnes réellement utiles ;
3. trier les résultats ;
4. exporter le résultat vers un fichier exploitable.

Exemple de requête :

SELECT IdCommande, DateCommande, IdClient, Statut
FROM Commande
WHERE Statut = 'Enregistrée'
ORDER BY DateCommande;

12.6 Lien avec la qualité des données

Une exportation n’a de valeur que si la base est elle-même fiable. Si les mises à jour sont mal faites ou si l’intégrité référentielle n’est pas respectée, les données exportées seront de mauvaise qualité.

Ainsi, mise à jour, intégrité référentielle et exportation forment une chaîne logique :

1. on enregistre correctement les données ;
2. on maintient leur cohérence ;
3. on extrait une information fiable ;
4. on exporte cette information pour l’action ou la décision.

13. Cas pratique progressif

Situation

Une entreprise utilise les tables suivantes :

• Client (IdClient, NomClient, Ville)
• Commande (IdCommande, DateCommande, IdClient, Statut)

On vous demande :

1. d’ajouter un nouveau client ;
2. de corriger la ville d’un client ;
3. de supprimer un client test ;
4. d’extraire la liste des commandes en cours.

13.1 Ajouter un client

INSERT INTO Client (IdClient, NomClient, Ville)
VALUES (150, 'Atelier Martin', 'Nantes');

Pourquoi ? Parce qu’il s’agit d’une donnée nouvelle, absente de la table.

13.2 Corriger une ville

UPDATE Client
SET Ville = 'Rennes'
WHERE IdClient = 150;

Pourquoi ? Parce que l’enregistrement existe déjà, mais une donnée doit être modifiée.

13.3 Supprimer un client test

DELETE FROM Client
WHERE IdClient = 999;

Pourquoi ? Parce qu’il s’agit d’un enregistrement inutile.

Point de vigilance : si ce client est lié à des commandes, la suppression peut être bloquée par l’intégrité référentielle.

13.4 Extraire les commandes en cours

SELECT IdCommande, DateCommande, IdClient, Statut
FROM Commande
WHERE Statut <> 'Livrée'
ORDER BY DateCommande;

Pourquoi ? Parce que l’objectif est ici d’obtenir une information exploitable, non de modifier la base.

14. Erreurs fréquentes à éviter

14.1 Oublier le WHERE

C’est l’erreur la plus classique avec UPDATE et DELETE.

Conséquence : modification ou suppression massive non voulue.

14.2 Modifier une clé étrangère sans vérifier son existence

Exemple : attribuer à une commande un IdClient inexistant.

Conséquence : incohérence, normalement bloquée par l’intégrité référentielle.

14.3 Supprimer un enregistrement encore référencé

Exemple : supprimer un client qui a des commandes.

Conséquence : rupture de cohérence entre tables.

14.4 Exporter trop de colonnes ou trop de lignes

Conséquence : fichier peu lisible, traitement inefficace, risque d’erreur.

14.5 Ne pas tester avant mise à jour

Une requête SELECT préalable permet souvent d’éviter une erreur grave.

15. Bonnes pratiques professionnelles

Dans un contexte de gestion, les bonnes pratiques suivantes sont essentielles :

• toujours identifier précisément la table concernée ;
• comprendre les liens entre tables avant toute modification ;
• utiliser un WHERE ciblé ;
• tester avec une requête d’extraction avant une requête de modification ;
• raisonner en termes de cohérence globale et non de simple ligne isolée ;
• n’exporter que les données réellement utiles au besoin exprimé.

Ces bonnes pratiques relèvent autant de la rigueur technique que du contrôle interne de l’information.

16. Synthèse : articuler mise à jour, intégrité et exploitation

Pour bien gérer des données du système d’information, il faut comprendre que :

• une base de données n’est pas seulement un outil de stockage ;
• les données doivent être manipulées en fonction des besoins de gestion ;
• les requêtes de mise à jour permettent d’ajouter, corriger ou supprimer des enregistrements ;
• ces opérations doivent respecter les relations entre tables ;
• la contrainte d’intégrité référentielle garantit cette cohérence ;
• les données ainsi fiabilisées peuvent ensuite être extraites et exportées pour être exploitées dans d’autres outils.

On retrouve donc une logique complète de gestion de la donnée :

saisir → modifier → contrôler → extraire → exporter.

Mémo

Requêtes de mise à jour

• Ajouter une ligne : INSERT INTO ... VALUES ...
• Modifier une ligne : UPDATE ... SET ... WHERE ...
• Supprimer une ligne : DELETE FROM ... WHERE ...

Point clé

Le WHERE est indispensable pour cibler les enregistrements concernés.

Intégrité référentielle

Elle garantit qu’une clé étrangère correspond à une clé primaire existante dans la table référencée.

Risques évités

• commande sans client ;
• ligne sans commande ;
• suppression incohérente ;
• données orphelines.

Extraction et exportation

• Extraction : sélectionner les données utiles avec une requête ;
• Exportation : transférer le résultat vers un autre support de travail.

Points à retenir

• Manipuler des données d’une base de données ne se limite pas à les consulter.
• Les requêtes de mise à jour de données sont essentielles dans la vie d’un système d’information.
• Une modification mal ciblée peut altérer toute la base.
• La contrainte d’intégrité référentielle protège la cohérence des relations entre tables.
• Extraire des informations d’une base de données permet de répondre à un besoin de gestion.
• L’exportation prolonge l’extraction en mettant les données à disposition d’autres outils ou utilisateurs.

Cette leçon complète donc logiquement les précédentes : après avoir appris à structurer et interroger une base, vous savez désormais agir sur les données tout en préservant leur cohérence.