Normalizzazione in inglese semplice

https://stackoverflow.com/questions/2331838

22-09-2019
|

Domanda

Capisco il concetto di normalizzazione del database, ma ho sempre difficoltà a spiegarlo in un inglese semplice, soprattutto per un colloquio di lavoro.Ho letto il Wikipedia post, ma trovo ancora difficile spiegare il concetto ai non sviluppatori."Progettare un database in modo da non ottenere dati duplicati" è la prima cosa che mi viene in mente.

Qualcuno ha un modo carino per spiegare il concetto di normalizzazione del database in un inglese semplice?E quali sono alcuni esempi interessanti per mostrare le differenze tra la prima, la seconda e la terza forma normale?

Supponiamo che tu vada a un colloquio di lavoro e la persona chieda: Spiegare il concetto di normalizzazione e come si potrebbe progettare un database normalizzato.

Quali punti chiave stanno cercando gli intervistatori?

Soluzione

Beh, se dovessi spiegarlo a mia moglie che sarebbe stato qualcosa di simile:

L'idea principale è quella di evitare la duplicazione di dati di grandi dimensioni.

Diamo uno sguardo a una lista di persone e il paese di provenienza. Invece di tenere il nome del paese, che può essere fino a quando "Bosnia-Erzegovina" per ogni persona, abbiamo semplicemente tenere un numero che fa riferimento a una tabella di paesi. Così, invece di tenere 100 s "Bosnia ed Erzegovina", teniamo 100 # 45. Ora, nel futuro, come spesso accade con i paesi dei Balcani, si dividono a due paesi: Bosnia-Erzegovina, dovrò cambiarlo solo in un posto. bene, più o meno.

Ora, per spiegare 2NF, avrei cambiato l'esempio, e supponiamo che teniamo l'elenco dei paesi visitati ogni persona. Invece di tenere una tabella come:

Person   CountryVisited   AnotherInformation   D.O.B.
Faruz    USA              Blah Blah            1/1/2000
Faruz    Canada           Blah Blah            1/1/2000

avrei creato tre tabelle, una tabella con l'elenco dei paesi, una tabella con l'elenco delle persone e un altro tavolo per collegarli entrambi. Questo mi dà la massima libertà posso ottenere modifica delle informazioni o di un paese le informazioni della persona. Questo mi permette di "rimuovere le righe duplicate", come la normalizzazione si aspetta.

Altri suggerimenti

uno-a-molti dovrebbero essere rappresentati come due tavoli separati, collegati tramite una chiave esterna. Se si tenta di spingere una relazione logica uno-a-molti in un'unica tabella, allora si stanno violando la normalizzazione, che porta a problemi pericolosi.

Diciamo che avete un database dei vostri amici e dei loro gatti. Dal momento che una persona può avere più di un gatto, abbiamo una relazione uno-a-molti tra le persone e gatti. Ciò richiede due tabelle:

Friends
Id | Name | Address
-------------------------
1  | John | The Road 1
2  | Bob  | The Belltower


Cats
Id | Name   | OwnerId 
---------------------
1  | Kitty  | 1
2  | Edgar  | 2
3  | Howard | 2

(Cats.OwnerId è una chiave esterna per Friends.Id)

Il disegno sopra è completamente normalizzata e conforme a tutti i livelli di normalizzazione conosciuti.

Ma dico io avevo cercato di rappresentare le informazioni di cui sopra in una sola tabella come questa:

Friends and cats
Id | Name | Address       | CatName
-----------------------------------
1  | John | The Road 1    | Kitty     
2  | Bob  | The Belltower | Edgar  
3  | Bob  | The Belltower | Howard

(Questo è il tipo di design che potrei aver fatto se ero abituato a Excel schede tecniche, ma non database relazionali.) Un approccio a tavolo singolo mi costringe a ripetere alcune informazioni se voglio i dati siano coerenti. Il problema di questo progetto è che alcuni fatti, come le informazioni che l'indirizzo di Bob è "Il campanile" si ripete due volte, che è ridondante, e rende difficile per interrogare e modificare i dati e (il peggiore) possibile introdurre incoerenze logiche.

Eg. se Bob si muove devo essere sicuro di cambiare l'indirizzo in sia righe. Se Bob ottiene un altro gatto, devo essere sicuri di ripetere il nome e l'indirizzo esattamente come digitato nelle altre due righe. Per esempio. se faccio un errore di battitura nel discorso di Bob in una delle righe, improvvisamente il database ha informazioni incoerenti su dove vive Bob. Il database non normalizzata non può impedire l'introduzione di dati incoerenti e contraddittorie, e quindi il database non è affidabile. Questo chiaramente non è accettabile.

