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 :

Relation réflexive dans un réseau de distribution import/export [MCD]


Sujet :

Schéma

  1. #1
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut Relation réflexive dans un réseau de distribution import/export
    Bonjours,
    Après un bon moment de réflexion, je trouve toujours pas le MCD qui représente correctement la solution que je doit concevoir:

    Le problème est de concevoir la gestion d'un réseau de distribution d'eau qui interconnecte plusieurs villes.
    Voici les règles fondamentales:
    Une ville peut importer et exporter de l'eau de/à plusieurs villes.
    Chaque connexion réseau entre deux villes est liée à un compteur de consommation d'eau.
    Le compteur est utilisé pour calculer la quantité d'eau qui transite entre une ville à l'autre dans les deux sens (import / export).
    Le but et d'avoir mensuellement dans chacune des villes du réseau et par compteur la quantité d'eau importée et la quantité exportée.

    j'ai traduit ces règle ainsi:
    ville---1,N------importe-----1,N------ville
    ville---1,N------exporte-----1,N------ville
    ville---1,N------utilise-----1,N------compteur
    compteur---1,1------enregistre-----1,N------consommation

    Ci-joint le model que j'ai conçu qui pose un problème majeur : quant j'enregistre une consommation j'arrive pas à identifier la ville exportatrice et la ville importatrice de la quantité transitée !
    J'attends vos idées pour améliorer mon MCD.
    Merci.
    Images attachées Images attachées  

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir adelneo,



    Citation Envoyé par adelneo
    Quand j'enregistre une consommation j'arrive pas à identifier la ville exportatrice et la ville importatrice de la quantité transitée !
    Vous pourriez vous orienter vers une modélisation du genre de celle-ci :


    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Merci pour votre réponse rapide.
    Je suis pour le moment noyé dans le travail ce qui m’empêche d'analyser le MCD que vous avez conçu.
    je ferais mon possible pour le faire dans la journée.

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonjour adelneo,


    Pas de problème, je reste à l'écoute.


    Bon courage
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #5
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Citation Envoyé par adelneo Voir le message
    Bonjours,
    Voici les règles fondamentales:
    ....
    Chaque connexion réseau entre deux villes est liée à un compteur de consommation d'eau.
    ...
    .
    J'ai oublié de mentionner une règle importante:
    Deux villes peuvent être interconnectée par plusieurs point donc plusieurs compteurs; d'ou la règle: ville---1,N------utilise-----1,N------compteur.
    Et cela change un peu le MCD de MR fsmrel.
    Ci-joint le schéma des modifications que j'ai apporté.
    Qu'en pensez vous ?
    Images attachées Images attachées  

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir adelneo,


    D’accord pour la nouvelle règle.


    Quelques observations à propos de votre diagramme :

    (1) Concernant la table des consommations, vous avez défini une clé primaire singleton {id_consommation}, soit. Mais il ne faudra pas oublier de définir une clé candidate supplémentaire {id_compteur, date_consommation}, c'est-à-dire une contrainte d’unicité voulant que pour un compteur donné, à une date donnée, on ait une seule valeur pour l’attribut index_initial, même chose pour l’attribut index_final. L’alternative consiste à ne pas mettre en oeuvre cet attribut id_consommation, et rendre la paire {id_compteur, date_consommation} clé primaire (qui est en même temps clé étrangère) :






    (2) La paire d’associations entre VILLE et LIVRAISON est justifiée, puisqu’elle traduit la réflexivité entre villes. Par contre la paire d’associations entre LIVRAISON et LIVRAISON_COMPTEUR n’est pas justifiée, car elle voudrait dire qu’il y a réflexivité entre les livraisons, ce qui n’est pas le cas : une de ces deux associations doit donc disparaître.


    (3) Vous avez défini le triplet {id_ville_import, id_ville_export, id_compteur} comme clé primaire de la table LIVRAISON_COMPTEUR. Cela veut dire qu’un compteur peut être utilisé pour plus de de deux villes :


    id_compteur id_ville_import id_ville_export
    c1 v1 v2
    c2 v1 v2
    c2 v1 v3


    Les deux 1res lignes du tableau sont légales (entre v1 et v2 on peut avoir plus d’un compteur), mais si un compteur n’est utilisé au plus que pour deux villes, alors la 3e ligne ne peut pas exister. Si donc un compteur ne concerne que deux villes, celle d’import et celle d’export, alors la clé primaire de la table LIVRAISON_COMPTEUR se réduit au singleton {id_compteur} :





    (4) Supposons maintenant qu’il y ait des compteurs qui ne soient pas encore affectés. Dans ces conditions, la table CONSOMMATION doit être associée non pas à la table COMPTEUR, mais LIVRAISON_COMPTEUR :






    (5) La table LIVRAISON_COMPTEUR serait nécessaire s’il pouvait exister des livraisons non concernées par des compteurs. En revanche, si chaque livraison fait référence à au moins un compteur, ce qui découle de la nouvelle la règle :

    ville---1,N------utilise-----1,N------compteur »

    Alors la table LIVRAISON peut absorber la table COMPTEUR :






    (6) Dans les diagrammes précédents, un compteur peut ne pas être associé à des livraisons. S’il devait l’être, on pourrait fondre les tables COMPTEUR et LIVRAISON :


    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  7. #7
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Bonjours,

    Citation Envoyé par fsmrel Voir le message
    Bonsoir adelneo,
    (1) Concernant la table des consommations, vous avez défini une clé primaire singleton {id_consommation}, soit. Mais il ne faudra pas oublier de définir une clé candidate supplémentaire {id_compteur, date_consommation}, c'est-à-dire une contrainte d’unicité voulant que pour un compteur donné, à une date donnée, on ait une seule valeur pour l’attribut index_initial, même chose pour l’attribut index_final. L’alternative consiste à ne pas mettre en oeuvre cet attribut id_consommation, et rendre la paire {id_compteur, date_consommation} clé primaire (qui est en même temps clé étrangère)
    Je suis d'accord.

    Citation Envoyé par fsmrel Voir le message
    (2) La paire d’associations entre VILLE et LIVRAISON est justifiée, puisqu’elle traduit la réflexivité entre villes. Par contre la paire d’associations entre LIVRAISON et LIVRAISON_COMPTEUR n’est pas justifiée, car elle voudrait dire qu’il y a réflexivité entre les livraisons, ce qui n’est pas le cas : une de ces deux associations doit donc disparaître.
    Là aussi je suis d'accord: est ce que ça suffit de lier livraisons.id_ville_import à livraisons_compteurs.id_ville_import dans ce cas???

    Citation Envoyé par fsmrel Voir le message
    (3) Vous avez défini le triplet {id_ville_import, id_ville_export, id_compteur} comme clé primaire de la table LIVRAISON_COMPTEUR. Cela veut dire qu’un compteur peut être utilisé pour plus de de deux villes :
    Oui, il peut être utilisé par plus de deux villes .

    Citation Envoyé par fsmrel Voir le message
    (4) Supposons maintenant qu’il y ait des compteurs qui ne soient pas encore affectés.
    Cette supposition n'est pas envisageable dans le système: un compteur doit obligatoirement être affecté à au moins deux villes.

    Citation Envoyé par fsmrel Voir le message
    (5) La table LIVRAISON_COMPTEUR serait nécessaire s’il pouvait exister des livraisons non concernées par des compteurs. En revanche, si chaque livraison fait référence à au moins un compteur, ce qui découle de la nouvelle la règle :

    ville---1,N------utilise-----1,N------compteur »

    Alors la table LIVRAISON peut absorber la table COMPTEUR :
    Je confirme que chaque livraison fait référence à un et un seul compteur, mais un compteur peut faire référence à plusieurs livraisons.
    Exemple:
    Livraison 1/ La ville V1 export de l'eau à la ville V2 via le compteur C1
    Livraison 2/ La ville V1 importe de l'eau de la ville V2 via le même compteur C1
    sachant que les deux livraisons s'effectuent dans la même date D
    dans ce cas, on a deux livraisons différentes via le même compteur C1 et dans la même date D.


    Citation Envoyé par fsmrel Voir le message
    (6) Dans les diagrammes précédents, un compteur peut ne pas être associé à des livraisons. S’il devait l’être, on pourrait fondre les tables COMPTEUR et LIVRAISON :
    Oui un compteur peut ne pas être associé à des livraisons. mais avec cette conception on pourra pas représenter l'exemple expliqué ci dessus.

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonjour adelneo,



    Citation Envoyé par adelneo
    Livraison 1/ La ville V1 exporte de l'eau à la ville V2 via le compteur C1
    Livraison 2/ La ville V1 importe de l'eau de la ville V2 via le même compteur C1, les deux livraisons s'effectuent dans la même date D
    Cet exemple soulève des questions.

    (Q1) Y a-t-il nécessairement réciprocité, c'est-à-dire que si V1 exporte de l’eau vers V2 à la date D, V2 doit-il importer à cette date de l’eau venant de chez V1 ?

    (Q2) Si le compteur C1 est utilisé à la date D1 pour un échange entre V1 et V2, ce compteur C1 peut-il aussi être utilisé à la date D2 pour un échange entre V1 et V3 ?

    (Q3) Ce même compteur C1 peut-il être utilisé à la date D3 pour un échange entre deux autres villes, V4 et V5 ?

    (Q4) Si ce même compteur C1 est utilisé à la date D1 pour un échange entre V1 et V2, peut-il être utilisé à cette date D1 (pendant une autre période) pour un échange entre V1 et V3 ?

    (Q5) Ce même compteur C1 étant utilisé à la date D1 pour un échange entre V1 et V2, peut-il être utilisé à cette date D1 (pendant une autre période) pour un échange entre V4 et V5 ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  9. #9
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Bonjour adelneo,
    Cet exemple soulève des questions.
    (Q1) Y a-t-il nécessairement réciprocité, c'est-à-dire que si V1 exporte de l’eau vers V2 à la date D, V2 doit-il importer à cette date de l’eau venant de chez V1 ?
    Bonjour fsmrel,
    Oui c'est ça.
    Concrètement, si la ville V2 a besoin d'une quantité d'eau, elle demande aux villes limitrophes de l'exporter.
    En supposant que la ville V1 est une ville limitrophe à V2, V1 va livrer la quantité d'eau demandée vers la ville V2.
    La quantité d'eau livrée passe impérativement par le compteur C1.
    Le compteur C1 se trouvant entre V1 et V2 va automatiquement enregistrer la quantité livrée ainsi que le sens de la livraison (V1 vers V2) .

    Citation Envoyé par fsmrel Voir le message
    (Q2) Si le compteur C1 est utilisé à la date D1 pour un échange entre V1 et V2, ce compteur C1 peut-il aussi être utilisé à la date D2 pour un échange entre V1 et V3 ?
    Oui, ce scénario est possible si V3 est limitrophe à V1.

    Citation Envoyé par fsmrel Voir le message
    (Q3) Ce même compteur C1 peut-il être utilisé à la date D3 pour un échange entre deux autres villes, V4 et V5 ?
    Non.

    Citation Envoyé par fsmrel Voir le message
    (Q4) Si ce même compteur C1 est utilisé à la date D1 pour un échange entre V1 et V2, peut-il être utilisé à cette date D1 (pendant une autre période) pour un échange entre V1 et V3 ?
    En réalité, j'ai utilisé le terme date pour simplifier la représentation, mais malheureusement cela a ramener a des confusions, je suis désolé.
    La relève du compteur se fait une fois par mois.
    Donc pour répondre à votre question: supposant que V2 et V3 sont limitrophes à V1 et sont liées toutes les deux à la ville V1 en passant par le compteur C1
    Dans ces conditions dans un mois donné, C1 peut être utilisé pour calculer l'échange entre V1 et V2 et aussi entre V1 et V3.

    Citation Envoyé par fsmrel Voir le message
    (Q5) Ce même compteur C1 étant utilisé à la date D1 pour un échange entre V1 et V2, peut-il être utilisé à cette date D1 (pendant une autre période) pour un échange entre V4 et V5 ?
    Non.

  10. #10
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir adelneo,


    Je récapépète :

    A ma question (Q1) :

    Citation Envoyé par fsmrel

    Citation Envoyé par adelneo
    Livraison 1/ La ville V1 exporte de l'eau à la ville V2 via le compteur C1
    Livraison 2/ La ville V1 importe de l'eau de la ville V2 via le même compteur C1, les deux livraisons s'effectuent dans la même date D
    Cet exemple soulève des questions.

    (Q1) Y a-t-il nécessairement réciprocité, c'est-à-dire que si V1 exporte de l’eau vers V2 à la date D, V2 doit-il importer à cette date de l’eau venant de chez V1 ?
    Vous répondez :

    Citation Envoyé par adelneo
    Le compteur C1 se trouvant entre V1 et V2 va automatiquement enregistrer la quantité livrée ainsi que le sens de la livraison (V1 vers V2) .
    Je repose donc ma question (en remplaçant Date par Période) :

    (Q1’) Y a-t-il nécessairement réciprocité, c'est-à-dire que, si V1 exporte de l’eau vers V2 durant la période P, V2 doit-il lui aussi importer au cours de cette période de l’eau venant de chez V1 ? Est-ce bien une obligation (ce que sous-entend votre formulation initiale) ou seulement une possibilité ?



    Citation Envoyé par adelneo
    dans un mois donné, C1 peut être utilisé pour calculer l'échange entre V1 et V2 et aussi entre V1 et V3.
    Plus généralement, si C1 est utilisé pour V1 et si V2, V3, ..., Vn sont limitrophes de V1, je suppose que C1 peut enregistrer les échanges entre V1 et toutes ces villes qui lui sont limitrophes. C’est ça ?

    Mais si C2 est utilisé pour V3 et toutes les villes qui lui sont limitrophes (donc V1), C1 et C2 ne vont-ils pas faire double emploi ?


    Pardonnez-moi d'insister ainsi, mais je cherche à comprendre la structure précise du réseau, de l'implantation des compteurs, les contraintes qui en résultent, donc l'impact sur la modélisation des livraisons...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  11. #11
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Bonjour fsmrel,

    Citation Envoyé par fsmrel Voir le message
    Bonsoir adelneo,
    (Q1’) Y a-t-il nécessairement réciprocité, c'est-à-dire que, si V1 exporte de l’eau vers V2 durant la période P, V2 doit-il lui aussi importer au cours de cette période de l’eau venant de chez V1 ? Est-ce bien une obligation (ce que sous-entend votre formulation initiale) ou seulement une possibilité ?
    Effectivement, c'est réciproque et c'est obligatoire.

    Citation Envoyé par fsmrel Voir le message
    Plus généralement, si C1 est utilisé pour V1 et si V2, V3, ..., Vn sont limitrophes de V1, je suppose que C1 peut enregistrer les échanges entre V1 et toutes ces villes qui lui sont limitrophes. C’est ça ?
    Mais si C2 est utilisé pour V3 et toutes les villes qui lui sont limitrophes (donc V1), C1 et C2 ne vont-ils pas faire double emploi ?
    pas du-tout, puisque entre deux villes limitrophes, on peut avoir plusieurs points de livraison (de 1 à N) et chaque point de livraison est lié à un compteur.
    Les points de livraisons sont éloignées les uns des autres par plusieurs kilomètres.
    Techniquement, si les deux villes V1 et V2 sont liée par deux points de livraison P1 et P2, P1 doit être installé dans un cartier limitrophe CA1, et P2 dans un autre cartier limitrophe CA2 (CA1 et CA2 sont des cartiers de la ville V1).
    Si la ville V1 a besoin d'une quantité d'eau au niveau du cartier CA1, logiquement, elle va l'importer par le biais du point P1 et la quantité importée sera enregistrée par le compteur C1.
    Si le besoin est au niveau de CA2, l'importation s’effectuera sur P2 donc enregistrée par le compteur C2.

    Citation Envoyé par fsmrel Voir le message
    Pardonnez-moi d'insister ainsi, mais je cherche à comprendre la structure précise du réseau, de l'implantation des compteurs, les contraintes qui en résultent, donc l'impact sur la modélisation des livraisons...
    Ne vous inquiétez pas, c'est ma faute de ne pas avoir bien expliquer le fonctionnement du réseau.

  12. #12
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir adelneo,


    Décidemment, il faudrait que je surveille mes copier/coller...

    Dans mon message précédent, j’ai écrit :

    (Q1’) Y a-t-il nécessairement réciprocité, c'est-à-dire que, si V1 exporte de l’eau vers V2 durant la période P, V2 doit-il lui aussi importer au cours de cette période de l’eau venant de chez V1 ? Est-ce bien une obligation (ce que sous-entend votre formulation initiale) ou seulement une possibilité ?

    Il est évidemment qu’il n’y a pas là une quelconque réciprocité, mais un truisme... La question en relation avec la réciprocité est en fait la suivante :

    (Q1’) Y a-t-il nécessairement réciprocité, c'est-à-dire que, si V1 exporte de l’eau vers V2 durant la période P, V2 doit-il lui aussi exporter au cours de cette période de l’eau à destination de V1 ?


    Indépendamment de cette question, je reprends la règle de votre 1er message :


    VILLE---1,N------UTILISE-----1,N----COMPTEUR


    On infère que la relation entre villes, leur interconnexion, est connue grâce à l’association UTILISE. Les consommations font alors l’objet d’une table CONSOMMATION assez comparable à la vôtre. Le diagramme deviendrait le suivant :





    Exemple de contenu de la table CONSOMMATION en ce qui concerne le compteur c1 :


    
    id_compteur    id_ville_export    id_ville_import    date_conso    index_initial    index_final
    
    c1             v1                 v2                 d1            xi1121           xf1121
    c1             v1                 v2                 d2            xi1122           xf1122
    c1             v1                 v3                 d1            xi1131           xf1131
    c1             v2                 v3                 d1            xi1231           xf1231
    c1             v2                 v1                 d2            xi1212           xf1212
    c1             v3                 v1                 d1            xi1311           xf1311
    
    

    Sommes-nous en phase ? (Aux erreurs de copier/coller près )


    N.B. Serait-il utille de modéliser les point de livraison ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  13. #13
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Bonjour,
    Citation Envoyé par fsmrel Voir le message
    (Q1’) Y a-t-il nécessairement réciprocité, c'est-à-dire que, si V1 exporte de l’eau vers V2 durant la période P, V2 doit-il lui aussi importer au cours de cette période de l’eau venant de chez V1 ? Est-ce bien une obligation (ce que sous-entend votre formulation initiale) ou seulement une possibilité ?

    Il est évidemment qu’il n’y a pas là une quelconque réciprocité, mais un truisme... La question en relation avec la réciprocité est en fait la suivante :

    (Q1’) Y a-t-il nécessairement réciprocité, c'est-à-dire que, si V1 exporte de l’eau vers V2 durant la période P, V2 doit-il lui aussi exporter au cours de cette période de l’eau à destination de V1 ?
    Non c'est pas une obligation mais c'est une possibilité.

    Citation Envoyé par fsmrel Voir le message
    Indépendamment de cette question, je reprends la règle de votre 1er message :


    VILLE---1,N------UTILISE-----1,N----COMPTEUR


    On infère que la relation entre villes, leur interconnexion, est connue grâce à l’association UTILISE. Les consommations font alors l’objet d’une table CONSOMMATION assez comparable à la vôtre. Le diagramme deviendrait le suivant :





    Exemple de contenu de la table CONSOMMATION en ce qui concerne le compteur c1 :


    
    id_compteur    id_ville_export    id_ville_import    date_conso    index_initial    index_final
    
    c1             v1                 v2                 d1            xi1121           xf1121
    c1             v1                 v2                 d2            xi1122           xf1122
    c1             v1                 v3                 d1            xi1131           xf1131
    c1             v2                 v3                 d1            xi1231           xf1231
    c1             v2                 v1                 d2            xi1212           xf1212
    c1             v3                 v1                 d1            xi1311           xf1311
    
    

    Sommes-nous en phase ? (Aux erreurs de copier/coller près )
    Apparemment la conception est correcte (appart le manque de la relation entre ville-compteur et consommation sur le schéma pour la colonne id_compteur).

    Citation Envoyé par fsmrel Voir le message
    N.B. Serait-il utille de modéliser les point de livraison ?
    Non, modéliser les points de livraison, n'est pas dans l'ordre du jour.

    Question : Supposant qu'on a une autre table utilisateur (utilisateur de l'application) liée à la table ville avec la règle Utilisateur-------1,1-------Habite-------1,N-------Ville
    L'utilisateur U1 (qui habite à la ville V1) enregistre les consommations de de l’échange (Import / Export) entre V1 et V2 au niveau du compteur C1.
    L'utilisateur U2 (qui habite à la ville V2) enregistre les consommations de de l’échange (Import / Export) entre V2 et V1 au niveau du compteur C1.
    Techniquement, les quantités enregistrées doivent être les mêmes (c-à-d U1 et U2 doivent enregistrer les mêmes quantités) puisque la quantité importée par V1 de V2 est la même quantité exportée par V2 vers V1.
    Serait il nécessaire de créer une table temporaire pour enregistrer les consommations saisies par les deux utilisateurs dans le but de les comparer avant d'enregistrer la consommation exacte dans la table consommations (sachant que la phase de comparaison est obligatoire) ?? ou y a t'il une autre possibilité??

  14. #14
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir adelneo,



    Citation Envoyé par adelneo
    Apparemment la conception est correcte (appart le manque de la relation entre ville-compteur et consommation sur le schéma pour la colonne id_compteur).
    La table VILLE_COMPTEUR a pour clé primaire la paire {id_compteur, id_ville}, et la table CONSOMMATION a deux clés étrangères faisant référence à cette clé primaire : {id_compteur, id_ville_import} et {id_compteur, id_ville_export} : la colonne id_compteur est donc bien présente, en tant qu’élément de chacune de ces deux clés étrangères.


    Script SQL correspondant :


    
    CREATE TABLE VILLE 
    (
            id_ville                      INT               NOT NULL,
            nom_ville                     VARCHAR(32)       NOT NULL,
          CONSTRAINT VILLE_PK PRIMARY KEY (id_ville)
    ) ;
    
    CREATE TABLE COMPTEUR 
    (
            id_compteur                   INT               NOT NULL,
            numero_compteur               VARCHAR(32)       NOT NULL,
          CONSTRAINT COMPTEUR_PK PRIMARY KEY (id_compteur),
          CONSTRAINT COMPTEUR_AK UNIQUE (numero_compteur)
    ) ;
    
    CREATE TABLE VILLE_COMPTEUR 
    (
            id_compteur                   INT               NOT NULL,
            id_ville                      INT               NOT NULL,
            CONSTRAINT VILLE_COMPTEUR_PK PRIMARY KEY (id_compteur, id_ville),
            CONSTRAINT VILLE_COMPTEUR_COMPTEUR_FK FOREIGN KEY (id_compteur)
                REFERENCES COMPTEUR (id_compteur),
            CONSTRAINT VILLE_COMPTEUR_VILLE_FK FOREIGN KEY (id_ville)
                REFERENCES VILLE (id_ville)
    ) ;
    
    CREATE TABLE CONSOMMATION 
    (
            id_compteur                   INT               NOT NULL,
            id_ville_export               INT               NOT NULL,
            id_ville_import               INT               NOT NULL,
            date_conso                    DATE              NOT NULL,
            index_initial                 INT               NOT NULL,
            index_final                   INT               NOT NULL,
          CONSTRAINT CONSOMMATION_PK PRIMARY KEY (id_compteur, id_ville_export, id_ville_import, date_conso),
          CONSTRAINT CONSOMMATION_VILLE_COMPTEUR_EXPORT_FK FOREIGN KEY (id_compteur, id_ville_import)
              REFERENCES VILLE_COMPTEUR (id_compteur, id_ville),
          CONSTRAINT CONSOMMATION_VILLE_COMPTEUR_IMPORT_FK FOREIGN KEY (id_compteur, id_ville_export)
              REFERENCES VILLE_COMPTEUR (id_compteur, id_ville)
    ) ;
    
    CREATE TABLE UTILISATEUR 
    (
            id_utilisateur                INT               NOT NULL,
            id_ville                      INT               NOT NULL,
            nom_utilisateur               VARCHAR(32)       NOT NULL,
          CONSTRAINT UTILISATEUR_PK PRIMARY KEY (id_utilisateur),
          CONSTRAINT UTILISATEUR_VILLE_FK FOREIGN KEY (id_ville)
              REFERENCES VILLE (id_ville)
    ) ;
    
    

    Un début de jeu d’essai :


    
    INSERT INTO UTILISATEUR (id_utilisateur, id_ville, nom_utilisateur) VALUES
        (1, 1, 'Fernand'), (2, 2, 'Raoul'), (3, 3, 'Paul'), (4, 4, 'Pascal')
    ;    
    
    INSERT INTO VILLE (id_ville, nom_ville) VALUES
        (1, 'ville v1'), (2, 'ville v2'), (3, 'ville v3'), (4, 'ville v4'), (5, 'ville v5')
    ;    
    
    INSERT INTO COMPTEUR (id_compteur, numero_compteur) VALUES
        (1, 'compteur c1'), (2, 'compteur c2'), (3, 'compteur c3'), (4, 'compteur c4'), (5, 'compteur c5')
    ;    
    
    INSERT INTO VILLE_COMPTEUR (id_compteur, id_ville) VALUES
        (1, 1), (1, 2), (1, 3), (2, 1), (2, 2), (2, 3), (3, 1), (3, 4), (3, 5)
    ;
    
    INSERT INTO CONSOMMATION (id_compteur, id_ville_export, id_ville_import, date_conso, index_initial, index_final) VALUES
        (1, 1, 2, '2015-01-31', 1000, 1500)
      , (1, 1, 2, '2015-02-28', 1400, 2000)
      , (1, 1, 3, '2015-01-31', 1700, 2300)
      , (1, 2, 3, '2015-01-31', 2400, 2500)  
      , (1, 2, 1, '2015-02-28', 1100, 1200) 
      , (1, 3, 1, '2015-02-28', 1300, 1400)   
      , (2, 1, 2, '2015-01-31', 1000, 1500)
      , (2, 1, 2, '2015-02-28', 2400, 2700)
    ;
    
    SELECT * FROM CONSOMMATION ;
    
    

    Résultat du SELECT :

    
    id_compteur    id_ville_export    id_ville_import    date_conso    index_initial    index_final
    -----------    ---------------    ---------------    ----------    -------------    -----------
              1                  1                  2    2015-01-31             1000           1500
              1                  1                  2    2015-02-28             1400           2000
              1                  1                  3    2015-01-31             1700           2300
              1                  2                  1    2015-02-28             1100           1200
              1                  2                  3    2015-01-31             2400           2500
              1                  3                  1    2015-02-28             1300           1400
              2                  1                  2    2015-01-31             1000           1500
              2                  1                  2    2015-02-28             2400           2700
    
    


    Citation Envoyé par adelneo
    L'utilisateur U1 (qui habite à la ville V1) enregistre les consommations de de l’échange (Import / Export) entre V1 et V2 au niveau du compteur C1.
    L'utilisateur U2 (qui habite à la ville V2) enregistre les consommations de de l’échange (Import / Export) entre V2 et V1 au niveau du compteur C1.
    Je ne comprends pas bien, quelque chose m'échappe... Le résultat du SELECT ci-dessus est-il conforme ? Voulez-vous dire que ce sont U1 et U2 qui mettent à jour la table CONSOMMATION ? Sinon, enregistrent-ils les consommations dans leurs propres tables (non représentées ici) en recopiant le contenu de la table CONSOMMATION ? S’agit-il d’un autre scénario ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  15. #15
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Bonjours fsmrel;

    Citation Envoyé par fsmrel Voir le message
    Bonsoir adelneo,
    Je ne comprends pas bien, quelque chose m'échappe... Le résultat du SELECT ci-dessus est-il conforme ? Voulez-vous dire que ce sont U1 et U2 qui mettent à jour la table CONSOMMATION ? Sinon, enregistrent-ils les consommations dans leurs propres tables (non représentées ici) en recopiant le contenu de la table CONSOMMATION ? S’agit-il d’un autre scénario ?
    Oui, le résultat du SELECT est conforme.

    U1 (id_utilisateur=1) et U2 (id_utilisateur=2) sont des utilisateurs de l'application ayant la tâche de saisir les consommations (Import / Export) de leur ville d’appartenance.
    Je veux éviter que ces utilisateurs inscrivent les consommations directement dans la table CONSOMMATION.

    Voici le scénario:
    1/U1 se connecte à l'application en tant que utilisateur de la ville V1.
    U1 enregistre toutes les consommations du mois M de la ville V1 dans une table temporaire TEMP.
    U1 se déconnecte de l'application.

    2/U2 se connecte à l'application en tant que utilisateur de la ville V2.
    U2 enregistre toutes les consommations du mois M de la ville V2 dans la table temporaire TEMP.
    U2 se déconnecte de l'application.

    et ainsi de suite pour les utilisateurs des autres villes.

    Script SQL correspondant à création de la table TEMP (il manque les clés étrangères !):
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    CREATE TABLE TEMP
    (
            id_utilisateur                INT               NOT NULL,
            id_compteur                   INT               NOT NULL,
            id_ville_export               INT               NOT NULL,
            id_ville_import               INT               NOT NULL,
            date_conso                    DATE              NOT NULL,
            index_initial                 INT               NOT NULL,
            index_final                   INT               NOT NULL,
          CONSTRAINT CONSOMMATION_PK PRIMARY KEY (id_utilisateur, id_compteur, id_ville_export, id_ville_import, date_conso),
    );
    Le jeu d'essai:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    INSERT INTO TEMP (id_utilisateur,id_compteur, id_ville_export, id_ville_import, date_conso, index_initial, index_final) VALUES
        (1,1, 1, 2, '2015-01-31', 1000, 1500)
      , (1,1, 1, 2, '2015-02-28', 1400, 2000)
      , (1,1, 1, 3, '2015-01-31', 1700, 2300)
      , (2,1, 2, 3, '2015-01-31', 2400, 2500)  
      , (2,1, 2, 1, '2015-02-28', 1100, 1200) 
      , (1,1, 3, 1, '2015-02-28', 1300, 1400)   
      , (2,2, 1, 2, '2015-01-31', 1000, 1500)
      , (2,2, 1, 2, '2015-02-28', 2400, 2700)
      , (2,1, 1, 2, '2015-01-31', 1000, 1400)
    ;
    SELECT * FROM TEMP;
    Le résultat du SELECT:

    id_utilisateur id_compteur id_ville_export id_ville_import date_conso index_initial index_final
    ------------- ----------- --------------- --------------- ------------ ------------- -----------
    1 1 1 2 2015-01-31 1000 1500
    1 1 1 2 2015-02-28 1400 2000
    1 1 1 3 2015-01-31 1700 2300
    2 1 2 1 2015-02-28 1100 1200
    2 1 2 3 2015-01-31 2400 2500
    1 1 3 1 2015-02-28 1300 1400
    2 2 1 2 2015-01-31 1000 1500
    2 2 1 2 2015-02-28 2400 2700
    2 1 1 2 2015-01-31 1000 1400

    Concentrons-nous sur le premier et le dernier enregistrement :
    Les utilisateurs U1 et U2 ont enregistré l'échange entre Ville V1(exportatrice) et Ville V2(importatrice) pour la même date 2015-01-31.
    Les valeurs des index (initial et final) doivent être les mêmes pour valider les valeurs de l'échange et les enregistrer dans la table CONSOMMATION.
    Or c'est pas le cas (U1 a saisi 1500 pour l'index final alors que U2 a saisi 1400);
    Après vérification U2 corrige l'erreur et remplace 1400 par 1500.
    La validation est désormais possible et la table CONSOMMATION reçoit l'enregistrement suivant:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO CONSOMMATION (id_compteur, id_ville_export, id_ville_import, date_conso, index_initial, index_final) VALUES
        (1, 1, 2, '2015-01-31', 1000, 1500);
    Pour résumer, un échange entre deux villes est enregistré par deux utilisateurs (chacun appartenant à une d'elle). La comparaison des deux enregistrements est obligatoire avant de valider l'opération et l’enregistrer dans la table CONSOMMATION.
    Est ce que l'utilisation d'une table temporaire pour permettre la comparaison est une bonne idée ??

  16. #16
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir adelneo,


    On peut effectivement mettre en oeuvre une table, temporaire ou non (car après tout, elle peut figurer dans le modèle des données), appelons-la UTILISATEUR_CONSOMMATION (ou TEMP, comme vous voulez), dans laquelle chaque utilisateur insère (et corrige) ce qu’il a relevé.

    Comme un utilisateur « habite » une commune et une seule, si celle-ci correspond à la commune d’import (ou d’export, au choix), alors la clé primaire est réductible, l’attribut id_ville_export n’en fait pas partie (ou id_ville_import, toujours au choix) et devient :

    {id_utilisateur, id_compteur, id_ville_export, date_conso}


    Les clés étrangères sont analogues à celles utilisées pour la table CONSOMMATION, avec en plus celle qui référence la table UTILISATEUR :


    
    CREATE TABLE UTILISATEUR_CONSOMMATION 
    (
            id_utilisateur                INT               NOT NULL,
            id_compteur                   INT               NOT NULL,
            id_ville_export               INT               NOT NULL,
            id_ville_import               INT               NOT NULL,
            date_conso                    DATE              NOT NULL,
            index_initial                 INT               NOT NULL,
            index_final                   INT               NOT NULL,
         CONSTRAINT UTILISATEUR_CONSOMMATION_PK PRIMARY KEY (id_utilisateur, id_compteur, id_ville_export, date_conso),
         CONSTRAINT UTILISATEUR_CONSOMMATION_VILLE_COMPTEUR_EXPORT_FK FOREIGN KEY (id_compteur, id_ville_import)
              REFERENCES VILLE_COMPTEUR (id_compteur, id_ville),
          CONSTRAINT UTILISATEUR_CONSOMMATION_VILLE_COMPTEUR_IMPORT_FK FOREIGN KEY (id_compteur, id_ville_export)
              REFERENCES VILLE_COMPTEUR (id_compteur, id_ville)
       ,  CONSTRAINT UTILISATEUR_CONSOMMATION_UTILISATEUR_FK FOREIGN KEY (id_utilisateur)
             REFERENCES UTILISATEUR (id_utilisateur)
    ) ;
    
    

    La requête qui permet de connaître les relevés cohérents :

    
    SELECT x.id_compteur, x.date_conso, x.id_utilisateur, x.id_ville_export AS vers_ville, x.id_ville_import AS depuis_ville, x.index_initial, x.index_final
    FROM   UTILISATEUR_CONSOMMATION AS x JOIN UTILISATEUR_CONSOMMATION AS y
              ON  x.id_compteur = y.id_compteur
             AND  x.date_conso = y.date_conso
             AND  x.id_ville_export = y.id_ville_import   
             AND  x. index_initial = y.index_initial 
             AND x.index_final = y.index_final     
             AND x.id_utilisateur <> y.id_utilisateur
    ORDER BY x.id_compteur, x.date_conso, x.id_ville_export       
    ;
    
    

    La requête qui permet de connaître les relevés non cohérents :


    
    SELECT id_compteur, date_conso, id_utilisateur, id_ville_export AS vers_ville, id_ville_import AS depuis_ville, index_initial, index_final
    FROM   UTILISATEUR_CONSOMMATION AS x
    WHERE  NOT EXISTS 
          (SELECT ''
           FROM   UTILISATEUR_CONSOMMATION AS y
           WHERE  x.id_compteur = y.id_compteur
             AND  x.date_conso = y.date_conso
             AND  x.id_ville_export = y.id_ville_import   
             AND  x. index_initial = y.index_initial AND x.index_final = y.index_final     
             AND x.id_utilisateur <> y.id_utilisateur)
    ORDER BY id_compteur, date_conso, id_ville_export       
    ;
    
    
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  17. #17
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut clé étrangère référençant une surclé
    Bonjour adelneo,


    A toutes fins utiles, on peut observer que selon le script SQL actuel, un utilisateur de la commune V1 peut effectuer des relevés pour le compte d’une commune autre que V1. S’il ne doit pas en être ainsi, on peut blinder de la façon suivante : ajouter une surclé (clé réductible) pour la table UTILISATEUR (contrainte CONSTRAINT UTILISATEUR_SK), et modifier la contrainte UTILISATEUR_CONSOMMATION_UTILISATEUR_FK de la table UTILISATEUR_CONSOMMATION (contrainte selon laquelle par convention, l’utilisateur doit résider dans la commune importatrice) :

    
    CREATE TABLE UTILISATEUR 
    (
            id_utilisateur                INT               NOT NULL,
            id_ville                      INT               NOT NULL,
            nom_utilisateur               VARCHAR(32)       NOT NULL,
          CONSTRAINT UTILISATEUR_PK PRIMARY KEY (id_utilisateur),
          CONSTRAINT UTILISATEUR_SK UNIQUE (id_utilisateur, id_ville),
         CONSTRAINT UTILISATEUR_VILLE_FK FOREIGN KEY (id_ville)
              REFERENCES VILLE (id_ville)
    ) ;
    
    CREATE TABLE UTILISATEUR_CONSOMMATION 
    (
            id_utilisateur                INT               NOT NULL,
            id_compteur                   INT               NOT NULL,
            id_ville_export               INT               NOT NULL,
            id_ville_import               INT               NOT NULL,
            date_conso                    DATE              NOT NULL,
            index_initial                 INT               NOT NULL,
            index_final                   INT               NOT NULL,
         CONSTRAINT UTILISATEUR_CONSOMMATION_PK PRIMARY KEY (id_utilisateur, id_compteur, id_ville_export, date_conso),
         CONSTRAINT UTILISATEUR_CONSOMMATION_VILLE_COMPTEUR_EXPORT_FK FOREIGN KEY (id_compteur, id_ville_import)
              REFERENCES VILLE_COMPTEUR (id_compteur, id_ville),
          CONSTRAINT UTILISATEUR_CONSOMMATION_VILLE_COMPTEUR_IMPORT_FK FOREIGN KEY (id_compteur, id_ville_export)
              REFERENCES VILLE_COMPTEUR (id_compteur, id_ville)
       ,  CONSTRAINT UTILISATEUR_CONSOMMATION_UTILISATEUR_FK FOREIGN KEY (id_utilisateur, id_ville_import)
             REFERENCES UTILISATEUR (id_utilisateur, id_ville)
    ) ;
    
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  18. #18
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Bonjour fsmrel,
    Si j'ai bien saisi le MCD se traduit comme suit:
    Images attachées Images attachées  

  19. #19
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonjour adelneo,


    Oui, votre diagramme correspond, à la nuance près que le quadruplet {id_utilisateur, id_compteur, id_ville_import, date_conso} y est clé primaire de la table UTILISATEUR_CONSOMMATION, c'est-à-dire que l’utilisateur habite la ville id_ville_export, alors que de mon côté j’ai retenu {id_utilisateur, id_compteur, id_ville_export, date_conso} pour la clé primaire, faisant que l’utilisateur habite la ville id_ville_import. Mais, pour des raisons de symétrie évidente, nos choix respectifs se valent. L’essentiel est qu’un utilisateur ne puisse résider que dans une ville, et que cet utilisateur ne fasse pas des relevés pour le compte d’une ville qui n’est pas la sienne, d’où la surclé {id_utilisateur, id_ville} définie pour la table UTILISATEUR et la présence dans la table UTILISATEUR_CONSOMMATION de la clé étrangère {id_utilisateur, id_ville_export} chez vous, {id_utilisateur, id_ville_import} chez moi, garantissant cette contrainte.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  20. #20
    Membre éclairé

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2010
    Messages
    297
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Décembre 2010
    Messages : 297
    Points : 705
    Points
    705
    Par défaut
    Grand merci fsmrel.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. [MCD] relation réflexive dans access
    Par patmar83 dans le forum Schéma
    Réponses: 8
    Dernier message: 17/02/2011, 17h45
  2. gestion des connections à internet dans un réseau
    Par evarisnea dans le forum Web & réseau
    Réponses: 3
    Dernier message: 21/10/2005, 20h15
  3. Stopper le peer to peer dans un réseau local
    Par spopo dans le forum Administration
    Réponses: 15
    Dernier message: 19/10/2005, 19h21
  4. Import/Export d'un document Word dans un état
    Par uskiki85 dans le forum Access
    Réponses: 2
    Dernier message: 28/09/2005, 14h18
  5. Comment subsituer un chemin par un autre dans un réseau ?
    Par Baillard dans le forum Développement
    Réponses: 3
    Dernier message: 11/08/2002, 15h01

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