database - Numero minimo di tabelle esistenti dopo la decomposizione della relazione R in 1NF?



database-design relational-database (1)

Considera la relazione R (A, B, C, D, E, F, G) con i seguenti tipi di attributi: -

Numero totale di chiavi = 1 = {A}

Insieme di attributi semplici (o) atomici (o) a valore singolo = {B, C}

Insieme di attributi multivalore = {D, E}

Insieme di attributi compositi = {F, G}

Quale sarebbe il numero minimo di tabelle esistenti dopo aver decomposto la relazione R in 1NF?

(A) 3 (B) 2 (C) 4 (D) 5

Il mio tentativo:

Avevamo bisogno di una tabella diversa per ogni attributo multivalore con la chiave data (A), totale = 2

Allo stesso modo, avevamo bisogno di una tabella diversa per ogni attributo composito, totale = 2.

Ci sono un totale di 4 di questi attributi. Fornisco 4 tabelle con la chiave data (A) in ciascuna (4) tabelle. Mi è permesso inserire attributi atomici (B, C) in una qualsiasi delle 4 tabelle indicate. Quindi, ho concluso che 4 tabelle sono sufficienti per rappresentare la relazione nella prima forma normale.

Puoi spiegare in modo formale, per favore?


Per ogni attributo che ritieni "composito" (con parti eterogenee, come una tupla):

Per ogni componente di attributo composito che può mancare: aggiungere una relazione con gli attributi di una chiave candidata e un attributo per quel componente. Per ogni riga della relazione originale che ha quel componente ha una riga nella nuova relazione il cui nuovo valore di attributo è il valore del componente e i cui valori dell'attributo chiave candidato sono quelli della riga originale. Quindi rilasciare il componente. Ciò aggiunge una relazione per componente che può mancare.

Per ogni componente rimanente: aggiungi un attributo alla relazione originale il cui valore in ogni riga è il valore del componente. Quindi rilasciare l'attributo composito. Questo non aggiunge relazioni.

Per un attributo che ritieni "multivalore" (con parti omogenee, come una relazione):

Per un attributo di un tipo che può avere zero elementi: aggiungere una relazione con gli attributi di una chiave candidata e quell'attributo. Per ogni riga della relazione originale avere un insieme di righe nella nuova relazione i cui nuovi valori di attributo sono gli elementi dell'attributo multivalore e i cui valori di attributo chiave candidato sono quelli della riga originale. Quindi rilasciare l'attributo multivalore. Ciò aggiunge una relazione per attributo multivalore.

Per un attributo di un tipo che ha sempre elementi: sostituisci ogni riga della relazione originale con un insieme di righe i cui valori di attributo multivalore sono gli elementi dell'attributo multivalore e i cui altri valori di attributo sono quelli della riga originale. Questo non aggiunge relazioni.

Quindi le relazioni finali qui sono {A, B, C, F1, ..., G1, ...}, {A, D} e {A, E}, un totale 1 (per originali e compositi) + 2 ( per multivalore).

(Se tutte le chiavi candidate di una relazione contengono attributi multivalore, è necessario introdurre un attributo surrogato per almeno un attributo multivalore.)

Naturalmente, in pratica dovresti normalizzare le nuove tabelle, che potrebbero generare nuove tabelle. Ma questo è per migliorare il design. Qui vogliamo un design con il minor numero possibile di tabelle aggiunte.

(Non esiste una cosa come "decomporre" una relazione in 1NF. Il senso originale di "normalizzare" significava sbarazzarsi degli attributi valutati in relazione. La teoria della normalizzazione successiva considera ogni relazione in 1NF. Vedi this 1NF e atomicità. Possiamo sostituiamo una relazione con attributi che consideriamo avere parti omogenee (multivalore) o parti eterogenee (composito) con una o più relazioni che hanno invece attributi per parti. E possiamo convertire un disegno non relazionale in uno relazionale. -relational design non avrà un candidato / chiave primaria, perché è definito solo per le relazioni.)





database-normalization