LibreOffice-Forum

Hi,

wie ich an anderer Stelle bereits angedeutet habe, bin ich in Sachen Datenbankerstellung noch ein absoluter Noob, während ich mich früher mit Abfragen und SQL durchaus schon beschäftigt habe.

Bei uns im Hause wurde bisher die Schließfachverwaltung mehr oder minder handschriftlich in eine Tabelle eingetragen, das ganze natürlich u.a. getrennt nach Miete und Versicherungsbeiträgen etc.

Für die Erstellung von Serienbriefen (z.B. für Rechnungen) wurden die Adressen dann komplett in ein Tabellendokument (jeweils neu?) erfasst und dann das Seriendokument erstellt.

Vor kurzem ist das bei mir aufgeschlagen, daher habe ich mich entschlossen, dass ich die Schließfachverwaltung gerne als Datenbankanwendung mit allen zu pflegenden Daten anlegen möchte.

Grundlage ist im Prinzip zunächst eine einzelne und hier angehängte Tabelle mit allen relevanten Feldern, soweit bisher vorhanden. Weitere Felder könnten gegebenenfalls noch hinzukommen, mir fallen aktuell aber noch keine weiteren Felder ein.

Ausgangssituation:
1. Wir haben insgesamt zwei Geschäftsstellen wo Schließfächer in verschiedenen Größen vermietet werden.
Geschäftsstelle 1: 96 Schließfächer
Geschäftsstelle 2: 30 Schließfächer
Schließfachgrößen: klein, mittel oder groß -> jeweils dem einzelnen Schließfach zuzuordnen
2. Die Schließfächer sind derzeit nur zum Teil vermietet, d.h. einige Schließfächer sind derzeit nicht in Verwendung bzw. stehen leer.
3. Für die Schließfächer ist eine Jahresmiete/Jahresgebühr zu entrichten, die auf verschiedene Weise (Zahlungsart) bezahlt wird.
Zahlungsarten: Dauerlastschrift (Mandatsreferenz erforderlich), Überweisung oder auch in Bar.
4. Manche Schließfächer sind auch mit einer bestimmten Versicherungssumme versichert, hier ist ein jährlicher Versicherungsbeitrag zu leisen, der ebenfalls per vorgenannter Zahlungsarten entrichtet werden kann. Die Mandatsreferenz für Miete und Versicherungen ist getrennt.
5. Die Mieter der Schließfächer sollen mit Adresse, Telefon-Nr. und E-Mail-Adresse hinterlegt werden.
6. Für etwaige Anschreiben soll zudem der jeweilige Kundenberater des Mieters als Ansprechpartner greifbar bzw. hinterlegt sein.

Zielbild:
1. Erstellung eines passenden/sinnvollen Datenbankschemas von Grund auf.
2. Es sollen möglichst keine redundanten Daten gehalten werden.
3. Erstellung von einem oder mehreren Erfassungsformularen mit Suchmöglichkeiten nach Schließfächern und/oder Mietern.
4. Erstellung von Abfragen zur Verwendung in anderen Programmteilen und/oder
5. Erstellung von Serienbriefen als Bericht direkt aus der Datenbank heraus.

In einem ersten Schritt möchte ich zunächst die Tabellen sinnvoll aufteilen und dann die richtigen Beziehungen zueinander schaffen. Hierzu werden ich vermutlich des öfteren Eure Hilfe benötigen, gerade wenn statt 1:n zum Beispiel eine m:n Beziehung benötigt wird, ...

Hylli

Der Anfang wäre denke ich geschafft, trotzdem stoße ich gerade auf mein erstes kleineres (?) Problem.

Nachdem ich schon fast wieder aufstecken wollte, habe ich Dank des Videos von F3K_Total zu m:n Beziehungen meinen ersten Ansatz für die Datenbank erstellt.

Ausgangssituation bisher:
- Geschäftsstelle 1: 96 Schließfächer (Nr. 1-96)
- Geschäftsstelle 2: 30 Schließfächer (Nr. 1-30)
- eine unbestimmte Anzahl von Kunden derzeit mit Kundennummer, Nachname u. Vorname
- jeder Kunde kann Mieter eines oder mehrerer Schließfächer pro Geschäftsstelle sein
- jedes Schließfach kann durch einen oder mehrere Kunden (gemeinschaftlich) gemietet sein
- jedes Schließfach hat eine bestimmte Größe

Ich denke das anhängender Ansatz mit m:n Beziehungen zwischen Geschäftstelle, Schließfach(-Nr.) und Kunden hier der richtige Ansatz sind?

Wo ich jedoch aktuell hänge:
Jedes Schließfach pro Geschäftsstelle hat exakt eine Größe -> klein, mittel oder groß.

Wie bekomme ich das hier am einfachsten gebacken?
Muss ich da noch eine weitere Relationstabelle mit Geschäftsstelle, Schließfach-Nr und Größe anlegen? Dann würde ich doch aber die Beziehung zwischen Geschäftsstelle und Schließfachnummer doppelt pflegen?!?

Hylli

Hallo hylli,

