Ein Datenmodell einer Immobilienagentur

Abgesehen vom Standort, was braucht es, um ein erfolgreiches Immobilienunternehmen zu führen? Wir untersuchen ein Datenmodell, um Immobilienagenturen dabei zu helfen, organisiert zu bleiben.

Der Kauf, Verkauf und die Vermietung von Wohnungen oder Häusern ist heute ein echtes Big Business. Die meisten Menschen zahlen gerne eine Gebühr und lassen eine professionelle Immobilienagentur die Arbeit für sie erledigen. Andererseits könnte das Unternehmen in eigenem Namen handeln und Immobilien kaufen, um sie weiterzuverkaufen oder zu vermieten. Ein Immobilienunternehmen kann eine Immobilie auch leasen, dann vermieten oder untervermieten und aus der Differenz einen Gewinn erzielen.

Offensichtlich ist es ein wichtiger Teil der Führung eines Immobiliengeschäfts, den Überblick über Immobilien zu behalten. Gleichzeitig sind Daten ebenso wichtig. (z. B. Wann wird eine Mietwohnung verfügbar? Wann kommt eine Immobilie auf den Markt?) In diesem Artikel werfen wir einen Blick auf ein Datenmodell, das Immobilienunternehmen helfen kann, organisiert zu bleiben /P>

Häufig gestellte Fragen zu Immobilien

Bevor wir mit der Beschreibung des Modells und der erwarteten Daten beginnen, beantworten wir zunächst einige Fragen, die sich speziell auf ein Immobilienunternehmen beziehen. Immobilien hat viele Begriffe und eine vollständige Erklärung ihres Fachjargons und ihrer Prinzipien würde den Rahmen dieses Artikels bei weitem sprengen, daher werden wir hier nur die häufigsten und grundlegendsten Fragen beantworten.

Was kann als Nachlass oder Eigentum betrachtet werden?

Wenn wir an Immobilien denken, ist das erste Bild, das wir bekommen, oft ein Haus oder eine andere Wohnung. Immobilien sind viel mehr als das. Auch Gebäude, Büros, Grundstücke, Bodenschätze und Korps fallen in diese Kategorie. Für die Zwecke dieses Artikels behandle ich alles, was „unbeweglich“ ist, als Immobilien. Allerdings konzentrieren wir uns hauptsächlich auf Mehrfamilienhäuser und Häuser.
Wo befindet sich das Anwesen oder Eigentum?

Für Häuser, Gebäude und Wohnungen ist dies sehr einfach. Wir kennen die genaue Adresse, an der sich die Immobilie befindet. Land hat keine Adresse, aber seine Position wird durch ein Grundbuch definiert.
Welche Daten müssen wir speichern?

In unserem Modell müssen wir alle Nachlässe (d. h. Immobilien) und Kunden speichern, mit denen wir zusammenarbeiten. Wir benötigen diese Informationen, um Berichte zu erstellen und unser Geschäft zu verbessern.

Wir können davon ausgehen, dass wir häufig mit Kunden kommunizieren werden, daher müssen wir alle ihre Kontaktdaten speichern. Wir möchten auch wissen, welcher Mitarbeiter den Kunden kontaktiert hat und welches Interesse der Kunde während des Gesprächs bekundet hat.

Bei Objekten benötigen wir deren Daten und aktuellen Status auf Knopfdruck, um Anfragen potenzieller Kunden schnell beantworten zu können.

Wir speichern auch unseren Kontaktverlauf und alle Verträge im Zusammenhang mit Kunden oder Immobilien.
Wie wichtig sind Daten?

Termine sind immer entscheidend, aber ich möchte betonen, dass sie bei Immobilien besonders wichtig sind. Wir müssen wissen, wie lange eines unserer Mietobjekte belegt ist, damit wir es wieder vermieten können, sobald es verfügbar ist. Es darf keine Überschneidungen geben, wenn zwei Kunden dieselbe Immobilie mieten. Wenn ein potenzieller Kunde den Wunsch äußert, zu einem bestimmten zukünftigen Datum zu mieten, sollten wir diese Informationen speichern und eine Erinnerung erhalten, wenn dieses Datum näher rückt.
Wie soll unsere Bewerbung aussehen?

Hierfür ist eine Webanwendung die beste Lösung. Ein Großteil der Immobilienarbeit findet im Büro statt, aber Handelsvertreter sollten in der Lage sein, neue Daten einzufügen, wo immer sie sich befinden. Die wichtigste Funktion in unserer App ist eine schnelle Suche, die Kunden, Immobilien und Immobilienstatus finden kann.

