Bonsoir,
Allons-y pour modéliser. Je propose différents diagrammes, et en traiterai en deux épisodes.
Premier épisode
Reprenons votre dernier diagramme :
Passons en revue les attributs de la table PIECE :
a) Par référence à
votre réponse concernant le prix et le stock, ceux-ci dépendent du code société.
A cette occasion je n’ai pas posé la question concernant l’attribut QuantiteInstallee : je vais supposer que sa valeur dépend elle aussi du code société. S’il n’en est pas ainsi, on corrigera.
Merci de me dire ce qu’il en est.
b) Par référence à
votre réponse à la question Q1, la désignation de la pièce est indépendante du code société.
c) Par référence à
votre réponse à la question Q19, la relation de la pièce avec le sous-ensemble auquel elle appartient est indépendante du code société.
d) Par référence à
vos réponses aux questions Q13 et Q14, le repère de la pièce, ainsi que le plan auquel elle fait référence, sont indépendants du code société.
Il ressort que la table PIECE ne doit conserver que les attributs et relations indépendants du code société, tandis que ceux qui en dépendent doivent être regroupés dans une table ad-hoc, appelons-la par exemple PIECE_CODE_SOCIETE :
PIECE {ReferencePiece, Designation, NumSousEnsemble, Repere, NumPlan} ;
PIECE_CODE_SOCIETE {ReferencePiece, CodeSociete, Stock, Prix, QuantiteInstallee} ;
Clé de la table PIECE : celle que vous aviez définie initialement : {ReferencePiece}.
Clé de la table PIECE_CODE_SOCIETE : par référence à votre réponse à la question Q2, comme le code société est unique, la clé de cette table est le singleton {CodeSociete}.
A noter que par référence à votre réponse à la question Q3, comme le code variante est unique, la clé de la table VARIANTE est le singleton {CodeVariante}.
Pour ma part, dans les diagrammes qui suivent, je renomme la table PIECE en PIECE_AU_CATALOGUE, et je renomme aussi les attributs à ma façon, mais à votre tour, faites à votre façon...
On tend vers quelque chose qui ressemble à ceci, où je remplace la notation ACCESS par la notation UML :
Où les losanges en rouge symbolisent les clés étrangères. Par exemple, dans la table SYSTEME, le singleton {NoSerie} est clé étrangère par rapport à la clé primaire {NoSerie} de la table MACHINE, c'est-à-dire que les valeurs prises par l’attribut NoSerie de la table SYSTEME doivent d’abord être des valeurs prises par l’attribut NoSerie de la table MACHINE : pas d’orphelins dans les tables...
N.B. J’ai utilisé la notation UML car plus complète quant aux cardinalités, et en plus, la notation ACCESS fait qu’on obtient quelque chose qui tient plus de l’art new-yorkais qu’autre chose et devient vite pénible à lire :
Il y a encore des points à préciser, mais je pense que la base est à peu près stabilisée. Cela vous convient-il ?
Les questions du jour...
Envoyé par fatich
Répondre avec citation
Partager