Een gegevensmodel voor een makelaarskantoor

Wat is er, behalve locatie, nodig om een succesvol onroerendgoedbedrijf te runnen? We onderzoeken een datamodel om makelaars te helpen georganiseerd te blijven.

Het kopen, verkopen en huren van appartementen of huizen is tegenwoordig echt big business. De meeste mensen betalen graag een vergoeding en laten een professioneel makelaarskantoor het werk voor hen doen. Aan de andere kant zou het bedrijf in eigen naam kunnen handelen door onroerend goed te kopen om door te verkopen of te verhuren. Een vastgoedbedrijf kan ook een onroerend goed leasen en het vervolgens verhuren of onderverhuren en winst maken op het verschil.

Het is duidelijk dat het bijhouden van eigendommen een belangrijk onderdeel is van het runnen van een onroerendgoedbedrijf. Tegelijkertijd zijn datums even belangrijk. (bijv. Wanneer komt een huurappartement beschikbaar? Wanneer komt een stuk onroerend goed op de markt?) In dit artikel bekijken we een datamodel dat vastgoedbedrijven kan helpen georganiseerd te blijven.

Veelgestelde vragen over onroerend goed

Voordat we beginnen met het beschrijven van het model en de verwachte gegevens, zullen we eerst enkele vragen beantwoorden die specifiek zijn voor een vastgoedbedrijf. Vastgoed heeft veel termen en een volledige uitleg van het jargon en de principes gaat het bestek van dit artikel te buiten, dus we zullen hier alleen de meest voorkomende en fundamentele vragen beantwoorden.

Wat kan worden beschouwd als een landgoed of een onroerend goed?

Als we aan onroerend goed denken, is het eerste beeld dat we krijgen vaak van een huis of een andere woning. Vastgoed is veel meer dan dat. Gebouwen, kantoren, grond, minerale hulpbronnen en korpsen vallen ook in deze categorie. Voor de toepassing van dit artikel behandel ik alles dat "onverplaatsbaar" is als onroerend goed. Dat gezegd hebbende, zullen we ons vooral concentreren op appartementsgebouwen en huizen.
Waar bevindt zich het landgoed of het onroerend goed?

Voor huizen, gebouwen en appartementen is dit heel eenvoudig. We weten het exacte adres waar de woning zich bevindt. Land heeft geen adres, maar zijn positie wordt bepaald door een kadaster.
Welke gegevens moeten we opslaan?

In ons model moeten we alle landgoederen (d.w.z. onroerend goed) en klanten waarmee we werken opslaan. We hebben deze informatie nodig om rapporten te maken en ook om ons bedrijf te verbeteren.

We kunnen verwachten dat we regelmatig met klanten zullen communiceren, dus we moeten al hun contactgegevens opslaan. We willen ook weten welke medewerker contact heeft opgenomen met de klant en welke interesse de klant heeft getoond tijdens het gesprek.

Voor eigendommen hebben we hun gegevens en huidige status binnen handbereik nodig, zodat we vragen van potentiële klanten snel kunnen beantwoorden.

We bewaren ook onze contactgeschiedenis en alle contracten met betrekking tot klanten of eigendommen.
Hoe belangrijk zijn datums?

Datums zijn altijd cruciaal, maar ik wil benadrukken dat ze vooral belangrijk zijn in onroerend goed. We moeten precies weten hoe lang een van onze huurwoningen bezet is, zodat we het opnieuw kunnen verhuren zodra het beschikbaar komt. Er kan geen overlapping zijn wanneer twee klanten dezelfde woning huren. Als een potentiële klant de wens uitdrukt om op een bepaalde datum in de toekomst te huren, moeten we die informatie opslaan en een herinnering krijgen wanneer die datum nadert.
Hoe moet onze applicatie eruit zien?

Hiervoor is een webapplicatie de beste oplossing. Veel van het onroerendgoedwerk is op kantoor gebaseerd, maar verkoopagenten moeten nieuwe gegevens kunnen invoegen waar ze zich ook bevinden. De belangrijkste functionaliteit in onze app is een snelle zoekopdracht die klanten, eigendommen en eigendomsstatussen kan vinden.

