Cracymike
(Themenstarter)
Anmeldungsdatum: 18. August 2014
Beiträge: 41
|
Ok ich gebe zu ich bin Doof:-) Also wenn ich das jetzt "Richtig" verstanden habe Muss doch dann nur 1 neue DB mit einer Tabelle geschaffen werden ? In dieser Tabelle werden dann einfach alle Transformierten Daten aus den Quelldateien eingelesen. Danach habe ich einfach eine Tabelle die alle Informationen enthält. Den Rest macht mann dann mit Views ( noch keine Ahnung was das ist . Gruß Mike
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
Cracymike schrieb: Also wenn ich das jetzt "Richtig" verstanden habe Muss doch dann nur 1 neue DB mit einer Tabelle geschaffen werden ?
Nein! S. hier ❗
|
Cracymike
(Themenstarter)
Anmeldungsdatum: 18. August 2014
Beiträge: 41
|
Ja ich habe schon verstanden das es am besten eine Tabelle gibt welche eine eindeutige id für den Sensor zur Verfügung stellt. Wenn ich aber sage das solche Informationen einfach nicht zur Verfügung stehen, zumindest nicht mit der benötigten Sicherheit, muss es doch möglich sein das ganze ohne eine solche Tabelle zu erledigen? Gruß Mike
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
Ach so... klar geht das - aber: Du darfst dann da auch keine künstlichen Relationen hinein interpretieren. Du brauchst aber auf jeden Fall einen wie auch immer gearteten Schlüssel, der eine Datenzeile eindeutig bestimmt. Wenn der ohne einen Sensor auskommen kann, ok, wenn nicht, kannst Du die Daten so nicht in einer Tabelle ablegen. Ich habe das Gefühl, dass Dir die Grundlagen der relationalen Datenbanken inkl. der Modellierung fehlen. Da solltest Du erst einmal nachziehen, um ein Gefühl zu bekommen, wie man von einem Problem zum DB-Modell kommt.
|
Cracymike
(Themenstarter)
Anmeldungsdatum: 18. August 2014
Beiträge: 41
|
Also ich habe bereits viele Jahre mit dem Auslesen von Datenbanken zugebracht, das hineinbekommen der Daten haben immer andere gemacht:-) Deine Ursprüngliche Strategie war ja eine Tabelle anzulegen welche alle Standorte mit zugehörigem Sensor enthält dadurch hätte jeder Sensor einen eindeutige ID bekommen. Diese ID hättest du dann verwendet um aus der Messwerte Tabelle die entsprechenden Daten zu filtern. Dazu hätte es doch aber immer noch einer zusätzliche ID in der Wertetabelle bedurft da der Timestamp ja nicht einmalig ist, es kann ja durchaus zu gleichen Zeiten bei unterschiedlichen Sensoren kommen. Deshalb war mein Gedanke die Usprünglichen .txt Dateien entsprechend im Script zu ändern, meiner Ansicht nach passiert so etwas schon, nur mit anderen Informationen. Anhand der .txt weis ich ja den Sensor und das Datum beides im Dateinamen enthalten zusätzlich befindet sich in der Datei eine unbestimmte Anzahl an Messwerten, abhängig vom Intervall oder Event, mit einer zugehörigen Zeit. Bis jetzt ist es so, und das ist Mist weil es sich auch beschi... abfragt, das es für jedes Jahr eine DB gibt und für jeden Sensor eine Tabelle in dieser. Viel besser ist es natürlich das mit den beiden Tabellen zu machen wie vorgeschlagen. Dann müsste es aber in der Lage sein die Sensoren und Standorte selber zu pflegen, bedeutet wenn es einen neuen Sensor findet muss es die Standort-Tabelle automatisch um einen Sensor erweitern. Deshalb mein Gedanke die Bezugstabelle zu umgehen und den Standort und den Sensor zusammen mit der Zeitinformation und dem Messwert in die neue DB zu schreiben. Die Standorte sind natürlich bekannt und entsprechend auch schon in einer DB und Tabelle gespeichert für die VPN-zugangsinformationen.
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
Noch einmal: Du brauchst einen sogenannten Primärschlüssel (PK) für Deine Messwert-Tabelle. (Imho sollte jede Tabelle über einen PK verfügen) Wie der aufgebaut ist, musst und kannst Du selber entscheiden. Wenn der Sensor dafür relevant ist, kommst Du wohl nicht drum herum, diesen dabei zu berücksichtigen! Ob der Eintrag nun für eine weitere Relation relevant ist und man damit über die Einführung einer künstlichen ID für einen Sensor nachdenken sollte (etwa, um Zusatzinformationen zu speichern, wie Name oder Zugehörigkeit zu einem Standort), kannst nur Du entscheiden. Natürlich kann der Wert auch "as it is" als Wert in der Datentabelle auftauchen. (Solange eben die Integrität gewahrt bleibt).
|
Cracymike
(Themenstarter)
Anmeldungsdatum: 18. August 2014
Beiträge: 41
|
Das mit dem Primärschlüssel habe ich verstanden, kann der Primärschlüssel nicht auch einfach eine fortlaufende Zahl sein? Alle anderen Informationen sind dann in der Tabelle enthalten und für
mich auswertbar ich kann jederzeit die Daten bezogen auf den Standort und die Zeit abfragen, es werden immer nur Daten eines Standortes benötigt es werden nicht zwei Standorte miteinander verglichen. Ich glaube mir ist gerade klar geworden das du wahrscheinlich davon ausgehst das Sensornamen eindeutig sind sind sie nicht die Namen wiederholen sich ich werde aber niemals eine Abfrage haben nach Sensornamen, sondern immer nach Standort .
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
Cracymike schrieb:
Deine Ursprüngliche Strategie war ja eine Tabelle anzulegen welche alle Standorte mit zugehörigem Sensor enthält dadurch hätte jeder Sensor einen eindeutige ID bekommen. Diese ID hättest du dann verwendet um aus der Messwerte Tabelle die entsprechenden Daten zu filtern. Dazu hätte es doch aber immer noch einer zusätzliche ID in der Wertetabelle bedurft da der Timestamp ja nicht einmalig ist, es kann ja durchaus zu gleichen Zeiten bei unterschiedlichen Sensoren kommen.
Genau. Diese Id wird dann benutzt zwischen den zwei Tabellen zu joinen.
Deshalb war mein Gedanke die Usprünglichen .txt Dateien entsprechend im Script zu ändern, meiner Ansicht nach passiert so etwas schon, nur mit anderen Informationen. Anhand der .txt weis ich ja den Sensor und das Datum beides im Dateinamen enthalten zusätzlich befindet sich in der Datei eine unbestimmte Anzahl an Messwerten, abhängig vom Intervall oder Event, mit einer zugehörigen Zeit.
Der Import sähe so aus, wenn man ad hoc einfügen will:
Finden des Sensors in der Sensortabelle basierend auf irgendwelchen Kriterien (Standort...) und Id merken. Falls nicht gefunden, neuen Datensatz in der Tabelle anlegen und die neue Id merken. Beim Schreiben der Daten in die Messwert-Tabelle die oben gewonnene Id zusammen mit den Messdaten (Zeitstempel, Werte etc.) einfügen.
Falls man die Sensor-Tabelle manuell pflegen will, ändert sich Schritt 2 zu "Falls nicht gefunden, Abbruch mit Fehler".
Bis jetzt ist es so, und das ist Mist weil es sich auch beschi... abfragt, das es für jedes Jahr eine DB gibt und für jeden Sensor eine Tabelle in dieser.
Genau. Das ist schlimmes Design.
Viel besser ist es natürlich das mit den beiden Tabellen zu machen wie vorgeschlagen. Dann müsste es aber in der Lage sein die Sensoren und Standorte selber zu pflegen, bedeutet wenn es einen neuen Sensor findet muss es die Standort-Tabelle automatisch um einen Sensor erweitern.
Genau (s.o.). Cracymike schrieb: Das mit dem Primärschlüssel habe ich verstanden, kann der Primärschlüssel nicht auch einfach eine fortlaufende Zahl sein?
Kann er. Das ist ein Surrogatschlüssel, den man oft aus Sequenzen oder als UUID generiert.
Alle anderen Informationen sind dann in der Tabelle enthalten und für
mich auswertbar ich kann jederzeit die Daten bezogen auf den Standort und die Zeit abfragen, es werden immer nur Daten eines Standortes benötigt es werden nicht zwei Standorte miteinander verglichen.
Du wirst aber die Information über den Standort in der der Tabelle finden, die ich "Sensor" genannt habe. Du selektierst dann die Daten, indem Du einen Join machst zwischen den beiden Tabellen mit einem Filterkriterium für welche Sensoreigenschaften auch immer - ob das nun der Name, Standort oder die Modellbezeichnung des Herstellers ist.
Ich glaube mir ist gerade klar geworden das du wahrscheinlich davon ausgehst das Sensornamen eindeutig sind sind sie nicht die Namen wiederholen sich ich werde aber niemals eine Abfrage haben nach Sensornamen, sondern immer nach Standort .
Nein, ich denke, davon geht Lysander nicht aus. Wir wissen einfach nicht, was einen Sensor in Deinem Modell ausmacht und was Du darüber speichern musst / willst. Ciao robert
|
Cracymike
(Themenstarter)
Anmeldungsdatum: 18. August 2014
Beiträge: 41
|
Ok dann hier das Szenario: Der Standort ist eine Anlage. Mit Standort ist tatsächlich ein Ort gemeint. An jedem Ort gibt es verschiedene Sensoren z.B. Druck, Füllstand, Rotation u.s.w. . Je nach Größe der Anlage variiert die Anzahl dieser Sensoren.
Angezeigt/Abgefragt werden sollen immer nur die Daten eines Standortes zwecks Graphischer Darstellung. Daher auch mein Ursprünglicher Wunsch nach Tabellen mit bereits aggregierten Daten Stunde/Tag/Monat. Diese Konzept bin ich noch aus dem Callcenter gewohnt wobei dort die kleinste ebene 15 min war:-). Ich hoffe das hilft. Gruß mike
|
Cracymike
(Themenstarter)
Anmeldungsdatum: 18. August 2014
Beiträge: 41
|
So ich noch mal, ich habe ja das script weiter oben bereits gepostet besteht die Möglichkeit das ihr mir bitte dabei behilflich seit das ding anzupassen. Da ich aktuell noch keinen Plan habe wie die genaue Syntax ist bekomme ich das nicht allein hin 😢 . Wenn ich das eventuell richtig verstanden habe gibt es in dem Script Zwei stellen die nicht mehr benötigt werden Das anlegen der Datenbank für das Jahr und das anlegen der Tabellen, hier benötige ich ja zukünftig nur noch
eine Datenbank mit der Messwertetabelle. Ich habe aber keine Ahnung an welchen stellen ich das auskommentieren soll. Mein zweiter Knackpunkt ist das umwandeln der .txt Dateien in das CSV Format, da an dieser stelle ja die Informationen geändert werden müssen. Bitte Bitte Bitte bin am Verzweifeln... Gruß Mike
|
snafu1
Anmeldungsdatum: 5. September 2007
Beiträge: 2123
Wohnort: Gelsenkirchen
|
Nichts für ungut, aber dein Skript ist ziemlich unübersichtlich und man hat auch nicht den Eindruck, dass du planvoll agierst. Den Ablauf des Ausführens eines SQL-Statements mitsamt der ggf nötigen Fehlermeldung könnte man in eine Funktion stecken, die dann mit den Parametern sql_stmt und error_msg (oder so ähnlich) arbeitet. Dann hätte man auch mehr Übersicht drin, weil man die Statements an einer zentralen Stelle sammeln kann.
|
Cracymike
(Themenstarter)
Anmeldungsdatum: 18. August 2014
Beiträge: 41
|
Du hast völlig recht ich bin Planlos, das Script habe ich geerbt und wenn man selber fast keinen Plan hat muss man versuchen einen zu bekommen und ich bezeichne mich nicht als "Beratungsresistent" und bin hier ins Forum gekommen um meinem Problem Herr zu werde, und mit Hilfe derer die Ahnung haben etwas zu lernen. Das es bestimmt bessere Lösungen gibt ist mir durchaus klar aber das Script funktioniert fast und der Ersteller ist nicht mehr zu kriegen. Also mein Plan erst mal das anpassen dabei lernen und es im Anschluss, wenn die Katze vom Herd ist besser machen, aber nacheinander. Gruß Mike
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Cracymike schrieb: Also mein Plan erst mal das anpassen dabei lernen und es im Anschluss, wenn die Katze vom Herd ist besser machen, aber nacheinander.
Also, ich kann Dir auch nur empfehlen, das nicht so zu machen, sondern schön planmäßig, genau wie snafu1 vorschlägt ! Es ist viel mehr Arbeit, ein solches (etwas chaotisches !) Skript zu verstehen und nachzubessern, als es selber von der Pike auf neu zu machen:
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 !) Überleg Dir, wie die Datenbank aussehen soll, richtig sauber, mit ihrer Struktur. (oder ist die vorgegeben, und Du musst sie nehmen wie sie ist ?) 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.
Wenn Du uns Deine Überlegungen zu den Zwischenschritten verrätst, helfen wir Dir auch gerne. LG, track
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
@track: Genau so 👍 track schrieb: Wenn Du uns Deine Überlegungen zu den Zwischenschritten verrätst, helfen wir Dir auch gerne.
Und noch ein 👍 @Cracymike: Es wurde ja schon so viel geschrieben - mache es einfach sauber, gründlich und solide! So doll kann der Zeitdruck ja auch nicht sein; der Thread dauert ja schon lange an, *ohne* dass etwas grundlegendes passiert ist, gel 😉 Und wie track ja nun erneut schrieb: So schwer scheint das alles nicht zu sein, wenn man mit Struktur dran geht. Überzeuge Deine Entscheider eben davon, dass es nur so machbar ist.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
Lysander schrieb:
Überzeuge Deine Entscheider eben davon, dass es nur so machbar ist.
Das ist manchmal schwerer als die Implementierung. ☺ Argumente:
Du musst das auch in Zukunft pflegen und wenn Du nicht die Zeit bekommst, es zu verstehen, dann dauert die kleinste Änderung ewig. Besseres Datenbankschema, das einfachere Abfragen erlaubt. Man kann dann z.B. auch Werte von verschiedenen Sensoren korrelieren. Auch automatische Werkzeuge wie z.B. Reportgeneratoren kommen mit so einem Schema besser zurecht. Du lernst etwas - das ist gut für die Motivation.
|