E 'ancora normalizzata db schema? Banca dati

Question

Ho il seguente db-schema.

File , GROUP e BLOCK rappresentare la struttura oggetto del file XML. File è la radice. GROUP ha FK a File . BLOCK ha quello FK a GROUP e l'altro FK a Unità .

UNIT gruppi "simili" Blocchi da differente Gruppi nel contesto del FILE .

La banca dati è attualmente in 3NF. Eppure mi piacerebbe sapere che Unità appartengono a File .id = 1. Per fare questo ancora, devo fare una query che unisce tutti i 4 tavoli. Per ottimizzare questo schema, posso creare la nuova relazione Unità n - FK -> 1 File . Eppure, la mia domanda si unisce solo due tavoli sul db-schema ottimizzato. Ed ecco la domanda: è questo DB (con questo nuovo FK) ancora in 3 NF? Ciò che la teoria dice?

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

o

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Answer 1

Da informazioni fornite, sembra che si tratta di una vera gerarchia parallela. Su questa base, credo che lo schema modificato proposto sarebbe ancora essere normalizzato a 3NF.

Answer 2

Non è chiaro come le crisi di tabella unità nel schema prima di apportare modifiche.

Ovviamente, dopo aver apportato le modifiche, tutto quello che dovete fare per sapere quale unità appartengono a un file è unire i tavoli di file e unità.

Dal momento che le tabelle sono in 3NF quando tutte le dipendenze funzionali sono determinati dalle chiavi, le chiavi intere, e nient'altro che i tasti (in modo help me Codd), si deve guardare il vostro schema in questa luce.

Sulla base delle informazioni disponibili, molto probabilmente i tavoli sono tutti in 3NF (e BCNF, e AFAICT in 4NF e 5NF troppo).

Answer 3

Non credo che la tua "canti piede" supporti diagramma le altre dipendenze delineati nella sua interrogazione. Come ti è venuta con l'1: molti tra FILE e Unità

?

Queste sono le dipendenze funzionali che descrivi ...

• GROUP -> File
• BLOCK -> GROUP
• BLOCK -> Unità

Inoltre, presumo che ciascuno degli attributi di cui sopra funzionalmente determinare alcune attributi aggiuntivi che non figurano sul lato sinistro di qualsiasi altra dipendenza funzionale. Questi sarebbero:

• File -> altro-file-attributi
• GROUP -> altri-gruppo-attributi
• BLOCK -> altri-block-attributi
• Unità -> altre unità-attributi

La costruzione di un insieme di relazioni 3NF da quanto sopra dipendenze funzionali dà:

• FileRelation: ( File , altro-file-attributi)
• GroupRelation: ( GROUP , file , altra-group-attributi)
• UnitRelation: ( UNIT , altre-quote attributi)
• BlockRelation: ( BLOCK , GROUP , Unità , altra-block-attributi)

Questo più o meno corrisponde a quello che hai descritto.

Determinare quali UNIT istanze sono raggruppate in un FILE richiede un join di FileRelation per GroupRelation su File e poi GroupRelation a BlockRelation su GROUP , quindi BlockRelation a UnitRelation su Unità .

Si vuole evitare questo multi-tavolo join con l'inserimento di un nuovo rapporto da qualche parte nel modello che dà una mappatura diretta da Unità a File . Tale relazione un implica la funzionale Dipendenza:

• Unità -> File

Questo appare come il bit aggiunto alla "canti piede" diagramma. L'aggiunta di questo introduce una logica contraddizione. I supporti dello schema originale con un dato Unità in materia di più file le istanze. come in:

• FileRelation (F1, ...)
• FileRelation (F2, ...)
• GroupRelation (G1, F1, ...)
• GroupRelation (G2, F2, ...)
• BlockRelation (B1, G1, U1, ...)
• BlockRelation (B2, G2, U1, ...)
• UnitRelation (U1, ...)

istanza UNIT U1 riferisce ad istanze FILE F1 e F2. Data questa situazione sia il Unità -> File dipendenza funzionale non può essere supportato o la serie originale di dipendenze funzionali erano incomplete e lo schema non è in 3NF.

A questo punto è necessario risolvere se il mondo reale sostiene il File -> Unità dipendenza o no. Se lo fa, allora il modello originale non è in 3NF e un po 'di più rielaborazione dello schema è in ordine. Se la dipendenza non è supportata allora il migliore che si può dire è:

• File , Unità -> non

e il rapporto corrispondente:

• FileUnit: ( File , Unità )

è un de-normalizzazione perché il suo contenuto può essere derivata attraverso tabelle esistenti dipendenze funzionali.

============================================ =====================================

Modifica

In base a una serie di osservazioni fatte a questo ed altre risposte, sembra che:

• Unità -> File

è una vera e propria dipendenza funzionale, la dipendenza funzionale:

• BLOCK -> Unità

anche se non corretto, deve essere ridondante. Credo che l'insieme corretto 3NF di relazioni perquesto modello ora è:

• FileRelation: ( File , altro-file-attributi)
• GroupRelation: ( GROUP , file , altra-group-attributi)
• UnitRelation: ( UNIT , FILE , altre-quote attributi)
• BlockRelation: ( BLOCK , GROUP , altra-block-attributi)

Si noti che il Unità chiave esterna è scesa dal BlockRelation. Questo perché il Unità -> File FD ha reso ridondante. Il ( BLOCK , UNIT ) relazione viene ora formato unendo UnitRelation a FileRelation su FILE poi FileRelation a GroupRelation su File , quindi GroupRelation a BlockRelation su GROUP .

Lo schema originale non era in 3NF a causa del non dichiarato dipendenza funzionale: Unità -> File . L'insieme dei rapporti sopra proposta è in 3NF.

Nota: quando normalizzare uno schema, ogni dipendenza funzionale deve essere indicata in anticipo. Manca si può cambiare l'intero quadro!