¿Cuál es una buena estructura relacional para unidades y conversiones de unidades complejas?

Mi compañía está en la industria de la energía y necesito encontrar una buena manera de representar la conversión de unidades de medida. He hecho algunas búsquedas y aún no he encontrado un buen artículo que cubra esto en la profundidad que necesito. La mayoría de la información publicada sobre las conversiones de unidades supone que, dada la Unidad 1, hay una tasa de conversión conocida (codificada) para llegar a la Unidad 2 y es matemática simple ( este es el ejemplo más complejo que he encontrado y que todavía no ayuda). Sin embargo, esto no siempre es cierto en el mundo real y ciertamente no es cierto para lo que debemos manejar. (Perdón por la larga reseña, ¡estoy tratando de proporcionar tanta información como sea posible!)

Ejemplo complicado 1: algunas conversiones varían con el tiempo, como convertir $ 5 a euros o viceversa. Esto suena como que no tiene nada que ver con la energía, pero realmente lo tiene en el mercado de productos básicos de energía (piense en el mercado de valores).

Ejemplo complicado 2: (simplificado en exceso) Algunos gases naturales arden más calientes que otros . Además, el gas natural puede medirse / almacenarse ya sea en función de la Energía en el gas (como Therms ) O en función del Volumen de dicho gas (como MCF, que es 1000 pies cúbicos), y también hay otras posibilidades (como como Ton para misa ). Una analogía de la gasolina es que 1 galón de 87 octanos sin plomo proporciona menos energía que 1 galón de 93 octanos sin plomo.

Ejemplo complicado 3: además de tener estas unidades de medida, a menudo también tenemos que lidiar con tasas, como $ por Therm o € por MCF . Por lo tanto, necesitamos alguna forma de trabajar con estas tarifas y cómo se relacionan con las unidades base, por lo que si necesitamos convertir de $ por Therm a € por MCF , podemos y utiliza las mismas tarifas publicadas que la conversión de Therm a MCF .

Ejemplo complicado 4: Anteriormente, he usado el término Energía muy libremente y posiblemente a veces incorrectamente. En este punto y de ahora en adelante, eso está cambiando. Entonces, la última curva es que tratamos tanto con energía como con potencia . Con electricidad, esto significa kWH versus kW ( una explicación bastante buena a pesar de ser Yahoo Answers ). Una analogía de datos: sería como comparar MB totales de datos descargados con sus Mbpsancho de banda que le proporciona su ISP. Al igual que los datos, la energía tarda en entregarse. Continuando con la analogía de los datos, es posible que tengamos que calcular el ancho de banda efectivo promedio consumido durante un período de tiempo, por lo que dado que se descargaron 60 MB en 1 minuto, la velocidad "efectiva" sería 60 * 8/60 = 8 Mbps. El "truco" aquí es que si almacenamos Mbps como una unidad en sí, también necesitamos alguna forma de relacionarlo directamente con un MB , aunque también implique un componente de tiempo. Afortunadamente, la conversión de Energía en Energía (o viceversa) es algo bastante raro que tenemos que hacer, por lo que nuestra solución debe optimizarse para todos los otros ejemplos difíciles y, con suerte, permitir este también, pero no manejar Energíaa la energía es una opción.

Ejemplo complicado 5: Esto es esencialmente 3 + 4. Es posible que tengamos tanto $ por KW como $ por KWh , por lo que las tarifas se refieren tanto a Potencia como a Energía .

Ejemplo sencillo : algunas conversiones son muy fáciles y estas son las que puede manejar la mayoría de la información en la web. 1000 Wh = 1kWh y tal. Lo mismo con Therms y Decatherms o kW a MW, etc. No necesito ayuda aquí, pero tenga en cuenta que ~ 70% de nuestras conversiones serán de este tipo.

Mis pensamientos sobre cómo comenzar pero no estoy seguro de cómo terminar:

