Datenmodellierung und Tabellen- / Datenbankdesign Apartments/Mieter

[mmarschner]

Hallo zusammen,

ich bin gerade dabei, eine etwas ältere Datenbank zu analysieren und mir darüber Gedanken zu machen, wie weit ich die Normalisierung treiben sollte.

Zur Information:

Apartments:

In der DB werden Apartments - 300 Stück auf 5 Häuser verteilt - verwaltet. Diese Apartments werden immer nur für einen bestimmten Zeitraum von ca. 3 Jahren vermietet (an Auszubildende und Studierende). Zu jedem Apartment werden neben der Apartmentnummer weitere Informationen über das Apartment verwaltet. In dieser Tabelle ist auch der aktuelle Mieter als Verknüpfung (1:1) fest hinterlegt und wird bei Änderungen über einen Prozess aktualisiert.

Die Gebäudenummer mit der Adresse, Instandhaltungsarbeiten, Apartmentmiete, weitere Planungen für die Vergabe des Apartments werden in separaten Tabellen (Verknüpfung 1:N) verwaltet.

Mieter:

Es werden neben den Kontaktdaten - die aktuelle Adresse ist durch das Apartment bekannt - weitere Informationen zu der Tätigkeit - hier Ausbildung, mit Beginn und voraussichtlichem Ende - und zu dem Mietvertrag gespeichert.

Prozess:

Hier werden die Mietverträge angelegt und verwaltet. Wenn ein Mieter nicht in den Stammdaten vorhanden ist, wird er aus dieser Erfassungsmaske heraus bei Bedarf angelegt.

Jetzt zu meinen Überlegungen:

Da ggf. die gesamte Datenbank auf einen SQL Server migriert werden soll, mache ich mir - insbesondere bei dem Mieter und bei den Prozessen, siehe anhängende Grafik - Gedanken über eine Normalisierung und wie weit die getrieben werden sollte.

Hier stellt sich für mich die Frage, ob ich die Kontaktdaten und die Informationen über die Ausbildung und den Mietvertrag in separate Tabellen auslagere oder nicht.

Der Hintergrund dazu ist, dass es eine Apartmenthistorie in einer separaten Tabelle gibt, die bis ins Jahr 1975 zurück reicht - BITTE JETZT KEINE DISKUSION ÜBER DATENSCHUTZ UND DATENHALTUNG. Das ist mir und dem Kunden beides Bekannt, aber wird zur Zeit noch tolleriert - Und diese Historie beinhaltet in einer Tabelle alle Daten der Mieter, der Ausbildung, des Mietvertrages, etc.

Was würdet Ihr machen?

Fragende Grüße

Michael

 

[dabadepdu]

Mieter / Kontaktdaten würde ich separieren von den Prozessen.
Mieter bzw Kontaktdaten sind ja u.U. mehrere verschiedene Personen hier, die sich alle auf ein Mietobjekt beziehen. Die Prozesse nach Möglichkeit vereinheitlichen. Z.b. Einzug und Auszug als 2 Datensätze mit Datum und unterschiedlicher Kategorie, ähnlich Kaution erhalten, -zurück usw.
Mängel und Reparaturen könnte man ebenfalls normalisieren.
Eine Tabelle mit bel. Mängeln und Appartement bzw Zimmerzuordnung.
Reparaturen, die beliebige der erfassten Mängel oder eigene, generelle Sanierungsmaßnahmen abbilden.

 

[mmarschner]

Guten Morgen dabadepdu,

erst mal Danke für die Anregungen.

Bei den Mietern verhält es sich so, dass es immer nur eine Person pro Apartment (Größe ca. 20 qm) gibt. Da die Personen nicht immer vorher unter dem Punkt Mieter angelegt werden, sondern die Daten im Rahmen des Prozesses erfasst werden, muss ich mal sehen, wie ich hier eine Trennung unkompliziert hinbekomme, ohne dass die historischen Daten davon betroffen sind.

Ich würde generell auch eine physische Trennung vorziehen, insbesondere da vereinzelt Personen mehrmals ein Apartment im Rahmen ihrer Ausbildung oder ihres Studiums mieten könnten.

Die Mängel, die bereits in einer separaten Tabelle verwaltet werden und keinen Bezug auf die Instandsetzungsarbeiten haben, sind fest mit dem Apartment verknüpft und dienen bisher nur der Information, um einen Report erstellen zu können, welche Arbeiten durchgeführt werden müssen.

Die Instandsetzungsarbeiten - hier handelt es sich um größere Arbeiten - werden nach außen vergeben und nur der Information halber erfasst. Die Mängel hingegen werden regelmäßig intern abgearbeitet, wenn ein Apartment frei geworden ist. Ob man die Instandsetzung und die Mängel verknüpfen sollte, muss ich einmal mit dem Kunden klären.

Michael

 

[ukulele]

