Come decidere veramente se un'entità è debole o no

C'è un po 'di spazio di manovra se qualche concetto dovrebbe essere modellato come entità o come entità debole.

Credete che le entità deboli non possono esistere senza un'altra entità non è sbagliato, non è solo la caratteristica che definisce. Le entità forti possono fare riferimento ad altre entità senza diventare entità deboli.

Dovremmo invece chiedere se l'entità esiste indipendentemente dai valori che contiene. Nei database, questa domanda è solitamente equivalente a: questa entità ha un ID?

Esistono entità forti indipendentemente dai valori che hanno, quindi possono essere identificate solo dal loro ID. Nel tuo modello dati: due diversi clienti possono vivere allo stesso indirizzo, ma sono clienti diversi perché hanno un numero cliente diverso. Qui, viene modellato che gli ordini hanno un numero di ordine.

Le entità deboli sono identificate dai loro valori. Qui, OrderItems sono identificati dalla combinazione di Order + ItemLineNumber (una chiave composta). ItemLineNumber non è una chiave primaria di per sé perché più elementi possono avere lo stesso numero di riga, se fanno parte di ordini diversi.

Naturalmente questo potrebbe essere stato modellato in modo diverso. Gli ordini potrebbero essere un'entità debole identificata da Customer + OrderNumber. Oppure ogni OrderItem potrebbe avere un campo ID, elevandolo a un'entità strong.

Quindi quando dovresti scegliere quale variante? Questo dipende interamente dal contesto. La regola "X appartiene a Y" o "X non può esistere senza Y" è una buona euristica che X potrebbe essere un'entità debole. Quindi pensi al dominio del problema. Per esempio. nel mio paese le fatture devono avere un numero univoco, quindi è logico utilizzare il numero di fattura come ID per l'ordine - l'ordine ha una chiave naturale / chiave di dominio. Dovresti anche pensare a come verrà interrogato il database. Se un'entità è l'obiettivo di qualche riferimento di chiave esterna, le query saranno molto più semplici se si tratta di un'entità strong con un ID - è possibile assegnare una chiave surrogata / chiave sintetica.

Nell'articolo Wikipedia a cui ti stai riferendo, si dice:

a weak entity is an entity that cannot be uniquely identified by its attributes alone

L'idea è che l'entità di per sé contenga informazioni incomplete; nell'esempio illustrato, potrebbero esserci diverse OrderItem entità che hanno tutti gli stessi attributi (se non si contano i OrderNumber FK), ma in realtà sono correlati a diversi Order entità.

Al contrario, ogni Order è determinato in modo univoco dalla sua chiave primaria. Sì, esiste una relazione con Customer , ma si noti che l'ordine non perde la propria identità se viene rimosso il riferimento a CustomerNumber . (Certo, è un po 'strano avere un ordine e non sapere chi sia il cliente, ma nel modo in cui viene concettualizzato, l'ordine esiste davvero indipendentemente dal cliente, una volta creato.)