Модел на данни за агенция за недвижими имоти

Освен местоположението, какво е необходимо, за да управлявате успешен бизнес с недвижими имоти? Разглеждаме модел на данни, за да помогнем на агенциите за недвижими имоти да останат организирани.

Купуването, продажбата и отдаването под наем на апартаменти или къщи днес е наистина голям бизнес. Повечето хора с удоволствие плащат такса и оставят професионална агенция за недвижими имоти да свърши работата вместо тях. От друга страна, компанията може да действа от свое име, купувайки имоти за препродажба или отдаване под наем. Компанията за недвижими имоти може също да отдаде имот под наем, след което да го отдаде под наем или пренаем и да реализира печалба от разликата.

Очевидно проследяването на имотите е важна част от управлението на бизнес с недвижими имоти. В същото време датите са еднакво важни. (напр. Кога ще стане достъпен апартамент под наем? Кога даден имот ще излезе на пазара?) В тази статия ще разгледаме модел на данни, който може да помогне на компаниите за недвижими имоти да останат организирани.

Често задавани въпроси за недвижими имоти

Преди да започнем да описваме модела и неговите очаквани данни, първо ще отговорим на някои въпроси, специфични за бизнеса с недвижими имоти. Недвижимите имоти имат много термини и пълното обяснение на неговия жаргон и принципи надхвърлят обхвата на тази статия, така че тук ще отговорим само на най-често срещаните и основни въпроси.

Какво може да се счита за имот или имот?

Когато мислим за недвижими имоти, първото изображение, което получаваме, често е къща или друго жилище. Недвижимите имоти са много повече от това. Сгради, офиси, земя, минерални ресурси и корпуси също попадат в тази категория. За целите на тази статия ще третирам всичко, което е „недвижимо“ като недвижим имот. Като казахме това, ще се съсредоточим главно върху жилищни сгради и къщи.
Къде се намира имението или имотът?

За къщи, сгради и апартаменти това е много просто. Ще знаем точния адрес, където се намира имота. Земята няма адрес, но нейната позиция се определя от поземлен регистър.
Какви данни трябва да съхраняваме?

В нашия модел трябва да съхраняваме всички имоти (т.е. недвижими имоти) и клиенти, с които работим. Тази информация ни е необходима, за да създаваме отчети, а също и да подобрим нашия бизнес.

Можем да очакваме, че ще общуваме често с клиенти, така че трябва да съхраняваме всичките им данни за контакт. Също така ще искаме да знаем кой служител се е свързал с клиента и какъв интерес е изразил клиентът по време на разговора.

За имоти се нуждаем от техните данни и текущо състояние на една ръка разстояние, за да можем бързо да отговорим на запитванията на потенциалните клиенти.

Ние също така ще съхраняваме нашата история на контактите и всички договори, свързани с клиенти или имоти.
Колко важни са датите?

Датите винаги са от решаващо значение, но искам да подчертая, че те са особено важни в недвижимите имоти. Трябва да знаем точното време, през което един от нашите имоти под наем е зает, за да можем да го наемем отново веднага щом стане наличен. Не може да има припокриване, когато двама клиенти наемат един и същ имот. Ако потенциален клиент изрази желание да наеме на определена бъдеща дата, ние трябва да съхраняваме тази информация и да получим напомняне, когато тази дата наближава.
Как трябва да изглежда нашето приложение?

За тази цел уеб приложение е най-доброто решение. Голяма част от работата с недвижими имоти е офис базирана, но агентите по продажбите трябва да могат да вмъкват нови данни, където и да се намират. Най-важната функционалност в нашето приложение е бързото търсене, което може да намери клиенти, имоти и статуси на имоти.

Моделът на данните

Нашият модел на данни за недвижими имоти се състои от три основни предметни области:

Estates and locations
Clients and contacts
Contracts and transactions

Има една маса, employee , което е извън която и да е тема.

Моля, имайте предвид, че employee и estate таблици в Clients and contacts предметната област и client таблица в Contracts and transactions предметната област са просто копия, използвани за опростяване на модела.

Ще разгледаме employee първо таблица, продължете с Estates and locations , преминете към Clients and contacts , и след това завършете с Contracts and transactions .

Таблица на служителите

