Una tabella figlio (AKA entità debole ) è una tabella i cui attributi della chiave primaria dipende su un'altra tabella, quindi la tabella figlia è identificata o parzialmente identificato per righe nella tabella da cui dipende (genitore). Le righe in una tabella figlio non possono esistere senza una riga corrispondente nella tabella padre.
Per illustrare, prendiamo un esempio semplice e del tutto pertinente che tutti conosciamo:Genitori e figli nel contesto della famiglia . Possiamo modellare questa relazione con le tabelle in questo modo:
Nel modello sopra, ogni riga in Parents la tabella è identificata in modo univoco da un SSN . Il SSN è un attributo intrinseco e unico per ciascun genitore, quindi è un'entità autonoma o "forte" perché non si basa su un'altra tabella per definire la sua identità.
I bambini, invece, richiedono un genitore per esistere (Parent_SSN deve riferimento a un SSN esistente nel Parents tavolo).
Notare la chiave primaria composita (Parent_SSN, Name ) nel Children tavolo. Ciò significa che i bambini sono identificati in modo univoco dalla combinazione di Parent_SSN e Name . Non puoi eseguire query per un singolo figlio in base solo al Name campo perché più genitori possono avere figli con lo stesso nome. Allo stesso modo, non puoi eseguire query per un singolo figlio in base solo al Parent_SSN campo perché un genitore può avere molti figli. Tenendo conto di ciò, i bambini sono parzialmente identificati dal genitore, quindi identificandosi relazione.
Ma i bambini non possono essere identificati in modo univoco anche da un SSN? Perché sì, certo. Andiamo avanti e regoliamo il nostro modello per includerlo:
In questa versione del modello, nota che abbiamo introdotto il SSN campo per Children . L'identità unica dei bambini è ora definito dal proprio SSN intrinseco e univoco . La loro identità non dipende più su Parents tavolo. Sebbene il Parent_SSN il campo fa ancora riferimento al SSN dei Parents tabella, non fa parte dell'identità univoca del bambino, quindi i genitori hanno un non identificativo relazione con i propri figli ed entrambe le tabelle possono ora essere considerate entità autonome "forti".
Per inciso, questa versione del modello presenta alcuni vantaggi rispetto alla prima:
- Un genitore ora può avere due o più figli con lo stesso nome, mentre l'integrità dell'entità vincolo nel modello precedente non lo consentirebbe.
- Puoi consentire il
Parent_SSNcampo per contenereNULLper tenere conto dell'evento in cui disponi di dati sul bambino, ma non sai chi è il suo genitore.
In entrambi i modelli precedenti, i Parents table è considerata la tabella padre dei Children tavolo. Tuttavia, in non identificativo relazioni come nel secondo modello, Parents è solo una tabella padre nel contesto della chiave esterna Parent_SSN perché Parent_SSN riferimenti/dipende su SSN nel Parents tabella, ma non avere un ruolo nella definizione dell'effettiva identità dei bambini.
Per illustrare perché il contesto è importante quando si decide quali tabelle sono tabelle padre/figlio, si consideri il seguente esempio che coinvolge una dipendenza circolare:
In questo esempio, dipendenti e reparti sono identificati in modo univoco dai propri attributi e non derivano alcuna parte della loro identità da altre tabelle.
Qui abbiamo due relazioni non identificative:un dipendente lavora per un dipartimento (DeptNo nel Employee table) e un reparto è gestito da un dipendente (ManagerSSN nel Department tavolo). Qual è la tabella padre? ...Tavolino per bambini?
Dipende dal contesto:di quale relazione di chiave esterna stai parlando? La tabella Department sarebbe considerata la tabella padre nel contesto di DeptNo nel Employee tabella perché DeptNo è riferito/dipendente nel Department tavolo.
Tuttavia, la tabella Employee verrebbe considerata la tabella padre nel contesto di ManagerSSN nel Department tabella perché ManagerSSN è riferito/dipendente sul Employee tabella.
