SQL Wie kann ich die zyklische Abhängigkeit in dieser Datenbankstruktur entfernen?

Hallo SQL-Fans,

ich sitze gerade an einer Android-App für eine Zählerdatenerfassung.
Die App verwendet eine SQLite-Datenbank, an der ich gerade wieder bastle. Ich bin jedoch nicht wirklich 100 % zufrieden damit, da ich, wie im Titel angedeutet, eine zyklische Datenstruktur habe.
So sieht das ganze zurzeit aus:



Folgendes zur Erklärung:

• Die Tabellen "Zähler" und "Ablesewert" sind mehr oder weniger fixe Tabellen. Sie sind sozusagen Listen über die tatsächlich vorhandenen Geräte. Ein "Zähler" ist dabei das eigentliche Stück Hardware. Der Zähler kann mehrere verschiedene Werte haben, die abgelesen werden müssen. (Tabelle "Ablesewert" - der Name ist Mist, hat jemand bessere Vorschläge?)
  Bei einem Gaszähler gibt es nur einen: den Gasverbrauch. Bei einem Stromzähler wiederum zum Beispiel gibt es verschiedene Werte, da Hoch- und Niedertarif, sowie Wirk- und Blindleistung unterschieden werden. Ein Tank hat Werte wie "Füllstand" und "Lieferung".
• Ein Element der Tabelle "Ablesebogen" wird einmal pro Tag erstellt (Spalte Datum ist UNIQUE), spiegelt also den tatsächlichen Rundgang wieder.
• Für jeden Zähler der nun abgelesen wird, wird ein Element der Tabelle "Ablesung" erzeugt. Das ist wichtig, da ich wissen muss, welche Zähler tatsächlich besucht wurden. Es kann ja sein, dass ein Zähler besucht wurde, aber dieser defekt ist, und somit keine Daten abgelesen werden können. Dann wird das auch als Kommentar hinterlegt.
• Zu jeder "Ablesung", die ja einem physischen Zähler entspricht, werden nun die entsprechenden "Ablesewerte" abgelesen, und als "Zählerstand" gespeichert. Im Defekt-Fall wie im Punkt darüber. würden hier für diese "Ablesung" keine Einträge erzeugt.

Und bei dieser ganzen logischen Datenstruktur fällt es mir schwer, diesen Kreis aufzuheben.
Hat jemand von euch ein paar gute Tipps dazu und kann mir Feedback zu dieser DB geben?

Es grüßt,
der Physikbuddha

Ich kann da keinen Zykel erkennen (das wäre ja eine Abhängigkeit von der Form A -> ... -> A). Bei dir gehen alle Abhängigkeiten in eine Richtung, nämlich vom Zählerstand zum Zähler - nur dass es eben zwei parallele Ketten gibt, eine über Ablesung und eine über Ablesewert.

Das ist prinzipiell nicht schlimm, allerdings könnte man noch Redundanzen entfernen. Ob das sinnvoll ist, hängt aber vom Kontext ab. Zum Beispiel ist die Abhängigkeit Ablesung -> Zähler redundant, weil du stattdessen auch zum Zähler kommst, indem du den zu der Ablesung gehörigen Zählerstand (bzw. die Stände) hernimmst und dich von dort aus über den Ablesewert zum Zähler vorarbeitest. Das ist aber evtl. wesentlich komplizierter als jetzt, so dass es absolut gerechtfertigt sein kann, die jetzige Abhängigkeitsstruktur beizubehalten.

Danke, NullPointer, für deine Antwort!

Ich habe mich mit dem "zyklischen" Verhalten vielleicht falsch ausgedrückt. Denke, dass "Redundanz" es besser beschreibt.

Die Verknüpfung von Ablesung und Zähler kann ich leider nicht entfernen. Das Problem ist ja, dass wie oben beschrieben ein Zähler mal kaputt ist, und dann keine Zählerstände aufgenommen werden. Trotzdem gilt dieser Zähler dann als besucht. Dann würde das Ablesung-Objekt mit dem Kommentar aber in der Luft hängen, ohne Verknüpfung zu einem Zählerobjekt.
Hm, oder ich lasse Null-Werte für Zählerstand.Wert zu, und erstelle somit immer ein oder mehrere Zählerstand-Objekte.
Ich werd mir das mal in Ruhe durch den Kopf gehen lassen.

Hast du / habt ihr noch Verbesserungsvorschläge für die Tabellenbenennung? Manchmal blicke ich selbst nicht mehr durch, aber mein Einfallsreichtum ist magerer als ein Kopfsalat.

Dann ist es auch völlig in Ordnung, diese Beziehung so zu lassen. Vielleicht hilft es ja, dir zwei parallele Strukturen vorzustellen: Der Ablesewert verhält sich zum Zähler wie der Zählerstand zur Ablesung. Nur dass die eine Struktur (Zähler / Ablesewert) permanent ist und die andere (Ablesung / Zählerstand) eine Momentaufnahme darstellt.

Wichtiger ist IMHO sowieso weniger das Schema in der Datenbank, sondern die (Objekt-)Struktur in der Software selbst, weil dort die eigentliche Logik ihren Platz hat. Wie man's dann wegspeichert, ist ein Implementationsdetail.

Wenn in deinem Umfeld schon ein Begriff dafür gängig ist, nimm den. Ansonsten denk dir was aus, was dir einleuchtet