Vraisemblablement, un camion et/ou un camionneur a une mission impliquant de passer par une séquence d'événements qui comprend le suivi d'un chemin et la réalisation de livraisons et de transactions, etc. dépôt.
Les tables d'une base de données relationnelle décrivent l'état d'une application. Chaque table est associée à une instruction fill-in-the-(named-)blanks (prédicat). Les prédicats de la table de base sont donnés par le concepteur :
// 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 prédicat caractérise une relation d'application, alias relation, représentée par une table, alias relation, d'où "le modèle relationnel".)
Les paramètres du prédicat sont les colonnes de la table. Lorsque vous fournissez des valeurs pour chaque paramètre, vous obtenez une déclaration (proposition) vraie ou fausse concernant votre application. Une ligne de valeurs pour les colonnes donne ces valeurs pour chaque blanc nommé. Les lignes qui rendent vrai le prédicat d'une table vont dans la table. Les lignes qui font si faux restent en dehors. C'est ainsi que l'état de la base de données décrit la situation de l'application. Vous devez connaître les instructions des tables afin de lire ou d'interroger la base de données pour savoir par ses lignes ce qui est vrai et faux sur une situation et mettre à jour la base de données en y mettant exactement les lignes qui font de vraies propositions après avoir observé la situation .
Chaque requête a également un prédicat construit à partir des prédicats de ses tables. Le JOIN de deux tables donne les lignes qui satisfont le AND de leurs prédicats, UNION le OR, etc. Et un résultat de requête contient également les lignes qui satisfont son prédicat .
(Les contraintes ne sont pas pertinentes à cela ; elles décrivent simplement collectivement les états de la base de données qui peuvent survenir compte tenu des prédicats et des états d'application qui peuvent survenir.)
Vous devez choisir suffisamment de prédicats pour pouvoir décrire complètement les stituations de votre application. Cela inclut des éléments abstraits tels que les itinéraires, les transactions, les événements, les horaires et les affectations, etc. (Une fois que nous avons suffisamment de prédicats/tables, nous les améliorons via des techniques telles que la normalisation.)
Lorsqu'il peut y avoir différents types de choses, nous parlons de supertypes et de sous-types et voyons des prédicats comme (j'utiliserai "job" que je considère comme un événement) :
// 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,...)
...
(Vous pouvez ou non avoir une notion différente ou supplémentaire de transfert en tant qu'événement avec deux ou plusieurs conteneurs associés, etc.) (Rechercher "sous-types". Ex. )
