Aller au contenu

Conception

Conception de Bases de Données : Modèle Entité-Association et Schéma Relationnel

Bien modéliser, c'est tout un art

Créer une base de données sans réfléchir à sa conception, c’est comme construire une maison sans plan. Cela peut tenir un temps, mais dès qu’il y a des modifications à faire, tout s’écroule. Pour éviter cela, on utilise des outils et méthodes de conception qui permettent de structurer les données de manière cohérente et évolutive.

Le Problème de la Redondance des Données

Qu’est-ce que la redondance ?

La redondance se produit lorsqu’une même information est stockée à plusieurs endroits. Cela peut entraîner des incohérences et alourdir inutilement la base.

Exemple : Table sans normalisation

ID_Vente Nom_Client Email Produit
1 Dupont dupont@gmail.com Livre
2 Dupont dupont@gmail.com Stylo
3 Dupont dupont@gmail.com Cahier

Le client Dupont est répété trois fois. Imaginons qu’il change d’adresse email, il faudra le modifier partout, au risque d’oublier une ligne.

Pourquoi éviter la redondance ?

  • Risque d'incohérences : Un email modifié sur une seule ligne entraîne des données erronées.
  • Espace perdu : Si une base contient des millions d’enregistrements, ces duplications gaspillent de l’espace.
  • Maintenance compliquée : Plus il y a de redondance, plus la gestion devient laborieuse.

Modèle Entité-Association (MCD)

Définition

Le Modèle Conceptuel de Données (MCD), ou Modèle Entité-Association, permet de représenter de manière visuelle les données d'un système, leurs relations, et leurs propriétés.

  • Entités : Ce sont les objets ou concepts du système. Par exemple, un Client, un Produit.
  • Associations : Ce sont les relations entre les entités. Par exemple, un Client achète un Produit.
  • Attributs : Ce sont les propriétés des entités ou des associations. Par exemple, Nom_Client, Email.

Exemple simple de MCD

Imaginons une boutique où des clients achètent des produits.

    ┌─────────────────┐                           ┌─────────────────┐
    │     CLIENT      │                           │     PRODUIT     │
    ├─────────────────┤                           ├─────────────────┤
    │ #ID_Client (PK) │                           │ #ID_Produit (PK)│
    │  Nom            │                           │  Nom_Produit    │
    │  Email          │                           │  Prix           │
    └────────┬────────┘                           └────────┬────────┘
             │                                             │
             │ 1,n                                     1,n │
             │                                             │
             │         ┌─────────────────┐                 │
             └─────────┤     ACHETE      ├─────────────────┘
                       │   (Association) │
                       ├─────────────────┤
                       │  Date           │
                       │  Quantité       │
                       └─────────────────┘

Lecture des cardinalités : - Un client peut acheter 1 à n produits (1,n) - Un produit peut être acheté par 1 à n clients (1,n) - C'est une relation n-n (plusieurs à plusieurs)

Légende : - # : clé primaire - (PK) : Primary Key - Les rectangles représentent les entités - Les losanges (ici simplifiés) représentent les associations

Autre exemple : Relation 1-n

    ┌─────────────────┐         1,1         ┌─────────────────┐
    │   PROFESSEUR    │◄────────────────────┤      COURS      │
    ├─────────────────┤      enseigne       ├─────────────────┤
    │ #ID_Prof (PK)   │                     │ #ID_Cours (PK)  │
    │  Nom            │         1,n         │  Nom_Cours      │
    │  Spécialité     │                     │  Horaire        │
    └─────────────────┘                     └─────────────────┘

Lecture : Un professeur enseigne 1 à n cours. Un cours est enseigné par 1 et 1 seul professeur.

  • L'entité Client possède des attributs comme Nom et Email.
  • L'entité Produit possède des attributs comme Nom_Produit et Prix.
  • L'association Achète représente l'achat d'un produit par un client, avec des attributs comme Date et Quantité.

Pourquoi faire un MCD ?

Le MCD permet de poser une base claire avant d’implémenter. C’est un peu comme un plan d’architecte : mieux vaut tout prévoir avant de commencer à coder.

Du MCD au Schéma Relationnel

Conversion des Entités

Chaque entité du MCD devient une table dans le schéma relationnel. Les attributs des entités deviennent les colonnes des tables.

Exemple :
Entité Client → Table Client(ID_Client, Nom_Client, Email)

Conversion des Associations

Les associations peuvent : - Devenir une table séparée (notamment pour les associations n-n). - Être représentées par une clé étrangère dans une table.

Exemple :
Association achète (entre Client et Produit) devient une table Vente(ID_Vente, ID_Client, ID_Produit, Date).

