おそらく、トラックおよび/またはトラック運転手は、経路をたどり、配達や取引などを行う一連のイベントを通過することを含む割り当てを持っています。おそらく、仕事はそのようなイベントであり、ピックアップ、転送、ドロップオフ。
リレーショナルデータベースのテーブルは、アプリケーションの状態を記述します。各テーブルには、（named-）blanksステートメント（述語）が関連付けられています。基本テーブルの述語は、設計者によって提供されます：
// 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, ...)
（述語は、アプリケーション関係、別名関係、テーブル、別名関係、したがって「関係モデル」によって表されることを特徴づけます。）
述語のパラメーターは、テーブルの列です。各パラメーターに値を指定すると、アプリケーションについて真または偽のステートメント（命題）が得られます。列の値の行は、名前付きブランクごとにそのような値を示します。テーブルの述語をtrueにする行は、テーブルに入ります。 falseの場合に作成される行は除外されます。これが、データベースの状態がアプリケーションの状況を表す方法です。データベースを読み取ったりクエリしたりして、状況について真と偽を行ごとに見つけ、状況を観察した後、真の命題を作成する行をデータベースに正確に配置してデータベースを更新するには、テーブルのステートメントを知っている必要があります。 。
すべてのクエリには、そのテーブルの述語から構築された述語もあります。 2つのテーブルの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,...)
...
（2つ以上のコンテナが関連付けられているイベントなど、異なるまたは追加の転送の概念がある場合とない場合があります。）（「サブタイプ」を検索します。例 ）