Semestre 1

Ce premier semestre m’a permis de comprendre comment structurer, sécuriser et exploiter les données, au cœur de tout système d’information. En R1.05 (Introduction aux bases de données et SQL), j’ai appris à concevoir des modèles de données (diagrammes de classes) et, surtout, à les traduire rigoureusement en schémas relationnels. C’est à cette occasion que j’ai découvert la syntaxe SQL pour créer, modifier et interroger des tables. La ressource R1.06 (Mathématiques discrètes) m’a apporté un éclairage plus théorique : la théorie des ensembles et l’algèbre relationnelle m’ont aidé à mieux comprendre la logique des clés primaires et des jointures. Enfin, la ressource R1.09 (Économie durable et numérique) m’a donné le recul nécessaire pour saisir l’importance de ces données dans le pilotage d’une entreprise et la nécessité de les maintenir cohérentes.

1. Démarches, prises de décisions, implication et autonomie

Dans cette SAÉ, l’objectif était de créer de A à Z une base de données fonctionnelle à partir d’un modèle conceptuel, en binôme. Le projet s’est structuré en plusieurs étapes techniques.

Notre première démarche a consisté à traduire notre diagramme de classes (réalisé en partie 1) en schéma relationnel. Nous avons pris le temps de le formaliser sur papier afin d’éviter les erreurs liées aux règles de passage, notamment pour gérer les associations (déterminer où placer la clé étrangère ou s’il fallait créer une table d’association).

Nous sommes ensuite passés à la création des tables en SQL. Une décision importante a été d’intégrer dès le départ les contraintes d’intégrité (clés primaires, clés étrangères, NOT NULL, CHECK) afin de partir sur une base solide. Nous avons ensuite rédigé les 5 requêtes ALTER TABLE demandées (ajout et suppression de colonnes et de contraintes, modification de type) pour montrer que nous savions faire évoluer le schéma.

Pour la partie insertion des données, le cahier des charges interdisait l’utilisation d’IA génératives. Nous avons donc créé nos propres jeux d’essais à la main (au moins 3 tuples par table). Cette étape était fastidieuse, mais elle nous a obligés à réfléchir à l’ordre d’insertion : on ne peut pas insérer une ligne dans une table enfant si la clé étrangère ne référence pas une donnée existante dans la table parente.

Enfin, nous avons réalisé la batterie de 10 tests de contraintes. Pour cela, nous avons volontairement écrit des requêtes INSERT, UPDATE et DELETE destinées à échouer (par exemple, créer un doublon de clé primaire ou violer une contrainte CHECK). À chaque fois, nous avons copié le message d’erreur renvoyé par le SGBD et l’avons ajouté en commentaire dans notre script SQL pour attester que la base réagissait correctement.

2. Ressources choisies et combinées

Plusieurs ressources ont été combinées pour construire ce livrable :

• R1.05 (Bases de données et SQL) : C’est le cœur de la SAÉ. Cette ressource nous a fourni les règles de traduction du modèle UML vers le relationnel, ainsi que la syntaxe SQL indispensable (CREATE TABLE, ALTER TABLE, INSERT, UPDATE, DELETE).
• R1.06 (Mathématiques discrètes) : Les notions de domaines de valeurs et de relations mathématiques nous ont aidés à paramétrer correctement les contraintes de validation (clauses CHECK).
• Outils de développement : Nous avons utilisé des éditeurs de texte et des IDE pour écrire nos scripts .sql proprement avant exécution, afin de conserver une trace claire pour le rendu final (archive .zip) et la démonstration orale.

3. Justification de la maîtrise des apprentissages critiques

• AC14.01 | Mettre à jour et interroger une base de données relationnelle

  Justification : Notre script final illustre clairement cette compétence. L’utilisation des commandes ALTER TABLE montre notre capacité à mettre à jour la structure de la base. De plus, l’insertion du jeu de données via INSERT INTO et nos 10 requêtes de test (UPDATE, DELETE) prouvent que nous savons manipuler la donnée et vérifier son intégrité face aux contraintes du système. Les commentaires contenant les retours d’erreurs du SGBD attestent que les tests ont été exécutés et compris.

• AC14.03 | Concevoir une base de données relationnelle à partir d’un cahier des charges

  Justification : La tâche 1 de la SAÉ en est une preuve directe. Nous sommes partis d’un diagramme de classes (modèle conceptuel) que nous avons su traduire en un schéma relationnel strict et normalisé, en respectant les règles liées aux clés primaires et aux clés étrangères. Le script de création des tables qui en découle concrétise cette conception de manière opérationnelle.

4. Ressources manquantes / Si c’était à refaire

Le principal point de friction a été l’ordre de création et de remplissage des tables. Au début, nous avons rencontré plusieurs erreurs de type "violation de clé étrangère", car nous essayions de créer ou de remplir des tables dépendant d’autres tables pas encore créées ou alimentées. Si c’était à refaire, je commencerais par dessiner un graphe de dépendance des tables avant d’écrire la première ligne de code, afin de définir clairement l’ordre d’exécution des requêtes.

Ensuite, concernant la génération des données (Tâche 3), le fait de tout inventer « à la main » prend beaucoup de temps et limite le volume de données à tester. Si c’était à refaire, il me manquerait des compétences en algorithmique (par exemple, utiliser des boucles en Python) pour écrire un petit script générant des données aléatoires cohérentes au format .sql, sans recourir à une IA.