Je lijkt de specificatie verkeerd te lezen. Een artikel wordt naar een UPS-winkelcentrum gebracht en vervolgens naar een bestemming verzonden. Maar laten we eens kijken naar de ternaire relatie dat een verzonden item een transportgebeurtenis nodig heeft om een specifieke bestemming te bereiken .
Dat is een van de vele mogelijke relaties tussen die drie entiteiten.
Ja dat doet het. Maar de ternaire relatie is uit te drukken in termen van deze diagram binaire relaties. (En niet andersom.)
Elke tabel - basisvariabele of queryresultaat - bevat rijen die deelnemen aan een bepaalde relatie. We kunnen de relatie karakteriseren met een predikaat --een verklaringssjabloon geparametreerd door attributen.
Een tabel bevat de rijen waarvan de waarden voor attributen een waar statement maken van zijn predikaat. Het predikaat van een basisvariabele wordt gegeven door de DBA.
-- shipped item ItemNumber is received by retail center UniqueId
SELECT * FROM ReceivedFrom
-- shipped item ItemNumber takes transportation event ScheduleNumber
SELECT * FROM ShippedVia
Het predikaat van een query-expressie is opgebouwd uit zijn operators en argumenten. Het predikaat van de NATUURLIJKE JOIN van twee tabellen is de AND van de predikaten van de tabellen.
-- shipped item ItemNumber is received by retail center UniqueId
and takes transportation event ScheduleNumber
SELECT * FROM ReceivedFrom NATURAL JOIN ShippedVia
Natuurlijk is uw specifieke opvatting van de ternaire relatie misschien niet deze exacte query / tabel. Maar een praktische UPS-database zou tabellen hebben voor de fundamentele relaties waarin elke relevante relatie kan worden uitgedrukt.
(Normalisatie splitst predikaten van de vorm "... AND ..." in afzonderlijke predikaten voor de "..."s wanneer dat mogelijk en nuttig is; de originele tabel wordt teruggegeven door de JOIN van de componenten.)