Un modèle de données d'agence immobilière

Outre l'emplacement, que faut-il pour gérer une entreprise immobilière prospère? Nous examinons un modèle de données pour aider les agences immobilières à rester organisées.

Acheter, vendre et louer des appartements ou des maisons est aujourd'hui une activité très importante. La plupart des gens sont heureux de payer des frais et de laisser une agence immobilière professionnelle faire le travail à leur place. D'autre part, la société pourrait agir en son propre nom, en achetant des propriétés pour les revendre ou les louer. Une société immobilière peut également louer un bien immobilier puis le louer ou le sous-louer et réaliser un bénéfice sur la différence.

De toute évidence, le suivi des propriétés est un élément important de la gestion d'une entreprise immobilière. Dans le même temps, les dates sont tout aussi importantes. (par exemple, quand un appartement en location va-t-il devenir disponible ? Quand un bien va-t-il être mis sur le marché ?) Dans cet article, nous examinerons un modèle de données qui peut aider les sociétés immobilières à rester organisées.

FAQ sur l'immobilier

Avant de commencer à décrire le modèle et ses données attendues, nous allons d'abord répondre à quelques questions spécifiques à une entreprise immobilière. L'immobilier a de nombreux termes et une explication complète de son jargon et de ses principes va bien au-delà de la portée de cet article, nous ne répondrons donc ici qu'aux questions les plus courantes et les plus élémentaires.

Qu'est-ce qui peut être considéré comme un domaine ou une propriété ?

Quand on pense à l'immobilier, la première image qui nous vient est souvent celle d'une maison ou d'une autre habitation. L'immobilier est bien plus que cela. Les bâtiments, les bureaux, les terrains, les ressources minérales et les corps entrent également dans cette catégorie. Aux fins de cet article, je traiterai tout ce qui est « inamovible » comme un bien immobilier. Cela dit, nous nous concentrerons principalement sur les immeubles d'habitation et les maisons.
Où se trouve le domaine ou la propriété ?

Pour les maisons, les immeubles et les appartements, c'est très simple. Nous connaîtrons l'adresse exacte où se trouve la propriété. Le terrain n'a pas d'adresse, mais sa position est définie par un cadastre.
De quelles données devons-nous stocker ?

