En Ejendomsmægler Data Model

Hvad skal der til, bortset fra beliggenhed, for at drive en succesfuld ejendomsmæglervirksomhed? Vi undersøger en datamodel for at hjælpe ejendomsmæglere med at holde sig organiseret.

At købe, sælge og leje lejligheder eller huse er en virkelig stor forretning i dag. De fleste betaler gerne et honorar og lader et professionelt ejendomsmæglerbureau gøre arbejdet for dem. På den anden side kunne virksomheden handle på egne vegne ved at købe ejendomme for at videresælge eller leje. Et ejendomsselskab kan også lease en ejendom og derefter leje eller fremleje den og få en fortjeneste på forskellen.

Det er klart, at holde styr på ejendomme er en vigtig del af at drive en ejendomsvirksomhed. Samtidig er datoer lige så vigtige. (f.eks. hvornår bliver en lejelejlighed ledig? Hvornår kommer et stykke ejendom på markedet?) I denne artikel tager vi et kig på en datamodel, der kan hjælpe ejendomsselskaber med at holde sig organiseret.

Ofte stillede spørgsmål om fast ejendom

Før vi begynder at beskrive modellen og dens forventede data, vil vi først besvare nogle spørgsmål, der er specifikke for en ejendomsmæglervirksomhed. Fast ejendom har mange udtryk, og en fuldstændig forklaring af dens jargon og principper går langt ud over denne artikels omfang, så vi besvarer kun de mest almindelige og grundlæggende spørgsmål her.

Hvad kan betragtes som et dødsbo eller en ejendom?

Når vi tænker på fast ejendom, er det første billede, vi får, ofte af et hus eller en anden bolig. Fast ejendom er meget mere end det. Bygninger, kontorer, jord, mineralressourcer og korps falder også i denne kategori. I forbindelse med denne artikel vil jeg behandle alt, der er "uflytbart" som fast ejendom. Når det er sagt, vil vi primært fokusere på lejlighedsbygninger og huse.
Hvor ligger godset eller ejendommen?

For huse, bygninger og lejligheder er dette meget enkelt. Vi kender den nøjagtige adresse, hvor ejendommen ligger. Jord har ikke en adresse, men dens position er defineret af et matrikelregister.
Hvilke data skal vi gemme?

I vores model skal vi opbevare alle de ejendomme (dvs. fast ejendom) og kunder, vi arbejder med. Vi har brug for disse oplysninger til at oprette rapporter og også for at forbedre vores forretning.

Vi kan forvente, at vi kommunikerer ofte med kunder, så vi skal gemme alle deres kontaktoplysninger. Vi vil også gerne vide, hvilken medarbejder der kontaktede klienten, og hvilken interesse klienten gav udtryk for under samtalen.

For ejendomme har vi brug for deres detaljer og aktuelle status lige ved hånden, så vi kan besvare potentielle kunders forespørgsler hurtigt.

Vi gemmer også vores kontakthistorik og eventuelle kontrakter relateret til enten kunder eller ejendomme.
Hvor vigtige er datoer?

Datoer er altid afgørende, men jeg vil gerne understrege, at de er særligt vigtige i fast ejendom. Vi har brug for at vide, hvor meget tid en af vores lejeboliger er optaget, så vi kan leje den igen, så snart den bliver ledig. Der kan ikke være nogen overlapning, når to kunder lejer den samme ejendom. Hvis en potentiel kunde udtrykker et ønske om at leje på en bestemt fremtidig dato, bør vi gemme disse oplysninger og få en påmindelse, når denne dato nærmer sig.
Hvordan skal vores ansøgning se ud?

Til dette formål er en webapplikation den bedste løsning. Meget af ejendomsarbejdet er kontorbaseret, men salgsagenter bør være i stand til at indsætte nye data, uanset hvor de er. Den vigtigste funktionalitet i vores app er en hurtig søgning, der kan finde kunder, ejendomme og ejendomsstatusser.

Datamodellen

Vores ejendomsdatamodel består af tre hovedfagområder:

Ejendomme og lokationer
Kunder og kontakter
Kontrakter og transaktioner

Der er én tabel, medarbejder , som er uden for ethvert fagområde.

Bemærk venligst, at medarbejderen og godset tabeller i Kunder og kontakter emneområdet og klienten tabellen i Kontrakter og transaktioner emneområdet er blot kopier, der bruges til at forenkle modellen.

Vi tager et kig på medarbejderen tabel først, fortsæt med Ejendomme og lokationer , flyt til Kunder og kontakter , og afslut derefter med Kontrakter og transaktioner .

Medarbejdertabellen

