ubuntuusers.de

Bash Script mit MySQL und Berechnung

Status: Ungelöst | Ubuntu-Version: Ubuntu 12.04 (Precise Pangolin)
Antworten |

Lysander

Avatar von Lysander

Anmeldungsdatum:
30. Juli 2008

Beiträge: 2669

Wohnort: Hamburg

rklm schrieb:

Lysander schrieb:

Überzeuge Deine Entscheider eben davon, dass es nur so machbar ist.

Das ist manchmal schwerer als die Implementierung. ☺

Ja, aber notfalls bringt man das finale Argument: Es geht nur so! (Oder in Kanzlersprache: "Es ist alternativlos") 😎

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13215

Lysander schrieb:

Ja, aber notfalls bringt man das finale Argument: Es geht nur so! (Oder in Kanzlersprache: "Es ist alternativlos") 😎

Wenn der Chef auch nur etwas heller ist als wir Wähler, dann wird er darauf nicht hereinfallen. ☺

Lysander

Avatar von Lysander

Anmeldungsdatum:
30. Juli 2008

Beiträge: 2669

Wohnort: Hamburg

rklm schrieb:

Wenn der Chef auch nur etwas heller ist als wir Wähler, dann wird er darauf nicht hereinfallen. ☺

Naja, offenbar hat er ja bisher jemanden an die Sache gesetzt, der ziemlich unglücklich agiert hat. Und der Nachfolger scheint (bisher!) auch nicht bewandert in der Materie zu sein - nichts für Ungut, Cracymike ☺ Insofern hat der Chef entweder keine Ahnung, oder er will seinen Mitarbeiter testen oder aber die Priorität ist sehr gering...

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13215

Lysander schrieb:

Insofern hat der Chef entweder keine Ahnung, oder er will seinen Mitarbeiter testen oder aber die Priorität ist sehr gering...

Es gibt auch positivere Interpretationen, z.B. dass es eine Gelegenheit zum Lernen ist. Alles wilde Spekulation natürlich und hier völlig OT. 😬

Cracymike

(Themenstarter)

Anmeldungsdatum:
18. August 2014

Beiträge: 41

Danke für die Blumen:-) aber ihr habt ja recht.

Da sorgen wir doch mal dafür das der Nachfolger für die Zukunft etwas bewanderter wird. Dazu dann hier jetzt die Antworten auf die Fragen und ja ich nehme mir die Zeit.

schreib Dir mal auf, wie die Daten, die Du sammeln willst, vorliegen. Dann ist es auch nicht schwer, sie entsprechend aufzubereiten. (aber man braucht zuerst einen Überblick !)

Die Daten liegen an verschiedenen, Örtlich getrennten, Standorten. Diese Standorte werde ich nach und nach zuschalten, sie sind über eine Open VPN Verbindung erreichbar, die Daten für diese Verbindung sind in einer eigenen Datenbank gespeichert. Dort finden sich folgende Informationen zur Herstellung der Verbindung: Spalte

	 1	name	varchar(255)	latin1_swedish_ci	--> Enspricht dem Namen der Anlage und dem Standort	
	 2	remote	varchar(255)	latin1_swedish_ci	--> Ist der Domain Name für die Erreichbarkeit 
	 3	secret	varchar(255)	latin1_swedish_ci      --> Keine Ahnung ist leer
	 4	client	varchar(255)	latin1_swedish_ci	--> die IP des Rechners Hinter dem VPN-Server
	 5	share	varchar(255)	latin1_swedish_ci	--> Freigabepfad der Datenspeicherorte auf dem Client
	 6	user	varchar(255)	latin1_swedish_ci		--> User für zugriff auf die Freigabe
	 7	password	varchar(255)	latin1_swedish_ci	--> Paswort für den User

Auserdem gibt es eine Zweite Tabelle für jeden Standort in welcher die Datenpfad Unterordner gespeichert sind.

         1	id	 int(11)			                     --> EEnthält eine Nummer
	 2	path	 varchar(255)	latin1_swedish_ci  --> Enthält einen Ordnernamen als Unterordner des Freigabeordners

Die Anzahl der Unterordner ist nicht definiert kann also unterschiedlich sein.

Die eigentlichen Daten liegen in den Unterordner als .txt Dateien vor. Die einzelnen Dateien enthalten immer die Daten zu einem Sensor und einem Tag.

