ajout cours conception bdd et exercices modele relationnel
This commit is contained in:
155
BDD_SGBD/CONCEPTION.md
Normal file
155
BDD_SGBD/CONCEPTION.md
Normal file
@@ -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
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt="Licence Creative Commons" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png" /></a> <br />Ce cours est mis à disposition selon les termes de la <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International</a>.
|
||||
93
BDD_SGBD/Exercices.md
Normal file
93
BDD_SGBD/Exercices.md
Normal file
@@ -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.
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user