Parece que você está interpretando mal a especificação. Um item é levado a um centro de varejo da UPS e, em seguida, enviado para um destino. Mas vamos considerar a relação ternária em que um item enviado leva um evento de transporte para chegar a um destino específico .
Esse é um dos muitos relacionamentos concebíveis nessas três entidades.
Sim. Mas o relacionamento ternário é exprimível em termos desses relacionamentos binários do diagrama. (E não vice-versa.)
Cada tabela - variável base ou resultado de consulta - contém linhas que participam de algum relacionamento específico. Podemos caracterizar o relacionamento por um predicado --um modelo de instrução parametrizado por atributos.
Uma tabela contém as linhas cujos valores para atributos fazem uma declaração verdadeira de seu predicado. O predicado de uma variável base é dado pelo DBA.
-- shipped item ItemNumber is received by retail center UniqueId
SELECT * FROM ReceivedFrom
-- shipped item ItemNumber takes transportation event ScheduleNumber
SELECT * FROM ShippedVia
O predicado de uma expressão de consulta é construído a partir de seus operadores e argumentos. Por exemplo, o predicado do NATURAL JOIN de duas tabelas é o AND dos predicados das tabelas.
-- shipped item ItemNumber is received by retail center UniqueId
and takes transportation event ScheduleNumber
SELECT * FROM ReceivedFrom NATURAL JOIN ShippedVia
Claro, sua concepção particular do relacionamento ternário pode não ser essa consulta/tabela exata. Mas um banco de dados UPS prático teria tabelas para os relacionamentos fundamentais em termos dos quais qualquer relacionamento relevante pode ser expresso.
(A normalização divide os predicados da forma "... AND ..." em predicados separados para os "..." quando isso for possível e útil; a tabela original é retornada pelo JOIN dos componentes.)
