Ü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") 😎
Anmeldungsdatum: Beiträge: 2669 Wohnort: Hamburg |
|
Projektleitung
Anmeldungsdatum: Beiträge: 12829 |
|
Anmeldungsdatum: Beiträge: 2669 Wohnort: Hamburg |
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... |
Projektleitung
Anmeldungsdatum: Beiträge: 12829 |
|
(Themenstarter)
Anmeldungsdatum: 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.
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.
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.
Dafür brauch ich dann wohl euch ich will ja etwas lernen.... Gruß Mike |
Anmeldungsdatum: Beiträge: 2123 Wohnort: Gelsenkirchen |
|
Anmeldungsdatum: 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. |
(Themenstarter)
Anmeldungsdatum: 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 |
Projektleitung
Anmeldungsdatum: Beiträge: 12829 |
Nur punktuelle Antworten, weil mir die Zeit fehlt.
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.
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.
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.
Sieht im Großen und Ganzen gut aus.
Wie gesagt, Du brauchst vermutlich keine neuen Schlüssel.
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 |
(Themenstarter)
Anmeldungsdatum: 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 |
Anmeldungsdatum: Beiträge: 2669 Wohnort: Hamburg |
Die Tabellennamen finde ich nicht gut! Lass die 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 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. |
(Themenstarter)
Anmeldungsdatum: 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 |
Anmeldungsdatum: Beiträge: 2669 Wohnort: Hamburg |
Japp.
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:
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 Am PK in der Messdatentabelle ändert sich dabei nichts, denn offenbar hängen die Messwerte von Standort *und* Sensor *und* Timestamp ab. |
Projektleitung
Anmeldungsdatum: Beiträge: 12829 |
Ich verliere langsam die Übersicht. M.E. gibt es folgende Optionen, die sich anbieten (es gibt natürlich noch beliebig viel mehr):
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.
Das stimmt nicht, denn Lysander schrieb:
Alle relevanten IDs sind also in der Tabelle vorhanden und damit können Messwerte eindeutig zugeordnet werden.
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
Dort könnten auch noch weitere Eigenschaften eines Sensors gespeichert sein.
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.
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 |
(Themenstarter)
Anmeldungsdatum: 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 |