Objectif final

Chaque étudiant doit réaliser une interface WEB pour afficher/ajouter/modifier/supprimer une des tables du MCD.


L’évaluation, compte tenu de la diversité des sujets, portera sur :

schéma et définition du travail de chacun ; code SQL

Une fois vos modèles réalisés (MCD et MLD ou MR) : Il faudra choisir une table pour chaque étudiant.


Cette table doit obligatoirement posséder une clé étrangère au minimum.


Cette table est définie avec l’enseignant qui suit votre travail de SAE.

Sur certains schémas, il faudra peut être modifier votre MCD pour simplifier la réalisation de l’interface

voir la partie sur la modification du schéma

Application à réaliser

Chaque étudiant doit réaliser :

CRUD : Create Read Update Delete


La complexité de réalisation sera prise en compte. Ne pas à choisir les tables les moins complexes pour les interfaces. Il est obligatoire de choisir une table qui possède au moins une clé étrangère .


La conception visuelle (design) ne sera que très peu évaluée. Seule l’utilisabilité de l’interface sera beaucoup prise en compte lors de l’évaluation.

exemple de page d’accueil et de menu

Le menu permet d’accéder rapidement au “CRUD” réalisé par un étudiant. Le menu permet également d’accéder à l’état réalisé par un étudiant en sachant qui est l’auteur du travail.

exemple de page d’accueil et de menu

Interface CRUD pour afficher, ajouter, modifier et supprimer des données dans une table

CRUD : Create, Read, Update, Delete


exemple d’affichage d’une table

Interfaces (formulaires) pour ajouter/modifier les données :

Dans votre jeu de test, choisissez des noms des noms qui permettent de désigner clairement un objet. Par exemple, évitez de désigner un véhicule par un numéro qui est l’identifiant de la clé primaire automatique ( Dans une flotte de véhicules, il est possible de remplacer le numéro 3 par un nouveau véhicule ayant également le numéro 3, mais qui peut être différent.)

suppression des données :

États :

Dans le contexte des bases de données, un état fait référence à une représentation figée des données stockées à un moment donné. Il s’agit d’un instantané ou d’une vue spécifique des données dans un certain état, généralement obtenu à partir d’une requête SQL de type “SELECT” exécutée sur la base de données.

Un état permet d’afficher les informations contenues dans la base de données selon certains critères spécifiés, tels que des filtres, des agrégations ou des jointures. Il peut être utilisé pour générer des rapports, des factures, des statistiques ou tout autre type de sortie qui présente les données de manière structurée et significative.

L’idée principale d’un état est de fournir une vue claire et cohérente des données à un moment précis, facilitant ainsi leur analyse, leur compréhension et leur utilisation pour des besoins spécifiques.


Une fiche de paye, une facture, un bon de livraison sont des états. Un tableau de bord de données permet d’afficher, suivre, analyser des données.


La note sera d’autant meilleure que les états seront complexes à réaliser :

exemple d’état “minimum” (capture d’écran d’un ancien projet)
exemple d’état très complet (capture d’écran d’un ancien projet)

paramétrage d’un état

paramétrage d’un état (capture d’écran d’un ancien projet)

Remarque : les paramètres peuvent être saisis dans un formulaire indépendant.


Livrable 1

Lien sur Moodle

Vous devez fournir un script SQL nommé “sql_projet.sql” qui permettra de tester votre application. Ce script SQL doit :


exemple de modification :
exemple de fichier PDF (format A4) avec un MCD qui sera imprimé
exemple de fichier PDF (format A4) avec un MLD qui sera imprimé

Livrable final S1 BDD

Le projet doit être rendu sur Moodle en utilisant le lien suivant d’ici le 5 décembre.

Ce dossier doit contenir les éléments suivant :

Votre application doit être fonctionnelle sur une machine de l’IUT avec la commande “python app.py” dans un environnement local où les paquets “pymysql” et “flask” sont installés.

En remplaçant le login et le motDePasse des instructions ci-dessous par votre login et mot de passe sur le serveur MySQL de l’IUT, les 3 commandes ci-dessous doivent fonctionner pour tester votre application (dans un terminal ouvert dans votre dossier de projet) :