Ще започнем с employee маса. Просто е:съхранява само first_name и last_name на всеки служител. Бихме могли да добавим други подробности като данъчен идентификационен номер на служителя, неговата дата на раждане, адрес, длъжност и т.н. Въпреки това, в този модел няма да се фокусираме върху служителите, така че всичко, от което се нуждаем, е начин да свържем служителите с действия (като приписване на задача или договор). Тази таблица също така ще ни позволи да запишем кой служител е участвал във всеки контакт с клиент.

Раздел 1:Имения и местоположения

Estates and location Темата съдържа шест таблици, които описват всички имоти (имоти), с които работим, тяхното местоположение и текущото им състояние.

Централната таблица в тази предметна област е estate маса. Той съдържа списък на всички имоти, с които сме, сме били или ще работим. Това включва имоти, за които посредничим между двама клиенти, тези, които притежаваме, всички, които сме продали или отдали под наем на клиенти, и всички, които сме наели или купили от клиенти. Той също така съхранява запис на имоти, с които планираме (или сме планирали) да правим бизнес.

Тъй като в тази статия се фокусираме главно върху апартаменти и къщи, атрибутите в тази таблица са свързани предимно с тях. Ако искаме да опишем други типове недвижими имоти, бихме могли да добавим допълнителни описателни атрибути с нула. Бихме могли също така просто да въведем тези стойности в estate_description атрибут. Атрибутите в estate таблицата са:

estate_name – Името на имението. Това може да бъде нашето вътрешно име за имот („Stoker house“) или добре известно публично име („Bran Castle“).
city_id – Идент. № на града, в който се намира имението.
estate_type_id – Препраща към estate_type речник.
floor_space и balconies_space – Размерът (в квадратни метри) на етажите на апартаментите и балконите.
number_of_balconies , number_of_bedrooms , number_of_garages и number_of_parking_spaces – Целочислени стойности за всяка категория. Разбира се.
pets_allowed – Булева стойност, обозначаваща дали са разрешени домашни любимци. Това се използва предимно за имоти под наем.
estate_description – Подробно описание на имот. Тук съхраняваме всякаква допълнителна информация, напр. история на собствеността.
estate_status_id – Ако имотът е наличен в момента или не. Ще използваме това поле в нашата функция за търсене.

Вече споменахме два речника, които estate таблицата се отнася до, estate_type и estate_status . И двата речника съдържат само ID и атрибут UNIQUE name.

В estate_type речник, ще съхраняваме стойности като „апартамент“, „къща“, „поле“ и т.н. estate_status таблицата ще има стойности, посочващи дали имотът в момента е наличен или не, като например „имот под наем“, „имот закупен“, „имот продаден“, „имот под наем“.

Ще дефинираме местоположението на всеки имот, не само по описание (estate . estate_description атрибут), но също и по неговата държава и град. За тази цел ще използваме две речникови таблици:country и city . Всяка държава е уникално дефинирана от country_name , който ще бъде единственият атрибут (различен от ID), съхранен в таблицата. От друга страна, всеки град има име и държава. Някои градове могат да имат едно и също име, но ще приемем, че името на всеки град е уникално за неговата страна – само една Виена, Австрия или Женева, Швейцария. Въпреки това, ако искаме да се предпазим от дублиране, можем да добавим атрибут за регион. Засега обаче ще оставим всичко както е. city_name – country_id pair е УНИКАЛНИЯ ключ на city таблица.

Последната таблица в тази тематична област е in_charge маса. Можем да очакваме, че всеки имот ще има поне един служител, който да се занимава с въпроси, свързани с него. Този служител отговаря за неща като комуникация с клиенти, показване на имота на потенциални клиенти и други административни и правни задачи. В in_charge таблица, ще имаме:

estate_id и employee_id – Външни ключове, които се отнасят съответно до свързаното имущество и клиента.
date_from и date_to – Интервалът, през който служителят е бил назначен в това имущество. Обърнете внимание, че „date_to“ може да бъде NULL, защото служител може да се грижи за имущество за неопределено време. Когато назначаваме служител в имот, трябва да се уверим, че той вече не е назначен към друг имот, като проверим за припокриващи се интервали от дати. От друга страна, можем да назначим много служители в едно и също имение едновременно. Това би било желателно, когато служителите имат различни роли, напр. един служител се грижи за комуникацията с клиентите, друг служител показва това имущество, друг се грижи за продажбите и правните договори и т.н.