Exemple complet de schéma relationnel

À partir de notre MCD, voici le schéma relationnel correspondant :

  • Client(ID_Client, Nom_Client, Email)
  • Produit(ID_Produit, Nom_Produit, Prix)
  • Vente(ID_Vente, Date, ID_Client, ID_Produit)

Contraintes d’Intégrité

Intégrité d'Entité

La clé primaire de chaque table doit être unique et non nulle. Elle garantit que chaque enregistrement est identifiable de manière unique.

Exemple :
La clé primaire de la table Client est ID_Client. Deux clients ne peuvent pas avoir le même ID_Client.

Intégrité Référentielle

Les clés étrangères assurent que les relations entre les tables restent cohérentes. Une clé étrangère doit toujours pointer vers une clé primaire existante.

Exemple :
Dans la table Vente, ID_Client est une clé étrangère qui doit correspondre à un ID_Client existant dans la table Client.

Intégrité de Domaine

Chaque attribut doit contenir des valeurs valides en fonction de son type (domaine). Par exemple, un champ Prix doit contenir un nombre positif.

La Normalisation : Optimiser la Base

Introduction à la Normalisation

La normalisation est un processus pour structurer une base et réduire la redondance. Voici les trois premières formes normales (FN).

Première Forme Normale (1NF)

Règle : Chaque colonne contient des valeurs atomiques (indivisibles).

Exemple de table NON en 1NF :

ID_Commande Client Produits
1 Dupont Livre, Stylo, Cahier
2 Martin Clavier

Le champ Produits contient plusieurs valeurs → violation de 1NF.

Table en 1NF :

ID_Commande Client Produit
1 Dupont Livre
1 Dupont Stylo
1 Dupont Cahier
2 Martin Clavier

Chaque cellule contient une seule valeur.

Deuxième Forme Normale (2NF)

Règle : La table est en 1NF ET chaque attribut non-clé dépend de toute la clé primaire (pas seulement d'une partie).

Exemple de table en 1NF mais PAS en 2NF :

ID_Commande ID_Produit Nom_Produit Quantité
1 101 Livre 2
1 102 Stylo 5
2 101 Livre 1

Clé primaire : (ID_Commande, ID_Produit)

Problème : Nom_Produit dépend uniquement de ID_Produit, pas de toute la clé.

Tables en 2NF :

Table Commandes_Produits :

ID_Commande ID_Produit Quantité
1 101 2
1 102 5
2 101 1

Table Produits :

ID_Produit Nom_Produit
101 Livre
102 Stylo

Troisième Forme Normale (3NF)

Règle : La table est en 2NF ET aucun attribut non-clé ne dépend d'un autre attribut non-clé (pas de dépendance transitive).

Exemple de table en 2NF mais PAS en 3NF :

ID_Etudiant Nom ID_Classe Nom_Classe
1 Alice A1 Terminale
2 Bob A1 Terminale
3 Clara B2 Première

Clé primaire : ID_Etudiant

Problème : Nom_Classe dépend de ID_Classe (qui n'est pas la clé) → dépendance transitive.

Tables en 3NF :

Table Etudiants :

ID_Etudiant Nom ID_Classe
1 Alice A1
2 Bob A1
3 Clara B2

Table Classes :

ID_Classe Nom_Classe
A1 Terminale
B2 Première

Résumé des formes normales

Forme Condition
1NF Valeurs atomiques dans chaque cellule
2NF 1NF + pas de dépendance partielle à la clé
3NF 2NF + pas de dépendance transitive

Anecdote : Les erreurs d’un mauvais modèle

Dans les années 2000, un célèbre site de commerce a perdu des milliers d’euros à cause d’une mauvaise conception de sa base de données. Une erreur de relation entre les tables de commande et client a permis à des utilisateurs de modifier leurs commandes après validation… Certains ont payé 1€ pour un téléviseur ! Moralité : une base mal conçue peut coûter très cher.

Conclusion : Une base bien modélisée, c'est un jeu d'enfant

La modélisation est une étape clé dans la conception des bases de données. Avec un bon MCD, un schéma relationnel clair, et des contraintes bien définies, vous serez prêts à créer des bases robustes et cohérentes.

Prochaines étapes : - Créer un MCD pour un projet simple (ex : gestion de bibliothèque, boutique en ligne). - Passer du MCD au schéma relationnel. - Implémenter le tout en SQL.

Et souvenez-vous : "Bien modéliser, c’est éviter les migraines de demain !"

Bibliographie

Auteur : Florian Mathieu

Licence CC BY NC

Licence Creative Commons
Ce cours est mis à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.