Der Dateiname sieht immer so aus "PositionDuese11 2012_11_02.txt" Teil 1 Name des Sensors(variabel) Teil 2 Datum der Inhalt stellt sich wie folgt dar:

02.11.2012 21:50:25	0,00000
02.11.2012 21:50:25	0,00000
02.11.2012 21:53:50	12,24500
02.11.2012 22:20:17	12,24500	Ende
02.11.2012 22:20:38	12,23167
02.11.2012 22:30:40	12,23167	Ende
02.11.2012 22:31:01	12,22833
02.11.2012 22:46:24	12,22833	Ende
02.11.2012 22:48:37	12,22667
02.11.2012 22:54:27	20,76667
02.11.2012 22:54:32	19,82833
02.11.2012 22:55:07	19,72167
02.11.2012 23:41:07	32,38500
02.11.2012 23:41:12	41,11666
02.11.2012 23:41:17	48,08000
02.11.2012 23:41:22	55,97000
02.11.2012 23:41:32	55,86000
02.11.2012 23:41:37	43,61666
02.11.2012 23:41:42	30,23833
02.11.2012 23:41:47	17,75000
02.11.2012 23:41:52	13,81500
02.11.2012 23:42:17	13,71333
02.11.2012 23:56:46	13,71333	Ende
02.11.2012 23:58:59	0,00000
02.11.2012 23:59:24	13,62667

Diese Dateien sind unterschiedlich lang je nachdem wie oft der entsprechende Sensor einen Wert liefert. Das geht von gar keinem bis hin zu einem 3 Sekunden Intervall. Die 4 mal "Ende in dieser Datei haben keine Relevanz und können ignoriert werden.

In den einzelnen Unterordnern finden sich immer Dateien für mehrere Sensoren welche das sind ist am Anfang und auch nicht welche Menge.

Überleg Dir, wie die Datenbank aussehen soll, richtig sauber, mit ihrer Struktur. (oder ist die vorgegeben, und Du musst sie nehmen wie sie ist ?)

Die Datenbank kann ja ausgehend von den Kommentaren in diesem Thema ja sehr einfach gehalten sein.

Zwei Tabellen eine für die Sensoren und Standorte als Zuordnung und einer SensorID Eine zweite für die eigentlichen Daten sollte also enthalten die SensorID , einen Timestamp ( am liebsten Unix) wenn wir schon bei null anfangen kann man doch auch das machen, und dem Value also Sensorwert.

Dann kannst Du den Weg von 1. nach 2. planen: welche DB- Befehle sind nötig, und wie muss ich ggf. die Daten vorher noch aufbereiten ? Wenn das alles in "Prosa" steht, dann kannst Du den Code schreiben. Dann ist das auch nicht mehr schwer, denn Du hast ja einen Überblick, was Du willst.

Dafür brauch ich dann wohl euch ich will ja etwas lernen....

Gruß Mike

snafu1

Avatar von snafu1

Anmeldungsdatum:
5. September 2007

Beiträge: 2133

Wohnort: Gelsenkirchen

Cracymike schrieb:

Dafür brauch ich dann wohl euch ich will ja etwas lernen....

Du lässt dir ein Schema vorkauen und lernst durch Copy&Paste, oder wie hast du dir das gedacht?

Lysander

Avatar von Lysander

Anmeldungsdatum:
30. Juli 2008

Beiträge: 2669

Wohnort: Hamburg

Und jetzt scheinen Sensoren ja doch eine Id zu haben oder zu bekommen? Was denn nun? Unlängst hieß es ja noch, dass die uninteressant seien...

Vermutlich bilden die Sensoren eine schwache Entität und müssen mit der Standort-Id verknüpft werden.

@Cracymike *Wie* die Daten zu Dir kommen scheint mir nicht so wichtig; iirc ist das doch schon lauffähig! Überlege Dir eher, *wie* die Textdaten aufgebaut sind, wie die DB-Struktur aussehen sollte und dann, wie man diese Rohdaten in das SQL-Schema hinein bekommt. Hatten wir alles schon angesprochen.

Bei der Struktur kannst Du ja mal ins "blaue" entwerfen und fügst dann manuell Testdaten ein und *testest* damit einmal, ob Du einfach alle Auswertungen über Queries abbilden kannst! Dabei berücksichtige doppelte "Sensoren" in irgend einer Form und uneindeutige Messdaten (also gleicher Sensorname, gleicher Wert, gleicher Timestamp). Wenn Du diese Daten *eindeutig* in Deiner Tabelle abbilden kannst, weißt Du quasi schon, dass das Schema etwas taugt.

