Model danych agencji nieruchomości

Co oprócz lokalizacji jest potrzebne, aby prowadzić udany biznes na rynku nieruchomości? Badamy model danych, aby pomóc agencjom nieruchomości zachować porządek.

Kupowanie, sprzedawanie i wynajmowanie mieszkań lub domów to dziś naprawdę wielki biznes. Większość ludzi chętnie uiszcza opłatę i powierza pracę profesjonalnej agencji nieruchomości. Z drugiej strony firma mogłaby działać we własnym imieniu, kupując nieruchomości do odsprzedaży lub wynajmu. Firma zajmująca się nieruchomościami może również wydzierżawić nieruchomość, a następnie ją wydzierżawić lub poddzierżawić i osiągnąć zysk z różnicy.

Oczywiście śledzenie nieruchomości jest ważną częścią prowadzenia działalności na rynku nieruchomości. Jednocześnie daty są równie ważne. (np. Kiedy mieszkanie na wynajem będzie dostępne? Kiedy nieruchomość trafi na rynek?) W tym artykule przyjrzymy się modelowi danych, który może pomóc firmom z branży nieruchomości w utrzymaniu porządku.

Najczęstsze pytania dotyczące nieruchomości

Zanim zaczniemy opisywać model i jego oczekiwane dane, najpierw odpowiemy na kilka pytań dotyczących branży nieruchomości. Nieruchomość ma wiele terminów, a pełne wyjaśnienie ich żargonu i zasad wykracza daleko poza zakres tego artykułu, więc odpowiemy tutaj tylko na najczęstsze i podstawowe pytania.

Co można uznać za majątek lub nieruchomość?

Kiedy myślimy o nieruchomościach, pierwszym obrazem, jaki otrzymujemy, jest często dom lub inne mieszkanie. Nieruchomości to znacznie więcej. Budynki, biura, grunty, surowce mineralne i korpusy również należą do tej kategorii. Na potrzeby tego artykułu wszystko, co „nieruchome” potraktuję jako nieruchomość. To powiedziawszy, skupimy się głównie na budynkach mieszkalnych i domach.
Gdzie znajduje się posiadłość lub nieruchomość?

W przypadku domów, budynków i mieszkań jest to bardzo proste. Poznamy dokładny adres, pod którym znajduje się nieruchomość. Grunt nie posiada adresu, ale jego położenie określa księga wieczysta.
Jakie dane musimy przechowywać?

W naszym modelu musimy przechowywać wszystkie nieruchomości (czyli nieruchomości) i klientów, z którymi współpracujemy. Potrzebujemy tych informacji do tworzenia raportów, a także do ulepszania naszej działalności.

Możemy oczekiwać, że będziemy często komunikować się z klientami, dlatego musimy przechowywać wszystkie ich dane kontaktowe. Będziemy również chcieli wiedzieć, który pracownik skontaktował się z klientem i jakie zainteresowanie wyraził podczas rozmowy.

W przypadku nieruchomości potrzebujemy ich danych i aktualnego stanu na wyciągnięcie ręki, abyśmy mogli szybko odpowiedzieć na zapytania potencjalnych klientów.

Będziemy również przechowywać naszą historię kontaktów i wszelkie umowy związane z klientami lub nieruchomościami.
Jak ważne są daty?

Daty są zawsze kluczowe, ale chcę podkreślić, że są one szczególnie ważne w branży nieruchomości. Musimy znać dokładną ilość czasu, w której jedna z naszych wynajmowanych nieruchomości jest zajęta, abyśmy mogli ją ponownie wynająć, gdy tylko stanie się dostępna. Nie może się nakładać, gdy dwóch klientów wynajmuje tę samą nieruchomość. Jeśli potencjalny klient wyrazi chęć wynajęcia w określonym terminie w przyszłości, powinniśmy przechowywać te informacje i otrzymać przypomnienie, gdy ten termin się zbliża.
Jak powinna wyglądać nasza aplikacja?

