Un modelo de datos de una agencia inmobiliaria

Además de la ubicación, ¿qué se necesita para administrar un negocio inmobiliario exitoso? Examinamos un modelo de datos para ayudar a las agencias inmobiliarias a mantenerse organizadas.

Comprar, vender y alquilar apartamentos o casas es un gran negocio hoy en día. La mayoría de las personas están felices de pagar una tarifa y dejar que una agencia inmobiliaria profesional haga el trabajo por ellos. Por otra parte, la sociedad podría actuar por cuenta propia, comprando inmuebles para revender o alquilar. Una empresa de bienes raíces también puede arrendar una propiedad y luego alquilarla o subarrendarla y obtener una ganancia sobre la diferencia.

Obviamente, hacer un seguimiento de las propiedades es una parte importante de la gestión de un negocio inmobiliario. Al mismo tiempo, las fechas son igualmente importantes. (por ejemplo, ¿cuándo estará disponible un apartamento de alquiler? ¿Cuándo saldrá al mercado una propiedad?) En este artículo, veremos un modelo de datos que puede ayudar a las empresas inmobiliarias a mantenerse organizadas.

Preguntas frecuentes sobre bienes raíces

Antes de comenzar a describir el modelo y sus datos esperados, primero responderemos algunas preguntas específicas de un negocio inmobiliario. Los bienes raíces tienen muchos términos y una explicación completa de su jerga y principios va mucho más allá del alcance de este artículo, por lo que aquí solo responderemos las preguntas más comunes y básicas.

¿Qué se puede considerar un patrimonio o una propiedad?

Cuando pensamos en bienes raíces, la primera imagen que obtenemos es a menudo la de una casa o alguna otra vivienda. Los bienes raíces son mucho más que eso. Edificios, oficinas, terrenos, recursos minerales y cuerpos también entran en esta categoría. A los efectos de este artículo, trataré todo lo que sea "inamovible" como bienes inmuebles. Dicho esto, nos centraremos principalmente en edificios de apartamentos y casas.
¿Dónde se encuentra la finca o propiedad?

Para casas, edificios y apartamentos esto es muy simple. Sabremos la dirección exacta donde se encuentra la propiedad. La tierra no tiene una dirección, pero su posición está definida por un registro de la propiedad.
¿Qué datos necesitamos almacenar?

En nuestro modelo, necesitamos almacenar todas las propiedades (es decir, bienes inmuebles) y clientes con los que trabajamos. Necesitamos esta información para crear informes y también para mejorar nuestro negocio.

Podemos esperar que nos comuniquemos con frecuencia con los clientes, por lo que debemos almacenar todos sus datos de contacto. También querremos saber qué empleado se puso en contacto con el cliente y qué interés expresó el cliente durante la conversación.

En el caso de las propiedades, necesitamos tener al alcance de la mano sus datos y su estado actual para poder responder rápidamente a las consultas de los clientes potenciales.

También almacenaremos nuestro historial de contactos y cualquier contrato relacionado con clientes o propiedades.
¿Qué tan importantes son las fechas?

Las fechas siempre son cruciales, pero quiero enfatizar que son especialmente importantes en el sector inmobiliario. Necesitamos saber la cantidad exacta de tiempo que una de nuestras propiedades de alquiler está ocupada para poder alquilarla de nuevo tan pronto como esté disponible. No puede haber superposición cuando dos clientes alquilan la misma propiedad. Si un cliente potencial expresa su deseo de alquilar en una fecha futura específica, debemos almacenar esa información y recibir un recordatorio cuando se acerque esa fecha.
¿Cómo debería ser nuestra aplicación?

Para este propósito, una aplicación web es la mejor solución. Gran parte del trabajo inmobiliario se realiza en la oficina, pero los agentes de ventas deberían poder insertar nuevos datos dondequiera que estén. La funcionalidad más importante de nuestra aplicación es una búsqueda rápida que puede encontrar clientes, propiedades y estados de propiedad.

El modelo de datos

Nuestro modelo de datos inmobiliarios consta de tres áreas temáticas principales:

Estates and locations
Clients and contacts
Contracts and transactions

Hay una mesa, employee , que está fuera de cualquier área temática.

Tenga en cuenta que el employee y el estate tablas en los Clients and contacts área de asunto y el client tabla en los Contracts and transactions el área temática son solo copias utilizadas para simplificar el modelo.

Echaremos un vistazo al employee primero la tabla, continuar con Estates and locations , vaya a Clients and contacts y luego termine con Contracts and transactions .