Das Datenmodell

Unser Immobiliendatenmodell besteht aus drei Hauptthemenbereichen:

Estates and locations
Clients and contacts
Contracts and transactions

Es gibt eine Tabelle, employee , das außerhalb eines Fachgebiets liegt.

Bitte beachten Sie, dass der employee und der estate Tabellen in Clients and contacts Sachgebiet und client Tabelle in den Contracts and transactions Themenbereich sind nur Kopien, die zur Vereinfachung des Modells verwendet werden.

Schauen wir uns den employee Tabelle zuerst, weiter mit Estates and locations , wechseln Sie zu Clients and contacts , und schließen Sie dann mit Contracts and transactions ab .

Die Mitarbeitertabelle

Wir beginnen mit dem employee Tisch. Ganz einfach:Es speichert nur den first_name und last_name jedes Mitarbeiters. Wir könnten weitere Details wie die Steueridentifikationsnummer des Mitarbeiters, sein Geburtsdatum, seine Adresse, seine berufliche Funktion usw. hinzufügen. In diesem Modell konzentrieren wir uns jedoch nicht auf die Mitarbeiter, sodass wir nur eine Möglichkeit benötigen, Mitarbeiter zuzuordnen Aktionen (wie die Zuweisung zu einer Aufgabe oder einem Vertrag). In dieser Tabelle können wir auch erfassen, welcher Mitarbeiter an jedem Kundenkontakt teilgenommen hat.

Abschnitt 1:Ländereien und Standorte

Die Estates and locations Der Themenbereich enthält sechs Tabellen, die alle Grundstücke (Immobilien), mit denen wir arbeiten, ihre Standorte und ihren aktuellen Status beschreiben.

Die zentrale Tabelle in diesem Themenbereich ist der estate Tisch. Es enthält eine Liste aller Weingüter, mit denen wir zusammenarbeiten, waren oder werden. Dazu gehören Immobilien, für die wir zwischen zwei Kunden vermitteln, die wir besitzen, die wir an Kunden verkauft oder vermietet haben und die wir von Kunden geleast oder gekauft haben. Es führt auch Aufzeichnungen über Nachlässe, mit denen wir planen (oder geplant hatten), Geschäfte zu machen.

Da wir uns in diesem Artikel hauptsächlich auf Wohnungen und Häuser konzentrieren, beziehen sich die Attribute in dieser Tabelle hauptsächlich auf diese. Wenn wir andere Arten von Immobilien beschreiben möchten, könnten wir zusätzliche nullbare beschreibende Attribute hinzufügen. Wir könnten diese Werte auch einfach in die estate_description eingeben Attribut. Die Attribute im estate Tabelle sind:

estate_name – Der Name des Anwesens. Dies könnte unser interner Name für ein Grundstück („Stoker House“) oder ein bekannter öffentlicher Name („Bran Castle“) sein.
city_id – Die ID der Stadt, in der sich das Anwesen befindet.
estate_type_id – Referenziert den estate_type Wörterbuch.
floor_space und balconies_space – Die Größe (in Quadratmetern) von Wohnungsetagen und Balkonen.
number_of_balconies , number_of_bedrooms , number_of_garages und number_of_parking_spaces – Ganzzahlige Werte für jede Kategorie. Selbsterklärend.
pets_allowed – Ein boolescher Wert, der angibt, ob Haustiere erlaubt sind. Dies wird hauptsächlich für Mietobjekte verwendet.
estate_description – Eine detaillierte Beschreibung eines Nachlasses. Hier speichern wir eventuelle Zusatzinformationen, z.B. Immobiliengeschichte.
estate_status_id – Ob derzeit ein Nachlass verfügbar ist oder nicht. Wir werden dieses Feld in unserer Suchfunktion verwenden.

Wir haben bereits zwei Wörterbücher erwähnt, die estate Tabelle bezieht sich auf estate_type und estate_status . Diese beiden Wörterbücher enthalten nur eine ID und ein EINDEUTIGES Namensattribut.

Im estate_type Wörterbuch speichern wir Werte wie „Wohnung“, „Haus“, „Feld“ usw. Der estate_status Die Tabelle enthält Werte, die angeben, ob die Immobilie derzeit verfügbar ist oder nicht, z. B. „Immobilie geleast“, „Immobilie gekauft“, „Immobilie verkauft“, „Immobilie vermietet“.