Also deine Idee, Mieter und Apartments 1:1 zu verknüpfen, ist vermutlich deinen Workflow und deinem UI geschuldet. In Strukturierten Daten für sich genommen bräuchte es keinen Prozess, der die Zuordnung ändert und Daten in eine Historien-Tabelle überführt. Man würde es mit einer n:m-Beziehung abbilden bei der die Zwischentabelle die Historie abbildet. So lassen sich dann auch unterjährige Mieterwechsel transparent abbilden, ohne das Fremdschlüssel umgeschrieben werden müssten. Das wäre die Normalform.

Wenn du davon abweichst magst du gute Gründe haben, aber die kommen nicht aus der Datenbank-Welt sondern z.B. aus Beschränkungen im UI, wo man die Tabellen eventuell direkt "passend" haben möchte, der User die Historie gar nicht sehen soll oder eingeschränkt ist wenn es darum geht, Anpassungen in mehreren Tabellen gleichzeitig vornehmen zu müssen. Deine Frage ist daher nicht pauschal zu beantworten.

 

[mmarschner]

Hallo ukulele,

danke für die Anmerkungen.

Das Problem mit der Verknüpfung der Apartments und den Mietern rührt daher, dass die Anforderung ursprünglich in Excel erledigt wurde und dort pro Zeile immer alle Informationen verwaltet wurden. Das sollte bisher auch so beibehalten werden. Die Daten wurden dann per Copy und Paste von einer Exceltabelle in eine andere oder auch wieder zurück kopiert. So sind viele redundante Daten entstanden.

Die heute Arbeitsweise in der Accessdatenbank ist so, dass ein Interessent unter den Prozessen erfasst wird, dort die Zuordnung zu einem Apartment vorgenommen wird, sofern eins frei ist. Wenn dann der Mietvertrag unterschrieben wurde und die Wohnungsübergabe erfolgt ist, wird der Interessent zum Mieter und in die entsprechende Tabelle überführt. In der Prozesstabelle wird der Datensatz dann gelöscht.

Wenn der Mieter dann irgendwann auszieht - in der Regel nach ca. 3 Jahren, manchmal aber auch früher oder später, je nachdem wie die Ausbildung verläuft - wird das Apartment und der Mieter mit allen Daten zusätzlich in die Historientabelle übernommen, und in der Mietertabelle als "Ex_Mieter" gekennzeichnet. Also doppelte Daten in Tabelle Mieter und Historie.

Wenn dann ein "Ex_Mieter" noch mal eine weitere Ausbildung macht, würde er ein weiteres Mal angelegt.

Da das ganze obendrein Datenschutzrechtlich problematisch ist, soll das Backend jetzt auf einen SQL Server migriert werden, wobei ich die doppelte Datenhaltung minimieren will. Ebenso sollen zusätzlich Funktionen integriert werden, da z.B. die Übergabe, bzw. die Abnahme eines Apartments heute noch vor Ort auf Papier erfolgt und diese dann nachträglich in der Datenbank erfasst werden.

Daher kam die oben gestellt Frage und mein bisheriger Ansatz sieht erst einmal wie im anhängenden Beziehungsbild für die Prozesse aus. Hier sind noch nicht alle verknüpften Tabellen aufgeführt, da ich weitere Datenbankdiagramme erstellen will, um das überschaubarer zu halten.

Dabei sind die Felder, die mit idx beginnen, immer die Primärschlüssel der Tabellen und die Felder, die mit vidx beginnen, die Verknüpfungen zu anderen Tabellen über deren Primärschlüssel.

Es sollen in der Erfassungsmaske für die Prozesse die Mieterdaten eingegeben werden und nachdem Nachname, Vorname und Geburtsdatum erfasst wurden, eine Prüfung erfolgen, ob es einen passenden oder ähnlichen Eintrag in der Mietertabelle gibt. Wenn hier Ähnlichkeiten vorhanden sind, sollen die entsprechenden Daten zur Auswahl angeboten und ggf. korrigiert werden. Nachdem die Daten für die Ausbildung / das Studium erfasst wurden, wird das Apartment anhand der Termine für die Ausbildung ausgewählt und die entsprechenden Prozesse angestoßen - Zustimmung des Personalrates einholen, Mietvertrag verschicken, etc.

In der Erfassungsmaske für den Mieter können dann dessen Daten ggf. angepasst und über die verknüpften Daten in der Tabelle Mietvertrag und Mietvertrag_Termine weitere Schritte eingeleitet werden.

Ich denke, dass ich so die Datenhaltung - auch unter dem Gesichtspunkt des Datenschutzes und der Datenminimierung - schon einmal zum Teil optimieren kann.

In den Tabellen fehlen noch einige Felder, um z.B. den entstehenden Prozess als "Ex_Prozess" zu kennzeichnen (zum Ausblenden), etc.

Und ebenso könnte man das alles noch weiter verfeinern, indem, wie von dabadepdu bereits erwähnt, die Mängel und die Instandhaltungsarbeiten verknüpft werden, etc. Hier müssen der Kunde und ich noch Entscheidungen und Denkarbeit leisten.