Dans notre modèle, nous devons stocker tous les domaines (c'est-à-dire les biens immobiliers) et les clients avec lesquels nous travaillons. Nous avons besoin de ces informations pour créer des rapports et aussi pour améliorer notre activité.

Nous pouvons nous attendre à communiquer fréquemment avec les clients, nous devons donc stocker toutes leurs coordonnées. Nous voudrons également savoir quel employé a contacté le client et quel intérêt le client a exprimé au cours de la conversation.

Pour les propriétés, nous avons besoin de leurs détails et de leur état actuel à portée de main afin de pouvoir répondre rapidement aux demandes des clients potentiels.

Nous conserverons également notre historique de contacts et tous les contrats liés aux clients ou aux propriétés.
Quelle est l'importance des dates ?

Les dates sont toujours cruciales, mais je tiens à souligner qu'elles sont particulièrement importantes dans l'immobilier. Nous avons besoin de connaître la durée exacte d'occupation d'un de nos biens locatifs afin de pouvoir le relouer dès qu'il sera disponible. Il ne peut y avoir de cumul lorsque deux clients louent le même bien. Si un client potentiel exprime le désir de louer à une date ultérieure précise, nous devons stocker ces informations et recevoir un rappel lorsque cette date approche.
À quoi devrait ressembler notre application ?

Pour cela, une application web est la meilleure solution. Une grande partie du travail immobilier se fait au bureau, mais les agents commerciaux devraient pouvoir insérer de nouvelles données où qu'ils se trouvent. La fonctionnalité la plus importante de notre application est une recherche rapide qui peut trouver des clients, des propriétés et des statuts de propriété.

Le modèle de données

Notre modèle de données immobilières se compose de trois domaines principaux :

Estates and locations
Clients and contacts
Contracts and transactions

Il y a une table, employee , c'est-à-dire en dehors de tout domaine.

Veuillez noter que le employee et le estate tableaux dans les Clients and contacts le domaine et le client tableau dans le Contracts and transactions domaine ne sont que des copies utilisées pour simplifier le modèle.

Nous allons jeter un œil au employee tableau d'abord, continuez avec Estates and locations , passez à Clients and contacts , puis terminez avec Contracts and transactions .

Le tableau des employés

Nous allons commencer par le employee table. C'est simple :il ne stocke que le first_name et last_name de chaque employé. Nous pourrions ajouter d'autres détails comme le numéro d'identification fiscale de l'employé, sa date de naissance, son adresse, sa fonction, etc. Cependant, dans ce modèle, nous ne nous concentrerons pas sur les employés, donc tout ce dont nous avons besoin est un moyen d'associer les employés à actions (comme être affecté à une tâche ou à un contrat). Ce tableau nous permettra également d'enregistrer quel employé a participé à chaque contact client.

Section 1 :Domaines et emplacements

Les Estates and location Le domaine contient six tableaux qui décrivent tous les domaines (propriétés) avec lesquels nous travaillons, leurs emplacements et leur statut actuel.

La table centrale dans ce domaine est le estate table. Il contient une liste de tous les domaines avec lesquels nous travaillons, avons travaillé ou travaillerons. Cela inclut les domaines pour lesquels nous assurons la médiation entre deux clients, ceux que nous possédons, ceux que nous avons vendus ou loués à des clients et ceux que nous avons loués ou achetés à des clients. Il tient également un registre des successions avec lesquelles nous prévoyons (ou avions prévu) de faire affaire.

Étant donné que nous nous concentrons principalement sur les appartements et les maisons dans cet article, les attributs de ce tableau leur sont principalement liés. Si nous souhaitons décrire d'autres types de biens immobiliers, nous pourrions ajouter des attributs descriptifs nullables supplémentaires. Nous pourrions aussi simplement entrer ces valeurs dans le estate_description attribut. Les attributs du estate le tableau sont :

estate_name – Le nom du domaine. Il peut s'agir du nom interne d'une propriété ("Stoker house") ou d'un nom public bien connu ("Bran Castle").
city_id – L'identifiant de la ville où se situe le domaine.
estate_type_id – Fait référence au estate_type dictionnaire.
floor_space et balconies_space – La taille (en mètres carrés) des étages et des balcons des appartements.
number_of_balconies , number_of_bedrooms , number_of_garages et number_of_parking_spaces – Valeurs entières pour chaque catégorie. Indéniable.
pets_allowed – Une valeur booléenne indiquant si les animaux domestiques sont autorisés. Ceci est principalement utilisé pour les propriétés locatives.
estate_description – Une description détaillée d'un bien. C'est ici que nous stockons toute information supplémentaire, par ex. historique de la propriété.
estate_status_id – Si un domaine est actuellement disponible ou non. Nous utiliserons ce champ dans notre fonction de recherche.

Nous avons déjà mentionné deux dictionnaires que le estate la table fait référence à, estate_type et estate_status . Ces deux dictionnaires contiennent uniquement un ID et un attribut de nom UNIQUE.

Dans le estate_type dictionnaire, nous stockerons des valeurs telles que "appartement", "maison", "terrain", etc. Le estate_status Le tableau contiendra des valeurs indiquant si la propriété est actuellement disponible ou non, telles que « domaine loué », « domaine acheté », « domaine vendu », « domaine loué ».

Nous définirons l'emplacement de chaque domaine, pas seulement par la description (le estate . estate_description attribut), mais aussi par son pays et sa ville. Pour cela, nous utiliserons deux tables de dictionnaire :country et city . Chaque pays est défini de manière unique par un country_name , qui sera le seul attribut (autre que ID) stocké dans la table. D'autre part, chaque ville a un nom et un pays. Certaines villes pourraient avoir le même nom, mais nous supposerons que le nom de chaque ville est unique à son pays - un seul Vienne, Autriche ou Genève, Suisse. Cependant, si nous voulons nous protéger contre les doublons, nous pourrions ajouter un attribut de région. Pour l'instant, cependant, nous allons tout laisser tel quel. Le city_name – country_id pair est la clé UNIQUE de la city tableau.

Le dernier tableau de ce domaine est le in_charge table. On peut s'attendre à ce que chaque domaine ait au moins un employé affecté à la gestion des affaires qui s'y rapportent. Cet employé est responsable de choses telles que la communication avec les clients, la présentation de la succession à des clients potentiels et d'autres tâches administratives et juridiques. Dans le in_charge table, nous aurons :

estate_id et employee_id – Clés étrangères faisant référence au domaine et au client associés, respectivement.
date_from et date_to – L'intervalle au cours duquel l'employé a été affecté à cette succession. Notez que "date_to" peut être NULL car un employé peut s'occuper d'une succession indéfiniment. Lorsque nous affectons un employé à une succession, nous devons nous assurer qu'il n'est pas déjà affecté à une autre succession en vérifiant les intervalles de dates qui se chevauchent. D'autre part, nous pouvons affecter plusieurs employés au même domaine en même temps. Cela serait souhaitable lorsque les employés ont des rôles différents, par ex. un employé s'occupe de la communication avec le client, un autre s'occupe de la succession, un autre s'occupe des ventes et des contrats juridiques, etc.

Section 2 :Clients et contacts

Le Client and contacts le domaine se compose de seulement deux tables, le client table et le contact table. Les deux autres tableaux affichés dans cette zone, employee:Clients and contacts et estate:Clients and contacts ne sont que des copies.

Le client table contient des enregistrements de tous les clients avec lesquels nous avons travaillé, y compris les clients actuels et potentiels. Qui est un client potentiel ? Il peut s'agir de quelqu'un qui a déclaré vouloir vendre, acheter ou louer une propriété chez nous à l'avenir. Nous devons stocker les coordonnées et les propriétés de ces clients pour une utilisation future. Les attributs dans le client table sont :

client_name – Pour un individu, ce champ contient son prénom et son nom. Si le client est une personne morale, il détient le nom de la société ou de l'entité.
client_address – Une description textuelle de l'emplacement du client.
contact_person – Nom et prénom (et probablement une fonction si le client est une entreprise) de notre personne de contact.
phone , mobile et mail – Les coordonnées du client.
client_details – Tous les autres détails liés à ce client. Ceux-ci sont stockés dans un format texte non structuré.

Les cinq derniers attributs de ce tableau acceptent les valeurs NULL car ils ne sont pas cruciaux. Nous aurons probablement besoin de stocker des informations pour au moins une personne de contact, mais nous ne savons peut-être pas à l'avance qui sera notre contact.

Le deuxième et dernier tableau de ce domaine est le contact table. Ici, nous stockerons des données sur chaque interaction que nous avons eue avec les clients. Nous utiliserons ces informations pour optimiser nos activités futures - par exemple, si un client nous demande de louer un certain domaine dès qu'il devient disponible, nous devons stocker cette demande et l'informer lorsque le domaine est prêt. Les attributs du tableau sont :

client_id – L'identifiant du client concerné.
employee_id – L'ID de l'employé impliqué dans cette instance de contact. Cela peut être NULL parce qu'un client ne peut pas contacter un employé individuel - par ex. peut-être que le client a envoyé un e-mail au compte de l'entreprise. Néanmoins, dans la plupart des cas, nous pouvons nous attendre à savoir quel employé a géré une interaction.
estate_id – L'identifiant du domaine concerné. Ceci est utile lorsque le client demande une certaine propriété ou s'il souhaite vendre ou louer quelque chose que nous avons déjà dans notre système.
contact_time – L'heure à laquelle le contact a eu lieu.
contact_details – Toutes les notes non structurées que nous souhaitons enregistrer à propos de ce contact. Nous pourrions écrire quelque chose comme "Le client a exprimé le désir d'acheter une maison dans quartier."

Section 3 :Contrats et transactions

Le dernier domaine de notre modèle est Contracts and transactions . Nous l'utiliserons pour relier les successions aux clients.

Le tableau central de cette section est le contract table. C'est là que nous stockons tous les détails du contrat et que nous relions les contrats avec les clients et les employés. Les attributs de ce tableau sont :

client_id – L'identifiant du client qui a signé le contrat associé.
employee_id – L'identifiant de l'employé qui a signé le contrat au nom de notre société.
contract_type_id – Fait référence au contract_type dictionnaire et indique si le contrat concerne l'achat, la vente, le crédit-bail ou la location d'un bien.
contract_details – Une description détaillée du contact, stockée au format texte.
payment_frequency_id – Fait référence au payment_frequency dictionnaire et définit les intervalles d'envoi des factures.
number_of_invoices – Le nombre de factures à générer. Si l'entreprise ne paie qu'une seule fois, une valeur de "1" est stockée dans cet attribut et l'intégralité du payment_amount sera égal au invoice_amount .
payment_amount – Le montant total payé.
fee_percentage – Le pourcentage que nous facturons au client. Par exemple, nous pouvons facturer 5 % du prix de vente d'une maison à titre de frais. La valeur de cette colonne doit être identique à contract_type .fee_percentage attribut pour ce contrat. Le fee_percentage l'attribut sera utilisé pour calculer le fee_amount lorsque nous saisissons une valeur dans le payment_amount attribut.
fee_amount – Le montant total des frais que nous facturerons au client pour ce contrat.
date_signed – La date à laquelle le contrat a été signé.
start_date – La date à laquelle le contrat devient valide (par exemple pour un contrat de location ou de bail).
end_date – La date d'expiration du contrat. Il peut être NULL si nous signons un contrat sans date de fin. Cependant, dans la plupart des cas, nous connaîtrons la end_date à l'avance.
transaction_id –Référence la transaction tableau si le contrat fait partie d'une transaction entre deux clients. Il peut contenir des valeurs NULL car il n'y aura pas d'enregistrement de transaction associé si le contrat est directement entre nous et un client.

Le under_contract tableau relie les contrats et les successions. À côté de l'attribut de clé primaire id , il ne contient que deux clés étrangères, estate_id et contract_id . Cette paire de clés étrangères constitue également la clé UNIQUE de la table.

Nous conserverons les enregistrements de chaque facture que nous avons générée dans la invoice table. Si le client effectue un paiement unique pour l'ensemble du contrat, il n'y aura qu'un seul enregistrement dans ce tableau pour ce contrat. Il en va de même si nous effectuons un paiement unique à un client. Si le client (ou notre société) choisit de payer en plusieurs fois, il y a le même nombre d'enregistrements que la valeur dans le contract .number_of_invoices domaine. Les attributs de ce tableau sont :

contract_id – L'identifiant du contrat associé.
invoice_number – Un identifiant interne unique pour la facture.
issued_by – Une description textuelle de l'émetteur de la facture. Lorsque nous émettons une facture, nous stockons les détails de notre entreprise ici. Si le client l'émet, ses coordonnées seront stockées ici.
issued_to – Le contraire de issued_by . Si nous facturons le client, cet attribut contiendra ses coordonnées ; si le client nous facture, nos coordonnées sont stockées ici.
invoice_details – Tous les détails de l'article de facture.
invoice_amount – Le montant dû sur cette facture.
date_created – La date réelle à laquelle la facture a été créée dans notre système.
billing_date – La date à laquelle la facture doit être payée.
date_paid – La date réelle à laquelle la facture a été payée. Il peut être NULL jusqu'à ce que la facture soit payée.

Nous utiliserons deux autres dictionnaires pour décrire les contrats, contract_type et payment_frequency . Le contract_type_name champ est utilisé pour indiquer l'action que nous réalisons dans le contrat :"médiation (achat)", "médiation (vente)", "médiation (location)", "médiation (location)", "achat (d'un client) », « vendre (à un client) », « louer (à un client) » et « louer (à un client) ». Le payment_frequency_name L'attribut décrit simplement la fréquence à laquelle les factures seront générées, soit par nous, soit par le client. Il peut stocker des valeurs telles que "une fois", "une fois par mois", "une fois tous les 2 mois" et "une fois par an".