W tym celu najlepszym rozwiązaniem jest aplikacja internetowa. Wiele prac związanych z nieruchomościami odbywa się w biurach, ale agenci sprzedaży powinni mieć możliwość wprowadzania nowych danych, gdziekolwiek się znajdują. Najważniejszą funkcjonalnością naszej aplikacji jest szybkie wyszukiwanie, które może znaleźć klientów, nieruchomości i statusy nieruchomości.

Model danych

Nasz model danych dotyczących nieruchomości składa się z trzech głównych obszarów tematycznych:

Estates and locations
Clients and contacts
Contracts and transactions

Jest jedna tabela, employee , czyli poza obszarem tematycznym.

Należy pamiętać, że employee i estate tabele w Clients and contacts obszar tematyczny i client tabela w Contracts and transactions obszar tematyczny to tylko kopie używane w celu uproszczenia modelu.

Przyjrzymy się employee najpierw tabela, przejdź do Estates and locations , przejdź do Clients and contacts , a następnie zakończ z Contracts and transactions .

Tabela pracowników

Zaczniemy od employee stół. To proste:przechowuje tylko first_name i last_name każdego pracownika. Moglibyśmy dodać inne szczegóły, takie jak numer NIP pracownika, jego datę urodzenia, adres, stanowisko, itp. Jednak w tym modelu nie będziemy koncentrować się na pracownikach, więc wszystko, czego potrzebujemy, to sposób na skojarzenie pracowników z działania (np. przypisanie do zadania lub umowy). Ta tabela pozwoli nam również zapisać, który pracownik brał udział w każdym kontakcie z klientem.

Sekcja 1:Posiadłości i lokalizacje

Estates and location obszar tematyczny zawiera sześć tabel opisujących wszystkie nieruchomości (właściwości), z którymi pracujemy, ich lokalizacje i ich aktualny status.

Centralną tabelą w tym obszarze tematycznym jest estate stół. Zawiera listę wszystkich osiedli, z którymi jesteśmy, byliśmy lub będziemy pracować. Obejmuje to nieruchomości, w których pośredniczymy między dwoma klientami, tymi, których jesteśmy właścicielami, tymi, które sprzedaliśmy lub wynajmowaliśmy klientom, oraz tymi, które wydzierżawiliśmy lub kupiliśmy od klientów. Prowadzi również rejestr nieruchomości, z którymi planujemy (lub planowaliśmy) prowadzić interesy.

Ponieważ w tym artykule skupiamy się głównie na mieszkaniach i domach, atrybuty w tej tabeli są w większości z nimi związane. Jeśli chcielibyśmy opisać inne rodzaje nieruchomości, moglibyśmy dodać dodatkowe atrybuty opisowe, które nie mogą zawierać wartości null. Moglibyśmy również po prostu wpisać te wartości w estate_description atrybut. Atrybuty w estate tabela to:

estate_name – Nazwa osiedla. Może to być nasza wewnętrzna nazwa nieruchomości („Dom Stokera”) lub dobrze znana nazwa publiczna („Zamek Bran”).
city_id – Identyfikator miasta, w którym znajduje się osiedle.
estate_type_id – Odwołuje się do estate_type słownik.
floor_space i balconies_space – Wielkość (w metrach kwadratowych) podłóg w mieszkaniach i balkonów.
number_of_balconies , number_of_bedrooms , number_of_garages i number_of_parking_spaces – Wartości całkowite dla każdej kategorii. Nie wymaga wyjaśnień.
pets_allowed – Wartość logiczna oznaczająca, czy zwierzęta są dozwolone. Jest to używane głównie do wynajmu nieruchomości.
estate_description – Szczegółowy opis posiadłości. Tutaj przechowujemy wszelkie dodatkowe informacje, m.in. historia nieruchomości.
estate_status_id – Czy posiadłość jest aktualnie dostępna, czy nie. Użyjemy tego pola w naszej funkcji wyszukiwania.

Wspomnieliśmy już o dwóch słownikach, które estate tabela odnosi się do, estate_type i estate_status . Oba te słowniki zawierają tylko identyfikator i atrybut UNIQUE name.

