# Gnral Dveloppement > ALM > Modlisation > Schma > [MCD] Bonne pratique pour mmoriser la date ?

## theserver

Bonjour  tous,

Dans le cadre d'un stage, j'ai besoin de stocker des donnes ayant t collectes sur des vhicules quotidiennement. Souhaitant garder un historique des donnes collectes, on souhaite pouvoir accder dans la BDD aux donnes collectes entre la date X et Y (pour tous les vhicules ou seulement un). Durant mes cours de MCD, il me semble que l'on ralisait des relations ternaires avec une entit date pour mmoriser la date de la donne, mais cela semble complexifier normment le MCD. 

J'avais donc d'abord pens  cela, mais a me semble incorrect en raison des cardinalits 1:1 :


J'ai donc pens  simplifier les relations ternaires en 2 relations 1-1 :


Mais je me suis ensuite demand, pourquoi ne pas mmoriser la date directement dans les entits (puisqu'il s'agit d'un datetime, il y a trs peu de chance que la date sois identique pour deux donnes) :


Et finalement, j'en suis arriv  me demander si je ne pouvais pas centraliser toutes mes donnes dans une grosse entit DATA (sachant que la liste des donnes prsentes est non exhaustive, c'est  titre d'exemple) :


La dernire approche me semblant un peu brute, je suis maintenant compltement perdu sur la meilleure approche  adopter (mes cours de MCD commenant en plus  dater un peu...).
Quelqu'un saurait-il me dire quelle approche serait  privilgier et pourquoi ? Merci d'avance.

Cordialement

----------


## escartefigue

Bonjour,

Si  chaque instant o on fait une mesure, il faut relever  la fois la golocalisation, la consommation et la distance parcourue, il n'est pas aberrant d'avoir une type d'entit unique (ce que vous avez appel "DATA") possdant tous les attributs.
Mais en ce cas, un seul attribut d'horodatage est requis.
Si  l'inverse, l'instant o on mesure la golocalisation, celui o on mesure la distance et celui o on mesure la consommation peuvent tre diffrents, alors il faut des types d'entit distincts.
Cela tant dit, mesurer la consommation sans savoir quelle est la charge moteur, la vitesse, le rapport de boite engag, la vitesse et la direction du vent... Bref, sans connatre les conditions de roulage, n'a qu'un intrt limit.

On peut considrer que la mesure est une entit-type faible du vhicule, la mesure pourrait donc tre identifie *relativement* au vhicule :
[VEHICULE] 0,n --- (effectuer) --- 1,1*(R)* [MESURE]

* noter :* il existe des types de donnes spcifiques aux donnes spatiales (les types geometry et geography), le premier est adapt aux donnes dans un plan, le deuxime est adapt aux mesures terrestres (prise en compte de la forme ellipsodale de la terre). Le type FLOAT, peu prcis, n'est pas pertinent pour des mesures fines.

----------


## theserver

Bonjour,

Merci de ta rponse, en effet, le moment auquel les donnes sont mesures par le vhicule peut diffrer en fonction des donnes. Concrtement, un vhicule peut tout  fait mesurer sa position  11h00, sa distance parcourue  14h et sa consommation  16h. Je vais personnellement rcuprer les 3 donnes au mme moment, lors de l'appel  l'API (obtenant ainsi pour chaque donne la mesure la plus rcente effectue). J'avais ainsi considr tout mettre dans la mme entit puisque je rcupre  chaque fois un set de donne complet (avec des donnes horodates diffremment). 
Mais sparer les entits semble en effet plus probant.

Il reste cependant une incertitude au vu de ta rponse, faut-il externaliser l'entit date ? (lequel des deux concepts ci-dessous te semble le plus appropri ?)

OU


Concernant l'intrt de mesurer la consommation seule, les 3 donnes prsentes dans mon MCD sont l  titre d'exemple. Concrtement le set de donnes sera beaucoup plus important, mais je n'avais pas  cur de raliser le MCD complet 4 fois pour poser ma question  ::): .

Et merci pour ton conseil sur les types de donnes, je vais regarder a plus en dtail !

----------


## SQLpro

Une entit DATE (ou planning, agenda...) n'est ncessaire que lorsqu'il doit y avoir une planification des dates.

Par exemple, pour un mdecin, une entit date au pas de 15 minutes sera ncessaire pour organiser les crneaux des RV de consultation. De mme pour une entreprise de contrle technique des vhicule. Toutes ces dates/heures devront tre pr-saisie pour les mois et les annes  venir.

C'est donc pour planifier le temps, c'est  dire prvoir  priori les crneaux temporels (par exemple pour des relevs de capteurs sur les cours d'eau pour la gestion des crues, j'ai modlis une entit temporelle au pas de 5 minutes, car les capteur envoi leurs donnes toutes les 5 minutes....

Si, en revanche, la date ne sert que pour une historisation  postriori de l'information cela est parfaitement inutiles

A +

----------


## theserver

Merci beaucoup, c'est vrai que vu comme a tout prends son sens !

Je visualise maintenant beaucoup mieux comment concevoir ma BDD  ::):

----------

