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

Modélisation Discussion :

Modélisation : Jointure à la carte


Sujet :

Modélisation

  1. #1
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut Modélisation : Jointure à la carte
    Bonjour,

    Attention débutant inside

    Je modélise actuellement une base de données pour une application avec les tables suivantes :



    Je souhaite représenter le fait qu'un afficheur peut être lié à un emplacement ou à un code géo ou à un groupe de sortie ou à un ensemble.

    L'ajout de la clef NO_AFFICHEUR dans chacune des tables ne me parait pas propre et surtout pas du tout évolutif. Si je souhaite lier un afficheur à une table autre de mon MCD (il est beaucoup plus vaste), alors je serai obligé de modifier ma base...

    Y a t il une solution élégante de faire cela ???
    Merci !

  2. #2
    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 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    Il suffit d'utiliser le principe de modélisation d'un héritage comme je l'indique dans cet article :
    http://sqlpro.developpez.com/cours/m...tion/heritage/

    certains outils de modélisation comme Power AMC ou Win Design implémente cela sans problème.

    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/ * * * * *

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Il suffit d'utiliser le principe de modélisation d'un héritage comme je l'indique dans cet article :
    http://sqlpro.developpez.com/cours/m...tion/heritage/

    certains outils de modélisation comme Power AMC ou Win Design implémente cela sans problème.

    A +
    Merci pour votre réponse.

    Je connaissait la modélisation par héritage que j'avais étudié pour un autre projet. Très bon article au passage d'ailleurs.
    Cependant, en tant que dev c++, j'ai cette vieille habitude de croire que l'héritage s'applique si l'entité est une sorte de.

    Or ici, l'entité EMPLACEMENT, n'est pas une sorte d'AFFICHEUR mais elle peut avoir un afficheur.
    Donc je vois pas trop comment appliquer la méthode d'héritage dans ce cas...

    Vous est il possible d'être plus précis ?

  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 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    C'est votre afficheur ensemble qui est la racine des afficheurs spécialisés

    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
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    C'est votre afficheur ensemble qui est la racine des afficheurs spécialisés

    A +
    Je suis désolé mais je ne vois toujours pas ou vous voulez en venir

    La table afficheur_ensemble est une table d'association entre un afficheur et un ensemble (qui n'est pas représentée sur le schéma ici) elle n'est pas un afficheur spécialisé.

    Bon alors je pense que j'ai mal exprimé ma demande.
    Je reformule.

    J'ai le schéma suivant :


    Comment modéliser le fait qu'un emplacement, un code geo, un groupe de sortie ou un ensemble puissent avoir un afficheur ?

    Vous allez me dire que c'est simple, en mettant juste la clef de la table afficheur dans chacune des tables citées. Mais cela ne me parait pas judicieux et pas évolutif. J'ai d'autres tables dans mon modèle. Je ne le sais pas encore mais il se peut que je soit obligé de faire un lien entre d'autres tables de mon modèle et la table afficheur.
    Je souhaite faire un modèle qui prenne en compte tout de suite cette possibilité.

    Désolé pour le doublon mais j'ai toujours l'impression que je ne suis pas clair...

    Edit : j'ai volontairement omis les autres colonnes des tables. je suppose que l'indicateur important est que j'utilise toujours un champ int unique pour clef primaire dans toutes les tables de mon modèle.

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 140
    Points : 89
    Points
    89
    Par défaut
    Citation Envoyé par Batou69 Voir le message
    Je souhaite représenter le fait qu'un afficheur peut être lié à un emplacement ou à un code géo ou à un groupe de sortie ou à un ensemble.
    C'est un OU exclusif ?
    Il peut être lié à un seul emplacement ?

    Dans l'affirmative, tu peux rajouter dans la table Afficheur la colonne LinkTable et LinkPK.

    Sinon, crée une table Affichage, avec les colonnes FKafficheur, LinkTable et LinkPK

    Pas très propre, mais très générique...

  7. #7
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    C'est effectivement très générique et c'est le but recherché.

    Le ou est exclusif, oui.

    J'ai en effet la possibilité d'associer un afficheur a plus d'un emplacement. Je penche donc, comme vous me l'avez indiqué, pour une table supplémentaire d'association.

    Je vais continuer a regarder cela. Merci

  8. #8
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    Par défaut
    Mais quel est la cardinalité de votre relation entre Afficheur et un des composants ?

    Afficheur-0,n-----Associer------1,1-Composant ?

    Sinon, concernant l'héritage :
    Il faut une entité supplémentaire qui ferai office de générateur de pk (voir peut-être certains attributs pourrai être déporté dedans)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
                                 -> Composant
                                |
               -------------------------------------------
               |            |             |             |
        Emplacement     Code_Geo    Ensemble     Groupe_sortie
    Apres selon vos cardinalité soit vous avez une table d'association entre Composant et Afficheur, soit vous allez effectivement avoir une FK dans Composant qui réfère Afficheur.

  9. #9
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par punkoff Voir le message
    Mais quel est la cardinalité de votre relation entre Afficheur et un des composants ?

    Afficheur-0,n-----Associer------1,1-Composant ?
    Si je comprend bien, c'est bien cela : un afficheur peut être associé à un ou plusieurs composants, mais un composant n'a au plus qu'un seul afficheur (il peut ne pas en avoir). Je ne sais pas bien lire cette notation encore, mais j'y travaille.

    Citation Envoyé par punkoff Voir le message
    Sinon, concernant l'héritage :
    Il faut une entité supplémentaire qui ferai office de générateur de pk (voir peut-être certains attributs pourrai être déporté dedans)

    Apres selon vos cardinalité soit vous avez une table d'association entre Composant et Afficheur, soit vous allez effectivement avoir une FK dans Composant qui réfère Afficheur.
    Je crois que je comprend. Mais je dois avouer que j'ai volontairement pas expliqué correctement et donc la solution est peut être différente.
    En fait la table ensemble sert a faire un regroupement de code geo multi niveau. C'est à dire qu'il est possible faire des groupes de code géo, qui eux même sont dans des groupe de groupes etc... Comme je ne connais pas le nombre de niveaux, je fait une représentation d'arbre intervallaire (voir l'article). Le truc c'est qu'a chaque ensemble, il est possible d'associer un afficheur...

    Le problème avec la solution d'héritage, c'est que les entités n'ont vraiment rien à voir entre elles. Si j'ai bien compris, dans cette solution, il faut que les tables en dessous aient la même clef que la table composant. Or je suis pas sûr que cela soit pertinent de dire que emplacement par exemple ait pour clef no_composant.

  10. #10
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    Par défaut
    Donc un code_geo n'est pas associé directement à un afficheur ?!

    Faites un tour sur le forum de modélisation et posez clairement votre problématique ... http://www.developpez.net/forums/f62...sation/schema/

  11. #11
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par punkoff Voir le message
    Donc un code_geo n'est pas associé directement à un afficheur ?!
    Non pas toujours.... Certain codes géo n'ont pas d'afficheur, d'autre un afficheur et certains codes géo partagent le même afficheur. En revanche, un code géo ne peut pas avoir deux afficheurs.

    Citation Envoyé par punkoff Voir le message
    Faites un tour sur le forum de modélisation et posez clairement votre problématique ... http://www.developpez.net/forums/f62...sation/schema/
    Merci

  12. #12
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 140
    Points : 89
    Points
    89
    Par défaut
    Citation Envoyé par Batou69 Voir le message
    Je penche donc, comme vous me l'avez indiqué, pour une table supplémentaire d'association.
    Attention, si le OU est exclusif, il faudrait laisser la colonne LinkTable dans Afficheur,
    (pour ne pas qu'un même afficheur puisse être relié à un code déo et à un emplacement, par exemple)
    la table d'association Affichage ne contenant plus que les colonnes FKafficheur et LinkPK.

    C'est une solution non relationnelle,
    aucune integrité ne peut vérifier l'existence de LienPK dans la table visée par LinkTable (a moins de le faire par Trigger)
    ...mais c'est générique, facile (...et moche )

    Sinon, la solution suggérée par punkoff est tout a fait envisageable, c'est dans ce cas la table Composant qui contiendrai la colonne LinkTable.
    C'est plus propre et tout aussi générique, mais il faut prendre en charge cette table Composant lors des Insert et Delete sur les tables CodeGéo, ensemble etc...
    Même si la clef no_composant n'a pas de sens sémantiquement, tu y gagnes tellement en fiabilité que ça en vaut la peine, il me semble.

    En bref, tu peux choisir d'être fainéant ou perfectionniste, mais pas puriste !

  13. #13
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par azur668 Voir le message
    Attention, si le OU est exclusif, il faudrait laisser la colonne LinkTable dans Afficheur,
    Non le OU n'est pas exclusif car physiquement un afficheur peut être sur deux code geo en même temps (un afficheur est alors partagé entre deux codes géo)

    Citation Envoyé par azur668 Voir le message
    (pour ne pas qu'un même afficheur puisse être relié à un code déo et à un emplacement, par exemple)
    Celle là on me l'avait jamais faite, elle est bien bonne !!

    Citation Envoyé par azur668 Voir le message
    Sinon, la solution suggérée par punkoff est tout a fait envisageable, c'est dans ce cas la table Composant qui contiendrai la colonne LinkTable.
    C'est plus propre et tout aussi générique, mais il faut prendre en charge cette table Composant lors des Insert et Delete sur les tables CodeGéo, ensemble etc...
    Même si la clef no_composant n'a pas de sens sémantiquement, tu y gagnes tellement en fiabilité que ça en vaut la peine, il me semble.

    En bref, tu peux choisir d'être fainéant ou perfectionniste, mais pas puriste !
    Bon, moi qui pensait aussi avoir la crémière...

    Je suis plutôt du genre à être perfectionniste, même au détriment de la fainéantise !

    Donc si j'ai bien compris, cela devrait donner un truc de ce genre : ?


    A noter que je commence a entrevoir d'autres modifications dans mon modèle.

    J'ai ajouté l'entité sortie et groupe sortie. Pourquoi j'ai ajouté cela ?

    Parce que dans mon modèle, j'ai plein d'entités qui peuvent être regroupées de cette façon : code géo, sortie, emplacement pour ne citer qu'elles. Je me demande s'il n'est pas plus judicieux de faire la gestion d'arbre dans l'entité composant, comme cela j'aurais à la fois l'association avec les afficheurs et la gestion des groupes.
    Dans ce cas, comment ne pas grouper des entités de nature différentes entre elles. Par trigger ?

    Merci pour vos explications

  14. #14
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    Par défaut
    En fait la table ensemble sert a faire un regroupement de code geo multi niveau. C'est à dire qu'il est possible faire des groupes de code géo, qui eux même sont dans des groupe de groupes etc... Comme je ne connais pas le nombre de niveaux, je fait une représentation d'arbre intervallaire (voir l'article). Le truc c'est qu'a chaque ensemble, il est possible d'associer un afficheur...
    Ce que je comprend de ceci c'est qu'un ensemble est en fait un code_geo père c'est bien ça ?

    Donc ce n'est pas l'ensemble qui est associé à un afficheur mais bien ce code_geo père ?

    Ensuite vous travaillez avec SqlServeur, selon la version, celui-ci dispose de requête recurssive qui permettent de recréer une arboressance avec des niveau.

    Ceci avec une simple modélisation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Code_geo-0,n------réfère
            |                      |
           0,1---------------
    On peut rendre le process un peu plus compliqué en transformant la relation "réfère" en entité.

    Cf. cette discussion sur des messages (lire la 1ere page) : http://www.developpez.net/forums/d11...-commentaires/

  15. #15
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    140
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 140
    Points : 89
    Points
    89
    Par défaut
    Citation Envoyé par Batou69 Voir le message
    Le ou est exclusif, oui.
    Citation Envoyé par Batou69 Voir le message
    Non le OU n'est pas exclusif car physiquement un afficheur peut être sur deux code geo en même temps (un afficheur est alors partagé entre deux codes géo)
    Etre OU ne pas être exclusif, telle est la question...
    Peut-être les deux en même temps ?
    mais alors y a plus de question

  16. #16
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 934
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 934
    Points : 4 347
    Points
    4 347
    Par défaut
    Citation Envoyé par Batou69 Voir le message
    L'ajout de la clef NO_AFFICHEUR dans chacune des tables ne me parait pas propre et surtout pas du tout évolutif. Si je souhaite lier un afficheur à une table autre de mon MCD (il est beaucoup plus vaste), alors je serai obligé de modifier ma base...

    Y a t il une solution élégante de faire cela ???
    Merci !
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    Afficheur
        no_afficheur (PK)
    
    Composant 
        no_composant (PK)
    
    Emplacement isa Composant
        no_composant (PK,FK)
    
    CodeGeo isa Composant
        no_composant (PK,FK)
    
    Sortie isa Composant
        no_composant (PK,FK)
    
    AfficheurComposant (table intersection comme si c'était pour un many to many)
        ref_afficheur (FK)
        ref_composant (FK)
        (option: un champ "type" pour simplifier l'implémentation de la Business Rule "tous les composants liés à l'afficheur doivent être de même type", 
    dans ce cas vous pourriez avoir comme PK de Afficheur [no_afficheur; type] et [ref_afficheur;type] comme FK dans AfficheurComposant)
    On peut simplifier en constatant que :
    un "afficheur à emplacement" est en fait un "afficheur à ensemble" dont le #(emplacement) == 1
    idem pour "afficheur à sortie" : "afficheur à groupe de sortie" dont le #(sortie) == 1

    Il faut que toutes les tables qui sont susceptibles de "fournir des composants" à l'afficheur partagent la PK de la table Composant dès le début, sinon c'est le choix du type de PK qui déterminera si le refactoring futur sera aisé ou non.

    La complexité apparente de la situation provient du fait que vous êtes confronté à deux formes de taxonomie :
    une "object oriented" autour de Composant : vous avez une hiérarchie de classes définies déterminant le contenu des objets (le Composant est un CodeGeo implique qu'il contienne des champs bien déterminés…)
    une "ontologique" au niveau de Afficheur : la classe est déterminée par le contenu, c'est parce que l'Afficheur contient des composants d'un certain type (et en certaine quantité) qu'il est considéré d'une certaine classe.
    (Rien n'empêche d'ailleurs que l'Afficheur soit polymorphe si vous changez d'avis à ce niveau-là…)

  17. #17
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par punkoff Voir le message
    Ce que je comprend de ceci c'est qu'un ensemble est en fait un code_geo père c'est bien ça ?

    Donc ce n'est pas l'ensemble qui est associé à un afficheur mais bien ce code_geo père ?
    Oui c'est bien cela mais un ensemble n'est pas un code géo lui même. Donc la dénomination de code geo pere me parait prêter à confusion. Mais le résultat est le même.

    Citation Envoyé par punkoff Voir le message
    Ensuite vous travaillez avec SqlServeur, selon la version, celui-ci dispose de requête recurssive qui permettent de recréer une arboressance avec des niveau.

    Ceci avec une simple modélisation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Code_geo-0,n------réfère
            |                      |
           0,1---------------
    On peut rendre le process un peu plus compliqué en transformant la relation "réfère" en entité.

    Cf. cette discussion sur des messages (lire la 1ere page) : http://www.developpez.net/forums/d11...-commentaires/
    Je suis en effet sous SQL Serveur 2008. Je vous remercie pour le lien.

  18. #18
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par azur668 Voir le message
    Etre OU ne pas être exclusif, telle est la question...
    Peut-être les deux en même temps ?
    mais alors y a plus de question
    Je suis sincèrement désolé . J'ai déjà du mal à expliquer mon problème, alors en plus si je donne des indications contradictoires, je comprend que cela ne va vous aider à cerner le problème.

    En réponse a ta question sous-entendue, la bonne indication est que l'afficheur peut etre partagé entre deux code géo.

    Donc le ou n'est pas exclusif.

    Encore désolé pour la confusion.

  19. #19
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Octobre 2009
    Messages
    118
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 118
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par JeitEmgie Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    Afficheur
        no_afficheur (PK)
    
    Composant 
        no_composant (PK)
    
    Emplacement isa Composant
        no_composant (PK,FK)
    
    CodeGeo isa Composant
        no_composant (PK,FK)
    
    Sortie isa Composant
        no_composant (PK,FK)
    
    AfficheurComposant (table intersection comme si c'était pour un many to many)
        ref_afficheur (FK)
        ref_composant (FK)
        (option: un champ "type" pour simplifier l'implémentation de la Business Rule "tous les composants liés à l'afficheur doivent être de même type", 
    dans ce cas vous pourriez avoir comme PK de Afficheur [no_afficheur; type] et [ref_afficheur;type] comme FK dans AfficheurComposant)
    Ok je commence à comprendre l'histoire d'héritage.
    Ce qui est compliqué pour moi c'est que j'ai érigé en dogme la règle de certains ici qui est de mettre un clef technique entière dans chaque table du modèle (la plupart du temps en auto incrément). Je connais les longs débats sur le sujet, et ce n'est pas le propos ici.
    Je me considère comme un débutant et je garde l'esprit ouvert sur le sujet.

    La solution proposée me semble aller à l'encontre de mon dogme (bêtement arbitraire).

    Citation Envoyé par JeitEmgie Voir le message
    On peut simplifier en constatant que :
    un "afficheur à emplacement" est en fait un "afficheur à ensemble" dont le #(emplacement) == 1
    idem pour "afficheur à sortie" : "afficheur à groupe de sortie" dont le #(sortie) == 1
    Là je ne vous suis plus.

    Citation Envoyé par JeitEmgie Voir le message
    Il faut que toutes les tables qui sont susceptibles de "fournir des composants" à l'afficheur partagent la PK de la table Composant dès le début, sinon c'est le choix du type de PK qui déterminera si le refactoring futur sera aisé ou non.

    La complexité apparente de la situation provient du fait que vous êtes confronté à deux formes de taxonomie :
    une "object oriented" autour de Composant : vous avez une hiérarchie de classes définies déterminant le contenu des objets (le Composant est un CodeGeo implique qu'il contienne des champs bien déterminés…)
    une "ontologique" au niveau de Afficheur : la classe est déterminée par le contenu, c'est parce que l'Afficheur contient des composants d'un certain type (et en certaine quantité) qu'il est considéré d'une certaine classe.
    (Rien n'empêche d'ailleurs que l'Afficheur soit polymorphe si vous changez d'avis à ce niveau-là…)
    Et là je suis complètement perdu. En tant que développeur C++, je comprend toutes les notions d'héritage, polymorphisme et autre. Mais je ne vois pas ce que cela vient faire dans la conception de la base.
    La plupart de ces notions sont propres à un langage objet je ne sais pas les représenter dans une base de données relationnelle.

  20. #20
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Je ne comprends rien à ces histoires d'afficheur partageant des codes géo.

    Pourriez-vous expliquer concrêtement ce que vous essayez de modéliser ?
    Lisez la phrase en bleu de ma signature et appliquez son principe !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

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

Discussions similaires

  1. Réponses: 0
    Dernier message: 06/11/2014, 17h59
  2. Conseils pour choix de modélisation d'une carte
    Par pmithrandir dans le forum Schéma
    Réponses: 8
    Dernier message: 26/07/2012, 17h50
  3. Utilité de modéliser son système (jointures)
    Par gorjette dans le forum Modélisation
    Réponses: 7
    Dernier message: 22/09/2010, 03h54
  4. [MCD]Modéliser une carte géographique
    Par hammoutiGI dans le forum Schéma
    Réponses: 1
    Dernier message: 18/11/2007, 18h14
  5. Réponses: 6
    Dernier message: 09/04/2007, 17h52

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