Sto cercando di ottenere una versione definitiva di ciò che è First Normal Form. Tutto quello che leggo ha una rotazione leggermente diversa.

Molte autorità, come Date, affermano che per definizione una relazione è sempre in prima forma normale, mentre altre forniscono un elenco di requisiti. Ciò significa che ci sono da zero a molti requisiti per 1NF.

Suppongo che la differenza sia tra tabelle e relazioni: le tabelle possono essere un disastro completo, mentre una relazione segue determinate restrizioni. Il fatto che una relazione sia rappresentata come una tabella in SQL crea quindi un po 'di confusione.

Mi sto concentrando specificamente su 1NF in relazione ai database SQL. La domanda è: quali proprietà sono necessarie per garantire che una tabella sia nella prima forma normale?

Molte autorità suggeriscono che se una tabella rappresenta una relazione , allora è già in 1NF. Questo riporta la definizione di 1NF alla definizione di una relazione.

Ecco alcune proprietà di una tabella in 1NF:

• L'ordine delle colonne è insignificante [1]
• L'ordine delle righe è insignificante
• Tutte le righe hanno la stessa lunghezza (ovvero, i dati delle righe corrispondono alle intestazioni di colonna)
• Non ci sono righe duplicate (questo può essere garantito usando una chiave primaria surrogata, ma il PK non è di per sé necessario)
• Non ci sono colonne ripetute
• Ogni colonna contiene un singolo valore (atomico)

[1] Gli attributi tecnicamente non sono ordinati, ma in una tabella i dati delle righe devono essere nello stesso ordine delle intestazioni di colonna. Tuttavia, l'ordine reale è insignificante.

Su più dati :

Il concetto di dati atomici è che un articolo non può essere ulteriormente suddiviso. Questo concetto è stato qualificato in quanto, sebbene tecnicamente tutto possa essere scomposto fino alla nausea , i dati in questione non possono essere praticamente scomposti ulteriormente, a seconda di come verranno utilizzati.

Ad esempio, un indirizzo completo o un nome completo dovrebbero normalmente essere ulteriormente suddivisi, ma i componenti come il nome o il nome della città probabilmente non dovrebbero essere ulteriormente suddivisi, nonostante il fatto che possano essere stringhe.

Per quanto riguarda le colonne ripetute, è una colonna di progettazione scadente avere colonne quasi ripetute, come phone1, phone2ecc. In generale, i dati ripetuti indicano la necessità di una tabella correlata aggiuntiva.

Dipendenza

Non ci dovrebbe essere alcuna relazione tra le righe, a parte il fatto che sono conformi alle stesse intestazioni.

Non dovrebbe esserci alcuna relazione tra le colonne, ma credo che sia l'oggetto di forme normali superiori.

La domanda è: quanto sopra è nella definizione di 1NF? Vi entrano anche le bit delle righe indipendenti?

Preliminare

La definizione di forma normale (che dalla presentazione di "Ulteriore normalizzazione del modello relazionale di base di dati" nel 1971 è nota come prima forma normale ) e la definizione del paradigma relazionale stesso è stata pubblicata nel 1970 nell'articolo scientifico che ha fornito un forte fondamento per la pratica dell'amministrazione di database, vale a dire "Un modello relazionale di dati per grandi banche dati condivise" (RM per brevità) creato dal Dr. EF Codd , che è un destinatario Turing Award e l' autorità per quanto riguarda il quadro relazionale.

Sì, ci sono molte spiegazioni, interpretazioni, esposizioni, deviazioni e opinioni sul testo del Dr. Codd, ma personalmente preferisco attenermi alla fonte originale e suggerisco caldamente di analizzarlo da solo in modo da poter trarre le tue conclusioni.

Certamente non capisco la RM nella sua interezza, ma ciò che capisco mi permette di apprezzarne l'eccellenza, la visione, l'intenzione e la portata, e sebbene decenni dopo si possa notare che ha alcune lievi imprecisioni, non si riducono, in ogni modo, il suo genio ed eleganza. Nel suo campo, l'RM ha superato la prova del tempo in un modo unico e non ha eguali.