La tabla de empleados

Comenzaremos con el employee mesa. Es simple:almacena solo el first_name y last_name de cada empleado. Podríamos agregar otros detalles como el número de identificación fiscal del empleado, su fecha de nacimiento, dirección, función laboral, etc. Sin embargo, en este modelo no nos centraremos en los empleados, por lo que todo lo que necesitamos es una forma de asociar a los empleados con acciones (como ser asignado a una tarea o contrato). Esta tabla también nos permitirá registrar qué empleado participó en cada contacto con el cliente.

Sección 1:Propiedades y ubicaciones

Las Estates and location El área temática contiene seis tablas que describen todas las propiedades (propiedades) con las que trabajamos, sus ubicaciones y su estado actual.

La tabla central en esta área temática es el estate mesa. Contiene una lista de todos los estados con los que estamos, estuvimos o estaremos trabajando. Esto incluye propiedades para las que mediamos entre dos clientes, las que poseemos, las que hemos vendido o alquilado a clientes y las que hemos alquilado o comprado a clientes. También mantiene un registro de las propiedades con las que planeamos (o habíamos planeado) hacer negocios.

Dado que en este artículo nos estamos centrando principalmente en apartamentos y casas, los atributos de esta tabla se relacionan principalmente con ellos. Si quisiéramos describir otros tipos de bienes inmuebles, podríamos agregar atributos descriptivos que aceptan valores NULL adicionales. También podríamos simplemente ingresar esos valores en el estate_description atributo. Los atributos en el estate tabla son:

estate_name – El nombre de la finca. Este podría ser nuestro nombre interno para una propiedad ("Stoker house") o un nombre público conocido ("Bran Castle").
city_id – El DNI de la ciudad donde se encuentra la finca.
estate_type_id – Hace referencia al estate_type diccionario.
floor_space y balconies_space – El tamaño (en metros cuadrados) de los pisos y balcones de los apartamentos.
number_of_balconies , number_of_bedrooms , number_of_garages y number_of_parking_spaces – Valores enteros para cada categoría. Se explica por sí mismo.
pets_allowed – Un valor booleano que indica si se permiten mascotas. Esto se usa principalmente para propiedades de alquiler.
estate_description – Una descripción detallada de una finca. Aquí es donde almacenamos cualquier información adicional, p. historial de la propiedad.
estate_status_id – Si una finca está actualmente disponible o no. Usaremos este campo en nuestra función de búsqueda.

Ya hemos mencionado dos diccionarios que el estate la tabla se refiere a, estate_type y estate_status . Ambos diccionarios contienen solo una ID y un atributo de nombre ÚNICO.

En el estate_type diccionario, almacenaremos valores como "apartamento", "casa", "campo", etc. El estate_status La tabla tendrá valores que indican si la propiedad está actualmente disponible o no, como "propiedad arrendada", "propiedad comprada", "propiedad vendida", "propiedad alquilada".

Definiremos la ubicación de cada finca, no solo por descripción (la estate . estate_description atributo), sino también por su país y ciudad. Para ello, utilizaremos dos tablas de diccionario:country y city . Cada país está definido de forma única por un country_name , que será el único atributo (aparte del ID) almacenado en la tabla. Por otro lado, cada ciudad tiene un nombre y un país. Algunas ciudades pueden tener el mismo nombre, pero supondremos que el nombre de cada ciudad es exclusivo de su país:solo Viena, Austria o Ginebra, Suiza. Sin embargo, si queremos protegernos contra duplicados, podríamos agregar un atributo de región. Por ahora, sin embargo, dejaremos todo como está. El city_name – country_id par es la clave ÚNICA de la city mesa.

La última tabla en esta área temática es in_charge mesa. Podemos esperar que cada finca tenga al menos un empleado asignado para manejar los asuntos relacionados con ella. Este empleado es responsable de cosas como comunicarse con los clientes, mostrar el patrimonio a clientes potenciales y otras tareas administrativas y legales. En el in_charge mesa, tendremos:

estate_id y employee_id – Claves foráneas que hacen referencia al patrimonio relacionado y al cliente, respectivamente.
date_from y date_to – El intervalo en el que el empleado estuvo asignado a ese patrimonio. Tenga en cuenta que "date_to" puede ser NULL porque un empleado podría hacerse cargo de un patrimonio indefinidamente. Cuando asignamos un empleado a un estado, debemos asegurarnos de que no esté asignado a otro estado verificando los intervalos de fechas superpuestas. Por otro lado, podemos asignar muchos empleados a la misma finca al mismo tiempo. Esto sería deseable cuando los empleados tienen diferentes funciones, p. un empleado se encarga de la comunicación con el cliente, otro empleado muestra ese patrimonio, otro maneja las ventas y los contratos legales, etc.

