From 464631689b621775d34772a83d1400fc8f282c7f Mon Sep 17 00:00:00 2001 From: Florian Mathieu Date: Fri, 15 Nov 2024 08:10:58 +0100 Subject: [PATCH] ajout cours conception bdd et exercices modele relationnel --- BDD_SGBD/CONCEPTION.md | 155 +++++++++++++++++++++++++++++++++++++++++ BDD_SGBD/Exercices.md | 93 +++++++++++++++++++++++++ BDD_SGBD/README.md | 22 +++++- 3 files changed, 268 insertions(+), 2 deletions(-) create mode 100644 BDD_SGBD/CONCEPTION.md create mode 100644 BDD_SGBD/Exercices.md 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 + +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. \ 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