Si notre société achète ou loue une propriété, nous paierons le client. Cela signifie que nous serons celui sur la invoice .issued_to champ et nous devrons payer des factures. Si nous vendons ou louons un bien, le client nous paiera et nous serons celui sur la invoice .issued_by champ.

Si nous négocions un accord entre deux clients, nous facturons des frais pour nos services. Dans ce cas, nous signerons deux contrats distincts, un avec le client vendeur/locataire et un autre avec le client acheteur/locataire. Nous allons relier ces deux contrats ensemble en attribuant le même transaction_id aux deux. La transaction La table est utilisée pour stocker les enregistrements des transactions que nous avons négociées. Les attributs de ce tableau sont :

transaction_id – Un identifiant unique pour chaque transaction.
transaction_type_id – Référence le transaction_type dictionnaire.
client_offered – Référence le client tableau et indique qui vend ou loue un domaine.
client_requested – Référence le client tableau et indique qui achète ou loue un domaine.
transaction_date – La date à laquelle la transaction aura effectivement lieu.
transaction_details – Tous les détails liés à cette transaction, stockés dans un format texte non structuré.

La table finale de notre modèle est le transaction_type dictionnaire. Les valeurs stockées dans cette table sont affectées à chaque transaction selon ce qu'elle est :« achat/vente » ou « location/location ».

Diriger une société immobilière est très compliqué, exigeant et même risqué. Afin que tout fonctionne bien, une grande organisation est nécessaire. J'espère que ce modèle de données vous a aidé à réaliser la complexité de ce domaine.

Comme toujours, il existe de nombreuses façons d'améliorer ce modèle. N'hésitez pas à partager vos suggestions et commentaires.