Bonjour,

Les copies d'écran ne sont pas toutes passées ...

Sans les voir et sans répondre à tes questions du coup, si je devais modéliser ce que tu as présenté, je ferai :

-
Edité par Benzouye 14 avril 2021 à 14:01:24

Bonjour,

Merci beaucoup pour votre réponse.

Le problème est que vous créez un attribut 'date_heure' dans la table mesure_h alors que la date est un enregistrement de la colonne 'date', et que chaque heure de la journée représente une colonne différente dans le fichier csv.

De plus, je ne possède la granularité horaire que pour les données à partir de 2020, voilà pourquoi je souhaitais avoir une table 'mesure' avec le total quotidien ainsi qu'une table par heure pour les mesures qui possédaient cette information, ce qui aurait permis de ne pas mélanger différentes infos au sein d'une même table.

De mon côté, je vois bien toutes les captures, lesquelles vous manque-t-il ? Ce sera peut-être plus simple pour mieux visualiser le problème.

Encore merci à vous !

simplonien a écrit:

Le problème est que vous créez un attribut 'date_heure' dans la table mesure_h alors que la date est un enregistrement de la colonne 'date', et que chaque heure de la journée représente une colonne différente dans le fichier csv

Ce n'est pas un problème, mais un choix de conception plus rigoureux qui permet de respecter la 1ère forme normale ...

Il faut, au moment de l'import des données en base depuis le CSV, transposer les données des colonnes en lignes distinctes ...

simplonien a écrit:

je ne possède la granularité horaire que pour les données à partir de 2020

Cela signifie simplement qu'il faut mettre une heure par défaut pour les données antérieures à 2020 (minuit par exemple) avec en valeur la totalité de la journée.

simplonien a écrit:

De mon côté, je vois bien toutes les captures, lesquelles vous manque-t-il ?

Je ne vois que la première avec le "pseudo" schéma de base, et la deuxième avec le tableau horaires et ses 24 colonnes (berk ).

-
Edité par Benzouye 16 avril 2021 à 11:43:14

Bonjour, merci pour votre réponse.

Pour voir toutes les captures d'écran, elles sont sur ce lien : https://forum.clubic.com/t/jointure-entre-tables/446448/3

Concernant le schéma de base, la seule différence est que j'avais ajouté une table Mesure qui donnaient simplement les données principales de chaque mesure (jour, id_station, comptage total de la journée). N'ayant un niveau de précision plus important (que ce soit pour les heures ou le type de véhicule) uniquement pour la dernière année, sur des données de 7 années, ces informations seront vraiment minoritaires, et je souhaitais éviter non seulement de mélanger dans une même colonne des mesures quotidiennes et horaires en laissant une colonne 'heure' vide sur la grande majorité des lignes, mais également, lorsque je ne possède que les données quotidiennes, sans hure ni type, pourquoi mettre ces enregistrements plutôt dans la table mesures_h plutôt que dans mesures_t ?

Cela permettait également d'avoir les totaux quotidiens directement dans les tables, sans devoir refaire systématiquement le calcul dans mes requêtes SQL dès que j'en aurai besoin.

Pensez-vous que ce schéma soit si impertinent ?

Merci et bonne journée

Dans les copies d'écran on ne voir pas la notion de type ...

Mais ce que j'en comprends c'est que désormais toutes tes mesures comprennent une heure et un type, alors qu'avant tu n'avais que des mesures globales journalières.

Si c'est bien cela, alors le modèle se simplifie :

Et oui, je te conseille de laisser id_type et heure à NULL pour les anciennes mesures ...

Cela te permettra de facilement faire le distinguo entre tes anciennes mesures et les nouvelles, tout en étant capable de faire des taux par date ou période de dates.

-
Edité par Benzouye 19 avril 2021 à 15:21:17

Pour résumer, dans la grande majorité de mes enregistrements (2014 à 2020), je ne possédais que des valeurs quotidiennes, sans plus de détail. Depuis 2020, certains enregistrements (présents dans un fichier csv A) possèdent les données par heure (avec les 24 colonnes ^^) et d'autres enregistrements (présents dans un fichier csv B) possèdent les données par type de véhicule, réparties dans plusieurs colonnes également; mais ces enregistrements sont totalement différents, et prises sur des stations différentes, donc totalement indépendantes l'une de l'autre. Selon moi, on ne peut pas faire de liens entre le type et l'heure.

Initialement, je comptais également créer une table Type, mais on m'a conseillé préciser directement le type dans la table Mesure_type, en mettant une constante (par exemple, écrire directement 'Véhicule électrique comme valeur plutôt qu'un identifiant sui sera rapporté à une autre table Type).

Merci !

-
Edité par yoann_lv 19 avril 2021 à 15:31:52

Ok.

Donc si tu es absolument sûr que les mesures avec type sont absolument distinctes des mesures horodatées, tu peux te faire deux programmes d'import distincts pour traiter chacun des deux types de fichier. Les deux programmes auront pour but de transformer les colonnes en lignes, mais le premier traitera des heures et le second des types ...

Concernant le fait de stocker du texte pour les types au lieu d'un identifiant unique, c'est à toi de voir en effet, mais pour le coup en stockant tout ce petit monde dans une table unique mesure, cela oblige à répéter X fois la même valeur texte ce qui sera plus gourmand en espace qu'avec un simple id auto incrémenté. D'autant que je suppose que les types ne sont pas trop variables et extensibles ...

Encore merci à toi !

Au fait, simple question, quel logiciel utilises-tu pour réaliser ta modélisation ? Je la trouve très propre :

Benzouye a écrit:

Bonjour,

Les copies d'écran ne sont pas toutes passées ...

Sans les voir et sans répondre à tes questions du coup, si je devais modéliser ce que tu as présenté, je ferai :

-
Edité par Benzouye 14 avril 2021 à 14:01:24

Ici c'est MoCoDo. Mais lorsque c'est plus complexe j'utilise Looping.