Domanda

Qual è un modo KISS (Keep it Simple, Stupid) per ricordare cos'è la forma normale di Boyce-Codd e come prendere una tabella non normalizzata e BCNF?

Wikipediale informazioni:non molto utile per me.

È stato utile?

Soluzione

La definizione di Chris Date è in realtà abbastanza buona, a patto che si capisce cosa vuol dire:

Ogni attributo

per i dati devono essere suddivisi in distinti attributi / colonne / valori distinti, che non dipendono da altri attributi. Il suo nome completo è un attributo. La vostra data di nascita è un attributo. La tua età non è un attributo, dipende dalla data corrente, che non fa parte della tua data di nascita.

deve rappresentare un fatto

Ogni attributo è un fatto singolo, non un insieme di fatti. Cambiare un bit in un attributo cambia l'intero significato. La vostra data di nascita è un dato di fatto. È il vostro nome e cognome un dato di fatto? Ebbene, in alcuni casi lo è, perché se si cambia il cognome tuo nome completo è diverso, giusto? Ma per un genealogista di avere un cognome e un nome di famiglia, e se si cambia il cognome il tuo nome di famiglia non cambia, in modo che siano fatti separati.

sulla chiave,

Un attributo è speciale, è una chiave. La chiave è un attributo che deve essere unico per tutte le informazioni in dati e non deve mai cambiare. Il tuo nome completo non è una chiave, perché può cambiare. Il tuo numero di assicurazione sociale non è una chiave perché vengono riutilizzati. Lo SSN più data di nascita non è una chiave, anche se la combinazione non può mai essere riutilizzato, perché un attributo non può essere una combinazione di due fatti. Un GUID è una chiave. Un certo numero si incrementa e mai riutilizzare è una chiave.

la chiave di tutto,

La chiave da sola deve essere sufficiente [ e necessaria !] Per identificare i vostri valori; non si può avere gli stessi dati rappresentati da chiavi diverse, né un sottoinsieme delle colonne chiave essere sufficienti a identificare il fatto. Supponete di avere una rubrica con una chiave GUID, il nome e valori di indirizzo. E 'OK per avere lo stesso nome che compare due volte con chiavi diverse, se essi rappresentano persone diverse e non sono gli "stessi dati". Se Mary Jones in contabilità cambia il suo nome a Maria Smith, Mary Jones in vendite non cambia il suo nome pure. D'altra parte, se Maria Smith e John Smith hanno lo stesso indirizzo ed è veramente nello stesso posto, questo non è permesso. È necessario creare una nuova coppia chiave / valore con l'indirizzo e una nuova chiave.

Si sono anche non ha permesso di utilizzare la chiave di questo nuovo indirizzo sola strada come un valore nella rubrica dal momento che ora la stessa chiave di indirizzo sarebbe rappresentato due volte. Invece, si deve fare una coppia di terze chiave / valore con i valori della chiave rubrica e il tasto di indirizzo; a trovare indirizzo di una persona facendo corrispondere loro chiave libro e chiave indirizzo in questo gruppo di valori.

e nient'altro che la chiave

Ci deve essere altro che la chiave che identifica i vostri valori. Ad esempio, se si è permesso un indirizzo di "The Taj Mahal" (presumere che vi sia una sola) non è consentito un valore della città nello stesso record, poiché se si conosce l'indirizzo si dovrebbe anche conoscere la città. Questo sarebbe anche aprire la possibilità che vi sia più di un Taj Mahal in una città diversa. Invece, è necessario creare di nuovo una chiave Località secondario con valori unici come il Taj, la Casa Bianca a Washington, e così via, e le loro città. O proibire "indirizzi" che sono unici per una città.

Così mi aiuti, Codd.

Altri suggerimenti

Ecco alcuni estratti utile dalla pagina di Wikipedia su terza forma normale :

Bill Kent definisce terza forma normale in questo modo:

  

Ogni attributo non chiave "deve fornire   un fatto che riguarda la chiave, la chiave di tutto,   e nient'altro che la chiave ".

     

che richiede che gli attributi non chiave siano   dipendente "interi chiave" assicura   che una tabella è in 2NF; ulteriore   richiedendo che gli attributi non chiave siano   dipende "nient'altro che la chiave"   assicura che la tabella è in 3NF.

Chris Date adatta mnemonico di Kent per definire Boyce-Codd Normal Form:

  

"Ogni attributo deve rappresentare un dato di fatto   sulla chiave, la chiave di tutta la, e   nient'altro che la chiave." Qui il   requisito si occupa di ogni   attributo nella tabella, non solo   attributi non chiave.

