En fastighetsbyrådatamodell

Förutom platsen, vad krävs för att driva en framgångsrik fastighetsaffär? Vi undersöker en datamodell för att hjälpa fastighetsbyråer att hålla sig organiserade.

Att köpa, sälja och hyra lägenheter eller hus är en riktigt stor affär idag. De flesta betalar gärna en avgift och låter en professionell fastighetsmäklare göra jobbet åt dem. Å andra sidan kan företaget agera för egen räkning, köpa fastigheter för att sälja vidare eller hyra ut. Ett fastighetsbolag kan också hyra en fastighet och sedan hyra ut eller hyra ut den i andra hand och göra en vinst på mellanskillnaden.

Uppenbarligen är att hålla reda på fastigheter en viktig del av att driva en fastighetsverksamhet. Samtidigt är datum lika viktiga. (t.ex. När kommer en hyreslägenhet att bli tillgänglig? När kommer en fastighet att släppas ut på marknaden?) I den här artikeln ska vi ta en titt på en datamodell som kan hjälpa fastighetsbolag att hålla ordning.

Vanliga frågor om fastigheter

Innan vi börjar beskriva modellen och dess förväntade data kommer vi först att svara på några frågor som är specifika för en fastighetsaffär. Fastigheter har många termer och en fullständig förklaring av dess jargong och principer går långt utanför den här artikeln, så vi svarar bara på de vanligaste och grundläggande frågorna här.

Vad kan anses vara ett dödsbo eller en fastighet?

När vi tänker på fastigheter är den första bilden vi får ofta av ett hus eller någon annan bostad. Fastigheter är mycket mer än så. Även byggnader, kontor, mark, mineraltillgångar och kårer hör till denna kategori. För syftet med denna artikel kommer jag att behandla allt som är "orörbart" som fastigheter. Med det sagt kommer vi främst att fokusera på flerbostadshus och hus.
Var finns godset eller egendomen?

För hus, byggnader och lägenheter är detta mycket enkelt. Vi vet den exakta adressen där fastigheten ligger. Mark har ingen adress, men dess position definieras av ett fastighetsregister.
Vilken data behöver vi lagra?

I vår modell behöver vi lagra alla fastigheter (dvs fastigheter) och kunder vi arbetar med. Vi behöver denna information för att skapa rapporter och även för att förbättra vår verksamhet.

Vi kan förvänta oss att vi kommer att kommunicera ofta med kunder, så vi måste lagra alla deras kontaktuppgifter. Vi kommer också att vilja veta vilken medarbetare som kontaktade klienten och vilket intresse klienten uttryckte under samtalet.

För fastigheter behöver vi deras uppgifter och nuvarande status till hands så att vi snabbt kan svara på potentiella kunders förfrågningar.

Vi kommer också att lagra vår kontakthistorik och alla kontrakt relaterade till antingen kunder eller fastigheter.
Hur viktiga är datum?

Datum är alltid avgörande, men jag vill betona att de är särskilt viktiga inom fastigheter. Vi behöver veta exakt hur lång tid en av våra hyresfastigheter är upptagen så att vi kan hyra den igen så snart den blir tillgänglig. Det kan inte finnas någon överlappning när två kunder hyr samma fastighet. Om en potentiell kund uttrycker en önskan att hyra vid något specifikt framtida datum bör vi lagra den informationen och få en påminnelse när det datumet närmar sig.
Hur ska vår ansökan se ut?

För detta ändamål är en webbapplikation den bästa lösningen. Mycket av fastighetsarbetet är kontorsbaserat, men försäljningsagenter bör kunna infoga ny data var de än befinner sig. Den viktigaste funktionen i vår app är en snabb sökning som kan hitta kunder, fastigheter och fastighetsstatusar.

Datamodellen

Vår fastighetsdatamodell består av tre huvudområden:

Estates and locations
Clients and contacts
Contracts and transactions

Det finns en tabell, employee , som ligger utanför något ämnesområde.

Observera att employee och estate tabeller i Clients and contacts ämnesområde och client tabellen i Contracts and transactions ämnesområde är bara kopior som används för att förenkla modellen.

Vi ska ta en titt på employee tabell först, fortsätt med Estates and locations , flytta till Clients and contacts , och avsluta sedan med Contracts and transactions .

Medarbetartabellen

