CP 5 - Mettre en place une base de données relationnelle

📚 Références

• REAC (mise à jour du 02/07/2024), pages 23 et 24
• RE (mise à jour du 02/07/2024), page 11

📋 En résumé

Le front-end : c'est fini !
Mais avant de nous attaquer au back-end d'un point de vue code, on va voir ce qui est attendu dans cette CP qui parle de la mise en place d'une base de données relationnelle.

🎨 Modélisation de la base de données

Commençons par le commencement : comment créer une base de données relationnelle ?

Il y a pléthore de possibilités, mais ici on va s'attarder sur une méthodologie française (cocorico 🐓) qui est la méthode Merise.
On va se baser sur différents schémas issus de cette méthode pour créer notre base de données relationnelle, à savoir :

1. Le dictionnaire des données : qui va recenser toutes les données que l'on va stocker par la suite dans notre base de données
2. Le MCD (Modèle Conceptuel des Données) : qui va représenter les données et leurs relations, sous la forme d'entités et d'associations dans un schéma graphique
3. Le MLD (Modèle Logique des Données) : qui va représenter les données sous forme de tables et de relations, dans un schéma graphique
4. Le MRD (Modèle Relationnel des Données) : qui va représenter les mêmes informations que le MLD, mais cette fois-ci en format texte
5. Le MPD (Modèle Physique des Données) : qui va représenter les données sous forme de tables et de relations, en intégrant les types de données et les contraintes

Tu remarqueras que j'y ai indiqué un ordre dans la liste ci-dessus.
Si je peux te donner un indice : ce n'est pas pour rien que c'est une liste ordonnée 😉

Donc si tu réalises un dictionnaire de données après avoir fait ton MPD, c'est que tu n'as pas compris l'objectif du dictionnaire de données ! (par exemple)

Si tu souhaites en savoir plus sur la méthode Merise, je t'invite à lire les articles dédiés sur le Memento.
Voici un lien vers l'introduction de la méthode Merise !

💾 Sauvegardes de la base de données

C'est bien beau de créer une base de données, mais si on ne la sauvegarde pas, on risque de tout perdre en cas de problème...

Certains hébergeurs permettent de faire des sauvegardes automatisées, mais dans le cas où tu dois toi-même sauvegarder ta base de données, il existe plusieurs solutions :

• Les sauvegardes manuelles : qui consistent à exporter le contenu de ta base de données dans un fichier (généralement au format SQL)
• Les sauvegardes automatiques : qui consistent à automatiser le processus de sauvegarde, généralement via un script ou un outil dédié

On va se concentrer (que très rapidement, ne t'inquiète pas !) sur la partie automatisée, puisqu'elle permet également de comprendre comment faire une sauvegarde manuellement.

Pour mettre en place l'automatisation, on peut mettre en place une tâche planifiée : un processus qui va s'exécuter à intervalles réguliers pour sauvegarder notre base de données.
Sur Linux, on parlera d'un cron job (ou tâche cron en français).

Sans rentrer dans les détails de configuration d'une tâche cron, on va devoir la créer en donnant plusieurs informations :

• Le chemin vers le script de sauvegarde : qui va contenir les commandes pour sauvegarder notre base de données
• La fréquence d'exécution : qui va déterminer à quelle fréquence notre tâche va s'exécuter (toutes les heures, tous les jours, toutes les semaines, etc.)
• Le compte utilisateur : qui va exécuter la tâche, généralement le compte de l'utilisateur qui a les droits d'accès à la base de données

#!/bin/bash

# Variables
DB_USER="user"
DB_NAME="database"
BACKUP_DIR="/path/to/backup"
DATE=$(date +"%Y%m%d%H%M%S")

# Création du répertoire de sauvegarde
mkdir -p $BACKUP_DIR

# Sauvegarde de la base de données
pg_dump -U $DB_USER $DB_NAME > $BACKUP_DIR/$DB_NAME-$DATE.sql

# Ouvrir le fichier de tâches cron
crontab -e

# Ajouter la tâche de sauvegarde, toutes les nuits à minuit
0 * * * * /path/to/backup.sh

🛡️ Sécurité et confidentialité des données

On ne le répétera jamais assez, mais la sécurité et la confidentialité des données sont primordiales pour toute application.

Pour garantir la sécurité de ta base de données, il est recommandé de mettre en place plusieurs mesures :

• Les sauvegardes régulières : pour éviter de perdre des données en cas de problème
• Les mises à jour régulières : pour corriger les failles de sécurité et les bugs
• Les accès restreints : pour limiter l'accès à la base de données aux seules personnes autorisées
• Les mots de passe forts : pour éviter les attaques par force brute ou par dictionnaire
• Les connexions sécurisées : pour éviter les interceptions de données

Mais la sécurité ne s'arrête pas là, il est également important de garantir la confidentialité des données :

• Le chiffrement des données : pour éviter que des tiers puissent lire les données stockées, en cas de fuite

➕ Informations complémentaires

Si tu utilises une autre méthode de modélisation que Merise, tu as évidemment le droit de le faire !
Fais juste attention à une chose...

🎯 Critères d'évaluation

• Les données du schéma conceptuel et leurs relations sont identifiées et prises en compte
• Le schéma physique est conforme aux besoins exprimés dans le dossier de conception et respecte les règles des bases de données relationnelles
• Les règles de nommage sont respectées
• La sécurité, l'intégrité et la confidentialité des données est assurée
• La base de données de tests mise en place est conforme au schéma physique
• Les utilisateurs sont créés avec leurs droits respectifs conformément au dossier de conception
• La base de données créée est sauvegardée et elle peut être restaurée en cas d'incident
• La documentation technique des bases de données est comprise, en langue française ou anglaise (niveau B1 du CECRL pour l'anglais)

🤯 Aller plus loin

Pas trop mal à la tête ? On continue un tout petit peu ? 😅
Tu as vu qu'on précise entre parenthèses la longueur des données, mais pourquoi on fait ça ?

Tu n'es pas sans savoir que pour stocker des données et que pour les stocker, il nous faut de l'espace.
Et cet espace, on le définit en fonction de la longueur de nos données : on parle alors d'allocation.

En précisant une valeur entre les parenthèses, on vient dire à notre SGBD combien de place il doit réserver pour stocker nos données au maximum.

Dans le cas d'un VARCHAR(30), on réserve 30 caractères pour stocker notre donnée, même si elle n'en fait que 5 (allocation dynamique).
Dans le cas d'un CHAR(30), on réserve également 30 caractères, mais cette fois-ci on "complète notre donnée avec des espaces" pour atteindre les 30 caractères (allocation statique).

Si on ne précise pas de longueur, le SGBD va réserver une place par défaut qui varie d'un SGBD à l'autre.
Donc ce n'est pas parce que tu te dis : "255 caractères c'est très bien pour mon VARCHAR, pas besoin de le préciser puisque c'est la valeur par défaut !" que tu as raison... 😅
Si demain la norme change et que l'allocation par défaut pour les types VARCHAR passe à 100 caractères au lieu de 255 caractères, tu risques de te retrouver avec des données tronquées !

🧠 Documentations

• Éditions ENI - Merise - Guide pratique (4e édition), par Jean-Luc Baptiste
• Medium - Non, les ID n'ont pas leur place dans un MCD, par Jean Prulière
• SQL.sh - Cours et tutoriels SQL
• Wikipédia - UML

🛠️ Outils

• Looping - Logiciel de modélisation de bases de données
• Mocodo - Logiciel en ligne de modélisation de bases de données