Presumivelmente, um caminhão e/ou caminhoneiro tem uma tarefa que envolve passar por uma sequência de eventos que inclui seguir um caminho e fazer entregas e transações, etc. Presumivelmente, um trabalho é um evento desse tipo, do qual existem vários tipos, por exemplo, coleta, transferência e deixar.
As tabelas em um banco de dados relacional descrevem o estado de um aplicativo. Cada tabela tem uma declaração de preenchimento de espaços (predicado) associada. Os predicados da tabela base são fornecidos pelo designer:
// 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, ...)
(Um predicado caracteriza uma relação de aplicação, também conhecida como relação, representada por uma tabela, também conhecida como relação, daí "o modelo relacional".)
Os parâmetros do predicado são as colunas da tabela. Ao fornecer valores para cada parâmetro, você obtém uma declaração (proposição) que é verdadeira ou falsa sobre seu aplicativo. Uma linha de valores para colunas fornece esses valores para cada espaço em branco nomeado. As linhas que tornam o predicado de uma tabela verdadeiro vão para a tabela. As linhas que se tornam falsas ficam de fora. É assim que o estado do banco de dados descreve a situação do aplicativo. Você tem que conhecer as declarações das tabelas para ler ou consultar o banco de dados para descobrir por suas linhas o que é verdadeiro e falso sobre uma situação e atualizar o banco de dados colocando exatamente as linhas que fazem proposições verdadeiras depois de observar a situação .
Cada consulta também tem um predicado construído a partir dos predicados de suas tabelas. O JOIN de duas tabelas fornece as linhas que satisfazem o AND de seus predicados, UNION o OR etc. E um resultado de consulta também contém as linhas que satisfazem seu predicado .
(As restrições são irrelevantes para isso; elas apenas descrevem coletivamente os estados do banco de dados que podem surgir, dados os predicados e os estados de aplicação que podem surgir.)
Você precisa decidir sobre predicados suficientes para poder descrever completamente as situações de sua aplicação. Isso inclui coisas abstratas como rotas e transações e eventos e horários e atribuições etc. (Uma vez que temos predicados/tabelas suficientes, nós os melhoramos por meio de técnicas como normalização.)
Quando pode haver diferentes tipos de coisas, falamos sobre supertipos e subtipos e vemos predicados como (vou usar "job" que considero um 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,...)
...
(Você pode ou não ter uma noção diferente ou adicional de transferência como um evento com dois ou mais contêineres associados etc.) (Pesquise "subtipos". Ex. )
