Relations et identifiants
Une table représente un ensemble d’occurrences décrites par des attributs. La clé primaire identifie chaque ligne de manière unique et ne prend pas de valeur NULL. Une clé étrangère relie une ligne à une clé référencée. Dans Client(id_client, nom) et Facture(id_facture, id_client, montant), une facture peut référencer son client sans recopier son nom dans chaque ligne.
Dépendances et normalisation
Une dépendance fonctionnelle X → Y signifie qu’une valeur de X détermine une seule valeur de Y dans les règles du domaine. Répéter l’adresse du client sur chaque facture peut provoquer des incohérences de mise à jour. Dans un modèle simplifié où l’on conserve seulement l’adresse actuelle du client, la séparer dans Client évite cette répétition. Si une adresse historique de facturation est requise, il faut au contraire modéliser cette information historique : on ne normalise pas en supprimant un besoin réel.
Interroger
SELECT choisit les expressions retournées, FROM les tables, WHERE les lignes satisfaisant une condition et ORDER BY l’ordre du résultat. Une jointure associe les lignes suivant une condition. INNER JOIN conserve les correspondances ; LEFT JOIN conserve aussi les lignes de gauche sans correspondance, complétées par NULL. RIGHT JOIN applique la logique symétrique. Sans ORDER BY, l’ordre n’est pas garanti.
Agréger et filtrer
GROUP BY forme les groupes ; SUM, COUNT et AVG peuvent calculer des synthèses. WHERE filtre les lignes avant le regroupement ; HAVING filtre les groupes. COUNT(*) compte les lignes, tandis que COUNT(colonne) ne compte pas ses valeurs NULL. Une jointure avec une table de détail peut multiplier les lignes d’une facture : le total doit être contrôlé au bon niveau.
Valeurs manquantes et modifications
NULL représente une absence de valeur, pas nécessairement zéro ou une chaîne vide. Tester IS NULL ou IS NOT NULL selon le besoin. Les requêtes INSERT, UPDATE et DELETE modifient les données ; une clause WHERE manquante peut étendre une modification à toutes les lignes. Vérifier d’abord la population et les contraintes sur un jeu d’essai, puis suivre la procédure de contrôle et de transaction prévue.
Cadre des exercices
Les exemples utilisent des constructions courantes compatibles avec le périmètre SQL-92 du programme. Les types, certaines fonctions et les modalités d’exécution varient selon le SGBD. La conception des tables est étudiée par les schémas ; l’exercice de mise à jour porte sur les données, sans demander de modifier la structure.