ajout repertoire et cours bdd sgbd
This commit is contained in:
104
BDD_SGBD/README.md
Normal file
104
BDD_SGBD/README.md
Normal file
@@ -0,0 +1,104 @@
|
||||
## Conception des bases de données
|
||||
|
||||
## Introduction : Pourquoi les bases de données ?
|
||||
|
||||
> Imaginez que vous soyez responsable d'un magasin de jeux vidéo. Vous commencez par gérer vos stocks sur un simple fichier Excel : titre du jeu, console, stock disponible. Tout va bien, jusqu'à ce que les ventes explosent ! Vous vous retrouvez avec des centaines de jeux, des promotions à gérer, des clients à fidéliser… et là, votre fichier Excel montre ses limites : lenteur, erreurs de saisie, données dupliquées. **Bienvenue dans le monde des bases de données !**
|
||||
|
||||
Les bases de données permettent de structurer, organiser et interroger les données de manière efficace. Avant d'aller plus loin, faisons un petit détour historique.
|
||||
|
||||
### Anecdote historique : Edgar Codd et les bases relationnelles
|
||||
Dans les années 1970, un certain **Edgar F. Codd**, mathématicien chez IBM, invente le modèle relationnel, qui repose sur des tables reliées entre elles par des relations logiques. Ce modèle, simple mais puissant, révolutionne la manière dont les données sont gérées.
|
||||
|
||||
---
|
||||
|
||||
## 1. Les limites des structures plates
|
||||
|
||||
### **1.1 Définition d'une structure plate**
|
||||
Une structure plate est un tableau bidimensionnel, comme une feuille Excel ou une table simple dans un fichier CSV. Chaque ligne représente un enregistrement, et chaque colonne, un attribut (ou champ). Exemple :
|
||||
|
||||
| ID | Nom | Console | Stock |
|
||||
| ---- | ----- | ------- | ----- |
|
||||
| 1 | Mario | Switch | 50 |
|
||||
| 2 | Zelda | Switch | 30 |
|
||||
| 3 | FIFA | PS5 | 20 |
|
||||
|
||||
### **1.2 Limites de cette approche**
|
||||
#### **1.2.1 Redondance des données**
|
||||
Supposons que vous ajoutiez une colonne pour l'éditeur de chaque jeu :
|
||||
|
||||
| ID | Nom | Console | Stock | Éditeur |
|
||||
| ---- | ----- | ------- | ----- | -------- |
|
||||
| 1 | Mario | Switch | 50 | Nintendo |
|
||||
| 2 | Zelda | Switch | 30 | Nintendo |
|
||||
| 3 | FIFA | PS5 | 20 | EA |
|
||||
|
||||
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**
|
||||
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**
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## 2. Vocabulaire des schémas relationnels
|
||||
|
||||
### **2.1 Table (ou relation)**
|
||||
Une table est un ensemble de lignes (ou enregistrements) et de colonnes (ou attributs). Chaque table représente une entité. Par exemple, une table `Jeux` pourrait ressembler à :
|
||||
|
||||
| ID | Nom | Console |
|
||||
| ---- | ----- | ------- |
|
||||
| 1 | Mario | Switch |
|
||||
| 2 | Zelda | Switch |
|
||||
| 3 | FIFA | PS5 |
|
||||
|
||||
### **2.2 Enregistrement (ou ligne, ou tuple)**
|
||||
Une ligne de la table représente une occurrence d'une entité. Exemple : `(1, Mario, Switch)`.
|
||||
|
||||
### **2.3 Attribut (ou colonne)**
|
||||
Chaque colonne représente une propriété de l'entité. Exemple : `Nom`, `Console`.
|
||||
|
||||
### **2.4 Clé primaire (Primary Key)**
|
||||
Un attribut (ou un ensemble d'attributs) qui permet d'identifier de manière unique chaque enregistrement. Exemple : l'attribut `ID` dans notre table `Jeux`.
|
||||
|
||||
### **2.5 Clé étrangère (Foreign Key)**
|
||||
Un attribut qui établit une relation entre deux tables. Exemple : si nous avons une table `Ventes` indiquant quel client a acheté quel jeu, la clé étrangère pourrait être l'ID du jeu.
|
||||
|
||||
**Table Ventes :**
|
||||
|
||||
| ID_vente | ID_jeu | ID_client |
|
||||
| -------- | ------ | --------- |
|
||||
| 1 | 1 | 1001 |
|
||||
| 2 | 2 | 1002 |
|
||||
|
||||
### **2.6 Relation**
|
||||
Une relation représente le lien entre deux tables via des clés primaires et étrangères.
|
||||
|
||||
### **2.7 Schéma relationnel**
|
||||
Un schéma relationnel décrit l'organisation des tables et les relations entre elles. Exemple d'un schéma simplifié :
|
||||
|
||||
- **Jeux**(ID, Nom, Console)
|
||||
- **Clients**(ID_client, Nom_client)
|
||||
- **Ventes**(ID_vente, ID_jeu, ID_client)
|
||||
|
||||
---
|
||||
|
||||
## Conclusion : De la théorie à la pratique
|
||||
|
||||
Nous avons vu que les structures plates, bien que simples, sont limitées en termes de redondance, de maintenance et de gestion des relations. Le modèle relationnel, basé sur des tables et des relations, permet de structurer efficacement les données tout en minimisant ces problèmes.
|
||||
|
||||
Dans les prochains cours, nous apprendrons à :
|
||||
- Concevoir des schémas relationnels.
|
||||
- Utiliser des outils comme SQL pour interagir avec des bases de données.
|
||||
- Optimiser nos bases pour des performances et une cohérence maximales.
|
||||
|
||||
Et n'oubliez pas : "Bien modéliser, c'est déjà réussir à moitié !"
|
||||
|
||||
--------
|
||||
|
||||
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>.
|
||||
120
BDD_SGBD/RELATION.md
Normal file
120
BDD_SGBD/RELATION.md
Normal file
@@ -0,0 +1,120 @@
|
||||
## Le Modèle Relationnel : Fondations et Contraintes
|
||||
|
||||
### Introduction : Le modèle qui a tout changé
|
||||
|
||||
Dans les années 1970, un chercheur d'IBM, **Edgar F. Codd**, propose un nouveau modèle pour organiser les données : le modèle relationnel. À l'époque, c'est une révolution. Les bases de données étaient alors gérées avec des structures hiérarchiques ou en réseau, complexes et rigides. Le modèle relationnel simplifie tout en utilisant des **tables** (ou relations) pour organiser les données. Résultat ? Une gestion plus efficace et un accès plus rapide aux informations.
|
||||
|
||||
Aujourd'hui, des outils comme MySQL, PostgreSQL ou SQLite appliquent toujours ce modèle. Et dire qu'il a commencé par une simple publication académique… Moralité : ne sous-estimez jamais le pouvoir d'un bon papier !
|
||||
|
||||
---
|
||||
|
||||
## 1. Les Clés : Gardiennes de l'Ordre
|
||||
|
||||
### **1.1 Clé Primaire (Primary Key)**
|
||||
|
||||
#### **Définition**
|
||||
La clé primaire est l’attribut (ou combinaison d’attributs) qui permet d’identifier de manière unique chaque enregistrement dans une table. **C’est l’équivalent d’une carte d’identité dans une base de données.**
|
||||
|
||||
#### **Exemple**
|
||||
Table `Etudiants` :
|
||||
|
||||
| ID_Etudiant | Nom | Prénom | Age |
|
||||
| ----------- | ------ | ------ | ---- |
|
||||
| 1 | Dupont | Marie | 18 |
|
||||
| 2 | Durant | Jean | 19 |
|
||||
| 3 | Morel | Sophie | 20 |
|
||||
|
||||
Ici, la colonne `ID_Etudiant` est la clé primaire, car chaque valeur est unique et permet de distinguer les étudiants.
|
||||
|
||||
#### **Rôle crucial de la clé primaire**
|
||||
- **Unicité** : Chaque enregistrement est unique.
|
||||
- **Référence** : Les autres tables peuvent s’y référer via des clés étrangères.
|
||||
|
||||
### **1.2 Clé Étrangère (Foreign Key)**
|
||||
|
||||
#### **Définition**
|
||||
Une clé étrangère est un attribut d’une table qui fait référence à la clé primaire d’une autre table. Elle établit un lien logique entre les deux tables.
|
||||
|
||||
#### **Exemple**
|
||||
Table `Cours` :
|
||||
|
||||
| ID_Cours | Nom_Cours | ID_Prof |
|
||||
| -------- | ------------- | ------- |
|
||||
| 101 | Mathématiques | 1 |
|
||||
| 102 | Informatique | 2 |
|
||||
| 103 | Histoire | 3 |
|
||||
|
||||
Table `Professeurs` :
|
||||
|
||||
| ID_Prof | Nom_Prof |
|
||||
| ------- | -------- |
|
||||
| 1 | Martin |
|
||||
| 2 | Leroy |
|
||||
| 3 | Dubois |
|
||||
|
||||
Ici, la colonne `ID_Prof` de la table `Cours` est une clé étrangère qui fait référence à la colonne `ID_Prof` de la table `Professeurs`. Cela permet de savoir quel professeur enseigne quel cours.
|
||||
|
||||
---
|
||||
|
||||
## 2. Les Contraintes d'Intégrité : Les Règles du Jeu
|
||||
|
||||
Les contraintes d’intégrité garantissent la cohérence des données dans une base de données relationnelle. Elles permettent d'éviter des erreurs telles que des données incohérentes ou incomplètes.
|
||||
|
||||
### **2.1 Contrainte d'Intégrité d'Entité**
|
||||
**Définition** : La clé primaire ne doit jamais contenir de valeur `NULL` et doit être unique.
|
||||
|
||||
**Exemple** :
|
||||
Dans la table `Etudiants`, il est impossible d’avoir deux fois le même `ID_Etudiant` ou un `ID_Etudiant` vide.
|
||||
|
||||
| ID_Etudiant | Nom | Prénom | Age |
|
||||
| ----------- | ------ | ------ | ---- |
|
||||
| 1 | Dupont | Marie | 18 |
|
||||
| 2 | Durant | Jean | 19 |
|
||||
| 1 | Morel | Sophie | 20 |
|
||||
|
||||
### **2.2 Contrainte d'Intégrité Référentielle**
|
||||
**Définition** : Une clé étrangère doit toujours faire référence à une clé primaire existante dans la table référencée.
|
||||
|
||||
**Exemple** :
|
||||
Si un cours dans la table `Cours` fait référence à un `ID_Prof` inexistant dans `Professeurs`, cela crée une incohérence.
|
||||
|
||||
| ID_Cours | Nom_Cours | ID_Prof |
|
||||
| -------- | ------------- | ------- |
|
||||
| 101 | Mathématiques | 1 |
|
||||
| 102 | Informatique | 4 |
|
||||
|
||||
### **2.3 Contrainte d'Intégrité de Domaine**
|
||||
**Définition** : Les valeurs d’un attribut doivent respecter un type ou un domaine prédéfini.
|
||||
|
||||
**Exemple** :
|
||||
Si l’attribut `Age` est défini comme un entier positif, une valeur comme `-3` ou `Texte` serait invalide.
|
||||
|
||||
| ID_Etudiant | Nom | Prénom | Age |
|
||||
| ----------- | ------ | ------ | ----- |
|
||||
| 1 | Dupont | Marie | 18 |
|
||||
| 2 | Durant | Jean | -3 |
|
||||
| 3 | Morel | Sophie | Texte |
|
||||
|
||||
---
|
||||
|
||||
## Anecdote : Le bug de la clé étrangère oubliée
|
||||
|
||||
Dans les années 1990, une banque a oublié d’appliquer la contrainte d’intégrité référentielle dans sa base de données. Résultat : des milliers de transactions faisaient référence à des comptes clients inexistants. Moralité : quand on parle d'argent, mieux vaut éviter les erreurs de clé étrangère !
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
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.
|
||||
|
||||
Et souvenez-vous : "Une base bien modélisée est comme une maison bien construite : elle résistera aux tempêtes (ou presque) !"
|
||||
|
||||
------
|
||||
|
||||
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