Discussion :

[Miko95]

Bonsoir,

Je suis en train de concevoir le MCD pour un système de partage de données entre des organisations et j'ai des difficultés a modéliser certaines règles.
Le système gère un ensemble d'organisations. Chaque organisation peut gérer des données, fixons par exemple qu'une organisation peut gérer des numéros de téléphones et des noms.
Les organisations peuvent être classées dans trois catégories (définissant trois différents rôles):

1. celles qui partagent des données au profit d'autres organisations,
2. celles qui profitent des données d'autres organisations,
3. et celles qui jouent les deux rôles.

Les organisations qui profitent des données d'autres organisations ne contiennent généralement pas de données. Mais, ce n'est pas toujours le cas. Je peux imaginer une organisation qui contiendrait des données mais qui ne les partage pas pour l'instant.
Il y a plusieurs règles de partage entre les organisations.
Premièrement, j'aimerais pouvoir représenter qu'une organisation jouant le rôle 1 ou 3 autorise le partage de ses données a une autre organisation jouant le rôle 2 ou 3. C'est une relation directe entre ces deux organisations. Dans ce cas, les modalités du partage ne concernent que la relation entre ces deux organisations.
Deuxièmement, j'aimerais pouvoir regrouper des organisations de tout rôle et de définir les modalités de partage au niveau de ce groupe. Je m'explique. J'aimerais pouvoir définir un groupe dans lequel j'aurais par exemple 4 organisations: deux jouant le rôle 1, une jouant le rôle 2 et une jouant le rôle 3. Je veux aussi définir les modalités de partage au niveau du groupe, ce qui signifie que l'organisation jouant le rôle 1 pourra accéder aux données des trois autres organisations mais selon les modalités définies au niveau du groupe.
Troisièmement, j'aimerais pouvoir regrouper des organisations de la manière définie dans le paragraphe précédent, mais cette fois en définissant des modalités de partage propre à une certaine organisation lorsqu'elle se trouve dans ce groupe.
Quatrièmement, j'aimerais pouvoir regrouper des organisations de la manière définie dans le paragraphe précédent, mais cette fois en définissant des modalités de partage propre à une paire d'organisations lorsque celles-ci se trouvent dans un certain groupe. Il est a noter que cette possibilité diffère de la première car ici les modalités définies ne s'appliquent seulement lorsque les deux organisations se trouve dans ce groupe.

Voila comment je vois mon MCD:
Organisation----0,n---GERE----1,n----NumerosDeTelephone
Organisation----0,n---GERE----1,n----Nom
Organisation----0,n---PARTAGE----0,n----Organisation , les modalités de partage sont propres au type-association PARTAGE

Maintenant, je n'ai aucune idée comment représenter les autres cas (avec les groupes).
De plus, est-ce qu'il est nécessaire de séparer les organisations de différents rôles en plusieurs entités?

Merci d'avance de votre aide

[Richard_35]

Bonjour Miko95,

Un peu touffu...

Dans ton exposé, il y a un mélange de modélisation (entités), d'affectation d'attributs (flags divers) et de processus (traitements).

Intéressons nous à la modélisation. D'après ce que j'ai compris :

1 groupe est composé de 1 ou plusieurs organisations ;
1 organisation appartient à 0 ou 1 seul groupe.
==> est-ce OK ?

D'autre part, ton MCD définit que :

1 organisation possède 0 ou plusieurs N° de téléphone ;
1 N° de téléphone appartient à 1 ou plusieurs organisations.
==> 1 n° de téléphone n'appartient-il pas à 1 et 1 seule organisation ?

[Miko95]

1 groupe est composé de 1 ou plusieurs organisations ;
1 organisation appartient à 0 ou 1 seul groupe.
==> est-ce OK ?

Une organisation peut exister sans être obligatoirement associée a un groupe. Mais, une organisation peut aussi être membre de un ou plusieurs groupes. Et bien sur, un groupe est composé de 1 ou plusieurs organisations.

1 organisation possède 0 ou plusieurs N° de téléphone ;
1 N° de téléphone appartient à 1 ou plusieurs organisations.
==> 1 n° de téléphone n'appartient-il pas à 1 et 1 seule organisation ?

Oui, une organisation est associée à (un terme qui conviendrait mieux que POSSÈDE serait GÈRE, car ça ne signifie pas vraiment que le numéro de téléphone associé est celui de l'organisation) 0 ou plusieurs numéros de téléphone. Mais, un numéro de téléphone peut être GÉRÉ par 1 ou plusieurs organisations. Le changement de terme répond a la question, je pense, car maintenant on peut concevoir qu'un numéro de téléphone puisse être géré par plusieurs organisations.

Merci de ton aide

[Richard_35]

Donc, pour l'instant, nous avons :

Groupe ---0,n---[composer]---0,n--- Organisation ;
Organisation ---0,n---[gérer]---1,n--- N° téléphone.

Existe-t-il une relation entre "Nom" et "N° téléphone" ?
Autrement dit, veux-tu qu'une organisation gère un ensemble de noms et un ensemble de n° de téléphone indépendamment les uns des autres ?

[Miko95]

Bonjour,

Je pensais ajouter cette relation dans une prochaine étape mais on peut le voir maintenant. Juste avant, j'aimerais faire quelques modifications. Je préfère remplacer Numéro de téléphone par Identifiant, et Nom par Route. Je sais que ça rend le problème peut être plus abstrait mais c'est exactement ce que j'essaye de faire, de sorte a ne pas limiter le système a la gestion de numéros de téléphone et de noms seulement.
Donc pour résumer, on a :

Groupe ---0,n---[composer]---0,n--- Organisation ;
Organisation ---0,n---[gérer]---1,n--- Identifiant.
Organisation ---0,n---[gérer]---1,n--- Route.

Ok. Maintenant, j'aimerais pouvoir relier des identifiants aux routes pour une organisation. Mais, j'aimerais utiliser le concept de groupe ici aussi. Je m'explique. Pour une même organisation, j'aimerais pouvoir créer des groupes d'identifiants et des groupes de Routes. Et, pour l'association, j'aimerais qu'il y ait plusieurs possibilités:

• pouvoir relier un groupe d'identifiant a un groupe de routes
• pouvoir relier un groupe d'identifiant a une seule route
• pouvoir relier un identifiant a un groupe de routes
• pouvoir relier un identifiant a une route

J'ai donc pense a ça:
GroupeIdentifiant ---1,n---[composer]---0,1--- Identifiant;
GroupeRoute ---1,n---[composer]---0,n--- Route.
GroupeIdentifiant ---0,n---[associer]---0,n--- GroupeRoute;

Mais je ne sais si ça me permet de réaliser les deuxième et troisième possibilités. A moins que dans ces cas, je sois oblige de créer un groupe pour le seul identifiant ou la seule route. Peut être que laisser le schéma comme il est permet de rendre la solution plus simple.

Merci

[Richard_35]

Bonjour Miko95,

Il s'agit, en fait, de créer une "entité supérieure" à Identifiant/GroupeIdentifiant et à Route/GroupeRoute qui se comporterait comme un "fournisseur de clé primaire"...

Suggestion :

Route ---0,1---[Etre groupe]---1,1--- Route_Groupe ;
Route ---0,1---[Etre route]---1,1--- Route_Route.
==> trigger interdisant un Id_Route d'être présent dans Route_Groupe ET dans Route_Route.

donnant :

Route(Id_Route, ... {attributs communs aux groupes de routes et aux routes}) ;
Route_Groupe(#Id_Route, ... {attributs propres aux groupes de routes}) ;
Route_Route(#Id_Route, ... {attributs propres aux routes}).

Idem pour Identifiant :

Identifiant ---0,1---[Etre groupe]---1,1--- Identifiant_Groupe ;
Identifiant ---0,1---[Etre Identifiant]---1,1--- Identifiant_Identifiant.
==> trigger interdisant un Id_Identifiant d'être présent dans Identifiant_Groupe ET dans Identifiant_Identifiant.

donnant :

Identifiant(Id_Identifiant, ... {attributs communs aux groupes d'identifiants et aux identifiants}) ;
Identifiant_Groupe(#Id_Identifiant, ... {attributs propres aux groupes d'identifiants}) ;
Identifiant_Identifiant(#Id_Identifiant, ... {attributs propres aux identifiants}).

et, enfin :

Route ---0,n---[associer]---0,n--- Identifiant.

donnant :

Route_Identifiant(#Id_Route, #Id_Identifiant, ... {attributs propres aux associations route/identifiant}).
==> Id_Route et Id_Identifiant "pointant", indépendamment, sur un groupe de route/groupe d'identifiant ou sur une route/un identifiant.

[Miko95]

Suggestion :

Route ---0,1---[Etre groupe]---1,1--- Route_Groupe ;
Route ---0,1---[Etre route]---1,1--- Route_Route.
==> trigger interdisant un Id_Route d'être présent dans Route_Groupe ET dans Route_Route.

donnant :

Route(Id_Route, ... {attributs communs aux groupes de routes et aux routes}) ;
Route_Groupe(#Id_Route, ... {attributs propres aux groupes de routes}) ;
Route_Route(#Id_Route, ... {attributs propres aux routes}).

Je ne comprends pas les cardinalités pour Route-RouteGroupe. Une route peut être associe a 0 ou plusieurs groupes. De même, Un groupe de route peut être vide ou contenir plusieurs routes.
Je ne comprends pas que signifie l'association entre Route et Route_Route.

Idem pour Identifiant :

Identifiant ---0,1---[Etre groupe]---1,1--- Identifiant_Groupe ;
Identifiant ---0,1---[Etre Identifiant]---1,1--- Identifiant_Identifiant.
==> trigger interdisant un Id_Identifiant d'être présent dans Identifiant_Groupe ET dans Identifiant_Identifiant.

donnant :

Identifiant(Id_Identifiant, ... {attributs communs aux groupes d'identifiants et aux identifiants}) ;
Identifiant_Groupe(#Id_Identifiant, ... {attributs propres aux groupes d'identifiants}) ;
Identifiant_Identifiant(#Id_Identifiant, ... {attributs propres aux identifiants}).

Même question que précédemment.

et, enfin :

Route ---0,n---[associer]---0,n--- Identifiant.

donnant :

Route_Identifiant(#Id_Route, #Id_Identifiant, ... {attributs propres aux associations route/identifiant}).
==> Id_Route et Id_Identifiant "pointant", indépendamment, sur un groupe de route/groupe d'identifiant ou sur une route/un identifiant.

La je comprends qu'une Route peut être associée a 0 ou plusieurs identifiants et qu'un identifiant peut être associe a 0 ou plusieurs routes.


Finalement, je crois que tu essayes de m'expliquer un concept quand tu dis:

Il s'agit, en fait, de créer une "entité supérieure" à Identifiant/GroupeIdentifiant et à Route/GroupeRoute qui se comporterait comme un "fournisseur de clé primaire"...

mais je ne comprends pas trop.

[Richard_35]

Finalement, je crois que tu essayes de m'expliquer un concept quand tu dis:

Il s'agit, en fait, de créer une "entité supérieure" à Identifiant/GroupeIdentifiant et à Route/GroupeRoute qui se comporterait comme un "fournisseur de clé primaire"...

==> oui.

Je ne comprends pas les cardinalités pour Route-RouteGroupe.

==> eh bien, Route est "le fournisseur de clé primaire" à Route_Groupe (qui est l'entité "groupe de routes") et à Route_Route (qui est l'entité "routes solitaires") :

• un groupe de route existe, forcément, dans Route (id propre) ;
• une route existe, forcément, dans Route (autre id propre) ;
• un Id_Route est soit un groupe de route, soit une route.

==> ce qui permet de faire l'association

Route ---0,n---[associer]---0,n--- Identifiant

les identifiants de liaisons étant, soit un x_groupe, soit un x_solitaire.

La je comprends qu'une Route peut être associée a 0 ou plusieurs identifiants et qu'un identifiant peut être associe a 0 ou plusieurs routes.

==> non. Il faut comprendre que

une Route ou un groupe de routes peut être associée a 0 ou plusieurs identifiants ou groupe d'identifiants et qu'un identifiant ou un groupe d'identifiants peut être associe a 0 ou plusieurs routes ou groupe de routes.

C'est assez alambiqué, je l'admets... mais l'astuce étant la création "d'une entité supérieure" à un groupe et à un élément solitaire.

[Miko95]

==> eh bien, Route est "le fournisseur de clé primaire" à Route_Groupe (qui est l'entité "groupe de routes") et à Route_Route (qui est l'entité "routes solitaires") :

• un groupe de route existe, forcément, dans Route (id propre) ;
• une route existe, forcément, dans Route (autre id propre) ;
• un Id_Route est soit un groupe de route, soit une route.

==> ce qui permet de faire l'association

Route ---0,n---[associer]---0,n--- Identifiant

les identifiants de liaisons étant, soit un x_groupe, soit un x_solitaire.

Ok, maintenant je vois. Ça ressemble beaucoup au concept d’héritage. Mais peut être que c'est réalisé de cette manière en MCD?
Cependant, je ne comprends pas les cardinalités 0,1 dans:
Route ---0,1---[Etre groupe]---1,1--- Route_Groupe ;
Route ---0,1---[Etre route]---1,1--- Route_Route.

Une entité appartenant au type-entité Route peut-il être ni une route solitaire, ni un route groupe? Je ne pense pas?

Donc je comprends que ce principe "d’héritage" est applique pour les routes et pour les identifiants. Ensuite les types-entite Route (représentant des routes solitaires et des groupes de routes) et Identifiant (représentant des identifiants solitaires et des groupes d'identifiants) sont associes selon:
Route ---0,n---[associer]---0,n--- Identifiant

L’idée est géniale, ça ressemble au principe d'abstraction lorsqu'on utilise des interfaces que je connaissais d'ailleurs, mais je n'ai pas du tout pense a l'appliquer ici.

Merci

PS: je n'ai pas finis avec le schéma, je vais juste revoir ce concept pour vérifier que je n'ai rien manque et ensuite je dois revoir les règles pour définir le partage entre les organisations.

[Richard_35]

Ça ressemble beaucoup au concept d’héritage.

==> c'est de l'héritage.

Cependant, je ne comprends pas les cardinalités 0,1 dans:
Route ---0,1---[Etre groupe]---1,1--- Route_Groupe ;
Route ---0,1---[Etre route]---1,1--- Route_Route.
Une entité appartenant au type-entité Route peut-il être ni une route solitaire, ni un route groupe? Je ne pense pas?

==> tu penses correctement : il faut qu'un enregistrement de Route soit un groupe de route ou bien une route solitaire, obligatoirement un des deux et jamais les deux à la fois, d'où le trigger à prévoir.

Je n'ai pas d'outil de modélisation, mais cela pourrait se représenter par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Route ---1,1---[Etre groupe/route]---1,1--- Route_Groupe
                        |------------1,1--- Route_Route

[Miko95]

Donc, pour résumer:
IdentificationElement---1,1--[Etre identifiant]--1,1--Identifiant
IdentificationElement---1,1--[Etre groupe d'identifiant]--1,1--GroupeIdentifiant
RoutageElement---1,1--[Etre route]--1,1--Route
RoutageElement---1,1--[Etre groupe de routes]--1,1--GroupRoute
IdentificationElement--0,n--[associer]--0,n--RoutageElement
Organisation--0,n--[gerer]--1,n--IdentificationElement
Organisation--0,n--[gerer]--1,n--RoutageElement

Maintenant, c'est vrai que pour l'instant je pense a l'association entre des Identifiants/GroupeIdentifiant avec des Route/GroupeRoute. Imaginons que plus tard je veuille pouvoir supporter l'association entre des Identifiants/GroupeIdentifiant et des CoordonneesGPS/GroupeCoordonneesGPS par exemple. N'est-il pas nécessaire d'ajouter encore un niveau d'abstraction?

Par exemple:
ElementAbstrait--1,1-[Etre IdentificationElement]--1,1--IdentificationElement
ElementAbstrait--1,1--[Etre RoutageElement]--1,1--RoutageElement

Et donc finalement de créer une association réflexive sur ElementAbstrait?
ElementAbstrait--0,n--[associer]--0,n--ElementAbstrait
Et pour le lien avec l'organisation, on aurait:
Organisation--0,n--[gerer]--1,n--ElementAbstrait

[Richard_35]

Je dirais :

IdentificationElement---1 0,1--[Etre identifiant]-- 1,1--Identifiant
IdentificationElement---1 0,1--[Etre groupe d'identifiant]--1,1--GroupeIdentifiant
RoutageElement---1 0,1--[Etre route]--1,1--Route
RoutageElement---1 0,1--[Etre groupe de routes]--1,1--GroupRoute
IdentificationElement--0,n--[associer]--0,n--RoutageElement
Organisation--0,n--[gerer]--1,n--IdentificationElement
Organisation--0,n--[gerer]--1,n--RoutageElement

==> mais c'est un détail.

Maintenant, c'est vrai que pour l'instant je pense a l'association entre des Identifiants/GroupeIdentifiant avec des Route/GroupeRoute. Imaginons que plus tard je veuille pouvoir supporter l'association entre des Identifiants/GroupeIdentifiant et des CoordonneesGPS/GroupeCoordonneesGPS par exemple. N'est-il pas nécessaire d'ajouter encore un niveau d'abstraction?

==> tel que tu le décris, CoordonneesGPS/GroupeCoordonneesGPS semble au même niveau que Identifiant/GroupeIdentifiant et Route/GroupeRoute. Donc, idem :

GPS ---0,1---[Etre groupe de coordonnées GPS]---1,1--- GroupeCoordonneesGPS ;
GPS ---0,1---[Etre coordonnées GPS]---1,1--- CoordonneesGPS.
==> trigger interdisant un Id_GPS d'être présent dans GroupeCoordonneesGPS ET dans CoordonneesGPS, mais obligatoirement dans l'un des deux.

donc :

IdentificationElement ---0,n---[associer]---0,n--- GPS.

Si j'ai bien tout compris...

[Miko95]

En fait, pour l'instant, on peut juste associer des Identifiant/GroupeIdentifiant avec des Route/GroupeRoute (4 combinaisons possibles d'associations). Si maintenant je décide d'ajouter CoordoneesGPS/GroupeCoordonneesGPS, je suis oblige de définir 2 nouvelles associations: une de GPSElement a IdentifiantElement, et une de GPSElement a RoutageElement. J'ai donc pense a peut être définir, un type-entité a un niveau d'abstraction supérieur a IdentificationElement et RoutageElement.
Ce qui donnerait comme dans mon précédent message:

IdentificationElement---1,1--[Etre identifiant]--1,1--Identifiant
IdentificationElement---1,1--[Etre groupe d'identifiant]--1,1--GroupeIdentifiant
RoutageElement---1,1--[Etre route]--1,1--Route
RoutageElement---1,1--[Etre groupe de routes]--1,1--GroupeRoute

ElementAbstrait--1,1-[Etre IdentificationElement]--1,1--IdentificationElement
ElementAbstrait--1,1--[Etre RoutageElement]--1,1--RoutageElement

Si maintenant je décide d'ajouter GPSElement, j'ai juste a définir cela:

GPSElement --1,1--[Etre GroupeCoordonnéesGPS]--1,1--GroupeCoordonneesGPS
GPSElement ---1,1---[Etre coordonnées GPS]---1,1--- CoordonneesGPS.

et de lier GPSElement a ElementAbstrait comme ceci:

ElementAbstrait--1,1--[Etre GPSElement]--1,1--GPSElement

Est ce que ce modèle pose un problème?

[Richard_35]

OK : tu veux donc définir ElementAbstrait en "fournisseur d'identifiant" de IdentificationElement et RoutageElement, en parallèle.

Eh bien, non, je ne ne vois pas de problème. Je crains juste que tu t'y perdes un peu, à force de monter des niveaux supérieurs... mais bon.

La morale de l'histoire c'est que l'héritage sert (aussi) à obtenir des relations avec un seul et même identifiant pouvant pointer sur des entités différentes.

[Miko95]

OK : tu veux donc définir ElementAbstrait en "fournisseur d'identifiant" de IdentificationElement et RoutageElement, en parallèle.

Eh bien, non, je ne ne vois pas de problème. Je crains juste que tu t'y perdes un peu, à force de monter des niveaux supérieurs... mais bon.

La morale de l'histoire c'est que l'héritage sert (aussi) à obtenir des relations avec un seul et même identifiant pouvant pointer sur des entités différentes.

Je pense que ça va pour le niveau d'abstraction. Ça révèle bien le concept de vouloir créer des associations entre différents types d’éléments.

J'ai fais quelques changements de noms de certaines entités. Je joins a ce post le diagramme a ce stade.

Pour définir la relation d'appartenance entre ElementAassociable et Organisation, j'utilise l'association "gérer" qui apparaît dans le schéma. La règle est que tout ElementAssociable est géré par zero ou plusieurs organisation et qu'une organisation peut gérer 0 ou plusieurs ElementAssociable.

Maintenant, j'aimerais revenir aux règles de partage entre organisations.
Une organisation peut appartenir a 0 ou plusieurs groupes d'organisations.
Un groupe d'organisation peut contenir 0 ou plusieurs organisations.On a donc l'association qui apparaît dans le schéma.

Maintenant, j'aimerais pouvoir représenter les règles de partage suivantes:

Une organisation peut partager un ElementAssociable qu'il gère, a une autre organisation.
Une organisation peut partager un ElementAssociable qu'il gère, a un groupe d'organisations.

Il y a d'autres règles de partage mais je dois les revoir.

Merci

[Richard_35]

Je n'ai pas trop le temps de vérifier ton schéma.

Maintenant, j'aimerais pouvoir représenter les règles de partage suivantes:
Une organisation peut partager un ElementAssociable qu'il gère, a une autre organisation.
Une organisation peut partager un ElementAssociable qu'il gère, a un groupe d'organisations.

==> même combat !... une "entité supérieure fournisseur d'identifiant à une organisation et à un groupe d'organisations, en parallèle" . Pas très élégant, comme définition, mais bon.

[Miko95]

Bonsoir,

J'ai de nouvelles questions sur le modèle.

J'aimerais pouvoir représenter le fait qu'une organisation est propriétaire d'un identifiant téléphonique. Le problème est que le lien entre Organisation et Identifiant téléphonique est défini a un niveau abstrait. Si j'ajoute un attribut a l'association 'gérer' entre Organisation et ElementAssociable, ca me donne la possibilité de représenter le fait qu'une organisation puisse être propriétaire d'un ElementAssociable, comme une Route par exemple, ce qui n'a pas de sens réellement. Est ce que je suis oblige de modifier le modèle et de définir une association entre Organisation et IdentifiantTelephonique ou y a t-il une autre solution?

Merci

[Richard_35]

Bonsoir Miko95,

Je suis un peu perdu, dans tes demandes...

Le schéma présenté dans le post #15 ne semble pas être le dernier :

.../... une "entité supérieure fournisseur d'identifiant à une organisation et à un groupe d'organisations, en parallèle" .../...

n'est pas présent (à moins que tu n'ai changé d'avis).

Peux-tu poster ton dernier schéma ?

[Miko95]

Bonsoir,

Je joins a ce post le dernier schéma, la ou j'en suis quoi.

Je réécris les règles de gestions sensées être représentées dans ce schéma.

• Pouvoir représenter des identifiants téléphoniques et des routes.
• Un numéro de téléphone est un type d'identifiant téléphonique.
• Une adresse est un type de route.
• Pouvoir représenter des groupes d'identifiants téléphoniques.
• Pouvoir représenter des groupes de routes.
• Un groupe contient 1 ou plusieurs éléments simples.
• Un élément simple peut appartenir a 0 ou plusieurs groupes.
• Un groupe doit être compose d’éléments simples de même type (soit des identifiants téléphoniques, soit des routes, mais pas les deux). Besoin de trigger?
• Un élément simple ou un groupe peut être géré par une ou plusieurs organisation(s).
• Une organisation peut gérer 0 ou plusieurs élément simple/groupes.
• Une organisation peut associer deux éléments associables de types différents. Besoin de trigger?
  
  • un identifiant téléphonique avec une route
  • un groupe d'identifiants téléphoniques avec une route
  • un identifiant téléphonique avec un groupe de routes
  • un groupe d'identifiants téléphoniques avec un groupe de routes

Merci

[Richard_35]

Bonjour Miko95,

OK, pour ton schéma.

Je me demande si la boucle du haut ne posera pas de problème lors de la génération automatique des tables (le cas échéant) : à tester.

Oui, pour les deux triggers : il s'agit de règles spécifiques à programmer.