Un modello di dati dell'agenzia immobiliare

Oltre alla posizione, cosa serve per gestire un'attività immobiliare di successo? Esaminiamo un modello di dati per aiutare le agenzie immobiliari a rimanere organizzate.

L'acquisto, la vendita e l'affitto di appartamenti o case è oggi un grande affare. La maggior parte delle persone è felice di pagare una quota e lasciare che un'agenzia immobiliare professionale faccia il lavoro per loro. D'altra parte, la società potrebbe agire per proprio conto, acquistando immobili da rivendere o affittare. Una società immobiliare può anche affittare una proprietà, quindi affittarla o subaffittarla e realizzare un profitto sulla differenza.

Ovviamente, tenere traccia delle proprietà è una parte importante della gestione di un'attività immobiliare. Allo stesso tempo, le date sono ugualmente importanti. (ad es. Quando sarà disponibile un appartamento in affitto? Quando verrà immesso sul mercato un immobile?) In questo articolo daremo un'occhiata a un modello di dati che può aiutare le società immobiliari a rimanere organizzate.

Domande frequenti sugli immobili

Prima di iniziare a descrivere il modello e i suoi dati attesi, risponderemo ad alcune domande specifiche per un'attività immobiliare. Il settore immobiliare ha molti termini e una spiegazione completa del suo gergo e dei suoi principi va ben oltre lo scopo di questo articolo, quindi qui risponderemo solo alle domande più comuni e basilari.

Cosa può essere considerato una proprietà o una proprietà?

Quando pensiamo al settore immobiliare, la prima immagine che otteniamo è spesso quella di una casa o di qualche altra abitazione. Il settore immobiliare è molto di più. Rientrano in questa categoria anche edifici, uffici, terreni, risorse minerarie e corpi. Ai fini di questo articolo, tratterò tutto ciò che è "immobile" come immobile. Detto questo, ci concentreremo principalmente su condomini e case.
Dove si trova la tenuta o la proprietà?

Per case, edifici e appartamenti questo è molto semplice. Sapremo l'indirizzo esatto in cui si trova la proprietà. Il terreno non ha un indirizzo, ma la sua posizione è definita da un catasto.
Quali dati dobbiamo archiviare?

Nel nostro modello, dobbiamo archiviare tutte le proprietà (cioè le proprietà immobiliari) e i clienti con cui lavoriamo. Abbiamo bisogno di queste informazioni per creare rapporti e anche per migliorare la nostra attività.

Possiamo aspettarci di comunicare frequentemente con i clienti, quindi dobbiamo memorizzare tutti i loro dettagli di contatto. Vorremo anche sapere quale dipendente ha contattato il cliente e quale interesse il cliente ha espresso durante la conversazione.

Per le proprietà, abbiamo bisogno dei loro dettagli e dello stato attuale a portata di mano in modo da poter rispondere rapidamente alle richieste dei potenziali clienti.

Conserveremo anche la nostra cronologia dei contatti e tutti i contratti relativi a clienti o proprietà.
Quanto sono importanti le date?

Le date sono sempre cruciali, ma voglio sottolineare che sono particolarmente importanti nel settore immobiliare. Abbiamo bisogno di conoscere la quantità esatta di tempo in cui una delle nostre proprietà in affitto è occupata in modo da poterla affittare di nuovo non appena sarà disponibile. Non ci possono essere sovrapposizioni quando due clienti affittano la stessa proprietà. Se un potenziale cliente esprime il desiderio di affittare in una data futura specifica, dovremmo archiviare tali informazioni e ricevere un promemoria quando tale data si avvicina.
Come dovrebbe essere la nostra applicazione?

A questo scopo, un'applicazione web è la soluzione migliore. Gran parte del lavoro immobiliare è in ufficio, ma gli agenti di vendita dovrebbero essere in grado di inserire nuovi dati ovunque si trovino. La funzionalità più importante della nostra app è una ricerca rapida in grado di trovare clienti, proprietà e stato delle proprietà.

Il modello dei dati

Il nostro modello di dati immobiliari è composto da tre aree tematiche principali:

Estates and locations
Clients and contacts
Contracts and transactions

C'è una tabella, employee , che è al di fuori di qualsiasi area tematica.

Tieni presente che il employee e il estate tabelle in Clients and contacts area tematica e il client tabella nella Contracts and transactions l'area tematica sono solo copie utilizzate per semplificare il modello.

Daremo un'occhiata al employee prima tabella, continua con Estates and locations , passa a Clients and contacts , quindi termina con Contracts and transactions .

Il tavolo dei dipendenti

