Office: (Office 2010) Wohnungszustandbericht

Hallo Gemeinde,
nachdem ich nun meine ersten unangenehmen Erfahrungen mit Access gemacht habe ist mein Wissensdurst wieder da.

Aus diesem Grunde fummele ich also nun weiter mit den vielen Möglichkeiten die Access so bietet.

Nun dachte ich mir, wenn man z.B. eine Bestelldatenbank erstellen kann, dann müsste es doch eigentlich auch möglich sein eine Datenbank zu erstellen mittels der man einen Zustandsbericht für eine Wohnung erstellen kann.
In diesem müsste man die vom derzeitigen Bewohner notwendigen Arbeiten dokumentieren und die Arbeiten die vom EIgentümer des Objektes verantwortlich übernommen werden müssten.

Hauptaugenmerk habe ich aber zunächts mit den Forderungen an den jetzigen Mieter.

Hierzu habe ich nun mehrere Tabellen erstellt die folgendes abdecken sollen.

Tabelle Wohnungsdaten ( Informationen wie Adresse usw. )
Tabelle Räume ( mögliche Räume in einer Wohnung oder einem Gewerbe )
Tabelle Zähler ( welche Zähler sind vorhanden und wie lauten die Stände )
Tabelle Schlüssel ( welche Schlüssel sind vorhanden und in welcher Menge )
Tabelle Produktgruppen ( welche Produkte gibt es in einer Wohnung - Wände, Decken, Fußboden usw. )
Tabelle Produkte ( jede Produktgruppe kann unterschiedliche Produkte haben wie Laminat, Teppich, PVC z.B, für Boden )

NUn habe ich ein Formular erstellt mittels dem ich zunächts die WOhung suchen kann die z.B. abgenommen werden soll.

Durch doppelklick auf diese komme ich in ein Einzelformular in dem ich nun die gewünschten daten sammeln möchte und in einer Ergebnistabelle speichern möchte.

http://www.bilderparken.de/view.php?...eziehungen.jpg

Kann mir jemand helfen und mir sagen wie ich nun weiter vorgehen kann ?

In meinem EInzelformular habe ich bi jetzt einige Daten zur Wohnung ( Adresse usw. und den Namen des Mieters eingefügt.
Nun möchte ich aber Schlüssel, Zähler, Mängel aufnehmen können )

vielen Dank für jegliche Hilfestellung

Ich möchte hier keine Lösung sondern möchte mich unbedingt in Access einarbeiten und am liebsten mache ich das mit einem kompletten Projekt da hier so ziemlich alles drinnen ist was man in anderen Projketen dann benötigt.
Learning by doing sozusagen

:)

 

Hi,

zunächst mal sollte das Datenmodell wasserdicht sein. Das ist es bisher eher nicht.

Ein paar Gedanken (da du ja keine fertige Lösung willst):

• Zähler, Schlüssel, Räume und Produkte lgehören zu Wohnungen. Bisher tun die so, als seien sie autonom. Das Datenmodell sollte "geschlossen" sein, also alle Tabellen einflechten, und keine Inseln enthalten.
• Eine Wohnung kann im Zeitverlauf mehrere Mietverträge haben. Die sollten in einer separaten Tabelle stehen und nicht als Vertragsnummer und -zeitraum in der Wohnungstabelle.
• Die tblSchlüssel sollte jeden einzelnen Schlüssel aufnehmen. Damit ist das Feld Anzahl hinfällig.
• Zähler ziehen nur selten um. Da würde ich den Standort zum Zähler packen und nicht zum Zählerstand.
• Wenn du schon mit Rollen der Vertragspartner rechnest (vermutlich sowas wie "Eigentümer", "Mieter", "Hausmeister", "Verwaltung" etc), dann solltest du auch damit rechnen, dass eine Partei mehrere Rollen hat. Damit ist dann die Partnerrolle als neue Tabelle nötig, die festhält, wer als was auftritt.
• Die Wohnungsdaten in der Schlüsseltabelle sind hofentlich nur die Wohnungsnummer. Und selbst dann ist mir unklar, wie du da z.B. Keller- oder Briefkastenschlüssel unterbringst.
• Was ist mit Parkplätzen? Und könnten die evtl. separat vermietet werden?

 

deine Gedankengänge habe ich in abgewandleter Fomr auch schon gehabt.
Deshalb sind sie für mich weitestgehend nachvollziehbar.

