If this ER diagram uses triple bond instead of
I have looked at the examples of ER diagrams to understand them better. I came across an ER diagram which I am pretty sure is correct.
Here is the question / specification:
UPS prides itself on having the latest information on the processing and current location of every item shipped. For this, the UPS relies on a system-wide information system. Shipped goods are the heart of the UPS product tracking information system. Items shipped can be characterized by Item Number (Unique), Weight, Size, Sum Insured, Destination and Final Delivery Date. The shipped goods enter the UPS system in one shopping mall. Shopping centers are characterized by their type, uniqueID and address. Dispatched items make their way to one or more of the standard UPS transport events (i.e. flights, delivery of trucks). These transport events are characterized by unique timetables of type, type (eg flight, truck) and delivery.
Essence: RetailCenter
, ShippedItems
, Transportation Event
Relationship: ReceivedFrom(RetailCenter,ShippedItems)
,ShippedVia(ShippedItems,TransportationEvent)
Here is the diagram: 
My questions are, shouldn't there be a triple relationship between these three entities? My thought process is that a shipped item takes a transportation event to get to a specific mall. Doesn't this diagram say that the shipped item is received at the mall and that the shipped item is receiving a transport event?
source to share
My thought process is that a shipped item takes a transportation event to reach a specific mall.
You seem to be reading the spec wrong. The item is shipped to a UPS mall and then shipped to its destination. But consider the triple relationship that a dispatched item takes on a transportation event to get to a particular destination.
This is one of many conceivable relationships for these three objects.
Doesn't this diagram say that the shipped item is received by the mall and that the shipped item is receiving a transport event?
Yes Yes. But the triple bond is expressed in terms of these binary diagram relationships. (And not vice versa.)
Each table variable or query result - contains rows that participate in a specific relationship. We can characterize a relationship with a predicate — a statement template parameterized by attributes.
The table contains rows whose attribute values make a true statement from its predicate. The base variable predicate is specified by the DBA.
-- shipped item ItemNumber is received by retail center UniqueId
SELECT * FROM ReceivedFrom
-- shipped item ItemNumber takes transportation event ScheduleNumber
SELECT * FROM ShippedVia
A query expression predicate is built from its operators and arguments. For example, the NATURAL JOIN predicate of two tables is AND of the table predicates.
-- shipped item ItemNumber is received by retail center UniqueId
and takes transportation event ScheduleNumber
SELECT * FROM ReceivedFrom NATURAL JOIN ShippedVia
Of course, your particular concept of ternary relationships may not be as precise a query / table. But the practical basis of a UPS must have tables for the fundamental relationships in terms of which any relevant relationship can be expressed.
(Normalization splits predicates of the form "... AND ..." into separate predicates for "..." s, when possible and useful, the original table returns the JOIN of the components.)
source to share