ajout de tous les cours et TP préparés cet été

This commit is contained in:
2026-01-17 23:10:49 +01:00
parent ed9415bc81
commit 301cf5a98f
125 changed files with 21614 additions and 542 deletions

View File

@@ -42,13 +42,58 @@ Le **Modèle Conceptuel de Données (MCD)**, ou **Modèle Entité-Association**,
Imaginons une boutique où des clients achètent des produits.
[Client] — achète —< [Vente] >— concerne —> [Produit]
```
┌─────────────────┐ ┌─────────────────┐
│ 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'entité **Vente** représente l'achat d'un produit par un client, avec des attributs comme `Date`.
- 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 ?
@@ -109,10 +154,113 @@ Chaque attribut doit contenir des valeurs valides en fonction de son type (domai
#### 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.
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 |
---