O que é uma boa estrutura relacional para unidades e complexas conversões de unidades?

Minha empresa está no setor de energia e preciso criar uma boa maneira de representar a conversão de unidades de medida. Eu fiz algumas pesquisas e ainda não encontrei um bom artigo abordando isso na profundidade necessária. A maioria das informações publicadas sobre conversões de unidades pressupõe que, dada a Unidade 1, há uma taxa de conversão conhecida (codificada) para chegar à Unidade 2 e é uma matemática simples ( este é o exemplo mais complexo que encontrei que ainda não ajuda). No entanto, isso nem sempre é verdade no mundo real e certamente não é verdade para o que devemos lidar. (Desculpe pelo longo artigo - estou tentando fornecer o máximo de informações possível!)

Exemplo complicado 1: algumas conversões variam com o tempo, como a conversão de US $ 5 para euros ou vice-versa. Parece que isso não tem nada a ver com energia, mas sim no mercado de commodities de energia (pense no mercado de ações).

Exemplo complicado 2: (simplificado demais ) Algum gás natural queima mais quente que outros . Além disso, o gás natural pode ser medido / armazenado com base na energia do gás (como terminas ) OU com base no volume do referido gás (como o MCF, que tem 1000 pés cúbicos), e também existem outras possibilidades (como como Ton para massa ). Uma analogia da gasolina é que 1 galão de 87-octano sem chumbo fornece menos energia que 1 galão de 93-octano sem chumbo.

Exemplo complicado 3: Além de ter essas unidades de medida, também precisamos lidar com taxas, como $ por Therm ou € por MCF . Portanto, precisamos de alguma maneira de trabalhar com essas taxas e como elas se relacionam com as unidades base. Se precisarmos converter de $ por Therm para € por MCF , podemos e ele utiliza as mesmas taxas publicadas da conversão de Therm para MCF .

Exemplo complicado 4: Anteriormente, usei o termo energia de maneira muito vaga e, às vezes, incorreta. Neste ponto e de agora em diante, isso está mudando. Portanto, a última curva é que lidamos com energia e potência . Com eletricidade, isso significa kWH versus kW ( uma explicação bastante boa, apesar de ser o Yahoo Answers ). Uma analogia de dados: seria como comparar o total de MB de dados baixados versus seu Mbpslargura de banda fornecida pelo seu ISP. Como os dados, a energia leva tempo para ser entregue. Continuando com a analogia dos dados, talvez tenhamos que calcular a largura de banda efetiva média consumida durante um período de tempo, portanto, considerando que 60 MB foram baixados em 1 minuto, a taxa "efetiva" seria 60 * 8/60 = 8Mbps. O "truque" aqui é que, se armazenarmos Mbps como uma unidade, precisaremos de alguma maneira de relacioná-lo diretamente a um MB , mesmo que também envolva um componente de tempo. FORTUNAMENTE, a conversão de energia em energia (ou vice-versa) é uma coisa bastante rara a ser feita, portanto nossa solução deve ser otimizada para todos os outros exemplos complicados e, com sorte, permitir esse também, mas não lidar com os problemas relacionados. Energiaa potência é uma opção.

Exemplo complicado 5: Isso é essencialmente 3 + 4. Podemos ter US $ por KW e US $ por KWh , portanto as tarifas lidam com potência e energia .

Exemplo fácil: algumas conversões são muito fáceis e são essas as que mais informações na Web podem gerenciar. 1000 Wh = 1kWh e tal. O mesmo ocorre com Termas e Decatherms ou kW em MW, etc. Não preciso de ajuda aqui, mas lembre-se de que ~ 70% de nossas conversões serão desse tipo.

Meus pensamentos sobre como começar, mas não tenho certeza sobre como terminar:

1. Isso é claramente MUITO confuso, por isso proponho que escolhamos uma unidade de medida padrão para armazenar todos os dados de cada mercadoria e "tipo de uso". Portanto, para eletricidade, nossa unidade de energia padrão seria kWH e nossa unidade de energia padrão seria kW. Portanto, para converter em qualquer outra unidade de energia / potência, precisaríamos apenas de uma taxa de conversão de / para nosso padrão e nem todas as combinações possíveis. Se precisarmos converter de MW para W, sempre podemos fazer isso convertendo para / de kW.
2. Como as taxas de conversão podem depender de um tempo específico, devemos permitir que a capacidade desse tempo seja armazenada em relação à medição. Eu suspeito que não precisamos nos preocupar com a alteração dessas taxas de conversão mais rapidamente do que uma vez por hora, e podemos até assumir isso uma vez por dia.
3. Como as taxas de conversão podem depender dos valores publicados, devemos permitir que esse valor seja armazenado em relação à medição. Eu suspeito que não precisamos nos preocupar com a alteração dessas taxas de conversão mais rapidamente do que uma vez por hora, e podemos até assumir isso uma vez por dia.
4. Depois que tudo isso for descoberto, prevejo a criação de um serviço da Web que não faz nada além de lidar com todas as conversões de unidade. NÃO estou procurando SQL para executar essas conversões e posso fazer um cache criativo para fazê-lo, de modo que não estou absolutamente martelando essas tabelas, mas às vezes será necessário lidar com a conversão de ~ 400 valores por carregamento de página no site acessado pelo usuário . Não tenho certeza se / como isso importa.

