Qual è la terza forma normale? (Banche dati)

IL Terzo modulo normale (database) È una tecnica di progettazione del database relazionale, in cui le diverse tabelle che la compongono non solo soddisfano la seconda forma normale, ma tutti i loro attributi o campi dipendono direttamente dalla chiave principale.

Quando è progettato un database, l'obiettivo principale è quello di creare una rappresentazione precisa dei dati, delle relazioni tra loro e delle restrizioni sui dati rilevanti.

Fonte: Pixabay.com

Per raggiungere questo obiettivo, è possibile utilizzare alcune tecniche di progettazione del database, tra cui la standardizzazione.

Questo è un processo di organizzazione dei dati in un database per evitare licenziamenti e possibili anomalie nell'inserimento, aggiornamento o smaltimento dei dati, generando per esso una progettazione semplice e stabile del modello concettuale.

Inizia esaminando la relazione funzionale o la dipendenza tra gli attributi. Questi descrivono alcune proprietà dei dati o la relazione tra loro.

[TOC]

Forme normali

La standardizzazione utilizza una serie di test, chiamati forme normali, per aiutare a identificare il raggruppamento ottimale di questi attributi e infine stabilire l'insieme di relazioni adeguate a supporto dei requisiti di dati di un'azienda

Cioè, la tecnica di normalizzazione è costruita attorno al concetto di modo normale, che definisce un sistema di restrizioni. Se una relazione soddisfa le restrizioni in un modo particolare normale, si dice che la relazione sia in quel modo normale.

Prima forma normale (1fn)

Si dice che una tabella sia in 1fn se tutti gli attributi o i campi al suo interno contengono solo valori univoci. Cioè, tutto il valore per ciascun attributo deve essere indivisibile.

Per definizione, un database relazionale sarà sempre normalizzato alla prima forma normale, perché i valori degli attributi sono sempre atomici. Tutte le relazioni in un database sono in 1fn.

Può servirti: costante (programmazione): concetto, tipi, esempi

Tuttavia, lasciare il database stimola semplicemente una serie di problemi, come la ridondanza e le possibili anomalie di aggiornamento. Le forme più alte normali sono state sviluppate per correggere questi problemi.

Seconda forma normale (2fn)

Si occupa di eliminare da un tavolo le unità circolari. Si dice che un rapporto sia in 2fn se è in 1fn e anche ogni campo o attributo non dipende completamente dalla chiave primaria, o più specificamente, si assicura che la tabella abbia un unico scopo.

Un attributo non la chiave non è un attributo che non fa parte della chiave primaria per una relazione.

Terza forma normale (3FN)

Si occupa di eliminare le dipendenze transitive da una tabella. Cioè, eliminare gli attributi non chiari che non dipendono dalla chiave primaria, ma da un altro attributo.

Una dipendenza transitiva è un tipo di dipendenza funzionale in cui il valore di un attributo o un campo non è determinato dal valore di un altro campo che non è neanche chiave.

I valori ripetuti dovrebbero essere ricercati negli attributi non chiari per garantire che questi attributi che non sono la chiave non dipendano solo dalla chiave primaria.

Si dice che gli attributi siano reciprocamente indipendenti se nessuno di essi dipende funzionalmente da una combinazione di altri. Questa reciproca indipendenza garantisce che gli attributi possano essere aggiornati individualmente, senza pericolo di influenzare un altro attributo.

Pertanto, affinché un rapporto di database sia in terza forma normale, deve rispettare:

- Tutti i requisiti 2FN.

Può servirti: ICT in casa

- Se ci sono attributi che non sono correlati alla chiave primaria, devono essere eliminati e posizionati in una tabella separata, relative entrambe le tabelle attraverso una chiave esterna. Cioè, non ci dovrebbe essere dipendenza transitiva.

Esempi di terza forma normale

Esempio 1

Essere la tabella dello studente, la cui chiave principale è l'identificazione dello studente (Id_estudiant) ed è composta dai seguenti attributi: nome dello studente, strada di strada, città e_postale, che soddisfa le condizioni da 2fn.

In questo caso, Street e City non hanno una relazione diretta con la chiave di identità primaria, poiché non sono direttamente correlati allo studente, ma dipendono totalmente dal codice postale.

Poiché lo studente si trova sul sito determinato da Code_Postal, Street e City sono collegati è a questo attributo. A causa di questo secondo grado di dipendenza, non è necessario archiviare questi attributi nella tabella degli studenti.

Crea nuovo tavolo

Supponiamo che ci siano più studenti situati nello stesso codice postale, con la tabella degli studenti che ha un'immensa quantità di record, ed è necessario modificare il nome della strada o della città, quindi questa strada o città dovrebbe essere cercata e aggiornata in tutto il Studente di tavolo.

Ad esempio, se è necessario cambiare la strada "El Limón" per "El Limón II", dovrà cercare "El Limón" in tutto il tavolo degli studenti e quindi aggiornarla su "El Limón II".

Trova in una tabella enorme e aggiorna i record univoci o multipli richiederanno molto tempo e, pertanto, influenzerà le prestazioni del database.

Invece, questi dettagli possono essere ottenuti in una tabella separata (cartolina) correlata alla tabella Student utilizzando l'attributo Code_Postal.

La tabella postale avrà una quantità relativamente inferiore di record e dovrà aggiornare solo una volta questa tabella postale. Questo verrà automaticamente riflesso nella tabella degli studenti, semplificando i database e le consultazioni. Quindi le tabelle saranno in 3FN:

Può servirti: metabuster: caratteristiche, tipi ed esempi

Esempio 2

Essere la tabella seguente con il campo NUM_Project come chiave principale e con valori ripetuti negli attributi che non sono la chiave.

Il valore del telefono viene ripetuto ogni volta che viene ripetuto il nome di un manager. Questo perché il numero di telefono ha solo una seconda dipendenza da gradi con il numero di progetto. Dipende davvero dal manager, e questo a sua volta dipende dal numero del progetto, il che rende una dipendenza transitiva.

L'attributo manager_project non può essere una possibile chiave nei progetti della tabella perché lo stesso manager gestisce più di un progetto. La soluzione per questo è eliminare l'attributo con dati ripetuti (telefono), creando una tabella separata.

Gli attributi corrispondenti devono essere raggruppati, creando una nuova tabella per salvarli. I dati vengono inseriti e viene verificato che i valori che vengono ripetuti non fanno parte della chiave primaria. Viene stabilita la chiave primaria per ciascuna tabella e, se necessario, vengono aggiunte i tasti esterni.

Per soddisfare la terza forma normale, viene creata una nuova tabella (manager) per risolvere il problema. Entrambe le tabelle sono correlate tramite il campo Manager_Project:

Riferimenti

1. Teradata (2019). Primo, secondo e terza forma normale. Preso da: documenti.Teradata.com.
2. Coppa Tutorial (2019). Terza forma normale (3NF). Tratto da: Tutorialcup.com.
3. Database Dev (2015). Terza forma normale (3NF) - Normalizzazione del database. Tratto da: DataBesedv.co.UK.
4. Relational DB Design (2019). Introduzione alla terza forma normale. Tratto da: relationaldbdesign.com.
5. Dummies (2019). SQL Primo, secondo e terza forma normale. Preso da: manichini.com.