ajout de tous les cours et TP préparés cet été
This commit is contained in:
@@ -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 |
|
||||
|
||||
---
|
||||
|
||||
|
||||
255
BDD_SGBD/Corrige_Exercices.md
Normal file
255
BDD_SGBD/Corrige_Exercices.md
Normal file
@@ -0,0 +1,255 @@
|
||||
# Corrigé : Entraînement sur les Schémas Relationnels
|
||||
|
||||
---
|
||||
|
||||
## 1. Tables initiales (Sandwicherie)
|
||||
|
||||
### Question 1 : Analyse des clés
|
||||
|
||||
**Clés primaires :**
|
||||
|
||||
| Table | Clé primaire | Justification |
|
||||
|-------|-------------|---------------|
|
||||
| Sandwichs | `Nom_Sandwich` | Identifie de manière unique chaque sandwich |
|
||||
| Clients | `ID_Client` | Identifiant unique pour chaque client |
|
||||
| Commandes | `ID_Commande` | Identifiant unique pour chaque commande |
|
||||
|
||||
**Clés étrangères :**
|
||||
|
||||
| Table | Clé étrangère | Référence |
|
||||
|-------|--------------|-----------|
|
||||
| Commandes | `ID_Client` | → Clients(ID_Client) |
|
||||
| Commandes | `Nom_Sandwich` | → Sandwichs(Nom_Sandwich) |
|
||||
|
||||
---
|
||||
|
||||
### Question 2 : Problèmes de modélisation
|
||||
|
||||
**Problèmes identifiés :**
|
||||
|
||||
1. **Clé primaire de Sandwichs** : Utiliser `Nom_Sandwich` comme clé primaire pose problème si deux sandwichs ont le même nom ou si on renomme un sandwich. Il vaudrait mieux ajouter un `ID_Sandwich`.
|
||||
|
||||
2. **Redondance potentielle** : Si un client commande plusieurs fois le même sandwich, le nom du sandwich est répété.
|
||||
|
||||
3. **Pas de gestion des quantités multiples** : Une commande ne peut contenir qu'un seul type de sandwich. Si un client veut commander 2 Cheeseburgers ET 1 Italien, il faut 2 commandes.
|
||||
|
||||
**Schéma amélioré :**
|
||||
|
||||
```
|
||||
Sandwichs(#ID_Sandwich, Nom_Sandwich, Type, Prix)
|
||||
Clients(#ID_Client, Nom, Prénom, Adresse)
|
||||
Commandes(#ID_Commande, Date, ID_Client*)
|
||||
Lignes_Commande(#ID_Commande*, #ID_Sandwich*, Quantité)
|
||||
```
|
||||
|
||||
Avec cette structure :
|
||||
- Une commande peut contenir plusieurs sandwichs différents
|
||||
- On utilise des identifiants numériques comme clés primaires
|
||||
|
||||
---
|
||||
|
||||
## 3. Modélisation d'une base pour un forum
|
||||
|
||||
### Question 1 : Schéma de la table Users
|
||||
|
||||
```
|
||||
Users(#ID_User, Pseudonyme, Email, Role, Date_Inscription)
|
||||
```
|
||||
|
||||
- `ID_User` : clé primaire (entier auto-incrémenté)
|
||||
- `Pseudonyme` : chaîne de caractères, UNIQUE
|
||||
- `Email` : chaîne de caractères, UNIQUE
|
||||
- `Role` : chaîne de caractères (ex: "membre", "modérateur", "admin")
|
||||
- `Date_Inscription` : date
|
||||
|
||||
### Question 2 : Schéma de la table Posts
|
||||
|
||||
```
|
||||
Posts(#ID_Post, Titre, Contenu, Date_Publication, ID_User*)
|
||||
```
|
||||
|
||||
- `ID_Post` : clé primaire
|
||||
- `Titre` : chaîne de caractères
|
||||
- `Contenu` : texte long
|
||||
- `Date_Publication` : date et heure
|
||||
- `ID_User` : clé étrangère vers Users
|
||||
|
||||
### Question 3 : Clés primaires et étrangères
|
||||
|
||||
| Table | Clé primaire | Clé(s) étrangère(s) |
|
||||
|-------|-------------|---------------------|
|
||||
| Users | `ID_User` | Aucune |
|
||||
| Posts | `ID_Post` | `ID_User` → Users(ID_User) |
|
||||
|
||||
### Question 4 : Gestion des modifications de pseudonymes
|
||||
|
||||
**Problème** : Si on utilise le pseudonyme comme référence dans d'autres tables, tout changement de pseudo nécessiterait de modifier toutes les références.
|
||||
|
||||
**Solution** : Utiliser `ID_User` (clé primaire numérique) comme référence dans les autres tables. Ainsi, le pseudonyme peut être modifié librement dans la table Users sans impacter les autres tables.
|
||||
|
||||
C'est pourquoi on préfère toujours utiliser un identifiant numérique comme clé primaire plutôt qu'un attribut "métier" comme le pseudonyme.
|
||||
|
||||
---
|
||||
|
||||
## 4. Extension : Albums sur le forum
|
||||
|
||||
### Question 1 : Modèle Entité-Association
|
||||
|
||||
```
|
||||
┌─────────────────┐ ┌─────────────────┐
|
||||
│ USER │ │ POST │
|
||||
├─────────────────┤ ├─────────────────┤
|
||||
│ #ID_User (PK) │ │ #ID_Post (PK) │
|
||||
│ Pseudonyme │ 1,n │ Titre │
|
||||
│ Email │◄──────────────────────────┤ Contenu │
|
||||
└────────┬────────┘ écrit │ Date │
|
||||
│ └────────┬────────┘
|
||||
│ 1,n │ 0,n
|
||||
│ │
|
||||
│ ┌─────────────────┐ │
|
||||
└────────►│ ALBUM │ │
|
||||
├─────────────────┤ │
|
||||
possède │ #ID_Album (PK) │ contient │
|
||||
│ Nom_Album │◄────────────────┘
|
||||
│ Date_Creation │ 0,n
|
||||
└─────────────────┘
|
||||
```
|
||||
|
||||
**Cardinalités** :
|
||||
- Un utilisateur possède 0 à n albums (0,n)
|
||||
- Un album appartient à 1 et 1 seul utilisateur (1,1)
|
||||
- Un album contient 0 à n posts (0,n)
|
||||
- Un post peut être dans 0 à n albums (0,n)
|
||||
|
||||
### Question 2 : Schéma Relationnel
|
||||
|
||||
```
|
||||
Users(#ID_User, Pseudonyme, Email, Role)
|
||||
Posts(#ID_Post, Titre, Contenu, Date, ID_User*)
|
||||
Albums(#ID_Album, Nom_Album, Date_Creation, ID_User*)
|
||||
Album_Posts(#ID_Album*, #ID_Post*)
|
||||
```
|
||||
|
||||
La table `Album_Posts` est une **table de liaison** nécessaire pour la relation n-n entre Albums et Posts.
|
||||
|
||||
### Question 3 : Exemple d'enregistrements
|
||||
|
||||
**Table Users :**
|
||||
|
||||
| ID_User | Pseudonyme | Email | Role |
|
||||
|---------|------------|-------|------|
|
||||
| 1 | GameMaster42 | gm42@mail.com | membre |
|
||||
|
||||
**Table Posts :**
|
||||
|
||||
| ID_Post | Titre | Contenu | Date | ID_User |
|
||||
|---------|-------|---------|------|---------|
|
||||
| 101 | Mon avis sur Zelda | Super jeu... | 2026-01-15 | 1 |
|
||||
| 102 | Guide débutant | Voici mes conseils... | 2026-01-16 | 1 |
|
||||
|
||||
**Table Albums :**
|
||||
|
||||
| ID_Album | Nom_Album | Date_Creation | ID_User |
|
||||
|----------|-----------|---------------|---------|
|
||||
| 1 | Mes meilleurs posts gaming | 2026-01-17 | 1 |
|
||||
|
||||
**Table Album_Posts :**
|
||||
|
||||
| ID_Album | ID_Post |
|
||||
|----------|---------|
|
||||
| 1 | 101 |
|
||||
| 1 | 102 |
|
||||
|
||||
---
|
||||
|
||||
## 5. Normalisation : Exemple pour un lycée
|
||||
|
||||
### Question 1 : Schéma relationnel actuel
|
||||
|
||||
```
|
||||
Eleves(Nom, Prénom, Date_Naissance, Classe, Option1, Option2, Option3)
|
||||
```
|
||||
|
||||
### Question 2 : Clé primaire et clés étrangères
|
||||
|
||||
**Clé primaire** : Il n'y a pas de clé primaire clairement définie. On pourrait utiliser `(Nom, Prénom, Date_Naissance)` mais ce n'est pas idéal (deux élèves peuvent avoir le même nom et être nés le même jour).
|
||||
|
||||
**Clés étrangères** : Aucune. La table est isolée.
|
||||
|
||||
### Question 3 : Défauts de conception
|
||||
|
||||
1. **Pas de clé primaire fiable** : Le couple (Nom, Prénom) n'est pas unique (deux "Michel" existent).
|
||||
|
||||
2. **Violation de 1NF** : Les colonnes Option1, Option2, Option3 représentent la même information (une option). C'est une répétition de groupe.
|
||||
|
||||
3. **Valeurs NULL** : Beaucoup de valeurs NULL pour les options non choisies.
|
||||
|
||||
4. **Pas de normalisation** : La classe est répétée pour chaque élève de la même classe.
|
||||
|
||||
5. **Rigidité** : Si un élève prend 4 options, il faut modifier la structure de la table.
|
||||
|
||||
### Amélioration : Schéma normalisé
|
||||
|
||||
```
|
||||
Eleves(#ID_Eleve, Nom, Prénom, Date_Naissance, ID_Classe*)
|
||||
Classes(#ID_Classe, Nom_Classe)
|
||||
Options(#ID_Option, Nom_Option)
|
||||
Eleves_Options(#ID_Eleve*, #ID_Option*)
|
||||
```
|
||||
|
||||
**Tables résultantes :**
|
||||
|
||||
**Table Eleves :**
|
||||
|
||||
| ID_Eleve | Nom | Prénom | Date_Naissance | ID_Classe |
|
||||
|----------|-----|--------|----------------|-----------|
|
||||
| 1 | Alan | Michel | 12/12/2005 | 1 |
|
||||
| 2 | Bergue | John | 13/01/2006 | 1 |
|
||||
| 3 | Zidane | Michel | 12/12/2005 | 2 |
|
||||
| 4 | Bergue | Inès | 06/04/2004 | 3 |
|
||||
|
||||
**Table Classes :**
|
||||
|
||||
| ID_Classe | Nom_Classe |
|
||||
|-----------|------------|
|
||||
| 1 | 2de1 |
|
||||
| 2 | 1S2 |
|
||||
| 3 | T-STL |
|
||||
|
||||
**Table Options :**
|
||||
|
||||
| ID_Option | Nom_Option |
|
||||
|-----------|------------|
|
||||
| 1 | CIT |
|
||||
| 2 | Chinois |
|
||||
| 3 | Latin |
|
||||
| 4 | Maths |
|
||||
| 5 | Physique |
|
||||
| 6 | NSI |
|
||||
|
||||
**Table Eleves_Options :**
|
||||
|
||||
| ID_Eleve | ID_Option |
|
||||
|----------|-----------|
|
||||
| 1 | 1 |
|
||||
| 1 | 2 |
|
||||
| 2 | 1 |
|
||||
| 2 | 2 |
|
||||
| 2 | 3 |
|
||||
| 3 | 4 |
|
||||
| 3 | 5 |
|
||||
| 3 | 6 |
|
||||
|
||||
**Avantages du nouveau schéma :**
|
||||
- Chaque élève a un identifiant unique
|
||||
- Plus de colonnes Option1/2/3 : on peut avoir n'importe quel nombre d'options
|
||||
- Les noms de classes ne sont plus répétés
|
||||
- Conforme aux formes normales 1NF, 2NF et 3NF
|
||||
|
||||
---
|
||||
|
||||
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>.
|
||||
@@ -1,4 +1,4 @@
|
||||
### Entraînement sur les Schémas Relationnels
|
||||
# Entraînement sur les Schémas Relationnels
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -90,4 +90,12 @@ Chaque utilisateur peut créer un ou plusieurs **albums** contenant des messages
|
||||
3. Quels sont les défauts de conception (redondance, incohérences) ?
|
||||
|
||||
### **Amélioration** :
|
||||
- Proposez un schéma relationnel alternatif pour corriger ces défauts.
|
||||
- Proposez un schéma relationnel alternatif pour corriger ces défauts.
|
||||
|
||||
---
|
||||
|
||||
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>.
|
||||
@@ -1,4 +1,4 @@
|
||||
## Conception des bases de données
|
||||
# Conception des bases de données
|
||||
|
||||
|
||||
|
||||
@@ -60,10 +60,10 @@ Supposons que vous ajoutiez une colonne pour l'éditeur de chaque jeu :
|
||||
|
||||
Ici, "Nintendo" est répété plusieurs fois. En cas d'erreur de saisie (`Nintnedo`), les données deviennent incohérentes.
|
||||
|
||||
#### **1.2.2 Difficile à maintenir**
|
||||
#### Difficile à maintenir
|
||||
Si l'éditeur de "Zelda" change, il faut parcourir tout le tableau pour le modifier, ce qui est fastidieux et sujet aux erreurs.
|
||||
|
||||
#### **1.2.3 Limite des relations**
|
||||
#### Limite des relations
|
||||
Il devient complexe de représenter les relations entre différentes entités. Par exemple, comment savoir quel client a acheté quel jeu ? Cela nécessiterait des tableaux imbriqués ou des fichiers séparés, augmentant le risque d'incohérences.
|
||||
|
||||
---
|
||||
|
||||
@@ -115,7 +115,7 @@ Dans les années 1990, une banque a oublié d’appliquer la contrainte d’int
|
||||
|
||||
Le modèle relationnel repose sur des concepts simples mais puissants. Les clés primaires et étrangères permettent de lier les données de manière cohérente, tandis que les contraintes d'intégrité assurent la fiabilité des informations.
|
||||
|
||||
**Pousuite :** nous verrons comment utiliser le langage SQL pour manipuler ces données et appliquer ces contraintes.
|
||||
**Poursuite :** nous verrons comment utiliser le langage SQL pour manipuler ces données et appliquer ces contraintes.
|
||||
|
||||
Et souvenez-vous : "Une base bien modélisée est comme une maison bien construite : elle résistera aux tempêtes (ou presque) !"
|
||||
|
||||
|
||||
380
BDD_SGBD/TP_StreamFlix.md
Normal file
380
BDD_SGBD/TP_StreamFlix.md
Normal file
@@ -0,0 +1,380 @@
|
||||
# TP : Modéliser StreamFlix - La base de données d'une plateforme de streaming
|
||||
|
||||
> **Thème** : Conception de bases de données et schémas relationnels
|
||||
|
||||
---
|
||||
|
||||
## Contexte
|
||||
|
||||
En 2026, les plateformes de streaming (Netflix, Disney+, Prime Video, Apple TV+) dominent le marché du divertissement. Derrière leurs interfaces élégantes se cachent des **bases de données massives** qui gèrent des millions d'utilisateurs, de contenus et de visionnages.
|
||||
|
||||
Vous êtes embauché(e) comme stagiaire chez **StreamFlix**, une nouvelle plateforme de streaming française qui veut concurrencer les géants américains. Votre mission : **concevoir la base de données** qui fera tourner la plateforme.
|
||||
|
||||
---
|
||||
|
||||
## Partie 1 : Analyse des besoins
|
||||
|
||||
### Les fonctionnalités de StreamFlix
|
||||
|
||||
La plateforme doit permettre :
|
||||
- Aux utilisateurs de **créer un compte** et de **s'abonner**
|
||||
- De **parcourir un catalogue** de films et séries
|
||||
- De **regarder** des contenus et de **reprendre** là où on s'est arrêté
|
||||
- De créer une **liste de favoris** ("Ma Liste")
|
||||
- De **noter** les contenus (1 à 5 étoiles)
|
||||
|
||||
### Exercice 1 : Identifier les entités
|
||||
|
||||
À partir de la description ci-dessus, identifiez les **entités** principales de la base de données.
|
||||
|
||||
**Indice** : Une entité est un "objet" du monde réel qu'on souhaite représenter. Pensez aux noms communs dans la description.
|
||||
|
||||
---
|
||||
|
||||
## Partie 2 : Le Modèle Entité-Association
|
||||
|
||||
### Exercice 2 : Définir les attributs
|
||||
|
||||
Pour chaque entité identifiée, listez les **attributs** pertinents.
|
||||
|
||||
**Exemple** :
|
||||
```
|
||||
Entité : Utilisateur
|
||||
Attributs : ID, Email, Mot_de_passe, Nom, Prénom, Date_naissance, Date_inscription
|
||||
```
|
||||
|
||||
Faites de même pour :
|
||||
- Film
|
||||
- Série
|
||||
- Épisode
|
||||
- Abonnement
|
||||
|
||||
### Exercice 3 : Identifier les associations
|
||||
|
||||
Quelles sont les **relations** entre les entités ? Pour chaque relation, précisez :
|
||||
- Les entités concernées
|
||||
- Le nom de l'association
|
||||
- Les **cardinalités** (1-1, 1-n, n-n)
|
||||
|
||||
**Exemple** :
|
||||
```
|
||||
Utilisateur ---< possède >--- Abonnement
|
||||
Cardinalités : Un utilisateur possède 0 ou 1 abonnement actif.
|
||||
Un abonnement appartient à 1 et 1 seul utilisateur.
|
||||
→ Relation 1-1
|
||||
```
|
||||
|
||||
### Exercice 4 : Dessiner le MCD
|
||||
|
||||
Représentez le **Modèle Conceptuel de Données** complet sous forme de schéma.
|
||||
|
||||
Utilisez la notation suivante :
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐
|
||||
│ ENTITE1 │ │ ENTITE2 │
|
||||
├─────────────┤ 1,n ├─────────────┤
|
||||
│ #clé │◄───────►│ #clé │
|
||||
│ attribut1 │ nom │ attribut1 │
|
||||
│ attribut2 │ │ attribut2 │
|
||||
└─────────────┘ └─────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Partie 3 : Du MCD au Schéma Relationnel
|
||||
|
||||
### Rappel des règles de conversion
|
||||
|
||||
| Élément MCD | Conversion en relationnel |
|
||||
|-------------|---------------------------|
|
||||
| Entité | Table |
|
||||
| Attribut | Colonne |
|
||||
| Association 1-1 | Clé étrangère dans l'une des tables |
|
||||
| Association 1-n | Clé étrangère côté "n" |
|
||||
| Association n-n | Table de liaison |
|
||||
|
||||
### Exercice 5 : Convertir en schéma relationnel
|
||||
|
||||
Transformez votre MCD en **schéma relationnel**. Utilisez la notation :
|
||||
|
||||
```
|
||||
NomTable(#cle_primaire, attribut1, attribut2, cle_etrangere*)
|
||||
```
|
||||
|
||||
**Convention** :
|
||||
- `#` indique la clé primaire
|
||||
- `*` indique une clé étrangère
|
||||
|
||||
---
|
||||
|
||||
## Partie 4 : La gestion des visionnages
|
||||
|
||||
### Le problème
|
||||
|
||||
StreamFlix veut permettre aux utilisateurs de **reprendre un contenu là où ils l'ont arrêté**. Il faut donc enregistrer :
|
||||
- Quel utilisateur a regardé quel contenu
|
||||
- À quelle date/heure
|
||||
- Jusqu'à quelle minute du contenu
|
||||
- Si le visionnage est terminé ou non
|
||||
|
||||
### Exercice 6 : Modéliser les visionnages
|
||||
|
||||
1. Créez une entité/table `Visionnage` avec les attributs appropriés.
|
||||
2. Quelles sont les clés étrangères nécessaires ?
|
||||
3. Quelle est la clé primaire de cette table ?
|
||||
|
||||
**Réflexion** : Un utilisateur peut-il regarder le même contenu plusieurs fois ? Comment gérer ce cas ?
|
||||
|
||||
---
|
||||
|
||||
## Partie 5 : Les contraintes d'intégrité
|
||||
|
||||
### Exercice 7 : Identifier les contraintes
|
||||
|
||||
Pour chaque table de votre schéma, identifiez :
|
||||
- Les contraintes d'**intégrité d'entité** (clé primaire unique et non nulle)
|
||||
- Les contraintes d'**intégrité référentielle** (clés étrangères valides)
|
||||
- Les contraintes de **domaine** (types de données, valeurs autorisées)
|
||||
|
||||
**Exemple** :
|
||||
```
|
||||
Table Utilisateur :
|
||||
- ID_Utilisateur : entier, clé primaire, non nul, unique
|
||||
- Email : chaîne, non nul, unique, format email valide
|
||||
- Date_naissance : date, non nul, doit être dans le passé
|
||||
```
|
||||
|
||||
### Exercice 8 : Que se passe-t-il si...
|
||||
|
||||
Répondez aux questions suivantes en justifiant :
|
||||
|
||||
1. On essaie d'insérer un utilisateur avec un email déjà existant ?
|
||||
2. On essaie de supprimer un film qui a été visionné par des utilisateurs ?
|
||||
3. On essaie d'ajouter un visionnage pour un utilisateur qui n'existe pas ?
|
||||
|
||||
---
|
||||
|
||||
## Partie 6 : Normalisation
|
||||
|
||||
### Exercice 9 : Vérifier la normalisation
|
||||
|
||||
Voici une proposition de table pour gérer les séries :
|
||||
|
||||
| ID_Serie | Titre | Genre | Nb_Saisons | Acteur1 | Acteur2 | Acteur3 |
|
||||
|----------|-------|-------|------------|---------|---------|---------|
|
||||
| 1 | Stranger Things | SF | 5 | Millie Bobby Brown | Finn Wolfhard | Gaten Matarazzo |
|
||||
| 2 | The Crown | Drame | 6 | Claire Foy | Olivia Colman | Imelda Staunton |
|
||||
|
||||
1. Cette table est-elle en **1NF** ? Pourquoi ?
|
||||
2. Proposez un schéma **normalisé** pour gérer les séries et leurs acteurs.
|
||||
|
||||
---
|
||||
|
||||
## Partie 7 : Schéma final
|
||||
|
||||
### Exercice 10 : Synthèse
|
||||
|
||||
Proposez le **schéma relationnel complet** de StreamFlix avec :
|
||||
- Toutes les tables
|
||||
- Toutes les clés (primaires et étrangères)
|
||||
- Les types de données principaux
|
||||
|
||||
### Exemple de format attendu
|
||||
|
||||
```
|
||||
Utilisateurs(
|
||||
#ID_Utilisateur INT,
|
||||
Email VARCHAR(255) UNIQUE NOT NULL,
|
||||
Mot_de_passe VARCHAR(255) NOT NULL,
|
||||
Nom VARCHAR(100),
|
||||
Prénom VARCHAR(100),
|
||||
Date_naissance DATE,
|
||||
Date_inscription DATE DEFAULT CURRENT_DATE
|
||||
)
|
||||
|
||||
Films(
|
||||
#ID_Film INT,
|
||||
Titre VARCHAR(255) NOT NULL,
|
||||
...
|
||||
)
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Bonus : Pour aller plus loin
|
||||
|
||||
### Réflexion 1 : L'algorithme de recommandation
|
||||
|
||||
Netflix utilise un algorithme de recommandation basé sur :
|
||||
- Les contenus déjà visionnés
|
||||
- Les notes attribuées
|
||||
- Les contenus similaires (même genre, mêmes acteurs)
|
||||
|
||||
Quelles informations de notre base de données seraient utiles pour cet algorithme ?
|
||||
|
||||
### Réflexion 2 : Passage à l'échelle
|
||||
|
||||
StreamFlix a maintenant 10 millions d'utilisateurs et chacun regarde en moyenne 2 contenus par jour.
|
||||
|
||||
1. Combien d'enregistrements sont ajoutés dans la table `Visionnage` chaque jour ?
|
||||
2. Quels problèmes cela peut-il poser ?
|
||||
3. Avez-vous entendu parler des bases de données **NoSQL** ? Pourquoi pourraient-elles être utiles ici ?
|
||||
|
||||
---
|
||||
|
||||
## Résumé des notions travaillées
|
||||
|
||||
| Notion | Application dans ce TP |
|
||||
|--------|------------------------|
|
||||
| Entité | Utilisateur, Film, Série, etc. |
|
||||
| Attribut | Email, Titre, Durée, etc. |
|
||||
| Association | "regarde", "possède", etc. |
|
||||
| Clé primaire | ID_Utilisateur, ID_Film |
|
||||
| Clé étrangère | ID_Utilisateur dans Visionnage |
|
||||
| Cardinalités | 1-1, 1-n, n-n |
|
||||
| Contraintes d'intégrité | Unicité, référence, domaine |
|
||||
| Normalisation | Éviter la redondance |
|
||||
|
||||
---
|
||||
|
||||
## Annexe : Schéma relationnel de référence (corrigé)
|
||||
|
||||
<details>
|
||||
<summary>Cliquez pour afficher le corrigé</summary>
|
||||
|
||||
```
|
||||
Utilisateurs(
|
||||
#ID_Utilisateur,
|
||||
Email,
|
||||
Mot_de_passe,
|
||||
Nom,
|
||||
Prenom,
|
||||
Date_naissance,
|
||||
Date_inscription
|
||||
)
|
||||
|
||||
Abonnements(
|
||||
#ID_Abonnement,
|
||||
Type, -- "Basic", "Standard", "Premium"
|
||||
Prix_mensuel,
|
||||
Date_debut,
|
||||
Date_fin,
|
||||
ID_Utilisateur*
|
||||
)
|
||||
|
||||
Films(
|
||||
#ID_Film,
|
||||
Titre,
|
||||
Annee,
|
||||
Duree_minutes,
|
||||
Synopsis,
|
||||
ID_Genre*
|
||||
)
|
||||
|
||||
Series(
|
||||
#ID_Serie,
|
||||
Titre,
|
||||
Annee_debut,
|
||||
Annee_fin,
|
||||
Synopsis,
|
||||
ID_Genre*
|
||||
)
|
||||
|
||||
Episodes(
|
||||
#ID_Episode,
|
||||
Numero_saison,
|
||||
Numero_episode,
|
||||
Titre,
|
||||
Duree_minutes,
|
||||
ID_Serie*
|
||||
)
|
||||
|
||||
Genres(
|
||||
#ID_Genre,
|
||||
Nom_genre
|
||||
)
|
||||
|
||||
Acteurs(
|
||||
#ID_Acteur,
|
||||
Nom,
|
||||
Prenom,
|
||||
Date_naissance
|
||||
)
|
||||
|
||||
Films_Acteurs(
|
||||
#ID_Film*,
|
||||
#ID_Acteur*,
|
||||
Role
|
||||
)
|
||||
|
||||
Series_Acteurs(
|
||||
#ID_Serie*,
|
||||
#ID_Acteur*,
|
||||
Role
|
||||
)
|
||||
|
||||
Visionnages(
|
||||
#ID_Visionnage,
|
||||
Date_heure,
|
||||
Minute_arret,
|
||||
Est_termine,
|
||||
ID_Utilisateur*,
|
||||
ID_Film*, -- NULL si c'est un épisode
|
||||
ID_Episode* -- NULL si c'est un film
|
||||
)
|
||||
|
||||
MaListe(
|
||||
#ID_Utilisateur*,
|
||||
#ID_Film*, -- ou ID_Serie selon le contenu
|
||||
Date_ajout
|
||||
)
|
||||
|
||||
Notes(
|
||||
#ID_Utilisateur*,
|
||||
#ID_Film*, -- ou ID_Serie
|
||||
Note, -- 1 à 5
|
||||
Date_note
|
||||
)
|
||||
```
|
||||
|
||||
**MCD correspondant** :
|
||||
|
||||
```
|
||||
┌──────────────┐ 1,1 ┌──────────────┐
|
||||
│ UTILISATEUR │◄────────────┤ ABONNEMENT │
|
||||
├──────────────┤ possède ├──────────────┤
|
||||
│ #ID │ │ #ID │
|
||||
│ Email │ │ Type │
|
||||
│ Nom │ │ Prix │
|
||||
└──────┬───────┘ └──────────────┘
|
||||
│
|
||||
│ 0,n
|
||||
│
|
||||
▼ 0,n ┌──────────────┐
|
||||
REGARDE ─────────────────► │ FILM │
|
||||
│ ├──────────────┤
|
||||
│ │ #ID │
|
||||
│ │ Titre │
|
||||
│ 0,n │ Duree │
|
||||
│ └──────────────┘
|
||||
▼
|
||||
┌──────────────┐
|
||||
│ EPISODE │◄──── appartient ──── SERIE
|
||||
├──────────────┤ 1,n
|
||||
│ #ID │
|
||||
│ Numero │
|
||||
│ Titre │
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
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>.
|
||||
Reference in New Issue
Block a user