Não sei em que nível devo armazenar as taxas de conversão que nunca mudam versus as taxas de conversão que mudam e exatamente como encerrá-las de uma maneira que permita que eu as acesse rapidamente de uma maneira fácil de trabalhar com.

Alguma idéia de como lidar com este ou mesmo algum material de leitura publicado que possa ajudar? Estou usando o SQL Server (que em breve será o SQL Azure), mas isso realmente não deve importar. O esquema para representar corretamente isso é com o que estou tendo problemas aqui. Se fosse tão simples quanto polegadas versus centímetros, é fácil. Mas as taxas de conversão variadas são o problema aqui.

Há algumas coisas que você deseja levar em consideração no seu design:

1. As medidas precisam de um carimbo de data / hora

Verifique se todas as suas medidas têm uma indicação de:

• Valor escalar
• Unidade de medida
• Data e hora em que a medição foi realizada

Isso permitirá que você trabalhe com medições que precisam de cálculos de conversão dependentes do tempo.

2. Unidades de medida possuem atributos

Cada unidade de medida possui alguns atributos diferentes. Os óbvios são indicativos, como um código e talvez um nome descritivo. Há também alguns outros atributos críticos a serem mantidos para cada unidade de medida. (i) Tipo de Unidade e (ii) Fator de Conversão para a Unidade Base .

O primeiro informa se sua unidade de medida é um comprimento, um peso, energia, potência, moeda, etc. etc. Também deve informar qual é a unidade de medida básica. Você deve escolher exatamente um para cada tipo de unidade. Você pode usar coisas como kWh, se quiser, mas eu me ateria às unidades SI de base (conforme aplicável) se eu fosse você.

O segundo diz a você que sua unidade de medida precisa ser multiplicada para chegar à base. Mencionei que esse é um atributo do seu UOM, mas na verdade ele precisa estar em uma tabela filho. A chave comercial da tabela filha que contém esse fator de conversão base é a combinação da UOM, seu tipo de unidade base e uma data / hora. Eu manteria uma data / hora efetiva e uma data de validade na tabela de fatores de conversão base. Isso permite que você encontre rapidamente a taxa certa que se aplica a qualquer momento específico. Se acontecer de ser uma taxa que não muda, tudo bem. Basta usar uma data efetiva de intercalação mínima e uma data de vencimento de intercalação máxima para o registro.

3. Tentando conduzir tudo à mesa, você ficará louco A última peça do quebra-cabeça é determinar o cálculo para passar de um tipo de unidade para outro tipo de unidade. Você pode tentar conduzir esse tipo de cálculo de tabela, mas, no final, os mais complicados tornarão o design tão geral (ler complicado e lento) que será impraticável. Em vez disso, crie uma tabela de códigos de cálculos de conversão e use-a para vincular um tipo de tipo de unidade a outro tipo de tipo de unidade. Execute os cálculos reais em algum código em algum lugar. Qual parte do código que você usa para qualquer conversão é o que a tabela de códigos diz. Como o cálculo é realizadoestá apenas no código. Você pode fazer um cálculo para as várias coisas fáceis, como a área precisa de dois comprimentos e o volume precisa de três comprimentos, e os mais difíceis, como o trabalho, precisam de energia e tempo.

Quando você descobrir os detalhes do seu design, deverá enviá-lo ao blog e voltar aqui para postar um link!

É algo para o qual você pode usar visualizações ou consultas. Tenha uma tabela com os dados brutos e outra com a taxa de conversão que você precisa aplicar - talvez com uma data ou outras informações, se a taxa a aplicar for sensível à hora ou à situação. Em seguida, crie uma consulta ou exibição que faça a conversão necessária juntando as tabelas. Dessa forma, você pode alterar o valor da taxa de conversão conforme necessário e recalcular.

Exemplo simples (PostgreSQL) para um cenário hipotético, o seu será diferente:

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'   ;