Datový model realitní kanceláře

Co je kromě lokality potřeba k úspěšnému podnikání v oblasti nemovitostí? Zkoumáme datový model, který pomůže realitním kancelářím udržet si pořádek.

Nákup, prodej a pronájem bytů nebo domů je dnes opravdu velký byznys. Většina lidí si ráda zaplatí poplatek a nechá práci od profesionální realitní kanceláře. Na druhou stranu by společnost mohla jednat svým vlastním jménem a kupovat nemovitosti za účelem jejich dalšího prodeje nebo pronájmu. Realitní společnost může také pronajmout nemovitost, poté ji pronajmout nebo podnajmout a vydělat na rozdílu.

Sledování nemovitostí je samozřejmě důležitou součástí podnikání v oblasti nemovitostí. Termíny jsou přitom stejně důležité. (např. Kdy bude k dispozici nájemní byt? Kdy se nemovitost dostane na trh?) V tomto článku se podíváme na datový model, který může realitním společnostem pomoci udržet si pořádek.

Nejčastější dotazy k nemovitostem

Než začneme popisovat model a jeho očekávaná data, nejprve si odpovíme na některé otázky specifické pro obchod s nemovitostmi. Nemovitosti mají mnoho termínů a úplné vysvětlení jejich žargonu a principů značně přesahuje rámec tohoto článku, takže zde odpovíme pouze na ty nejběžnější a základní otázky.

Co lze považovat za majetek nebo majetek?

Když přemýšlíme o nemovitosti, první obrázek, který se nám často naskytne, je dům nebo nějaké jiné obydlí. Nemovitosti jsou mnohem víc než to. Do této kategorie spadají také budovy, kanceláře, pozemky, nerostné zdroje a sbory. Pro účely tohoto článku budu vše, co je „nemovité“, považovat za nemovitost. Přesto se zaměříme především na bytové domy a domy.
Kde se nemovitost nebo nemovitost nachází?

U domů, budov a bytů je to velmi jednoduché. Budeme znát přesnou adresu, kde se nemovitost nachází. Pozemek nemá adresu, ale jeho poloha je určena katastrem nemovitostí.
Jaká data potřebujeme uchovávat?

V našem modelu potřebujeme uložit všechny nemovitosti (tj. nemovitosti) a klienty, se kterými pracujeme. Tyto informace potřebujeme k vytváření přehledů a také ke zlepšení našeho podnikání.

Můžeme očekávat, že s klienty budeme často komunikovat, takže musíme uchovávat všechny jejich kontaktní údaje. Budeme také chtít vědět, který zaměstnanec klienta kontaktoval a jaký zájem klient během rozhovoru projevil.

U nemovitostí potřebujeme jejich podrobnosti a aktuální stav na dosah ruky, abychom mohli rychle odpovídat na dotazy potenciálních zákazníků.

Uložíme také naši historii kontaktů a veškeré smlouvy týkající se klientů nebo nemovitostí.
Jak důležitá jsou data?

Termíny jsou vždy zásadní, ale chci zdůraznit, že jsou důležité zejména v realitách. Potřebujeme znát přesnou dobu, po kterou je jedna z našich pronajatých nemovitostí obsazená, abychom si ji mohli znovu pronajmout, jakmile bude k dispozici. Když dva klienti pronajímají stejnou nemovitost, nemůže dojít k žádnému překrývání. Pokud potenciální klient vyjádří přání pronajmout si k nějakému konkrétnímu budoucímu datu, měli bychom tyto informace uložit a dostat připomenutí, až se toto datum blíží.
Jak by měla naše aplikace vypadat?

Pro tento účel je nejlepším řešením webová aplikace. Velká část realitní práce probíhá v kanceláři, ale obchodní zástupci by měli mít možnost vkládat nová data, ať jsou kdekoli. Nejdůležitější funkcí naší aplikace je rychlé vyhledávání, které dokáže najít klienty, nemovitosti a stavy nemovitostí.

Datový model

Náš datový model nemovitostí se skládá ze tří hlavních tematických oblastí:

Estates and locations
Clients and contacts
Contracts and transactions

Je tam jeden stůl, employee , která je mimo jakoukoli předmětnou oblast.

Upozorňujeme, že employee a estate tabulky v Clients and contacts předmětová oblast a client tabulky v Contracts and transactions předmětová oblast jsou pouze kopie používané pro zjednodušení modelu.

Podíváme se na employee nejprve tabulku, pokračujte Estates and locations , přejděte na Clients and contacts a poté dokončete Contracts and transactions .

Tabulka zaměstnanců

