análisis dimensional y de unidades en bases de datos SQL

Question

Problema:

Una base de datos relacional (Postgres) que almacena datos de series de tiempo de varios valores de medición. Cada valor de medición puede tener un tipo de medición específico (p. ej., temperatura, oxígeno disuelto, etc.) y puede tener unidades de medida específicas. (por ejemplo, Fahrenheit / Celsius / Kelvin, porcentaje / miligramos por litro, etc.).

Pregunta:

¿Alguien ha construido una base de datos similar para conservar la integridad dimensional? ¿Tienes alguna sugerencia?

Estoy considerando construir una tabla measure_type y measure_unit, ambas tendrían dos columnas de texto, ID y texto. Luego crearía claves foráneas para estas tablas en la tabla medición_valor. El texto me preocupa un poco porque existe la posibilidad de duplicados no únicos (por ejemplo, 'ug / l' vs '& # 181; g / l' para microgramos por litro).

El propósito de esto sería para poder convertir y verificar unidades en consultas o mediante programación externa. Idealmente, tendría la posibilidad de incluir análisis dimensionales estrictos (por ejemplo, vincular & # 181; g / l al valor 'M / V' (masa dividida por volumen)).

¿Hay una manera más elegante de lograr esto?

Answer 1

Hace un eón elaboré un sub-esquema de base de datos para manejar unidades (está bien, exagero un poco; sin embargo, fue hace unos 20 años). Afortunadamente, solo tenía que lidiar con la masa simple, la longitud, las dimensiones de tiempo, no la temperatura, la corriente eléctrica o la luminosidad, etc. Más bien menos simple era el lado monetario del juego: había una miríada de formas diferentes de convertir entre una moneda y otro dependiendo de la fecha, moneda y período durante el cual la tasa de conversión fue válida. Eso se manejó por separado de las unidades físicas.

Fundamentalmente, creé una tabla 'medidas' con una columna 'id', un nombre para la unidad, una abreviatura y un conjunto de exponentes de dimensión, uno para masa, longitud y tiempo. Esto se llena con nombres como 'volumen' (longitud = 3, masa = 0, tiempo = 0), 'densidad' (longitud = 3, masa = -1, tiempo = 0), y similares.

Había una segunda tabla de unidades, que identificaba una medida y luego las unidades reales utilizadas por una medida particular. Por ejemplo, había barriles y metros cúbicos, y todo tipo de otras unidades de relevancia.

Había una tercera tabla que definía los factores de conversión entre unidades específicas. Esto consistió en dos unidades y el factor de conversión multiplicativo que convirtió la unidad 1 en la unidad 2. El mayor problema aquí fue el rango dinámico de los factores de conversión. Si la conversión de U1 a U2 es 1.234E + 10, entonces el inverso es un número bastante pequeño (8.103727714749e-11).

El comentario de S.Lott sobre las temperaturas es interesante, no tuvimos que lidiar con eso. Un procedimiento almacenado habría abordado eso, aunque integrar un procedimiento almacenado en el sistema podría haber sido complicado.

El esquema que describí permitió que la mayoría de las conversiones se describieran una vez (incluidas unidades hipotéticas como furlongs por quincena o menos hipotéticas pero igualmente oscuras, fuera de los EE. UU., como acre-pies), y las conversiones podrían validarse (para ejemplo, ambas unidades en la tabla de factores de conversión tenían que tener la misma medida). Podría extenderse para manejar la mayoría de las otras unidades, aunque las unidades adimensionales como los ángulos (o ángulos sólidos) presentan algunos problemas interesantes. Hubo código de soporte que manejaría las conversiones arbitrarias, o generaría un error cuando la conversión no pudiera ser soportada. Una razón para este sistema fue que las diversas compañías afiliadas internacionales informaban sus datos en sus unidades localmente convenientes, pero el sistema HQ tenía que aceptar los datos originales y presentar los datos agregados resultantes en unidades que se adaptaban a los gerentes, donde cada uno de los gerentes era diferente. tenían su propia idea (basada en sus antecedentes nacionales y duración del servicio en la sede) sobre las mejores unidades para sus informes.

Answer 2

" El texto me preocupa un poco porque existe la posibilidad de duplicados no únicos "

Correcto. Así que no uses el texto como clave. Use la ID como clave.

" ¿Hay alguna forma más elegante de lograr esto? "

No realmente. Es dificil. La temperatura es un problema propio porque la temperatura es en sí misma un promedio y no se suma como lo hace la distancia; más la conversión de F a C no es una multiplicación (como lo es con cualquier otra conversión de unidad).

Answer 3

Una nota sobre las conversiones: muchas unidades están relacionadas linealmente y se pueden convertir usando una fórmula como `` y = A + Bx '', donde A y B son constantes que podrían almacenarse en la base de datos para cada par de unidades entre las que necesita convertir. Por ejemplo, para grados Celsius a Farenheit las constantes son A = 32, B = 1.8.

Sin embargo, también hay raras excepciones. Conversión entre unidades logarítmicas y no logarítmicas, por ejemplo. O convertir entre masa por volumen y masa molar por volumen (en cuyo caso, necesitaría saber la masa molar del compuesto que se está midiendo).

Por supuesto, si está seguro de que todas las conversiones requeridas por el sistema son lineales, entonces no hay necesidad de ingeniería excesiva, solo almacene las dos constantes. Luego puede extraer resultados estandarizados de la base de datos utilizando uniones SQL directas con campos calculados.