Vi starter med medarbejderen bord. Det er enkelt:det gemmer kun first_name og efternavn af hver medarbejder. Vi kunne tilføje andre detaljer såsom medarbejderens skatte-id-nummer, deres fødselsdato, adresse, jobrolle osv. Men i denne model fokuserer vi ikke på medarbejderne, så alt hvad vi behøver er en måde at forbinde medarbejdere med handlinger (som at blive tildelt en opgave eller kontrakt). Denne tabel vil også lade os registrere, hvilken medarbejder der deltog i hver kundekontakt.

Afsnit 1:Ejendomme og beliggenheder

Ejendomme og beliggenhed emneområdet indeholder seks tabeller, der beskriver alle ejendomme (ejendomme), vi arbejder med, deres placeringer og deres nuværende status.

Den centrale tabel i dette emneområde er ejendommen bord. Den indeholder en liste over alle de godser, vi er, var eller vil arbejde med. Dette omfatter ejendom, som vi mægler mellem to kunder, dem vi ejer, alle vi har solgt eller udlejet til kunder, og alle vi har leaset eller købt af kunder. Det fører også en fortegnelse over godser, som vi planlægger (eller havde planlagt) at gøre forretninger med.

Da vi hovedsageligt fokuserer på lejligheder og huse i denne artikel, er egenskaberne i denne tabel for det meste relateret til dem. Hvis vi gerne vil beskrive andre typer fast ejendom, kan vi tilføje yderligere nullable beskrivende attributter. Vi kunne også blot indtaste disse værdier i estate_description attribut. Attributterne i ejendommen tabellen er:

ejendomsnavn - Boets navn. Dette kan være vores interne navn for en ejendom ("Stoker house") eller et velkendt offentligt navn ("Bran Castle").
by_id – ID for den by, hvor godset ligger.
estate_type_id – Refererer til ejendomstype ordbog.
gulvplads og balkoner_rum – Størrelsen (i kvadratmeter) af lejlighedsgulve og altaner.
antal_af_balkoner , antal_soveværelser , antal_garager og antal_parkeringspladser – Heltalsværdier for hver kategori. Selvforklarende.
kæledyr_tilladt – En boolsk værdi, der angiver, om kæledyr er tilladt. Dette bruges mest til lejeboliger.
ejendomsbeskrivelse – En detaljeret beskrivelse af et dødsbo. Det er her vi gemmer eventuelle yderligere oplysninger, f.eks. ejendomshistorie.
estate_status_id – Om et dødsbo i øjeblikket er ledigt eller ej. Vi vil bruge dette felt i vores søgefunktion.

Vi har allerede nævnt to ordbøger, som ejendommen tabel henviser til ejendomstype og estate_status . Begge disse ordbøger indeholder kun et ID og en UNIKT navneattribut.

I ejendomstype ordbog, gemmer vi værdier som "lejlighed", "hus", "mark" osv. estate_status tabel vil have værdier, der angiver, om ejendommen er ledig i øjeblikket eller ej, såsom "ejendom udlejet", "ejendom købt", "ejendom solgt", "ejendom lejet".

Vi vil definere hver ejendoms placering, ikke kun ved beskrivelse (ejendommen . ejendomsbeskrivelse egenskab), men også efter dets land og by. Til dette formål vil vi bruge to ordbogstabeller:land og by . Hvert land er entydigt defineret af et country_name , som vil være den eneste attribut (udover ID), der er gemt i tabellen. På den anden side har hver by et navn og et land. Nogle byer kunne have det samme navn, men vi antager, at hver bys navn er unikt for sit land - kun én Wien, Østrig eller Genève, Schweiz. Men hvis vi ønsker at beskytte mod dubletter, kan vi tilføje en region-attribut. For nu vil vi dog lade alt være som det er. bynavn – country_id par er den UNIKKE nøgle til byen tabel.

Den sidste tabel i dette emneområde er in_charge bord. Vi kan forvente, at hvert dødsbo får tildelt mindst én medarbejder til at varetage sager vedrørende det. Denne medarbejder er ansvarlig for ting som at kommunikere med kunder, vise boet til potentielle kunder og andre administrative og juridiske opgaver. I in_charge tabel, har vi:

ejendoms-id og employee_id – Fremmednøgler, der refererer til henholdsvis det relaterede bo og klient.
dato_fra og dato_til – Intervallet, hvor medarbejderen blev henvist til det pågældende bo. Bemærk, at "dato_to" kan være NULL, fordi en medarbejder kan tage sig af et dødsbo på ubestemt tid. Når vi tildeler en medarbejder til et dødsbo, bør vi sikre os, at de ikke allerede er tildelt et andet dødsbo ved at kontrollere for overlappende datointervaller. Til gengæld kan vi ansætte mange medarbejdere til samme ejendom på samme tid. Dette vil være ønskeligt, når medarbejderne har forskellige roller, f.eks. en medarbejder tager sig af kundekommunikation, en anden medarbejder viser, at boet, en anden varetager salg og juridiske kontrakter osv.