Wir werden den Standort jedes Anwesens definieren, nicht nur durch Beschreibung (das estate . estate_description Attribut), sondern auch nach Land und Stadt. Zu diesem Zweck verwenden wir zwei Wörterbuchtabellen:country und city . Jedes Land wird eindeutig durch einen country_name definiert , das das einzige Attribut (außer ID) ist, das in der Tabelle gespeichert wird. Andererseits hat jede Stadt einen Namen und ein Land. Einige Städte könnten den gleichen Namen haben, aber wir gehen davon aus, dass der Name jeder Stadt einzigartig für ihr Land ist – nur ein Wien, Österreich oder Genf, Schweiz. Wenn wir jedoch vor Duplikaten schützen wollen, könnten wir ein Regionsattribut hinzufügen. Vorerst lassen wir aber alles so wie es ist. Der city_name – country_id Paar ist der EINZIGARTIGE Schlüssel der city Tabelle.

Die letzte Tabelle in diesem Themenbereich ist der in_charge Tisch. Wir können davon ausgehen, dass jedem Anwesen mindestens ein Mitarbeiter zugewiesen wird, der sich um die damit verbundenen Angelegenheiten kümmert. Dieser Mitarbeiter ist für Dinge wie die Kommunikation mit Kunden, das Zeigen des Nachlasses an potenzielle Kunden und andere administrative und rechtliche Aufgaben verantwortlich. Im in_charge Tabelle haben wir:

estate_id und employee_id – Fremdschlüssel, die auf den zugehörigen Nachlass bzw. Mandanten verweisen.
date_from und date_to – Das Intervall, in dem der Mitarbeiter diesem Anwesen zugewiesen wurde. Beachten Sie, dass „date_to“ NULL sein kann, da sich ein Mitarbeiter auf unbestimmte Zeit um einen Nachlass kümmern könnte. Wenn wir einen Mitarbeiter einer Niederlassung zuweisen, sollten wir sicherstellen, dass er nicht bereits einer anderen Niederlassung zugewiesen ist, indem wir nach sich überschneidenden Datumsintervallen suchen. Andererseits können wir viele Mitarbeiter gleichzeitig demselben Betrieb zuweisen. Dies wäre wünschenswert, wenn Mitarbeiter unterschiedliche Rollen haben, z. Ein Mitarbeiter kümmert sich um die Kundenkommunikation, ein anderer Mitarbeiter zeigt den Nachlass an, ein anderer kümmert sich um Verkaufs- und Rechtsverträge usw.

Abschnitt 2:Kunden und Kontakte

Der Client and contacts Der Themenbereich besteht aus nur zwei Tabellen, dem client Tabelle und den contact Tisch. Die beiden anderen Tabellen, die in diesem Bereich angezeigt werden, employee:Clients and contacts und estate:Clients and contacts sind nur Kopien.

Der client Die Tabelle enthält Aufzeichnungen aller Kunden, mit denen wir jemals zusammengearbeitet haben, einschließlich aktueller und potenzieller Kunden. Wer ist ein potenzieller Kunde? Es könnte jemand sein, der gesagt hat, dass er in Zukunft eine Immobilie von uns verkaufen, kaufen oder mieten möchte. Wir müssen die Kontaktdaten und Eigenschaften dieser Kunden für die zukünftige Verwendung speichern. Die Attribute im client Tabelle sind:

client_name – Bei einer Einzelperson enthält dieses Feld ihren Vor- und Nachnamen. Wenn der Kunde eine juristische Person ist, hält er den Firmen- oder Körperschaftsnamen.
client_address – Eine Textbeschreibung des Standorts des Kunden.
contact_person – Vor- und Nachname (und wahrscheinlich eine Berufsbezeichnung, wenn der Kunde ein Unternehmen ist) unserer Kontaktperson.
phone , mobile und mail – Die Kontaktdaten des Kunden.
client_details – Alle anderen Details zu diesem Kunden. Diese werden in einem unstrukturierten Textformat gespeichert.

Die letzten fünf Attribute in dieser Tabelle sind nullable, da sie nicht entscheidend sind. Wir müssen wahrscheinlich Informationen für mindestens eine Kontaktperson speichern, aber wir wissen möglicherweise nicht im Voraus, wer unser Kontakt sein wird.

Die zweite und letzte Tabelle in diesem Themenbereich ist der contact Tisch. Hier speichern wir Daten über jede Interaktion, die wir mit Kunden hatten. Wir verwenden diese Informationen, um unser zukünftiges Geschäft zu optimieren – wenn beispielsweise ein Kunde darum bittet, ein bestimmtes Anwesen von uns zu mieten, sobald es verfügbar ist, sollten wir diese Anfrage speichern und ihn informieren, wenn das Anwesen fertig ist. Die Attribute in der Tabelle sind:

