Qual è una buona struttura relazionale per unità e conversioni di unità complesse?

La mia azienda è nel settore energetico e devo trovare un buon modo per rappresentare la conversione di unità di misura. Ho fatto qualche ricerca e non ho ancora trovato un buon articolo che lo riguardi nella profondità di cui ho bisogno. La maggior parte delle informazioni pubblicate sulle conversioni di unità presuppone che, data l'Unità 1, vi sia un tasso di conversione noto (codificato) per arrivare all'Unità 2 ed è semplice matematica ( questo è l'esempio più complesso che ho trovato che non aiuta ancora). Tuttavia, questo non è sempre vero nel mondo reale e certamente non è vero per ciò che dobbiamo gestire. (Ci scusiamo per il lungo scritto - Sto cercando di fornire quante più informazioni possibili!)

Esempio complicato 1: alcune conversioni variano nel tempo, ad esempio convertendo $ 5 in euro o viceversa. Sembra che non abbia nulla a che fare con l'energia, ma lo fa davvero nel mercato delle materie prime energetiche (pensa al mercato azionario).

Esempio complicato 2: (semplificato eccessivamente) Alcuni gas naturali bruciano più caldi di altri . Inoltre, il gas naturale può essere misurato / immagazzinato in base all'energia nel gas (come Therms ) OPPURE in base al volume di detto gas (come MCF che è 1000 piedi cubi), e ci sono anche altre possibilità (come come Ton for Mass ). Un'analogia della benzina è che 1 gallone di 87 ottani senza piombo fornisce meno energia di 1 gallone di 93 ottani senza piombo.

Esempio complicato 3: Oltre ad avere queste unità di misura, spesso dobbiamo anche fare i conti con tariffe, come $ per Therm o € per MCF . Quindi abbiamo bisogno di un modo per lavorare con queste tariffe e il modo in cui si collegano alle unità di base, quindi se abbiamo bisogno di convertire da $ per Therm a € per MCF , possiamo e utilizza le stesse tariffe pubblicate della conversione da Therm a MCF .

Esempio complicato 4: In precedenza, avevo usato il termine Energia in modo molto approssimativo e forse a volte in modo errato. A questo punto e da ora in poi, questo sta cambiando. Quindi l'ultima curva è che ci occupiamo sia di energia che di potenza . Con l'elettricità, questo significa kWH contro kW ( una spiegazione abbastanza buona nonostante sia Yahoo Answers ). Un'analogia dei dati: sarebbe come confrontare i MB totali di dati scaricati rispetto ai tuoi Mbpslarghezza di banda fornita dall'ISP. Come i dati, l'energia richiede tempo per essere erogata. Continuando con l'analogia dei dati, potremmo dover calcolare la larghezza di banda effettiva media consumata in un periodo di tempo, quindi dato che 60 MB sono stati scaricati in 1 minuto, la velocità "effettiva" sarebbe 60 * 8/60 = 8 Mbps. Il "trucco" qui è che se memorizziamo Mbps come unità stessa, abbiamo bisogno di un modo per collegarlo direttamente a un MB , anche se coinvolge anche una componente temporale. FORTUNATAMENTE, la conversione da energia a potenza (o viceversa) è una cosa abbastanza rara per noi da fare, quindi la nostra soluzione dovrebbe essere ottimizzata per tutti gli altri esempi difficili e, si spera, consentire anche questo, ma non gestirla Energiaal potere è un'opzione.

Esempio complicato 5: si tratta essenzialmente di 3 + 4. Potremmo avere sia $ per KW che $ per KWh , quindi le tariffe riguardano sia Potenza che Energia .

Esempio semplice: alcune conversioni sono molto semplici e sono quelle che possono gestire la maggior parte delle informazioni sul Web. 1000 Wh = 1kWh e simili. Stessa cosa con Therms e Decatherms o da kW a MW, ecc. Non ho bisogno di aiuto qui, ma tieni presente che circa il 70% delle nostre conversioni sarà di questo tipo.

I miei pensieri su come iniziare ma non sono sicuro su come finire:

1. Questo è chiaramente MOLTO disordinato, quindi sto proponendo di scegliere un'unità di misura standard in cui archiviare tutti i dati per ciascuna merce e "tipo di utilizzo". Quindi, per l'elettricità, la nostra unità di energia standard sarebbe kWH e la nostra unità di potenza standard sarebbe kW. Quindi, per convertire qualsiasi altra unità di energia / potenza, avremmo solo bisogno di un tasso di conversione da / verso il nostro standard e non tutte le possibili combinazioni. Se mai avessimo bisogno di convertire da MW a W, possiamo sempre farlo convertendo in / da kW.
2. Poiché i tassi di conversione possono dipendere da un tempo specifico, dobbiamo consentire la possibilità per questo tempo di essere memorizzati in relazione alla misurazione. Sospetto che non dovremmo preoccuparci che questi tassi di conversione cambino più rapidamente di una volta all'ora e potremmo anche essere in grado di ipotizzare una volta al giorno.
3. Poiché i tassi di conversione possono dipendere dai valori pubblicati, dobbiamo consentire la memorizzazione di questo valore in relazione alla misurazione. Sospetto che non dovremmo preoccuparci che questi tassi di conversione cambino più rapidamente di una volta all'ora e potremmo anche essere in grado di ipotizzare una volta al giorno.
4. Dopo aver capito tutto, prevedo di creare un servizio Web che non fa altro che gestire tutte le conversioni di unità. NON sto cercando SQL per eseguire queste conversioni e posso fare un po 'di cache creativa per farlo, quindi non sto assolutamente martellando queste tabelle ma a volte dovrà gestire la conversione di ~ 400 valori per caricamento della pagina nel sito Web accessibile dall'utente . Non sono sicuro se / come questo sia importante.

Non so a quale livello dovrei memorizzare i tassi di conversione che non cambiano mai rispetto ai tassi di conversione che cambiano, ed esattamente come separarli da un modo che mi permetterà di accedervi rapidamente in un modo facile da lavorare con.

Qualche idea su come affrontare questo o anche qualche materiale di lettura pubblicato che potrebbe essere di aiuto? Sto usando SQL Server (che presto diventerà SQL Azure) ma questo non dovrebbe davvero importare. Lo schema per rappresentare correttamente questo è ciò di cui sto avendo problemi qui. Se fosse semplice come pollici contro centimetri, è facile. Ma i vari tassi di conversione sono il problema qui.

Ci sono alcune cose che vuoi considerare nel tuo design:

1. Le misurazioni richiedono un timestamp

Assicurati che tutte le tue misure abbiano un'indicazione di:

• Valore scalare
• Unità di misura
• Data e ora della misurazione

Ciò ti consentirà di lavorare con misurazioni che richiedono calcoli di conversione dipendenti dal tempo.

2. Le unità di misura hanno attributi

Ogni unità di misura ha alcuni attributi diversi. Quelli ovvi sono indicativi, come un codice e forse un nome descrittivo. Ci sono anche un paio di altri attributi critici da conservare per ogni unità di misura. (i) Tipo di unità e (ii) Fattore di conversione nell'unità base .

Il primo ti dice se la tua unità di misura è una lunghezza, un peso, energia, potenza, valuta, ecc. Ecc. Dovrebbe anche dirti qual è l'unità di misura base. Dovresti sceglierne esattamente uno per ogni tipo di unità. Puoi usare cose come kWh se vuoi, ma mi atterrerei alle unità SI di base (se applicabile) se fossi in te.

Il secondo indica quale unità di misura deve essere moltiplicata per portarla alla base. Ho detto che questo è un attributo del tuo UOM, ma in realtà deve essere in una tabella figlio. La chiave aziendale della tabella figlio che contiene questo fattore di conversione di base è la combinazione di UOM, il suo tipo di unità di base e una data / ora. Vorrei mantenere sia una data / ora effettiva che una scadenza sulla tabella dei fattori di conversione di base. Ciò ti consente di trovare rapidamente la giusta tariffa che si applica in un determinato momento. Se capita che sia un tasso che non cambia, va bene. Basta usare una data di decorrenza minima di fascicolazione e una data di scadenza di fascicolazione massima per un record.

3. Provare a guidare il tavolo Tutto ti farà impazzire L'ultimo pezzo del puzzle è determinare il calcolo per passare da un tipo di unità a un altro tipo di unità. Potresti provare a guidare questo tipo di calcolo, ma alla fine quelli difficili renderanno il design così generale (leggi complicato e lento) che sarà impraticabile. Invece, crea una tabella di codici per i calcoli di conversione e usala per collegare un tipo di Tipo unità a un altro tipo di Tipo unità. Esegui i calcoli reali in qualche codice da qualche parte. Quale parte di codice usi per una determinata conversione è ciò che ti dice la tabella dei codici. Come viene eseguito il calcoloè solo nel codice. Puoi avere un calcolo ciascuno per le varie cose facili, come l'area ha bisogno di due lunghezze e il volume ha bisogno di tre lunghezze, mentre quelli più difficili come il lavoro hanno bisogno di energia e tempo.

Quando avrai capito i dettagli del tuo design, dovresti blog e tornare qui per pubblicare un link!

Questo è qualcosa per cui puoi utilizzare le visualizzazioni o le query. Avere una tabella con i dati non elaborati e un'altra con il rapporto di conversione che è necessario applicare, magari con una data o alcune altre informazioni se il rapporto da applicare è sensibile al tempo o alla situazione. Quindi creare una query o una vista che esegua la conversione necessaria unendo le tabelle. In questo modo è possibile modificare il valore del rapporto di conversione come richiesto e ricalcolare.

Esempio semplice (PostgreSQL) per uno scenario ipotetico, il tuo sarà diverso:

CREATE TABLE join_test.amounts
(
  amount integer,
  unit character varying(10)
);

CREATE TABLE join_test."conversion"
(
  unit character varying(10),
  ratio integer
);

insert into join_test.amounts ( amount,unit) values (10 , 'dollar' );
insert into join_test.amounts ( amount,unit) values (10 , 'euro' );
insert into join_test.amounts ( amount,unit) values (15 , 'dollar' );
insert into join_test.amounts ( amount,unit) values (15 , 'euro' );

insert into join_test.conversion ( unit, ratio) values ('dollar', 2 );
insert into join_test.conversion ( unit, ratio) values ('euro', 3 );

-- create this as a view
select a.amount, c.ratio, a.amount * c.ratio as "result"
from    join_test.amounts a,
    join_test.conversion c
where a.unit = c.unit
and   c.unit = 'euro'
and   a.unit = 'euro'   ;