W estate_type słownika, będziemy przechowywać wartości takie jak „mieszkanie”, „dom”, „pole” itp. estate_status tabela będzie zawierała wartości określające, czy nieruchomość jest obecnie dostępna, czy nie, na przykład „nieruchomość wydzierżawiona”, „nieruchomość kupiona”, „nieruchomość sprzedana”, „nieruchomość wynajęta”.

Zdefiniujemy lokalizację każdej osiedla, nie tylko poprzez opis (estate . estate_description atrybut), ale także według kraju i miasta. W tym celu użyjemy dwóch tabel słownikowych:country i city . Każdy kraj jest jednoznacznie zdefiniowany przez country_name , który będzie jedynym atrybutem (poza identyfikatorem) przechowywanym w tabeli. Z drugiej strony każde miasto ma nazwę i kraj. Niektóre miasta mogą mieć taką samą nazwę, ale zakładamy, że nazwa każdego miasta jest unikalna dla danego kraju – tylko jeden Wiedeń w Austrii lub Genewa w Szwajcarii. Jeśli jednak chcemy zabezpieczyć się przed duplikatami, możemy dodać atrybut regionu. Na razie jednak zostawimy wszystko tak, jak jest. city_name – country_id para to UNIKALNY klucz city tabela.

Ostatnia tabela w tym obszarze tematycznym to in_charge stół. Możemy oczekiwać, że w każdym osiedlu będzie wyznaczony co najmniej jeden pracownik do obsługi spraw z nim związanych. Pracownik ten jest odpowiedzialny m.in. za komunikację z klientami, pokazywanie majątku potencjalnym klientom oraz za inne zadania administracyjne i prawne. W in_charge stół, będziemy mieli:

estate_id i employee_id – Klucze obce, które odnoszą się odpowiednio do powiązanej nieruchomości i klienta.
date_from i date_to – Interwał, w którym pracownik został przydzielony do tej osiedla. Zauważ, że „data_do” może mieć wartość NULL, ponieważ pracownik może zajmować się majątkiem w nieskończoność. Kiedy przypisujemy pracownika do spadku, powinniśmy upewnić się, że nie jest on już przypisany do innego majątku, sprawdzając, czy nie nakładają się na siebie interwały dat. Z drugiej strony do tego samego osiedla możemy jednocześnie przypisać wielu pracowników. Byłoby to pożądane, gdy pracownicy pełnią różne role, np. jeden pracownik zajmuje się komunikacją z klientem, inny pokazuje, że majątek, inny zajmuje się sprzedażą i umowami prawnymi itp.

Sekcja 2:Klienci i kontakty

Client and contacts obszar tematyczny składa się tylko z dwóch tabel, client tabela i contact stół. Dwie inne tabele pokazane w tym obszarze, employee:Clients and contacts i estate:Clients and contacts to tylko kopie.

client tabela zawiera rekordy wszystkich klientów, z którymi współpracowaliśmy, w tym obecnych i potencjalnych klientów. Kim jest potencjalny klient? Może to być ktoś, kto powiedział, że chce w przyszłości sprzedać, kupić lub wynająć od nas jakąś nieruchomość. Musimy przechowywać dane kontaktowe i właściwości takich klientów do wykorzystania w przyszłości. Atrybuty w client tabela to:

client_name – W przypadku osoby w tym polu znajduje się imię i nazwisko. Jeśli klient jest osobą prawną, posiada nazwę firmy lub podmiotu.
client_address – Tekstowy opis lokalizacji klienta.
contact_person – Imię i nazwisko (i prawdopodobnie stanowisko, jeśli klientem jest firma) naszej osoby kontaktowej.
phone , mobile i mail – Dane kontaktowe klienta.
client_details – Wszystkie inne szczegóły związane z tym klientem. Są one przechowywane w nieustrukturyzowanym formacie tekstowym.

Ostatnie pięć atrybutów w tej tabeli ma wartość null, ponieważ nie są one kluczowe. Prawdopodobnie będziemy musieli przechowywać informacje o co najmniej jednej osobie kontaktowej, ale możemy nie wiedzieć z góry, kto będzie naszym kontaktem.