Раздел 2:Клиенти и контакти

Client and contacts предметната област се състои само от две таблици, client таблица и contact маса. Двете други таблици, показани в тази област, employee:Clients and contacts и estate:Clients and contacts са просто копия.

client таблицата съдържа записи на всички клиенти, с които някога сме работили, включително настоящи и потенциални клиенти. Кой е потенциален клиент? Може да е някой, който е казал, че иска да продаде, купи или наеме някакъв имот от нас в бъдеще. Трябва да съхраняваме данни за контакт и свойства на такива клиенти за бъдеща употреба. Атрибутите в client таблицата са:

client_name – За физическо лице това поле съдържа неговото име и фамилия. Ако клиентът е юридическо лице, той притежава името на фирмата или юридическото лице.
client_address – Текстово описание на местоположението на клиента.
contact_person – Име и фамилия (и вероятно длъжност, ако клиентът е бизнес) на нашето лице за контакт.
phone , mobile и mail – Данни за връзка с клиента.
client_details – Всички други подробности, свързани с този клиент. Те се съхраняват в неструктуриран текстов формат.

Последните пет атрибута в тази таблица са нулеви, защото не са от решаващо значение. Вероятно ще трябва да съхраняваме информация за поне едно лице за контакт, но може да не знаем предварително кой ще бъде нашият контакт.

Втората и последна таблица в тази тематична област е contact маса. Тук ще съхраняваме данни за всяко взаимодействие, което сме имали с клиенти. Ще използваме тази информация, за да оптимизираме бъдещия си бизнес – например, ако клиент поиска да наеме определен имот от нас, когато стане наличен, трябва да съхраняваме това искане и да го информираме, когато имотът е готов. Атрибутите в таблицата са:

client_id – Идентификационният номер на клиента.
employee_id – Идентификационният номер на служителя, участващ в този контакт. Това може да бъде NULL, защото клиентът не може да се свързва с нито един отделен служител – напр. може би клиентът е изпратил имейл до акаунта на компанията. Все пак в повечето случаи можем да очакваме, че ще знаем кой служител е управлявал взаимодействието.
estate_id – ИД на свързаното имущество. Това е полезно, когато клиентът поиска определен имот или ако клиентът иска да продаде или отдаде под наем нещо, което вече имаме в нашата система.
contact_time – Времето, когато е осъществен контактът.
contact_details – Всички неструктурирани бележки, които искаме да запазим за този контакт. Можем да напишем нещо като „Клиентът изрази желание да закупи къща в <този> квартал.”

Раздел 3:Договори и транзакции

Последната предметна област в нашия модел е Contracts and transactions . Ще го използваме за свързване на имоти с клиенти.

Централната таблица на този раздел е contract маса. Там ще съхраняваме всички подробности за договора и ще свързваме договори с клиенти и служители. Атрибутите в тази таблица са:

client_id – Идент. № на клиента, подписал съответния договор.
employee_id – Идентификацията на служителя, подписал договора от името на нашата компания.
contract_type_id – Препраща contract_type речник и обозначава дали договорът се отнася до покупка, продажба, лизинг или отдаване под наем на имот.
contract_details – Подробно описание на контакта, съхранено в текстов формат.
payment_frequency_id – Препраща payment_frequency речник и определя интервалите, през които трябва да се изпращат фактури.
number_of_invoices – Броят на фактурите, които трябва да бъдат генерирани. Ако компанията плаща само веднъж, в този атрибут се съхранява стойност „1“ и целият payment_amount ще бъде равен на invoice_amount .
payment_amount – Общата платена сума.
fee_percentage – Процентът, който таксуваме от клиента. Например, можем да начислим 5% от продажната цена на къща като такса. Стойността в тази колона трябва да е същата като contract_type .fee_percentage атрибут за този договор. fee_percentage атрибутът ще се използва за изчисляване на fee_amount когато въвеждаме стойност в payment_amount атрибут.
fee_amount – Общата сума на таксата, която ще таксуваме от клиента за този договор.
date_signed – Датата, на която е подписан договорът.
start_date – Датата, на която договорът става валиден (например за договор за наем или лизинг).
end_date – Датата на изтичане на договора. Може да бъде NULL, в случай че подпишем договор, който няма крайна дата. В повечето случаи обаче ще знаем end_date предварително.
transaction_id – Препраща към transaction таблица, ако договорът е част от сделка между двама клиенти. Може да съдържа стойности NULL, защото няма да има свързан запис на транзакция, ако договорът е директно между нас и клиент.

