B01 - Les concepts des bases de données relationnelles
Objectif
Le vocabulaire de base (SGBD, table, ligne, colonne, clé primaire, clé étrangère, intégrité) et les formes normales, avant de modéliser (B02 - Modélisation Merise et UML) et d’écrire du SQL.
1. Base de données et SGBD
- Base de données : ensemble organisé de données (clients, commandes, produits…).
- SGBD (Système de Gestion de Base de Données) : le logiciel qui stocke, protège et interroge ces données.
- SQL : le langage standard pour parler à un SGBD relationnel.
| SGBD | Éditeur / licence | Où tu le croises |
|---|---|---|
| SQL Server | Microsoft (édition Developer/Express gratuites) | Cours d’Alan (B2) - dialecte T-SQL |
| MariaDB | Libre (fork de MySQL) | Projet transversal, GLPI, WordPress |
| MySQL | Oracle (Community gratuite) | Révision SQL B1 (Northwind MySQL) |
| PostgreSQL | Libre | Très utilisé en entreprise |
| SQLite | Libre, un simple fichier | Applis mobiles, prototypes |
| Oracle Database | Oracle | Grands comptes |
| MongoDB, Redis | NoSQL (non relationnels) | Documents JSON, cache |
2. Le modèle relationnel
erDiagram CLIENTS ||--o{ COMMANDES : "passe" CLIENTS { int id_client PK nvarchar nom nvarchar email UK } COMMANDES { int id_commande PK date date_commande int id_client FK }
| Terme | Synonymes | Exemple |
|---|---|---|
| Table | Relation, entité | Clients |
| Ligne | Enregistrement, tuple, row | Le client n°12 |
| Colonne | Attribut, champ | email |
| Domaine | Type de données | NVARCHAR(255) |
| Clé primaire (PK) | Identifiant | id_client - unique et non nulle |
| Clé étrangère (FK) | Référence | Commandes.id_client → Clients.id_client |
| Clé candidate / unique (UK) | Autre identifiant possible | email |
Clé primaire : laquelle choisir ?
| Type | Exemple | Remarque |
|---|---|---|
| Entier auto-incrémenté (clé technique) | INT IDENTITY(1,1) (SQL Server), AUTO_INCREMENT (MariaDB) | Le choix par défaut : simple, performant |
| GUID | UNIQUEIDENTIFIER DEFAULT NEWID() | Unique au monde (systèmes distribués), difficile à deviner, mais plus lourd |
| Clé naturelle | N° de sécurité sociale, code article | Seulement si vraiment stable et unique |
| Clé composée | (id_oeuvre, id_artiste) | Tables d’association (plusieurs-à-plusieurs) |
3. Les contraintes d’intégrité
| Contrainte | Garantit que… |
|---|---|
PRIMARY KEY | Chaque ligne est identifiable de façon unique |
FOREIGN KEY | La valeur référencée existe (pas de commande pour un client inexistant) |
UNIQUE | Pas de doublon (ex. email) |
NOT NULL | La valeur est obligatoire |
CHECK | Une règle métier est respectée (prix > 0, date_depart > date_arrivee) |
DEFAULT | Valeur par défaut si rien n’est fourni |
Actions sur clé étrangère : ON DELETE CASCADE (supprimer les lignes filles), SET NULL, SET DEFAULT, NO ACTION (refuser - défaut). Détails et syntaxe : B04 - SQL - créer la structure (DDL).
4. Les formes normales (éviter la redondance)
Objectif : chaque information est stockée une seule fois → pas d’incohérence quand on la modifie.
| Forme | Règle | Contre-exemple → correction |
|---|---|---|
| 1FN | Chaque cellule contient une seule valeur (atomique), pas de groupes répétés | telephones = "0601…, 0702…" → table Telephones séparée |
| 2FN | 1FN + chaque attribut non-clé dépend de toute la clé (cas des clés composées) | Dans LigneCommande(id_commande, ref_produit, quantite, designation_produit), designation ne dépend que de ref_produit → elle va dans Produits |
| 3FN | 2FN + aucun attribut non-clé ne dépend d’un autre attribut non-clé | Employes(id, nom, id_service, nom_service) : nom_service dépend de id_service → table Services |
Moyen mnémotechnique : chaque attribut dépend « de la clé, de toute la clé, et de rien que la clé ».
Parfois on dénormalise volontairement (ex. prix_unitaire_facture copié dans la ligne de commande pour historiser le prix au moment de l’achat - exercice Héritage).
5. Transactions et ACID
Une transaction = un groupe d’opérations « tout ou rien » (ex. virement : débiter A et créditer B).
| Propriété | Signification |
|---|---|
| Atomicité | Tout est fait, ou rien |
| Cohérence | La base passe d’un état valide à un autre état valide |
| Isolation | Les transactions simultanées ne se perturbent pas |
| Durabilité | Une fois validée (COMMIT), la modification survit à une panne |
BEGIN TRANSACTION;
UPDATE Comptes SET solde = solde - 100 WHERE id = 1;
UPDATE Comptes SET solde = solde + 100 WHERE id = 2;
COMMIT; -- ou ROLLBACK; pour tout annuler