Cracymike

(Themenstarter)

Anmeldungsdatum:
18. August 2014

Beiträge: 41

Hm das mit der Sensor id habe ich jetzt mit übernommen da Ihr ja der Meinung wart das es so der bessere weg ist, und wenn ich jetzt schon neu Baue dann natürlich der "bessere" Weg.

Das die Daten zu mir zu kommen ist ja in dem von mir geposteten Script enthalten, will ich das jetzt neu bauen muss ich das mit berücksichtigen da der gesamte Prozess ja als eine Einheit abläuft. Wie die Textdaten aussehen habe ich in meinem letzten Post bereits dargestellt hier geht es hautsächlich darum aus dem Datum und der Zeit den Timestamp zu berechnen. So das aus der einzelnen Textdatei eine neue .csv erzeugt wird welche sich dann in die DB importieren lässt. Dazu müssen die Daten modifiziert werden das heißt ich muss jeder Zeile noch den Standort und den Sensornamen anhängen. Alternativ wenn ich eine Zweite Tabelle verwende welche eine Id über die Beziehung Sensor zu Standort zur Verfügung stellt muss die Zeile um diese Id erweitert werden. Ich war bis dato der Meinung das es besser wäre einfach nur den Sensor und den Standort zu ergänzen da dann alle Daten in einer Tabelle enthalten sind, in den Abfragen werde ich nur Daten eines Standortes verwenden und an einem Standort kommt kein Sensor zweimal vor, dies würde nur Standortübergreifend passieren. Die von den Sensoren gelieferten Daten sollen nur innerhalb von Diagrammen angezeigt werden um einen Verlauf darstellen zu können. Am Ende heißt das du hast eine Excel Datei in der du den Standort und den Sensor/Sensoren auswählst und einen Zeitraum danach werden die Daten abgefragt und Graphisch dargestellt. Daher auch meine Ursprüngliche Idee Tabellen in verschiednen Agregationstufen zu erzeuge um in bestimmten Situationen die Anzahl der Datenpunkte zu minimieren, Verstanden habe ich an dieser Stelle das das nicht sinnvoll ist. Wobei mir mittlerweile auch bewusst ist das die Lösung mit einer eindeutigen Standort/Sensor ID wohl die bessere wenn auch in der Programmierung komplexere ist . Hier ist es nötig einfach immer zu schauen ob der Sensor mit dem Standort schon existiert, und wenn nicht in der ID Tabelle einen neuen Eintrag zu erzeugen.

Dem zu folge wäre die DB Struktur sehr einfach :

Tabelle 1 –> Name kommt noch

ID            --> Einmalige ID die Sowohl Standort als auch sensor Identifiziert. Was verwendet man hier am besten? eine fortlaufende Zahl wäre wahrscheinlich das einfachste aber im Bezug zur 2. Tabelle unpassend wie wäre z.B.  S1 S2 ...Sn 
Standort  --> Name des Standortes
Sensor     --> Name des Sensors

Tabelle 2

ID                --> Entspricht der ID aus Tabelle1 um die Zugehörigkeit der Daten festzulegen
Timestamp  --> Zeitpunkt der Datenerfassung
Value          --> der Messwert

Vermutlich benötige ich hier auch noch einen zusätlichen Schlüssel um die Datensätze "einmalig" zu gestalten da es ja zu Dopplung sowohl beim Timestamp als auch beim Value kommen kann?

Desweitern habe ich noch die Herausforderung das ganze mit einer gewissen Redundanz auszustatten. Da es auch zu Störungen im Abholen kommen kann muss das ganze so angelegt sein das Täglich mehrere Tage abgeholt werden z.B. 5 Tage. Dabei muss dann beachtet werden das identischen Einträge nicht gedoppelt werden.

Und wenn ich mir jetzt den Prozess ansehe dann wohl grob so.

Datei nehmen aus Dateinamen Sensor entnehmen.

Jetzt in Zusammenhang mit Standort in Tabelle 1 Prüfen ob schon Existiert 
--> wenn Ja ID übernehmen
--> wenn nein neuen Eintrag generieren ID übernehmen


Jetzt jede Zeile abarbeiten aus Datum und Zeit Timastamp berechne und eine Neue CSV erzeugen Inhalt    ID  Timestamp  Value.