Inizieremo con il employee tavolo. È semplice:memorizza solo il first_name e last_name di ogni dipendente. Potremmo aggiungere altri dettagli come il codice fiscale del dipendente, la sua data di nascita, l'indirizzo, il ruolo lavorativo, ecc. Tuttavia, in questo modello non ci concentreremo sui dipendenti, quindi tutto ciò di cui abbiamo bisogno è un modo per associare i dipendenti con azioni (come essere assegnato a un'attività o a un contratto). Questa tabella ci consentirà anche di registrare quale dipendente ha partecipato a ciascun contatto con il cliente.

Sezione 1:Tenute e posizioni

Le Estates and location l'area tematica contiene sei tabelle che descrivono tutte le proprietà (proprietà) con cui lavoriamo, le loro posizioni e il loro stato attuale.

La tabella centrale in questa area tematica è la estate tavolo. Contiene un elenco di tutte le proprietà con cui siamo, eravamo o lavoreremo con. Ciò include le proprietà per le quali facciamo da intermediario tra due clienti, quelli di nostra proprietà, quelli che abbiamo venduto o affittato a clienti e quelli che abbiamo affittato o acquistato dai clienti. Tiene anche un registro delle proprietà con cui pianifichiamo (o avevamo pianificato) di fare affari.

Poiché in questo articolo ci concentriamo principalmente su appartamenti e case, gli attributi in questa tabella sono per lo più correlati ad essi. Se volessimo descrivere altri tipi di proprietà immobiliari, potremmo aggiungere ulteriori attributi descrittivi nullable. Potremmo anche semplicemente inserire quei valori in estate_description attributo. Gli attributi nella estate tabella sono:

estate_name – Il nome della tenuta. Questo potrebbe essere il nostro nome interno per una proprietà ("Stoker house") o un noto nome pubblico ("Bran Castle").
city_id – L'ID della città in cui si trova la tenuta.
estate_type_id – Fa riferimento a estate_type dizionario.
floor_space e balconies_space – La dimensione (in metri quadrati) dei piani e dei balconi degli appartamenti.
number_of_balconies , number_of_bedrooms , number_of_garages e number_of_parking_spaces – Valori interi per ciascuna categoria. Autoesplicativo.
pets_allowed – Un valore booleano che indica se sono ammessi animali domestici. Viene utilizzato principalmente per le proprietà in affitto.
estate_description – Una descrizione dettagliata di un immobile. Qui è dove memorizziamo qualsiasi informazione aggiuntiva, ad es. storia della proprietà.
estate_status_id – Se un immobile è attualmente disponibile o meno. Useremo questo campo nella nostra funzione di ricerca.

Abbiamo già menzionato due dizionari che estate la tabella si riferisce a estate_type e estate_status . Entrambi questi dizionari contengono solo un ID e un attributo di nome UNIQUE.

Nel estate_type dizionario, memorizzeremo valori come "appartamento", "casa", "campo", ecc. Il estate_status la tabella conterrà i valori che indicano se la proprietà è attualmente disponibile o meno, ad esempio "immobile locato", "immobile acquistato", "immobile venduto", "immobile locato".

Definiremo la posizione di ciascuna tenuta, non solo tramite la descrizione (la estate . estate_description attributo), ma anche dal suo paese e città. A tale scopo, utilizzeremo due tabelle di dizionario:country e city . Ogni paese è definito in modo univoco da un country_name , che sarà l'unico attributo (diverso dall'ID) memorizzato nella tabella. D'altra parte, ogni città ha un nome e un paese. Alcune città potrebbero avere lo stesso nome, ma supponiamo che il nome di ogni città sia unico nel suo paese:solo una Vienna, in Austria o Ginevra, in Svizzera. Tuttavia, se vogliamo proteggerci dai duplicati, potremmo aggiungere un attributo regione. Per ora, però, lasceremo tutto così com'è. Il city_name – country_id pair è la chiave UNICA della city tabella.

L'ultima tabella in questa area tematica è il in_charge tavolo. Possiamo aspettarci che ogni patrimonio abbia almeno un dipendente assegnato a gestire le questioni ad esso relative. Questo dipendente è responsabile di cose come comunicare con i clienti, mostrare la proprietà ai potenziali clienti e altre attività amministrative e legali. Nel in_charge tabella, avremo:

estate_id e employee_id – Chiavi esterne che si riferiscono rispettivamente al relativo patrimonio e al cliente.
date_from e date_to – L'intervallo in cui il dipendente è stato assegnato a tale patrimonio. Si noti che "data_a" può essere NULL perché un dipendente potrebbe prendersi cura di un patrimonio a tempo indeterminato. Quando assegniamo un dipendente a una proprietà, dobbiamo assicurarci che non sia già assegnato a un'altra proprietà controllando la sovrapposizione di intervalli di date. D'altra parte, possiamo assegnare più dipendenti allo stesso patrimonio contemporaneamente. Ciò sarebbe auspicabile quando i dipendenti hanno ruoli diversi, ad es. un dipendente si occupa della comunicazione con il cliente, un altro dipendente mostra quella proprietà, un altro gestisce le vendite e i contratti legali, ecc.