Začneme employee stůl. Je to jednoduché:ukládá pouze first_name a last_name každého zaměstnance. Mohli bychom přidat další podrobnosti, jako je daňové identifikační číslo zaměstnance, jeho datum narození, adresa, pracovní role atd. V tomto modelu se však nebudeme zaměřovat na zaměstnance, takže vše, co potřebujeme, je způsob, jak zaměstnance sdružit akce (jako je přiřazení k úkolu nebo smlouvě). Tato tabulka nám také umožní zaznamenat, který zaměstnanec se účastnil každého kontaktu s klientem.

Část 1:Statky a lokality

Estates and location předmětová oblast obsahuje šest tabulek, které popisují všechny nemovitosti (vlastnosti), se kterými pracujeme, jejich umístění a jejich aktuální stav.

Ústřední tabulkou v této tematické oblasti je estate stůl. Obsahuje seznam všech statků, se kterými jsme, byli nebo budeme pracovat. To zahrnuje nemovitosti, pro které zprostředkováváme mezi dvěma klienty, ty, které vlastníme, ty, které jsme prodali nebo pronajali klientům, a všechny, které jsme si pronajali nebo koupili od klientů. Vede také záznamy o nemovitostech, se kterými plánujeme (nebo jsme plánovali) obchodovat.

Protože se v tomto článku zaměřujeme hlavně na byty a domy, atributy v této tabulce se většinou týkají právě nich. Pokud bychom chtěli popsat jiné typy nemovitostí, mohli bychom přidat další popisné atributy s možností null. Můžeme také jednoduše zadat tyto hodnoty do estate_description atribut. Atributy v estate tabulka jsou:

estate_name – Jméno panství. Může to být náš interní název pro nemovitost („Stokerův dům“) nebo známý veřejný název („Hrad Bran“).
city_id – ID města, kde se nemovitost nachází.
estate_type_id – Odkazuje na estate_type slovník.
floor_space a balconies_space – Velikost (v metrech čtverečních) bytových pater a balkonů.
number_of_balconies , number_of_bedrooms , number_of_garages a number_of_parking_spaces – Celočíselné hodnoty pro každou kategorii. Samovysvětlující.
pets_allowed – Booleovská hodnota označující, zda jsou povolena domácí zvířata. To se většinou používá pro pronájem nemovitostí.
estate_description – Podrobný popis nemovitosti. Zde ukládáme jakékoli další informace, např. historie majetku.
estate_status_id – Je-li nemovitost aktuálně k dispozici, či nikoli. Toto pole použijeme v naší vyhledávací funkci.

Již jsme zmínili dva slovníky estate tabulka odkazuje na, estate_type a estate_status . Oba tyto slovníky obsahují pouze ID a atribut UNIQUE name.

V estate_type slovníku, budeme ukládat hodnoty jako „byt“, „dům“, „pole“ atd. estate_status tabulka bude mít hodnoty udávající, zda je nemovitost aktuálně k dispozici či nikoli, například „nemovitost pronajatá“, „koupená nemovitost“, „prodaná nemovitost“, „pronajatá nemovitost“.

Definujeme polohu každé nemovitosti, nejen popisem (estate . estate_description atribut), ale také podle země a města. Pro tento účel použijeme dvě slovníkové tabulky:country a city . Každá země je jednoznačně definována country_name , což bude jediný atribut (kromě ID) uložený v tabulce. Na druhou stranu má každé město svůj název a zemi. Některá města mohou mít stejný název, ale budeme předpokládat, že jméno každého města je jedinečné pro jeho zemi – pouze jedno Vídeň, Rakousko nebo Ženeva, Švýcarsko. Pokud však chceme chránit před duplikáty, mohli bychom přidat atribut region. Zatím však necháme vše tak, jak je. city_name – country_id pár je UNIKÁTNÍ klíč city tabulka.

Poslední tabulka v této oblasti je in_charge stůl. Dá se očekávat, že každé panství bude mít přiděleného alespoň jednoho zaměstnance, který bude vyřizovat záležitosti s ním související. Tento zaměstnanec je zodpovědný za věci, jako je komunikace s klienty, ukazování nemovitosti potenciálním klientům a další administrativní a právní úkony. V in_charge stůl, budeme mít:

estate_id a employee_id – Cizí klíče, které odkazují na související nemovitost a klienta.
date_from a date_to – Interval, kdy byl zaměstnanec přidělen k tomuto majetku. Všimněte si, že „date_to“ může být NULL, protože zaměstnanec by se mohl starat o majetek neomezeně dlouho. Když přiřadíme zaměstnance k nemovitostem, měli bychom se ujistit, že již nejsou přiřazeni do jiné nemovitosti, a to kontrolou překrývajících se intervalů dat. Na druhou stranu můžeme do stejné nemovitosti přiřadit mnoho zaměstnanců současně. To by bylo žádoucí, když zaměstnanci mají různé role, např. jeden zaměstnanec se stará o komunikaci s klientem, další zaměstnanec ukazuje nemovitost, další vyřizuje prodejní a právní smlouvy atd.

