Office: (Office 2007) Eine Adressentabelle für alles Adresstypen

Hallo Forum,

Eine gute Struktur ist das A&O einer jeder Datenbank. Als Hobby versuche ich derzeit für die Verwaltung meiner FeWo eine Datenbank zu entwickeln. Das was ich hier „zusammen gebastelt“ habe, ist nicht optimal. Derzeit existieren zwei Tabellen für Adressen: Gäste und Besteller.



Erklärung:
Gäste sind alle Personen, die tatsächlich meine FeWo besuchen
Besteller ist z.B die Person, welche die Rechnung bezahlt.
In der Regel ist es die gleiche Person, aber gerade bei Geschäftsreisen buchen Firmen für Ihre Mitarbeiter.
Die Angaben PLZ, Ort und Anrede werden für beide Tabellen benötigt und stehen somit in einer Beziehung.
Nur - wie macht man es Richtig?
Stelle ich in einem Formular einen Vorgang (Gast & Besteller, Vorgang, Vorgangsdetails und Leistungen) dar, lässt Access es nicht zu, zwei Mal auf die Tabelle Gäste zu verweisen.

Was meint Ihr?
Grüße
Andreas

:)

 

Wenn es um die Beziehungen geht, dann musst du die Tabelle T1_Gaeste zweimal einfügen, dann kannst du zwei Beziehungen mit ihr aufbauen.

Die Benamsung finde ich jetzt etwas irreführend. Ich würde hier von einem Rechnungsempfänger und von einem Kunden sprechen.

Wie man das löst da gibt es schlussendlich viele Möglichkeiten. Aber unsere Profis halten sich wie immer zurück.*Smilie
Es gibt oft nur kontextabhängige Möglichkeiten und weniger richtig oder falsch.

Bei der Erstellung einer Tabellenstruktur muss für mich immer im Vordergrund stehen - was passiert wenn sich etwas ändert. Brauche ich historische Daten, oder kann ich einfach überschreiben? Oder brauche ich eine zeitliche Abgrenzung für Daten -> Also gültig von bis?

Bezüglich Besteller und Gäste würde ich eher in die Richtung tendieren eine Adresstabelle zu erstellen.
Weiters eine 1:1 Tabelle mit den zusätzlichen GrundDaten für die Kunden (Gäste).

LG Markus

 

Hallo markusxy,
danke für die schnelle Antwort.
Anbei die Umsetzung.



Die Beziehungen wurden mit der FeWo (vergleichbar mit der Zimmer-Nr. bei Hotels) erweitert. Hoffentlich richtig.
Ziel ist, dass bei Auswahl der FeWo (Nr.xy) (siehe Tabelle Vorgänge) auch nur die Leistungen der FeWo xy in die Auswahl kommen.
Die Daten werden mit VBA in die Tabelle Vorgänge_Positionen koppiert, damit die Positionen in den Vorgängen bei Preisänderungen (Tabelle Liestungen) unverändert bleiben.
Grüße
Andreas

 

Servus AndreasO,
erleichtere doch den Helfern die Arbeit und stelle eine zip oder rar DB ins Forum.
Nenne dabei auch deine Accessversion (möglichst Acc2003, um viele Helfer
ansprechen zu können).
Vor dem zippen oder raren die DB bitte in den Accessoptionen Komprimieren/Reparieren.
Am Ostermontag würde ich mal wieder reinschauen, um mich zu beteiligen.

 

Hallo Ohrkester,
deiner Aufforderung komme ich gerne nach.
Der Stand 15.04. findet Ihr hier:
http://www.ferienwohnung-ohler.de/ac...o_test2017.zip
Erstellt mit Access 2007
Aber Achtung:
Durch die Änderungen in der Struktur ist das Projekt nicht lauffähig.
Die Abragen, Formulare und VB-Code muss ich in den nächsten Wochen wieder neu erstellen.

 

Nachtrag:
Hallo Forum,
anbei neue Version, Stand 16.04.



