[BACKEND] Mise en place d'une dimension SCD pour les vessels

[rv2931]

Le but de cette évolution est de pouvoir suivre les modifications administratives d'un navire physique telles que:

• changement de mmsi
• changement de nom
• changement de pays
• changement de type de navire
• changement de IRCS (= call sign)
• changement d'external marking
  tout en permettant de l'identifier d'une manière unique et indépendante du point de vue "métier" et garder une certaine continuité dans son historique d'activité au délà de ces informations administrative

Le fonctionnement des dimensions SCD est décrit ici et est assez standard en stockage de données. Le type de type 6 (hybride) est le plus complet et le plus flexible et donc le plus utilisé.

Dans un premier temps, l'utilisation de l'identifiant IMO semble être une bonne option en tant qu'identifiant unique SCD renseigné par défaut au travers des différents versions de données du navire dans le temps, cependant il est à noter que l'identifiant unique pourrait être autre chose et peut être modifier par la suite dès lors qu'il est modifié pour toutes les versions historisées au sein de la table SCD pour un même navire/IMO

Cette migration version une dimension SCD pour les vessels aura un impact sur toutes les recherches et sauvegarde de récupération d'un id de vessel en table. En effet il faudra systématiquement accompagner la recherche d'un vessel par une date de validité effective afin de récupérer la bonne version du même vessel aux dates souhaitées. C'est particulièrement important lors du recalcul de statistiques afin que celle-ci soient valides sur la période en question

si possible, ça peut être une bonne occasion de créer une première surcouche de Service (design pattern Repository, UnitOfWork, Service + Dependency injection) pour simplifier la gestion des Vessels. Potentiellement d'autres suivront comme une éventuelle SCD pour la dimension des Zones

[marthevienne]

Description du fonctionnement de mise à jour des données relatives aux navires via le EU fleet register + GFW :

[marthevienne]

On partirait sur un type de SCD 2

[rv2931]

La description du wikipedia français est pas hyper complète, la version anglophone est bien plus détaillée et pratique
Le format le plus répandu c'est la formule 6 format:

• colonne: scd_start:timestamptz
• colonne: scd_end:timestamptz
• colonne: scd_active:bool

Plutôt que de mettre du NULL dans start/end pour rendre explicite qu'il n'y a pas de date de début ou de fin, il vaut mieux définir une date de début du genre début 01/01/1900 et et fin 31/12/2999, ça permet de faire des filtrages plus simple et un index de table plus efficace en utilisant un BETWEEN start AND end quand il y a une date de référence, ainsi start et end ne sont jamais NULL et du coup pas d'ambiguité sur la façon dont NULL est pris en compte ou pas filtrage complexe pour prendre en compte les cas start=null ou end=null

Pour les cas où on a pas de date de référence, du genre interrogation API, on ne prend que les lignes ou scd_active=true, on se retrouve donc très facilement comme s'il n'y avait qu'une version sans faire de test de dates

[rv2931]

flowchart TD
    001(Vessel)-->002{if new_vessel.imo matches with UVI in feet register}
    002-->|yes|003(Get information** in fleet register)
    003-->004{If there's a DES event}
    004-->|yes|005(Get static data through Spire)
    005-->006{If no data}
    006-->|yes|007("Update vessel status (tracking_activated = False, tracking_status=wreck)")
    007-->008(Update vessel)
    002-->|no|009{If new_vessel.ircs matches IRCS on fleet register}
    009-->|yes|003
    009-->|no|010("Get vessel info* in GFW API (vessel.imo)")
    004-->|no|011{"If newet country end date is None (e.g. still un UE fleet)"}
    011-->|yes|008
    011-->|no|012(Get country through Spire)
    012-->010
    010-->013("Convert gear type to gear category (to be defined)")
    013-->014{If gear category is different from vessel.type}
    014-->|yes|015(Notify admin that vessel gear category needs to be checked)
    015-->016{If country changed}
    014-->|no|016
    016-->|yes|017(Get time period in Spire data)
    017-->008

Loading

[marthevienne]

La description du wikipedia français est pas hyper complète, la version anglophone est bien plus détaillée et pratique Le format le plus répandu c'est la formule 6 format:

• colonne: scd_start:timestamptz
• colonne: scd_end:timestamptz
• colonne: scd_active:bool

Plutôt que de mettre du NULL dans start/end pour rendre explicite qu'il n'y a pas de date de début ou de fin, il vaut mieux définir une date de début du genre début 01/01/1900 et et fin 31/12/2999, ça permet de faire des filtrages plus simple et un index de table plus efficace en utilisant un BETWEEN start AND end quand il y a une date de référence, ainsi start et end ne sont jamais NULL et du coup pas d'ambiguité sur la façon dont NULL est pris en compte ou pas filtrage complexe pour prendre en compte les cas start=null ou end=null

Pour les cas où on a pas de date de référence, du genre interrogation API, on ne prend que les lignes ou scd_active=true, on se retrouve donc très facilement comme s'il n'y avait qu'une version sans faire de test de dates

Ok, c'est bon à savoir, merci pour l'explication !

Merci d'avoir converti le graphe ! Le fonctionnement trouvé me semble pas mal du tout. Etant donné que GFW fait déjà le travail d'identification des navires à partir des messages AIS et des registres : https://globalfishingwatch.org/datasets-and-code-vessel-identity/, le faire nous de notre côté à partir des données Spire seraient redondant. En se contentant de ce pipeline, on devrait arriver à suivre l'évolution de la flotte en top-down.

Si on part là-dessus, le seul problème que je vois persister, c'est le spoofing : et si on notifie juste l'admin qu'un navire présente plusieurs messages AIS pour un même timestamp et on lui permet de sélectionner le "bon" message ?

[rv2931]

Comme discuté par ailleurs, le besoin de SCD est validé, maintenant ça ne résout pas forcément tous les problèmes
L'ajout de sources consolidées comme Fleet register permettra de gérer/créer automatiquement et/ou consolider un historique de la dimansion dim_vessel mais le besoin d'une SCD vessel persiste. Sachant qu'il existe des cas où dim_vessel contiendra d'autres informations non présentes dans le registre Fleet, il faut donc garder une certaine indépendance entre les sources de références et la dimension dim_vessel en elle-même
Je propose de me lancer sur la mise en place d'une dimension dim_vessel. Pour la gestion des mises à jour je pense qu'on pourra fiare ça dans une autre issue mais au moins mettre la structure en place et les paramètres de requêtage du repository

[marthevienne]

Super, let's go alors !