Discussion :

[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]

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]

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]

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 :

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.

[Batou69]

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.

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/

[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 :

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/

[azur668]

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]

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)

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

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

[azur668]

Le ou est exclusif, oui.

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]

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

[Batou69]

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

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.

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 !

[Batou69]

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 !

J'ai véritablement failli la citer car c'est aussi une phrase que je garde souvent en mémoire. Mais son application n'est pas toujours aisée, même sur des sujets qui paraissent "simples"

Pour les afficheurs : Je modélise une installation de préparation de commandes avec ce que l'on appelle du "pick to light". Si vous ne connaissez pas, en gros on a une armoire avec des cases (les codes géo). Chaque case contient un seul article. Un afficheur est souvent constitué de quelque digits et d'un bouton. Les digits indiquent la quantité que l'opérateur doit prendre dans la case et le bouton sert de validation. Compte tenu du prix des afficheurs et du grand nombre de cases, il est possible de partager un afficheur entre deux cases. Dans ce cas, l'affichage ne peut pas être simultané bien sûr. Il est séquentiel : on indique à l'opérateur de prendre la quantité X dans la case du haut, puis la quantité Y dans la case du bas.

Alors pourquoi ce binz sur le reste ?
Parce qu'il est possible, en plus des afficheurs sur chaque case, de gérer un afficheur par groupe de cases. Cet afficheur sert pour d'autres informations.
Et pour couronner le tout, comme je modélise un logiciel qui s'adapte à tous les cas, je ne veut pas fixer le nombre de niveaux de groupe (je souhaite pouvoir faire des groupes de groupes et ainsi de suite). C'est ce que j'ai appelé ENSEMBLE dans mon modèle. Un ensemble peut aussi avoir un afficheur (mais dans ce cas un seul).

Enfin, une installation de préparation de commandes est vaste, et comporte des tas de systèmes différents présent dans mon modèle. Par exemple des sorties de trieur. Les sorties n'ont rien à voir avec les code géo, mais ont ceci en commun : elles peuvent avoir un afficheur et elles peuvent s’agréger en groupes (avec des niveaux aussi).

Voila, c'est certainement plus clair avec toutes ces explications...

[CinePhil]

OK. Essayons de modéliser progressivement., mais vous devriez lire mon billet sur les règles de gestion, ça aiderait beaucoup à la modélisation.

on a une armoire avec des cases (les codes géo). Chaque case contient un seul article.

Une case peut-elle être vide ?
Un article peut-il ne pas être contenu dans une case ?
En attendant, je modélise avec hypothèses ; il faudra éventuellement changer les cardinalités.

MCD 1 :
code_geo -1,1----contenir----1,n- article

Compte tenu du prix des afficheurs et du grand nombre de cases, il est possible de partager un afficheur entre deux cases.

Au plus deux cases ou bien un afficheur peut-il être partagé entre n>2 cases ?
Une case peut-elle avoir plusieurs afficheurs ? J'ai l'impression que non.

MCD 2 :
afficheur -1,n----partager----1,1- code_geo

Alors pourquoi ce binz sur le reste ?
Parce qu'il est possible, en plus des afficheurs sur chaque case, de gérer un afficheur par groupe de cases. Cet afficheur sert pour d'autres informations.

Les groupes de cases sont-il des ensembles définis ? Immuables ?
une case peut-elle être dans plusieurs groupes ?
Peut-on considérer qu'il existe des afficheurs de type "case" et des afficheurs de type "groupe" puisque les informations affichées sont différentes ?
Un afficheur de groupe peut-il être partagé entre plusieurs groupes ?

On pourrait alors avoir cette structure pour les groupes :
MCD 3 :
code_geo -0,1----constituer----1,n- groupe

Et un héritage pour les afficheurs.
MCD 4 :
aff_case -(1,1)----être----0,1- afficheur
aff_groupe -(1,1)----être----0,1---|



Du coup, on modifie le MCD 2 de la façon suivante :
MCD 2 bis :
aff_case -1,n----partager----1,1- code_geo

puis on associe aff_groupe à groupe :
MCD 5 :
aff_groupe -1,n----affecter----1,1- groupe

Et pour couronner le tout, comme je modélise un logiciel qui s'adapte à tous les cas, je ne veut pas fixer le nombre de niveaux de groupe (je souhaite pouvoir faire des groupes de groupes et ainsi de suite).

Donc une modélisation d'arbre intervallaire semble en effet judicieuse. Si un groupe ne peut-être inclu que dans un seul groupe de niveau immédiatement supérieur.

MCD 6 :
groupe -0,n--(père)--comprendre
|------------0,1--(fils)-----------|

Les sorties n'ont rien à voir avec les code géo, mais ont ceci en commun : elles peuvent avoir un afficheur

Peut-on considérer alors que nous avons un troisième type d'afficheur ?

MCD 4 bis :
aff_case -(1,1)----être----0,1- afficheur
aff_groupe -(1,1)----être----0,1---|
aff_sortie -(1,1)----être----0,1-----|

Plusieurs sorties peuvent-elles partager le même afficheur ?
MCD 7 :
sortie -0,1----avoir----1,n- aff_sortie

et elles peuvent s’agréger en groupes (avec des niveaux aussi).

Je suppose que les groupes pour les cases sont différents des groupes pour les sorties ? Un groupe X ne peut pas comprendre à la fois des cases et des sorties ?
Auquel cas il y aurait un nouvel arbre intervallaire et une spécialisation des groupes. En supposant que les deux types de groupes aient des propriétés communes, on fait un nouvel héritage :

MCD 8 :
groupe_case (1,1)----être----0,1- groupe
groupe_sortie -(1,1)----être----0,1---|

Ce qui nous amène à modifier le MCD 3, le MCD 5 et le MCD 6.
MCD 3 bis :
code_geo -0,1----constituer----1,n- groupe_case

MCD 5 bis :
aff_groupe -1,n----affecter----1,1- groupe_case

MCD 6 bis :
groupe_case -0,n--(père)--comprendre
|------------0,1--(fils)-------------------|

On modélise l'arborescence des groupes de sorties comme dans le MCD 6 bis.
MCD 9 :
groupe_sortie -0,n--(père)--comprendre
|------------0,1--(fils)-------------------|


Je crois que je suis arrivé au bout de vos explications.
J'ai dessiné le MCD complet à la main, ça me semble cohérent.

Vous pouvez faire de même avec un logiciel de modélisation et nous proposer le résultat.

[JeitEmgie]

Là je ne vous suis plus.

# signifie cardinal : regardez votre premier schéma
que votre afficheur soit lié à 1 seul emplacement ou à N peut être modéliser de la même manière, simplement si vous devez distinguer entre les 2 cas au point de les considérer comme 2 classes différentes, vous pouvez le faire via une business rule : il n'est pas nécessaire d'avoir 2 modèles différents (mais vous pouvez le faire si d'autres raisons y poussent).

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.

c'est vous qui demandez que la solution soit évolutive : si vous mettez des auto_increment dans toutes vos tables, vous ne pourrez pas refactorer pour qu'une table X devienne à son tour une sous-classe de Composant dans le futur : puisqu'il y a aura un conflit sur les PK, par contre une "table sequence" commune fonctionnera (ou des UUIDs).
Faire de la table X une sous-classe de Composant reviendra simplement à ajouter des records Composant pour chaque record de X et une FK de la PK de X vers Composant(no_composant) : soit 2 lignes de SQL.

Et que la base soit relationnelle n'empêche en aucune manière de modéliser des concepts objets ni de les représenter.