Mysql
 sql >> Database >  >> RDS >> Mysql

Modellazione di database per un'entità debole

Un'entità non è debole perché non può esistere in modo indipendente, ma perché non può essere identificata indipendentemente. Pertanto, una relazione che "conduce" a un'entità debole è chiamata relazione "identificativa". In pratica, ciò significa che la chiave primaria del genitore viene migrata in (di solito corretto ) sottoinsieme della PK del bambino (il termine "entità debole" è solitamente definito in relazione alle chiavi primarie, sebbene in teoria potrebbe applicarsi a qualsiasi chiave).

È perfettamente legittimo avere un'entità che non può esistere in modo indipendente, ma può essere identificata in modo indipendente, in altre parole, in una relazione non identificativa con un non NULL.

Devi chiedere:can historyLineID essere unico da solo o in combinazione con orderID ? Sospetto che sia il secondo caso, il che lo renderebbe un'entità debole.

Quello che ci hai mostrato non è un'entità debole:la PK del genitore non viene migrata nella PK del figlio.

Hai essenzialmente due opzioni:

  • orderHistory ha una PK composita:{orderID, historyLineID} , dove orderID è FK. A proposito, questo PK potrebbe essere considerato "naturale":

  • orderHistory ha un PK surrogato:{orderHistoryID} , mentre orderID è al di fuori del PK. Dovresti comunque avere una chiave alternativa {orderID, historyLineID} però:

Sì, questa è la prima opzione sopra descritta. A meno che tu non abbia relazioni figlio su orderHistory di per sé, questa è anche la soluzione migliore. Se orderHistory ha figli, quindi questa potrebbe essere o meno la soluzione migliore, a seconda di diversi fattori.

Questo non è né-o. Un campo può essere sia FK che parte di una chiave (primaria o alternativa), come mostrato sopra.

Non sarai in grado di raggiungere 3NF se non specifichi correttamente le tue chiavi e non potrai farlo senza considerare quale entità può essere identificata in modo indipendente e quale no.