Was mir auf jeden Fall noch Kopfzerbrechen bereitet, sind die Übergabe- und Abnahmeprotokolle, die zukünftig per Tablet vor Ort erfasst werden sollen.

Vielleicht hat ja jemand von Euch noch eine Idee, wie man die Tabellen für die Checklisten sinnvoll aufbaut. Im Augenblick fällt mir dazu noch nicht allzu viel ein, insbesondere da die Daten im Büro dann noch synchronisiert werden müssen. Hier könnte zwar ein Windowstablet zum Einsatz kommen, aber es wird eigentlich ein iPad favorisiert, da diese schon bei dem Kunden im Unternehmen in einer Vielzahl eingesetzt werden. Hier müsste man dann wahrscheinlich auf Excel zurückgreifen und vor und nach der jeweiligen Abnahme oder Übergabe die Daten erst einmal nach Excel exportieren, auf das Tablet übertragen und hinterher alles umgekehrt. Dieser Gedanke gefällt mir noch nicht wirklich. Und ob RDP zum Einsatz kommen kann, muss mit der EDV Abteilung des Kunden geklärt werden, wobei ich allerdings ziemlich schwarz sehen, dass die so etwas bereit stellen.

 

[ukulele]

Also ich würde Mieter und Mietobjekt mit einer Tabelle Mietverhältnis verknüpfen, in der der Zeitraum gepflegt wird. Eine Zuordnung eines Interessenten findet dann über ein Mietverhältnis mit Startdatum in der Zukunft statt das als Interesse gekennzeichnet wird. Ggf. gibt es auch mehrere gleichzeitige Interessenten, das müsste bei einem Constraint, der Doppelbuchungen verhindern kann, berücksichtigt werden.

Ein Mieter könnte theoretisch auch ein Unternehmen sein, dann wäre Mieter und Person nicht zwingend die selbe Tabelle.

Datenbanktechnisch lässt sich das alles durchnormalisieren, auch Übergabeprotokolle. Deine Fragen und Probleme sind streng genommen alle FrontEnd und UI bezogen, davon hängt am Ende ab ob man die Datenbank komplett normalisieren kann oder ob man sich am FrontEnd orientieren muss. Schon mal nach einer fertigen Software oder einem individualisierbaren CRM oder ERP geschaut? Grade wenn Mobile Devices involviert sind ist Eigenbau nicht trivial. Leider kenne ich mich da auch zu wenig aus.

 

[mmarschner]

Guten Morgen,

erst einmal Danke für die vielen Anregungen. Ich werde mir das alles noch einmal in Ruhe durch den Kopf gehen lassen und dann mal sehen, wie weit ich komme.

Die Prozesse sind leider an die internen Arbeitsabläufe gebunden und es wird nicht einfach werden, hier die Struktur zu durchbrechen. Aber die Überlegungen von Euch haben mir einige Anregungen gegeben, die - wenn es zu einer Beauftragung kommt - sicherlich mit einfließen werden.

 

[Martinha]

Hallo,

ich habe immer ein Problem damit, wenn die gleichen Personen in unterschiedlichen Rollen redundant in unterschiedlichen Tabellen gespeichert werden. Man kann das z.B. mit einem Rollenkonzept lösen.
Eine Person ist nur einmal da in der Personentabelle. Dann gibt es eine Tabelle Rollen, mit einer RolleID. Dort stehen die Rollen, die eine Person in dem System einnehmen kann. Dann gibt es eine Tabelle Partner mit Personid, Rolleid und Partnerid. Die Partnerid wird im System verwendet.
Dieser Ansatz verhindert das redundante Speichern von Personendaten.

Martin

 

[mmarschner]

Guten Morgen Martin,

Danke für Deine Anmerkung.

Ein Rollenkonzept in Deinem Sinne benötige ich wahrscheinlich nicht, da es sich bei den Personen immer nur um Auszubildende oder Mitarbeiter - eher selten der Fall - handelt, die ein Apartment mieten. Nachdem ein Mieter ausgezogen ist, wird dieser über ein separates Feld als Ex-Mieter gekennzeichnet.

In den ursprünglichen Exeltabellen waren die Personen mehrfach vorhanden, in der aktuellen Datenbank leider in der Historientabelle auch noch. Um das zu ändern, sowie weitere Normalisierungen durchzuführen, habe ich ja dieses Thema aufgemacht, was ja schon sehr umfänglich mit Ratschlägen versorgt wurde.

Jetzt muss erst einmal mit dem Kunden geklärt werden, ob und wie die Datenbank migriert werden soll.

Michael

 

[Martinha]

Hallo Michael,

wenn eine Person zu einem Zeitpunkt immer genau eine Rolle inne hat, das brauchst du das nicht mit der Partnertabelle. Sollte sich das aber mal ändern, wirst du am so einen Konzept nicht vorbei kommen.
Neben dem guten Forum hier, kann Chatgpt auch sehr gut helfen. Ki hat mir jetzt meine gesamten VBA Pozeduren und Stored Proodures auf Vordermann gebracht.

MfG
Michael