Qu'est-ce qu'une bonne structure relationnelle pour les unités et les conversions d'unités complexes?

Mon entreprise est dans le secteur de l'énergie et je dois trouver un bon moyen de représenter la conversion des unités de mesure. J'ai fait quelques recherches et je n'ai pas encore trouvé un bon article couvrant cela à la profondeur dont j'ai besoin. La plupart des informations publiées sur les conversions d'unités supposent que, compte tenu de l'unité 1, il existe un taux de conversion connu (codé en dur) pour accéder à l'unité 2 et il s'agit de calculs simples ( c'est l'exemple le plus complexe que j'ai trouvé qui n'aide toujours pas). Cependant, ce n'est pas toujours vrai dans le monde réel et ce n'est certainement pas vrai pour ce que nous devons gérer. (Désolé pour la longue rédaction - j'essaie de fournir autant d'informations que possible!)

Exemple délicat 1: certaines conversions varient avec le temps, comme la conversion de 5 $ en euros ou vice versa. On dirait que cela n'a rien à voir avec l'énergie, mais c'est vraiment le cas sur le marché des matières premières énergétiques (pensez au marché boursier).

Exemple délicat 2: (simplifié à outrance) Certains gaz naturels brûlent plus chaud que d'autres . De plus, le gaz naturel peut être mesuré / stocké soit en fonction de l' énergie contenue dans le gaz (comme les Thermes ) OU en fonction du volume dudit gaz (comme le MCF qui est de 1000 pieds cubes), et il existe également d'autres possibilités (telles que comme Ton pour la messe ). Une analogie avec l'essence est qu'un gallon de sans plomb à 87 octanes fournit moins d'énergie qu'un gallon de sans plomb à 93 octanes.

Exemple délicat 3: En plus d'avoir ces unités de mesure, nous devons également souvent faire face à des taux, tels que $ par Therm ou € par MCF . Nous avons donc besoin d'un moyen de travailler avec ces taux et leur relation avec les unités de base.Si nous devons convertir de $ par Therm en € par MCF , nous pouvons et il utilise les mêmes taux publiés que la conversion de Therm en MCF .

Exemple délicat 4: Auparavant, j'ai utilisé le terme Énergie de manière très lâche et peut-être parfois incorrectement. À ce stade et à partir de maintenant, cela change. Donc, la dernière courbe est que nous traitons à la fois l' énergie et la puissance . Avec l'électricité, cela signifie kWH contre kW ( une assez bonne explication malgré le fait qu'il s'agit de Yahoo Answers ). Une analogie de données: ce serait comme comparer le total de Mo de données téléchargées à vos Mbpsla bande passante que votre FAI vous fournit. Comme les données, l'énergie prend du temps à être livrée. En poursuivant l'analogie des données, nous pourrions avoir à calculer la bande passante effective moyenne consommée sur une période de temps, donc étant donné que 60 Mo ont été téléchargés sur 1 minute, le taux "effectif" serait de 60 * 8/60 = 8 Mbps. Le "truc" ici est que si nous stockons les Mbps comme une unité elle-même, nous avons également besoin d'un moyen de le relier directement à un Mo , même si cela implique également une composante temporelle. Heureusement, la conversion de l' énergie en énergie (ou vice versa) est une chose assez rare pour nous, donc notre solution devrait être optimisée pour tous les autres exemples délicats et, espérons-le, permettre celle-ci également, mais pas la gestion des relations Énergieau pouvoir est une option.

Exemple délicat 5: Il s'agit essentiellement de 3 + 4. Nous pouvons avoir à la fois $ par KW et $ par KWh , donc les tarifs concernent à la fois la puissance et l' énergie .

Exemple simple: certaines conversions sont très faciles et ce sont celles que la plupart des informations sur le Web peuvent gérer. 1000 Wh = 1 kWh et autres. Même chose avec Therms et Decatherms ou kW en MW, etc. Je n'ai pas besoin d'aide ici mais gardez à l'esprit que ~ 70% de nos conversions seront de ce type.

Mes réflexions sur la façon de commencer, mais je ne sais pas comment terminer:

1. C'est clairement TRÈS compliqué, donc je propose que nous choisissions une unité de mesure standard pour stocker toutes les données pour chaque produit et "type d'utilisation". Ainsi, pour l'électricité, notre unité d'énergie standard serait kWH et notre unité d'alimentation standard serait kW. Donc, pour convertir vers n'importe quelle autre unité d'énergie / puissance, nous n'aurions besoin que d'un taux de conversion vers / depuis notre standard et pas toutes les combinaisons possibles. Si jamais nous avons besoin de convertir de MW en W, nous pouvons toujours le faire en convertissant de / en kW.
2. Étant donné que les taux de conversion peuvent dépendre d'un moment précis, nous devons permettre la possibilité de stocker ce temps par rapport à la mesure. Je soupçonne que nous n'avons pas à nous inquiéter du fait que ces taux de conversion changent plus rapidement qu'une fois par heure et nous pourrions même être en mesure de supposer une fois par jour.
3. Étant donné que les taux de conversion peuvent dépendre des valeurs publiées, nous devons prévoir la possibilité de stocker cette valeur par rapport à la mesure. Je soupçonne que nous n'avons pas à nous inquiéter du fait que ces taux de conversion changent plus rapidement qu'une fois par heure et nous pourrions même être en mesure de supposer une fois par jour.
4. Une fois tout cela compris, je prévois de créer un service Web qui ne fait rien de plus que de gérer toutes les conversions d'unités. Je ne recherche PAS SQL pour effectuer ces conversions et je peux faire une mise en cache créative pour le faire, donc je ne martèle pas absolument ces tables, mais il devra parfois gérer la conversion de ~ 400 valeurs par chargement de page dans le site Web accessible par l'utilisateur . Je ne sais pas si / comment cela compte.