Es gint Haustür-, Wohnungstür-, Kellertür- und weitere Schlüsselarten.
Ein Wohnungstürschlüssel hat eine bestimmte Schlüsselnummer und von diesem hat der Mieter dann z.B. 3 Stück.

Man muss ja irgendwie nachprüfen können wieviele er einmal bekommen hat.

hmm, so habe ich es doch ?!
Es gibt Hauptmieter; Erben, Nachlassverwalter und einige Andere.
Somit könnte doch ein Hauptmieter auch noch als Erbe hinterlegt werden wobei sowas nicht vorkommen dürfte aber so eng bin ich an diesem Thema nicht dran.

Das Feld Wohnungsdaten wollte ich mit der Tabelle Wohnungsdaten in Beziehung bringen.
Keller- oder Briefkastenschlüssel stehen dann in der Schlüsselart

Stimmt, ich müsste eigentlich noch eine Tabelle einbinden die die einzelnen Möglichkeiten hergibt.
Also z.B. Wohnung, Gewerbe, Parkplatz, Garage usw.

Was ich einfach nicht hinbekomme sind die ganzen Beziehungen.
Da hänge ich ständig an irgendeiner Stelle fest

 

Mal eine Frage zum Verständnis :

Müsste ich nicht nur die Beziehungen nach folgender Logik aufbauen ?

Eine Wohnung hat ein oder mehrere Schlüsselgruppen
Eine Wohnung hat ein oder mehrere Räume

Demnach müsste ich doch "nur" in der Tabelle Schlüsselgruppe und Räume ein Feld einfügen ( z.B. Wohnung ) und diese in Beziehung mit der WOhnung ID setzen ?

Daraus ergäbe sich folgende Endlogik

Eine Wohnung kann mehrere Partner mit unterschiedlichen Rollen haben
Eine Wohnung kann mehrere Räume haben
Eine Wohung kann mehrere Zählerarten haben
Eine Wohung kann mehrere Schlüsselgruppen haben

Eine Zählerart kann mehrere Zähler haben
Eine Schlüsselgruppe kann mehrere Schlüssel haben

Ein Raum kann mehrere Mängel haben usw.

Irgendwie komme ich mit diesen verdammten Beziehungen nicht so ganz klar.

Am Ende müsste es ja eine Ergebnistabelle geben in der ich dann alle Punkte z.B. in einen Bericht packen könnte ?!

 

könnte sich bitte jemadn mal angucken wie man die Beziehungen am besten setzen könnte ?

 

Mir wird - nach allem bislang Geschriebenen - Deine Ausgangslage noch nicht ganz klar: geht es um die Verwaltung der Wohnungs-Objekte oder um die Betreuung der Verträge? Davon abhängig würde ich das eine oder das andere in den Mittelpunkt der Betrachtung stellen.

Wie war's, wenn Du einfach mal anfingst, die Datenstruktur mit den Tabellen und den Beziehungen auf Grundlage der Anmerkungen und Deiner neuen Erkenntnisse ändertest.
Und dann einen neuen ScreenShot vom Beziehungsfenster machst, ihn hier hochlädst - dann wissen wir zumindest mal, wie weit Du inzwischen bist.

Es gibt prinzipiell nicht nur 1:n Beziehungen sondern auch m:n. Diese sind in einer relationalen Datenbank über eine zusätzliche Tabelle zu realisieren.

Zum Beispiel zwischen Produktarten und Räumen. In einem Raum sind mehrere Produktarten und jede Produktart befindet sich in mehreren Räumen. An der Schnittstelle (in der m:n Tabelle) befindet sich jeweils das konkrete Produkt. Zu jedem konkreten Produkt gibt es dann noch eine Historie (angeschafft, als defekt erkannt, repariert, abgeschafft). Insofern hat nicht der Raum den Mangel sondern das Produkt in dem Raum.

Am Ende - kurz vor dem Bericht - steht sicherlich weniger eine Tabelle als vielmehr eine Abfrage, die die gewünschten Daten zusammenfasst und für den Bericht aufbereitet ...

 

Glaub ich nicht. Eine Wohnung hat allenfalls Schlüssel, und zwar mehrere. Jeder davon gehört zu genau einer Schlüsselart. Die Wohnung hat also nur sog. transitive ("durchgeleitete") Abhängigkeiten zur Schlüsselart, aber keine direkten. Also auch keine Beziehung Wohnung-Schlüsselart.