L'atto di enfatizzare le suddette imprecisioni sarebbe — usare un termine caritatevole — ingiusto perché, visto da una distanza considerevole, questo materiale fondamentale ha richiesto alcuni perfezionamenti ed estensioni, sì, ma il corpo principale dell'opera era solido come la roccia dal stessa concezione (e, in effetti, il Dott. Codd ha fatto la maggior parte, se non tutte, di tali perfezionamenti ed estensioni).

Continuo a rileggere costantemente il RM al fine di rafforzare la mia comprensione di questa eccezionale fonte di conoscenza (e la mia stima di essa continua a crescere su ogni rilettura); l'obiettivo è stare sulle spalle dei giganti.

Relazioni e tabelle

È importante notare che poiché le relazioni sono risorse astratte , il Dr. Codd ha immaginato l'utilità di rappresentarle in forma tabellare (inizialmente ha usato il termine "rappresentazione di array" ma successivamente ha usato "table" o "r-table"), in modo che gli utenti, i progettisti e gli amministratori di un database relazionale (RDB) possono affrontarli in un modo più familiare o concreto . Pertanto, nel contesto di un'implementazione di RDB, è valido utilizzare la tabella come scorciatoia per la relazione, purché detta tabella rappresenti una relazione effettiva. Questa caratteristica è - anche se ovvia - abbastanza significativa perché prima di valutare se una tabella rappresenti o meno una relazione conforme alla prima forma normale (1NF), deve rappresentare, precisamente, una relazione.

