Представление единиц измерения стандартизированным способом

Question

Предположим, вы хотите записать в базу данных, что длина составляет 30 метров, или 50 футов, или температура была 50 Кельвинов, скорость составляла 50 километров в час. Как бы вы представили единицы?

Для уточнения, два пункта:

• любой вид единиц, а не предопределенное, четко определенное их подмножество.
• мой вопрос больше относится к существованию онтологии единиц. Я взял пример базы данных, потому что он был первым, что мне пришло в голову, но сценарии, такие как представление модуля в XML или JSON, одинаково вероятны.

Answer 1

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

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

Возможно, вы захотите взглянуть на ISO 2955 , «Обработка информации - представление СИ и других единиц в системах с ограниченными наборами символов. "

Также см. « Стиль программирования SQL Джо Селко », глава 4, Шкалы и измерения .

Answer 2

Согласно реляционной теории, каждый relvar («таблица») имеет связанный предикат, который определяет значение кортежей в нем. Этот предикат должен быть частью формальной документации базы данных, так что никто, кто на самом деле консультируется с документацией, не может иметь никаких оправданий для «неправильного понимания чего-либо» (если, конечно, документация не полная).

Включая определение единиц в этом предикате (например, «Длина человека ... есть ФУТЫ», «Измеренная температура была ... КЕЛЬВИН», ...) достигает этой полноты и избегает необходимости прибегать к эти довольно некрасивые имена атрибутов («столбцов»).

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

Если foobaricity существует как единица, и кто-то придумывает новое пушистое восприятие единицы, тогда этот кто-то сначала должен будет официально установить соответствие между количествами foobaricity и количествами пушистого восприятия, или ничего, что он утверждает, не будет / не может быть понято кем угодно.

EDIT

Я видел это добавлено: «Мне нужно сохранить информацию об оригинальном устройстве.»

Ничто не мешает вам сделать это. Два дополнительных столбца (оригинальное количество и оригинальное название единицы) наряду с «канонизированным» значением. Вы можете ограничить «оригинальное имя юнита» так сильно или слабо, как хотите.

Answer 3

Я бы включил единицы измерения в имя столбца (например, LengthInMeters, WeightInKilograms, AnnoyingnessInFishSlapsPerSecond и т. Д.), А затем просто сохранил числа в столбце.

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

Я сталкивался с решениями БД, которые включают единицы измерения во втором столбце, но поскольку не существует стандартизированного способа представления единиц измерения, в результате получается текстовое поле со значениями, такими как "ft.", "Fts", "Feet". "и т. д., или же FK для таблицы, в которой хранятся возможные единицы измерения (также текст). В любом случае выполнение запросов SUM или AVG (или любых вычислений) становится кошмаром, особенно если вы разрешаете хранить значения с разными единицами измерения в одном столбце.

Answer 4

Есть ли у вас особая причина хранить количества в различных типах единиц вместо преобразования в некоторые «канонические» единицы (например, метрическую систему)? Вставляя данные, вы конвертируете введенное количество в каноническую единицу. А при чтении данных вы конвертируете в любую нужную вам единицу вывода.

Этот подход во многих отношениях проще, чем хранение данных в разных единицах, но вы теряете информацию об исходной единице, в которой были указаны данные.