単位と複雑な単位変換に適した関係構造は何ですか？

私の会社はエネルギー業界に属しており、測定単位の変換を表す良い方法を考え出す必要があります。私はいくつかの検索を行ったが、必要な深さでこれをカバーする良い記事をまだ見つけていない。ユニット変換について公開されているほとんどの情報は、ユニット1が与えられた場合、ユニット2に到達するための既知の（ハードコードされた）変換率があり、それが単純な計算であることを前提としています（これは私が見つけた中で最も複雑な例で、まだ役に立ちません）。ただし、これは現実の世界では常に当てはまるわけではなく、処理しなければならないことについても当てはまりません。（長い記事で申し訳ありません-私はできるだけ多くの情報を提供しようとしています！）

トリッキーな例1： $ 5をユーロに、またはその逆に変換するなど、一部の変換は時間とともに変化します。これはエネルギーとは何の関係もないように聞こえますが、実際にはエネルギー商品市場（株式市場を考えてください）に関係しています。

トリッキーな例2：（ 過度に簡略化された）一部の天然ガスは他のものよりも熱く燃えます。さらに、天然ガスは、ガスのエネルギー（Thermsなど）またはガスの体積（MCFなどの1000立方フィート）に基づいて測定/保存でき、その他の可能性（たとえばトンのためのミサ）。ガソリンの類推は、87オクタン無鉛の1ガロンが、93オクタン無鉛の1ガロンよりも少ないエネルギーを提供することです。

トリッキーな例3： これらの測定単位があることに加えて、サームあたりの$またはMCFあたりの€などのレートも処理する必要があります。これらのレートで動作するようにいくつかの方法が必要で、どのように彼らは我々がから変換する必要がある場合に、ベースユニットに関連する我々はそうサームあたり$にMCFあたり€、我々はできるし、それからの変換と同じ公表レートを利用しサームにMCF。

トリッキーな例4： 以前は、「エネルギー」という用語を非常に緩く使用し、場合によっては誤って使用したことがあります。この時点で、そしてこれからは、状況が変わります。したがって、最後のカーブボールは、エネルギーとパワーの両方を扱うことです。電気の場合、これはkWH対kWを意味します（Yahoo Answersであるにもかかわらず、かなり良い説明です）。データの類推：ダウンロードしたデータの合計MBとMbpsを比較するようなものですISPが提供する帯域幅。データと同様に、エネルギーの供給には時間がかかります。データの類推を続けると、ある期間にわたって消費された平均有効帯域幅を計算する必要がある場合があるため、60MBが1分間にダウンロードされた場合、「有効」レートは60 * 8/60 = 8Mbpsになります。ここでの「トリック」は、Mbpsをユニットとして保存する場合、時間コンポーネントも含みますが、MBに直接関連付ける何らかの方法が必要であることです。幸いなことに、エネルギーから電力（またはその逆）への変換は、私たちが行う必要があるかなりまれなことです。そのため、私たちのソリューションは、他のすべてのトリッキーな例に合わせて最適化し、うまくいけば、この例も可能にする必要がありますが、関連する処理は行いません。エネルギー電源へのオプションです。

トリッキー例5： これは基本的に3 + 4である我々は両方持っているかもしれKWあたり$だけでなく、キロワット時あたりの$を、その速度は、両方を扱うパワーとエネルギー。

簡単な例： 一部の変換は非常に簡単で、これらはWeb上のほとんどの情報が処理できる変換です。1000 Wh = 1kWhなど。サームとデサームまたはkWからMWなどでも同じことが言えます。ここでは手助けは必要ありませんが、変換の約70％がこのタイプになることに注意してください。

開始方法についての私の考えですが、終了方法については不明です：

