Datenbank Layout/ERM

[psiyou]

Hallo,

bin neu hier und habe bis jetzt nicht wirklich Erfahrung mit Datenbanken, habe aber mal in ein Script durchgearbeitet und ein paar Übungen gemacht.

Nun habe ich gerade den ersten Entwurf für eine Datenbank fertig.

Ich möchte eine Datenbank aufsetzen in der die Messwerte mehrerer Stationen aufgenommen werden. Dabei soll es auch mobile Stationen geben.

Gespeichert werden soll also neben den Messwerten/Datum/Uhrzeit auch auch die Position der Messstation. Meine Frage ist jetzt mach das ganze ERM was ich aufgestellt habe erst mal überhaupt Sinn?

Und dann habe ich noch ein Problem bei der Messwert entity. Der Messwert und dessen Einheit hängen ja vom Sensor ab, soweit kein Problem. Jetzt habe ich aber auch Sensoren die zwei (bzw mehrere Messwerte, damit es allgemeiner ausgelegt ist) mit unterschiedlichen Einheiten ausgeben.

Wie kann ich das da unterbringen?

Hatte jetzt daran gedacht für diesen in hardware einen Sensor in der DB zwei Sensoren einzubinden. Die müssten dann aber noch irgendwie miteinander verbunden werden und daran hänge ich gerade.

Oder würde es mehr Sinn machen für jeden Sensor eine eigene Tabelle mit den Messwerten zu erzeugen?

Dann ist mir noch aufgefallen das ich ein austauschen des Sensors (zB wegen eines Defekts) nicht in die DB einbinden (und nachvollziehen kann). Würde es da Sinn machen ein "aktiv Flag" beim Sensor mit einzubauen bzw gibt es so etwas überhaupt?

Gruß

[dr.dimitri]

Hi,

die Zeit/datum/Zeitzone ist eindeutig ein Attribut von Messwert und keine eigene identität. Es wäre auch zu überlegen ob die Position der Einfachheit halber zu Messwert hinzugenommen wird (man nennt das Denormalisieren). Muss man aber nicht, man macht das hauptsächlich um mehr Performance zu bekommen.

Dann stört der Plural bei Messert(e). Pro Messwert gibt es einen Eintrag. Mach nicht den Fehler etwas in der Art Messwert1, Messwert2 etc zu machen wenn es sich in Wirklichkeit um voneinander unabhängige Messungen handelt.

Den Status Defekt würde ich als Attribut von Sensor sehen.

Ansonsten sieht das recht vernünftig aus.

Dim

[psiyou]

Hi Dim,

Danke für das Feedback.

Allerdings ist mir das mit Zeit/Datum/Zeitzone als Attribut nicht klar. Die Messstation hat ja mehrere Sensoren deren Werte regelmäßig aufgenommen werden. Dabei soll keine zeitliche Unterscheidung beim Abfragen der einzelnen Sensoren getroffen werden (Zeitauflösung >= 1min). Ich habe also für alle Sensoren einer Messstation für ein Messintervall die gleiche Zeit. Aus diesem Grund habe ich das als extra Identität aufgeführt.

Würdest Du die Zeit auch aus diesem Blickwinkel mit zu den Messwert zählen?

Die Position würde ich jetzt so lassen. Gefällt mir besser und ist evt für Erweiterungen flexibler. Auf Geschwindigkeit kommt es nicht so an. Die Daten werden in den Messstationen zwischen gespeichert und nur > Täglich übertragen. Wenn es also mal zu Engpässen kommen sollte kann man das noch entsprechend verteilen.

Ansonsten habe ich das mit dem Aktiv Flag plus Einsatzdauer des Sensors mal mit eingebaut. Soweit ich das überblicken kann sollte das auch mit dem einbeziehen von nicht mehr aktiven Sensoren bei der Datenabfrage klappen

psiyou

[dr.dimitri]

Hi,

die Zeit als eigene Entität würde nur dann Sinn machen, wenn Du einen begrenzte Anzahl von Zeiten hättest. Da die Anzahl der Messergebnisse aber praktisch unbegrenzt sind solange Deine Anwendung läuft, ist es viel Sinnvoller und gleichzeitig einfacher zu Implementieren wenn die zeit als Attribut einer Messung gesehen wird. Mag sein, dass dann doppelte Werte in den eigenen zeilen stehen, aber es würde auch niemand auf die Idee kommen z.B. in einer Adressverwaltung eine eigene Tabelle mit allen Datümern eines Jahres einzuführen nur damit ein Geburtsdatum nicht redundant abgelegt wird.

Des weiteren geh ich davon aus, dass Du auch noch nie eine Anwendung geschrieben hast die auf ein solches ERM zugreift. Du wirst dann sehr schnell sehen, dass jede Entität die man hinzufügt die ganze Zugriffsschicht komplexer macht. Daher sollte man auf just for fun Tabellen verzichten.

Auf Geschwindigkeit kommt es nicht so an.

Ja auch das ist ein häufiger Fehler. Designe deine Application und die DB immer so, dass sie von Anfang an so performant wie möglich ist. Steht die Anwendung und die DB, dann ist nachträgliches Tuning immer sehr viel schwieriger. Im übrigen hängst Du ja auch keinen Anker an dein Auto nur weil Du vielleicht momentan nicht schneller als 100 fahren möchtest.

Dim

[psiyou]

Hallo,

danke für die Erklärung!

Gebe Dir da recht, macht so betrachtet deutlich mehr sinn.

(Und nein, Anwendungen für DB hab ich noch nie geschrieben, immer nur den Query Browser beim lernen verwendet).

Werde das jetzt entsprechend umsetzen

Danke noch mal für Deine Hilfe,

Psiyou