Sección 2:Clientes y Contactos

El Client and contacts el área de asunto consta de solo dos tablas, el client tabla y el contact mesa. Las otras dos tablas que se muestran en esta área, employee:Clients and contacts y estate:Clients and contacts son solo copias.

El client La tabla contiene registros de todos los clientes con los que hemos trabajado, incluidos los clientes actuales y potenciales. ¿Quién es un cliente potencial? Podría ser alguien que ha dicho que quiere vender, comprar o alquilar alguna propiedad nuestra en el futuro. Necesitamos almacenar los datos de contacto y las propiedades de dichos clientes para uso futuro. Los atributos en el client tabla son:

client_name – Para una persona, este campo contiene su nombre y apellido. Si el cliente es una persona jurídica, posee el nombre de la empresa o entidad.
client_address – Una descripción de texto de la ubicación del cliente.
contact_person – Nombre y apellido (y probablemente un puesto de trabajo si el cliente es una empresa) de nuestra persona de contacto.
phone , mobile y mail – Los datos de contacto del cliente.
client_details – Todos los demás detalles relacionados con ese cliente. Estos se almacenan en un formato de texto no estructurado.

Los últimos cinco atributos de esta tabla se pueden anular porque no son cruciales. Probablemente necesitemos almacenar información para al menos una persona de contacto, pero es posible que no sepamos de antemano quién será nuestro contacto.

La segunda y última tabla en esta área temática es el contact mesa. Aquí almacenaremos datos sobre cada interacción que hayamos tenido con los clientes. Usaremos esta información para optimizar nuestro negocio futuro; por ejemplo, si un cliente nos solicita alquilar una determinada propiedad cuando esté disponible, debemos almacenar esa solicitud e informarle cuando la propiedad esté lista. Los atributos en la tabla son:

client_id – El DNI del cliente involucrado.
employee_id – El ID del empleado involucrado en esa instancia de contacto. Esto puede ser NULL porque un cliente no puede contactar a ningún empleado individual, p. tal vez el cliente envió un correo electrónico a la cuenta de la empresa. Aún así, en la mayoría de los casos podemos esperar que sepamos qué empleado manejó una interacción.
estate_id – El DNI de la finca relacionada. Esto es útil cuando el cliente solicita una determinada propiedad o si el cliente quiere vender o arrendar algo que ya tenemos en nuestro sistema.
contact_time – La hora en que se produjo el contacto.
contact_details – Cualquier nota no estructurada que queramos guardar sobre ese contacto. Podríamos escribir algo como "El cliente expresó su deseo de comprar una casa en vecindario".

Sección 3:Contratos y Transacciones

La última área temática de nuestro modelo es Contracts and transactions . Lo usaremos para relacionar fincas con clientes.

La tabla central de esta sección es el contract mesa. Es donde almacenaremos todos los detalles del contrato y relacionaremos los contratos con clientes y empleados. Los atributos de esta tabla son:

client_id – El DNI del cliente que firmó el contrato relacionado.
employee_id – El DNI del empleado que firmó el contrato en nombre de nuestra empresa.
contract_type_id – Hace referencia al contract_type diccionario e indica si el contrato se relaciona con la compra, venta, arrendamiento o alquiler de una propiedad.
contract_details – Una descripción detallada del contacto, almacenada en formato de texto.
payment_frequency_id – Hace referencia a la payment_frequency diccionario y define los intervalos en los que se deben enviar las facturas.
number_of_invoices – El número de facturas que se deben generar. Si la empresa paga solo una vez, se almacena un valor de "1" en este atributo y el payment_amount completo será igual al invoice_amount .
payment_amount – La cantidad total pagada.
fee_percentage – El porcentaje que cobramos al cliente. Por ejemplo, podríamos cobrar el 5% del precio de venta de una casa como tarifa. El valor en esta columna debe ser el mismo que el contract_type .fee_percentage atributo para este contrato. El fee_percentage el atributo se usará para calcular el fee_amount cuando ingresamos un valor en el payment_amount atributo.
fee_amount – El monto total de la tarifa que le cobraremos al cliente por este contrato.
date_signed – La fecha en que se firmó el contrato.
start_date – La fecha de entrada en vigor del contrato (por ejemplo, para un contrato de alquiler o arrendamiento).
end_date – La fecha de vencimiento del contrato. Puede ser NULL en caso de que firmemos un contrato que no tenga fecha de finalización. Sin embargo, en la mayoría de los casos conoceremos la end_date por adelantado.
transaction_id –Hace referencia a la transaction table si el contrato es parte de una transacción entre dos clientes. Puede contener valores NULL porque no habrá un registro de transacción relacionado si el contrato es directamente entre nosotros y un cliente.

