analisi dimensionale e unitaria nel database SQL

Question

Problema:

Un database relazionale (Postgres) che memorizza i dati della serie temporale di vari valori di misurazione. Ciascun valore di misurazione può avere un "tipo di misurazione" specifico (ad es. temperatura, ossigeno disciolto, ecc.) e può avere specifiche "unità di misura" (ad es. Fahrenheit / Celsius / Kelvin, percentuale / milligrammi per litro, ecc.)

Domanda:

Qualcuno ha creato un database simile in modo tale da preservare l'integrità dimensionale? Hai qualche suggerimento?

Sto pensando di costruire un tipo di misura e una tabella di misura, entrambi con testo due colonne, ID e testo. Quindi vorrei creare chiavi esterne per queste tabelle nella tabella meas_value. Il testo mi preoccupa un po 'perché c'è la possibilità di duplicati non univoci (ad esempio' ug / l 'vs' & # 181; g / l 'per microgrammi per litro).

Lo scopo sarebbe quello di poter sia convertire e verificare le unità su query, sia programmando esternamente. Idealmente, in seguito avrei la possibilità di includere un'analisi dimensionale rigorosa (ad es. Collegando & # 181; g / l al valore "M / V" (massa divisa per volume))

Esiste un modo più elegante per farlo?

Answer 1

Ho prodotto un sotto-schema del database per la gestione delle unità un paio di anni fa (ok, esagero leggermente; era circa 20 anni fa, però). Fortunatamente, doveva solo gestire massa, lunghezza, dimensioni del tempo - non temperatura, corrente elettrica o luminosità, ecc. Piuttosto meno semplice era il lato valutario del gioco - c'erano una miriade di modi diversi di convertire tra una valuta e un altro a seconda della data, della valuta e del periodo durante il quale il tasso di conversione era valido. Questo è stato gestito separatamente dalle unità fisiche.

Fondamentalmente, ho creato una tabella "misure" con una colonna "id", un nome per l'unità, un'abbreviazione e un insieme di esponenti della dimensione - uno ciascuno per massa, lunghezza, tempo. Questo viene popolato con nomi come 'volume' (lunghezza = 3, massa = 0, tempo = 0), 'densità' (lunghezza = 3, massa = -1, tempo = 0) - e simili.

C'era una seconda tabella di unità, che identificava una misura e quindi le unità effettive utilizzate da una determinata misura. Ad esempio, c'erano barili e metri cubi e ogni sorta di altre unità di pertinenza.

C'era una terza tabella che definiva i fattori di conversione tra unità specifiche. Ciò consisteva in due unità e il fattore di conversione moltiplicativo che convertiva l'unità 1 in unità 2. Il problema maggiore qui era la gamma dinamica dei fattori di conversione. Se la conversione da U1 a U2 è 1,234E + 10, l'inverso è un numero piuttosto piccolo (8.103727714749e-11).

Il commento di S.Lott sulle temperature è interessante - non abbiamo dovuto affrontare quelle. Una procedura memorizzata avrebbe risolto il problema, sebbene l'integrazione di una procedura memorizzata nel sistema sarebbe stata complicata.

Lo schema che ho descritto ha permesso di descrivere la maggior parte delle conversioni una volta (comprese unità ipotetiche come le furlong per quindici giorni, o meno ipotetiche ma ugualmente oscure - al di fuori degli Stati Uniti - come i piedi acri), e le conversioni potrebbero essere validate (per esempio, entrambe le unità nella tabella dei fattori di conversione dovevano avere la stessa misura). Potrebbe essere esteso per gestire la maggior parte delle altre unità, sebbene le unità senza dimensioni come gli angoli (o angoli solidi) presentino alcuni problemi interessanti. Esisteva un codice di supporto che gestiva conversioni arbitrarie o generava un errore quando la conversione non poteva essere supportata. Uno dei motivi di questo sistema era che le varie società affiliate internazionali avrebbero riportato i loro dati nelle loro unità localmente convenienti, ma il sistema HQ doveva accettare i dati originali e tuttavia presentare i dati aggregati risultanti in unità adatte ai gestori, in cui diversi gestori ciascuno avevano una propria idea (basata sul loro background nazionale e durata del servizio nel quartier generale) sulle migliori unità per i loro rapporti.

Answer 2

" Il testo mi preoccupa un po 'perché c'è la possibilità di duplicati non unici "

destro. Quindi non usare il testo come chiave. Usa l'ID come chiave.

" Esiste un modo più elegante per ottenere questo? "

Non proprio. È difficile. La temperatura è un problema proprio perché la temperatura è essa stessa una media e non si somma come fa la distanza; più la conversione da F a C non è un moltiplicatore (come per ogni altra conversione di unità).

Answer 3

Una nota sulle conversioni: molte unità sono linearmente correlate e possono essere convertite usando una formula come " y = A + Bx " ;, dove A e B sono costanti che possono essere archiviate nel database per ogni coppia di unità tra cui devi convertire. Ad esempio, per Celsius a Farenheit le costanti sono A = 32, B = 1.8.

Tuttavia, ci sono anche rare eccezioni. Conversione tra unità logaritmiche e non logaritmiche, ad esempio. O la conversione tra massa per volume e massa molare per volume (nel qual caso dovresti conoscere la massa molare del composto da misurare).

Naturalmente, se si è certi che tutte le conversioni richieste dal sistema siano lineari, non è necessario un eccesso di ingegneria, è sufficiente memorizzare le due costanti. È quindi possibile estrarre risultati standardizzati dal database utilizzando join SQL semplici con campi calcolati.