Het gegevensmodel

Ons vastgoeddatamodel bestaat uit drie hoofdonderwerpen:

Estates and locations
Clients and contacts
Contracts and transactions

Er is één tabel, employee , dat buiten elk vakgebied valt.

Houd er rekening mee dat de employee en het estate tabellen in de Clients and contacts onderwerpgebied en de client tabel in de Contracts and transactions onderwerpgebied zijn slechts kopieën die worden gebruikt om het model te vereenvoudigen.

We bekijken de employee tafel eerst, ga verder met Estates and locations , ga naar Clients and contacts en sluit af met Contracts and transactions .

De werknemerstabel

We beginnen met de employee tafel. Het is eenvoudig:het slaat alleen de first_name op en last_name van elke werknemer. We zouden andere details kunnen toevoegen, zoals het belastingnummer van de werknemer, hun geboortedatum, adres, functie, enz. In dit model zullen we ons echter niet concentreren op de werknemers, dus alles wat we nodig hebben is een manier om werknemers te associëren met acties (zoals toegewezen worden aan een taak of contract). In deze tabel kunnen we ook vastleggen welke medewerker aan elk klantcontact heeft deelgenomen.

Sectie 1:Landgoederen en locaties

De Estates and location onderwerpgebied bevat zes tabellen die alle landgoederen (eigendommen) beschrijven waarmee we werken, hun locaties en hun huidige status.

De centrale tabel in dit onderwerpgebied is het estate tafel. Het bevat een lijst van alle landgoederen waarmee we zijn, waren of zullen werken. Dit omvat landgoederen waarvoor we bemiddelen tussen twee klanten, die we bezitten, die we hebben verkocht of verhuurd aan klanten, en alle bezittingen die we hebben gehuurd of gekocht van klanten. Het houdt ook een register bij van landgoederen waarmee we van plan zijn (of hadden gepland) om zaken mee te doen.

Omdat we ons in dit artikel voornamelijk richten op appartementen en huizen, zijn de attributen in deze tabel er meestal mee gerelateerd. Als we andere soorten onroerend goed willen beschrijven, kunnen we extra beschrijvende attributen met een nulwaarde toevoegen. We kunnen die waarden ook gewoon invoeren in de estate_description attribuut. De attributen in het estate tafel zijn:

estate_name – De naam van het landgoed. Dit kan onze interne naam zijn voor een woning (“Stoker house”) of een bekende publieke naam (“Bran Castle”).
city_id – De ID van de stad waar het landgoed zich bevindt.
estate_type_id – Verwijst naar het estate_type woordenboek.
floor_space en balconies_space – De grootte (in vierkante meters) van appartementsvloeren en balkons.
number_of_balconies , number_of_bedrooms , number_of_garages en number_of_parking_spaces – Gehele waarden voor elke categorie. Spreekt voor zich.
pets_allowed – Een Booleaanse waarde die aangeeft of huisdieren zijn toegestaan. Dit wordt meestal gebruikt voor huurwoningen.
estate_description – Een gedetailleerde beschrijving van een nalatenschap. Hier slaan we eventuele aanvullende informatie op, b.v. eigendomsgeschiedenis.
estate_status_id – Of er op dit moment een landgoed beschikbaar is of niet. We zullen dit veld gebruiken in onze zoekfunctie.

We hebben al twee woordenboeken genoemd die het estate tabel verwijst naar, estate_type en estate_status . Beide woordenboeken bevatten alleen een ID en een UNIEK naamkenmerk.

In de estate_type woordenboek, slaan we waarden op zoals "appartement", "huis", "veld", enz. De estate_status tabel zal waarden bevatten die aangeven of het onroerend goed momenteel beschikbaar is of niet, zoals "landgoed verhuurd", "vastgoed gekocht", "verkocht onroerend goed", "landgoed verhuurd".