Druga i ostatnia tabela w tym obszarze tematycznym to contact stół. Tutaj będziemy przechowywać dane o każdej interakcji, jaką mieliśmy z klientami. Wykorzystamy te informacje, aby zoptymalizować naszą przyszłą działalność – na przykład, jeśli klient poprosił nas o wynajęcie od nas określonej nieruchomości, gdy stanie się ona dostępna, powinniśmy przechowywać tę prośbę i poinformować go, gdy osiedle będzie gotowe. Atrybuty w tabeli to:

client_id – Identyfikator zaangażowanego klienta.
employee_id – Identyfikator pracownika zaangażowanego w tę instancję kontaktu. Może to być NULL, ponieważ klient nie może kontaktować się z żadnym indywidualnym pracownikiem – np. być może klient wysłał maila na konto firmowe. Mimo to w większości przypadków możemy się spodziewać, że będziemy wiedzieć, który pracownik obsługiwał interakcję.
estate_id – Identyfikator powiązanej nieruchomości. Jest to przydatne, gdy klient prosi o określoną nieruchomość lub jeśli chce sprzedać lub wydzierżawić coś, co już mamy w naszym systemie.
contact_time – Czas, w którym nastąpił kontakt.
contact_details – Wszelkie nieustrukturyzowane notatki, które chcemy zapisać na temat tego kontaktu. Możemy napisać coś w stylu „Klient wyraził chęć zakupu domu w okolicy”.

Sekcja 3:Umowy i transakcje

Ostatni obszar tematyczny w naszym modelu to Contracts and transactions . Wykorzystamy go do powiązania nieruchomości z klientami.

Centralną tabelą tej sekcji jest contract stół. To tam będziemy przechowywać wszystkie szczegóły umowy i powiązać umowy z klientami i pracownikami. Atrybuty w tej tabeli to:

client_id – Identyfikator klienta, który podpisał powiązaną umowę.
employee_id – Identyfikator pracownika, który podpisał umowę w imieniu naszej firmy.
contract_type_id – Odwołuje się do contract_type słownika i wskazuje, czy umowa dotyczy kupna, sprzedaży, dzierżawy lub wynajmu nieruchomości.
contract_details – Szczegółowy opis kontaktu, zapisany w formacie tekstowym.
payment_frequency_id – Odwołuje się do payment_frequency słownika i określa interwały, w jakich powinny być wysyłane faktury.
number_of_invoices – Liczba faktur, które powinny zostać wygenerowane. Jeśli firma płaci tylko raz, wartość „1” jest przechowywana w tym atrybucie i cała payment_amount będzie równa invoice_amount .
payment_amount – Całkowita zapłacona kwota.
fee_percentage – Procent jaki obciążamy klienta. Na przykład możemy pobrać jako opłatę 5% ceny sprzedaży domu. Wartość w tej kolumnie powinna być taka sama jak contract_type .fee_percentage atrybut dla tej umowy. fee_percentage atrybut zostanie użyty do obliczenia fee_amount kiedy wprowadzimy wartość w payment_amount atrybut.
fee_amount – Całkowita kwota opłaty, jaką obciążymy klienta za tę umowę.
date_signed – Data podpisania umowy.
start_date – Data, w której umowa zaczyna obowiązywać (np. umowa najmu lub dzierżawy).
end_date – Data wygaśnięcia umowy. Może być NULL w przypadku podpisania umowy bez daty końcowej. Jednak w większości przypadków będziemy znać end_date z góry.
transaction_id – Odwołuje się do transaction tabela, jeśli umowa jest częścią transakcji między dwoma klientami. Może zawierać wartości NULL, ponieważ nie będzie powiązanego rekordu transakcji, jeśli umowa jest bezpośrednio między nami a klientem.

under_contract tabela dotyczy umów i posiadłości. Obok głównego atrybutu klucza id , zawiera tylko dwa klucze obce, estate_id i contract_id . Ta para kluczy obcych tworzy również UNIKATOWY klucz tabeli.

