Discussion :

[DiverSIG]

Bonjour,

Je cherche à combiner une relation d'exclusion avec une relation réflexive, je m'explique :
J'ai des données, qui peuvent soit être fournies par un opérateur, soit être acquises au cours d'une expérience, soit être calculées à partir d'autre données.
Au niveau du MCD, j'ai une entité des données, une entité des expériences, une entité des opérateurs.

Il me faut donc une relation réflexive au niveau de l'entité données, mais il faut aussi une relation exclusive entre cette relation réflexive, la relation expérience-données, et la relation opérateur-données.

Comment combiner tout cela ?

Merci,

Nico

[fsmrel]

Par exemple, quelque chose comme cela :





Mais pour assurer la contrainte dans les faits, le gros du travail restera à faire au niveau SQL, à l'aide de triggers.

[DiverSIG]

j'ai bien essayé de faire quelque chose comme ça (cf. mcd.jpg), mais quand je demande à PowerAMC de vérifier le modèle, il sort une erreur :

Code :

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

1
2
3
4
5
6
Package	Circularité formée de liens obligatoires	
Lien d'association 'DONNEES - créer à partir de', 
Lien d'association 'DONNEE_CREEE - créer à partir de', 
Lien d'héritage 'DONNEES - Heritage_1 - DONNEE_CREEE', 
Héritage 'Heritage_1'

Est-ce qu'on ne peut pas supprimer l'héritage, pour avoir un modèle comme sur l'image mcd2.jpg, et gérer la provenance des données avec la variable DATA_STATUT qui vaudrait par exemple 1 si la donnée est fournie, 2 si elle vient d'expérience,3 si elle est créée. ?

un des problème que je vois est que comme on a des cardinalités 1,1 du côté de la table Données pour les relations fournir et acquérir, au niveau du modèle physique, les clés des tables Fournisseurs et Expériences vont migrer dans la table Données, et ça va faire des variables à moitié vides...
mais je sais pas si c'est vraiment un problème ? votre avis ?
je sais pas trop quelle solution est la plus facilement gérable par la suite quand la base est opérationnelle .

Nico

[fsmrel]

j'ai bien essayé de faire quelque chose comme ça (cf. mcd.jpg), mais quand je demande à PowerAMC de vérifier le modèle, il sort une erreur :

Code :

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

1
2
3
4
5
Package	Circularité formée de liens obligatoires	
Lien d'association 'DONNEES - créer à partir de', 
Lien d'association 'DONNEE_CREEE - créer à partir de', 
Lien d'héritage 'DONNEES - Heritage_1 - DONNEE_CREEE', 
Héritage 'Heritage_1'

Erreur ou warning ?

Pour ma part, j'ai droit à un message analogue, mais sous forme de warning. En l'occurrence, PowerAMC est trop regardant.
Supposons qu'au niveau opérationnel, je supprime une donnée D1, entrant dans la composition d'une donnée D2 : d'après mon MCD, la suppression de la ligne correspondante dans la table Donnee entraîne la suppression de D1 dans la table DonneDonnee, donc le lien avec D2, mais D2 elle-même n'est pas impactée.

Si D1 entre dans la composition de D3, un RESTRICT pour la clé étrangère connectant Donnee et DonneeDonnee bloquera la tentative de suppression de D3. Autrement dit, pour supprimer une donnée parente, il faudra d'abord supprimer ses enfants.

Le warning de Power AMC pourrait avoir un sens si par mégarde D1 était parente de D1 car, selon le scénario que j'utilise, D1 deviendrait indestructible.

Le MLD correspondant est le suivant :







Et la partie de code SQL correspondante (MS SQL Server) :

Code SQL :

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
Create Table Donnee (
   DonneeId             Int                  Not null,
   DonneeLibelle        Varchar(48)          Not null,
   Constraint Donnee_PK Primary Key  (DonneeId)
) ;
 
Create Table DonneeDonnee (
   DonneeId             Int                  Not null,
   Parent_DonneeId      Int                  Not null,
   DonneeLibelle        Varchar(48)          Not null,
   Constraint DonneeDonnee_PK Primary Key  (DonneeId),
   Constraint DonneeDonnee_Donnee_2 Foreign Key (DonneeId)
      References Donnee (DonneeId) on Delete Cascade,
   Constraint DonneeDonnee_Donnee_1 Foreign Key (Parent_DonneeId)
      References Donnee (DonneeId)
) ;