We zullen de locatie van elk landgoed definiëren, niet alleen door een beschrijving (de estate . estate_description attribuut), maar ook per land en stad. Voor dit doel gebruiken we twee woordenboektabellen:country en city . Elk land wordt uniek gedefinieerd door een country_name , wat het enige attribuut (behalve ID) is dat in de tabel is opgeslagen. Aan de andere kant heeft elke stad een naam en een land. Sommige steden kunnen dezelfde naam hebben, maar we gaan ervan uit dat de naam van elke stad uniek is voor zijn land - slechts één Wenen, Oostenrijk of Genève, Zwitserland. Als we ons echter willen beschermen tegen duplicaten, kunnen we een regiokenmerk toevoegen. Maar voorlopig laten we alles zoals het is. De city_name – country_id paar is de UNIEKE sleutel van de city tafel.

De laatste tabel in dit onderwerpgebied is de in_charge tafel. We kunnen verwachten dat elke nalatenschap ten minste één medewerker zal hebben om de zaken die ermee verband houden te behandelen. Deze medewerker is onder meer verantwoordelijk voor de communicatie met klanten, het tonen van de nalatenschap aan potentiële klanten en andere administratieve en juridische taken. In de in_charge tafel hebben we:

estate_id en employee_id – Buitenlandse sleutels die respectievelijk verwijzen naar het gerelateerde landgoed en de klant.
date_from en date_to – De periode waarin de werknemer aan die boedel is toegewezen. Merk op dat "date_to" NULL kan zijn omdat een werknemer voor onbepaalde tijd voor een nalatenschap kan zorgen. Wanneer we een werknemer aan een nalatenschap toewijzen, moeten we ervoor zorgen dat ze niet al aan een andere nalatenschap zijn toegewezen door te controleren op overlappende datum-intervallen. Aan de andere kant kunnen we veel medewerkers tegelijkertijd op hetzelfde landgoed plaatsen. Dit zou wenselijk zijn wanneer medewerkers verschillende rollen hebben, b.v. de ene medewerker zorgt voor de klantcommunicatie, een andere medewerker laat de nalatenschap zien, een ander handelt verkoop- en juridische contracten af, enz.

Sectie 2:Klanten en contacten

De Client and contacts onderwerpgebied bestaat uit slechts twee tabellen, de client tabel en de contact tafel. De twee andere tabellen die in dit gebied worden getoond, employee:Clients and contacts en estate:Clients and contacts zijn slechts kopieën.

De client tabel bevat records van alle klanten waarmee we ooit hebben gewerkt, inclusief huidige en potentiële klanten. Wie is een potentiële klant? Het kan iemand zijn die heeft gezegd dat hij in de toekomst onroerend goed van ons wil verkopen, kopen of huren. We moeten de contactgegevens en eigendommen van dergelijke klanten opslaan voor toekomstig gebruik. De attributen in de client tabellen zijn:

client_name – Voor een persoon bevat dit veld hun voor- en achternaam. Als de klant een rechtspersoon is, heeft hij de naam van het bedrijf of de entiteit.
client_address – Een tekstbeschrijving van de locatie van de klant.
contact_person – Voor- en achternaam (en waarschijnlijk een functietitel als de klant een bedrijf is) van onze contactpersoon.
phone , mobile en mail – De contactgegevens van de klant.
client_details – Alle andere details met betrekking tot die klant. Deze worden opgeslagen in een ongestructureerd tekstformaat.

De laatste vijf attributen in deze tabel zijn nullable omdat ze niet cruciaal zijn. We zullen waarschijnlijk informatie van ten minste één contactpersoon moeten opslaan, maar we weten misschien niet van tevoren wie onze contactpersoon zal zijn.

