Предполага се, че камион и/или шофьор на камион има задача, включваща преминаване през поредица от събития, които включват следване на път и извършване на доставки и транзакции и т.н. Предполага се, че работата е такова събитие, което има няколко вида, напр. вземане, трансфер и връщане.
Таблиците в релационна база данни описват състоянието на приложението. Всяка таблица има свързан оператор за попълване на (наименувани-) празни места (предикат). Предикатите на базовата таблица са дадени от дизайнера:
// 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, ...)
(Предикатът характеризира връзка на приложение, известна още като релация, представена от таблица, известна още като релация, следователно „отношен модел“.)
Параметрите на предиката са колоните на таблицата. Когато предоставяте стойности за всеки параметър, получавате твърдение (предложение), което е вярно или невярно за вашето приложение. Ред от стойности за колони дава такива стойности за всяко наименувано празно място. Редовете, които правят предиката на таблицата верен, влизат в таблицата. Редовете, които правят if false, остават извън. Ето как състоянието на базата данни описва ситуацията на приложението. Трябва да знаете изявленията на таблиците, за да четете или правите заявки в базата данни, за да разберете по нейните редове кое е вярно и невярно за дадена ситуация и да актуализирате базата данни, като поставите в нея точно редовете, които правят верни предложения, след като наблюдавате ситуацията .
Всяка заявка също има предикат, изграден от предикатите на нейните таблици. JOIN на две таблици дава редовете, които отговарят на AND на техните предикати, UNION на OR и т.н. И резултатът от заявката също така съдържа редовете, които отговарят на нейния предикат .
(Ограниченията са без значение за това; те просто колективно описват състоянията на базата данни, които могат да възникнат, като се имат предвид предикатите и състоянията на приложението, които могат да възникнат.)
Трябва да вземете решение за достатъчно предикати, за да можете да опишете напълно структурите на вашето приложение. Това включва абстрактни неща като маршрути и транзакции, събития, графици и присвоявания и т.н. (След като имаме достатъчно предикати/таблици, ние ги подобряваме чрез техники като нормализиране.)
Когато може да има различни видове неща, ние говорим за супертипове и подтипове и виждаме предикати като (ще използвам „работа“, което приемам за събитие):
// 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,...)
...
(Вие може да имате или да нямате различна или допълнителна представа за трансфер като събитие с два или повече свързани контейнера и т.н.) (Търсете „подтипове“. Напр. )
