Normalisierung 2. Form

Computer: Software & Programmierung Datenbanken allgemein
#1

Moin zusammen.
Ich möchte eine kleine und einfache DB schreiben, hänge jedoch an der Normalisierung fest.
Ich will die Zählerstände (Strom, Warmwasser, etc) meiner Wohnung verwalten um später Statistiken über Verbrauch usw. zu erstellen.
Die erste Normalform sieht so aus:
ZählerNr | ZählerArt | ZählerStandort| Datum | Stand |
Wenn ich die Abhängigkeiten festlege komme ich darauf, dass die ZählerArt und ZählerStandort von ZählerNr abhängen. Der Stand jedoch hängt von zwei „Werten“ ab- ZählerNr und Datum. Einverstanden?
Wie wird die 2. und evtl. 3. Normalform aussehen?

Danke.
Vitali

#2

Moin, Vitali,

Die Frage ershcließt sich mir nicht ganz, deshalb von vorne:

Die Zählernr identifiziert den Zähler. Der Standort ist dann interessant, wenn der Zähler morgen ausgebaut werden kann, woanders eingebaut und Dich dieser Ortswechsel auch noch interessiert. Ich tippe, eher nicht.

Der Stand jedoch hängt von zwei „Werten“ ab- ZählerNr und Datum.

Stimmt. Damit hast Du dann die Entitäten

Zähler (Zählernr, Typ, Standort)
und
Stand (Zählernr, Ablesedatum, Zählerstand)

Stand ist in der 2.NF; sie ist in der 3.NF, wenn ihre Nichtschlüsselattribute nicht voneinander abhängen. Die Frage stellt sich hier nicht, weil nur 1 solches Attribut vorhanden ist.

Gruß Ralf

#3

OK, den Standort des Zählers können wir weglassen- es ändert nichts an der Sache.

So wie ich deinen Vorschlag verstehe, hat die Entität „Stand“ zwei Primärschlüssel: ZählerNr und Datum. Habe nicht gewusst, dass das möglich ist? (habe sofort in Access tatsächlich 2 Felder mit dem PK „markiert“)
Danke, Ralf, das war neu für mich.

Ich schätze aber dass in diesem Fall Redundanzen entstehen. Lese ich an einem Tag 3 Zähler ab, wird 3 mal das gleiche Datum gespeichert. Liege ich da falsch?

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

Hallo,

das Modell von Ralf ist vorbildlich.

OK, den Standort des Zählers können wir weglassen- es ändert
nichts an der Sache.

So wie ich deinen Vorschlag verstehe, hat die Entität „Stand“
zwei Primärschlüssel: ZählerNr und Datum. Habe nicht gewusst,
dass das möglich ist? (habe sofort in Access tatsächlich 2
Felder mit dem PK „markiert“)
Danke, Ralf, das war neu für mich.

Es handelt sich NICHT um 2 Primärschlüssel, sondern um einen Promärschlüssel mit 2 Attributen. Der Unterschied ist wesentlich.
…
CONSTRAINT pk_tab PRIMARY KEY (zaehlernummer, ablesedatum)
…

Ich schätze aber dass in diesem Fall Redundanzen entstehen.
Lese ich an einem Tag 3 Zähler ab, wird 3 mal das gleiche
Datum gespeichert. Liege ich da falsch?

Ja.
Man kann nicht zwei Einträge an einem Tag machen. Jedenfalls nicht für denselben Zähler. Wozu denn auch.

Gruß

Peter

Moin, Vitali,

Die Frage ershcließt sich mir nicht ganz, deshalb von vorne:

Die Zählernr identifiziert den Zähler. Der Standort ist dann
interessant, wenn der Zähler morgen ausgebaut werden kann,
woanders eingebaut und Dich dieser Ortswechsel auch noch
interessiert. Ich tippe, eher nicht.

Der Stand jedoch hängt von zwei „Werten“ ab- ZählerNr und Datum.

Stimmt. Damit hast Du dann die Entitäten

Zähler (Zählernr, Typ, Standort)
und
Stand (Zählernr, Ablesedatum, Zählerstand)

