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¶

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¶

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¶

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¶

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¶

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.

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.