Publicité
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 34
  1. #1
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 415
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 415
    Points : 27 569
    Points
    27 569

    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
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 415
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 415
    Points : 27 569
    Points
    27 569

    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
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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 du Club
    Inscrit en
    juin 2007
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 137
    Points : 56
    Points
    56

    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
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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é Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 037
    Points : 4 613
    Points
    4 613

    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 :
    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
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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é Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 037
    Points : 4 613
    Points
    4 613

    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
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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 du Club
    Inscrit en
    juin 2007
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 137
    Points : 56
    Points
    56

    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
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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é Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 037
    Points : 4 613
    Points
    4 613

    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 :
    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 du Club
    Inscrit en
    juin 2007
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 137
    Points : 56
    Points
    56

    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 390
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : septembre 2006
    Messages : 2 390
    Points : 2 807
    Points
    2 807

    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 :
    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
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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 :
    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
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    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
    Candidat au titre de Membre du Club
    Homme Profil pro Gratien
    Inscrit en
    octobre 2009
    Messages
    93
    Détails du profil
    Informations personnelles :
    Nom : Homme Gratien

    Informations forums :
    Inscription : octobre 2009
    Messages : 93
    Points : 12
    Points
    12

    Par défaut

    Citation Envoyé par JeitEmgie Voir le message
    Code :
    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 Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 817
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    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 : 13 817
    Points : 23 075
    Points
    23 075

    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 de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « 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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •