Какова хорошая реляционная структура для единиц и сложных преобразований единиц?

Моя компания работает в энергетической отрасли, и мне нужно найти хороший способ представить преобразование единиц измерения. Я провел некоторые поиски и до сих пор не нашел хорошую статью, освещающую эту тему, в которой я нуждаюсь. Большинство опубликованной информации о преобразованиях единиц предполагает, что для данного модуля 1 существует известный (жестко запрограммированный) коэффициент конверсии, чтобы добраться до модуля 2, и это простая математика ( это самый сложный пример, который я нашел, но он до сих пор не помогает). Тем не менее, это не всегда верно в реальном мире и, конечно, не соответствует тому, с чем мы должны справиться. (Извините за длинную запись - я стараюсь предоставить как можно больше информации!)

Сложный пример 1. Некоторые конверсии меняются со временем, например, конвертация 5 долларов в евро или наоборот. Похоже, это не имеет ничего общего с энергией, но на самом деле это имеет место на рынке энергоносителей (подумайте на фондовом рынке).

Сложный пример 2: (слишком упрощенно). Некоторые природные газы горят горячее, чем другие . Кроме того, природный газ может быть измерен / сохранен либо на основе энергии в газе (например, термины ), либо на основе объема указанного газа (например, MCF, который составляет 1000 кубических футов), и также существуют другие возможности (такие как как тонна для мессы ). Аналогия бензина заключается в том, что 1 галлон неэтилированного 87-октана обеспечивает меньше энергии, чем 1 галлон неэтилированного 93-октана.

Сложный пример 3: Помимо наличия этих единиц измерения, нам также часто приходится иметь дело со ставками, такими как $ за Терм или € за MCF . Таким образом, нам нужен какой-то способ работы с этими ставками и как они соотносятся с базовыми единицами, поэтому, если нам нужно пересчитать из $ за Терм в € за MCF , мы можем использовать те же опубликованные курсы, что и при конвертации из Therm в MCF .

Сложный пример 4: Ранее я использовал термин « Энергия» очень свободно и, возможно, иногда неправильно. На данный момент и с этого момента, это меняется. Таким образом, последний кривая состоит в том, что мы имеем дело как с энергией, так и с силой . С электричеством это означает кВтч против кВт ( довольно хорошее объяснение, несмотря на то, что это Yahoo Ответы ). Аналогия данных: это было бы похоже на сравнение общего МБ данных , загруженной в сравнении с вашими Mbpsпропускная способность, которую предоставляет вам ваш провайдер. Как и данные, энергия требует времени для доставки. Продолжая аналогию с данными, нам, возможно, придется рассчитать среднюю эффективную пропускную способность, использованную за определенный период времени, поэтому, учитывая, что 60 МБ было загружено в течение 1 минуты, «эффективная» скорость будет равна 60 * 8/60 = 8 Мбит / с. «Хитрость» заключается в том, что если мы храним Мбит / с как единое целое, нам нужен какой-то способ связать его напрямую с МБ, даже если он также включает компонент времени. К счастью, преобразование энергии в энергию (или наоборот) является для нас довольно редкой вещью, поэтому наше решение должно быть оптимизировано для всех других хитрых примеров и, надо надеяться, учитывать и этот, но не обрабатывать энергиик власти это вариант.

Сложный пример 5: по сути, это 3 + 4. У нас может быть как $ за киловатт, так и $ за киловатт-час , поэтому тарифы касаются как мощности, так и энергии .

Простой пример: некоторые преобразования очень просты, и с ними справляется большинство информации в Интернете. 1000 Втч = 1 кВтч и тому подобное. То же самое с Therms и Decatherms или кВт в МВт и т. Д. Мне здесь не нужна помощь, но имейте в виду, что ~ 70% наших преобразований будут такого типа.

Мои мысли о том, как начать, но не уверены, как закончить:

1. Это явно ОЧЕНЬ грязно, поэтому я предлагаю выбрать стандартную единицу измерения для хранения всех данных по каждому товару и «типу использования». Таким образом, для электроэнергии наша стандартная единица энергии будет кВтч, а наша стандартная единица мощности будет кВт. Таким образом, для преобразования в любые другие единицы энергии / мощности нам потребуется только коэффициент преобразования в / из нашего стандарта, а не каждая возможная комбинация. Если нам когда-либо понадобится перевести из МВт в Вт, мы всегда можем сделать это путем преобразования в / из кВт.
2. Поскольку показатели конверсии могут зависеть от определенного времени, мы должны разрешить сохранение этого времени по отношению к измерению. Я подозреваю, что нам не нужно беспокоиться об изменении этих коэффициентов конвертации быстрее, чем раз в час, и мы можем даже рассчитывать один раз в день.
3. Поскольку показатели конверсии могут зависеть от опубликованных значений, мы должны разрешить возможность сохранения этого значения по отношению к измерению. Я подозреваю, что нам не нужно беспокоиться об изменении этих коэффициентов конвертации быстрее, чем раз в час, и мы можем даже рассчитывать один раз в день.
4. После того, как все это выяснится, я ожидаю создания веб-службы, которая не делает ничего, кроме обработки всех преобразований единиц измерения. Я НЕ ищу SQL для выполнения этих преобразований, и я могу сделать некоторое творческое кеширование, чтобы сделать это таким образом, что я не совсем разбираюсь в этих таблицах, но иногда потребуется обрабатывать преобразование ~ 400 значений на загрузку страницы на веб-сайте, доступном пользователю. , Я не уверен, если / как это имеет значение.

