von muhl » Di, 09.02.2010 16:14
Wow,
das ist natürlich eine weitreichende Frage.
Das erste, was in der Datenbanktheorie zählt, ist der Entwurf.
Ich fasse zusammen (auch auf die Gefahr hin zu wiederholen)
Ein Windpark hat mehrere Standorte.
Ein Standort hat mehrere Einzel-Zähler.
Ein Standort hat einen Hauptzähler.
Daraus ergibt sich folgendes Modell:
Da der Windpark die Datenbank als solche ist, bedarf es keiner Tabelle dafür.
Ein erster Entwurf sähe so aus wie im Anhang dargestellt. (Leider bekomme ich den Anhang nicht angehängt.... Werd mal nachdenken, warum...)
Du gibst als Tabelle die Standorte mit ihren eindeutigen IDs, einem Namen und anderen Infos und dem zugewiesenen Hauptzählern ein.
Du gibst als Tabelle die Zähler mit ihren eindeutigen IDs (wahrscheinlich Zählernummer) mit einer Bezeichnung und anderen Infos dazu ein.
Du gibst als Hilfstabelle die Standort-ID, die Zähler-ID, das Datum der Ablesung und den Stand ein.
Du gibst als Hilfstabelle die Zähler-ID, das Datum der Ablesung und den Stand ein.
Ich habe mal den ersten Entwurf mit roten Korrekturen so belassen wie er mir eingefallen ist um zu zeigen, dass das nicht so einfach ist. Die roten Striche sind Korrekturen. Wenn der Entwurf stimmt, trägst du ihn einfach als Tabellen ein.
Alles andere sind dann Abfragen oder direkte SQL-Statements, die dir die Ergebnisse ausweisen. Berechnete Felder werden NICHT in Tabellen festgehalten.
Um das nachzuvollziehen empfehle ich dir nach dem Begriff Normalisierung zu googeln und an Beispielen nachzuvollziehen. Alles andere macht keinen Sinn, weil du sonst wie ein Schwein vorm Uhrwerk sitzt und auf die Datenbank schaust. Wenn auch nur ein Rädchen mal nicht so läuft wie du willst, dann kommst du nicht weiter.
Wenn du die Normalisierung "gelernt" hast, dann sag Bescheid, dann machen wir weiter.
Ach ja, die ersten drei Normalformen reichen völlig aus, weitere brauchst du dir (noch) nicht anzusehen.
Gruß,
Maik
Wow,
das ist natürlich eine weitreichende Frage.
Das erste, was in der Datenbanktheorie zählt, ist der Entwurf.
Ich fasse zusammen (auch auf die Gefahr hin zu wiederholen)
Ein Windpark hat mehrere Standorte.
Ein Standort hat mehrere Einzel-Zähler.
Ein Standort hat einen Hauptzähler.
Daraus ergibt sich folgendes Modell:
Da der Windpark die Datenbank als solche ist, bedarf es keiner Tabelle dafür.
Ein erster Entwurf sähe so aus wie im Anhang dargestellt. (Leider bekomme ich den Anhang nicht angehängt.... Werd mal nachdenken, warum...)
Du gibst als Tabelle die Standorte mit ihren eindeutigen IDs, einem Namen und anderen Infos und dem zugewiesenen Hauptzählern ein.
Du gibst als Tabelle die Zähler mit ihren eindeutigen IDs (wahrscheinlich Zählernummer) mit einer Bezeichnung und anderen Infos dazu ein.
Du gibst als Hilfstabelle die Standort-ID, die Zähler-ID, das Datum der Ablesung und den Stand ein.
Du gibst als Hilfstabelle die Zähler-ID, das Datum der Ablesung und den Stand ein.
Ich habe mal den ersten Entwurf mit roten Korrekturen so belassen wie er mir eingefallen ist um zu zeigen, dass das nicht so einfach ist. Die roten Striche sind Korrekturen. Wenn der Entwurf stimmt, trägst du ihn einfach als Tabellen ein.
Alles andere sind dann Abfragen oder direkte SQL-Statements, die dir die Ergebnisse ausweisen. Berechnete Felder werden NICHT in Tabellen festgehalten.
Um das nachzuvollziehen empfehle ich dir nach dem Begriff Normalisierung zu googeln und an Beispielen nachzuvollziehen. Alles andere macht keinen Sinn, weil du sonst wie ein Schwein vorm Uhrwerk sitzt und auf die Datenbank schaust. Wenn auch nur ein Rädchen mal nicht so läuft wie du willst, dann kommst du nicht weiter.
Wenn du die Normalisierung "gelernt" hast, dann sag Bescheid, dann machen wir weiter.
Ach ja, die ersten drei Normalformen reichen völlig aus, weitere brauchst du dir (noch) nicht anzusehen.
Gruß,
Maik