.. _ref-projet2: .. spelling:word-list:: crashé anonymisée d'INGINIOUS téléchargeable tutoriel l'UCLouvain l'Internet l'URL l'HyperText grading frontend Phase 2 : Intégration et affichage de la base de données -------------------------------------------------------- Nous avons extrait pour vous les données de `avionstack.com`. Les données sont déjà présentes dans une base de données SQLite. Cette base de données comporte les tables suivantes : airline ============ .. code-block:: sql CREATE TABLE airline(iata_airline TEXT PRIMARY KEY, name TEXT); Cette table stock les données concernant les compagnies aériennes. Elle est constitué de deux colonnes. ``iata_airline`` L'identificateur unique de la compagnie et ``name`` le nom de la compagnie. airport =========== .. code-block:: sql CREATE TABLE airport(iata_code TEXT PRIMARY KEY, name TEXT, latitude_deg REAL, longitude_deg REAL, iso_country TEXT FOREIGN KEY (iso_country) REFERENCES country(iso_country), ); La table ``airport`` reprend les données relatives aux aéroports. ``iata_code`` est un identificateur unique pour l'aéroport. ``name`` est le nom de l'aéroport. ``latitude_deg`` et ``longitude_deg`` désigne les coordonnées de l'aéroport. ``iso_contry`` est une clef étrangère se rapportant à la table ``country``. country =========== .. code-block:: sql CREATE TABLE country(iso_country TEXT PRIMARY KEY, name TEXT); La table ``country`` stock les différents pays. Elle comprend deux colonnes, ``iso_contry`` l'identificateur unique du pays et ``name`` le nom du pays. aircraft =========== .. code-block:: sql CREATE TABLE aircraft(iata_aircraft TEXT PRIMARY KEY, name TEXT, aircraft_type TEXT); La table ``aircraft`` comprends les appareils. Elle est constituée de trois colonnes, ``iata_aircraft`` l'identificateur de l'appareil, ``name`` le nom de l'appareil et ``aircraft_type`` le type de l'appareil. flight =========== .. code-block:: sql CREATE TABLE flight(flight_id INTEGER PRIMARY KEY, iata_airline TEXT, iata_aircraft TEXT, iata_flight TEXT, flight_date TEXT, iata_departure TEXT, iata_arrival TEXT, departure_time TEXT, departure_delay INTEGER DEFAULT(0), arrival_time TEXT, arrival_delay INTEGER DEFAULT(0), UNIQUE(flight_date, iata_departure, iata_arrival, departure_time, arrival_time), FOREIGN KEY (iata_airline) REFERENCES airline(iata_airline), FOREIGN KEY (iata_aircraft) REFERENCES aircraft(iata_aircraft), FOREIGN KEY (iata_departure) REFERENCES airports(iata_code), FOREIGN KEY (iata_arrival) REFERENCES airports(iata_code) ); Cette dernière table est la plus conséquente, elle regroupe les informations concernant les vols et possède plusieurs clefs étrangères. * ``fight_id`` est l'identificateur unique pour le vol * ``iata_aircraft`` est l'identificateur unique pour l'appareil * ``iata_flight`` est un identificateur pour le vol, mais celui-ci n'est pas unique * ``flight_date`` la date du vol * ``iata_departure`` l'aéroport de départ * ``iata_arival`` l'aéroport d'arrivée * ``departure_time`` l'heure de décollage. * ``departure_delay`` le retard au décollage * ``arrival_time`` l'heure d'arrivée * ``arrival_delay`` le retard à l'atterrissage L'objectif de cette phase est d'implémenter quelques fonctionnalités basées sur le SQL dans votre site. Rappels: - Chaque groupe **DOIT** réaliser son travail en utilisant la `Forge UCLouvain `__ et en particulier le répertoire qui vous a été assigné par votre tuteur et le gestionnaire de version Git. - Votre site ne doit jamais être "down". Cela signifie que le code se trouvant sur la branche `main` doit **toujours** être fonctionnel. - Toute modification du code (excepté les corrections triviales) doit se faire à travers une merge request, qui a été reviewée par un membre du groupe. - Pensez à organiser votre GitLab proprement et utilisez des messages de commit clairs (effectuez des commits régulièrement). Taches -------- Nous vous demandons d'intégrer le schéma dans votre site Flask. Vous devrez créer un menu, qui permettra d'accéder aux pages de votre site. Il comportera au moins les pages suivantes : * Une page d'accueil. * Une seule page qui présente l'équipe, en agrégeant les informations de la phase 1. * Une page qui présente des statistiques. **En utilisant des requêtes SQL pour effectuer les opérations mathématiques telles que des sommes ou des comptages :** * Le nombre d'entrées par table, selon le schéma fourni ci-dessus. * Le nombre de vols par aéroports. * Le nombre de vols par compagnie aérienne. * Une page de requête qui permet de choisir un aéroport dans un menu déroulant. * Après sélection la page affiche le nombre de vols par type d'appareil. * Pour l'aéroport choisi, affiche le nombre de vols par jours de la semaine (lundi, mardi, ...). L'affichage des deux dernières pages utilisera toujours le nom textuel complet et pas les codes ISO ou IATA. Par exemple il faut afficher "Belgium" et pas "BE". Liège Airport et pas LGG. En utilisant évidemment les jointures appropriées. .. Les listes faites au TP1 et TP3 peuvent être supprimées ou déplacées dans une page de manipulation de la base de données qui est cachée (par exemple /admin), communément appelée "backend". Vous avez environ deux semaines pour terminer cette phase après la phase précédente. **La deadline précise est donnée sur Moodle.** Le site doit être en ligne **et fonctionnel** avec la dernière version du code. Vous devez également faire un `tag` git, qui va marquer le dernier commit comme celui du code final. Pour cela, utilisez `git tag phase3 && git push phase3`. Vérifiez que ce tag est disponible sur l'interface de la Forge. Rapport ------- Sur Moodle, vous remettrez un rapport qui répond aux critères ci-dessous. Critères d'évaluation --------------------- Rapport : - Le rapport est clair, complet, mais concis. - Le rapport présente les fonctionnalités implémentées. - Le rapport explique chacune des requêtes, pourquoi elles sont optimales. Site : - Le site fonctionne et est en ligne - Le design est réfléchi, le site est navigable, élégant, épuré - Le site est résistant à l'utilisateur : il n'y a pas de crash, d'injections SQL, ... Présenter un site avec une faille de sécurité mènera à un malus conséquent. Documentation du code : - Le code est commenté SQL : - Les requêtes SQL sont correctes. - Les requêtes SQL sont élégantes, directes et efficaces. Elles ne retournent pas de données qui ne seront pas utilisées par le contrôleur. Git : - L'ensemble des modifications importantes ont été faites en utilisant des merge requests. - Les merge requests ont fait l'objet de reviews systématiques. Code : - Le code est correct. - Le code est structuré. - L'architecture MVC est respectée. - Les templates HTML sont propres. Les données paramétrables sont passées par l'application, et pas codées en dure. Travail de groupe : - L'évaluation du groupe se fera via un module dynamo sur Moodle, cloturé 2 jours après la soumission. Une pénalité sera appliquée pour les membres qui n'y répondent pas. Pour rappel, la phase 2 dans son ensemble compte pour 15% de la note finale. **Les deadlines sont données sur Moodle.**