La normalizzazione non si può impedire di entrare dati sbagliati. Ciò impedisce la normalizzazione è la possibilità di dati incoerenti .

E 'importante notare che la normalizzazione dipende da decisioni aziendali. Se si dispone di un database di clienti, e si decide di registrare solo un singolo indirizzo per cliente, quindi il disegno (#CustomerID, CustomerName, CustomerAddress) tavolo va bene. Se invece si decide che si consente ad ogni cliente di registrare più di un indirizzo, quindi la stessa struttura della tabella non è normalizzata, perché ora avete una relazione uno-a-molti tra il cliente e l'indirizzo. Pertanto non si può semplicemente guardare un database per determinare se è normalizzata, è necessario capire il modello di business dietro il database.

Questo è quello che chiedo intervistati:

Perché non si usa un singola Tavolo per un'applicazione invece di utilizzare più le tabelle?

La risposta è naturalmente la normalizzazione. Come già detto, la sua per evitare ridondanza e là da anomalie di aggiornamento.

Questa non è una spiegazione completa, ma un obiettivo di normalizzazione è quello di consentire la crescita, senza imbarazzo.

Ad esempio, se hai un tavolo user, e ogni utente avrà uno e un solo numero di telefono, è bene avere una colonna phonenumber in tale tabella.

Tuttavia, se ogni utente sta per avere un numero variabile di numeri di telefono, sarebbe imbarazzante avere colonne come phonenumber1, phonenumber2, ecc Questo per due motivi:

Se le colonne andare fino a phonenumber3 e qualcuno ha bisogno di aggiungere un quarto numero, è necessario aggiungere una colonna alla tabella.
Per tutti gli utenti con meno di 3 numeri di telefono, ci sono le colonne vuote sul loro file.

Al contrario, ci si vuole avere un tavolo phonenumber, in cui ogni riga contiene un numero di telefono e un riferimento di chiave esterna a cui riga della tabella user a cui appartiene. Non sono necessari colonne vuote, e ogni utente può avere come pochi o molti numeri di telefono, se necessario.

Un punto lato da notare su normalizzazione: un database completamente normalizzato è spazio efficiente, ma non è necessariamente il più tempo efficiente disposizione dei dati a seconda modelli di consumo.

Saltare intorno a più tavoli per cercare tutti i pezzi di informazioni dalle loro posizioni denormalizzati richiede tempo. In situazioni di carico elevato (milioni di righe al secondo volano intorno, migliaia di clienti simultanei, come dire carta di credito l'elaborazione delle transazioni) in cui il tempo è più prezioso di spazio di archiviazione, tavoli opportunamente denormalizzati può dare tempi di risposta migliori rispetto tavoli completamente normalizzati.

Per ulteriori informazioni, cercare libri scritti da SQL Ken Henderson.

Direi che la normalizzazione è come tenere le note di fare le cose in modo efficiente, per così dire:

Se si ha una nota che ha detto che doveva   andare a fare shopping per il gelato senza   la normalizzazione, si dovrebbe quindi avere   un'altra nota, dicendo che deve andare   lo shopping per il gelato, solo uno su   ogni tasca.

Ora, nella vita reale, si sarebbe mai fare   questo, quindi perché farlo in un database?

Per la progettazione e la parte di attuazione, thats quando si può tornare a "il gergo" e tenerlo lontano da termini profani, ma suppongo che si possa semplificare. Si potrebbe dire che cosa si doveva in un primo momento, e poi, quando la normalizzazione entra in esso, dite che vi assicurarsi di quanto segue:

Non ci devono essere gruppi ripetuti di informazioni all'interno di una tabella
Nessuna tabella deve contenere dati che non è funzionalmente dipendente da quella chiave tavoli primaria
Per 3NF mi piace prendere di Bill Kent su di esso: ogni attributo non chiave deve fornire un fatto che riguarda la chiave, la chiave di tutta la, e nient'altro che la chiave

Penso che possa essere più impressionante se si parla di denormalizzazione pure, e il fatto che non si può sempre avere la migliore struttura e di essere in forme normali.

La normalizzazione è un insieme di regole che ha usato per progettare le tabelle che collegavano attraverso le relazioni.

E 'aiuta ad evitare voci ripetitive, riducendo lo spazio di archiviazione necessario, evitando la necessità di ristrutturare le tabelle esistenti per accogliere i nuovi dati, aumentando la velocità di query.

prima forma normale: I dati dovrebbero essere suddiviso in unità più piccole. Le tabelle non devono contenere gruppi ripetuti di colonne. Ogni riga è identificata con uno o più chiave primaria. Ad esempio, v'è una colonna denominata 'Nome' nella tabella un 'personalizzato', dovrebbe essere rotto per 'Nome' e 'cognome'. Inoltre, 'Custom' dovrebbe avere una colonna denominata 'CustiomID' per identificare un particolare personalizzato.

Seconda forma normale: Ogni colonna non chiave deve essere direttamente collegato a tutta la chiave primaria. Ad esempio, se la tabella di un 'personalizzato' ha una colonna denominata 'City', la città dovrebbe ha un tavolo separato con chiave primaria e nome definito, nella tabella 'Personalizzato', sostituire la colonna 'City' con 'cityID' e fare 'cityID' la chiave esterna nel racconto.

Terza forma normale: Ogni colonna non chiave non dovrebbe dipendere da altre colonne non chiave. Ad esempio, in una tabella di ordine, la colonna 'Total' dipende 'unitario' e 'quantita', per cui la colonna 'Total' dovrebbe essere rimosso.

Io insegno la normalizzazione nei miei corsi di accesso e scomposizione alcuni modi.

Dopo aver discusso i precursori di storyboarding o pianificazione fuori il database, ho poi scavare nella normalizzazione. Spiego le regole in questo modo:

Ogni campo dovrebbe contenere il più piccolo valore significativo:

Scrivo un campo nome sulla scheda e quindi inserire un nome e cognome in esso come Bill Lumbergh. Abbiamo poi interrogare gli studenti e chiedere loro che cosa avremo problemi con, quando il nome e il cognome sono tutti in un campo. Io uso il mio nome come esempio, che è Jim Richards. Se gli studenti non mi portano lungo la strada, poi ho Yank la loro mano e li porto con me. :) Io dico loro che il mio nome è un nome difficile per alcuni, perché ho quello che alcune persone considererebbero 2 nomi e alcune persone mi chiamano Richard. Se stavi cercando di cercare il mio cognome allora sarà più difficile per una persona normale (senza caratteri jolly), perché il mio cognome è sepolto alla fine del campo. Ho anche dire loro che avranno problemi con l'ordinamento facilmente il campo in base al cognome, perché ancora una volta il mio cognome è sepolto alla fine.

