dimensional und Einheit Analyse in SQL-Datenbank

Question

Problem:

Eine relationale Datenbank (Postgres) Zeitreihen-Daten von verschiedenen Messwerte speichert. Jeder Messwert kann einen spezifischen "Messart" (beispielsweise Temperatur, gelöster Sauerstoff, usw.) und kann spezifischen "measurement units" (z.B. Fahrenheit / Celsius / Kelvin, Prozent / Milligramm pro Liter, etc).

Frage:

Hat jemand gebaut ist eine ähnliche Datenbank, so dass dimensionale Integrität bewahrt? Haben Sie irgendwelche Vorschläge?

Ich betrachte eine measurement_type Aufbau und eine measurement_unit Tabelle, die beide diese würden Text zwei Spalten, ID und Text haben. Dann würde ich Fremdschlüssel auf diese Tabellen in der Gemessener_Wert Tabelle erstellen. Text beunruhigt mich etwas, weil es die Möglichkeit für nicht eindeutige Duplikate (z ‚ug / l‘ vs ‚ug / l‘ für Mikrogramm pro Liter).

Der Zweck wäre dies so sein, dass ich beide umwandeln und überprüfen Einheiten auf Abfragen oder extern über Programmierung. Im Idealfall würde ich später die Fähigkeit hat, strenge Dimensionsanalyse (z.B. & mgr; g / l auf den Wert ‚M / V‘ Verknüpfung (Volumenmasse geteilt)).

Gibt es eine elegantere Möglichkeit, dies zu erreichen?

Answer 1

produzierte ich eine Datenbank Teilschema für vor Einheiten ein Äon Handling (okay, ich übertreibe ein wenig, es ist etwa 20 Jahre her, obwohl). Glücklicherweise hatte es nur mit einfacher Masse, Länge, Zeitdimensionen zu bewältigen - nicht Temperatur oder elektrischem Strom oder Helligkeit usw. Eher weniger einfach die Währung Seite des Spiels war - es gab unzählige verschiedene Möglichkeiten, zwischen einer Währung Umwandlung und eine andere, je nach Datum, Währung und Zeitraum, über den Umrechnungskurs gültig war. Das wurde getrennt von den physikalischen Einheiten behandelt.

Im Grunde habe ich eine Tabelle ‚Maßnahmen‘ mit einer ‚id‘ Spalte, einen Namen für das Gerät, eine Abkürzung, und eine Reihe von Dimension Exponenten - je eine für Masse, Länge, Zeit. Dies wird mit Namen bevölkert wie 'Volumen' (Länge = 3, Masse = 0, Zeit = 0), 'Dichte' (Länge = 3, Masse = -1, Zeit = 0) - und dgl.

Es gab eine zweite Tabelle von Einheiten, die ein Maß identifiziert und dann den tatsächlichen Einheiten, die durch eine bestimmte Messung verwendet. Zum Beispiel gab es Fässer und Kubikmeter, und alle möglichen anderen Einheiten von Bedeutung.

Es gab eine dritte Tabelle, die Umrechnungsfaktoren zwischen bestimmten Einheiten definiert. Diese bestand aus zwei Einheiten und die multiplikative Umrechnungsfaktor, der 2. Das größte Problem Einheit 1 Einheit umgerechnet hier war der dynamische Bereich der Umrechnungsfaktoren. Wenn die Umwandlung von U1 bis U2 ist 1.234E + 10, dann die Umkehrung ist eine eher kleine Zahl (8.103727714749e-11).

Der Kommentar von S. Lott über Temperaturen ist interessant - wir mussten nicht mit denen beschäftigen. Eine gespeicherte Prozedur hätte angegangen, dass -. Obwohl eine gespeicherte Prozedur in das System zu integrieren könnte heikel gewesen sein

Das Schema I beschrieben, erlaubt die meisten Conversions einmal beschrieben werden (einschließlich der hypothetischen Einheiten wie furlongs pro vierzehn Tage oder weniger hypothetisch, aber ebenso obskuren - außerhalb der USA - wie acre-feet) und die Umsätze validiert werden konnten (für Beispiel beide Einheiten in der Umwandlungsfaktortabelle hatten das gleiche Maß haben). Es könnte erweitert werden, die meisten anderen Einheiten zu handhaben - auch wenn die dimensionslosen Einheiten wie Winkel (oder Raumwinkel) einige interessante Probleme. Es gab Unterstützung Code, der beliebige Konvertierungen umgehen würde - oder einen Fehler erzeugen, wenn die Konvertierung nicht unterstützt werden könnten. Ein Grund für dieses System war, dass die verschiedenen internationalen Affiliate-Unternehmen, die ihre Daten in ihren lokal geeigneten Einheiten berichten würden, aber das HQ-System hatte die ursprünglichen Daten zu akzeptieren und dennoch stellt die resultierenden aggregierten Daten in Einheiten, die die Manager geeignet - wo verschiedene Manager je ihre eigene Idee hatte (auf der Grundlage ihrer nationalen Herkunft und der Länge der Pflicht im HQ) über die besten Einheiten für ihre Berichte.

Answer 2

„Text beunruhigt mich etwas, weil es die Möglichkeit ist für nicht eindeutige Duplikate“

Richtig. Also nicht Text als Schlüssel verwenden. Verwenden Sie die ID als Schlüssel.

„Gibt es eine elegantere Möglichkeit, dies zu erreichen?“

Nicht wirklich. Es ist schwer. Die Temperatur ist es eigenes Problem, da Temperatur ist selbst ein Durchschnitt und nicht summiert nicht wie Abstand tut; und F bis C Umwandlung ist kein mehrfach (wie bei jeder anderen Einheit Umwandlung ist.)

Answer 3

Ein Hinweis zu Conversions: viele Einheiten linear aufeinander bezogen sind, und können umgesetzt werden unter Verwendung einer Formel wie „y = A + Bx“, wobei A und B Konstanten sind, die in der Datenbank für jedes Paar von Einheiten gespeichert werden könnten dass Sie brauchen, um zu konvertieren zwischen. Zum Beispiel für Celsius der Konstanten A = 32, B = 1,8 bis Farenheit.

Allerdings gibt es auch seltene Ausnahmen. Konvertieren zwischen logarithmisch und nicht-logarithmischen Einheiten, zum Beispiel. Oder Umwandlung von Masse-pro-Volumen und Molmasse-pro-Volumen (in diesem Fall müßten Sie die Molmasse der Verbindung zu wissen, die gemessen wird).

Natürlich, wenn Sie sicher sind, dass alle Umwandlungen durch das System erforderlich linear sind, dann gibt es keine Notwendigkeit für Over-Engineering, nur speichern die beiden Konstanten. Anschließend können Sie standardisierte Ergebnisse aus der Datenbank unter Verwendung von SQL gerade mit berechneten Feldern verbindet extrahieren.