Diese CSV in die Tabelle 2 Importieren dabei neue Schlüssel erstellen und beachten wenn Information schon vorhanden dann Ignorieren.

Danach CSV und TXT löschen und Prozess neu beginnen.

Eventuell könnte mann das ganze noch so machen das mann nicht jedes mal einen neue CSV erzeugt sonder nur eine für alle TXT um dann nicht mehrere Importe zu fahren sondern nur einen einzelnen. Bin mir nicht sicher denke aber das das die Performance beeinflusst.

Und das ganze logischer weise eingebettet in den Abholprozess der Daten auf diese weis ist dann immer auch bekannt sui welchem Standort die Aktuellen TXT Dateien gehören.

Gruß Mike

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13215

Nur punktuelle Antworten, weil mir die Zeit fehlt.

Cracymike schrieb:

Tabelle 1 –> Name kommt noch

Gewöhn Dir bitte an, einen sprechenden Namen für Deine Tabellen zu finden. Das macht es den Lesern leichter, aber hilft vor allem auch Dir selber zur Begriffs- und Konzeptklärung.

Tabelle 2

Vermutlich benötige ich hier auch noch einen zusätlichen Schlüssel um die Datensätze "einmalig" zu gestalten da es ja zu Dopplung sowohl beim Timestamp als auch beim Value kommen kann?

Wozu? Wenn der Timestamp genügend auflöst, kannst Du wohl kaum zwei Messwerte von einem Sensor zur selben Zeit haben. Und selbst wenn Du z.B. nur Sekundenauflösung und damit mehrfache Werte pro (ID, Timestamp) hast, ist das für die Datenbank kein Problem. Da hängt es nur von den gewünschten Auswertungen ab, ob die richtige Reihenfolge der, sagen wir mal: vier Messwerte in einer Sekunde wichtig ist oder nicht.

Desweitern habe ich noch die Herausforderung das ganze mit einer gewissen Redundanz auszustatten. Da es auch zu Störungen im Abholen kommen kann muss das ganze so angelegt sein das Täglich mehrere Tage abgeholt werden z.B. 5 Tage. Dabei muss dann beachtet werden das identischen Einträge nicht gedoppelt werden.

OK, das könnte in der Tat ein Grund für einen Primary Key auf der Datentabelle sein. Du könntest es aber auch über den Max-Timestamp pro ID regeln, wenn Du sicherstellst, dass die Dateien in chronologischer Reihenfolge importiert werden und Du beim ersten Fehler abbrichst.

Und wenn ich mir jetzt den Prozess ansehe dann wohl grob so. [...]

Sieht im Großen und Ganzen gut aus.

Diese CSV in die Tabelle 2 Importieren dabei neue Schlüssel erstellen und beachten wenn Information schon vorhanden dann Ignorieren.

Wie gesagt, Du brauchst vermutlich keine neuen Schlüssel.

Eventuell könnte mann das ganze noch so machen das mann nicht jedes mal einen neue CSV erzeugt sonder nur eine für alle TXT um dann nicht mehrere Importe zu fahren sondern nur einen einzelnen. Bin mir nicht sicher denke aber das das die Performance beeinflusst.

Je nach Größe der einzelnen Dateien. Wenn die sowieso schon hunderte oder tausende Messwerte beinhalten, lohnt es sich vermutlich nicht, die in eine Datei zusammen zu fassen. Zumal Du dann bei einem Fehler nicht weißt, wo es schief gegangen ist.

Ciao

robert

Cracymike

(Themenstarter)

Anmeldungsdatum:
18. August 2014

Beiträge: 41

So da bin ich wieder mit ein parr Fragen.

Die Datenbank wird "dwh_bga" heißen, die Tabelle 1 wird "Sensor_ID" heißen und Tabelle 2 "Messdaten_ALL"

Die Datenbank habe ich angelegt jetzt geht es an die Tabellen wie muss ich jetzt die einzelnen Spalten am besten definieren und warum genau so. Die folgenden Spalten sollen ja enthalten sein in Tabelle "Sensor_ID"

ID           -->   die ID soll so "S1 S2 .... Sn " aussehen.
Standort -->  enthält einen Ort z.B. Berlin  Hamburg
Sensor    -->  enthält den Sensor Namen  z.B. Druck_Pumpe_11_11  

Das selbe für die Tabelle "Messdaten_ALL"