Link der zip-Datei: siehe Beitrag vom 15.04.
So richtig verstehe ich die Vorteile einer 1:1 Beziehung für diesen Anwendungsfall nicht.
(Geändert wurden seit 15.04: Beziehungen und ein Formular "F_1Leistungen"

 

Warum machst du es dann?
Stell dir vor du hast eine einizige Tabelle für alle Adressen.
Kunden, Lieferanten, Lieferadressen u.v.m.
Dann gibt es Eigenschaften die haben nur Kunden, oder nur Lieferanten.
Bei allen anderen bleiben die Felder leer, oder man füllt sogar falsch aus, weil nicht klar ist, dass die Daten nur für eine Gruppe gedacht sind. usw.

Ja nach Zuordnung zu einer - oder auch mehreren Gruppen, kann man ein Subform für die zusätzlichen Daten einblenden, oder wie auch immer. Es ist einfach eine Möglichkeit.*Smilie

LG Markus

 

Hallo,
prinzipiell habe ich auch nix gegen 1:1 Beziehungen, aber in diesem Fall würde ich das eher nicht machen. Es ist nur eine weitere Tabelle mit einem einzigen Feld (Autokennzeichen), das kann man auch leer lassen.
Was bedeutet denn die VorgandsIDalt mit der noch mal verwendeten Tabelle für die Vorgänge ?

Die Briefanrede hängt ja direkt mit der Anrede zusammen, daher gehört dieses Feld in die Anredetabelle.

Was ist die Kategorie ?
Wieso ist diese Tabelle 2x verknüpft auf das gleiche Feld, das macht keinen Sinn.
Was ist der Vorgangstyp ?
Was darin das Feld LetzteNr ?
Was kommt in den Anschreibentext ?

Die DB kann ich mir nicht ansehen, ich habe nur Access2003 und benötige eine MDB.

 

Hallo markusxy,
danke für deine Hilfe am Feiertag.
Mir sind die Auswirkungen bei der Aufspaltung nicht so ganz klar.
Eine Abfrage (einschließlich dem Anhang "Gäste_erw") liefert logischer weise auch nur die Datensätze, zu denen es in der Erweiterung einen Datensatz gibt. Somit wird für die "restlichen" Adressen eine eigene Abfrage benötigt. Daraus folgt, dass für die Adressenpflege 2 Formulare benötigt werden. 1x für die Gäste mit einem Datensatz in der Erweiterung und 1x für die ohne Daten im Anhang. Beim Pflegen einer Adresse müsste vorher wissen, über welches Formular der Datensatz zu ändern ist. Werde das in der Datenbank mal durchspielen, um es mir zu verdeutlichen.
Überzeuge mich bitte, dass der Weg der richtige ist.

 

Hallo gpswanderer,
die Pfalz grüßt die Pfalz. Danke für dein Interesse. Zu deinen Fragen:
- Die Kategorien sind vorgesehen, um die Adressen zu katalogisieren (Gelegenheitsgast, wiederkehrender Gast, Stammgast) oder so.
- Kategorien 2x verknüpft: das ist ein Fehler! wird geändert.
- Vorgangstype: Es gibt Angebot, Buchung, Rechnung und Storno. Theoretisch auch „Gutschein“. Da Gutscheine „nur“ finanzielle Auswirkungen haben, wird es vermutlich eine separate Tabelle „Gutscheine“ geben. Werden Gutscheine in den Vorgängen mit erfasst, so muss ich diese Datensätze wieder herausfiltern, zumal es keinen dazugehörigen Datensatz in der Tabelle „Vorgänge_Positionen“ gibt.
- Letzte Nr.: Die Felder mit dem Schlüssel sind Autowert-Felder. Es kann also zu Lücken in der Nummerierung kommen. In den (Kunden)Belegen soll aber die Nummerierung pro Vorgangstype fortlaufend sein. Beim Speichern wird der Zähler um eins erhöht. Ein Warenwirtschaftsprogramm, mit dem ich arbeite, macht das auch so.
- Anschreibetext: Hat den Inhalt wie z.B:„Sehr geehrter Interessent / Gast, wir bedanken und für Ihre Anfrage / Buchung ….“ und so weiter. Es gibt eine Hand voll Varianten. Kann man auch anders machen.
- mdb 2003 gibt es hier: http://www.ferienwohnung-ohler.de/ac...st2017.mdb.zip
-

 

Hallo,

Antwort auf obige Frage steht noch aus.
Die LetzteNr gehört in die Tabelle mit den Vorgängen. Und wie bereits gesagt, die Briefanrede in die Tabelle mit der Anrede.
Auch die Gutscheine sind ein Vorgang und gehören in diese Tabelle, wozu eine extra Tabelle?
Dass es keinen dazugehörigen Datensatz in der Tabelle „Vorgänge_Positionen“ gibt spielt doch keine Rolle ?
Was kann denn ein Gutschein sein, ein Aufenthalt im Ferienhaus, oder was sonst ?

 

Hallo gpswanderer,
sorry, dass ich die Frage nicht beantwortet habe.
VorgandsIDalt ist die Nummer / der Vorgang des Vorgängers.
Beispiel: Es gibt ein Angebot. Nun bucht der Gast. Das Angebot wird kopiert (siehe im Modul Duplizieren) und die Nummer des „alten“ (Ursprung) wird hier festgehalten. Somit entsteht eine „Versionskette“.
Gutscheine sind mit einem Einkaufsgutschein zu vergleichen.

 

Hallo,

Das halte ich für ungeeignet, zumal es mehrere Zustände geben kann.
Angebot > Buchung > Rechnung (oder) > Storno
Was wird dann aus der Kette.
Hier würde ich einfach eine weitere Tabelle erstellen mit einem Fremdschlüssel zum Vorgang und einem Fremdschlüssel zum Vorgangstyp. In dieser Tabelle dann noch ein Datum und Du hast zu einem Vorgang eine lückenlose Historie. Und vor allen Dingen, das Kopieren entfällt ersatzlos. Mit dem Kopieren erzeugst Du jede Menge redundante Daten die es zu vermeiden gilt.

Die DB sehe ich mir nachher mal an, habe sie gerade heruntergeladen.

PS:
Lade doch die Beispiel direkt im Forum hoch. Und bitte keine vollständigen Beiträge zitieren, schon gar nicht in direkter Antwort. Es verlängert nur unnötigerweise die Themen.

 

Hallo,
ich habe mal etwas umgemodelt.
Tabelle mit Besteller gelöscht, ist überflüssig, da der Zahler mit den Adressen verknüpft ist. Ebenso halte ich die Tabelle T1_Gaeste_erw (1:1) wegen der wenigen Felder nicht für erforderlich. Daher auch gelöscht. In den TAbellen habe ich auch noch Felder gelöscht.
Bei den Tabellen und Beziehungen habe ich meinen Vorschlag von oben eingebaut.

DB anbei. Die DB enthält nur die Tabellen mit Beziehungen.

Du hast sowieso zu früh Formulare gemacht.

PS:
Der Tabellenname Adressen ist verwirrend, das sind doch die Personen (Gäste/Zahler).

Nachtrag:
Ich habe es erst jetzt gesehen. Nachschlagefelder in Tabellen direkt sind unbedingt zu vermeiden. Die haben dort nichts zu suchen. Nur in Formularen sind diese sinnvoll. Siehe hierzu:
http://dbwiki.net/wiki/Access_Anf%C3...schlagefeldern
Ich habe diese daher alle in normale Textfelder umgewandelt.
Die Tabelle habe ich mal verkleinert, 40000 DS für die PLZ machen in einer Beispieldab keinen Sinn. Da die DB jetzt kleiner ist, habe ich diese direkt im Forum hochgeladen.

 

Hallo gpswanderer,
vielen Dank für deine Vorschläge und den Link.

Genau genommen ist die Datenbank auch die 3. Version. Mit der Version 2 (inkl. Formulare) wird derzeit gearbeitet. Learning by doing. Daher die Formulare und die "lange" Tabelle mit den Postleitzahlen.
Dein Vorschlag im Umgang mit der "Historie" sieht interessant aus. So ganz verstehe ich es noch nicht. Die anderen Vorschläge wurden übernommen.
Vielen Dank.
Hier der Stand 20.04.:
http://www.ferienwohnung-ohler.de/ac...st2017.mdb.zip