Discussion :

[vivicente]

Bonjour je travaille sur un projet de gestion de parc informatique,
J'aimerais effectué un historique pour chaque équipement :
Concernant les cardinalités entre les entités, je mettrai ça :
Equipement (1,1) -------HISTORISE (1,1)-----Historique





Un equipement a un et un seul historique ...et un historique appartient à un seul et un seul équipement .
je me trompe ?


Au niveau des tables, ça donne quoi les cardinalités (1,1) de chaque coté ?

[CinePhil]

Tes cardinalités supposent que tu ne conserves que le dernier historique et que tu supprimes les plus anciens.
Mais c'est conforme à ta règle de gestion :

Un equipement a un et un seul historique ...et un historique appartient à un seul et un seul équipement .

La règle de gestion est-elle juste ?

Au niveau des tables, ça donne quoi les cardinalités (1,1) de chaque coté ?

Il faut choisir la table qui va recevoir la clé étrangère.
Dans ton cas, ce sera probablement la table Historique.

D'ailleurs, je verrais plutôt, en supposant toujours que tu ne conserve qu'un seul historique par équipement, ces cardinalités là :
Equipement -0,1 -------HISTORISER----(1,1)- Historique

Un nouvel équipement n'a pas encore d'historique !

[JPhi33]

Bonjour vivicente,

Un equipement a un et un seul historique ...et un historique appartient à un seul et un seul équipement .
je me trompe ?

La règle de gestion est peut-être juste mais as-tu réellement réfléchi à la manière dont elle se modélise ?

Un équipement, c'est 1 occurrence de l'entité Equipement. Mais un historique d'équipement, est-ce 1 occurrence de l'entité Historique ou plusieurs occurrences ? Ne faudrait-il pas faire intervenir une date ou un horodatage dans le concept d'historique ?

J'ai mon idée sur ces questions mais je ne veux pas t'influencer.

Au niveau des tables, ça donne quoi les cardinalités (1,1) de chaque coté ?

Lorsque ce type d'association est pleinement justifié (souvent il s'agit d'erreurs de modélisation), il faut choisir le sens de la CIF. L'une des tables sera alors référencée par l'autre au moyen d'une clé étrangère.

Exemple théorique. Soient deux entité A et B :

[ A ]--1,1----( )----1,1--[ B ]

On choisit le sens de la CIF :

[ A ]--1,1----( )----1,1->[ B ]

Le MLD obtenu à partir de ce MCD est (clés primaires soulignées, clé étrangère suffixée par #) :

A (A, A1, A2, ..., An, B#)
B (B, B1, B2, ..., Bn)

Le contrôle que chaque ligne de B est liée à une et une seule ligne de A doit se faire par programme.

[fsmrel]

Bonjour à tous,

Le MLD obtenu à partir de ce MCD est (clés primaires soulignées, clé étrangère suffixée par #) :

A (A, A1, A2, ..., An, B#)
B (B, B1, B2, ..., Bn)

Le contrôle que chaque ligne de B est liée à une et une seule ligne de A doit se faire par programme.

Hum... Concernant la table B, la règle de gestion selon laquelle pour une valeur de l’attribut B il y a exactement une valeur de l’attribut A, entraîne la mise en œuvre d’une clé alternative {B#} de préférence à celle d'un programme.

Dans le style de Tutorial D :

Code Tutorial_D :

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

1
2
3
4
5
6
7
VAR B {B, B1, B2, ..., Bn}
      KEY {B} ;

VAR A {A1, A2, ..., An, B#}
      KEY {A}
      KEY {B#}
      FOREIGN KEY {B#} REFERENCES B ;

[JPhi33]

Bonjour fsmrel,

Hum... Concernant la table B, la règle de gestion selon laquelle pour une valeur de l’attribut B il y a exactement une valeur de l’attribut A, entraîne la mise en œuvre d’une clé alternative {B#} de préférence à celle d'un programme.

Oui, c'est encore mieux si le SGBD prend en charge cette contrainte.

Code Tutorial_D :

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

1
2
3
4
5
VAR A {A1, A2, ..., An, B#}
      KEY {A}
      KEY {B#}
      FOREIGN KEY {B#} REFERENCES B ;

Par contre, je ne comprends pas la disparition de l'attribut A dans la liste des attributs de VAR A. Est-ce un oubli ou bien y a-t-il une particularité inhérente à la coexistence de la clé A et de la clé arternative B# ?

[fsmrel]

Hello JPhi33,

je ne comprends pas la disparition de l'attribut A dans la liste des attributs de VAR A.

Dont acte. Il s’agit d’une coquille. Je rectifie donc :

Code Tutorial_D :

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

1
2
3
4
VAR A {A, A1, A2, ..., An, B#}
      KEY {A}
      KEY {B#}
      FOREIGN KEY {B#} REFERENCES B ;

Dans le style SQL :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
CREATE TABLE A
(
        A ...   
      , A1 ...
      , ...
      , An ...
      , B# ...
  , PRIMARY KEY (A)
  , UNIQUE (B#) 
  , FOREIGN KEY (B) REFERENCES B
) ;

c'est encore mieux si le SGBD prend en charge cette contrainte.

Cette contrainte (voir la clause UNIQUE dans le code SQL ci-dessus) existe dans la norme depuis SQL:92. Elle est disponible dans les SGBDR (à titre d'exemple, depuis la version 3 de DB2, qui date de 1993). Dans les années quatre-vingts, on palliait l’absence de cette contrainte en définissant au niveau physique un index de type UNIQUE.