wine /opt/looping-mcd/Looping.exe mcd.loo
mysql --user=login  --password=motDePasse --host=serveurmysql --database=BDD_login < sql_projet.sql
python app.py


FAQ :

Les principaux problèmes rencontrés :

La clé primaire n’est plus un entier avec un compteur (int aut_increment) mais plutôt une combinaison de clés étrangères sur d’autres clés primaires. Dans ce cas il est recommandé de modifier le schéma afin de faciliter les opérations de modification ou de suppression d’un enregistrement (voir annexe ci-dessous).


Il est possible d’ajouter des colonnes supplémentaires dans les tables

Annexe : aide pour réaliser un CRUD

Les associations dans les M.C.D. Merise sont souvent transformées en tables dites “table de liaison ou table de jonction” dans les MLD (à l’exception des associations binaires avec une cardinalité se terminant par 1)

Passage d’une clé primaire composée de plusieurs colonnes à une clé primaire composée d’une seule colonne.

exemple de modification :

MCD
MLD

l’objectif est de remplacer les tables issues de relation

MCD
MLD



CONSTRAINT uk_projection  UNIQUE (num_salle, id_film, id_creneau)

doc unique key - doc index key

Création d’un enregistrement :

Modification d’un enregistrement :

Pour modifier un enregistrement avec un formulaire,, vous pouvez stocker la clé primaire dans un (des) champ(s) caché(s) du formulaire. Cela permet de récupérer l’identifiant unique de l’enregistrement lors de la soumission du formulaire, afin de savoir quel enregistrement doit être modifié dans la base de données.

<form  action="/projection/update"  method="post" >
      <input type="hidden" name="init_num_salle" value="{{ projection.num_salle }}">
      <input type="hidden" name="init_id_film" value="{{ projection.id_film }}">
      <input type="hidden" name="init_id_creneau" value="{{ projection.id_creneau }}">

      <select name="num_salle">

      
      ....

      <button class="btn  btn-outline-danger" > Modifier </button>
</form>

Annexes : erreurs classiques

Encodage des noms de fichiers et des noms de dossiers

Attention, pour les développeurs travaillant sur des machines avec un système d’exploitation Windows, il est important de prendre en compte les erreurs potentielles liées à l’encodage des caractères.


Lors du développement d’une application qui manipule des caractères spéciaux ou des langues non-anglaises, il est crucial de s’assurer que l’encodage des caractères est correctement géré pour éviter les problèmes d’affichage ou de traitement des données.

Configuration de MySql

MySql est moins “strict” par défaut sur Windows et parfois sur Linux:

Alors que MySQL est sensible par défaut à la casse (au niveau des noms de base et de table)dans la plupart des distributions Unix, il ne l’est pas pour Windows! En revanche, concernant les noms de colonnes, index, alias de colonnes, déclencheurs et procédures MySQL n’est pas sensible à la casse tous systèmes confondus. En fait, tous ces noms sont stockés en minuscules dans le dictionnaire de données.
La variable lower_case_table_names permet de forcer la sensibilité à la casse pour les noms des tables et des bases de données (si elle vaut 0, la sensibilité à la casse est active et les noms sont stockés en minuscules; 1, pas de sensibilité à la casse et les noms sont stockés en minuscules; 2, pas de sensibilité à la casse et les noms sont stockés en respectant la casse). Je vous invite à positionner cette variable à 0 de manière à homogénéiser le codage et à contrôler un peu plus l’écriture de vos instructions SQL. De plus, c’est l’option par défaut sur Linux.

SELECT @@lower_case_table_names; : Cette requête retournera la valeur actuelle de la variable lower_case_table_names qui doit être à 0