Я не знаю, на каком уровне мне следует хранить коэффициенты конверсии, которые никогда не меняются, по сравнению с коэффициентами конверсии, которые меняются, и как именно их отключить таким образом, чтобы я мог быстро получить к ним доступ таким образом, чтобы это было легко работать с.

Любые мысли о том, как справиться с этим или даже некоторые опубликованные материалы для чтения, которые могут помочь? Я использую SQL Server (скоро будет SQL Azure), но это не должно иметь большого значения. Схема для правильного представления - вот с чем у меня здесь проблемы. Если бы это было так просто, как дюймы против сантиметров, это легко. Но проблема заключается в разных коэффициентах конверсии.

Есть несколько вещей, которые вы хотите включить в свой дизайн:

1. Измерения нуждаются в метке времени

Убедитесь, что все ваши измерения имеют указание на:

• Скалярное значение
• Единица измерения
• Дата и время измерения

Это позволит вам работать с измерениями, которые требуют расчета преобразования, зависящего от времени.

2. Единицы измерения имеют атрибуты

Каждая единица измерения имеет несколько разных атрибутов. Очевидные из них являются ориентировочными, например, код и, возможно, описательное имя. Есть также несколько важных других атрибутов, которые нужно сохранить для каждой единицы измерения. (i) Тип единицы и (ii) Коэффициент преобразования в Базовую единицу .

Первый говорит вам, является ли ваша единица измерения длиной, весом, энергией, силой, валютой и т. Д. И т. Д. Он также должен указывать, что является базовой единицей измерения. Вы должны выбрать точно один для каждого типа юнита. Вы можете использовать такие вещи, как кВт-ч, если хотите, но я бы придерживался базовых единиц СИ (если применимо) на вашем месте.

Вторая говорит вам, на что нужно умножить вашу единицу измерения, чтобы добраться до базы. Я упоминал, что это атрибут вашей UOM, но на самом деле он должен быть в дочерней таблице. Бизнес-ключ дочерней таблицы, который содержит этот базовый коэффициент преобразования, представляет собой комбинацию UOM, ее типа базовой единицы и даты / времени. Я бы сохранил как дату, так и дату окончания срока действия в таблице базовых коэффициентов пересчета. Это позволяет быстро найти правильный тариф, который применяется в любой конкретный момент времени. Если это будет ставка, которая не меняется, это нормально. Просто используйте минимальную дату вступления в силу и максимальную дату истечения срока действия для одной записи.

3. Попытка прижать к столу все сделает вас чокнутым Последний кусок головоломки - это определение расчета перехода от одного вида юнита к другому. Вы можете попытаться провести такой расчет на основе таблиц, но в конце концов, сложные хитрости сделают дизайн настолько общим (читай сложным и медленным), что он будет непрактичным. Вместо этого создайте кодовую таблицу расчетов преобразования и используйте ее, чтобы связать один тип Типа с другим типом Типа. Выполните фактические вычисления в некотором коде где-нибудь. Какой фрагмент кода вы используете для любого конкретного преобразования, это то, что говорит вам таблица кодов. Как выполняется расчетпросто в коде. Вы можете иметь один расчет для разных простых вещей, например, области требуется две длины, а объему - три длины, а более сложным, например, работа требует энергии и времени.

Когда вы узнаете детали вашего дизайна, вы должны написать в блоге и вернуться сюда, чтобы опубликовать ссылку!

Это то, что вы можете использовать представления или запросы. Имейте одну таблицу с необработанными данными, а другую - с коэффициентом конверсии, который вам нужно применить - возможно, с датой или какой-либо другой такой информацией, если применяемый коэффициент зависит от времени или ситуации. Затем создайте запрос или представление, которое выполняет необходимое преобразование, объединяя таблицы. Таким образом, вы можете изменить значение коэффициента пересчета по мере необходимости и пересчитать.

Простой пример (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'   ;