Questo entra in gioco quando una tabella ha più chiavi composti candidati, e un attributo all'interno di tasti di un candidato ha una dipendenza da un parte di un'altra chiave candidata. Terza forma normale non vieterebbe questo, perché esclude gli attributi chiave. Ma BCNF applica la regola di attributi chiave pure.

Per quanto riguarda come fare un tavolo soddisfare BCNF, è necessario rappresentare la dipendenza in più, con un altro attributo e, eventualmente, dividendosi attributi in un'altra tabella.

Ho cercato su google "Boyce Codd forma normale" e dopo wikipedia questo è il secondo risultato. Il mio libro di testo dà una definizione molto semplice in termini di sistemi di gestione di database relazionali:

  

La parte sinistra di ogni banale FD deve essere una superchiave.

-. "Database Systems The Complete Book" di Garcia-Molina, Ullman e Widom

La migliore risposta informale che ho letto è che, in BCNF, ogni "freccia" in ogni dipendenza funzionale è un "freccia" di una chiave candidata. Non ricordo la fonte, ma era probabilmente qualcosa Chris Data ha scritto.

Fondamentalmente Boyce-Codd è la "quinta forma normale".È visivamente riconoscibile dall'esistenza di "entità attributive" nel modello dati, per cose come Tipi (ad es.ruoli, stato, stato del processo, tipo di posizione, tipo di telefono, ecc.).Le entità attributive (sottotipi) sono elenchi di insiemi finiti di valori che classificano ulteriormente un'entità a livello di classe.Quindi potresti avere un tipo di telefono ("mobile", "scrivania", "VOIP"), un tipo di account e-mail ("business", "personale", "gioco"), un ruolo (responsabile di progetto, modellatore di dati, super modello) ecc. .Un altro indizio morfologico è l'esistenza di supertipi, (aka.masterclass, superclassi, metaentità) come i Party (sottotipi azienda, persona, ecc.).

Fondamentalmente è una tassonomia impazzita (..no, il video non è così entusiasmante) a livello atomico o fogliare;vedere il commento di Bill Karwin sopra per una spiegazione più tecnica.

I modelli di livello Boyce-Codd sono essenzialmente modelli logici altamente dettagliati, derivati ​​da modelli concettuali più semplicistici basati sul business.**In genere NON sono implementati alla lettera nel modello FISICO, poiché l'ottimizzazione PDM per le prestazioni (o la semplicità funzionale) può comportare la gestione dei supertipi e delle entità attributive come elenchi a discesa nelle interfacce utente o nella logica dietro le quinte nell'applicazione o nei vincoli e nei metodi del database per garantire l'integrità referenziale.(cioè.potrebbero finire come tabelle di ricerca nello schema PDM oppure potrebbero essere gestiti da codice e non rappresentati nel database).

Allora perché farlo se rischiano di non finire nel PDM?Per lo stesso motivo per cui costruisci un buon modello 3NF prima di "ottimizzarlo", in modo che la struttura del database rifletta il mondo reale e sia quindi più stabile dei tipici errori che ereditiamo e che dobbiamo compiere atti eroici per far funzionare la nostra azienda/cliente. i requisiti cambiano.

Spesso è più facile ascoltare il vostro intestino e questo verrà naturalmente. In generale, se si incontra 3NF hai incontrato BCNF. Ciò non comprendono l'analisi dettagliata di un disco di ripristino o di avere esempi, ma ci sono tredici regole secondo Codd. Trovo meglio seguire queste regole, ma ricordo sempre non esiste un modo corretto di fare le cose in modo da seguirli senza stringere. Quindi per quanto riguarda il RDBMS, ecco le regole:

http://www.87android.com / 12-regole-di-relazionale-Database-modello-by-Codd /

Questo non può rispondere alla domanda direttamente, ma se ti stai chiedendo su come arrivare a BCNF o un modo semplice per ricordare allora non si capisce la normalizzazione abbastanza bene. Questo è di nessuna preoccupazione però. I database relazionali assumere molte forme e molto pochi sono fatte bene. La cosa migliore che puoi fare è sapere che cosa vuol dire essere relazionale, seguire le regole di cui sopra, e non doversi preoccupare del livello di normalizzazione. Il processo di normalizzazione elimina la duplicazione dei dati. Ogni livello più spostando in migrazione di dipendenze funzionali. Tenete a mente e vi andrà bene, il vostro intestino e l'intelletto faranno il resto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top