Ja.

Nein, siehe oben. Und selbst wenn, wäre das dann ein mehrwertiges Feld, was auf eine "umgekehrte" Beziehung deutet.

Ja.

Ja.

Hier ist es wie mit den Schlüsselarten: die Wohnung hat Zähler, die wiederum einer Art angehören.

Nein, siehe oben.

Ja.

Ja.

Ja.

Du kommst der Sache näher. Setz mal die Tipps um, und zeig dann mal das Modell her.

 

ich kann mich drehen und wenden wie ich will, komme aber nicht weiter.





Vom Prinzip her möchte ich nur über ein Formular

• Schlüssel und Zählermengen und -nummern eingeben
• einen Raum auswählen
• diverse Mängel im Raum aufnehmen

Egal was ich anstelle aber irgendetwas stimmt scheinbar immer nicht *frown.gif*

 

Du hast nicht vernommen, was Martin schrieb: die Daten gehören alle in einen Topf. Räume sind Entitäten, die zu Wohnungen gehören. In tblRäume gehört ein Fremdschlüssel zur Wohnungs-ID. Und so weiter ...
Ich schrieb etwas über m:n Beziehungen und versuchte, das am Beispiel von Räumen und Produkten zu verdeutlichen. Auch davon ist in Deinem neuen Screenshot nichts angekommen.

Auf zum nächsten Versuch. Es kann nur besser werden.
Von #1 bis #8 sind keine nennenswerten Fortschritte zu verzeichnen.
Leider.
Vorläufig ungenügend, wenn Du mich fragst.

Nimm Dir einen Bleistift und ein großes Blatt Papier und male das Datenmodell mal auf.

 

wollte ich aber ich stolpere über

Dies würde ja wohl zutreffen wenn ich eben einen Fremdschlüssel in Räume einfüge und einen in Schlüssel

Dann würde allein vom Primärschlüssel der Wohnungsdaten jeweils eine Beziehung zur Tabelle Räume, Schlüssel und Partner bestehen und hätte ein mehrwertiges Feld.

Kann ich denn denn von einem Feld xviele Tabellenbeziehungen herstellen die dann den Fremdschlüssel enthalten ?

Wenn ja, dann müsste doch folgende Beziehungskiste richtig angedacht sein oder ?

 

Hallo.

Natürlich kann die 1: Seite mehre Beziehungen zu verschiedenen Tabellen haben, die dann jede einzeln die :n Seite darstellt.

- derzeit kann ein Partner nur eine Rolle haben. War das nicht anders angedacht? Ein Partner kann mehrere Rollen haben?

- Thema Schlüssel: Können die Zimmer in Wohnungen nicht auch Schlüssel haben und müssten diese dann nicht mit den Räumen in Beziehung stehen? Gleiches gilt für den Keller-Raum), wo häuifig die Zähler untergebracht sind.

- Eine Wohnung wird im Laufe Ihres daseins mehre Zählerstände haben. Eine Tabelle mit Zählerständen wäre dann noch zu erstellen. Hier sollte dann das Ablesedatum mit aufgenommen werden. In diesen Zusammenhang...

- Würde ich zwschen der Tabelle Wohnungsdaten und Partner eine Mietvertragstabelle hängen.

Ich hatte Schwierigkeiten Dein Datenmodell zu lesen. Liegt in der Hauptsache daran, dass Du keine gleichbleibenden Feldnamenverwendest. Beispiel: ID aus Tabelle Wohnung zum Fremdschlüssel Zählerstandort. Deshalb grundsätzliches als Tip:

• Vermeide in Tabellennamen, Abfragenamen, Feldnamen (eigentlich alle Access Objekte) Leerzeichen, Umlaute und Sonderzeichen wie z.B.( oder )
• Benenne das Fremdschlüsselfeld(FK) genauso wie das Feld des Primärschlüsselfeldes und setze vielleicht noch einen Präfix davor. Beispiel: WohnungID (PK) FK_WohnungID (FK)
• Tabellennamen sollte möglichst eindeutig (aber kurz) den Inhalt der Tabelle beschreiben. Ich würde diesen auch ins Plural setzten. Beispiel: tbl_Wohnungen oder tbl_Vertragspartner. Hast Du soweit ich das sehe ja auch gemacht. Ich leite aus den Tabellennamen auch immer den Namen des PK-Feldes ab und setze ihn in Einzahl. tbl_Wohnungen = WohnungID