[fsmrel]

un des problème que je vois est que comme on a des cardinalités 1,1 du côté de la table Données pour les relations fournir et acquérir, au niveau du modèle physique, les clés des tables Fournisseurs et Expériences vont migrer dans la table Données, et ça va faire des variables à moitié vides...

Pas de mon côté.

Voici la génération SQL fournie par PowerAMC, à partir de mon "MPD" qui en réalité est un MLD :

Code SQL :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
Create Table Donnee (
   DonneeId             Int                  Not null,
   DonneeLibelle        Varchar(48)          Not null,
   Constraint Donnee_PK Primary Key  (DonneeId)
);
 
Create Table DonneeDonnee (
   DonneeId             Int                  Not null,
   Parent_DonneeId      Int                  Not null,
   Constraint DonneeDonnee_PK Primary Key  (DonneeId),
   Constraint DonneeDonnee_Donnee_1 Foreign Key (DonneeId)
      References Donnee (DonneeId)
         On Delete Cascade,   
   Constraint DonneeDonnee_Donnee_2 Foreign Key (Parent_DonneeId)
      References Donnee (DonneeId)
)
;
 
Create Table Experience (
   ExperienceId         Int                  Not null,
   ExperienceLibelle    Varchar(48)          Not null,
   Constraint Experience_PK Primary Key  (ExperienceId)
)
;
Create Table Operateur (
   OperateurId          Int                  Not null,
   OperateurLibelle     Varchar(48)          Not null,
   Constraint Operateur_PK Primary Key  (OperateurId)
)
;
 
Create Table DonneeExp (
   DonneeId             Int                  Not null,
   ExperienceId         Int                  Not null,
   Constraint DonneeExp_PK Primary Key  (DonneeId),
   Constraint DonneeExp_Experience_1 Foreign Key (ExperienceId)
      References Experience (ExperienceId),
   Constraint DonneeEXP_Donnee Foreign Key (DonneeId)
      References Donnee (DonneeId)
         On Delete Cascade
)
;
 
Create Table DonneeOper (
   DonneeId             Int                  Not null,
   OperateurId          Int                  Not null,
   Constraint DonneeOper_PK Primary Key  (DonneeId),
   Constraint DonneeOper_Operateur_1 Foreign Key (OperateurId)
      References Operateur (OperateurId),
   Constraint DonneeOper_Donnee_2 Foreign Key (DonneeId)
      References Donnee (DonneeId)
         On Delete Cascade
);

Mais au niveau MCD, fenêtre "Propriétés de l'héritage", j'ai coché "Générer les parents", "Générer les enfants", "N'hériter que des attributs primaires".

Au niveau MLD, dans la fenêtre "Propriété de la référence - Héritage_1", j'ai coché "Contrainte de suppression en cascade".




Concernant votre proposition de MCD :





La cardinalité 1,N portée par la patte reliant DONNEE_CREEE et "créer à partir de" signifie qu'une donnée peut entrer dans la composition de plusieurs données, c'est-à-dire avoir plusieurs mères, alors que dans ce que je vous propose, une donnée n'a qu'une seule mère, ne peut provenir que d'une autre donnée, tout comme une donnée ne peut provenir que d'une expérience ou d'un opérateur.

gérer la provenance des données avec la variable DATA_STATUT qui vaudrait par exemple 1 si la donnée est fournie, 2 si elle vient d'expérience,3 si elle est créée.

Cela est parfois pratiqué, mais introduit une redondance. Autant mettre en oeuvre un mécanisme de vues. Par exemple, concernant les données venant d'un opérateur :

Code SQL :

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

1
2
3
4
5
Create View DonneeOperateur (DonneeId, DonneeLibelle, Etc, OperateurId) As
Select x.DonneeId, x.DonneeLibelle, x.Etc, y.OperateurId
From   Donnee x Inner Join DonneeOper y
         On x.DonneeId = y.DonneeId
;