Pour vérifier le mode SQL en cours d’utilisation dans votre serveur MySQL, vous pouvez exécuter la requête suivante : SELECT @@sql_mode;.
Cette requête renverra la valeur actuelle de la variable sql_mode, qui représente le mode SQL en cours d’utilisation.
Le résultat sera une chaîne de caractères contenant les différents modes SQL activés et leurs paramètres. Assurez-vous de trouver la valeur ONLY_FULL_GROUP_BY dans la chaîne de caractères renvoyée. Si ce mode n’est pas activé, cela signifie que MySQL peut être moins strict en ce qui concerne la clause GROUP BY dans vos requêtes, ce qui peut entraîner des résultats inattendus. Il est possible que votre application fonctionne correctement sur votre machine, mais rencontre des erreurs lorsqu’elle est exécutée sur une machine de l’IUT.


En résumé, tester sur votre machine :

SELECT @@lower_case_table_names;
-- la réponse devrait être 0

SELECT @@sql_mode;
-- la réponse devrait contenir le mot clé ONLY_FULL_GROUP_BY



Si la configuration de MySQL n’est pas bonne :

Éditer le fichier de configuration my.ini ou my.cnf en tant que root. Dans ce fichier, sous la section serveur identifiée par [mysqld] si elle existe, ajouter les lignes ci-dessous (créer la section si elle n’existe pas):

[mysqld]
lower_case_table_names=0
local_infile=ON
sql_mode = "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"

[mysql]
local_infile=ON

Pour connaître le dossier du fichier my.cnf (Linux,MacOS) ou my.ini (Windows), exécutez la commande mysql --help --verbose. L’information est généralement affichée au début de la sortie. Sur Linux, utilisez sudo en début de commande pour obtenir les privilèges de superutilisateur.



Vous pouvez vérifier l’encodage du serveur MySQL par défaut avec la commande SQL SHOW VARIABLES LIKE 'character_set_%';. Cette requête renvoie les variables liées à l’encodage dans MySQL, y compris la variable character_set_server qui indique l’encodage du serveur MySQL. Les dernières versions de MySQL utilisent par défaut utf8mb4 qui convient parfaitement.

test de l’application

script de test du projet :

Un premier script extrait les archives .tar.gz et .zip, ce script recherche un dossier et copie un autre script test_projet.sh dans le dossier. Le script test_projet.sh se trouve au même niveau que le fichier app.py (une erreur est signalée dans le cas contraire).


script de test test_projet.sh:

#!/bin/bash

# mysql --user=login --password=secret --host=localhost BDD_s1_projet

HOST=localhost
LOGIN=login
PASSWORD=secret
DATABASE=BDD_s1_projet

sed -i "s/host=.*/host=\"${HOST}\",/g" app.py
sed -i "s/user=.*/user=\"${LOGIN}\",/g" app.py
sed -i "s/password=.*/password=\"${PASSWORD}\",/g" app.py
sed -i "s/database=.*/database=\"${DATABASE}\",/g" app.py

projet=$(ls -l sql_projet.sql)
if [ $? -ne 0 ]
    then
    echo -e "\033[0;31m \n* pas de fichier sql_projet.sql \033[0m"
    nb_fic_sql=$(ls -l *.sql | wc -l)
    if [ "${nb_fic_sql}" -eq "1" ]
    then
        NOM_FIC_SQL=$(echo *.sql)
        cp "$NOM_FIC_SQL" sql_projet.sql
        echo -e "\033[0;32m \n* fichier copier $NOM_FIC_SQL sql_projet.sql \033[0m"
    else
        echo -e "\033[0;31m \n* pas de fichier ****.sql \033[0m"
        exit 2
    fi  
fi

echo "DROP DATABASE  IF EXISTS ${DATABASE}; CREATE DATABASE ${DATABASE};" | mysql --user=${LOGIN} --password=${PASSWORD} --host=${HOST} ${DATABASE}
mysql --user=${LOGIN} --password=${PASSWORD} --host=${HOST} ${DATABASE} < sql_projet.sql

echo "mysql --user=${LOGIN} --password=${PASSWORD} --host=${HOST} ${DATABASE}" > connect.sh
chmod a+x connect.sh
gnome-terminal --tab -- ./connect.sh  &

xed sql_projet.sql app.py &

killall python3
flask --debug  --app app  run   --host 0.0.0.0  &
chromium 127.0.0.1:5000