Modélisation : Jointure à la carte [Résolu]

[Batou69]

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 !

[SQLpro]

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 +

[Batou69]

Envoyé par SQLpro

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 ?

[SQLpro]

C'est votre afficheur ensemble qui est la racine des afficheurs spécialisés

A +

[Batou69]

Envoyé par SQLpro

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.

[azur668]

Envoyé par Batou69

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...

[Batou69]

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

[punkoff]

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.

[Batou69]

Envoyé par punkoff

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.

Envoyé par punkoff

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.

[punkoff]

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/

[Batou69]

Envoyé par punkoff

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.

Envoyé par punkoff

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

Merci

[azur668]

Envoyé par Batou69

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 !

[Batou69]

Envoyé par azur668

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)

Envoyé par azur668

(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 !!

Envoyé par azur668

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

[punkoff]

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/

[azur668]

Envoyé par Batou69

Le ou est exclusif, oui.

Envoyé par Batou69

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

[JeitEmgie]

Envoyé par Batou69

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à…)

[Batou69]

Envoyé par punkoff

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.

Envoyé par punkoff

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 :

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.

[Batou69]

Envoyé par azur668

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.

[Batou69]

Envoyé par JeitEmgie

Code :

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).

Envoyé par JeitEmgie

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.

Envoyé par JeitEmgie

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.

[CinePhil]

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 !