Skip to main content

Mettere un database in Second Normal Form (2NF)

Advisory Council Meeting, 25 September 2014, Paris (Potrebbe 2024)

Advisory Council Meeting, 25 September 2014, Paris (Potrebbe 2024)
Anonim

Abbiamo esaminato diversi aspetti della normalizzazione di una tabella di database. Innanzitutto, abbiamo discusso i principi di base della normalizzazione del database. L'ultima volta, abbiamo esplorato i requisiti di base stabiliti dalla prima forma normale (1NF). Ora, continuiamo il nostro viaggio e copriamo i principi della seconda forma normale (2NF).

I requisiti generali di 2NF

  • Rimuovi sottoinsiemi di dati che si applicano a più righe di una tabella e inseriscili in tabelle separate.
  • Creare relazioni tra queste nuove tabelle e i loro predecessori attraverso l'uso di chiavi esterne.

Queste regole possono essere riassunte in una semplice dichiarazione: 2NF tenta di ridurre la quantità di dati ridondanti in una tabella estraendoli, inserendoli in nuove tabelle e creando relazioni tra queste tabelle.

Diamo un'occhiata a un esempio. Immagina un negozio online che conserva le informazioni sui clienti in un database. Potrebbero avere una singola tabella chiamata Clienti con i seguenti elementi:

  • CustNum
  • Nome di battesimo
  • Cognome
  • Indirizzo
  • Città
  • Stato
  • cerniera lampo

Un breve sguardo a questa tabella rivela una piccola quantità di dati ridondanti. Archiviamo le voci "Sea Cliff, NY 11579" e "Miami, FL 33157" due volte ciascuna. Ora, questo potrebbe non sembrare uno storage troppo aggiunto nel nostro semplice esempio, ma immagina lo spazio sprecato se avessimo migliaia di righe nella nostra tabella. Inoltre, se il codice di avviamento postale di Sea Cliff dovesse cambiare, avremmo bisogno di apportare tale modifica in molti punti del database.

In una struttura di database conforme a 2NF, queste informazioni ridondanti vengono estratte e archiviate in una tabella separata. La nostra nuova tabella (chiamiamola ZIP) potrebbe avere i seguenti campi:

  • cerniera lampo
  • Città
  • Stato

Se vogliamo essere super-efficienti, possiamo persino riempire questo tavolo in anticipo - l'ufficio postale fornisce una directory di tutti i codici postali validi e le loro relazioni città / stato. Sicuramente, hai riscontrato una situazione in cui questo tipo di database è stato utilizzato. Qualcuno che ha effettuato un ordine potrebbe averti chiesto prima il tuo codice postale e poi conoscere la città e lo stato da cui stai chiamando. Questo tipo di disposizione riduce gli errori dell'operatore e aumenta l'efficienza.

Ora che abbiamo rimosso i dati duplicativi dalla tabella Clienti, abbiamo soddisfatto la prima regola del secondo modulo normale. Dobbiamo ancora utilizzare una chiave esterna per legare insieme le due tabelle. Useremo il codice di avviamento postale (la chiave primaria della tabella ZIP) per creare quella relazione. Ecco la nostra nuova tabella Clienti:

  • CustNum
  • Nome di battesimo
  • Cognome
  • Indirizzo
  • cerniera lampo

Abbiamo ridotto al minimo la quantità di informazioni ridondanti memorizzate nel database e la nostra struttura è in una forma normale.