Vorgenanntes ist kein Muss, macht aber Sinn und erst recht dann, wenn das Datenmodell komplexer wird. Hans-Christian hat schon Recht, wenn er sagt

Das wird nicht bedeuten, dass wir Dir nicht helfen wollen. Sollte aber das "Gefühl" aufkommen, dass Du von den Helferlein vermitteltes Wissen nicht umsetzt, dann kann es stiller werden. Manchmal liegt es aber auch daran, das der Helfende aufgrund seines Wissen schon eine andere Sprache spricht als der Fragende und umgekehrt. Wenn Du was nicht verstehst, dann Frag nach. Häufig hilft das "googeln", insbeondere dann wenn man das eine oder andere Wort nicht kennt/versteht.

Toi, toi, toi.*Smilie

 

Zähler würde ich nicht mit Räume sondern mit Wohnung verbinden.
Und - wie Sascha auch schreibt - die Ablesedaten in eine weitere Tabelle.

Bezüglich Schlüssel bin ich unentschlossen *wink.gif*
Briefkasten oder Hauseingang sind sicher zur Wohnung und nicht zu einem speziellen Raum ...

Produkte sind noch nicht mit dem Ganzen verbunden.
Wie ich schrieb, würde ich einen Fremdschlüssel auf den Raum in tbl_produkte legen. Und dann eine weitere Tabelle mit der Produkt-Raum-Historie wo neben An- und Abschaffung und auch die Defekte bzw. ihre Reparaturen festgehalten werden.

 

feine Sache, vielen Dank

Nein, ein Partner kann nur eine Rolle haben, das passt schon so.
Eine Rolle "Erbe" kann höchstens zum neuen Hauptmieter werden aber dann wäre dies in einem neuen Datensatz ( später dazu mehr )

Zimmerschlüssel sind nicht von Interesse, Keller ist bei mir schon eine Schlüsselgruppe

Der Datensatz beinhaltet eine laufende Nummer die in Zusammenhang mit der Wohnungsnummer steht. Es kann zwar in einer Wohnung viele Zählerstände geben, nicht aber in einer laufenden Nummer da die laufende Nummer bei einem neuen Mieter um eins erhöht wird.

Das ist mir auch bereits negativ aufgestossen und werde es entsprechend überarbeiten.
vielen Dank

vielen Dank, ich denke, was die Beziehungen angeht, bin ich schon ein ganzes Stück schlauer *Smilie

 

jep, Zähler gehören nach der verwendeten Logik zum Raum weil ich eine Angabe benötige in welchem Raum der Zähler ist.
Aus diesem Grunde habe ich mich für diesen Weg entschieden.
Eigentlich müsste man aber tatsächlich den Zähler zur Wohnung packen und zusätzlich die Angabe des Standortes ( Raum ermöglichen )
Werde ich mal testen

Schlüssel sind, denke ich, so OK da sie Wohnungsbezogen sind.
Es interessieren nur die Wohnungsbezogenen Schlüssel, die von einem Raum eher nicht.

Produkte habe ich noch nicht in Beziehung gesetzt da ich erst einmal wissen wollte ob meine Gangart generell so funktioniert.
Ich werde die vielen Tips erst einmal umsetzen und dann das Gesamtgebilde hier darstellen.


vielen Dank für die vielen Tips die mich ein gutes Stück weiter bringen in meinem Verständnis.

 

so, di eletzten Tage habe ich ab und an mal etwas gefummelt und bin zu dem Schluß gekommen, mich nach und nach dem Ziel zu nähern und zeitgleich die Formulare in Angriff zu nehmen.
Ich musste feststellen, dass die Beziehungen auch für die Formulare und das Platzieren der Felder wichtig ist.

Bisher bin ich an folgendem Punkt angelangt wobei die Zähler, Schlüssel und Partnerdaten mittels eines Formulars eingegeben, bzw. ausgelesen werden können.

Wie ich nun die Problematik mit den Mängeln angehe ist mir derzeit noch nicht ganz klar.

Um aber mal eine Rückmeldung zu geben hier mein jetziger Stand der Dinge in den Beziehungen