IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Bonne pratique pour mémoriser la date ? [MCD]


Sujet :

Schéma

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2015
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Août 2015
    Messages : 7
    Points : 8
    Points
    8
    Par défaut Bonne pratique pour mémoriser la date ?
    Bonjour à tous,

    Dans le cadre d'un stage, j'ai besoin de stocker des données ayant été collectées sur des véhicules quotidiennement. Souhaitant garder un historique des données collectées, on souhaite pouvoir accéder dans la BDD aux données collectées entre la date X et Y (pour tous les véhicules ou seulement un). Durant mes cours de MCD, il me semble que l'on réalisait des relations ternaires avec une entité date pour mémoriser la date de la donnée, mais cela semble complexifier énormément le MCD.

    J'avais donc d'abord pensé à cela, mais ça me semble incorrect en raison des cardinalités 1:1 :
    Nom : concept1.PNG
Affichages : 214
Taille : 52,5 Ko

    J'ai donc pensé à simplifier les relations ternaires en 2 relations 1-1 :
    Nom : concept2.PNG
Affichages : 216
Taille : 49,5 Ko

    Mais je me suis ensuite demandé, pourquoi ne pas mémoriser la date directement dans les entités (puisqu'il s'agit d'un datetime, il y a très peu de chance que la date sois identique pour deux données) :
    Nom : concept3.PNG
Affichages : 194
Taille : 38,4 Ko

    Et finalement, j'en suis arrivé à me demander si je ne pouvais pas centraliser toutes mes données dans une grosse entité DATA (sachant que la liste des données présentées est non exhaustive, c'est à titre d'exemple) :
    Nom : concept4.PNG
Affichages : 190
Taille : 23,6 Ko

    La dernière approche me semblant un peu brute, je suis maintenant complètement perdu sur la meilleure approche à adopter (mes cours de MCD commençant en plus à dater un peu...).
    Quelqu'un saurait-il me dire quelle approche serait à privilégier et pourquoi ? Merci d'avance.

    Cordialement

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Si à chaque instant où on fait une mesure, il faut relever à la fois la géolocalisation, la consommation et la distance parcourue, il n'est pas aberrant d'avoir une type d'entité unique (ce que vous avez appelé "DATA") possédant tous les attributs.
    Mais en ce cas, un seul attribut d'horodatage est requis.
    Si à l'inverse, l'instant où on mesure la géolocalisation, celui où on mesure la distance et celui où on mesure la consommation peuvent être différents, 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 connaître les conditions de roulage, n'a qu'un intérêt limité.

    On peut considérer que la mesure est une entité-type faible du véhicule, la mesure pourrait donc être identifiée relativement au véhicule :
    [VEHICULE] 0,n --- (effectuer) --- 1,1(R) [MESURE]

    À noter : il existe des types de données spécifiques aux données spatiales (les types geometry et geography), le premier est adapté aux données dans un plan, le deuxième est adapté aux mesures terrestres (prise en compte de la forme ellipsoïdale de la terre). Le type FLOAT, peu précis, n'est pas pertinent pour des mesures fines.

  3. #3
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2015
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Août 2015
    Messages : 7
    Points : 8
    Points
    8
    Par défaut
    Bonjour,

    Merci de ta réponse, en effet, le moment auquel les données sont mesurées par le véhicule peut différer en fonction des données. Concrètement, un véhicule peut tout à fait mesurer sa position à 11h00, sa distance parcourue à 14h et sa consommation à 16h. Je vais personnellement récupérer les 3 données au même moment, lors de l'appel à l'API (obtenant ainsi pour chaque donnée la mesure la plus récente effectuée). J'avais ainsi considéré tout mettre dans la même entité puisque je récupère à chaque fois un set de donnée complet (avec des données horodatées différemment).
    Mais séparer les entités semble en effet plus probant.

    Il reste cependant une incertitude au vu de ta réponse, faut-il externaliser l'entité date ? (lequel des deux concepts ci-dessous te semble le plus approprié ?)
    Nom : concept2.PNG
Affichages : 166
Taille : 49,5 Ko
    OU
    Nom : concept3.PNG
Affichages : 169
Taille : 38,4 Ko

    Concernant l'intérêt de mesurer la consommation seule, les 3 données présentées dans mon MCD sont là à titre d'exemple. Concrètement le set de données sera beaucoup plus important, mais je n'avais pas à cœur de réaliser le MCD complet 4 fois pour poser ma question .

    Et merci pour ton conseil sur les types de données, je vais regarder ça plus en détail !

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Une entité DATE (ou planning, agenda...) n'est nécessaire que lorsqu'il doit y avoir une planification des dates.

    Par exemple, pour un médecin, une entité date au pas de 15 minutes sera nécessaire pour organiser les créneaux des RV de consultation. De même pour une entreprise de contrôle technique des véhicule. Toutes ces dates/heures devront être pré-saisie pour les mois et les années à venir.

    C'est donc pour planifier le temps, c'est à dire prévoir à priori les créneaux temporels (par exemple pour des relevés de capteurs sur les cours d'eau pour la gestion des crues, j'ai modélisé une entité temporelle au pas de 5 minutes, car les capteur envoi leurs données toutes les 5 minutes...°.

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

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2015
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Août 2015
    Messages : 7
    Points : 8
    Points
    8
    Par défaut
    Merci beaucoup, c'est vrai que vu comme ça tout prends son sens !

    Je visualise maintenant beaucoup mieux comment concevoir ma BDD

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Bonne pratique pour inclure source de projet open source ?
    Par joseph_p dans le forum Eclipse Java
    Réponses: 3
    Dernier message: 05/07/2007, 22h51
  2. Réponses: 5
    Dernier message: 12/09/2006, 19h06
  3. Tutoriel SEO : Introduction et bonnes pratiques pour l'optimisation de pages Web
    Par Community Management dans le forum Référencement
    Réponses: 0
    Dernier message: 06/07/2006, 01h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo