Discussion :

[ygrim]

Bonjour à tous,
J'ai un cas un peu spécial dans la modélisation d'une BD.
Est il "clean" de lier une relation avec une autre relation dans un MCD ? Je veux dire par cela, est ce que cela risque de poser des problèmes conceptuels ou de performance ?
Je donnes un exemple pour eclaircir tout ça.
Imaginons une entité Client liée à une entitée GroupeClient par la relation "appartenir"
L'entité GroupeClient est liée à l'entité Privileges par la relation "avoir privileges" (des privilèges sont afféctés à des groupes de clients).

Maintenant je veux créer la relation liant un client à un privilège, mais cette relation est dépendant du groupe client car c'est avec ce dernier que sont définis les privilèges. Dans tous les cas, il sera techniquement faisable de donner n'importe quel privilège à n'importe quel client..... Sauf si on lie notre relation avec la relation "avoir privilèges.
Est ce que cette bidouille m'apportera des problèmes que je ne vois pas ?

Désolé si l'explication est un peu fastidieuse, je me ferais un plaisir d'éclaircir tout ça au besoin.

Merci

[MadStar]

En effet j'ai du mal à comprendre pourquoi tu veux faire ça.
Est ce que tu pourrais expliquer où tu veux en venir ?

[fsmrel]

Puisqu’un client appartient à un seul groupe, il hérite a priori de tous les privilèges du groupe.
Si vous souhaitez restreindre ces privilèges pour certains clients, alors seulement dans ce cas vous pouvez mettre en relation l’entité-type Client et l’association-type Avoir_Privilèges. Pour éviter de traiter à la fois du besoin fonctionnel et des contraintes techniques merisiennes (mettre en relation une entité-type et une association-type), je pars du MLD (où j’ai renommé Avoir_Privilèges en Priv_Groupe).



Mais attention au piège : selon ce MLD, aucune contrainte n’interdit d’attribuer à un client des privilèges qui sont ceux d’un groupe qui n’est pas le sien : il faudra prévoir de mettre en œuvre la règle selon laquelle les privilèges attribués à un client doivent faire partie des privilèges du groupe auquel appartient le client. Selon la norme SQL, il faut prévoir la mise en œuvre d’une instruction CREATE ASSERTION. Si votre SGBD ne propose pas cette instruction, il faudra en passer par des triggers pour contrôler l’insertion des lignes dans la table Priv_Client et la modification des groupes dans cette même table.
Voici un exemple de trigger concernant l’insertion (MS SQL Server 2005). Quand la règle est respectée, la table Priv_Client est alimentée, sinon les délinquants sont envoyés dans une table des rebuts.

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Create trigger T1 ON Priv_Client Instead Of Insert As
  INSERT INTO Priv_Client 
     SELECT  *
     FROM    Inserted i
     Where   Exists (Select *
                     From   Client c
                     Where  i.GroupeId = c.GroupeId) ;
  Insert Into Priv_Client_Rebut
     Select * 
     From   Inserted i  
     Where  not exists (Select *
                        From   Client c
                        Where  i.GroupeId = c.GroupeId) ;

Je vous laisse le soin d’adapter ce trigger en fonction de votre SGBD et de coder le trigger de mise à jour.

[ygrim]

Mais attention au piège : selon ce MLD, aucune contrainte n’interdit d’attribuer à un client des privilèges qui sont ceux d’un groupe qui n’est pas le sien : il faudra prévoir de mettre en œuvre la règle selon laquelle les privilèges attribués à un client doivent faire partie des privilèges du groupe auquel appartient le client. Selon la norme SQL, il faut prévoir la mise en œuvre d’une instruction CREATE ASSERTION. Si votre SGBD ne propose pas cette instruction, il faudra en passer par des triggers pour contrôler l’insertion des lignes dans la table Priv_Client et la modification des groupes dans cette même table.

C'est la réponse que je voulais avoir ! Ce sont donc les assertions qui permettent d'integrer une telle règle d'affaire dans un modèle de données.

Merci beaucoup pour la limpidité de votre réponse !