Afsnit 2:Klienter og kontakter

Kunden og kontakter emneområdet består kun af to tabeller, klienten tabellen og kontaktpersonen bord. De to andre tabeller vist i dette område, medarbejder:klienter og kontakter og estate:klienter og kontakter er kun kopier.

klienten tabel indeholder optegnelser over alle de kunder, vi nogensinde har arbejdet med, inklusive nuværende og potentielle kunder. Hvem er en potentiel kunde? Det kan være nogen, der har sagt, at de ønsker at sælge, købe eller leje en ejendom hos os i fremtiden. Vi er nødt til at gemme sådanne kunders kontaktoplysninger og egenskaber til fremtidig brug. Attributterne i klienten tabellen er:

klientnavn – For en person indeholder dette felt deres for- og efternavn. Hvis kunden er en juridisk enhed, besidder den virksomhedens eller enhedsnavnet.
klientadresse – En tekstbeskrivelse af kundens placering.
kontaktperson – For- og efternavn (og sandsynligvis en stillingsbetegnelse, hvis kunden er en virksomhed) på vores kontaktperson.
telefon , mobil og mail – Kundens kontaktoplysninger.
client_details – Alle andre detaljer relateret til den pågældende klient. Disse gemmes i et ustruktureret tekstformat.

De sidste fem attributter i denne tabel er nullable, fordi de ikke er afgørende. Vi bliver sandsynligvis nødt til at gemme oplysninger for mindst én kontaktperson, men vi ved muligvis ikke på forhånd, hvem vores kontakt vil være.

Den anden og sidste tabel i dette emneområde er kontakten bord. Her gemmer vi data om hver interaktion, vi har haft med kunder. Vi bruger disse oplysninger til at optimere vores fremtidige forretning – hvis en kunde for eksempel anmoder om at leje en bestemt ejendom af os, når den bliver tilgængelig, bør vi gemme denne anmodning og informere dem, når boet er klar. Attributterne i tabellen er:

klient_id – ID'et på den involverede klient.
medarbejder-id – ID'et på den medarbejder, der er involveret i denne kontaktinstans. Dette kan være NULL, fordi en klient ikke må kontakte nogen enkelt medarbejder – f.eks. måske har kunden sendt en e-mail til virksomhedens konto. Alligevel kan vi i de fleste tilfælde forvente, at vi ved, hvilken medarbejder der håndterede en interaktion.
ejendoms-id – ID for det tilknyttede bo. Dette er nyttigt, når kunden beder om en bestemt ejendom, eller hvis kunden ønsker at sælge eller lease noget, vi allerede har i vores system.
kontakttid – Det tidspunkt, hvor kontakten fandt sted.
kontakt_detaljer – Eventuelle ustrukturerede noter, vi ønsker at gemme om den kontakt. Vi kan skrive noget i stil med "Kunden udtrykte ønske om at købe et hus i kvarter."

Afsnit 3:Kontrakter og transaktioner

Det sidste emneområde i vores model er Kontrakter og transaktioner . Vi vil bruge det til at relatere dødsboer til kunder.

Den centrale tabel i dette afsnit er kontrakten bord. Det er her, vi gemmer alle kontraktoplysninger og relaterer kontrakter med kunder og medarbejdere. Attributterne i denne tabel er:

klient_id – ID'et på den klient, der underskrev den relaterede kontrakt.
medarbejder-id – ID på den medarbejder, der underskrev kontrakten på vegne af vores virksomhed.
contract_type_id – Refererer til contract_type ordbog og angiver, om kontrakten vedrører køb, salg, leasing eller leje af ejendom.
contract_details – En detaljeret beskrivelse af kontakten, gemt i tekstformat.
payment_frequency_id – Refererer til betalingsfrekvensen ordbog og definerer intervallerne for, hvornår fakturaer skal sendes.
antal_af_fakturaer – Antallet af fakturaer, der skal genereres. Hvis virksomheden kun betaler én gang, gemmes værdien "1" i denne attribut og hele payment_amount vil være lig med invoice_amount .
betalingsbeløb – Det samlede beløb, der er betalt.
gebyr_procent – Den procentdel, vi opkræver kunden. For eksempel kan vi opkræve 5 % af et huss salgspris som et gebyr. Værdien i denne kolonne skal være den samme som contract_type .gebyr_procent egenskab for denne kontrakt. gebyr_procent attribut vil blive brugt til at beregne fee_amount når vi indtaster en værdi i payment_amount attribut.
gebyrbeløb – Det samlede gebyrbeløb, vi opkræver kunden for denne kontrakt.
dato_signeret – Datoen, hvor kontrakten blev underskrevet.
startdato – Den dato, hvor kontrakten bliver gyldig (f.eks. for en leje- eller leasingkontrakt).
slutdato – Den dato, hvor kontrakten udløber. Den kan være NULL, hvis vi underskriver en kontrakt, der ikke har nogen slutdato. Men i de fleste tilfælde kender vi end_date på forhånd.
transaktions-id –Referencer til transaktionen tabel, hvis kontrakten er en del af en transaktion mellem to kunder. Den kan indeholde NULL-værdier, fordi der ikke vil være en relateret transaktionspost, hvis kontrakten er direkte mellem os og en klient.