Vi börjar med employee tabell. Det är enkelt:det lagrar bara first_name och last_name av varje anställd. Vi skulle kunna lägga till andra detaljer som den anställdes skatte-ID-nummer, deras födelsedatum, adress, jobbroll, etc. Men i den här modellen kommer vi inte att fokusera på de anställda, så allt vi behöver är ett sätt att associera anställda med åtgärder (som att bli tilldelad en uppgift eller ett kontrakt). Denna tabell låter oss också registrera vilken anställd som deltog i varje kundkontakt.

Avsnitt 1:Gods och platser

Estates and location ämnesområdet innehåller sex tabeller som beskriver alla fastigheter (fastigheter) vi arbetar med, deras lägen och deras nuvarande status.

Den centrala tabellen i detta ämnesområde är estate tabell. Den innehåller en lista över alla gods vi är, var eller kommer att arbeta med. Detta inkluderar fastigheter för vilka vi förmedlar mellan två kunder, de som vi äger, alla vi har sålt eller hyrt ut till kunder och alla vi har leasat eller köpt av kunder. Den för också ett register över gods som vi planerar (eller hade planerat) att göra affärer med.

Eftersom vi huvudsakligen fokuserar på lägenheter och hus i den här artikeln, är attributen i den här tabellen mest relaterade till dem. Om vi skulle vilja beskriva andra typer av fastigheter kan vi lägga till ytterligare beskrivande nullattribut. Vi kan också helt enkelt ange dessa värden i estate_description attribut. Attributen i estate tabellen är:

estate_name – Godsets namn. Detta kan vara vårt interna namn för en fastighet ("Stoker house") eller ett välkänt offentligt namn ("Bran Castle").
city_id – ID för den stad där dödsboet ligger.
estate_type_id – Refererar till estate_type ordbok.
floor_space och balconies_space – Storleken (i kvadratmeter) på lägenhetsgolv och balkonger.
number_of_balconies , number_of_bedrooms , number_of_garages och number_of_parking_spaces – Heltalsvärden för varje kategori. Självförklarande.
pets_allowed – Ett booleskt värde som anger om husdjur är tillåtna. Detta används mest för hyresfastigheter.
estate_description – En detaljerad beskrivning av ett dödsbo. Det är här vi lagrar eventuell ytterligare information, t.ex. fastighetshistorik.
estate_status_id – Om ett dödsbo för närvarande finns tillgängligt eller inte. Vi kommer att använda det här fältet i vår sökfunktion.

Vi har redan nämnt två ordböcker som estate Tabell hänvisar till, estate_type och estate_status . Båda dessa ordböcker innehåller endast ett ID och ett UNIKT namnattribut.

I estate_type ordbok lagrar vi värden som "lägenhet", "hus", "fält" etc. estate_status Tabellen kommer att ha värden som anger om fastigheten för närvarande är tillgänglig eller inte, såsom "fastighet uthyrd", "fastighet köpt", "fastighet såld", "fastighet uthyrd".

Vi kommer att definiera varje egendoms plats, inte bara genom beskrivning (estate . estate_description attribut), men också av dess land och stad. För detta ändamål kommer vi att använda två ordbokstabeller:country och city . Varje land definieras unikt av ett country_name , vilket kommer att vara det enda attributet (förutom ID) som lagras i tabellen. Å andra sidan har varje stad ett namn och ett land. Vissa städer kan ha samma namn, men vi antar att varje stads namn är unikt för sitt land - bara en Wien, Österrike eller Genève, Schweiz. Men om vi vill skydda mot dubbletter kan vi lägga till ett regionattribut. För nu kommer vi dock att lämna allt som det är. city_name – country_id par är den UNIKA nyckeln för city bord.

Den sista tabellen i detta ämnesområde är in_charge tabell. Vi kan förvänta oss att varje dödsbo kommer att ha minst en anställd tilldelad att handlägga ärenden som rör det. Denna medarbetare är ansvarig för saker som att kommunicera med kunder, visa boet för potentiella kunder och andra administrativa och juridiska uppgifter. I in_charge tabell, vi har:

estate_id och employee_id – Utländska nycklar som hänvisar till tillhörande dödsbo respektive klient.
date_from och date_to – Intervallet då den anställde hänfördes till det dödsboet. Observera att "date_to" kan vara NULL eftersom en anställd kan ta hand om ett dödsbo på obestämd tid. När vi tilldelar en anställd till ett dödsbo bör vi se till att de inte redan är tilldelade ett annat dödsbo genom att kontrollera om det finns överlappande datumintervall. Å andra sidan kan vi anvisa många anställda till samma dödsbo samtidigt. Detta vore önskvärt när anställda har olika roller, t.ex. en anställd tar hand om kundkommunikation, en annan anställd visar att dödsbo, en annan sköter försäljning och juridiska avtal etc.

