OpenOffice.info

Hallo,
wieder mal ein Neuer, der grundsätzliche Fragen stellt, die vielleicht keiner mehr lesen/hören kann.
Es geht um eine DB für einen Kleingartenverein.
Ich habe bereits eine Tabelle mit den Mitgliedsdaten erstellt und als Primärschlüssel die Spalte "Mitglied" mit aufsteigender Nummerierung definiert.
Nun möchte ich eine weitere Tabelle (Abrechnung o.ä.) erstellen, in der die Abrechnungsdaten (Wasserverbrauch, Stromverbrauch, ...) gespeichert werden.
Natürlich soll die DB nicht nur für ein Jahr genutzt werden, sondern ab jetzt für "alle" folgenden Jahre.
Muß ich nun für jedes folgende Jahr (also 2014, 2015, ...) jeweils eine weitere Tabelle (Abrechnung) erstellen, in der die dann geltenden Daten gespeichert werden?
Also wenn ich das Prinzip DB verstanden zu haben glaube, würde ich sagen JA. Oder?
Bitte nicht steinigen, sondern mich bestätigen, oder mir erklären, wie ich es richtig machen muß.
Vielen Dank!
Gruß
Lanius2

Hallo,

erst einmal ein fettes NEIN , zu jedes Jahr eine Tabelle.
Mein Vorschlag ist folgender :
1. Tabelle : Mitglieder ( ist von dir schon angelegt )
2.Tabelle : Verbrauch
Felder : VerbrauchsID [Autowert] , Jahr [Date] , Mitgliedsnummer [Integer] , Wasser [Double] , Strom [Double] ......... , was du für Verbrauchswerte pro Mitglied du haben möchtest.
Also nur zwei Tabellen , deren gemeinsamer Wert die Mitgliedsnummer ist. Dadurch sind Abfragen und Berichte einfach zu gestalten.

Nur eine kleine Ergänzung:
Das Jahr wird vermutlich eher ein vierstelliges Zahlenfeld als ein Datum sein. Vielleicht wird ja auch nur das Abrechnungsdatum gespeichert und die Abrechnung grundsätzlich auf das direkt davor liegende Jahr bezogen.

Gruß

Robert

boser hat geschrieben: Also nur zwei Tabellen , deren gemeinsamer Wert die Mitgliedsnummer ist. Dadurch sind Abfragen und Berichte einfach zu gestalten.

D.h., auch in der 2. Tabelle ist die Mitgliedsnummer auch der Primärschlüssel?
Und die beiden Tabellen haben eine 1:1-Beziehung?

Danke auch für den Hinweis auf das Handbuch!

Hallo lanius2,

zwei Tabellen, aber die zweite hat einen separaten Primärschlüssel. Die Mitgliedsnummer ist als Fremdschlüssel vertreten. Schließlich soll zur gleichen Mitgliedsnummer jedes Jahr ein neuer Datensatz entstehen. Beziehung von Mitglieder zu Verbrauch ist dann 1:n.

Gruß

Robert

lanius2 hat geschrieben:D.h., auch in der 2. Tabelle ist die Mitgliedsnummer auch der Primärschlüssel?

Nein. In der 2. Tabelle "Verbrauch" ist der Primärschlüssel der AutoWert VerbrauchsID.

Und die beiden Tabellen haben eine 1:1-Beziehung?

Nein, sondern eine 1:n-Beziehung. Für jedes Mitglied gibt es für jedes Jahr einen neuen Eintrag zum Verbrauch.

Jürgen

Hallo,

ich hab dir schnell mal eine kleine DB erstellt, fürs bessere Verständnis.

Vielen Dank!

Bin erst heute wieder dazu gekommen mal ins Forum zu schauen.

@boser
Warum haben MitgliederID und VerbrauchsID eigentlich AutoWert von Dir bekommen?

lanius2 hat geschrieben:@boser
Warum haben MitgliederID und VerbrauchsID eigentlich AutoWert von Dir bekommen?

Das kann ich natürlich nicht beantworten. Die Frage muss eigentlich lauten: "Gibt es einen Grund, diese ID nicht auf AutoWert zu setzen?" Die ID als Primärschlüssel hat grundsätzlich keine andere Bedeutung als die Identifizierung eines Datensatzes innerhalb der Datenbank.

