Normalizzazione in inglese semplice

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

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

Dì che vai a un colloquio di lavoro e la persona chiede: Spiega il concetto di normalizzazione e come procedere nella progettazione di un database normalizzato.

Quali sono i punti chiave che gli intervistatori stanno cercando?

    Beh, se dovessi spiegarlo a mia moglie sarebbe stato qualcosa del genere:

    L’idea principale è di evitare la duplicazione di grandi dati.

    Diamo un’occhiata a un elenco di persone e al paese da cui provengono. Invece di mantenere il nome del paese che può essere lungo quanto la “Bosnia ed Erzegovina” per ogni persona, abbiamo semplicemente un numero che fa riferimento a una tabella di paesi. Quindi, invece di tenere 100 “Bosnia Erzegovina”, abbiamo 100 # 45. Ora in futuro, come spesso accade nei paesi balcanici, si dividono in due paesi: la Bosnia ed Erzegovina, dovrò cambiarlo solo in un posto. bene, un po ‘.

    Ora, per spiegare 2NF, avrei cambiato l’esempio, e assumiamo che terremo l’elenco dei paesi visitati da ogni persona. Invece di tenere un tavolo come:

    Person CountryVisited AnotherInformation DOB Faruz USA Blah Blah 1/1/2000 Faruz Canada Blah Blah 1/1/2000 

    Avrei creato tre tavoli, una tabella con la lista dei paesi, una tabella con la lista delle persone e un’altra tabella per collegarli entrambi. Ciò mi dà la massima libertà che posso ottenere cambiando le informazioni della persona o le informazioni sul paese. Ciò mi consente di “rimuovere le righe duplicate” come previsto dalla normalizzazione.

    Le relazioni uno-a-molti dovrebbero essere rappresentate come due tabelle separate collegate da una chiave esterna. Se si tenta di inserire una relazione logica uno-a-molti in una singola tabella, si sta violando la normalizzazione che porta a problemi pericolosi.

    Supponi di avere un database dei tuoi amici e dei loro gatti. Dal momento che una persona può avere più di un gatto, abbiamo una relazione uno-a-molti tra 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 straniera per Friends.Id )

    Il progetto di cui sopra è completamente normalizzato e conforms a tutti i livelli noti di normalizzazione.

    Ma dire che avevo cercato di rappresentare le informazioni di cui sopra in una singola 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 disegno che avrei potuto fare se fossi abituato ai fogli Excel ma non ai database relazionali.) Un approccio a tabella singola mi obbliga a ripetere alcune informazioni se voglio che i dati siano coerenti. Il problema con questo disegno è che alcuni fatti, come l’informazione che l’indirizzo di Bob è “The belltower” è ripetuto due volte, che è ridondante, e rende difficile interrogare e modificare i dati e (il peggiore) ansible introdurre incoerenze logiche.

    Per esempio. se Bob si muove, devo assicurarmi di cambiare l’indirizzo in entrambe le righe. Se Bob ottiene un altro gatto, devo essere sicuro di ripetere il nome e l’indirizzo esattamente come digitato nelle altre due righe. Ad esempio, se faccio un refuso nell’indirizzo di Bob in una delle righe, improvvisamente il database ha informazioni incoerenti su dove vive Bob. Il database non normalizzato non può impedire l’introduzione di dati incoerenti e contraddittori, e quindi il database non è affidabile. Questo è chiaramente non accettabile.

    La normalizzazione non può impedirti di inserire dati errati. Ciò che impedisce la normalizzazione è la possibilità di dati incoerenti .

    È importante notare che la normalizzazione dipende dalle decisioni aziendali. Se si dispone di un database clienti e si decide di registrare un solo indirizzo per cliente, la struttura della tabella (#CustomerID, CustomerName, CustomerAddress) va bene. Se tuttavia si decide di consentire a ciascun cliente di registrare più di un indirizzo, la stessa struttura della tabella non viene normalizzata, poiché ora si ha una relazione uno-a-molti tra cliente e indirizzo. Pertanto non si può semplicemente guardare un database per determinare se è normalizzato, bisogna capire il modello di business dietro il database.

    Questo è quello che chiedo agli intervistati:

    Perché non usiamo una singola tabella per un’applicazione invece di usare più tabelle?

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

    Questa non è una spiegazione approfondita, ma un objective della normalizzazione è quello di consentire la crescita senza imbarazzo.

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

    Tuttavia, se ogni utente avrà un numero variabile di numeri di telefono, sarebbe scomodo avere colonne come phonenumber1 , phonenumber2 , ecc. Ciò è dovuto a due motivi:

    • Se le colonne salgono a phonenumber3 e qualcuno deve aggiungere un quarto numero, devi aggiungere una colonna alla tabella.
    • Per tutti gli utenti con meno di 3 numeri di telefono, ci sono colonne vuote sulle loro righe.

    Invece, si vorrebbe avere una tabella dei phonenumber telefono, in cui ogni riga contiene un numero di telefono e una chiave esterna di riferimento a quale riga nella tabella user cui appartiene. Non sono necessarie colonne vuote e ogni utente può avere il numero minimo o il numero di telefono necessario.

    Un punto da notare sulla normalizzazione: un database completamente normalizzato è efficiente in termini di spazio , ma non è necessariamente la disposizione dei dati più efficiente in termini di tempo in base ai modelli di utilizzo.

    Saltare attorno a più tavoli per cercare tutte le informazioni dalle loro posizioni denormalizzate richiede tempo. In situazioni di carico elevato (milioni di file al secondo in movimento, migliaia di client concorrenti, come ad esempio l’elaborazione delle transazioni con carta di credito) dove il tempo è più prezioso dello spazio di archiviazione, le tabelle denormalizzate in modo appropriato possono offrire tempi di risposta migliori rispetto alle tabelle completamente normalizzate.

    Per maggiori informazioni su questo, cerca i libri SQL scritti da Ken Henderson.

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

    Se avessi una nota che diceva che dovevi andare a fare la spesa per il gelato senza normalizzazione, avresti quindi un altro appunto, dicendo che devi andare a fare shopping per un gelato, solo uno per ogni tasca.

    Ora, nella vita reale, non lo faresti mai, quindi perché farlo in un database?

    Per la parte di progettazione e implementazione, questo è il momento in cui è ansible tornare al “gergo” e tenerlo lontano da termini generici, ma suppongo che tu possa semplificare. In un primo momento diresti ciò di cui avevi bisogno, e poi quando arriva la normalizzazione, dici che assicurerai quanto segue:

    1. Non ci devono essere gruppi ripetuti di informazioni all’interno di una tabella
    2. Nessuna tabella deve contenere dati che non dipendono funzionalmente dalla chiave primaria di tali tabelle
    3. Per 3NF mi piace l’interpretazione di Bill Kent: Ogni attributo non chiave deve fornire un dato sulla chiave, l’intera chiave e nient’altro che la chiave.

    Penso che potrebbe essere più impressionante se parli di denormalizzazione, e il fatto che non puoi sempre avere la struttura migliore E essere in forms normali.

    La normalizzazione è un insieme di regole utilizzate per progettare tabelle collegate tramite relazioni.

    Aiuta a evitare le voci ripetitive, riducendo lo spazio di archiviazione richiesto, impedendo la necessità di ristrutturare le tabelle esistenti per accogliere nuovi dati, aumentando la velocità delle query.

    Prima forma normale: i dati devono essere suddivisi nelle unità più piccole. Le tabelle non dovrebbero contenere gruppi ripetitivi di colonne. Ogni riga è identificata con una o più chiavi primarie. Ad esempio, c’è una colonna denominata “Nome” in una tabella “Personalizzata”, dovrebbe essere suddivisa in “Nome” e “Cognome”. Inoltre, “Personalizzato” dovrebbe avere una colonna denominata “CustiomID” per identificare una particolare abitudine.

    Secondo modulo normale: ogni colonna non chiave deve essere direttamente correlata all’intera chiave primaria. Ad esempio, se una tabella ‘Personalizzata’ ha una colonna denominata ‘Città’, la città dovrebbe avere una tabella separata con la chiave primaria e il nome della città definiti, nella tabella ‘Personalizzata’, sostituire la colonna ‘Città’ con ‘CityID’ e rendere ‘CityID’ la chiave straniera nel racconto.

    Terza forma normale: ogni colonna non chiave non dovrebbe dipendere da altre colonne non chiave. Ad esempio, in una tabella degli ordini, la colonna “Totale” dipende da “Prezzo unitario” e “quantità”, quindi la colonna “Totale” deve essere rimossa.

    Insegno alla normalizzazione nei miei corsi di accesso e lo analizzo in vari modi.

    Dopo aver discusso i precursori dello storyboarding o di aver progettato il database, ho quindi approfondito la normalizzazione. Spiego le regole in questo modo:

    Ogni campo dovrebbe contenere il più piccolo valore significativo:

    Scrivo un campo nome sulla lavagna e poi posto un nome e cognome come Bill Lumbergh. Quindi interrogiamo gli studenti e chiediamo loro cosa avremo problemi, quando il nome e il cognome sono tutti in un campo. Uso il mio nome come esempio, che è Jim Richards. Se gli studenti non mi guidano lungo la strada, allora li afferro e li porto con me. 🙂 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 stai 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. Dico anche loro che avranno problemi nel selezionare facilmente il campo per cognome, perché di nuovo il mio cognome è sepolto alla fine.

    Poi faccio loro sapere che il significato è basato sul pubblico che sta per usare anche il database. Noi, al nostro lavoro, non avremo bisogno di un campo separato per il numero di appartamento o suite se stiamo memorizzando gli indirizzi delle persone, ma le compagnie di spedizioni come UPS o FEDEX potrebbero aver bisogno di separarle per tirare facilmente l’appartamento o la suite di dove devono andare quando sono sulla strada e vanno dalla consegna alla consegna. Quindi non è significativo per noi, ma è decisamente significativo per loro.

    Evitare spazi vuoti:

    Uso un’analogia per spiegare loro perché dovrebbero evitare gli spazi vuoti. Dico loro che Access e la maggior parte dei database non memorizzano spazi vuoti come fa Excel. A Excel non interessa se non hai digitato nulla nella cella e non aumenterai le dimensioni del file, ma Access riserverà quello spazio fino a quel momento in cui utilizzerai effettivamente il campo. Quindi, anche se è vuoto, continuerà a utilizzare lo spazio e spiegherà loro che rallenta anche le ricerche.
    L’analogia che uso è scatole di scarpe vuote nell’armadio. Se hai delle scatole da scarpe nell’armadio e stai cercando un paio di scarpe, dovrai aprire e guardare in ognuna delle scatole un paio di scarpe. Se ci sono scatole di scarpe vuote, allora stai solo sprecando spazio nell’armadio e perdi anche tempo quando hai bisogno di guardarle attraverso per quel determinato paio di scarpe.

    Evitare la ridondanza nei dati:

    Io mostro loro una tabella che ha molti valori ripetuti per le informazioni sui clienti e poi dire loro che vogliamo evitare i duplicati, perché ho le dita salsicce e scriverò male nei valori se devo digitare la stessa cosa più e più volte. Questa “fat-fingering” di dati porterà alle mie domande a non trovare i dati corretti. Noi, invece, suddivideremo i dati in una tabella separata e creeremo una relazione utilizzando un campo chiave primario e esterno. In questo modo stiamo risparmiando spazio perché non stiamo scrivendo più volte il nome, l’indirizzo, il nome del cliente, ecc., Ma stiamo semplicemente usando il numero ID del cliente in un campo per il cliente. Discuteremo poi di elenchi a discesa / caselle combinate / elenchi di ricerca o qualsiasi altra cosa Microsoft voglia nominarli in seguito. 🙂 Come utente non vorrai cercare e digitare il numero del cliente ogni volta in quel campo cliente, quindi configureremo un elenco a discesa che ti darà un elenco di clienti, dove puoi selezionare il loro nome e riempirà l’ID del cliente per te. Questa sarà una relazione 1-a-molti, mentre 1 cliente avrà molti ordini diversi.

    Evitare gruppi ripetuti di campi:

    Lo dimostro quando parlo di relazioni molti-a-molti. Innanzitutto, disegno 2 tabelle, 1 che conserverà le informazioni sui dipendenti e 1 che conserverà le informazioni sul progetto. I tavoli sono disposti in modo 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 per stabilire una relazione tra un dipendente e tutti i progetti su cui lavorano. Innanzitutto, se abbiamo un nuovo dipendente, allora non avranno progetti, quindi sprecheremo tutti questi campi, in secondo luogo se un dipendente è qui da molto tempo, allora avrebbero potuto lavorare su 300 progetti, quindi avremmo per includere 300 campi di progetto. Quelle persone che sono nuove e hanno solo 1 progetto avranno 299 campi di progetto sprecati. Questo design è anche imperfetto perché dovrò cercare in ognuno dei campi del progetto per trovare tutte le persone che hanno lavorato su un determinato progetto, perché quel numero di progetto potrebbe trovarsi in uno qualsiasi dei campi del progetto.

    Ho coperto una buona parte dei concetti di base. Fatemi sapere se avete altre domande o avete bisogno di aiuto con la precisazione / scomposizione in inglese. La pagina wiki non ha letto un inglese semplice e potrebbe essere scoraggiante per alcuni.

    Ho letto i collegamenti wiki sulla normalizzazione molte volte ma ho trovato una migliore panoramica sulla normalizzazione da questo articolo . È una spiegazione semplice e semplice della normalizzazione fino alla quarta forma normale. Dagli una lettura!

    Anteprima:

    Cos’è la normalizzazione?

    La normalizzazione è il processo di organizzazione efficiente dei dati in un database. Esistono due obiettivi del processo di normalizzazione: eliminazione dei dati ridondanti (ad esempio, memorizzazione degli stessi dati in più di una tabella) e garanzia delle dipendenze dei dati (solo memorizzazione dei dati correlati in una tabella). Entrambi questi sono obiettivi degni di nota in quanto riducono la quantità di spazio che un database consuma e garantiscono che i dati siano archiviati logicamente.

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

    La normalizzazione del database è un processo formale di progettazione del database per eliminare i dati ridondanti. Il design è composto da:

    • pianificazione delle informazioni che il database memorizzerà
    • delineando quali informazioni saranno richieste dagli utenti
    • documentando le ipotesi per la revisione

    Utilizzare un dizionario dati o un’altra rappresentazione di metadati per verificare il progetto.

    Il problema più grande con la normalizzazione è che si finisce con più tabelle che rappresentano concettualmente un singolo elemento, come un profilo utente. Non preoccuparti di normalizzare i dati nella tabella in cui verranno inseriti record ma non aggiornati, come i registri della cronologia o le transazioni finanziarie.

    Riferimenti

    • Quando non normalizzare il database SQL

    • Nozioni di base sul database

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

    ma…

    Per aggiungere a questa conversazione, c’è l’altro lato della medaglia (che può essere importante in una intervista).

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

    Quando in un database veramente normalizzato, ho trovato che in situazioni è stato più facile scrivere query lente a causa di operazioni di join non valide, indicizzazione errata sulle tabelle e progettazione non corretta delle tabelle stesse.

    Senza mezzi termini, è più facile scrivere query non valide in tabelle normalizzate di alto livello.

    Penso che per ogni applicazione ci sia una via di mezzo. Ad un certo punto si desidera la facilità di estrarre tutto da qualche tabella, senza dover unirsi a una tonnellata di tabelle per ottenere un set di dati.