De tweede en laatste tabel in dit onderwerpgebied is de contact tafel. Hier slaan we gegevens op over elke interactie die we met klanten hebben gehad. We zullen deze informatie gebruiken om onze toekomstige activiteiten te optimaliseren. Als een klant bijvoorbeeld vraagt om een bepaald landgoed van ons te huren wanneer het beschikbaar komt, moeten we dat verzoek opslaan en hen informeren wanneer het landgoed klaar is. De attributen in de tabel zijn:

client_id – Het ID van de betrokken klant.
employee_id – Het ID van de betrokken medewerker bij die contactinstantie. Dit kan NULL zijn omdat een klant geen contact mag opnemen met een individuele medewerker – b.v. misschien heeft de klant een e-mail naar het bedrijfsaccount gestuurd. Toch kunnen we in de meeste gevallen verwachten dat we weten welke medewerker een interactie heeft afgehandeld.
estate_id – Het ID van de gerelateerde boedel. Dit is handig wanneer de klant om een bepaalde woning vraagt of als de klant iets wil verkopen of verhuren dat we al in ons systeem hebben.
contact_time – Het tijdstip waarop het contact plaatsvond.
contact_details – Alle ongestructureerde notities die we over dat contact willen bewaren. We zouden iets kunnen schrijven als "Klant heeft de wens uitgesproken om een huis te kopen in buurt."

Sectie 3:Contracten en transacties

Het laatste onderwerp in ons model is Contracts and transactions . We zullen het gebruiken om landgoederen met klanten te relateren.

De centrale tabel van deze sectie is het contract tafel. Hier slaan we alle contractdetails op en relateren we contracten met klanten en medewerkers. De kenmerken in deze tabel zijn:

client_id – De ID van de klant die het gerelateerde contract heeft ondertekend.
employee_id – De ID van de werknemer die het contract namens ons bedrijf heeft ondertekend.
contract_type_id – Verwijst naar het contract_type woordenboek en geeft aan of het contract betrekking heeft op het kopen, verkopen, leasen of huren van onroerend goed.
contract_details – Een gedetailleerde beschrijving van het contact, opgeslagen in tekstformaat.
payment_frequency_id – Verwijst naar de payment_frequency woordenboek en definieert de intervallen wanneer facturen moeten worden verzonden.
number_of_invoices – Het aantal facturen dat moet worden gegenereerd. Als het bedrijf slechts één keer betaalt, wordt een waarde van "1" opgeslagen in dit kenmerk en het volledige payment_amount zal gelijk zijn aan het invoice_amount .
payment_amount – Het totale betaalde bedrag.
fee_percentage – Het percentage dat wij de opdrachtgever in rekening brengen. We kunnen bijvoorbeeld 5% van de verkoopprijs van een huis als vergoeding in rekening brengen. De waarde in deze kolom moet hetzelfde zijn als het contract_type .fee_percentage attribuut voor dit contract. Het fee_percentage attribuut wordt gebruikt om het fee_amount . te berekenen wanneer we een waarde invoeren in het payment_amount attribuut.
fee_amount – Het totale bedrag dat we de klant voor dit contract in rekening brengen.
date_signed – De datum waarop het contract is ondertekend.
start_date – De datum waarop het contract geldig wordt (bijvoorbeeld voor een huur- of leasecontract).
end_date – De datum waarop het contract afloopt. Het kan NULL zijn als we een contract ondertekenen zonder einddatum. In de meeste gevallen weten we echter de end_date vooraf.
transaction_id –Verwijst naar de transaction tabel als het contract deel uitmaakt van een transactie tussen twee klanten. Het kan NULL-waarden bevatten omdat er geen gerelateerd transactierecord is als het contract rechtstreeks tussen ons en een klant is.

De under_contract tabel heeft betrekking op contracten en landgoederen. Naast het primaire sleutelkenmerk id , het bevat slechts twee externe sleutels, estate_id en contract_id . Dit vreemde sleutelpaar vormt tevens de UNIEKE sleutel van de tabel.

