Bonsoir,
Tout d’abord, l’association-type ENREGISTRER est redondante et sera source d’un viol de 2NF (deuxième forme normale) au niveau tabulaire et doit donc disparaître. En effet, un événement détermine un message qui détermine une machine, donc par transitivité, un événement détermine une machine.
Je ne suis pas complètement entré dans votre problème, mais en première approche, je représenterais les choses ainsi, en utilisant un outil de niveau logique (MLD) plus que conceptuel (MCD), mais évitant de bricoler les diagrammes et apte à produire le code SQL attendu. J’utilise donc en l’occurrence MySQL Workbench (gratuit) :
MLD.png)
Légende :
Lien en trait plein : association avec identification relative.
Lien en trait en pointillés : association lambda (sans identification relative).
Clé jaune = attribut participant à la clé primaire (voire à une clé étrangère).
Losange rouge : attribut parrticipant à une clé étrangère, mais pas à la clé primaire.
Losange bleu : attribut lambda (not null).
Par exemple, la structure de VALEUR est la suivante :
1
2
3
4
5
6
7
|
VALEUR {MachineId, MessageId, EvenementId, ValeurId, DetailId, Valeur}
PRIMARY KEY {MachineId, MessageId, EvenementId, ValeurId}
FOREIGN KEY {MachineId, MessageId, EvenementId}
REFERENCES EVENEMENT {MachineId, MessageId, EvenementId}
FOREIGN KEY {MachineId, MessageId, DetailId}
REFERENCES DETAIL {MachineId, MessageId, DetailId} |
Envoyé par
fifrelin70
le but est de rester performant dans les requêtes en évitant de multiplier les enregistrements dans la base
La multiplication des enregistrements (sous-entendu des tables, donc des jointures) n’est pas nécessairement un facteur de dégradation de performances. Il s’agit d’un mythe datant des années quatre-vingts et qui a été rapidement démoli, mais nombreux sont ceux qui l’entretiennent doctement et en toute incompétence.
Par contre, considérons l’en-tête de votre table MESSAGE :
num_message, #machine_message, libellé_message, #type_message
A supposer que l’ordre des attributs composant l’index utilisé pour la clé primaire reflète l’ordre des attributs dans l’en-tête de la table :
{num_message, machine_message}
Au niveau physique les accès à la table MESSAGE pourront être sujets à un phénomène d’« I/O bound » que l’on évitera en permutant l’ordre des attributs dans l’index (et dans la clé primaire) donc déjà dans la table :
#machine_message, num_message, libellé_message, #type_message
Etre I/O bound peut encore s'interpréter comme : ramer à cause des accès au disque.
Suivi de production
Répondre avec citation
(Valeur).png)
MLD_V2.png)
EvenementId_both.png)
PropertiesEditor.png)
mais qui aura quand même une bonne note quand il aura remis l'identification relative. 
Partager