client_id – Die ID des beteiligten Clients.
employee_id – Die ID des an dieser Kontaktinstanz beteiligten Mitarbeiters. Dies kann NULL sein, da ein Kunde keinen einzelnen Mitarbeiter kontaktieren darf – z. Vielleicht hat der Kunde eine E-Mail an das Firmenkonto gesendet. Dennoch können wir in den meisten Fällen davon ausgehen, dass wir wissen, welcher Mitarbeiter eine Interaktion bearbeitet hat.
estate_id – Die ID des zugehörigen Nachlasses. Dies ist nützlich, wenn der Kunde nach einer bestimmten Immobilie fragt oder wenn der Kunde etwas verkaufen oder vermieten möchte, das wir bereits in unserem System haben.
contact_time – Der Zeitpunkt, zu dem der Kontakt stattfand.
contact_details – Alle unstrukturierten Notizen, die wir über diesen Kontakt speichern möchten. Wir könnten etwas schreiben wie „Der Kunde hat den Wunsch geäußert, ein Haus in Nachbarschaft zu kaufen.“

Abschnitt 3:Verträge und Transaktionen

Der letzte Themenbereich in unserem Modell ist Contracts and transactions . Wir werden es verwenden, um Nachlässe mit Kunden in Beziehung zu setzen.

Die zentrale Tabelle dieses Abschnitts ist der contract Tisch. Dort speichern wir alle Vertragsdetails und verknüpfen Verträge mit Kunden und Mitarbeitern. Die Attribute in dieser Tabelle sind:

client_id – Die ID des Kunden, der den entsprechenden Vertrag unterzeichnet hat.
employee_id – Die ID des Mitarbeiters, der den Vertrag im Namen unseres Unternehmens unterzeichnet hat.
contract_type_id – Referenziert den contract_type Wörterbuch und gibt an, ob sich der Vertrag auf den Kauf, Verkauf, das Leasing oder die Miete von Immobilien bezieht.
contract_details – Eine detaillierte Beschreibung des Kontakts, gespeichert im Textformat.
payment_frequency_id – Referenziert die payment_frequency Wörterbuch und definiert die Intervalle, in denen Rechnungen versendet werden sollen.
number_of_invoices – Die Anzahl der Rechnungen, die generiert werden sollen. Wenn das Unternehmen nur einmal zahlt, wird in diesem Attribut der Wert „1“ und der gesamte payment_amount gespeichert entspricht dem invoice_amount .
payment_amount – Der gezahlte Gesamtbetrag.
fee_percentage – Der Prozentsatz, den wir dem Kunden in Rechnung stellen. Zum Beispiel könnten wir 5 % des Verkaufspreises eines Hauses als Gebühr berechnen. Der Wert in dieser Spalte sollte mit contract_type übereinstimmen .fee_percentage Attribut für diesen Vertrag. Der fee_percentage Attribut wird verwendet, um den fee_amount zu berechnen wenn wir einen Wert in den payment_amount eingeben Attribut.
fee_amount – Die Gesamtgebühr, die wir dem Kunden für diesen Vertrag in Rechnung stellen.
date_signed – Datum der Vertragsunterzeichnung.
start_date – Das Datum, an dem der Vertrag gültig wird (z. B. bei einem Miet- oder Pachtvertrag).
end_date – Das Datum, an dem der Vertrag ausläuft. Es kann NULL sein, falls wir einen Vertrag unterzeichnen, der kein Enddatum hat. In den meisten Fällen kennen wir jedoch das end_date im Voraus.
transaction_id – Verweist auf die transaction Tabelle, wenn der Vertrag Teil einer Transaktion zwischen zwei Kunden ist. Es kann NULL-Werte enthalten, da es keinen zugehörigen Transaktionsdatensatz gibt, wenn der Vertrag direkt zwischen uns und einem Kunden besteht.

Der under_contract Tabelle bezieht sich auf Verträge und Nachlässe. Neben dem Primärschlüsselattribut id , enthält es nur zwei Fremdschlüssel, estate_id und contract_id . Dieses Fremdschlüsselpaar bildet auch den UNIQUE-Schlüssel der Tabelle.

