analyse dimensionnelle et unitaire dans une base de données SQL

Question

Problème:

Une base de données relationnelle (Postgres) stockant des données temporelles de différentes valeurs de mesure. Chaque valeur de mesure peut avoir un "type de mesure" spécifique. (par exemple, la température, l'oxygène dissous, etc.) et peuvent avoir des "unités de mesure" spécifiques. (par exemple, Fahrenheit / Celsius / Kelvin, pourcentage / milligrammes par litre, etc.).

Question:

Quelqu'un a-t-il construit une base de données similaire afin de préserver l'intégrité dimensionnelle? Avez-vous des suggestions?

J'envisage de créer un type de mesure et une table de unités de mesure. Ces deux types de texte auraient deux colonnes de texte, ID et texte. Ensuite, je créerais des clés étrangères pour ces tables dans la table mesurée_valeur. Le texte m’inquiète un peu parce qu’il est possible de faire des doublons non uniques (par exemple, «ug / l» ou «µg / l» pour des microgrammes par litre).

Le but de cette opération serait que je puisse à la fois convertir et vérifier des unités sur des requêtes ou via une programmation externe. Dans l’idéal, j’aurais la possibilité d’inclure plus tard une analyse dimensionnelle stricte (par exemple, en liant µg / l à la valeur 'M / V' (masse divisée par le volume)).

Existe-t-il un moyen plus élégant d'y parvenir?

Answer 1

J'ai produit un sous-schéma de base de données pour la gestion des unités il y a quelque temps (bien, j'exagère légèrement; c'était il y a environ 20 ans, cependant). Heureusement, il ne s’agissait que de simples masses, longueurs, dimensions temporelles - pas de température, ni de courant électrique, ni de luminosité, etc. Le côté monétaire du jeu était un peu moins simple - il existait une multitude de façons de convertir une devise unique. et un autre en fonction de la date, de la devise et de la période sur laquelle le taux de conversion était valide. Cela a été traité séparément des unités physiques.

Fondamentalement, j'ai créé un tableau "mesures" avec une colonne "id", un nom pour l'unité, une abréviation et un ensemble d'exposants de dimensions, un pour la masse, la longueur et le temps. Des noms tels que "volume" (longueur = 3, masse = 0, temps = 0), "densité" (longueur = 3, masse = -1, temps = 0), etc. sont ajoutés.

Un deuxième tableau d’unités identifiant une mesure, puis les unités réellement utilisées par une mesure donnée. Par exemple, il y avait des barils, des mètres cubes et toutes sortes d'autres unités pertinentes.

Un troisième tableau définissait les facteurs de conversion entre des unités spécifiques. Il s’agissait de deux unités et du facteur de conversion multiplicatif qui convertissait l’unité 1 en unité 2. Le principal problème était la plage dynamique des facteurs de conversion. Si la conversion de U1 en U2 est 1.234E + 10, l’inverse est plutôt petit (8.103727714749e-11).

Le commentaire de S.Lott sur les températures est intéressant - nous n’avons pas eu à nous en occuper. Une procédure stockée aurait résolu ce problème - bien qu’intégrer une procédure stockée dans le système aurait pu être délicat.

Le schéma que j'ai décrit permettait de décrire une seule fois la plupart des conversions (y compris des unités hypothétiques telles que des intervalles de temps par quinzaine, ou des unités moins hypothétiques mais tout aussi obscures - en dehors des États-Unis - comme des acres), et les conversions pourraient être validées (par exemple. exemple, les deux unités de la table des facteurs de conversion devaient avoir la même mesure). Il pourrait être étendu à la plupart des autres unités, bien que les unités sans dimension telles que les angles (ou les angles pleins) posent des problèmes intéressants. Il existait un code de prise en charge capable de gérer des conversions arbitraires - ou de générer une erreur lorsque la conversion ne pouvait pas être prise en charge. Une des raisons de ce système était que les différentes sociétés affiliées internationales communiquaient leurs données dans leurs unités locales, mais le système du siège devait accepter les données d'origine et présenter les données agrégées résultantes dans des unités adaptées aux gestionnaires - chacun gérant avaient leur propre idée (en fonction de leurs antécédents nationaux et de la durée de leur mandat au siège) des meilleures unités pour leurs rapports.

Answer 2

"Le texte m'inquiète un peu parce qu'il est possible que des doublons ne soient pas uniques"

D'accord. Donc, n'utilisez pas le texte comme clé. Utilisez l'identifiant comme clé.

"Existe-t-il un moyen plus élégant d'y parvenir?"

Pas vraiment. C'est dur. La température est un problème en soi, car la température est elle-même une moyenne et ne correspond pas à la distance; plus la conversion de F à C n’est pas une multiplication (comme c’est le cas pour toutes les autres conversions d’unités.)

Answer 3

Remarque à propos des conversions: de nombreuses unités sont liées linéairement et peuvent être converties à l'aide d'une formule du type "y = A + Bx", où A et B sont des constantes pouvant être stockées dans la base de données pour chaque paire de unités que vous devez convertir entre. Par exemple, pour Celsius à Farenheit, les constantes sont A = 32, B = 1.8.

Cependant, il existe également de rares exceptions. Conversion entre unités logarithmiques et non logarithmiques, par exemple. Ou conversion entre masse par volume et masse molaire par volume (dans ce cas, vous devez connaître la masse molaire du composé à mesurer).

Bien sûr, si vous êtes sûr que toutes les conversions requises par le système sont linéaires, inutile de trop d’ingénierie, stockez simplement les deux constantes. Vous pouvez ensuite extraire des résultats standardisés de la base de données en utilisant des jointures SQL directes avec des champs calculés.