In aller Regel muss der Anwender die ID nicht einmal kennen. Dafür kann es z.B. eine manuell erstellte eindeutige Mitgliedsnummer geben. Wenn diese Mitgliedsnummer nach bestimmten Regeln vergeben wird (Eintrittsjahr, Sektion, Parzelle), ist sie als Primärschlüssel sowieso nicht geeignet. Aber der Anwender will diese Nummer sehen und nicht die ID. All das wird vom Entwickler der Datenbank gesteuert.

Jürgen

lanius2 hat geschrieben:@boser
Warum haben MitgliederID und VerbrauchsID eigentlich AutoWert von Dir bekommen?

Hallo Ianius2,

wie Jürgen schon ausführte, hat es etwas mit dem Indexieren von Datensätzen zu tun.
Ich würde es so ausdrücken, jeder Index , den ich oder ein andrer Benutzer verwalten müsste , unterliegt der Fehlerquelle.
Einmal ein Index falsch geschrieben und nicht aufgepasst, kann es so krachen, das nix mehr geht.
Deshalb dieser Automatismus, der einen eine eindeutigen Schlüssel von vorn herein schreibt.

[EDIT]
Ich möchte nicht nach drei Jahren, hunderte Datensätze bei den zwei Tabellen durchsuchen, nur weil ein Index kaputt ist. Das wäre Sklavenarbeit ^ 3 .
[/EDIT]

Hm, und wenn der Anwender ja nun genau Daten aus der DB über die Mitgliedsnummer abfragen will, da er ja nur diese kennt, warum gibt es dann diesen Index?

Wird der Datensatz aus irgendeinem Grund mal gelöscht, statt korrigiert, bekommt er ja einen neuen Index.

Ist dieser Index also "nur" für das einwandfreie Funktionieren der DB "in sich" wichtig? Sprich, das die Beziehungen zwischen den Tabellen auch noch z.B. nach Löschung eines Datensatzes funktionieren?

Hach, immer diese Anfänger?!

Es geht um die eindeutigen Identifizierung eines Datensatzes in einer Datenbank.
Das Löschen von Datensätzen ist eigentlich im strengen Sinn verboten, da sonst Datensätze im leeren Raum stehen können.
Deshalb verwendet man ein Feld "gelöscht am" und damit ist der Datensatz als nicht mehr aktive markiert.
Der Index ist deshalb so wichtig, damit die Beziehung von zwei oder mehreren Tabellen ein eindeutig ist.
Deshalb sollte der Benutzer auch in der Indexierung nicht eingreifen dürfen, weil sonst der Schade sehr hoch seien kann.

lanius2 hat geschrieben:Hach, immer diese Anfänger?!

Ich wollte dich eigentlich nicht mit noch mehr Informationen zuschütten. Trotzdem soll der Hinweis auf die Einführung in SQL erfolgen. Die Frage nach den Primärschlüsseln wird unter anderem bei der Normalisierung behandelt.

boser hat auf verschiedene Bedeutungen des Primärschlüssels hingewiesen. (Der Begriff Index passt nur bedingt und könnte verwirren; unter einem Index versteht man grundsätzlich jeden Suchbegriff.)

@lanius2
Es ist durchaus sinnvoll, die Mitgliedsnummer als zusätzlichen eindeutigen Index (im Sinne eines Suchbegriffs) festzulegen. Dann kann der Anwender genau nach so einem "vernünftigen" Suchbegriff suchen. Aber alles, was innerhalb der Datenbank mit diesem Datensatz verknüpft ist (beispielsweise alle Abrechnungsdaten), wird ausschließlich über die ID verknüpft. Während die Mitgliedsnummer durchaus einmal geändert werden kann (der Gärtner bekommt eine andere Parzelle), bleibt die ID unverändert; seine bisherigen Verbrauchsabrechnungen hängen nicht in der Luft, sondern werden weiterhin diesem Mitglied zugeordnet.

Ich hoffe, der Sinn wird dir klarer. Jürgen

Ich danke Euch beiden!

Hinweise auf Literatur sind immer willkommen.