Przechowujemy zapisy każdej wygenerowanej przez nas faktury na invoice stół. Jeśli klient dokona jednorazowej płatności za cały kontrakt, w tej tabeli będzie tylko jeden wpis dla tego kontraktu. To samo dotyczy sytuacji, gdy dokonujemy jednorazowej płatności na rzecz klienta. Jeśli klient (lub nasza firma) zdecyduje się płacić w ratach, liczba rekordów jest taka sama jak wartość w contract .number_of_invoices pole. Atrybuty w tej tabeli to:

contract_id – Identyfikator powiązanej umowy.
invoice_number – Unikalny wewnętrzny identyfikator faktury.
issued_by – Opis tekstowy wystawcy faktury. Kiedy wystawiamy fakturę, przechowujemy tutaj dane naszej firmy. Jeśli klient go wystawi, jego dane zostaną zapisane tutaj.
issued_to – Przeciwieństwo issued_by . Jeśli obciążymy klienta, to ten atrybut będzie zawierał jego dane; jeśli klient nas obciąża, nasze dane są przechowywane tutaj.
invoice_details – Wszystkie szczegóły pozycji faktury.
invoice_amount – Kwota należna na tej fakturze.
date_created – Rzeczywista data utworzenia faktury w naszym systemie.
billing_date – Data, kiedy faktura powinna zostać zapłacona.
date_paid – Faktyczna data zapłaty faktury. Może być NULL, dopóki faktura nie zostanie zapłacona.

Do opisywania umów użyjemy jeszcze dwóch słowników, contract_type i payment_frequency . contract_type_name pole służy do oznaczenia czynności jaką wykonujemy w umowie:„pośrednictwo (kupno)”, „pośrednictwo (sprzedaż)”, „pośrednictwo (wynajem)”, „pośrednictwo (leasing)”, „kupno (od klienta) ”, „sprzedaż (klientowi)”, „leasing (od klienta)” i „wynajem (klientowi)”. payment_frequency_name atrybut po prostu opisuje, jak często faktury będą generowane przez nas lub klienta. Może przechowywać wartości takie jak „raz”, „raz w miesiącu”, „raz na 2 miesiące” i „raz w roku”.

Jeśli nasza firma kupi lub wydzierżawi jakąś nieruchomość, zapłacimy klientowi. Oznacza to, że będziemy jedynymi na invoice .issued_to pole i będziemy musieli płacić faktury. Jeśli sprzedamy lub wynajmujemy nieruchomość, klient nam zapłaci, a my będziemy na invoice .issued_by pole.

Jeśli pośredniczymy w transakcji między dwoma klientami, pobieramy opłatę za nasze usługi. W takim przypadku podpiszemy dwie oddzielne umowy, jedną z klientem sprzedającym/wynajem, a drugą z klientem kupującym/wynajmującym. Połączymy te dwie umowy razem, przypisując ten sam transaction_id do obu. transaction tabela służy do przechowywania rekordów transakcji, w których pośredniczyliśmy. Atrybuty w tej tabeli to:

transaction_id – Unikalny identyfikator dla każdej transakcji.
transaction_type_id – Odwołuje się do transaction_type słownik.
client_offered – Odwołuje się do client tabela i oznacza, kto sprzedaje lub wynajmuje nieruchomość.
client_requested – Odwołuje się do client tabela i oznacza, kto kupuje lub dzierżawi nieruchomość.
transaction_date – Data faktycznej realizacji transakcji.
transaction_details – Wszystkie szczegóły związane z tą transakcją, przechowywane w nieustrukturyzowanym formacie tekstowym.

Ostatnia tabela w naszym modelu to transaction_type słownik. Wartości przechowywane w tej tabeli są przypisane do każdej transakcji zgodnie z tym, co to jest:„kupno/sprzedaż” lub „wynajem/leasing”.

Prowadzenie firmy zajmującej się nieruchomościami jest bardzo skomplikowane, wymagające, a nawet ryzykowne. Aby wszystko działało sprawnie, potrzebna jest duża organizacja. Mam nadzieję, że ten model danych pomógł Wam uświadomić sobie złożoność tego pola.

Jak zawsze istnieje wiele sposobów na ulepszenie tego modelu. Podziel się swoimi sugestiami i komentarzami.