Apa struktur relasional yang baik untuk konversi unit dan unit kompleks?

Perusahaan saya ada di industri Energi dan saya perlu menemukan cara yang baik untuk mewakili konversi satuan pengukuran. Saya sudah melakukan pencarian dan belum menemukan artikel bagus yang membahas hal ini pada kedalaman yang saya butuhkan. Sebagian besar info yang dipublikasikan tentang konversi unit mengasumsikan bahwa mengingat Unit 1 ada tingkat konversi yang diketahui (dikodekan) untuk menuju ke Unit 2 dan ini matematika sederhana ( ini adalah contoh paling kompleks yang saya temukan yang masih belum membantu). Namun, ini tidak selalu benar di dunia nyata dan tentu saja tidak benar untuk apa yang harus kita tangani. (Maaf untuk penulisan yang panjang - Saya mencoba memberikan info sebanyak mungkin!)

Contoh rumit 1: Beberapa konversi berbeda dengan waktu, seperti mengonversi $ 5 ke Euro atau sebaliknya. Ini kedengarannya tidak ada hubungannya dengan energi tetapi benar-benar terjadi di pasar komoditas energi (pikirkan pasar saham).

Contoh rumit 2: (Disederhanakan) Beberapa gas alam terbakar lebih panas daripada yang lain . Selain itu, gas alam dapat diukur / disimpan baik berdasarkan Energi dalam gas (seperti Therms ) ATAU berdasarkan Volume gas tersebut (seperti MCF yang 1000 Cubic Feet), dan ada kemungkinan lain juga (seperti sebagai Ton untuk Massa ). Analogi bensin adalah bahwa 1 galon 87-oktan Tanpa timbal menyediakan energi lebih sedikit dari 1 galon 93-oktan Tanpa timbal.

Contoh rumit 3: Selain memiliki unit pengukuran ini, kami juga sering harus berurusan dengan tarif, seperti $ per Therm atau € per MCF . Jadi kita perlu beberapa cara untuk bekerja dengan tarif ini dan bagaimana mereka berhubungan dengan unit dasar jadi jika kita perlu mengkonversi dari $ per Therm ke € per MCF , kita dapat dan menggunakan tarif yang diterbitkan sama seperti mengkonversi dari Therm ke MCF .

Contoh rumit 4: Sebelumnya, saya menggunakan istilah Energi dengan sangat longgar dan mungkin kadang-kadang salah. Pada titik ini dan mulai sekarang, itu berubah. Jadi bola curveball terakhir adalah bahwa kita berurusan dengan Energi dan Daya . Dengan listrik, ini berarti kWH versus kW ( penjelasan yang cukup bagus meskipun itu adalah Yahoo Answers ). Analogi data: ini seperti membandingkan total MB data yang diunduh dengan Mbps Andabandwidth yang disediakan ISP Anda untuk Anda. Seperti halnya data, energi membutuhkan waktu untuk dikirimkan. Melanjutkan dengan analogi data, kita mungkin harus menghitung bandwidth efektif rata-rata yang dikonsumsi selama periode waktu tertentu, jadi mengingat 60MB diunduh lebih dari 1 menit, tingkat "efektif" adalah 60 * 8/60 = 8Mbps. "Trik" di sini adalah bahwa jika kita menyimpan Mbps sebagai sebuah unit itu sendiri, kita perlu beberapa cara untuk menghubungkannya langsung ke MB juga meskipun itu juga melibatkan komponen waktu. FORTUNATELY, mengubah dari Energi ke Daya (atau sebaliknya) adalah hal yang cukup langka untuk kita lakukan, jadi solusi kita harus dioptimalkan untuk semua contoh rumit lainnya dan mudah-mudahan memungkinkan untuk yang satu ini juga, tetapi tidak menangani masalah terkait Energito Power adalah sebuah opsi.

Contoh rumit 5: Ini pada dasarnya adalah 3 + 4. Kita mungkin memiliki $ per KW dan $ per KWh , sehingga tarif berurusan dengan Power dan Energy .

Contoh mudah: Beberapa konversi sangat mudah dan ini adalah yang dapat ditangani oleh sebagian besar info di web. 1000 Wh = 1kWh dan semacamnya. Hal yang sama dengan Therms dan Decatherms atau kW ke MW, dll. Saya tidak perlu bantuan di sini, tetapi ingatlah bahwa ~ 70% dari konversi kami akan dari jenis ini.

Pikiranku tentang bagaimana memulai tetapi tidak yakin tentang bagaimana menyelesaikannya:

1. Ini jelas sangat SANGAT berantakan sehingga saya mengusulkan agar kami memilih unit pengukuran standar untuk menyimpan semua data untuk setiap komoditas dan "tipe penggunaan". Jadi untuk listrik, unit energi standar kami adalah kWH dan unit daya standar kami adalah kW. Jadi untuk mengkonversi ke unit energi / daya lain, kita hanya perlu tingkat konversi ke / dari standar kita dan tidak setiap kombinasi yang memungkinkan. Jika kita perlu mengkonversi dari MW ke W, kita selalu dapat melakukannya dengan cara mengkonversi ke / dari kW.
2. Karena tingkat konversi mungkin tergantung pada waktu tertentu, kami harus membiarkan kemampuan untuk waktu ini disimpan dalam kaitannya dengan pengukuran. Saya menduga kita tidak perlu khawatir tentang perubahan kurs ini yang berubah lebih cepat dari sekali dalam satu jam dan kita bahkan mungkin dapat mengasumsikan sekali sehari.
3. Karena tingkat konversi mungkin tergantung pada nilai yang dipublikasikan, kami harus memungkinkan kemampuan untuk nilai ini disimpan dalam kaitannya dengan pengukuran. Saya menduga kita tidak perlu khawatir tentang perubahan kurs ini yang berubah lebih cepat dari sekali dalam satu jam dan kita bahkan mungkin dapat mengasumsikan sekali sehari.
4. Setelah semua ini diketahui, saya mengantisipasi membuat layanan web yang tidak lebih dari menangani semua konversi unit. Saya TIDAK mencari SQL untuk melakukan konversi ini dan saya bisa melakukan beberapa caching kreatif untuk membuatnya jadi saya tidak benar-benar memalu tabel ini tetapi kadang-kadang perlu menangani konversi ~ 400 nilai per beban halaman di situs web yang diakses pengguna. . Saya tidak yakin apakah ini penting.

