Presumiblemente, un camión y/o camionero tiene una tarea que implica pasar por una secuencia de eventos que incluyen seguir un camino y realizar entregas y transacciones, etc. devolución.
Las tablas de una base de datos relacional describen el estado de una aplicación. Cada tabla tiene una instrucción (predicado) para completar los espacios en blanco (nombrados). Los predicados de la tabla base los proporciona el diseñador:
// 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 predicado caracteriza una relación de aplicación, también conocida como relación, representada por una tabla, también conocida como relación, por lo tanto, "el modelo relacional".)
Los parámetros del predicado son las columnas de la tabla. Cuando proporciona valores para cada parámetro, obtiene una declaración (proposición) que es verdadera o falsa sobre su aplicación. Una fila de valores para columnas proporciona dichos valores para cada espacio en blanco con nombre. Las filas que hacen verdadero el predicado de una tabla van en la tabla. Las filas que hacen si es falso quedan fuera. Así es como el estado de la base de datos describe la situación de la aplicación. Debe conocer las declaraciones de las tablas para leer o consultar la base de datos para averiguar por sus filas qué es verdadero y falso sobre una situación y actualizar la base de datos colocando exactamente las filas que hacen proposiciones verdaderas después de observar la situación. .
Cada consulta también tiene un predicado construido a partir de los predicados de sus tablas. El JOIN de dos tablas da las filas que satisfacen el AND de sus predicados, UNION el OR, etc. Y el resultado de una consulta también contiene las filas que satisfacen su predicado .
(Las restricciones son irrelevantes para esto; simplemente describen colectivamente los estados de la base de datos que pueden surgir dados los predicados y los estados de aplicación que pueden surgir).
Debe decidir sobre suficientes predicados para poder describir completamente las instituciones de su aplicación. Esto incluye cosas abstractas como rutas, transacciones, eventos, horarios, asignaciones, etc. (Una vez que tenemos predicados/tablas suficientes, los mejoramos mediante técnicas como la normalización).
Cuando puede haber diferentes tipos de cosas, hablamos de supertipos y subtipos y vemos predicados como (usaré "trabajo", que 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,...)
...
(Puede o no tener una noción diferente o adicional de transferencia como un evento con dos o más contenedores asociados, etc.) (Buscar "subtipos". Ej. )