Ho poi far loro sapere che significato si basa sul pubblico che sta per essere utilizzando il database. Noi, al nostro lavoro, non avremo bisogno di un campo separato per l'appartamento o suite numero se abbiamo memorizzato gli indirizzi delle persone, ma le compagnie di navigazione come UPS o FEDEX potremmo averne bisogno separato fuori per tirare facilmente l'appartamento o suite di cui hanno bisogno per andare quando sono sulla strada e correre dalla consegna alla consegna. Quindi non è significativo per noi, ma è decisamente significativo per loro.

Evitare spazi vuoti:

Io uso un'analogia per spiegare loro il motivo per cui essi dovrebbero evitare spazi vuoti. Dico loro che Access e maggior parte dei database non conservare gli spazi come Excel fa. Excel non importa se non hai niente digitato nella cella e non aumenterà la dimensione del file, ma l'accesso riserverà quello spazio fino a quel punto nel tempo che effettivamente utilizzare il campo. Quindi, anche se è vuoto, allora sarà ancora utilizzando lo spazio e spiegare loro che rallenta anche le loro ricerche verso il basso pure.
L'analogia che uso è contenitori di pattino vuoto nell'armadio. Se si dispone di scatole di scarpe nell'armadio e siete alla ricerca di un paio di scarpe, è necessario aprire e guardare in ciascuna delle scatole per un paio di scarpe. Se ci sono scatole di scarpe vuote, poi si sono solo sprecare spazio nell'armadio e anche perdere tempo quando si ha bisogno di guardare attraverso di loro per quel certo paio di scarpe.

Come evitare la ridondanza dei dati:

I mostrare loro una tabella che ha un sacco di valori ripetuti per informazioni sui clienti e poi dire loro che vogliamo evitare duplicati, perché ho le dita salsiccia e sarà mistype nei valori se devo digitare la stessa cosa più e più volte ancora. Questo “grasso-diteggiatura” dei dati porterà alle mie domande non trovare i dati corretti. Noi, invece, romperemo i dati fuori in una tabella separata e creare un rapporto utilizzando un campo chiave primaria e stranieri. In questo modo stiamo salvando spazio, perché non stiamo digitando il nome del cliente, indirizzo, ecc più volte e invece sono solo utilizzando il numero ID del cliente in un campo per il cliente. Abbiamo poi discuteremo elenchi a discesa / caselle combinate / liste di ricerca o qualsiasi altra cosa Microsoft vuole nominare loro in seguito. :) È come un utente non vuole guardare in alto e digitare il numero del cliente ogni volta che in quel campo cliente, quindi dovremo impostare un elenco a discesa che vi darà una lista di clienti, dove è possibile selezionare il loro nome e si riempirà ID del cliente per voi. Questo sarà un rapporto di 1-a-molti, mentre 1 cliente avrà molti ordini differenti.

