L'integrità dei dati è possibile senza normalizzazione?

0

Sto lavorando su un'applicazione che richiede la memorizzazione di informazioni sulla posizione come città, stato, codice postale, latitudine e longitudine. Vorrei assicurarmi:

  1. I dati sulla posizione sono precisi
    • Detroit, CA
      • Detroit NON in California
    • Detroit, MI
      • Detroit IS in Michigan
  2. Città e stati sono scritti correttamente
    • California non Calefornia
    • Detroit non Detriot
  3. Le città e gli stati sono denominati in modo coerente
    • Valido:
      • CA
      • Detroit
    • non valido:
      • Cali
      • California
      • DET
      • d-città
      • La D

Inoltre, dato che i dati di città / zip non sono garantiti come statici, l'aggiornamento di questi dati in modo normalizzato potrebbe essere difficile, mentre potrebbe essere implementato come una posizione di fatto se è denormalizzato.

Un paio di pensieri che ti vengono in mente:

  1. Una raccolta di tabelle di riferimento che memorizza un elenco di tutti gli stati e le città e i codici postali più comuni che possono crescere nel tempo. Cerca nel database una corrispondenza esatta o simile e raccomanda correzioni.
  2. Utilizzare un tipo di servizio per convalidare i dati sulla posizione prima che siano archiviati nel database.

È possibile soddisfare questi requisiti senza la normalizzazione e, in caso affermativo, dovrei denormalizzare questi dati?

    
posta shuniar 31.10.2012 - 01:00
fonte

4 risposte

4

Ciò che descrivi non ha nulla a che fare con la normalizzazione, ma con la convalida.

Puoi semplicemente avere una fonte da qualche parte con i valori validi. Quindi convalida prima di memorizzare le informazioni nel tuo database.

    
risposta data 31.10.2012 - 11:03
fonte
3

Sì, certo che puoi fare l'integrità dei dati su un database non normalizzato. Come pensi che abbiano fatto le cose prima che venissero scoperte le forme normali?

Tuttavia, il motivo per cui la normalizzazione è diventata una procedura standard è che ha reso tutto, inclusa l'integrità dei dati, SIMPLER.

    
risposta data 31.10.2012 - 04:31
fonte
1

È sempre possibile implementare un trasformatore di valori per normalizzare (o tentare di normalizzare) l'input, in modo simile a come funzionerebbe un controllo ortografico. Dai un'occhiata a Damerau-Levenshtein modifica la distanza se hai bisogno di idee su come ottenere la partita più vicina gratis -forma stringhe di input da un elenco di stringhe conosciute. Per garantire l'accuratezza dei dati, una volta che i dati sono stati normalizzati, puoi semplicemente archiviare i tuoi criteri in una sorta di struttura di dati associativi (un dizionario sarebbe sufficiente qui) come hai descritto.

In questo modo è ancora possibile consentire l'immissione in forma libera, consentendo nel contempo la coerenza e l'accuratezza all'interno del modello. Considera se la ricerca di Google richiede l'input normalizzato, perderai tonnellate di partite se il tuo ortografia / fraseggio non è accurato al 100%.

    
risposta data 31.10.2012 - 02:06
fonte
1

Sì. Puoi sempre assicurarti che i dati siano conformi alle regole all'interno dei programmi applicativi prima di aggiungere i dati al database. Ci sono due cose che rendono questo difficile da fare.

Il primo è la natura imperativa di quasi tutti i linguaggi di programmazione. Non esiste un modo semplice per dichiarare che un determinato campo non debba mai essere lasciato nullo o dovrebbe sempre fare riferimento a un referente esistente o dovrebbe sempre essere in tale e tale dominio. Tali regole dichiarative sarebbero generalmente controproducenti quando si tratta comunque di variabili di programma.

Quindi devi controllare ogni percorso di esecuzione per assicurarti che non infranga le regole. L'incapsulamento aiuta, ma non abbastanza.

Il secondo è che più programmi applicativi possono interagire con lo stesso database. Ho visto database in cui dozzine di programmi, parti di diverse applicazioni, condividono dati leggendo e scrivendo sullo stesso database. Accertarsi che nessuno di questi programmi vada in fumo è quasi impossibile.

Al contrario, i vincoli DBMS sono dichiarativi, relativamente semplici e vengono applicati ogni volta che è necessario nel contesto delle transazioni che manipolano i dati. I trigger possono rendere l'applicazione più flessibile, al costo di seguire la rotta imperativa piuttosto che quella dichiarativa.

La normalizzazione è rilevante solo per alcuni tipi di violazione dell'integrità dei dati. L'obiettivo delle forme normali da 2NF a 5NF è di ovviare alla possibilità di lasciare il database in uno stato contraddittorio. Le forme normali lo fanno assicurando che un singolo fatto venga memorizzato solo in un posto. È giusto o sbagliato, ma non è contraddetto da un altro fatto memorizzato altrove nel database.

Questo può essere estremamente utile per ridurre l'incidenza delle violazioni di integrità. Ma ci sono molti casi di integrità che non hanno nulla a che fare con la normalizzazione. L'integrità referenziale è uno di questi casi.

In quasi tutti i casi in cui un programmatore rinuncia all'integrità forzata del DBMS perché "i miei programmi non hanno mai errori logici" o "il DBMS è troppo lento", il programmatore o il suo successore hanno vissuto per pentirsene. Ricorda, il valore dei dati spesso supera il sistema che lo ha catturato.

Nel caso in cui ci hai dato, dove Detroit, CA è noto per essere sbagliato, come puoi essere sicuro? Come fai a sapere che non c'è un piccolo piccolo sobborgo, da qualche parte in California, a cui è stato dato il nome "Detroit"? Si può supporre che, se non è nel database, allora non può essere vero. Ma questa ipotesi può facilmente tornare a morderti.

    
risposta data 04.11.2012 - 14:58
fonte

Leggi altre domande sui tag