Auteurs : Matthieu Bertet D2
L'implantation physique d'une base de données nécessite une maîtrise rigoureuse du langage SQL (Structured Query Language). Dans le cadre de la Tâche 2 et de la Tâche 3 de cette SAÉ, j'ai conçu et exécuté un script complet d'opérations d'administration et de manipulation de données sous un environnement Oracle SQL.
J'ai d'abord développé le script d'initialisation mettant en œuvre les requêtes de nettoyage (DROP TABLE) puis d'insertion de tuples artificiels (INSERT INTO ... VALUES ...) pour l'ensemble de nos entités, garantissant un jeu de données initial d'au moins 3 tuples par table pour tester nos structures (par exemple, l'alimentation des tables Pays, TypeEquipement et IndicateurEnv).
Au-delà des insertions de base, j'ai prouvé ma capacité à modifier dynamiquement la structure de la base de données en concevant 5 commandes avancées basées sur la syntaxe ALTER TABLE. Ces requêtes m'ont permis d'ajouter et de supprimer des colonnes de test (sur la table RegionDuMonde), d'ajouter et de retirer des contraintes de présence (ck_nbHabNN sur la table Pays), ainsi que de modifier temporairement le type de données d'un attribut existant (dureeVie modifié en VARCHAR2(20) puis restauré en NUMBER).
Savoir concevoir une base de données implique de savoir formaliser un besoin métier pour le traduire en un schéma informatique cohérent et intègre. Pour la Tâche 1 de cette SAÉ, j'ai réalisé la traduction rigoureuse d'un diagramme de classes UML (fourni dans le cahier des charges) vers un Schéma Relationnel textuel, en appliquant scrupuleusement les règles théoriques d'association et de dérivation des clés.
Cette phase de conception m'a amené à identifier et formaliser les clés primaires (comme l'acronyme pour l'entité IndicateurEnv) ainsi que les clés étrangères permettant de lier logiquement nos tables (comme la référence @Pays.nom au sein de la table des faits Mesure ou EquipementUtilise).
De plus, j'ai enrichi cette conception en consignant les contraintes textuelles indispensables pour préserver l'intégrité des domaines, restreignant par exemple les valeurs autorisées pour les indicateurs environnementaux aux seuls éléments du dictionnaire métier validé : {"GES", "BEP", "ADP", "EAU", "ELEC"}.
La réalisation de cette deuxième partie de la SAÉ 1.04 a exigé une démarche d'ingénierie rigoureuse, en particulier pour la mise en place de la Tâche 3 dédiée au Remplissage et aux Tests de contraintes. Afin de valider la robustesse de notre implémentation de manière totalement autonome et sans recourir aux IA génératives (conformément aux exigences du sujet), j'ai pris l'initiative de concevoir un protocole de test destructif systématique.
J'ai défini et exécuté un jeu de tests complet comprenant 10 requêtes ciblées (mêlant INSERT INTO, UPDATE et DELETE FROM) visant à violer volontairement les contraintes déclarées. Ma démarche a consisté à intercepter, analyser et consigner sous forme de commentaires dans le code les codes d'erreur natifs renvoyés par le serveur Oracle (tels que l'erreur ORA-01400 pour l'absence de clé primaire, ORA-00001 pour la violation d'unicité, ORA-02291 pour les ruptures d'intégrité référentielle, ou encore ORA-02290 pour le non-respect des clauses CHECK). Mon implication a été entière pour garantir la livraison d'un code propre et auto-documenté avant notre évaluation orale.
La réussite de cette SAÉ repose sur la combinaison étroite de nos apprentissages théoriques en modélisation de données et de notre maîtrise technique des environnements de serveurs de bases de données.
Nous avons combiné la ressource R1.05 – Introduction aux bases de données (pour l'application des concepts de l'algèbre relationnelle, la sémantique des clés et les règles fondamentales de passage d'un modèle conceptuel à un modèle logique) avec la ressource pratique liée au Développement SQL sous environnement Oracle.
Le problème majeur consistait à s'assurer qu'aucune donnée incohérente ne puisse corrompre notre base. Pour le résoudre, nous avons fait le choix technique de combiner l'usage des contraintes de table (PRIMARY KEY, REFERENCES) à l'utilisation systématique de la fonction UPPER() couplée à des clauses CHECK ... IN (...) lors de la création de nos structures (Tâche 2). Cette approche logicielle combinée a permis de sécuriser les types de données directement au niveau du dictionnaire de la base de données, bloquant par exemple l'insertion d'une région non reconnue sur le plan géographique ou d'un indicateur environnemental hors périmètre.
La justification de ma maîtrise de la compétence "Gérer des données" est ancrée dans les traces concrètes issues de nos trois scripts de livrables (Tâche 1, Tâche 2 et Tâche 3).