Wir speichern Aufzeichnungen zu jeder von uns erstellten Rechnung in der invoice Tisch. Wenn der Kunde eine einzige Zahlung für den gesamten Vertrag leistet, gibt es in dieser Tabelle nur einen Datensatz für diesen Vertrag. Gleiches gilt, wenn wir an einen Kunden eine einmalige Zahlung leisten. Wählt der Kunde (oder unser Unternehmen) die Ratenzahlung, gibt es die gleiche Anzahl an Datensätzen wie der Wert im contract .number_of_invoices Feld. Die Attribute in dieser Tabelle sind:

contract_id – Die ID des zugehörigen Vertrags.
invoice_number – Eine eindeutige interne Kennung für die Rechnung.
issued_by – Eine Textbeschreibung des Rechnungsstellers. Wenn wir eine Rechnung ausstellen, speichern wir hier unsere Firmendaten. Wenn der Kunde es ausstellt, werden seine Daten hier gespeichert.
issued_to – Das Gegenteil von issued_by . Wenn wir den Kunden belasten, enthält dieses Attribut seine Details; Wenn der Kunde uns etwas in Rechnung stellt, werden unsere Daten hier gespeichert.
invoice_details – Alle Rechnungspositionsdetails.
invoice_amount – Der auf dieser Rechnung fällige Betrag.
date_created – Das tatsächliche Datum, an dem die Rechnung in unserem System erstellt wurde.
billing_date – Das Datum, an dem die Rechnung bezahlt werden soll.
date_paid – Das tatsächliche Datum, an dem die Rechnung bezahlt wurde. Es kann NULL sein, bis die Rechnung bezahlt ist.

Wir verwenden zwei weitere Wörterbücher, um Verträge zu beschreiben, contract_type und payment_frequency . Der contract_type_name Feld wird verwendet, um die Aktion zu bezeichnen, die wir im Vertrag durchführen:„Vermittlung (Kauf)“, „Vermittlung (Verkauf)“, „Vermittlung (Miete)“, „Vermittlung (Leasing)“, „Kauf (von einem Kunden) “, „Verkauf (an einen Kunden)“, „Leasing (von einem Kunden)“ und „Vermietung (an einen Kunden)“. Der payment_frequency_name Das Attribut beschreibt einfach, wie oft Rechnungen generiert werden, entweder von uns oder vom Kunden. Es kann Werte wie „einmal“, „einmal pro Monat“, „einmal alle 2 Monate“ und „einmal pro Jahr“ speichern.

Wenn unser Unternehmen eine Immobilie kauft oder mietet, zahlen wir den Kunden. Das bedeutet, dass wir derjenige auf der invoice sein werden .issued_to Feld und wir müssen Rechnungen bezahlen. Wenn wir eine Immobilie verkaufen oder vermieten, zahlt der Kunde uns und wir sind derjenige auf der invoice .issued_by Feld.

Wenn wir ein Geschäft zwischen zwei Kunden vermitteln, berechnen wir für unsere Dienstleistungen eine Gebühr. In diesem Fall unterzeichnen wir zwei separate Verträge, einen mit dem verkaufenden/vermietenden Kunden und einen weiteren mit dem kaufenden/vermietenden Kunden. Wir verknüpfen diese beiden Verträge miteinander, indem wir dieselbe transaction_id zuweisen zu beiden. Die transaction Tabelle wird verwendet, um Aufzeichnungen über Geschäfte zu speichern, die wir vermittelt haben. Die Attribute in dieser Tabelle sind:

transaction_id – Eine eindeutige ID für jede Transaktion.
transaction_type_id – Referenziert den transaction_type Wörterbuch.
client_offered – Referenziert den client Tabelle und zeigt an, wer ein Anwesen verkauft oder vermietet.
client_requested – Referenziert den client Tabelle und zeigt an, wer ein Anwesen kauft oder pachtet.
transaction_date – Das Datum, an dem die Transaktion tatsächlich stattfinden wird.
transaction_details – Alle Details zu dieser Transaktion, gespeichert in einem unstrukturierten Textformat.

Die letzte Tabelle in unserem Modell ist transaction_type Wörterbuch. Die in dieser Tabelle gespeicherten Werte werden jeder Transaktion entsprechend ihrer Art zugeordnet:„Kauf/Verkauf“ oder „Miete/Leasing“.

Die Führung eines Immobilienunternehmens ist sehr kompliziert, anspruchsvoll und sogar riskant. Damit alles reibungslos funktioniert, braucht es viel Organisation. Ich hoffe, dass dieses Datenmodell Ihnen geholfen hat, die Komplexität dieses Bereichs zu erkennen.

Wie immer gibt es viele Möglichkeiten, dieses Modell zu verbessern. Fühlen Sie sich frei, Ihre Vorschläge und Kommentare zu teilen.