Část 2:Klienti a kontakty

Client and contacts předmětová oblast se skládá pouze ze dvou tabulek, client tabulka a contact stůl. Další dvě tabulky zobrazené v této oblasti, employee:Clients and contacts a estate:Clients and contacts jsou jen kopie.

client tabulka obsahuje záznamy všech klientů, se kterými jsme kdy spolupracovali, včetně stávajících i potenciálních klientů. Kdo je potenciální klient? Může to být někdo, kdo řekl, že od nás chce v budoucnu prodat, koupit nebo pronajmout nějakou nemovitost. Potřebujeme uchovávat kontaktní údaje a vlastnosti těchto klientů pro budoucí použití. Atributy v client tabulka jsou:

client_name – U jednotlivce toto pole obsahuje jeho jméno a příjmení. Pokud je klientem právnická osoba, je držitelem názvu společnosti nebo subjektu.
client_address – Textový popis polohy klienta.
contact_person – Jméno a příjmení (a pravděpodobně pracovní zařazení, pokud je klient firma) naší kontaktní osoby.
phone , mobile a mail – Kontaktní údaje klienta.
client_details – Všechny další podrobnosti týkající se daného klienta. Ty jsou uloženy v nestrukturovaném textovém formátu.

Posledních pět atributů v této tabulce má hodnotu null, protože nejsou rozhodující. Pravděpodobně budeme muset uložit informace alespoň o jedné kontaktní osobě, ale možná předem nevíme, kdo bude náš kontakt.

Druhá a poslední tabulka v této oblasti je contact stůl. Zde budeme ukládat data o každé interakci, kterou jsme měli s klienty. Tyto informace použijeme k optimalizaci našeho budoucího podnikání – pokud například klient požádá o pronájem určité nemovitosti od nás, až bude k dispozici, měli bychom tuto žádost uložit a informovat jej, až bude nemovitost připravena. Atributy v tabulce jsou:

client_id – ID zúčastněného klienta.
employee_id – ID zaměstnance zapojeného do této instance kontaktu. To může být NULL, protože klient nesmí kontaktovat žádného jednotlivého zaměstnance – např. možná klient poslal e-mail na účet společnosti. Ve většině případů však můžeme očekávat, že budeme vědět, který zaměstnanec interakci zpracoval.
estate_id – ID související nemovitosti. To je užitečné, když klient žádá o určitou nemovitost nebo pokud chce prodat nebo pronajmout něco, co již máme v našem systému.
contact_time – Čas, kdy ke kontaktu došlo.
contact_details – Jakékoli nestrukturované poznámky, které chceme o tomto kontaktu uložit. Mohli bychom napsat něco jako „Klient vyjádřil přání koupit dům v čtvrti.“

Část 3:Smlouvy a transakce

Poslední předmět v našem modelu je Contracts and transactions . Použijeme ho ke spojení nemovitostí s klienty.

Ústřední tabulkou této sekce je contract stůl. Zde budeme ukládat všechny podrobnosti o smlouvě a vztahovat smlouvy s klienty a zaměstnanci. Atributy v této tabulce jsou:

client_id – ID klienta, který podepsal související smlouvu.
employee_id – ID zaměstnance, který za naši společnost podepsal smlouvu.
contract_type_id – Odkazuje na contract_type slovník a označuje, zda se smlouva týká nákupu, prodeje, leasingu nebo pronájmu nemovitosti.
contract_details – Podrobný popis kontaktu uložený v textovém formátu.
payment_frequency_id – Odkazuje na payment_frequency slovník a definuje intervaly, kdy mají být faktury odesílány.
number_of_invoices – Počet faktur, které mají být vygenerovány. Pokud společnost platí pouze jednou, je v tomto atributu uložena hodnota „1“ a celá payment_amount se bude rovnat invoice_amount .
payment_amount – Celková zaplacená částka.
fee_percentage – Procento, které účtujeme klientovi. Můžeme si například účtovat 5 % z prodejní ceny domu jako poplatek. Hodnota v tomto sloupci by měla být stejná jako hodnota contract_type .fee_percentage atribut pro tuto smlouvu. fee_percentage atribut bude použit k výpočtu fee_amount když zadáme hodnotu do payment_amount atribut.
fee_amount – Celková částka poplatku, kterou budeme klientovi účtovat za tuto smlouvu.
date_signed – Datum, kdy byla smlouva podepsána.
start_date – Datum, kdy smlouva nabude platnosti (např. u nájemní nebo leasingové smlouvy).
end_date – Datum, kdy smlouva vyprší. Může být NULL v případě, že podepíšeme smlouvu, která nemá žádné datum ukončení. Ve většině případů však budeme znát end_date předem.
transaction_id –Odkazuje na transaction pokud je smlouva součástí transakce mezi dvěma klienty. Může obsahovat hodnoty NULL, protože pokud je smlouva uzavřena přímo mezi námi a klientem, nebude existovat související záznam transakce.