under_kontrakt tabel vedrører kontrakter og dødsboer. Ved siden af den primære nøgleattribut id , den indeholder kun to fremmednøgler, estate_id og contract_id . Dette fremmednøglepar danner også tabellens UNIKKE nøgle.

Vi gemmer registreringer af hver faktura, vi har genereret, i fakturaen bord. Hvis kunden foretager en enkelt betaling for hele kontrakten, vil der kun være én post i denne tabel for den pågældende kontrakt. Det samme gælder, hvis vi foretager en enkelt betaling til en kunde. Hvis kunden (eller vores virksomhed) vælger at betale i rater, er der det samme antal poster som værdien i kontrakten .antal_af_fakturaer Mark. Attributterne i denne tabel er:

kontrakt_id – ID'et for den relaterede kontrakt.
fakturanummer – En unik intern identifikator for fakturaen.
udstedt_af – En tekstbeskrivelse af fakturaudsteder. Når vi udsteder en faktura, gemmer vi vores virksomhedsoplysninger her. Hvis klienten udsteder det, vil deres oplysninger blive gemt her.
udstedt_til – Det modsatte af udstedt_af . Hvis vi debiterer kunden, vil denne attribut indeholde deres detaljer; hvis kunden debiterer os, så gemmes vores oplysninger her.
invoice_details – Alle fakturaelementoplysninger.
fakturabeløb – Det skyldige beløb på denne faktura.
dato_oprettet – Den faktiske dato, hvor fakturaen blev oprettet i vores system.
faktureringsdato – Den dato, hvor fakturaen skal betales.
dato_paid – Den faktiske dato, hvor fakturaen blev betalt. Den kan være NULL indtil fakturaen er betalt.

Vi vil bruge yderligere to ordbøger til at beskrive kontrakter, contract_type og betalingsfrekvens . contract_type_name feltet bruges til at angive den handling, vi udfører i kontrakten:"mægling (køb)", "mægling (sælger)", "mægling (udlejning)", "mægling (leasing)", "køb (fra en kunde) ”, ”sælge (til en kunde)”, ”leasing (fra en kunde)” og ”udleje (til en kunde)”. payment_frequency_name attribut beskriver blot, hvor ofte fakturaer vil blive genereret, enten af os eller kunden. Den kan gemme værdier som "en gang", "en gang om måneden", "en gang hver 2. måned" og "en gang om året".

Hvis vores virksomhed køber eller leaser en ejendom, betaler vi kunden. Det betyder, at vi er den ene i fakturaen .udstedt_til felt, og vi skal betale fakturaer. Hvis vi sælger eller lejer en ejendom, betaler kunden os, og vi vil være den, der står på fakturaen .udstedt af felt.

Hvis vi formidler en handel mellem to kunder, vil vi opkræve et gebyr for vores tjenester. I dette tilfælde underskriver vi to separate kontrakter, en med den sælgende/lejeklient og en anden med køber/lejerkunden. Vi knytter disse to kontrakter sammen ved at tildele den samme transaction_id til begge. transaktionen tabellen bruges til at gemme registreringer af aftaler, vi har formidlet. Attributterne i denne tabel er:

transaktions-id – Et unikt ID for hver transaktion.
transaction_type_id – Refererer til transaction_type ordbog.
client_offered – Henviser til klienten tabel og angiver, hvem der sælger eller lejer en ejendom.
client_requested – Henviser til klienten tabel og angiver, hvem der køber eller forpagter en ejendom.
transaktionsdato – Den dato, hvor transaktionen rent faktisk vil finde sted.
transaction_details – Alle detaljer relateret til den pågældende transaktion, gemt i et ustruktureret tekstformat.

Den sidste tabel i vores model er transaction_type ordbog. Værdier gemt i denne tabel tildeles hver transaktion i henhold til, hvad den er:"køb/salg" eller "udlejning/leasing".

At drive et ejendomsselskab er meget kompliceret, krævende og endda risikabelt. For at få alt til at fungere gnidningsløst er det nødvendigt med en hel del organisation. Jeg håber, at denne datamodel hjalp dig med at indse kompleksiteten af dette felt.

Som altid er der mange måder at forbedre denne model på. Del gerne dine forslag og kommentarer.