We slaan records op van elke factuur die we hebben gegenereerd in de invoice tafel. Als de klant één keer betaalt voor het hele contract, is er slechts één record in deze tabel voor dat contract. Hetzelfde geldt als wij een eenmalige betaling doen aan een opdrachtgever. Als de klant (of ons bedrijf) ervoor kiest om in termijnen te betalen, is er hetzelfde aantal records als de waarde in het contract .number_of_invoices veld. De kenmerken in deze tabel zijn:

contract_id – De ID van het gerelateerde contract.
invoice_number – Een unieke interne identificatie voor de factuur.
issued_by – Een tekstbeschrijving van de uitgever van de factuur. Wanneer we een factuur uitreiken, slaan we hier onze bedrijfsgegevens op. Als de klant het uitgeeft, worden hun gegevens hier opgeslagen.
issued_to – Het tegenovergestelde van issued_by . Als we de klant kosten in rekening brengen, bevat dit kenmerk hun gegevens; als de klant ons kosten in rekening brengt, dan worden onze gegevens hier opgeslagen.
invoice_details – Alle details van de factuuritems.
invoice_amount – Het verschuldigde bedrag op deze factuur.
date_created – De werkelijke datum waarop de factuur in ons systeem is aangemaakt.
billing_date – De datum waarop de factuur betaald moet worden.
date_paid – De werkelijke datum waarop de factuur is betaald. Het kan NULL zijn totdat de factuur is betaald.

We gebruiken nog twee woordenboeken om contracten te beschrijven, contract_type en payment_frequency . De contract_type_name veld wordt gebruikt om de actie aan te duiden die we in het contract uitvoeren:"bemiddeling (kopen)", "bemiddeling (verkopen)", "bemiddeling (huren)", "bemiddeling (leasing)", "kopen (van een klant) ”, “verkopen (aan een klant)”, “leasing (van een klant)” en “verhuren (aan een klant)”. De payment_frequency_name attribuut beschrijft eenvoudig hoe vaak facturen worden gegenereerd, hetzij door ons, hetzij door de klant. Het kan waarden opslaan zoals "eenmaal", "eenmaal per maand", "eenmaal per 2 maanden" en "eenmaal per jaar".

Als ons bedrijf onroerend goed koopt of huurt, betalen we de klant. Dit betekent dat wij degene zijn op de invoice .issued_to veld en we moeten facturen betalen. Als we een landgoed verkopen of verhuren, betaalt de klant ons en zijn wij degene op de invoice .issued_by veld.

Als we een deal tussen twee klanten bemiddelen, brengen we een vergoeding in rekening voor onze diensten. In dit geval ondertekenen we twee afzonderlijke contracten, een met de verkopende/verhuurde klant en een andere met de koper/verhuurde klant. We koppelen deze twee contracten aan elkaar door dezelfde transaction_id . toe te wijzen aan beide. De transaction tabel wordt gebruikt om records op te slaan van deals die we hebben bemiddeld. De kenmerken in deze tabel zijn:

transaction_id – Een unieke ID voor elke transactie.
transaction_type_id – Verwijst naar het transaction_type woordenboek.
client_offered – Verwijst naar de client tabel en geeft aan wie een landgoed verkoopt of verhuurt.
client_requested – Verwijst naar de client tabel en geeft aan wie een landgoed koopt of huurt.
transaction_date – De datum waarop de transactie daadwerkelijk zal plaatsvinden.
transaction_details – Alle details met betrekking tot die transactie, opgeslagen in een ongestructureerd tekstformaat.

De finaletafel in ons model is het transaction_type woordenboek. De waarden die in deze tabel zijn opgeslagen, worden aan elke transactie toegewezen op basis van wat het is:"kopen/verkopen" of "huren/leasing".

Het runnen van een vastgoedbedrijf is erg ingewikkeld, veeleisend en zelfs riskant. Om alles in goede banen te leiden, is veel organisatie nodig. Ik hoop dat dit datamodel je heeft geholpen om de complexiteit van dit veld te realiseren.

Zoals altijd zijn er veel manieren om dit model te verbeteren. Deel gerust uw suggesties en opmerkingen.