under_contract tabulka se týká smluv a nemovitostí. Vedle atributu primárního klíče id , obsahuje pouze dva cizí klíče, estate_id a contract_id . Tento pár cizích klíčů tvoří také UNIKÁTNÍ klíč tabulky.

Záznamy o každé vygenerované faktuře uložíme do invoice stůl. Pokud klient provede jednu platbu za celou smlouvu, bude v této tabulce pro danou smlouvu pouze jeden záznam. Totéž platí, pokud provedeme jednorázovou platbu klientovi. Pokud se klient (nebo naše společnost) rozhodne platit ve splátkách, je zde stejný počet záznamů, jako je hodnota ve contract .number_of_invoices pole. Atributy v této tabulce jsou:

contract_id – ID související smlouvy.
invoice_number – Jedinečný interní identifikátor faktury.
issued_by – Textový popis vystavitele faktury. Když vystavíme fakturu, uložíme zde údaje o naší společnosti. Pokud jej klient vydá, jeho údaje budou uloženy zde.
issued_to – Opak issued_by . Pokud účtujeme klientovi, pak tento atribut bude obsahovat jeho podrobnosti; pokud nám klient účtuje poplatky, pak jsou naše údaje uloženy zde.
invoice_details – Všechny podrobnosti položky faktury.
invoice_amount – Částka splatná na této faktuře.
date_created – Skutečné datum, kdy byla faktura vytvořena v našem systému.
billing_date – Datum, kdy má být faktura uhrazena.
date_paid – Skutečné datum, kdy byla faktura uhrazena. Dokud nebude faktura uhrazena, může mít hodnotu NULL.

K popisu smluv použijeme další dva slovníky, contract_type a payment_frequency . contract_type_name pole se používá k označení akce, kterou ve smlouvě provádíme:„zprostředkování (nákup)“, „zprostředkování (prodej)“, „zprostředkování (pronájem)“, „zprostředkování (leasing)“, „nákup (od zákazníka) “”, “prodej (zákazníkovi)”, “leasing (od zákazníka)” a “pronájem (zákazníkovi)”. payment_frequency_name atribut jednoduše popisuje, jak často budou faktury generovány, ať už námi nebo klientem. Může ukládat hodnoty jako „jednou“, „jednou za měsíc“, „jednou za 2 měsíce“ a „jednou za rok“.

Pokud naše společnost koupí nebo pronajme nějakou nemovitost, zaplatíme klientovi. To znamená, že my budeme na invoice .issued_to pole a budeme muset platit faktury. Pokud prodáme nebo pronajmeme nemovitost, klient nám zaplatí a my budeme na invoice .issued_by pole.

Pokud zprostředkujeme obchod mezi dvěma klienty, budeme si za naše služby účtovat poplatek. V tomto případě podepíšeme dvě samostatné smlouvy, jednu s prodávajícím/pronajímatelem a druhou s kupujícím/pronajímatelem. Tyto dvě smlouvy spojíme dohromady přiřazením stejného transaction_id oběma. transaction tabulka slouží k ukládání záznamů o obchodech, které jsme zprostředkovali. Atributy v této tabulce jsou:

transaction_id – Jedinečné ID pro každou transakci.
transaction_type_id – Odkazuje na transaction_type slovník.
client_offered – Odkazuje na client tabulka a označuje, kdo prodává nebo pronajímá nemovitost.
client_requested – Odkazuje na client tabulka a označuje, kdo kupuje nebo pronajímá nemovitost.
transaction_date – Datum, kdy k transakci skutečně dojde.
transaction_details – Všechny podrobnosti související s touto transakcí, uložené v nestrukturovaném textovém formátu.

Konečná tabulka v našem modelu je transaction_type slovník. Hodnoty uložené v této tabulce jsou přiřazeny každé transakci podle toho, o co se jedná:„nákup/prodej“ nebo „pronájem/leasing“.

Provozování realitní společnosti je velmi komplikované, náročné a dokonce i riskantní. Aby vše fungovalo hladce, je potřeba velká organizace. Doufám, že vám tento datový model pomohl uvědomit si složitost tohoto oboru.

Jako vždy existuje mnoho způsobů, jak tento model vylepšit. Neváhejte se podělit o své návrhy a komentáře.