Avsnitt 2:Klienter och kontakter

Client and contacts Ämnesområdet består av endast två tabeller, client tabellen och contact tabell. De två andra tabellerna som visas i detta område, employee:Clients and contacts och estate:Clients and contacts är bara kopior.

client Tabellen innehåller register över alla kunder vi någonsin har arbetat med, inklusive nuvarande och potentiella kunder. Vem är en potentiell kund? Det kan vara någon som har sagt att de vill sälja, köpa eller hyra någon fastighet av oss i framtiden. Vi måste lagra sådana kunders kontaktuppgifter och egenskaper för framtida bruk. Attributen i client Tabellerna är:

client_name – För en individ innehåller detta fält deras för- och efternamn. Om kunden är en juridisk person innehar den företagets eller enhetens namn.
client_address – En textbeskrivning av kundens plats.
contact_person – För- och efternamn (och troligen en tjänstetitel om kunden är ett företag) på vår kontaktperson.
phone , mobile och mail – Kundens kontaktuppgifter.
client_details – Alla andra detaljer relaterade till den klienten. Dessa lagras i ett ostrukturerat textformat.

De sista fem attributen i den här tabellen är nullbara eftersom de inte är avgörande. Vi kommer förmodligen att behöva lagra information för minst en kontaktperson, men vi kanske inte vet i förväg vem vår kontakt kommer att vara.

Den andra och sista tabellen i detta ämnesområde är contact tabell. Här kommer vi att lagra data om varje interaktion vi har haft med kunder. Vi kommer att använda denna information för att optimera vår framtida verksamhet – om en kund till exempel ber om att hyra en viss fastighet av oss när den blir tillgänglig, bör vi lagra den förfrågan och informera dem när dödsboet är klart. Attributen i tabellen är:

client_id – ID för den inblandade klienten.
employee_id – ID för den anställde som var involverad i den kontaktinstansen. Detta kan vara NULL eftersom en kund inte får kontakta någon enskild anställd – t.ex. kanske har kunden skickat ett e-postmeddelande till företagskontot. Ändå kan vi i de flesta fall förvänta oss att vi vet vilken anställd som hanterade en interaktion.
estate_id – ID för tillhörande dödsbo. Detta är användbart när kunden frågar efter en viss fastighet eller om kunden vill sälja eller leasa något vi redan har i vårt system.
contact_time – Tidpunkten då kontakten ägde rum.
contact_details – Alla ostrukturerade anteckningar vi vill spara om den kontakten. Vi kanske skriver något i stil med "Kunden uttryckte önskan att köpa ett hus i grannskap."

Avsnitt 3:Kontrakt och transaktioner

Det sista ämnesområdet i vår modell är Contracts and transactions . Vi kommer att använda den för att relatera fastigheter till kunder.

Den centrala tabellen i detta avsnitt är contract tabell. Det är där vi lagrar alla kontraktsdetaljer och relaterar kontrakt med kunder och anställda. Attributen i den här tabellen är:

client_id – ID för kunden som undertecknade det relaterade avtalet.
employee_id – ID för den anställde som undertecknade avtalet på uppdrag av vårt företag.
contract_type_id – Refererar till contract_type ordbok och anger om avtalet avser köp, försäljning, leasing eller uthyrning av egendom.
contract_details – En detaljerad beskrivning av kontakten, lagrad i textformat.
payment_frequency_id – Refererar till payment_frequency ordbok och definierar intervallen när fakturor ska skickas.
number_of_invoices – Antalet fakturor som ska genereras. Om företaget bara betalar en gång lagras värdet "1" i detta attribut och hela payment_amount kommer att vara lika med invoice_amount .
payment_amount – Det totala beloppet som betalats.
fee_percentage – Den procentsats vi debiterar kunden. Till exempel kan vi ta ut 5 % av ett huss försäljningspris som en avgift. Värdet i den här kolumnen ska vara detsamma som contract_type .fee_percentage attribut för detta kontrakt. fee_percentage attribut kommer att användas för att beräkna fee_amount när vi anger ett värde i payment_amount attribut.
fee_amount – Det totala avgiftsbeloppet som vi debiterar kunden för detta kontrakt.
date_signed – Datum då avtalet undertecknades.
start_date – Datum då avtalet blir giltigt (t.ex. för ett hyres- eller hyreskontrakt).
end_date – Datum då avtalet löper ut. Det kan vara NULL om vi undertecknar ett kontrakt som inte har något slutdatum. Men i de flesta fall känner vi till end_date i förväg.
transaction_id – Refererar till transaction tabell om avtalet är en del av en transaktion mellan två kunder. Det kan innehålla NULL-värden eftersom det inte kommer att finnas en relaterad transaktionspost om kontraktet är direkt mellan oss och en kund.

