Presumibilmente un camion e/o un camionista ha un incarico che prevede il passaggio attraverso una sequenza di eventi che include seguire un percorso ed effettuare consegne e transazioni, ecc. Presumibilmente un lavoro è un tale evento, di cui esistono diversi tipi, ad esempio ritiro, trasferimento e abbandono.
Le tabelle in un database relazionale descrivono lo stato di un'applicazione. A ciascuna tabella è associata un'istruzione (predicato) di riempimento (con nome). I predicati della tabella di base sono forniti dal progettista:
// truck [truck_id] has code [truck_code] and ...
TRUCK (truck_id, truck_code, ...)
// product [product_id] has code [product_code] and name [product_name] ...
PRODUCT (product_id, product_code, product_name, ...)
(Un predicato caratterizza una relazione applicativa, alias relazione, rappresentata da una tabella, alias relazione, da cui "il modello relazionale".)
I parametri del predicato sono le colonne della tabella. Quando fornisci valori per ogni parametro, ottieni un'istruzione (proposizione) che è vera o falsa sulla tua applicazione. Una riga di valori per le colonne fornisce tali valori per ogni spazio vuoto denominato. Le righe che rendono vero il predicato di una tabella vanno nella tabella. Le righe che fanno se false restano fuori. È così che lo stato del database descrive la situazione dell'applicazione. Devi conoscere le istruzioni delle tabelle per leggere o interrogare il database per scoprire in base alle sue righe cosa c'è di vero e falso in una situazione e per aggiornare il database inserendo esattamente le righe che fanno proposizioni vere dopo aver osservato la situazione .
Ogni query ha anche un predicato costruito dai predicati delle sue tabelle. Il JOIN di due tabelle fornisce le righe che soddisfano l'AND dei loro predicati, UNION l'OR, ecc. E un risultato di query contiene anche le righe che soddisfano il suo predicato .
(I vincoli sono irrilevanti per questo; descrivono solo collettivamente gli stati del database che possono sorgere dati i predicati e gli stati di applicazione che possono sorgere.)
Devi decidere su predicati sufficienti per poter descrivere completamente le istituzioni della tua domanda. Ciò include cose astratte come rotte, transazioni ed eventi, programmi e assegnazioni, ecc. (Una volta che abbiamo predicati/tabelle sufficienti, li miglioriamo tramite tecniche come la normalizzazione.)
Quando possono esserci diversi tipi di cose, parliamo di supertipi e sottotipi e vediamo predicati come (io userò "lavoro" che considero un evento):
// job [job_id] for trucker [trucker_id] is ... stuff about all jobs ...
JOB(job_id, trucker_id...)
// job [job_id] is a pickup with ... stuff about pickups ...
PICKUP(job_id, container_id...)
// job [job_id] is a transfer with ... stuff about transfers
TRANSFER(job_id,...)
...
(Potresti o meno avere una nozione diversa o aggiuntiva di trasferimento come evento con due o più contenitori associati, ecc.) (Cerca "sottotipi". Es. )
