Conception de bases de données relationnelles

Se connecter pour s'inscrire

MySQL et PostgreSQL

Concevoir un modèle relationnel normalisé, garantir ses contraintes et écrire des requêtes métier testées.

  1. Public cible

    Débutants, étudiants et professionnels qui souhaitent acquérir une pratique structurée dans ce domaine.

  2. Objectifs

    Comprendre les notions essentielles et les appliquer dans un projet vérifiable.

  3. Prérequis

    Aucune connaissance préalable n’est strictement obligatoire ; les prérequis détaillés sont précisés dans les ateliers.

  4. Niveau

    Bac+3

  5. Ressources

    • Documentation officielle et références citées dans les ateliers.
    • Exercices, examens et projet de synthèse du catalogue.

  6. Validation des compétences

    La validation repose sur les évaluations actives et les livrables pratiques du cours.

  7. Besoins techniques

    Un ordinateur, un navigateur et les outils indiqués dans le premier atelier sont suffisants pour commencer.

Exercices, examens et projets

Conception relationnelle

Exercice

Modélisation relationnelle

Concevoir un modèle normalisé et ses contraintes.

Obligatoire Consulter
Examen

Examen modèle relationnel

Évaluer normalisation, intégrité et requêtes.

Obligatoire Consulter
Projet

Projet modèle

Livrer un modèle de données et sa documentation.

Livrables :

  • MCD
  • MLD
  • Contraintes
Obligatoire Consulter

Conception de bases de données relationnelles

Construire un modèle relationnel qui reflète le métier, respecte les contraintes et reste compréhensible par les développeurs et les utilisateurs.

À la fin du cours

  • Passer des règles métier à un MCD puis à un MLD.
  • Choisir des clés, relations et types adaptés.
  • Normaliser sans perdre les informations utiles.
  • Écrire des requêtes, contraintes et tests de cohérence.

Organisation

Le cours suit le modèle conceptuel, les contraintes, la normalisation et les requêtes.

Prérequis : Notions de tables, clés étrangères et requêtes SQL de base.

Du métier au modèle

Identifier les entités, leurs attributs, les règles et les relations avant de créer une table. Une relation many-to-many se matérialise généralement par une table associative avec ses propres règles.

Nommer les concepts métier plutôt que les détails techniques. Le modèle doit permettre de comprendre les règles sans connaître le nom d’une colonne.

client 1—N commande 1—N ligne_de_commande N—1 produit
Point de contrôle : Chaque entité et chaque relation possède une règle métier documentée.

Clés et contraintes

Choisir une clé primaire stable, indépendante de la clé naturelle quand elle peut changer. Les clés étrangères expriment les dépendances et les suppressions doivent être explicites.

Ajouter NOT NULL, CHECK, UNIQUE et(length) selon le sens métier. Une contrainte au bon endroit protège les données même lorsque plusieurs applications écrivent.

CREATE TABLE account (id BIGINT PRIMARY KEY, email VARCHAR(255) NOT NULL UNIQUE);
Point de contrôle : Les règles critiques sont garanties par la base et non seulement par un formulaire.

Normalisation et équilibre pragmatique

La normalisation élimine la duplication et les incohérences. Ne pas dénormaliser sans mesurer : la performance peut justifier une copie contrôlée, documentée et actualisée.

Distinguer la forme normale, les données historiques et les valeurs calculées. Une vue peut simplifier les lectures sans casser le modèle d’écriture.

Méthode

  1. Identifier les dépendances fonctionnelles.
  2. Décomposer les groupes répétitifs.
  3. Vérifier les lectures les plus fréquentes.
Point de contrôle : Une donnée saisie à un seul endroit ne crée pas de divergence silencieuse.

Requêtes et tests

Écrire des requêtes lisibles avec jointures explicites, agrégations et conditions de sécurité. Tester les résultats attendus, les doublons, les valeurs nulles et les suppressions.

Documenter le MCD, le MLD et les raisons des choix. Le modèle doit pouvoir évoluer sans que chaque développeur devine une intention cachée.

SELECT c.id, SUM(l.total) FROM customer c JOIN invoice l ON l.customer_id = c.id GROUP BY c.id;
Point de contrôle : Une requête de lecture est accompagnée d’un jeu de données et d’un résultat attendu.

Livrables et validation

Le livrable doit montrer une compréhension personnelle, des choix explicités et une vérification par un cas de test ou une procédure reproductible.

  • Un MCD et un MLD versionnés.
  • Un script de création avec contraintes et index.
  • Un dictionnaire de données et des choix justifiés.
  • Des requêtes métier et des tests de cohérence.
Critère de réussite : Le modèle est validé quand les règles métier sont garanties par des contraintes, les lectures sont testées et la duplication critique est supprimée.

Publié le 29/11/2025