Stand ist in der 2.NF; sie ist in der 3.NF, wenn ihre
Nichtschlüsselattribute nicht voneinander abhängen. Die Frage
stellt sich hier nicht, weil nur 1 solches Attribut vorhanden
ist.

Gruß Ralf

#5

Moin, moin,

Man kann nicht zwei Einträge an einem Tag machen. Jedenfalls
nicht für denselben Zähler. Wozu denn auch.

… es sein denn, man interpretiert den angegebenen Datentyp ‚Datum‘ etwas freizügiger um, und verwendet einen Timestamp (und zwar mit einer so hohen Auflösung, dass keine zwei Timestamps mit demselben Wert vorkommen können).

Bei herkömmlichen Gas/Wasser/Stromzählern mag ein mehrfaches Abspeichern der Stände ja Blödsinn sein; aber vielleicht will ja jemand überprüfen, wieviel Wasser die Waschmaschine heute nacht zwischen 4 und 6 Uhr verbraucht hat …

gruss
bernhard

#6

Gelöst: Normalisierung 2. Form
In dieser Sache bin ich weiter. Es hat daran gehackt, dass ich nicht wusste, dass mehrere Attribute zu einem PK „gemacht“ werden können.
Meine Lösung sieht so aus:

Zähler (Zählernr, Typ, Standort)
Stand (Zählernr, DatumID, Zählerstand)
Datum (DatumID, Datum)

Ich habe das Datum in eine eigene Tabelle ausgelagert, da ich denke, dass hier Redundanzen entstehen.

@Bernhard: in meinem Fall reicht es aus den Zählerstand max. 1 mal am Tag abzulesen. Aber, das was du angesprochen hast ist ein guter Grund die DB so zu konzepieren, dass an einem Tag mehr als 1 Stand eingepflegt werden kann.

Die Aufgabe ist gelöst.
Danke.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#7

Zu viel des Guten
Hi Vitali,

Datum (DatumID, Datum)

das Datum als Tabelle zu speichern ist unnötig, genauer gesagt unsinnig. Es gibt keinen vernünftigen Grund, Dinge zu speichern, die außer ihrer Identität keine Eigenschaften haben.

Durch die Vereinbarung als Datentyp date ist sichergestellt, dass in Stand.Datum ein gültiges Datum steht.

Gruß Ralf

#8

Es ist mir klar, dass die Entität „Datum“ nur ein Attribut haben wird. Und, dass die DB auch nur mit den 2 gennanten Entitäten funktioniert. Aber…
Werden an einem Tag 5 Zähler abgelesen- würde in der Tabelle „Stand“ (wäre „Datum“ nur ein Attribut von…) 5 mal z.B. „22.10.2005“ auftauchen. Ist das nicht redundant?
Würde es nicht weniger Speicher belegen, wenn in einer separaten DB das Datum 1 mal gespeichert wird und dann mittels Beziehung nur auf dieses „hingewiesen“ würde?
Ausserdem hängt das „Datum“ von keinem anderen Schlüssel ab, wieso sollte es dann Attribut einer Entität sein (das Datum hängt nicht vom Zählerstand und nicht vom Zähler ab). Laut 2. Normalform: muss jedes Nichtschlüsselfeld vom Schlüsselfeld abhängen.

Danke.
Vitali

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#9

Hallo,

unter Datum verstehen wir DATETIME, also Datum mit Uhrzeit.
Da es ja wohl kaum vorkommen wird, dass die Messungen öfter als im Millisekundenabstand erfolgen, kannst du das Datum getrost als Schlüssel nehmen. So macht es WIRKLICH jeder.

Alternativ nimmt man einen künstlichen Schlüssel, eine einfache Reihenfolgenummer, z.B. über eine Sequenz (wenn die DB das untertsützt) und hat das Datum als reines Faktenatribut dabei. (Wobei das dann eigentlich nicht ganz richtig normalisiert ist)

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#10

Hi Vitali,

Laut 2. Normalform: muss jedes Nichtschlüsselfeld vom Schlüsselfeld
abhängen.

Datum ist Schlüsselattribut, nicht Nichtschlüsselfeld :smile:))

Gruß Ralf