Saya tidak tahu pada tingkat apa saya harus menyimpan tingkat konversi yang tidak pernah berubah versus tingkat konversi yang berubah, dan bagaimana cara menguncinya dengan cara yang memungkinkan saya untuk dengan cepat mengaksesnya dengan cara yang mudah dilakukan. bekerja dengan.

Adakah pemikiran tentang cara mengatasi ini atau bahkan beberapa bahan bacaan yang diterbitkan yang mungkin bisa membantu? Saya menggunakan SQL Server (segera menjadi SQL Azure) tetapi ini seharusnya tidak terlalu penting. Skema untuk mewakili dengan tepat ini adalah apa yang saya mengalami masalah dengan di sini. Jika sesederhana inci versus sentimeter, itu mudah. Tetapi perbedaan tingkat konversi adalah masalah di sini.

Ada beberapa hal yang Anda ingin faktor ke dalam desain Anda:

1. Pengukuran Perlu cap waktu

Pastikan semua pengukuran Anda memiliki indikasi:

• Nilai skalar
• Unit Pengukuran
• Tanggal dan Waktu Pengukuran Diambil

Ini akan memungkinkan Anda bekerja dengan pengukuran yang memerlukan perhitungan konversi tergantung waktu.

2. Unit Ukur Memiliki Atribut

Setiap unit ukuran memiliki beberapa atribut yang berbeda. Yang jelas adalah indikasi, seperti kode dan mungkin nama deskriptif. Ada juga beberapa atribut penting lainnya untuk disimpan untuk setiap unit ukuran. (i) Jenis Unit dan (ii) Faktor Konversi ke Unit Dasar .

Yang pertama memberi tahu Anda apakah satuan ukuran Anda adalah panjang, berat, energi, kekuatan, mata uang, dll. Ini juga harus memberi tahu Anda apa satuan dasar pengukuran itu. Anda harus memilih tepat satu untuk setiap jenis unit. Anda dapat menggunakan hal-hal seperti kWh jika Anda suka, tapi saya akan tetap berpegang pada unit SI dasar (sebagaimana berlaku) jika saya adalah Anda.

Yang kedua memberi tahu Anda apa unit ukuran Anda perlu dikalikan dengan untuk mendapatkannya ke pangkalan. Saya menyebutkan bahwa ini adalah atribut dari UOM Anda, tetapi sebenarnya perlu di tabel anak. Kunci bisnis tabel anak yang memegang faktor konversi basis ini adalah kombinasi dari UOM, tipe unit dasarnya, dan tanggal / waktu. Saya akan menyimpan tanggal / waktu yang efektif dan kedaluwarsa pada tabel faktor konversi dasar. Ini memungkinkan Anda untuk dengan cepat menemukan tingkat yang tepat yang berlaku pada suatu titik waktu tertentu. Jika itu adalah tingkat yang tidak berubah, tidak apa-apa. Cukup gunakan tanggal efektif min-collating dan tanggal kedaluwarsa max-collating untuk satu catatan.

3. Mencoba Table-Drive Semuanya Akan Membuat Anda Kacang - kacangan Bagian terakhir dari teka-teki adalah menentukan perhitungan untuk bergerak dari satu jenis unit ke jenis unit lain. Anda bisa mencoba table-drive perhitungan semacam ini tetapi pada akhirnya yang rumit akan membuat desain begitu umum (baca rumit dan lambat) sehingga tidak praktis. Alih-alih, buat tabel kode perhitungan konversi dan gunakan untuk menautkan satu jenis Tipe Unit ke jenis Tipe Unit lainnya. Lakukan perhitungan aktual dalam beberapa kode di suatu tempat. Sepotong kode yang Anda gunakan untuk konversi apa pun yang diberikan tabel kode kepada Anda. Bagaimana perhitungan dilakukanhanya dalam kode. Anda dapat memiliki satu perhitungan masing-masing untuk berbagai hal mudah, seperti area membutuhkan dua panjang dan volume membutuhkan tiga panjang serta yang lebih sulit seperti pekerjaan membutuhkan energi dan waktu.

Ketika Anda mendapatkan rincian desain Anda tahu Anda harus blog itu dan kembali ke sini untuk memposting tautan!

Ini adalah sesuatu yang dapat Anda gunakan tampilan atau kueri. Memiliki satu tabel dengan data mentah dan lainnya dengan rasio konversi yang perlu Anda terapkan - mungkin dengan tanggal atau informasi lain semacam itu jika rasio yang diterapkan adalah waktu atau situasi yang peka. Lalu buat kueri atau tampilan yang melakukan konversi yang Anda butuhkan dengan menggabungkan tabel bersama. Dengan cara ini Anda dapat mengubah nilai rasio konversi sesuai kebutuhan dan menghitung ulang.

Contoh sederhana (PostgreSQL) untuk skenario hipotetis, skenario Anda akan berbeda:

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