Vous semblez mal lire la spécification. Un article est apporté à un centre de vente UPS et est ensuite expédié vers une destination. Mais considérons la relation ternaire selon laquelle un article expédié prend un événement de transport pour atteindre une destination spécifique .
C'est l'une des nombreuses relations imaginables sur ces trois entités.
Oui. Mais la relation ternaire est exprimable en termes de ces relations binaires de diagramme. (Et pas l'inverse.)
Chaque table (variable de base ou résultat de requête) contient des lignes qui participent à une relation particulière. On peut caractériser la relation par un prédicat --un modèle de déclaration paramétré par des attributs.
Une table contient les lignes dont les valeurs des attributs font une déclaration vraie à partir de son prédicat. Le prédicat d'une variable de base est donné par le DBA.
-- shipped item ItemNumber is received by retail center UniqueId
SELECT * FROM ReceivedFrom
-- shipped item ItemNumber takes transportation event ScheduleNumber
SELECT * FROM ShippedVia
Le prédicat d'une expression de requête est construit à partir de ses opérateurs et arguments. Par exemple, le prédicat du NATURAL JOIN de deux tables est le AND des prédicats des tables.
-- shipped item ItemNumber is received by retail center UniqueId
and takes transportation event ScheduleNumber
SELECT * FROM ReceivedFrom NATURAL JOIN ShippedVia
Bien sûr, votre conception particulière de la relation ternaire pourrait ne pas être cette requête/table exacte. Mais une base de données UPS pratique aurait des tables pour les relations fondamentales en termes desquelles toute relation pertinente peut être exprimée.
(La normalisation divise les prédicats de la forme "... AND ..." en prédicats séparés pour les "..." lorsque cela est possible et utile ; la table d'origine est restituée par le JOIN des composants.)