L'RM contiene naturalmente le qualità che una tabella deve avere per determinare se in realtà ritrae una relazione, ma offrirò qui un'interpretazione informale e senza pretese (un'altra, sì!):

• Deve avere un nome (ogni relazione particolare in una struttura di database deve essere distinta dal resto).
• Ciascuna delle sue righe deve rappresentare esattamente una tupla della relazione pertinente.
• L' ordine delle sue righe non è affatto importante.
• Ciascuna delle sue colonne deve avere un nome che rappresenti esattamente il significato di un solo dominio della relazione in questione e tale nome deve essere diverso dai nomi delle altre colonne della tabella (una colonna deve essere differenziata in modo univoco e deve contenere un significato distintivo e, sì, il ruolo svolto da un modellatore di database e dagli esperti di business per definire con precisione ogni dominio significativo è fondamentale)
• L' ordine delle sue colonne non ha significato.
• Tutte le sue righe devono avere lo stesso numero di colonne.
• Deve avere almeno una colonna o una combinazione di colonne che identifichi in modo univoco ognuna delle tuple rappresentate tramite le righe; in questo modo, tutte le righe devono essere diverse (sì, questo sottolinea l'importanza di avere almeno un KEY dichiarato, e quando ci sono due o più KEY uno dovrebbe essere definito come PRIMARIO in base a ragioni pragmatiche, mentre il resto può essere considerato ALTERNATIVO, ma sì, prima di prendere la decisione, ciascuna delle CHIAVI era un "candidato" per una definizione come PRIMARIA).

Avere una tabella che in realtà rappresenta una relazione è fondamentale poiché, quando subisce operazioni di manipolazione di tipo relazionale, il risultato è, di nuovo, una tabella che rappresenta una relazione. In questo modo, il comportamento di detta tabella è prevedibile .

Domini atomici (colonne)

Nelle prime sezioni della RM, il Dr. Codd presenta diversi esempi di relazioni al fine di introdurre alcuni concetti; quindi, al fine di comprendere il significato del dominio atomico , iniziamo con il seguente estratto dall'RM che dettaglia alcuni punti pertinenti:

Finora abbiamo discusso esempi di relazioni che sono definite su domini semplici, domini i cui elementi sono valori atomici (non componibili). I valori non anatomici possono essere discussi nel quadro relazionale. Pertanto, alcuni domini possono avere relazioni come elementi. Queste relazioni possono a loro volta essere definite su domini non semplici e così via.

In questo modo, si può dire che ciascuna delle relazioni espositive sopra menzionate si adatta in uno dei due tipi, ad esempio tipo A o tipo B :

• Tipo A raggruppa solo relazioni (tabelle) che sono strutturate con domini (colonne) che contengono valori esclusivamente semplici in ciascuna delle loro tuple (righe), vale a dire che tali domini (colonne) non contengono relazioni (tabelle) come valori, che in questo contesto significa che i valori sono atomici perché non possono essere scomposti successivamente in nuove relazioni (tabelle). Quindi, le relazioni di questa classe sono quelle che sono normalizzate , cioè sono conformi a 1NF, la loro forma è desiderabile.

• Il tipo B è integrato esclusivamente da relazioni (tabelle) che hanno uno o più domini (colonne) che mantengono le relazioni come valori in ciascuna rispettiva tupla (riga) e ciò significa che tali valori sono non anatomici poiché possono essere successivamente suddivisi in nuove relazioni (tabelle), cioè sono scomponibili . Pertanto, le relazioni di questo tipo sono non normalizzate, cioè violano 1NF, sono in una forma indesiderabile.

Normalizzazione

Il Dr. Codd introduce la sezione sulla normalizzazione in RM con il seguente paragrafo:

Una relazione i cui domini sono tutti semplici può essere rappresentata in memoria da una matrice bidimensionale omogenea di colonne del tipo sopra discusso. È necessaria una struttura di dati più complicata per una relazione con uno o più domini non semplici. Per questo motivo (e altri che verranno citati di seguito), vale la pena indagare sulla possibilità di eliminare domini non semplici! Esiste, infatti, una procedura di eliminazione molto semplice, che chiameremo normalizzazione.

Quindi continua a mostrare:

1. Un gruppo di relazioni in cui si è non normalizzati (ha domini che contengono relazioni come valori, cioè non sono anatomici; cioè non sono semplici)

2. Un gruppo di relazioni che sono normalizzate (cioè, che è stato decomposto; cioè, uno i cui domini valutati in relazione sono stati suddivisi in domini semplici che significa che sono atomici)

E poi descrive la procedura per ottenere relazioni normalizzate da quelle non normalizzate.

A questo proposito, le relazioni che ha impiegato per illustrare un esercizio di normalizzazione e la descrizione dell'esercizio stesso sono abbastanza chiare, e raccomando di nuovo di analizzarli da soli (e spero anche che ciò incoraggi alcuni lettori a impegnarsi con il testo).

In modo positivo, indica:

Sono possibili ulteriori operazioni di tipo normalizzante. Questi non sono discussi in questo documento.

E dette operazioni, vale a dire la seconda e la terza forma normale (2NF e 3NF) sono in realtà dettagliate in "Ulteriore normalizzazione del modello relazionale di base di dati", e come menzionato sopra, dopo la presentazione (e la successiva stampa e pubblicazione) di questo documento , la forma normale originale divenne nota come prima forma normale.

Come può osservare un professionista, avere relazioni (tabelle) non normalizzate introduce una convoluzione (quasi sempre non necessaria) nelle implementazioni di RDB.

Una relazione che soddisfa 1NF, facilita la definizione di vincoli e operazioni di manipolazione dei dati che possono essere implementate mediante una sublanguage di dati che è meno complessa di quella richiesta per relazioni (tabelle) non normalizzate, come sottolinea il Dr. Codd nelle seguenti righe:

L'adozione di un modello relazionale di dati, come descritto sopra, consente lo sviluppo di una sublanguage di dati universale basata su un calcolo del predicato applicato. Un calcolo del predicato del primo ordine è sufficiente se la raccolta di relazioni è in forma normale. Tale linguaggio fornirebbe un metro di potere linguistico per tutte le altre lingue di dati proposte e sarebbe esso stesso un candidato valido per essere incorporato (con opportune modifiche sintattiche) in una varietà di lingue host (programmazione, orientata ai comandi o ai problemi). [...]

[...]

L'universalità del linguaggio secondario dei dati risiede nella sua capacità descrittiva (non nella sua capacità di calcolo).

Lo stupore

Dal mio punto di vista, lo stupore è sorto, a causa (a) del suddetto eccesso di interpretazioni, spiegazioni, ecc., Su 1NF e lo stesso RM, e a causa di (b) ulteriori tentativi di ridefinire 1NF che affermano che avere relazioni con domini che contengono valori che sono, a loro volta, relazioni conformi a 1NF purché costituiscano un singolo valore per ciascuna tupla corrispondente.

La mia opinione sui tuoi altri punti

Non ci dovrebbe essere alcuna relazione tra le righe, a parte il fatto che sono conformi alle stesse intestazioni.

Non sono sicuro di comprendere correttamente l'intenzione di tale affermazione ma, a parte la conformità alle stesse intestazioni, deve esserci una connessione tra le (tuple) righe di una relazione (tabella) in quanto ciascuna di esse dovrebbe essere un'asserzione su un particolare occorrenza del tipo di entità specifica (definita in termini di contesto aziendale di interesse) che la relazione (tabella) dovrebbe rappresentare.

Non dovrebbe esserci alcuna relazione tra le colonne, ma credo che sia l'oggetto di forme normali superiori.

Non so nemmeno se sto interpretando correttamente il significato di quell'affermazione ma, in effetti, e in conformità con la mia risposta all'aspetto precedente, deve esserci anche una relazione tra i domini (colonne) di una relazione (tabella) , che è precisamente il motivo per cui è una relazione (la struttura essenziale del modello relazionale e di un'implementazione concreta di RDB).

Per esemplificare, per quanto riguarda la relazione ipotetica (tabella)

• Salary (PersonNumber, EffectiveDate, Amount)

la tupla (fila)

• Salary (x, y, z)

trasmetterebbe il significato

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Pertanto, ogni tupla (riga) della Salaryrelazione (tabella) deve adattarsi alla struttura dell'asserzione mostrata sopra e la differenza sarebbe la sostituzione dei valori di dominio (colonna) pertinenti, ma deve esistere una relazione tra (a) tutti i Salarydomini (colonne) e anche tra (b) tutti i loro valori corrispondenti rispetto a ciascuna tupla (riga); tale relazione è indispensabile.

Le forme normali più alte (2NF e 3NF) sono utili per sbarazzarsi delle dipendenze funzionali tra domini (colonne) di una relazione (tabella), aiutano a evitare connessioni indesiderate tra domini (colonne), poiché tali connessioni indesiderate consentono l'introduzione di anomalie di aggiornamento . Sia 2NF che 3NF sono utili per testare la solidità della struttura delle relazioni (tabelle) in una certa implementazione di RDB.

Un'illustrazione. Prendi una stringa di testo che contiene un tipico indirizzo americano:

"123 Cornhusk Rd., South Succotash, NY 12345"

Scrivere una domanda per trovare tutti i residenti di Cornhusk Road o un particolare residente della città di South Succotash o dello stato di New York sarebbe un compito scoraggiante. Soprattutto quando si hanno le seguenti stringhe nei dati:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Ognuno di questi specifica lo stesso indirizzo effettivo (e questo non considera nemmeno probabili errori di ortografia come "Succatash") ma scrivere l'algoritmo per confrontarli con successo è qualcosa che NON vorrei dedicare ai miei ultimi anni rimasti su questa Terra.

Inserisci il primo modulo normale. Non entrerò nei dettagli di come è fatto, basta considerare un modulo comune come visto nella maggior parte dei database:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Questa non è una normalizzazione completa. Ad esempio, potresti dividere ulteriormente Street in StreetNum e StreetName, ma questo è abbastanza lontano per una semplice illustrazione e si tratta di quanto riguarda il processo di normalizzazione nella vita reale. C'è ancora un piccolo problema nel trovare tutti gli abitanti di Cornhusk Road ma se hai cercato Street per la sottostringa "Cornhusk" e da qualche parte ci fosse una città di nome Cornhusk, almeno questo non causerebbe confusione.

Il problema con la definizione fornita da Date, et al, è che non riescono a guardare all'interno di un pezzo di dati e considerare il significato di tali dati. Non che li incolpi particolarmente, può essere abbastanza difficile.

Quindi dobbiamo prendere una "stringa di caratteri" e trasformarla in un "indirizzo". Ma trovare una definizione all-inclusive di indirizzo non è così semplice come sembra. Soprattutto quando si lavora con indirizzi in più di un paese.

Innanzitutto, risolviamo il contesto. Niente ha significato senza contesto. Il nostro contesto qui è l' indirizzo . In quel contesto, possiamo vedere parti dei dati che hanno significati specifici, come Via , Città , ecc. Assegniamo a ciascun significato un campo separato.

La parte difficile è che i dati, come le parole, possono avere significati diversi per persone diverse o alcune persone possono vedere il significato dove altri no. Può essere un progetto tutto per sé e richiedere un grande sforzo di cooperazione. Ma è un elemento critico nella buona progettazione del database.

Il punto di normalizzazione è eliminare o almeno minimizzare i dati anomali . Considera il fatto che, nella tabella sopra, può essere inserito un codice di città o CAP che non esiste nello stato che è stato selezionato. Oppure è entrata una strada che in realtà non esiste nella città selezionata. Ah, ma ora stiamo entrando nella seconda e terza forma normale e questo è un altro argomento.

Pensa a 1NF come un'introduzione al concetto matematico di relazioni, piuttosto che una particolare struttura di dati o un insieme fisso di regole. Le strutture matematiche come le relazioni possono essere rappresentate in diversi modi: le tabelle sono solo uno dei modi più convenienti. Quando si usano le tabelle, ci sono delle restrizioni per garantire che esse rappresentino chiaramente le loro relazioni previste e che le operazioni sulle tabelle siano logicamente valide rispetto alle relazioni rappresentate.

Quando diciamo che l'ordine e la duplicazione delle colonne e delle righe sono insignificanti, questo per garantire che tutte le informazioni significative siano registrate come valori nella tabella e accessibili alle nostre query e non codificate nella presentazione della tabella. Mentre pochi, se del caso, gli autori hanno vietato esplicitamente l'uso del colore nelle tabelle, comprendere lo scopo delle restrizioni di cui sopra ci porterebbe a escludere in modo simile l'uso di colori di presentazione significativi in ​​modo che i valori di colore significativi debbano essere esplicitamente registrati. Date e altri autori deprecano anche gli identificatori di righe nascoste per lo stesso motivo.

Il concetto di atomicità consiste nel garantire che tutte le strutture significative siano espresse come relazioni, in modo che siamo in grado di analizzare le dipendenze in tutti i nostri dati e prevenire anomalie, e che tutta la struttura significativa sia uniformemente accessibile alle operazioni relazionali. I valori compositi non sono invalidi, ma richiedono la decompressione degli operatori specifici del dominio, il che aumenta la complessità e possono introdurre ridondanza. Naturalmente, in pratica alcuni semplici tipi compositi e operatori associati sono utili e aiutano ad aumentare la compattezza e l'espressività delle query, ma ciò non contraddice la teoria.

Le dipendenze di riga come le dipendenze multivalore non violano 1NF, ma come le dipendenze tra le colonne, sono oggetto di forme normali più elevate. Le colonne quasi ripetute come phone1, phone2ecc., Non violano neanche 1NF, anche se sono di design scadente.

La definizione e la spiegazione di WikiPedia su 1NF, penso sia abbastanza buona. - joanolo

Espandendo su una frase nell'articolo di Wikipedia:

Visto come numeri di telefono, il testo non è atomico

Questo potrebbe darti un'idea del perché c'è così tanta confusione. Se questo è solo un goccio di testo, allora è atomico. Ma se è visto come numeri di telefono, non è atomico. Date e altri hanno evitato questo problema. Ha a che fare con il significato dei dati. Quando si analizza l'argomento, è necessario confrontarsi con il significato dei dati.

Se c'è qualche motivo per scomporlo ulteriormente è rilevante per la questione se è stata soddisfatta la prima forma normale. Il punto dietro 1NF è fornire un accesso con chiave a tutti i dati. Ma se la cosa che recuperi tramite accesso con chiave ha una sottostruttura, allora non hai accesso con chiave alla sottostruttura. - Walter Mitty

"1NF" è usato per significare un mucchio di cose diverse , molte delle quali sono simultaneamente senza senso e comuni. Vedi la mia risposta a "Normalizzazione nel sistema di gestione del database" , compresi i suoi collegamenti. Una di queste è la mia risposta a "Cos'è l'atomicità in dbms" . (Entrambi a Stack Overflow.) - Philipxy

_{Community Wiki risposta creata dai commenti lasciati sulla domanda}