размерный и модульный анализ в базе данных SQL - PullRequest
3 голосов
/ 04 августа 2009

Проблема:

Реляционная база данных (Postgres), хранящая данные временных рядов различных значений измерений. Каждое значение измерения может иметь определенный «тип измерения» (например, температура, растворенный кислород и т. Д.) И может иметь конкретные «единицы измерения» (например, Фаренгейт / Цельсий / Кельвин, процент / миллиграммы на литр и т. Д.).

Вопрос:

Кто-нибудь создал подобную базу данных, чтобы сохранить целостность измерений? Есть предложения?

Я подумываю о создании таблицы Measure_type и Measurement_unit, оба из которых будут иметь текст, два столбца, идентификатор и текст. Затем я бы создал внешние ключи для этих таблиц в таблице measure_value. Текст меня несколько беспокоит, потому что есть возможность для неуникальных дубликатов (например, «мкг / л» против «мкг / л» для микрограмм на литр).

Цель этого заключается в том, чтобы я мог как конвертировать, так и проверять единицы по запросам или посредством внешнего программирования. В идеале у меня была бы возможность позже включить строгий размерный анализ (например, связать мкг / л со значением «M / V» (масса, деленная на объем)).

Есть ли более элегантный способ сделать это?

Ответы [ 3 ]

4 голосов
/ 04 августа 2009

Я создал подсистему базы данных для обработки единиц измерения давным-давно (хорошо, я немного преувеличиваю; хотя это было около 20 лет назад). К счастью, он имел дело только с простой массой, длиной, временными измерениями, а не с температурой, не с электрическим током, не со светимостью и т. Д. Игровой стороной игры было не так просто - было множество различных способов конвертации одной валюты. и другой в зависимости от даты, валюты и периода, в течение которого действовал обменный курс. Это было обработано отдельно от физических единиц.

По сути, я создал таблицу «показатели» со столбцом «id», именем единицы измерения, аббревиатурой и набором показателей степени - по одной для массы, длины и времени. Это заполняется такими именами, как «объем» (длина = 3, масса = 0, время = 0), «плотность» (длина = 3, масса = -1, время = 0) и т. П.

Была вторая таблица единиц, в которой указана мера, а затем фактические единицы измерения, использованные в конкретном измерении. Например, там были бочки и кубометры, и всякие другие релевантные единицы.

Была третья таблица, в которой определялись коэффициенты пересчета между конкретными единицами. Он состоял из двух единиц и коэффициента мультипликативного преобразования, который преобразовал единицу 1 в единицу 2. Самой большой проблемой здесь был динамический диапазон коэффициентов преобразования. Если преобразование из U1 в U2 равно 1.234E + 10, то обратное число является довольно небольшим числом (8.103727714749e-11).

Комментарий С. Лотта о температурах интересен - нам не приходилось с этим сталкиваться. Хранимая процедура могла бы решить эту проблему - хотя интеграция одной хранимой процедуры в систему могла бы быть сложной.

Схема, которую я описал, позволила описать большинство преобразований один раз (включая гипотетические единицы, такие как фарлонги за две недели или менее гипотетические, но одинаково неясные - за пределами США - как акр-футы), и преобразования можно было проверить (для Например, обе единицы в таблице коэффициентов пересчета должны иметь одинаковую меру). Он может быть расширен для обработки большинства других единиц, хотя безразмерные единицы, такие как углы (или телесные углы), представляют некоторые интересные проблемы. Был поддерживающий код, который обрабатывал бы произвольные преобразования - или генерировал ошибку, когда преобразование не могло быть поддержано. Одной из причин этой системы было то, что различные международные аффилированные компании сообщали свои данные в своих удобных для них единицах, но система HQ должна была принимать исходные данные и в то же время представлять итоговые агрегированные данные в единицах, подходящих для менеджеров, где каждый из менеджеров по отдельности У них была своя идея (исходя из их национальной принадлежности и стажа работы в штаб-квартире) о лучших единицах для их отчетов.

0 голосов
/ 20 сентября 2009

Замечание о преобразованиях: многие единицы линейно связаны и могут быть преобразованы с использованием формулы типа "y = A + Bx", где A и B - это константы, которые можно хранить в базе данных для каждой пары единицчто вам нужно конвертировать между.Например, от Цельсия до Фаренгейта константы A = 32, B = 1,8.

Однако, есть и редкие исключения.Преобразование между логарифмическими и нелогарифмическими единицами, например.Или преобразование между массой на объем и молярной массой на объем (в этом случае вам необходимо знать молярную массу измеряемого соединения).

Конечно, если вы уверены, что всепреобразования, требуемые системой, являются линейными, поэтому нет необходимости в чрезмерном проектировании, просто сохраните две константы.Затем вы можете извлечь стандартизированные результаты из базы данных, используя прямые SQL-соединения с вычисляемыми полями.

0 голосов
/ 04 августа 2009

«Текст меня несколько беспокоит, потому что есть возможность для неуникальных дубликатов»

Верно.Так что не используйте текст в качестве ключа.Используйте идентификатор в качестве ключа.

«Есть ли более элегантный способ сделать это?»

Не совсем.Это тяжело.Температура - это ее собственная проблема, потому что температура сама по себе является средней, а не суммируется, как расстояние;преобразование плюс F в C не является умножением (как при любом другом преобразовании единиц).

...