diff --git a/BDD_SGBD/CONCEPTION.md b/BDD_SGBD/CONCEPTION.md
new file mode 100644
index 0000000..da59b0a
--- /dev/null
+++ b/BDD_SGBD/CONCEPTION.md
@@ -0,0 +1,155 @@
+## 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.
+
+Dans ce cours, nous allons découvrir comment bien modéliser une base de données en utilisant le **Modèle Conceptuel de Données (MCD)** et le **Schéma Relationnel**.
+
+---------
+
+### 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. Imagine 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] — achète —< [Vente] >— concerne —> [Produit]
+
+
+
+- L'entité **Client** possède des attributs comme `Nom` et `Email`.
+- L'entité **Produit** possède des attributs comme `Nom_Produit` et `Prix`.
+- L'entité **Vente** représente l'achat d'un produit par un client, avec des attributs comme `Date`.
+
+#### 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) :
+1. **1NF** : Chaque colonne contient des valeurs atomiques.
+2. **2NF** : Les colonnes dépendent entièrement de la clé primaire.
+3. **3NF** : Pas de dépendance transitives entre attributs.
+
+Un peu technique, mais rassure-toi, nous n’allons pas tout voir aujourd’hui !
+
+---
+
+## 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
+
+- Prépabac (Hatier)
+- [Site de Gilles Lassus](https://glassus.github.io/terminale_nsi/)
+
+-----------
+
+Auteur : Florian Mathieu
+
+Licence CC BY NC
+
+
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.
\ No newline at end of file
diff --git a/BDD_SGBD/Exercices.md b/BDD_SGBD/Exercices.md
new file mode 100644
index 0000000..085facd
--- /dev/null
+++ b/BDD_SGBD/Exercices.md
@@ -0,0 +1,93 @@
+### Entraînement sur les Schémas Relationnels
+
+## Introduction
+
+Nous disposons d'une base de données pour une sandwicherie. Voici les tables de cette base, comprenant des informations sur les sandwichs proposés, les clients, et les commandes passées.
+
+---
+
+## 1. Tables initiales
+
+### **Table : Sandwichs**
+
+| Nom_Sandwich | Type | Prix |
+| ------------- | ------------- | ---- |
+| Cheeseburger | Classique | 3.98 |
+| Double cheese | Classique | 4.90 |
+| Italien | Végétarien | 4.90 |
+| Foie gras | Gastronomique | 8.50 |
+
+### **Table : Clients**
+
+| ID_Client | Nom | Prénom | Adresse |
+| --------- | ------- | ------ | ---------------------------- |
+| 1 | Bernard | Alain | 9, rue Bienvenu, Marseille |
+| 2 | Bernard | Yves | 2, rue Vive la Joie, Aubagne |
+| 3 | Dupont | Sophie | 154, boulevard Aune, Lyon |
+
+### **Table : Commandes**
+
+| ID_Commande | Date | ID_Client | Nom_Sandwich | Quantité |
+| ----------- | ---------- | --------- | ------------ | -------- |
+| 12452 | 2019-12-11 | 1 | Italien | 2 |
+| 12453 | 2019-12-11 | 2 | Foie gras | 1 |
+| 13301 | 2019-12-23 | 3 | Cheeseburger | 3 |
+
+---
+
+## 2. Questions pour réflexion
+
+1. **Analyse des clés** :
+ - Quelle est la **clé primaire** de chaque table ?
+ - Les tables comportent-elles des **clés étrangères** ? Si oui, lesquelles ?
+
+2. **Problèmes de modélisation** :
+ - La base est-elle bien modélisée ?
+ - Proposez des améliorations pour éviter la redondance et mieux gérer les relations.
+
+---
+
+## 3. Modélisation d'une base pour un forum
+
+### **Contexte** :
+On souhaite modéliser une base de données simplifiée pour un **forum en ligne** avec deux tables principales :
+- **Users** : contenant des informations sur les utilisateurs (pseudonyme, email, rôle).
+- **Posts** : contenant des informations sur les messages (titre, contenu, date, auteur).
+
+### **Questions** :
+1. Quel serait le schéma relationnel de la table **Users** ?
+2. Quel serait celui de la table **Posts** ?
+3. Les tables comportent-elles des **clés primaires** ou **clés étrangères** ? Si oui, lesquelles ?
+4. Comment gérer les modifications de pseudonymes des utilisateurs ?
+
+---
+
+## 4. Extension : Albums sur le forum
+
+### **Nouvelle fonctionnalité** :
+Chaque utilisateur peut créer un ou plusieurs **albums** contenant des messages du forum.
+
+1. **Modèle Entité-Association** : Dessinez un modèle entité-association pour cette fonctionnalité.
+2. **Schéma Relationnel** : Proposez un schéma relationnel cohérent.
+3. Donnez un exemple d’enregistrement pour illustrer le fonctionnement.
+
+---
+
+## 5. Normalisation : Exemple pour un lycée
+
+### **Extrait initial** :
+
+| Nom | Prénom | Date_Naissance | Classe | Option1 | Option2 | Option3 |
+| ------ | ------ | -------------- | ------ | ------- | -------- | ------- |
+| Alan | Michel | 12/12/2005 | 2de1 | CIT | Chinois | NULL |
+| Bergue | John | 13/01/2006 | 2de1 | CIT | Chinois | Latin |
+| Zidane | Michel | 12/12/2005 | 1S2 | Maths | Physique | NSI |
+| Bergue | Inès | 06/04/2004 | T-STL | NULL | NULL | NULL |
+
+### **Problèmes** :
+1. Quel est le schéma relationnel de cette base ?
+2. La table contient-elle une **clé primaire** ? Des **clés étrangères** ?
+3. Quels sont les défauts de conception (redondance, incohérences) ?
+
+### **Amélioration** :
+- Proposez un schéma relationnel alternatif pour corriger ces défauts.
\ No newline at end of file
diff --git a/BDD_SGBD/README.md b/BDD_SGBD/README.md
index 1bbacd2..8d2340d 100644
--- a/BDD_SGBD/README.md
+++ b/BDD_SGBD/README.md
@@ -34,8 +34,6 @@ Ces derniers ont plusieurs fonctions dont 4 qui sont primordiales :
Mais avant de voir comment ces SGBD fonctionnent, voyons les limites des autres systèmes de gestion de données.
-
-
## Les limites des structures plates
### Définition d'une structure plate
@@ -110,6 +108,26 @@ Un schéma relationnel décrit l'organisation des tables et les relations entre
- **Clients**(ID_client, Nom_client)
- **Ventes**(ID_vente, ID_jeu, ID_client)
+-----------
+
+### Mots clés
+
+| Mot | Définition |
+| --------------------------- | ------------------------------------------------------------ |
+| **Attribut** | Colonne d'une table, représentant une propriété ou caractéristique d'une entité. |
+| **Domaine** | Ensemble des valeurs possibles pour un attribut donné. |
+| **Schéma** | Description formelle des structures d'une base de données (tables, relations, clés, etc.). |
+| **Table / Relation** | Structure contenant des données sous forme de lignes (enregistrements) et de colonnes (attributs). |
+| **Élément (Tuple)** | Ligne d’une table, représentant un enregistrement unique. |
+| **Cardinal** | Nombre de lignes (tuples) dans une table. |
+| **Clé primaire** | Attribut ou combinaison d'attributs permettant d'identifier de manière unique chaque enregistrement d'une table. |
+| **Clé étrangère** | Attribut d’une table qui fait référence à une clé primaire d'une autre table, établissant une relation entre elles. |
+| **Index** | Structure de données qui améliore les performances des recherches dans une table. |
+| **Relation** | Lien logique entre deux tables, souvent via des clés primaires et étrangères. |
+| **Intégrité référentielle** | Contrainte qui garantit que les clés étrangères pointent vers des valeurs existantes dans les tables référencées. |
+| **Intégrité d'entité** | Contrainte qui garantit que la clé primaire est unique et non nulle pour chaque enregistrement. |
+| **Jointure** | Opération qui permet de combiner des données issues de plusieurs tables en utilisant des relations logiques définies entre elles. |
+
---
## Conclusion : De la théorie à la pratique