under_contract таблицата се отнася до договори и имоти. До атрибута на първичния ключ id , съдържа само два външни ключа, estate_id и contract_id . Тази двойка външни ключове също формира УНИКАЛНИЯ ключ на таблицата.

Ще съхраняваме записи за всяка фактура, която сме генерирали в invoice маса. Ако клиентът направи еднократно плащане за целия договор, в тази таблица ще има само един запис за този договор. Същото важи и ако направим еднократно плащане към клиент. Ако клиентът (или нашата компания) избере да плаща на вноски, има същия брой записи като стойността в contract .number_of_invoices поле. Атрибутите в тази таблица са:

contract_id – Идент. № на съответния договор.
invoice_number – Уникален вътрешен идентификатор за фактурата.
issued_by – Текстово описание на издателя на фактурата. Когато издаваме фактура, тук ще съхраняваме данните за нашата компания. Ако клиентът го издаде, неговите данни ще бъдат съхранени тук.
issued_to – Обратното на issued_by . Ако таксуваме клиента, тогава този атрибут ще съдържа техните данни; ако клиентът ни таксува, нашите данни се съхраняват тук.
invoice_details – Всички данни за артикула на фактурата.
invoice_amount – Дължимата сума по тази фактура.
date_created – Действителната дата, на която фактурата е създадена в нашата система.
billing_date – Датата, на която трябва да бъде платена фактурата.
date_paid – Действителната дата на плащане на фактурата. Може да бъде NULL, докато фактурата не бъде платена.

Ще използваме още два речника, за да опишем договори, contract_type и payment_frequency . contract_type_name полето се използва за обозначаване на действието, което извършваме в договора:„посредничество (купуване)“, „посредничество (продажба)“, „посредничество (отдаване под наем)“, „посредничество (лизинг)“, „купуване (от клиент) “, „продажба (на клиент)”, „лизинг (от клиент)” и „отдаване под наем (на клиент)”. payment_frequency_name атрибут просто описва колко често ще се генерират фактури, било от нас, или от клиента. Може да съхранява стойности като „веднъж“, „веднъж на месец“, „веднъж на всеки 2 месеца“ и „веднъж годишно“.

Ако нашата компания купи или отдаде под наем някакъв имот, ние ще платим на клиента. Това означава, че ние ще бъдем този в invoice .issued_to поле и ще трябва да плащаме фактури. Ако продадем или наемем имот, клиентът ще ни плати и ние ще бъдем тези в invoice .issued_by поле.

Ако посредничим при сделка между двама клиенти, ще начислим такса за нашите услуги. В този случай ще подпишем два отделни договора, един с клиента за продажба/отдаване под наем и друг с клиента/купувача/наемателя. Ще свържем тези два договора заедно, като присвоим един и същ transaction_id и на двамата. transaction таблицата се използва за съхраняване на записи за сделки, които сме посредничили. Атрибутите в тази таблица са:

transaction_id – Уникален идентификатор за всяка транзакция.
transaction_type_id – Препраща transaction_type речник.
client_offered – Препраща към client таблица и обозначава кой продава или наема имот.
client_requested – Препраща към client таблица и обозначава кой купува или отдава имот.
transaction_date – Датата, на която транзакцията действително ще се случи.
transaction_details – Всички подробности, свързани с тази транзакция, съхранявани в неструктуриран текстов формат.

Крайната таблица в нашия модел е transaction_type речник. Стойностите, съхранени в тази таблица, се присвояват на всяка транзакция в зависимост от това какво представлява:„купуване/продажба” или „отдаване под наем/лизинг”.

Управлението на компания за недвижими имоти е много сложно, изискващо и дори рисковано. За да може всичко да работи гладко, е необходима голяма организация. Надявам се, че този модел на данни ви е помогнал да осъзнаете сложността на това поле.

Както винаги, има много начини за подобряване на този модел. Чувствайте се свободни да споделяте вашите предложения и коментари.