1. Esto es claramente MUY desordenado, por lo que propongo que elijamos una unidad de medida estándar para almacenar todos los datos de cada producto y "tipo de uso". Entonces, para la electricidad, nuestra unidad de energía estándar sería kWH y nuestra unidad de energía estándar sería kW. Por lo tanto, para convertir a cualquier otra unidad de energía / potencia, solo necesitaríamos una tasa de conversión hacia / desde nuestro estándar y no todas las combinaciones posibles. Si alguna vez necesitamos convertir de MW a W, siempre podemos hacerlo mediante la conversión de / a kW.
2. Dado que las tasas de conversión pueden depender de un tiempo específico, debemos permitir que la capacidad de este tiempo se almacene en relación con la medición. Sospecho que no debemos preocuparnos de que estas tasas de conversión cambien más rápido que una vez por hora e incluso podríamos suponer una vez al día.
3. Dado que las tasas de conversión pueden depender de los valores publicados, debemos permitir que este valor se almacene en relación con la medición. Sospecho que no debemos preocuparnos de que estas tasas de conversión cambien más rápido que una vez por hora e incluso podríamos asumirlo una vez al día.
4. Después de que todo esto esté resuelto, preveo crear un servicio web que no haga nada más que manejar todas las conversiones de unidades. NO estoy buscando SQL para realizar estas conversiones y puedo hacer un almacenamiento en caché creativo para hacerlo, así que no estoy manipulando absolutamente estas tablas, pero a veces será necesario manejar la conversión de ~ 400 valores por carga de página en el sitio web al que accede el usuario . No estoy seguro si / cómo importa esto.

No sé a qué nivel debo almacenar las tasas de conversión que nunca cambian frente a las tasas de conversión que sí cambian, y exactamente cómo eliminarlas de una manera que me permita acceder rápidamente a ellas de una manera fácil trabajar con.

¿Alguna idea sobre cómo abordar esto o incluso algún material de lectura publicado que pueda ayudar? Estoy usando SQL Server (que pronto será SQL Azure) pero esto realmente no debería importar. El esquema para representar esto correctamente es con lo que estoy teniendo problemas aquí. Si fuera tan simple como pulgadas versus centímetros, es fácil. Pero las tasas de conversión variables son el problema aquí.

Hay algunas cosas que desea incluir en su diseño:

1. Las mediciones necesitan una marca de tiempo

Asegúrese de que todas sus mediciones tengan una indicación de:

• Valor escalar
• Unidad de medida
• Fecha y hora en que se realizó la medición

Esto le permitirá trabajar con mediciones que necesitan cálculos de conversión dependientes del tiempo.

2. Las unidades de medida tienen atributos

Cada unidad de medida tiene algunos atributos diferentes. Los obvios son indicativos, como un código y tal vez un nombre descriptivo. También hay un par de otros atributos críticos para mantener para cada unidad de medida. (i) Tipo de unidad y (ii) Factor de conversión a la unidad base .

El primero le dice si su unidad de medida es una longitud, un peso, energía, potencia, moneda, etc., etc. También debe decirle cuál es la unidad de medida base. Debe elegir exactamente uno para cada tipo de unidad. Puede usar cosas como kWh si lo desea, pero me quedaría con las unidades SI básicas (según corresponda) si fuera usted.

El segundo te dice por qué tu unidad de medida necesita multiplicarse para llegar a la base. Mencioné que este es un atributo de su UOM, pero de hecho debe estar en una tabla secundaria. La clave empresarial de la tabla secundaria que contiene este factor de conversión base es la combinación de la unidad de medida, su tipo de unidad base y una fecha / hora. Mantendría una fecha / hora efectiva y una fecha de vencimiento en la tabla del factor de conversión base. Esto le permite encontrar rápidamente la tasa correcta que se aplica en cualquier momento en particular. Si resulta ser una tasa que no cambia, está bien. Solo use una fecha efectiva de clasificación mínima y una fecha de vencimiento de clasificación máxima para el registro único.

3. Intentar conducir en la mesa todo te volverá loco La última pieza del rompecabezas es determinar el cálculo para pasar de un tipo de unidad a otro tipo de unidad. Podría intentar manejar este tipo de cálculo en la tabla, pero al final los complicados harán que el diseño sea tan general (lectura complicada y lenta) que no será práctico. En su lugar, cree una tabla de códigos de cálculos de conversión y úsela para vincular un tipo de Tipo de unidad a otro tipo de Tipo de unidad. Realice los cálculos reales en algún código en alguna parte. El código que utiliza para cualquier conversión es lo que le indica la tabla de códigos. Cómo se realiza el cálculosolo está en el código. Puede tener un cálculo para cada una de las cosas fáciles, como el área necesita dos longitudes y el volumen necesita tres longitudes, así como las más difíciles como el trabajo necesita energía y tiempo.

¡Cuando descubra los detalles de su diseño, debe publicarlo en un blog y volver aquí para publicar un enlace!

Esto es algo para lo que puede usar vistas o consultas. Tenga una tabla con los datos sin procesar y otra con la proporción de conversión que necesita aplicar, tal vez con una fecha o alguna otra información si la proporción a aplicar depende del tiempo o la situación. Luego, cree una consulta o vista que realice la conversión que necesita uniendo las tablas. De esta manera, puede cambiar el valor de la relación de conversión según sea necesario y volver a calcular.

Ejemplo simple (PostgreSQL) para un escenario hipotético, el suyo 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'   ;