Quale aspetto delle forme normali violano le tabelle valore attributo-entità, se ce ne sono?

Una tabella EAV (aka Key-Question-Answer) è tecnicamente in 3NF:

1NF

• Le righe sono indipendenti dall'ordine - True , le righe possono essere memorizzate in qualsiasi ordine.
• Le colonne sono indipendenti dall'ordine - True , l'ordinamento della colonna non ha alcun effetto sullo stato dei dati contenuti e le colonne possono essere referenziate indipendentemente da qualsiasi altra.
• Nessuna riga duplicata - Vero , esiste una chiave candidata unica Entità + Attributo che non può essere duplicata.
• Ogni campo (ogni colonna di ogni riga) contiene uno e un solo valore - Vero , fornito che "valore" non contiene un elenco di valori o un composto "struttura" in formato serializzato.
• Niente è nascosto - true , il database contiene tutte le informazioni necessarie per seguire le quattro regole precedenti e non ne nasconde nessuna (può nascondere i dettagli di implementazione non necessari per seguire le quattro regole precedenti) .

2NF

• In 1NF - Vero
• Tutte le colonne della tabella che non sono la chiave candidata devono avere una relazione (diretta o indiretta) con l'intera chiave candidata - Vero , l'unica colonna che non è parte della chiave è legato alla chiave completa.

3NF

• In 2NF - Vero
• Tutte le colonne della tabella che non sono la chiave candidata sono direttamente correlate all'intera chiave candidata - Vero , l'unica colonna che non fa parte della chiave è direttamente correlata a entrambe le parti della chiave.

Pertanto, l'EAV aderisce alla terza forma normale. Non soddisfa i 4NF, perché la struttura ha dipendenze multivalore (in realtà è progettata per); l'aggiunta di un nuovo ID entità alla tabella richiede la creazione di una riga per ciascun Attributo, mentre l'aggiunta di un Attributo appena supportato richiede l'aggiunta di una riga per ogni Entità che ha quel nuovo Attributo. Una struttura di tabella "appiattita" più tradizionale può incontrare 4NF; l'aggiunta di una nuova entità richiede solo l'aggiunta di una riga, e questo è l'unico motivo per aggiungere una riga alla tabella.

Se c'è un argomento per dire che non è 3NF, sarebbe che viola la regola "nessuna informazione nascosta" di 1NF in quanto la struttura dei dati non è nota al DB. Il campo "Valore" di una tabella EAV è necessario per poter contenere tutto ciò che può essere usato come valore; in quanto tale, di solito è un campo stringa di qualche tipo, contenente le rappresentazioni di stringa di dati come i numeri. Questi dati devono essere analizzati nei tipi corretti e la conoscenza necessaria per farlo non è contenuta in un punto accessibile nel DB (a meno che non sia incorporata nel Valore stesso, violando la regola "uno e un solo valore" 1NF o inclusa come colonna aggiuntiva , violando la regola "tutti i campi direttamente correlati alla chiave candidata" di 3NF), quindi è "nascosto".

Non è normalizzato

Una delle regole di normalizzazione è la seguente: Un campo dovrebbe avere lo stesso significato in ogni riga della tabella.

Anche la tabella non rappresenta alcuna Entità specifica ..

Regole di normalizzazione del database SQL

Chiedere se è normalizzato o meno è in gran parte fuori luogo.

Invece, dovresti chiedere "è basato su un modello relazionale della materia"? La risposta è un sonoro NO. Questo è per intento. Quando vengono scoperte nuove funzionalità dell'oggetto, come nuove entità o attributi, l'EAV può essere aggiornato senza modifiche alle definizioni dei dati.

Ciò significa che l'EAV è indipendente dai requisiti di informazione sull'argomento. Ciò a sua volta significa che possiamo costruire un EAV senza fare alcuna analisi dei dati sull'argomento. Questa è sia la grande attrazione che la terribile trappola dell'EAV.