ID             -->  denke ich genau wie oben
Timstamp --> kann ich den Standard wählen
Value       --> kann eine beliebige Zahl sein würde ich gern auf 5 Nachkommastellen begrenzen

Gruß Mike

Lysander

Avatar von Lysander

Anmeldungsdatum:
30. Juli 2008

Beiträge: 2669

Wohnort: Hamburg

Cracymike schrieb:

Die Datenbank wird "dwh_bga" heißen, die Tabelle 1 wird "Sensor_ID" heißen und Tabelle 2 "Messdaten_ALL"

Die Tabellennamen finde ich nicht gut! Lass die _-Teile weg 😉 Nenne Sie "Sensoren" und "Messdaten" - das reicht vollkommen aus! Entscheide Dich auch, ob Du Plural oder Singular verwenden willst; aktuell ist es gemischt, was sich imho schlecht liest.

Ich persönlich denke ja, dass die Idee Standort und Sensor als *eine* Einheit zu betrachten falsch ist! Imho ist der Standort prinzipiell unabhängig vom Sensor. Ersterer hat also auch noch einen sprechenden Namen. Ergo nenne die Tabelle "Standorte" mit einer ID als PK. Woher stammt denn die ID? Wenn das künstlich ist, nutze *numerische* Werte, also "1, 2, 3 , ..." anstelle einer Buchstaben-Zahlen-Kombi. Diese kann man oftmals einfacher automatisch erzeugen!

Wenn die Sensoren tatsächlich keine weiteren Metainformationen beinhalten, so nutze diese einfach nur als Schlüsselbestandteil in der Messdaten-Tabelle, denn eine Sensor-ID ist ja nur innerhalb eines Standortes eindeutig, wenn ich das richtig verstanden habe. Der PK in der Messdaten-Tabelle wäre also (Standort_ID, Sensor, Timestamp).

Imho ist das die wesentlich bessere Struktur!

Wie ich weiter oben schon schrieb: Lege Dir diese Struktur erst einmal an und fülle die in so weit mit Testdaten (ruhig manuell per Script!), dass Du die Auswertungen und Queries testen kannst. Zudem kannst Du dann das Hinzukommen von "neuen" Sensoren usw. testen.

Erst dann würde ich mich daran machen, das Parsen und Einfügen der Live-Daten anzugehen.

Cracymike

(Themenstarter)

Anmeldungsdatum:
18. August 2014

Beiträge: 41

Ok Danke für die Anmerkungen zu den Namen.

Trotzdem noch mal zurück zu den Sensoren und Standorten. Wenn ich dich jetzt richtig verstanden habe meinst du eine ID nur für den Standort zu erzeugen und den Sensor außen vor zulassen und den Sensor dann erst in der Messwerte Tabelle zu verwenden?

Bei der Verknüpfung von Standort mit Sensor denke ich die Abfragen sind einfach zu generieren.

Bsp. Wenn ich die Standort Tabelle nach Standort abfrage den Anwender dann die zugehörigen Sensoren Anzeige und auswählen lasse kann ich danach in der Messwerte Tabelle direkt über die ID´s und den Timestamp abfragen. Mit deiner Methode hab ich ja nur eine ID für den Standort und kann dann in der Messwerte Tabelle zwar den Standort ansprechen hab aber keine Zuordnung zum Sensor.

Oder ich hab deinen Vorschlag falsch verstanden.

Gruß Mike

Lysander

Avatar von Lysander

Anmeldungsdatum:
30. Juli 2008

Beiträge: 2669

Wohnort: Hamburg

Cracymike schrieb:

Trotzdem noch mal zurück zu den Sensoren und Standorten. Wenn ich dich jetzt richtig verstanden habe meinst du eine ID nur für den Standort zu erzeugen und den Sensor außen vor zulassen und den Sensor dann erst in der Messwerte Tabelle zu verwenden?

Japp.

Bei der Verknüpfung von Standort mit Sensor denke ich die Abfragen sind einfach zu generieren.

Glaube ich - mit dem bisherigen Wissen ❗ - nicht! Denn Du brauchst in jedem Falle die Info des Standortes und des Sensors, wenn Du auf diese speziellen Daten zugreifen willst. Bei meinem Vorschlag relativ explizit, bei Deinem über den Umweg, die zugehörige Id heraus zu bekommen. Das nimmt sich ergo nichts!

Aber... nun kommt ja das, was ich schon vor zig Postings vermutet hatte:

Bsp. Wenn ich die Standort Tabelle nach Standort abfrage den Anwender dann die zugehörigen Sensoren Anzeige und auswählen lasse kann ich danach in der Messwerte Tabelle direkt über die ID´s und den Timestamp abfragen. Mit deiner Methode hab ich ja nur eine ID für den Standort und kann dann in der Messwerte Tabelle zwar den Standort ansprechen hab aber keine Zuordnung zum Sensor.

Die Sensoren sind also doch derartig vom Standort abhängig, dass es sich lohnt, diese *separat* zu verwalten. Iirc hieß es mal, dass solche Queries nicht vorkommen. Nun, sei es wie es will, mit diesen Aussagen ist doch klar, dass Du eine weitere Tabelle benötigst, in der Du die Relation zwischen Standort und Sensor abbildest. Diese würde ich dann Sensoren nennen. In dieser Tabelle steht nix weiter, als die Id des Standorts und die Id des Sensors. Der PK besteht aus *beiden* Spalten, denn eine Sensor-Id bildet eine *schwache* Entität, d.h. sie ist nur *innerhalb* eines Standortes eindeutig.

Am PK in der Messdatentabelle ändert sich dabei nichts, denn offenbar hängen die Messwerte von Standort *und* Sensor *und* Timestamp ab.

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13215

Lysander schrieb:

Cracymike schrieb:

Trotzdem noch mal zurück zu den Sensoren und Standorten. Wenn ich dich jetzt richtig verstanden habe meinst du eine ID nur für den Standort zu erzeugen und den Sensor außen vor zulassen und den Sensor dann erst in der Messwerte Tabelle zu verwenden?

Japp.

Ich verliere langsam die Übersicht. M.E. gibt es folgende Optionen, die sich anbieten (es gibt natürlich noch beliebig viel mehr):

  1. Komplett normalisiert mit

    • Tabelle für Standort mit PK

    • Tabelle für Sensor mit PK und FK auf den Standort-PK

    • Tabelle für Messwerte mit FK auf den Sensor-PK und Zeitstempel

  2. Manuell vergebene Sensor-IDs (bzw. Sensor-IDs gescoped auf Standort)

    • Tabelle für Standort mit PK

    • Tabelle für Messwerte mit FK auf den Standort-PK, manuelle ID des Sensors und Zeitstempel

  3. Manuell vergebene Sensor-IDs (bzw. Sensor-IDs gescoped auf Standort) und Sensor-Metadaten

    • Tabelle für Standort mit PK

    • Tabelle für Sensor mit FK auf den Standort-PK, manueller ID des Sensors und weiteren Daten (Hersteller des Sensors oder so etwas); PK aus (Standort PK, Sensor ID)

    • Tabelle für Messwerte mit FK auf den Standort-PK, manuelle ID des Sensors und Zeitstempel

Was man dann jeweils für die Standort-PK und anderen PK verwendet, muss man halt sehen. Wenn die Standorte in der Firma sowieso schon eindeutige Kennungen haben, dann kann man das verwenden, sonst kann man auch einen Surrogate-Key nehmen. Wichtig ist, dass die FKs in der Messwerte-Tabelle nicht zu groß werden, weil hier die meisten Daten anfallen.

Alle Varianten oben erlauben eine eindeutige Zuordnung von Messwerten zu einem speziellen Sensor und Zuordnung von Sensor zu Standort (und damit auch von Messwert zu Standort). Alle Varianten erlauben auch Messdaten eines speziellen Sensors oder eines Standorts abzufragen. Nur Option 1 kommt allerdings mit weniger Daten in der Messwerttabelle aus, weil die anderen beiden den Standort erfordern.

Bsp. Wenn ich die Standort Tabelle nach Standort abfrage den Anwender dann die zugehörigen Sensoren Anzeige und auswählen lasse kann ich danach in der Messwerte Tabelle direkt über die ID´s und den Timestamp abfragen. Mit deiner Methode hab ich ja nur eine ID für den Standort und kann dann in der Messwerte Tabelle zwar den Standort ansprechen hab aber keine Zuordnung zum Sensor.

Das stimmt nicht, denn Lysander schrieb:

Der PK in der Messdaten-Tabelle wäre also (Standort_ID, Sensor, Timestamp).

Alle relevanten IDs sind also in der Tabelle vorhanden und damit können Messwerte eindeutig zugeordnet werden.