El under_contract tabla relaciona contratos y sucesiones. Junto al atributo de clave principal id , contiene solo dos claves foráneas, estate_id y contract_id . Este par de claves foráneas también forma la clave ÚNICA de la tabla.

Guardaremos registros de cada factura que hayamos generado en la invoice mesa. Si el cliente realiza un único pago por todo el contrato, habrá un solo registro en esta tabla para ese contrato. Lo mismo ocurre si hacemos un pago único a un cliente. Si el cliente (o nuestra empresa) opta por pagar a plazos, hay el mismo número de registros que el valor en el contract .number_of_invoices campo. Los atributos de esta tabla son:

contract_id – El ID del contrato relacionado.
invoice_number – Un identificador interno único para la factura.
issued_by – Una descripción de texto del emisor de la factura. Cuando emitimos una factura, almacenaremos los datos de nuestra empresa aquí. Si el cliente lo emite, sus detalles se almacenarán aquí.
issued_to – Lo contrario de issued_by . Si cobramos al cliente, este atributo contendrá sus detalles; si el cliente nos cobra, nuestros datos se almacenan aquí.
invoice_details – Todos los detalles de los elementos de la factura.
invoice_amount – El monto adeudado en esta factura.
date_created – La fecha real en que se creó la factura en nuestro sistema.
billing_date – La fecha en que se debe pagar la factura.
date_paid – La fecha real en que se pagó la factura. Puede ser NULL hasta que se pague la factura.

Usaremos dos diccionarios más para describir contratos, contract_type y payment_frequency . El contract_type_name El campo se utiliza para indicar la acción que estamos realizando en el contrato:“mediación (compra)”, “mediación (venta)”, “mediación (alquiler)”, “mediación (arrendamiento)”, “compra (de un cliente) ”, “vender (a un cliente)”, “arrendar (a un cliente)” y “alquilar (a un cliente)”. El payment_frequency_name El atributo simplemente describe con qué frecuencia se generarán las facturas, ya sea por nosotros o por el cliente. Puede almacenar valores como "una vez", "una vez al mes", "una vez cada 2 meses" y "una vez al año".

Si nuestra empresa compra o arrienda alguna propiedad, le pagamos al cliente. Esto significa que seremos los de la invoice .issued_to y tendremos que pagar facturas. Si vendemos o alquilamos una finca, el cliente nos pagará y seremos nosotros los de la invoice .issued_by campo.

Si mediamos en un trato entre dos clientes, cobraremos una tarifa por nuestros servicios. En este caso, firmaremos dos contratos separados, uno con el cliente vendedor/alquiler y otro con el cliente comprador/arrendatario. Relacionaremos estos dos contratos asignando el mismo transaction_id a ambos. La transaction La tabla se utiliza para almacenar registros de transacciones que hemos mediado. Los atributos de esta tabla son:

transaction_id – Una identificación única para cada transacción.
transaction_type_id – Hace referencia al transaction_type diccionario.
client_offered – Hace referencia al client tabla e indica quién está vendiendo o alquilando una propiedad.
client_requested – Hace referencia al client tabla e indica quién está comprando o alquilando una propiedad.
transaction_date – La fecha en la que realmente se realizará la transacción.
transaction_details – Todos los detalles relacionados con esa transacción, almacenados en un formato de texto no estructurado.

La tabla final en nuestro modelo es el transaction_type diccionario. Los valores almacenados en esta tabla se asignan a cada transacción según sea:“compra/venta” o “alquiler/arrendamiento”.

Dirigir una empresa inmobiliaria es muy complicado, exigente e incluso arriesgado. Para que todo funcione sin problemas, se necesita mucha organización. Espero que este modelo de datos te haya ayudado a darte cuenta de la complejidad de este campo.

Como siempre, hay muchas maneras de mejorar este modelo. No dude en compartir sus sugerencias y comentarios.