Le prime due relazioni, One
e Many
, hanno un limite inferiore non specificato . Quindi quando li usi lasci un'ambiguità se sono obbligatori o facoltativi.
Questa ambiguità è utile nella modellazione, al fine di far fronte a una o più delle seguenti circostanze:
- il limite inferiore potrebbe essere temporaneamente indefinito, ad esempio durante la fase di progettazione, quando tutte le regole aziendali non sono ancora chiare.
- il limite inferiore non è rilevante, ad esempio perché è una decisione che può essere presa in seguito, quando si configura il software e in base alle regole aziendali (ad esempio, definizione ad hoc di not null vincolo nel database o parametro run-time che definisce se il codice dell'applicazione deve accettare o meno la situazione.
- per evitare l'ansia inutile quando c'è una discrepanza tra il modello teorico e la pratica dell'applicazione. In genere, questo è il caso della tua relazione da
shipment
a item
: nella vita reale, ti aspetteresti che una spedizione contenga almeno 1 elemento (di solito le persone non amano inviare scatole vuote!). Quindi, nel modello, ti aspetteresti one or many
. Ma dall'altra parte nella tua domanda, puoi benissimo decidere di creare una spedizione in due fasi: crei una spedizione vuota nell'ufficio vendite e successivamente aggiungi gli articoli (con un lettore di codici a barre in officina). Quindi l'app e il db devono gestire spedizioni che possono essere temporaneamente vuote.
L'ultimo caso si verifica molto più di quanto ci si aspetti di solito. Mantenere il limite inferiore non specificato, ha quindi il vantaggio di costringere dba e sviluppatori a mantenere il vincolo minore (ovvero 0 o più nella pratica dell'applicazione), senza contraddire l'assunto teorico (cioè 1 a molti, perché alla fine, nessuna spedizione lascia la fabbrica è vuota).