Die Sensoren sind also doch derartig vom Standort abhängig, dass es sich lohnt, diese *separat* zu verwalten. Iirc hieß es mal, dass solche Queries nicht vorkommen. Nun, sei es wie es will, mit diesen Aussagen ist doch klar, dass Du eine weitere Tabelle benötigst, in der Du die Relation zwischen Standort und Sensor abbildest.

Wie oben gezeigt ist dafür nicht unbedingt eine separate Tabelle nötig. Wenn die Sensor-ID pro Standort gescoped ist, dann kann man auch einfach immer die Standort-ID mit in die Messtabelle packen und hat damit die Zuordnung. Ich persönlich finde aber die normalisierte Variante besser, weil sie

  • mit weniger Daten in der Messtabelle auskommt,

  • ohne Redundanzen auskommt,

  • es einfach erlaubt, die Standort- und Sensor-Tabelle später mit zusätzlichen Spalten für Meta-Daten zu ergänzen, ohne zusätzliche Tabellen anlegen oder Daten durch die Gegend schaufeln zu müssen.

Diese würde ich dann Sensoren nennen. In dieser Tabelle steht nix weiter, als die Id des Standorts und die Id des Sensors.

Dort könnten auch noch weitere Eigenschaften eines Sensors gespeichert sein.

Der PK besteht aus *beiden* Spalten, denn eine Sensor-Id bildet eine *schwache* Entität, d.h. sie ist nur *innerhalb* eines Standortes eindeutig.

Meine Option 3 wäre das. Um nur die Zuordnung zu Standorten zu verwalten braucht man diese Tabelle aber nicht (siehe Option 2) denn der Standort-PK muss sowieso in die Messwerte-Tabelle, weil sich die Messwerte sonst nicht eindeutig zuordnen lassen.

Am PK in der Messdatentabelle ändert sich dabei nichts, denn offenbar hängen die Messwerte von Standort *und* Sensor *und* Timestamp ab.

Es ist nicht mal klar, dass die Messdatentabelle überhaupt einen PK braucht. Sicherlich braucht man einen Index, aber ob es ein PK oder auch nur ein eindeutiger Index sein muss, ist noch offen. Ich tendiere eher gegen einen PK, es sei denn der Zeitstempel löst genau genug auf, dass man alle unterschiedlichen Messwerte unterbringen kann UND man will den PK nutzen um doppelte Einfügungen zu vermeiden. Wenn eins von beiden nicht gegeben ist, lieber auf den PK verzichten.

Generell wird man auf der Messwertetabelle je nach Variante einen Index auf (Sensor ID, Timestamp) oder (Standort ID, Sensor ID, Timestamp) brauchen um Abfragen effizient machen zu können. Falls man auch alle Werte zu einem Zeitpunkt oder -intervall braucht, kann man auch noch einen zusätzlichen Index auf (Timestamp) anlegen.

Ciao

robert

Cracymike

(Themenstarter)

Anmeldungsdatum:
18. August 2014

Beiträge: 41

Input Input Input mein Kopf Raucht aber das ist auch gut so.

Eventuell noch mal als Info ich habe an jedem Standort gleiche Sensoren also eventuell selbe Bezeichnung. Soll heißen die Anlagen an den Standorten dienen alle dem selben Zweck sind aber unterschiedlich groß. Eine Metainformation zum Sensor ist eigentlich nicht nötig, Zentrale Information ist tatsächlich der Sensorname, wenn ich also am Behälter 1 am Standort 1 einen Druck Messe dann ist zwar klar das ich auch am Behälter1 Standort 2 einen Druck Messe das muss aber nicht zwangsläufig mit einem Sensor des selben Typs stattfinden.

Mein zweites Problem ist einen fehlende konsistent, bei diesen Bezeichnungen sie Unterscheide sich von Standort zu Standort an diese Stelle hat noch keine Normalisierung stattgefunden. Dadurch ist es nicht ohne weiteres Möglich zum Beispiel eine Tabelle zu erzeugen mit nur Sensornamen und einer ID und einer zweiten Tabelle mit den Standorten. Ich kann also nicht von einer "begrenzten" Anzahl Sensoren ausgehen sondern praktisch von einer unendlichen Anzahl Sensoren. Was der Grund dafür ist das ich die Sensortabelle variabel befüllen wollte.

Im Gegensatz dazu ist zum Glück die Anzahl der Standorte endlich.

Gruß Mike