under_contract Tabellen avser kontrakt och dödsbon. Bredvid primärnyckelattributet id , den innehåller bara två främmande nycklar, estate_id och contract_id . Detta främmande nyckelpar bildar också tabellens UNIKA nyckel.

Vi lagrar register över alla fakturor vi har genererat i invoice tabell. Om kunden gör en enda betalning för hela kontraktet kommer det bara att finnas en post i denna tabell för det kontraktet. Detsamma gäller om vi gör en engångsbetalning till en kund. Om kunden (eller vårt företag) väljer att delbetala finns samma antal poster som värdet i contract .number_of_invoices fält. Attributen i den här tabellen är:

contract_id – ID för det relaterade kontraktet.
invoice_number – En unik intern identifierare för fakturan.
issued_by – En textbeskrivning av fakturautfärdaren. När vi utfärdar en faktura lagrar vi våra företagsuppgifter här. Om klienten utfärdar det kommer deras uppgifter att lagras här.
issued_to – Motsatsen till issued_by . Om vi debiterar kunden kommer detta attribut att innehålla deras uppgifter; om kunden debiterar oss lagras våra uppgifter här.
invoice_details – Alla fakturaobjektdetaljer.
invoice_amount – Beloppet på denna faktura.
date_created – Det faktiska datumet då fakturan skapades i vårt system.
billing_date – Datum då fakturan ska betalas.
date_paid – Det faktiska datumet då fakturan betalades. Den kan vara NULL tills fakturan är betald.

Vi kommer att använda ytterligare två ordböcker för att beskriva kontrakt, contract_type och payment_frequency . contract_type_name fältet används för att beteckna den åtgärd vi utför i kontraktet:"förmedling (köp)", "förmedling (säljer)", "förmedling (uthyrning)", "förmedling (leasing)", "köp (från en kund) ”, ”sälja (till en kund)”, ”leasing (från en kund)” och ”uthyrning (till en kund)”. payment_frequency_name attribut beskriver helt enkelt hur ofta fakturor kommer att genereras, antingen av oss eller kunden. Den kan lagra värden som "en gång", "en gång per månad", "en gång varannan månad" och "en gång per år".

Om vårt företag köper eller arrenderar en del fastighet, betalar vi kunden. Det betyder att vi kommer att vara de i invoice .issued_to och vi måste betala fakturor. Om vi säljer eller hyr ut en dödsbo kommer kunden att betala oss och vi är den som står på invoice .issued_by fältet.

Om vi förmedlar en affär mellan två kunder kommer vi att ta ut en avgift för våra tjänster. I det här fallet kommer vi att underteckna två separata kontrakt, ett med den säljande/hyrande kunden och ett annat med köparen/hyresklienten. Vi kopplar samman dessa två kontrakt genom att tilldela samma transaction_id Till båda. transaction tabellen används för att lagra register över affärer vi har förmedlat. Attributen i den här tabellen är:

transaction_id – Ett unikt ID för varje transaktion.
transaction_type_id – Refererar till transaction_type ordbok.
client_offered – Refererar till client tabell och anger vem som säljer eller hyr ut en dödsbo.
client_requested – Refererar till client tabell och anger vem som köper eller arrenderar ett dödsbo.
transaction_date – Datumet då transaktionen faktiskt kommer att ske.
transaction_details – Alla detaljer relaterade till den transaktionen, lagrade i ett ostrukturerat textformat.

Den sista tabellen i vår modell är transaction_type lexikon. Värden som lagras i denna tabell tilldelas varje transaktion enligt vad den är:"köpa/sälja" eller "hyra/leasa".

Att driva ett fastighetsbolag är mycket komplicerat, krävande och till och med riskabelt. För att allt ska fungera smidigt krävs en hel del organisation. Jag hoppas att denna datamodell hjälpte dig att inse komplexiteten i detta område.

Som alltid finns det många sätt att förbättra denna modell. Dela gärna med dig av dina förslag och kommentarer.