Je ne sais pas à quel niveau je dois stocker les taux de conversion qui ne changent jamais par rapport aux taux de conversion qui changent, et comment exactement les désactiver d'une manière qui me permettra d'accéder rapidement à ceux-ci d'une manière facile à travailler avec.

Avez-vous des réflexions sur la façon de résoudre ce problème ou même certains documents de lecture publiés qui pourraient être utiles? J'utilise SQL Server (bientôt SQL Azure) mais cela ne devrait pas vraiment avoir d'importance. Le schéma pour représenter correctement ceci est ce avec quoi j'ai du mal ici. Si c'était aussi simple que des pouces contre des centimètres, c'est facile. Mais les taux de conversion variables sont le problème ici.

Il y a quelques éléments que vous souhaitez prendre en compte dans votre conception:

1. Les mesures nécessitent un horodatage

Assurez-vous que toutes vos mesures ont une indication de:

• Valeur scalaire
• Unité de mesure
• Date et heure de la prise de mesure

Cela vous permettra de travailler avec des mesures qui nécessitent des calculs de conversion en fonction du temps.

2. Les unités de mesure ont des attributs

Chaque unité de mesure a quelques attributs différents. Les plus évidents sont indicatifs, comme un code et peut-être un nom descriptif. Il existe également quelques autres attributs essentiels à conserver pour chaque unité de mesure. (i) Type d'unité et (ii) Facteur de conversion en unité de base .

Le premier vous indique si votre unité de mesure est une longueur, un poids, une énergie, une puissance, une devise, etc. etc. Il doit également vous indiquer quelle est l'unité de mesure de base. Vous devez choisir exactement un pour chaque type d'unité. Vous pouvez utiliser des choses comme kWh si vous le souhaitez, mais je m'en tiendrai aux unités SI de base (le cas échéant) si j'étais vous.

La seconde vous indique ce que votre unité de mesure doit être multipliée par pour arriver à la base. J'ai mentionné qu'il s'agit d'un attribut de votre UOM, mais en fait, il doit être dans une table enfant. La clé métier de la table enfant qui contient ce facteur de conversion de base est la combinaison de l'UdM, de son type d'unité de base et d'une date / heure. Je conserverais à la fois une date / heure effective et une date d'expiration sur la table des facteurs de conversion de base. Cela vous permet de trouver rapidement le bon taux qui s'applique à tout moment particulier. S'il se trouve que c'est un taux qui ne change pas, c'est OK. Utilisez simplement une date effective de collationnement minimum et une date d'expiration de collationnement maximum pour le seul enregistrement.

3. Essayer de conduire sur table tout vous fera des noix La dernière pièce du puzzle est de déterminer le calcul pour passer d'un type d'unité à un autre type d'unité. Vous pouvez essayer de piloter ce type de calcul, mais à la fin, les calculs délicats vont rendre la conception si générale (lue compliquée et lente) qu'elle ne sera pas pratique. Au lieu de cela, créez une table de codes de calculs de conversion et utilisez-la pour lier un type de type d'unité à un autre type de type d'unité. Effectuez les calculs réels dans un code quelque part. Le morceau de code que vous utilisez pour une conversion donnée est ce que la table de code vous indique. Comment le calcul est effectuéest juste dans le code. Vous pouvez avoir un calcul chacun pour les différentes choses faciles, comme la zone a besoin de deux longueurs et le volume a besoin de trois longueurs ainsi que les plus difficiles comme le travail a besoin d'énergie et de temps.

Lorsque vous aurez compris les détails de votre design, vous devriez le bloguer et revenir ici pour publier un lien!

C'est quelque chose pour lequel vous pouvez utiliser des vues ou des requêtes. Ayez une table avec les données brutes et une autre avec le taux de conversion que vous devez appliquer - peut-être avec une date ou d'autres informations si le taux à appliquer est sensible au temps ou à la situation. Créez ensuite une requête ou une vue qui effectue la conversion dont vous avez besoin en joignant les tables. De cette façon, vous pouvez modifier la valeur du taux de conversion selon vos besoins et recalculer.

Exemple simple (PostgreSQL) pour un scénario hypothétique, le vôtre sera différent:

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