die Schließfachgröße gehört zu der Schließfachnummer. Also: tbl_Schliessfaecher bekommt einen Fremdschlüssel FK_ID_SF_Groesse und da hängst Du das Ding rein.

Gruß

Robert

Das hatte ich erst auch gedacht, aber:
- Es gibt sowohl in Geschäftsstelle 1 als auch Geschäftsstelle 2 eine Schließfach-Nr. 1
- Schließfach Nr. 1 in Geschäftsstelle 1 wäre z.B. klein und in Geschäftsstelle 2 hingegen groß

Die Eindeutigkeit eines Schließfaches ist m.E. nur durch Beziehung von Geschäftstelle und Schließfach gegeben, oder sehe ich das falsch?

Hylli

<klugscheiss>

Sorry, aber da muß die Realität sich der Datenbank anpassen.
Wikipedia sagt:

Eindeutigkeit ist eine Zuordnung, bei der ein Zeichen (zum Beispiel ein Wort, ein Satz) genau eine Bedeutung hat.

Eindeutigkeit ist nicht, wenn man eine Bedeutung aus anderen Dingen ableiten muß.

Dann müssen die Schließfächer eben in Zukunft A1... für die Geschäftsstelle 1 heißen und B1... für die Geschäftsstelle 2. Macht garantiert auch sonst das Leben leichter.

</klugscheiss>

Darf ich jetzt daraus ableiten, dass wir entweder unsere Nummernsystematik auf den Kopf stellen sollen, z.B. Schließfach-Nr. 101-196 für Geschäftsstelle 1 und 201-230 Geschäftsstelle 2, oder dass ich doch eine weitere Relationstabelle zwischen Geschäftsstelle und Schließfachnummer benötige?!?

Ersteres kommt vermutlich nicht in Frage...

Hylli

Hallo hylli,

bei etwas genauerer Betrachtung:
Bez_GS_SF_Person hat einen Primärschlüssel zu viel: FK_ID_Person.
Dann definierst Du das Schließfach nämlich genau in dieser Tabelle und dort über einen Fremdschlüssel auch die Größe.

Wenn Du den Primärschlüssel FK_ID_Person nicht aus der Schlüsselfunktion heraus nimmst, dann existiert kein Schließfach, das nicht einer Person eindeutig zugeordnet ist. Und wenn Du noch mehrere Personen einem Schließfach zuordnen möchtest, so musst Du eine zusätzliche Tabelle zwischen die Personentabelle und die Bez-Tabelle legen, damit eine n:m-Beziehung möglich ist. Da ist es dann fraglich, ob Du überhaupt eine Konstruktion mit zwei Primärschlüsseln für die genaue Schließfachdefinition (in Bez_..) nehmen solltest. Eine Durchnummerierung für beide Standorte wäre hier wohl einfacher zu Handhaben - und die dann als Schlüsselwert.

Gruß

Robert

Hallo Robert,

ich zitiere mal von weiter oben:

- jeder Kunde kann Mieter eines oder mehrerer Schließfächer pro Geschäftsstelle sein
- jedes Schließfach kann durch einen oder mehrere Kunden (gemeinschaftlich) gemietet sein
- jedes Schließfach hat eine bestimmte Größe

Wir haben Kunden die mehrere Schließfächer gemietet haben und wir haben Schließfächer die von mehreren Kunden gemietet werden, daher gehe ich doch davon aus, dass hier m:n-Beziehungen bestehen müssen, oder?

Hylli

Hallo hylli,

unsere Nummernsystematik auf den Kopf stellen

Es wäre erst dann meines Erachtens eine Systematik. Wobei ich eine Kombination mit vorangestellten Buchstaben empfehlen würde. Sonst kommt das nächste Problem, wenn die Geschäftsstelle 1 weitere vier Schließfächer aufstellt.

Ich habe etwas ähnliches mit Aufbewahrungsfächern, die jedes eine eindeutige Zuordnung haben. Es gibt keine zwei Fächer mit derselben Bezeichnung. Das Stichwort heißt: chaotische bzw. dynamische Lagerhaltung.

Gruß
Freischreiber

PS: Siehe meine Frage dazu und Roberts Lösung: https://libreoffice-forum.de/viewtopic.php?f=10&t=15179
Bei dieser Lösung "verbrauchen" sich die freien Schließfachnummern und man kann nur aus freien Schließfächern noch auswählen bei der Vergabe. Funktioniert sehr gut.

Hallo Hylli,

ja, die solltest Du definieren - aber zwischen einzelnen Schließfächern und einzelnen Personen, lso so etwas wie rel_Schliessfach_Person mit FK_ID_Schliessfach und FK_ID_Person. Die ergeben dann zusammen den Primärschlüssel.

Vorher solltest Du aber die Schließfächer klar bekommen. Und dazu hast Du Nummern und Orte und die Größe, die alle irgendwo in einer Tabelle zusammengefasst werden müssen. Da gehört eine ID_Schliessfach rein, die bei den wenigen Fächern ja die kleinste Zahlengröße haben kann. Und dann eben Ort, Nummer und Größe als Fremdschlüssel.

Gruß

Robert