Il modo migliore per esprimere meta-informazioni sui dati mancanti?

Naviga le tue risposte
3

Lavoro nell'IT sanitario, rivedendo i processi di gestione dei dati di vari studi osservazionali. Un problema che ho più volte affrontato sono i dati scarsamente codificati, specialmente quando mancano alcuni valori.

Sfondo, salta se vuoi

Attualmente sto esaminando uno studio che raccoglie dati su pazienti affetti da una specifica malattia. I pazienti di solito entrano nello studio una volta confermata la malattia (alcuni mesi dopo l'epidemia). Uno dei parametri importanti è il risultato di un determinato esame del sangue nella fase acuta della malattia, vale a dire si spera il più vicino possibile al focolaio. A volte, tuttavia, quel test non è stato eseguito perché non c'era alcuna indicazione o il paziente si è dimenticato di portare una copia del risultato, ecc.

Un aspetto importante qui è che tutti i dati nel DB sono generati da (tonnellate di file di carta non ordinati) e spesso le persone non hanno il tempo di sfogliare tutto, quindi non entrano nel risultato del test del sangue perché non hanno ancora ottenuto .

Per "in qualche modo" codificare i motivi per cui un valore è assente, ho visto vari schemi:

  1. Utilizza un campo TEXT (3) per i booleani e usa n/a per esprimere che "i dati non sono realmente disponibili" (ad esempio perché il test del sangue non è stato eseguito) e NULL per esprimere "Forse i dati sono da qualche parte, non li ho ancora cercati".

  2. Utilizza un campo aggiuntivo nella stessa tabella , ad es. un campo booleano "bloodtest_perf" dove "perf" sta per "effettivamente eseguito".

Non mi piace il primo approccio perché consente di inserire "sì", "y", "ja", "SÌ", ecc. e si finisce per passare la maggior parte del tempo a pulire anziché analizzare i dati. Anche il secondo approccio non è molto meglio, perché si finisce con dati fittizi al meglio e dati inconsistenti nel peggiore dei casi: 

__ TBL_TEST1 __________________________________
| patID | test1_perf | test1_date | test1_res |
+---------------------------------------------+
| 12345 | no         | NULL       | NULL      |
| 12345 | yes        | 2011-05-13 | 20.0      |
+---------------------------------------------+

La soluzione migliore che potrei inventare è creare un TBL_TEST1_METADATA che contenga una voce iff test1 non sia stata eseguita, che poi specifica perché no, ma i clinici (con rudimentale MS -Accesso alla conoscenza) sono alle prese con questo approccio di normalizzazione.

Che cos'è una soluzione pragmatica ma efficace per questo problema?

    
posta blubb 13.05.2011 - 16:16
fonte

2 risposte

5

Ci sono due modi comuni per affrontare questo tipo di cose:

  1. Non normalizzato, con un campo di stato e un campo risultato. Il campo dello stato può essere un bit , char(1) , char(3) , qualunque sia, non importa. Puoi concedere valori di NULL in questo campo ma, soprattutto, metti un vincolo su di esso - questo è il modo in cui impedisci a garbage come "ja" e "yyy" di entrarci. Ovviamente, un valore NULL significa "non so" e qualsiasi altra cosa è uno stato effettivo.

  2. normalizzato; crei una seconda tabella per i test e i risultati. Probabilmente avrà un campo TestIndex e un campo di stato non forzato non (con un vincolo simile a quello di # 1). Se lo stato del test è sconosciuto, la riga semplicemente non esiste affatto.

Quale versione è migliore dipenderà dagli altri aspetti del design, dai requisiti di indicizzazione e prestazioni, ecc. La versione normalizzata richiede più tempo per progettare, ma ha la più piccola possibilità di essere mai utilizzata in modo improprio, dal momento che l'accoppiamento esiste Il problema con la prima versione è che devi controllare il valore del campo dello stato per interpretare cosa c'è nel campo del risultato, probabilmente con un sacco di codice ripetitivo.

Se sei a tuo agio con i compromessi, vai con # 1. Altrimenti, normalizzalo come in # 2.

    
risposta data 13.05.2011 - 17:11
fonte
1

Informazioni approfondite qui: NULL non ha una semantica utile.

Use an additional field in the same table, e.g. a boolean field "bloodtest_perf" where "perf" stands for "actually performed".

Una corretta.

Questo è esattamente ciò che devi fare.

Un singolo campo potrebbe non essere sufficiente. Se si dispone di più processi indipendenti che contribuiscono all'acquisizione e alla convalida di un singolo dato, potrebbe essere necessaria una colonna per lo stato corrente di ciascun processo indipendente.

Le misurazioni non elaborate sono "mancanti" o "in dubbio" o "non ancora disponibili"

La conferma della misurazione è - indipendentemente - "mancante" o "in dubbio" o "non ancora disponibile".

    
risposta data 13.05.2011 - 16:48
fonte

Leggi altre domande sui tag

Imparare PHP per uno sviluppatore ASP.NET [chiuso] Come risolvere il problema del blocco implicito e dell'esecuzione parallela?