Sezione 2:Clienti e contatti

Il Client and contacts l'area tematica è composta da due sole tabelle, il client tabella e il contact tavolo. Le altre due tabelle mostrate in quest'area, employee:Clients and contacts e estate:Clients and contacts sono solo copie.

Il client la tabella contiene i record di tutti i clienti con cui abbiamo lavorato, inclusi i clienti attuali e potenziali. Chi è un potenziale cliente? Potrebbe essere qualcuno che ha detto di voler vendere, acquistare o affittare una proprietà da noi in futuro. Abbiamo bisogno di memorizzare i dettagli di contatto e le proprietà di tali clienti per un uso futuro. Gli attributi nel client tabella sono:

client_name – Per un individuo, questo campo contiene il nome e il cognome. Se il cliente è una persona giuridica, detiene il nome della società o dell'entità.
client_address – Una descrizione testuale della posizione del cliente.
contact_person – Nome e cognome (e probabilmente un titolo professionale se il cliente è un'azienda) del nostro referente.
phone , mobile e mail – I dettagli di contatto del cliente.
client_details – Tutti gli altri dettagli relativi a quel cliente. Questi sono memorizzati in un formato di testo non strutturato.

Gli ultimi cinque attributi in questa tabella sono annullabili perché non sono cruciali. Probabilmente avremo bisogno di memorizzare le informazioni per almeno una persona di contatto, ma potremmo non sapere in anticipo chi sarà il nostro contatto.

La seconda e ultima tabella in questa area tematica è il contact tavolo. Qui memorizzeremo i dati su ogni interazione che abbiamo avuto con i clienti. Utilizzeremo queste informazioni per ottimizzare la nostra attività futura:ad esempio, se un cliente ci chiede di affittare un determinato immobile quando diventa disponibile, dovremmo archiviare tale richiesta e informarlo quando l'immobile è pronto. Gli attributi nella tabella sono:

client_id – L'ID del cliente coinvolto.
employee_id – L'ID del dipendente coinvolto nell'istanza di contatto. Questo può essere NULL perché un cliente potrebbe non contattare nessun singolo dipendente, ad es. forse il cliente ha inviato un'e-mail all'account aziendale. Tuttavia, nella maggior parte dei casi possiamo aspettarci di sapere quale dipendente ha gestito un'interazione.
estate_id – L'ID del relativo patrimonio. Questo è utile quando il cliente chiede una determinata proprietà o se vuole vendere o affittare qualcosa che abbiamo già nel nostro sistema.
contact_time – L'ora in cui è avvenuto il contatto.
contact_details – Eventuali note non strutturate che vogliamo salvare su quel contatto. Potremmo scrivere qualcosa come "Il cliente ha espresso il desiderio di acquistare una casa in quartiere".

Sezione 3:Contratti e transazioni

L'ultima area tematica del nostro modello è Contracts and transactions . Lo useremo per mettere in relazione le proprietà con i clienti.

La tabella centrale di questa sezione è il contract tavolo. È qui che memorizzeremo tutti i dettagli del contratto e collegheremo i contratti con clienti e dipendenti. Gli attributi in questa tabella sono:

client_id – L'ID del cliente che ha firmato il relativo contratto.
employee_id – L'ID del dipendente che ha firmato il contratto per conto della nostra azienda.
contract_type_id – Fa riferimento al contract_type dizionario e indica se il contratto riguarda l'acquisto, la vendita, la locazione o l'affitto di proprietà.
contract_details – Una descrizione dettagliata del contatto, memorizzata in formato testo.
payment_frequency_id – Fa riferimento al payment_frequency dizionario e definisce gli intervalli di invio delle fatture.
number_of_invoices – Il numero di fatture da generare. Se l'azienda paga una sola volta, in questo attributo viene memorizzato un valore "1" e l'intero payment_amount sarà uguale a invoice_amount .
payment_amount – L'importo totale pagato.
fee_percentage – La percentuale che addebitiamo al cliente. Ad esempio, potremmo addebitare il 5% del prezzo di vendita di una casa come commissione. Il valore in questa colonna dovrebbe essere lo stesso di contract_type .fee_percentage attributo per questo contratto. Il fee_percentage verrà utilizzato per calcolare il fee_amount quando inseriamo un valore in payment_amount attributo.
fee_amount – L'importo totale della commissione che addebiteremo al cliente per questo contratto.
date_signed – La data in cui è stato firmato il contratto.
start_date – La data in cui il contratto diventa valido (ad es. per un contratto di locazione o locazione).
end_date – La data di scadenza del contratto. Può essere NULL nel caso in cui firmiamo un contratto che non ha una data di fine. Tuttavia, nella maggior parte dei casi conosceremo il end_date in anticipo.
transaction_id –Fa riferimento alla transaction tabella se il contratto fa parte di una transazione tra due clienti. Può contenere valori NULL perché non ci sarà un record di transazione correlato se il contratto è direttamente tra noi e un cliente.

Il under_contract la tabella si riferisce a contratti e patrimoni. Accanto all'attributo della chiave primaria id , contiene solo due chiavi esterne, estate_id e contract_id . Questa coppia di chiavi esterne costituisce anche la chiave UNICA della tabella.

Conserveremo i record di ogni fattura che abbiamo generato nella invoice tavolo. Se il cliente effettua un unico pagamento per l'intero contratto, ci sarà un solo record in questa tabella per quel contratto. Lo stesso vale se effettuiamo un unico pagamento a un cliente. Se il cliente (o la nostra azienda) sceglie di pagare a rate, c'è lo stesso numero di record del valore nel contract .number_of_invoices campo. Gli attributi in questa tabella sono:

contract_id – L'ID del relativo contratto.
invoice_number – Un identificatore interno univoco per la fattura.
issued_by – Una descrizione testuale dell'emittente della fattura. Quando emettiamo una fattura, memorizzeremo i dettagli della nostra azienda qui. Se il cliente lo emette, i suoi dettagli verranno archiviati qui.
issued_to – L'opposto di issued_by . Se addebitiamo il cliente, questo attributo conterrà i suoi dettagli; se il cliente ci addebita, i nostri dettagli vengono archiviati qui.
invoice_details – Tutti i dettagli dell'elemento della fattura.
invoice_amount – L'importo dovuto su questa fattura.
date_created – La data effettiva di creazione della fattura nel nostro sistema.
billing_date – La data di pagamento della fattura.
date_paid – La data effettiva di pagamento della fattura. Può essere NULL fino al pagamento della fattura.

Useremo altri due dizionari per descrivere i contratti, contract_type e payment_frequency . Il contract_type_name il campo è utilizzato per indicare l'azione che stiamo eseguendo nel contratto:"mediazione (acquisto)", "mediazione (vendita)", "mediazione (affitto)", "mediazione (affitto)", "acquisto (da un cliente) ”, “vendita (a un cliente)”, ”locazione (da un cliente)” e “affitto (a un cliente)”. Il payment_frequency_name l'attributo descrive semplicemente la frequenza con cui verranno generate le fatture, da noi o dal cliente. Può memorizzare valori come "una volta", "una volta al mese", "una volta ogni 2 mesi" e "una volta all'anno".

Se la nostra azienda acquista o affitta una proprietà, pagheremo il cliente. Ciò significa che saremo noi nella invoice .issued_to campo e dovremo pagare le fatture. Se vendiamo o affittiamo un immobile, il cliente ci pagherà e noi saremo quello nella invoice .issued_by campo.

Se mediamo un accordo tra due clienti, addebiteremo una commissione per i nostri servizi. In questo caso, firmeremo due contratti separati, uno con il cliente venditore/affittuario e un altro con il cliente acquirente/affittuario. Metteremo in relazione questi due contratti assegnando lo stesso transaction_id A entrambi. La transaction la tabella viene utilizzata per archiviare i record delle offerte che abbiamo mediato. Gli attributi in questa tabella sono:

transaction_id – Un ID univoco per ogni transazione.
transaction_type_id – Fa riferimento al transaction_type dizionario.
client_offered – Fa riferimento al client tabella e indica chi sta vendendo o affittando un immobile.
client_requested – Fa riferimento al client tabella e indica chi sta acquistando o affittando un immobile.
transaction_date – La data in cui avverrà effettivamente la transazione.
transaction_details – Tutti i dettagli relativi a tale transazione, archiviati in un formato di testo non strutturato.

Il tavolo finale nel nostro modello è il transaction_type dizionario. I valori memorizzati in questa tabella vengono assegnati a ciascuna transazione in base a cosa sia:“acquisto/vendita” o “affitto/affitto”.

Gestire una società immobiliare è molto complicato, impegnativo e persino rischioso. Affinché tutto funzioni senza intoppi, è necessaria una grande organizzazione. Spero che questo modello di dati ti abbia aiutato a realizzare la complessità di questo campo.

Come sempre, ci sono molti modi per migliorare questo modello. Sentiti libero di condividere i tuoi suggerimenti e commenti.