Evitare gruppi ripetuti di campi:

dimostro questo quando si parla di molti-a-molti. In primo luogo, vorrei richiamare 2 tavoli, 1 che conterrà informazioni sui dipendenti e 1 °al conterrà le informazioni sul progetto. I tavoli sono disposti simile a questo.

(Table1)
tblEmployees
* EmployeeID
First
Last
(Other Fields)….
Project1
Project2
Project3
Etc.
**********************************
(Table2)
tblProjects
* ProjectNum
ProjectName
StartDate
EndDate
…..

Spiego loro che questo non sarebbe un buon modo di stabilire una relazione tra un dipendente e tutti i progetti che lavorano su. In primo luogo, se abbiamo un nuovo dipendente, allora essi non hanno alcun progetto, in modo che saranno sprecare tutti quei campi, secondo, se un dipendente è stato qui da molto tempo, allora si potrebbe hanno lavorato su 300 progetti, così avremmo per includere 300 campi di progetto. Coloro che sono nuovi e hanno solo 1 progetto avranno 299 campi di progetto sprecati. Questo progetto è anche viziata perché dovrò cercare in ciascuno dei campi di progetto per trovare tutte le persone che hanno lavorato su un determinato progetto, perché questo numero di progetto potrebbe essere in uno qualsiasi dei campi del progetto.

Ho coperto una discreta quantità dei concetti di base. Fatemi sapere se avete altre domande o bisogno di aiuto con clarfication / scomponendola in parole povere. La pagina wiki non ha letto come un inglese semplice e potrebbe essere scoraggiante per alcuni.

Ho letto i link wiki sulla normalizzazione molte volte, ma ho trovato una migliore visione di normalizzazione da questo articolo . Si tratta di un semplice facile da capire spiegazione della normalizzazione fino a quarta forma normale. Dategli una lettura!

Anteprima:

Che cos'è la normalizzazione?

La normalizzazione è il processo di organizzare in modo efficiente i dati in un Banca dati. Ci sono due obiettivi del processo di normalizzazione: eliminazione dati ridondanti (ad esempio, la memorizzazione gli stessi dati in più di una tabella) e assicurando dipendenze dei dati fanno senso (solo la memorizzazione dei dati relativi a un tavolo). Entrambi questi sono obiettivi meritevoli in quanto riducono la quantità di spazio a banca dati consuma e garantire che i dati è logico memorizzato.

http://databases.about.com/od/specificproducts/a /normalization.htm

la normalizzazione del database è un processo formale di progettare il vostro database per eliminare i dati ridondanti. Il progetto è composto da:

le informazioni di pianificazione nel database memorizzerà
che delinea ciò che gli utenti le informazioni sarà richiesta da esso
documentare i presupposti per la revisione

'data-dictionary'" o qualche altra rappresentazione dei metadati per verificare il progetto.

Il problema più grande con la normalizzazione è che si finisce con più tabelle rappresentano ciò che è concettualmente un singolo elemento, come ad esempio un profilo utente. Non preoccupatevi di normalizzare i dati nella tabella che avranno record inseriti, ma non aggiornati, come i registri di storia o le transazioni finanziarie.

Riferimenti

+1 per l'analogia di parlare con tua moglie.Trovo che parlare con chiunque non abbia una mente tecnologica abbia bisogno di una certa facilità in questo tipo di conversazione.

Ma...

Da aggiungere a questa conversazione c’è l’altro lato della medaglia (che può essere importante durante un’intervista).

Durante la normalizzazione, è necessario osservare come vengono indicizzati i database e come vengono scritte le query.

In un database veramente normalizzato, ho scoperto che in situazioni è più semplice scrivere query lente a causa di operazioni di join errate, indicizzazione errata sulle tabelle e semplice progettazione errata delle tabelle stesse.

Senza mezzi termini, è più semplice scrivere query errate in tabelle normalizzate di alto livello.

Penso che per ogni applicazione ci sia una via di mezzo.Ad un certo punto vuoi la facilità di estrarre tutto da poche tabelle, senza dover unirti a un sacco di tabelle per ottenere un set di dati.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow