Discussion :

[Miko95]

Bonsoir,

J'ai défini les règles de partage d'information.
Mais avant ça, j'aimerais préciser quelque chose. Selon le schéma, une organisation peut déclarer gérer un élément associable. Aussi, une organisation peut associer deux éléments associables. Je veux préciser qu'ici les éléments associables peuvent jouer deux rôles: le rôle de clés et celui de résultats. Je m'explique. Dans cet exemple, j'ai défini seulement deux exemples d’éléments associables: des identifiants téléphoniques (ou groupes d'identifiants téléphoniques) et des routes (ou groupes de routes). Quand l'identifiant téléphonique joue le rôle de clé, c'est qu'une organisation cherche a connaître les routes associées a un identifiant téléphonique. Quand la route joue le rôle de clé, c'est qu'une organisation cherche a connaître les identifiants téléphoniques associes a une route. Donc, il semblerait ici que l'information importante (qui a une valeur) est l'association entre éléments associables. Je réfléchis donc a supprimer l'association entre Organisation et ElementAssociable, mais je ne suis pas sur (pour l'instant je l'ai supprime du schéma).

Je joins a ce post le nouveau schéma utilise pour la suite du design.

Maintenant, les règles de partages.

Prérequis:

• L'information importante, qui est donc apte a être partagée, est l'association entre deux éléments associables.
• On distingue deux types d'organisations:celles qui possèdent des associations entre éléments associables et qui les partagent, celles qui ont accès a ces associations. Autrement dit, on peut très bien avoir des organisations qui ne possèdent pas d'associations et qui existent dans le système pour avoir accès aux associations d'autres organisations.
• Deux éléments associables peuvent être associes par une organisation.
• Un groupe d'organisation est compose de zéro ou plusieurs organisations. Les organisations qui composent le groupe peuvent être des organisations "partageuses" ou/et des organisations "profiteuses".
• Une organisation peut appartenir a zéro ou plusieurs groupes d'organisations.

Règles de partage:

• Une organisation peut partager certaines de ses associations a une autre organisation. Dans ce cas, une organisation jour le rôle de "partageuse" tandis que l'autre organisation joue le rôle de "profiteuse".
• Une organisation appartenant a un groupe d'organisations, peut partager certaines de ses associations a tous les autres organisations membres de ce groupe.

J'ai pris un peu de temps pour voir si les règles sont cohérentes, mais je pense que oui. J'essaye de voir comment représenter ces règles en modifiant le dernier schéma (présent dans ce post).

Merci de ton aide Richard_35

[Richard_35]

Bonjour Miko95,

Dommage d'avoir supprimé l'avant dernier schéma : cela permet de voir la progression.

Sur la forme, une suggestion :

• entre GroupeOrganisation et Organisation, remplacer "appartient à" par "composer" ;
• (un détail) inverser ElementSimple => GroupeElement : GroupeElement => ElementSimple ;
• entre GroupeElement et ElementSimple, remplacer "appartient à" par "composer".

Selon le schéma, une organisation peut déclarer gérer un élément associable.

==> non : la relation "Organisation" => association "Associer" est incomplète (dans un seul sens) et fausse, semble-t-il. Telle quelle, elle veut dire :
1 "Organisation" contient 0 ou n association "Associer".
Donc, 1 organisation contient 0 ou n groupe d'ElementAssociable, donc au moins 2 ElementAssociable.

Premières remarques à étudier avant de passer à la suite.

[Miko95]

Bonjour,

Pour les suggestions, je ferai les changements ce soir, je ne suis pas devant le logiciel. D'ailleurs c'est une évaluation qui se termine demain ou après demain, il va falloir que je trouve un autre moyen.

Concernant ta remarque, je me rends compte que j'ai dis complètement autre chose. Je voulais dire que selon le schéma, une organisation peut associer deux éléments associables, et bien sur le faire plusieurs fois. Le cas ou une organisation n'a aucune association est valable, surtout pour les organisations "profiteuses". Par exemple, une organisation peut associer un identifiant téléphonique a une route.

Merci

[Richard_35]

OK, mais la relation "Organisation" => association "Associer" reste incomplète car dans un seul sens. Ton schéma :

Organisation ---0,n---> association Associer (de un ou plusieurs ElementAssociable)

Cela devrait être :

Organisation ---0,n---[contenir]---0,n--- association Associer

OK ?

[Miko95]

Je ne comprends pas pourquoi la relation est incomplète. En définissant cette association ternaire, je donne la possibilité a une organisation d'avoir plusieurs associations entre deux éléments associables (ou aucune pour la cardinalité 0). Je ne vois pas pourquoi je devrais ajouter une nouvelle association "contenir" entre Organisation et l'association ternaire "associer". Ça s'exprime déjà dans le lien entre Organisation et "associer". Je manque quelque chose?

De plus, je ne savais pas qu'on pouvait lier deux associations entre elles. Ce n'est pas le but d'une association N-aire de fournir cette possibilité?

[Richard_35]

Je ne comprends pas pourquoi la relation est incomplète. En définissant cette association ternaire, je donne la possibilité a une organisation d'avoir plusieurs associations entre deux éléments associables (ou aucune pour la cardinalité 0). Je ne vois pas pourquoi je devrais ajouter une nouvelle association "contenir" entre Organisation et l'association ternaire "associer".

==> eh bien, dans ton schéma, tu obtiendras les tables suivantes :

Organisation(IdOrganisation, ...) ;
Associer(#IdElementAssociable_1, #IdElementAssociable_2, ...) ;
OrganisationAssocier(#IdOrganisation, #IdElementAssociable_1, #IdElementAssociable_2, ...) ==> pour éviter le bonhomme NULL.

qui, de fait, représente la relation :

Organisation ---0,n---[contenir]---0,n--- association Associer

De plus, je ne savais pas qu'on pouvait lier deux associations entre elles.

==> Merise ne semble pas l'autoriser, en effet. En final, l'association en question devra, sans doute, être transformée en entité (si tu es d'accord avec le raisonnement précédent, bien entendu).

Maintenant, CinePhil ou Fsmrel pourraient nous apporter leur lumière quant à la pure théorie.

[Miko95]

Ce que tu veux dire, c'est que je peux représenter mon association ternaire par deux associations binaires? Si oui, je suis d'accord, j'ai seulement utilise l'association ternaire parce que si c'est la, autant l'utiliser (malgré le fait que ça peut complexifier le schéma).

Donc, j'aurais:

Organisation--0,n--[contenir]--1,1--AssociationElement
AssociationElement--1,1--[associe 1]--0,n--ElementAssociable
AssociationElement--1,1--[associe 2]--0,n--ElementAssociable

C'est bien ça?

[Richard_35]

Oui, mais il me semblait que tu souhaitais :

Organisation --0,n--[contenir]--1,n-- AssociationElement

==> si oui, "contenir" deviendra une table à part entière.

D'autre part, ta représentation :

AssociationElement --1,1--[associe 1]--0,n-- ElementAssociable
AssociationElement --1,1--[associe 2]--0,n-- ElementAssociable

ne me semble pas "juste". Celle-ci est davantage dans les normes, me semble-t-il :

AssociationElement--2,2--[composer]--0,n--ElementAssociable

où "composer" devient, également, une table.

Vite fait... je dois m'absenter.
A tout à l'heure.

[Miko95]

Oui, mais il me semblait que tu souhaitais :

Organisation --0,n--[contenir]--1,n-- AssociationElement

==> si oui, "contenir" deviendra une table à part entière.

Je pense que la, c'est plus une question de définir est-ce qu'une entité AssociationElement peut être contenu par plusieurs organisations. A ce niveau la, je pense qu'il y a deux possibilités. Soit un AssociationElement existe seulement dans le contexte d'une organisation, et dans ce cas, tout AssociationElement est contenu par exactement une seule Organisation. Si une autre Organisation voudrait contenir la même association, elle créerait une autre instance de cet AssociationElement (cas de la cardinalité [contenir]--1,1-- AssociationElement). Une autre approche est de définir qu'un AssociationElement soit unique. C'est a dire, par exemple, qu'une association entre un certain identifiant téléphonique et une certaine route ne peut pas exister deux fois. Elle existerait donc une seule fois, et bien sur plusieurs organisations pourraient la contenir (cas de la cardinalité [contenir]--1,n-- AssociationElement).

D'autre part, ta représentation :

AssociationElement --1,1--[associe 1]--0,n-- ElementAssociable
AssociationElement --1,1--[associe 2]--0,n-- ElementAssociable

ne me semble pas "juste". Celle-ci est davantage dans les normes, me semble-t-il :

AssociationElement--2,2--[composer]--0,n--ElementAssociable

où "composer" devient, également, une table.

J'ai l'impression que les deux représentations sont équivalentes. Je pense juste que selon ta proposition, je dois utiliser un trigger pour limiter le nombre d'instances de l'association [composer] a 2. Si je n'avais pas utiliser l'abstraction ElementAssociable et que j'avais RouteElement et IdentElement, et que j'aurais voulu définir le fait qu'une organisation peut contenir 0 ou plusieurs associations entre un RouteElement et un IdentElement, j'aurais définis la même association ternaire présente dans le schéma. Pourquoi le même principe ne s'appliquerait pas ici? La seule différence c'est qu'on associe deux entités du même type.

[Richard_35]

Je pense que la, c'est plus une question de définir est-ce qu'une entité AssociationElement peut être contenu par plusieurs organisations. A ce niveau la, je pense qu'il y a deux possibilités. Soit un AssociationElement existe seulement dans le contexte d'une organisation, et dans ce cas, tout AssociationElement est contenu par exactement une seule Organisation. Si une autre Organisation voudrait contenir la même association, elle créerait une autre instance de cet AssociationElement (cas de la cardinalité [contenir]--1,1-- AssociationElement). Une autre approche est de définir qu'un AssociationElement soit unique. C'est a dire, par exemple, qu'une association entre un certain identifiant téléphonique et une certaine route ne peut pas exister deux fois. Elle existerait donc une seule fois, et bien sur plusieurs organisations pourraient la contenir (cas de la cardinalité [contenir]--1,n-- AssociationElement).

==> OK : c'est toi qui maîtrises tes règles de gestion.

J'ai l'impression que les deux représentations sont équivalentes.

==> non. Ta représentation modélise des tables entre elles (comme le ferait Access).

Je pense juste que selon ta proposition, je dois utiliser un trigger pour limiter le nombre d'instances de l'association [composer] a 2.

==> si c'est la règle de gestion, alors tu n'y coupes pas (au trigger).

[Miko95]

==> OK : c'est toi qui maîtrises tes règles de gestion.

J'ai pas vraiment de réponse a ça. Je ne sais pas si c'est lie aux règles de gestions. Dans mes règles de gestion, je définis qu'une organisation peut contenir 0 ou plusieurs associations entre deux éléments associables. Maintenant, concernant les deux possibilités, j'ai l'impression que ça ressemble beaucoup aux concepts de Entities Objects et Value Objects introduits par le Domain Driven Design, mais je ne suis pas sur, j'ai de gros trous en modélisation.

[Richard_35]

Bonjour Miko95,

J'ai pas vraiment de réponse a ça. Je ne sais pas si c'est lie aux règles de gestions. Dans mes règles de gestion, je définis qu'une organisation peut contenir 0 ou plusieurs associations entre deux éléments associables.

==> eh bien, si, c'est une règle de gestion... sauf qu'elle est incomplète.

je définis qu'une organisation peut contenir 0 ou plusieurs associations entre deux éléments associables.

==> OK, mais, dans l'autre sens, 1 association entre deux éléments associables peut-elle appartenir :
- à 1 ou n organisation ;
OU
- à 1 et 1 seule organisation.
Il me semblait avoir compris que c'était la première possibilité que tu souhaitais, mais j'ai du mal comprendre puisque la règle de gestion est la seconde possibilité.
En résumé, j'avais compris :

Organisation --0,n--[contenir]--1,n-- AssociationElement

alors que c'est :

Organisation --0,n--[contenir]--1,1-- AssociationElement

Soit.


Maintenant, ne connaissant pas "le fond" de l'application, il m'est impossible de déterminer si telle ou telle règle de gestion est judicieuse. Je suis resté dans le "pur conceptuel" en te suggérant, notamment, d'utiliser l'héritage pour créer des niveaux conceptuels "supérieurs" et pouvoir faire pointer des entités sur deux éléments via "un distributeur d'identifiant". Ce qui semblait être, en fait, une des bases de tes soucis.