1. これは明らかに非常に厄介なので、各商品と「使用タイプ」のすべてのデータを格納するために標準測定単位を選択することを提案します。したがって、電気の場合、標準のエネルギー単位はkWH、標準の電力単位はkWになります。したがって、他のエネルギー/電力単位に変換するには、すべての可能な組み合わせではなく、標準との間の変換率のみが必要です。MWからWに変換する必要がある場合は、kWへの変換またはkWからの変換によっていつでも実行できます。
2. 変換率は特定の時間に依存する可能性があるため、この時間を測定に関連して保存できるようにする必要があります。これらのコンバージョン率が1時間に1回以上変化することを心配する必要はなく、1日1回と想定することもできると思います。
3. 変換率は公開された値に依存する可能性があるため、この値を測定に関連して保存できるようにする必要があります。これらのコンバージョン率が1時間に1回以上変化することを心配する必要はなく、1日1回と想定することもできると思います。
4. これがすべて理解できたら、すべての単位変換を処理する以外に何もしないWebサービスを作成することを期待しています。私はこれらの変換を実行するSQLを探していません。それを作成するためにいくつかの創造的なキャッシュを行うことができるので、これらのテーブルを完全にハンマー処理するわけではありませんが、ユーザーがアクセスするWebサイトでページの読み込みあたり〜400の値の変換を処理する必要がある場合があります。これが重要かどうか、どのように重要かはわかりません。

変わらないコンバージョン率と変わらないコンバージョン率をどのレベルで保存すればよいかわからず、簡単に簡単にアクセスできる方法で正確にキーオフする方法もわかりませんと連携。

これに取り組む方法、または役立つ可能性のあるいくつかの公開されたリーディングマテリアルに取り組む方法についての考えは？私はSQL Serverを使用しています（間もなくSQL Azureになります）が、これは特に問題にはなりません。これを適切に表すためのスキーマが、ここで問題になっています。インチとセンチメートルのように単純なものであれば、簡単です。しかし、ここでは変換率の違いが問題です。

設計に考慮したいことがいくつかあります。

1.測定にはタイムスタンプが必要

すべての測定値が次のことを示していることを確認してください。

• スカラー値
• 測定単位
• 測定が行われた日時

これにより、時間に依存する変換計算を必要とする測定を処理できます。

2.測定単位には属性があります

各測定単位には、いくつかの異なる属性があります。明白なものは、コードのように、おそらく説明的な名前です。また、測定単位ごとに保持する重要な属性がいくつかあります。（i）ユニットタイプおよび（ii）ベースユニットへの変換係数。

1つ目は、測定単位が長さ、重量、エネルギー、パワー、通貨などであるかどうかを示します。また、基本測定単位が何であるかも示します。ユニットタイプごとに1つだけ選択する必要があります。必要に応じてkWhのようなものを使用できますが、私なら、基本SI単位（該当する場合）を使用します。

2番目は、ベースに到達するために乗算する必要がある測定単位を示します。これはUOMの属性であると述べましたが、実際には子テーブルにある必要があります。この基本変換係数を保持する子テーブルのビジネスキーは、UOM、その基本単位タイプ、および日付/時刻の組み合わせです。ベース変換係数テーブルに有効と有効期限の両方の日時を保持します。これにより、特定の時点で適用される適切なレートをすばやく見つけることができます。レートが変わらない場合は、問題ありません。1つのレコードに対して、最小照合有効日と最大照合有効期限を使用するだけです。

3.すべてをテーブル駆動にしようとすると、あなたはナッツ になりますパズルの最後のピースは、ある種類のユニットから別の種類のユニットに移動するための計算を決定することです。この種の計算をテーブル駆動にしようとすることもできますが、結局のところ、トリッキーな計算では、設計が一般的（複雑で遅い）になり、実用的ではなくなります。代わりに、変換計算のコードテーブルを作成し、それを使用してある種類のユニットタイプを別の種類のユニットタイプにリンクします。どこかのコードで実際の計算を実行します。 特定の変換にどのコードを使用するかは、コード表に示されています。 計算方法コード内にあります。面積は2つの長さを必要とし、体積は3つの長さを必要とし、作業のようなより難しいものはエネルギーと時間を必要とするなど、さまざまな簡単な事柄に対して1つずつ計算できます。

デザインの詳細がわかったら、それをブログに投稿し、ここに戻ってリンクを投稿してください。

これは、ビューまたはクエリを使用できるものです。生データと、適用する必要のある変換比率を持つ1つのテーブルを用意します。適用する比率が時間や状況に左右される場合は、日付などの情報を使用してください。次に、テーブルを結合して必要な変換を行うクエリまたはビューを作成します。このようにして、必要に応じて変換比率値を変更し、再計算できます。

架空のシナリオの簡単な例（PostgreSQL）では、実際のシナリオは異なります。

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