Um modelo de dados de agência imobiliária

Perguntas frequentes sobre imóveis

1. 
   O que pode ser considerado uma propriedade ou propriedade?
   
   Quando pensamos em imóveis, a primeira imagem que temos é muitas vezes de uma casa ou outra habitação. O mercado imobiliário é muito mais do que isso. Edifícios, escritórios, terrenos, recursos minerais e corpos também se enquadram nesta categoria. Para os propósitos deste artigo, tratarei tudo o que é “imóvel” como imóveis. Dito isso, vamos nos concentrar principalmente em prédios de apartamentos e casas.
   
2. 
   Onde está localizada a propriedade ou propriedade?
   
   Para casas, prédios e apartamentos, isso é muito simples. Saberemos o endereço exato onde a propriedade está localizada. O terreno não tem endereço, mas a sua posição é definida por um registo predial.
   
3. 
   Quais dados precisamos armazenar?
   
   Em nosso modelo, precisamos armazenar todas as propriedades (ou seja, imóveis) e clientes com quem trabalhamos. Precisamos dessas informações para criar relatórios e também para melhorar nossos negócios.
   
   Podemos esperar que nos comuniquemos frequentemente com os clientes, por isso devemos armazenar todos os seus detalhes de contato. Também queremos saber qual funcionário entrou em contato com o cliente e qual interesse o cliente expressou durante a conversa.
   
   Para propriedades, precisamos de seus detalhes e status atual ao nosso alcance para que possamos responder rapidamente às perguntas de clientes em potencial.
   
   Também armazenaremos nosso histórico de contatos e quaisquer contratos relacionados a clientes ou propriedades.
   
4. 
   Qual ​​a importância das datas?
   
   As datas são sempre cruciais, mas quero enfatizar que elas são especialmente importantes no setor imobiliário. Precisamos saber a quantidade exata de tempo que uma de nossas propriedades alugadas está ocupada para que possamos alugá-la novamente assim que estiver disponível. Não pode haver sobreposição quando dois clientes alugam o mesmo imóvel. Se um cliente em potencial expressar o desejo de alugar em alguma data futura específica, devemos armazenar essa informação e receber um lembrete quando essa data estiver se aproximando.
   
5. 
   Como deve ser nosso aplicativo?
   
   Para isso, uma aplicação web é a melhor solução. Grande parte do trabalho imobiliário é baseado em escritórios, mas os agentes de vendas devem ser capazes de inserir novos dados onde quer que estejam. A funcionalidade mais importante em nosso aplicativo é uma pesquisa rápida que pode encontrar clientes, propriedades e status de propriedades.
   

O modelo de dados

• Estates and locations
• Clients and contacts
• Contracts and transactions

A Tabela de Funcionários

Começaremos com o employee tabela. É simples:ele armazena apenas o first_name e last_name de cada funcionário. Poderíamos adicionar outros detalhes como o número de identificação fiscal do funcionário, sua data de nascimento, endereço, cargo, etc. No entanto, neste modelo não estaremos focando nos funcionários, então tudo o que precisamos é uma maneira de associar funcionários a ações (como ser atribuído a uma tarefa ou contrato). Essa tabela também nos permitirá registrar qual funcionário participou de cada contato com o cliente.

Seção 1:Propriedades e Locais

As Estates and location A área de assunto contém seis tabelas que descrevem todas as propriedades (propriedades) com as quais trabalhamos, suas localizações e seu status atual.

A tabela central nesta área de assunto é a estate tabela. Ele contém uma lista de todas as propriedades com as quais estamos, trabalhamos ou trabalharemos. Isso inclui propriedades para as quais mediamos entre dois clientes, aqueles que possuímos, aqueles que vendemos ou alugamos para clientes e aqueles que alugamos ou compramos de clientes. Ele também mantém um registro das propriedades com as quais planejamos (ou planejamos) fazer negócios.

Como estamos focando principalmente em apartamentos e casas neste artigo, os atributos nesta tabela estão principalmente relacionados a eles. Se quisermos descrever outros tipos de propriedade real, podemos adicionar atributos descritivos anuláveis ​​adicionais. Também podemos simplesmente inserir esses valores no estate_description atributo. Os atributos na estate tabela são:

• estate_name – O nome da propriedade. Pode ser nosso nome interno para uma propriedade ("Stoker house") ou um nome público bem conhecido ("Bran Castle").
• city_id – O ID da cidade onde a propriedade está localizada.
• estate_type_id – Refere-se ao estate_type dicionário.
• floor_space e balconies_space – O tamanho (em metros quadrados) dos pisos e varandas dos apartamentos.
• number_of_balconies , number_of_bedrooms , number_of_garages e number_of_parking_spaces – Valores inteiros para cada categoria. Autoexplicativo.
• pets_allowed – Um valor booleano indicando se animais de estimação são permitidos. Isso é usado principalmente para propriedades de aluguel.
• estate_description – Uma descrição detalhada de uma propriedade. É aqui que armazenamos qualquer informação adicional, por ex. histórico da propriedade.
• estate_status_id – Se uma propriedade está atualmente disponível ou não. Usaremos este campo em nossa função de pesquisa.

• estate_id e employee_id – Chaves estrangeiras que se referem ao espólio e cliente relacionados, respectivamente.
• date_from e date_to – O intervalo em que o funcionário foi atribuído a essa propriedade. Observe que “date_to” pode ser NULL porque um funcionário pode cuidar de uma propriedade indefinidamente. Quando atribuímos um funcionário a uma propriedade, devemos nos certificar de que ele já não esteja atribuído a outra propriedade, verificando os intervalos de datas sobrepostos. Por outro lado, podemos atribuir muitos funcionários à mesma propriedade ao mesmo tempo. Isso seria desejável quando os funcionários têm funções diferentes, por exemplo, um funcionário cuida da comunicação com o cliente, outro funcionário mostra essa propriedade, outro lida com vendas e contratos legais etc.

Seção 2:clientes e contatos

O Client and contacts área de assunto consiste em apenas duas tabelas, o client tabela e o contact tabela. As duas outras tabelas mostradas nesta área, employee:Clients and contacts e estate:Clients and contacts são apenas cópias.

O client A tabela contém registros de todos os clientes com quem já trabalhamos, incluindo clientes atuais e potenciais. Quem é um cliente em potencial? Pode ser alguém que disse que quer vender, comprar ou alugar alguma propriedade nossa no futuro. Precisamos armazenar os detalhes de contato e propriedades desses clientes para uso futuro. Os atributos no client tabela são:

• client_name – Para um indivíduo, este campo contém seu nome e sobrenome. Se o cliente for uma pessoa jurídica, ele possui o nome da empresa ou entidade.
• client_address – Uma descrição de texto da localização do cliente.
• contact_person – Nome e sobrenome (e provavelmente um cargo, se o cliente for uma empresa) de nossa pessoa de contato.
• phone , mobile e mail – Os detalhes de contato do cliente.
• client_details – Todos os outros detalhes relacionados a esse cliente. Eles são armazenados em um formato de texto não estruturado.

• client_id – O ID do cliente envolvido.
• employee_id – O ID do funcionário envolvido nessa instância de contato. Isso pode ser NULL porque um cliente não pode entrar em contato com nenhum funcionário individual - por exemplo, talvez o cliente tenha enviado um email para a conta da empresa. Ainda assim, na maioria dos casos, podemos esperar saber qual funcionário lidou com uma interação.
• estate_id – O ID do espólio relacionado. Isso é útil quando o cliente solicita um determinado imóvel ou deseja vender ou arrendar algo que já temos em nosso sistema.
• contact_time – A hora em que o contato ocorreu.
• contact_details – Quaisquer notas não estruturadas que queremos salvar sobre esse contato. Podemos escrever algo como “O cliente expressou desejo de comprar uma casa bairro.”

Seção 3:Contratos e Transações

A última área de assunto em nosso modelo é Contracts and transactions . Vamos usá-lo para relacionar propriedades com clientes.

A tabela central desta seção é o contract tabela. É onde armazenamos todos os detalhes do contrato e relacionamos contratos com clientes e funcionários. Os atributos nesta tabela são:

• client_id – O ID do cliente que assinou o contrato relacionado.
• employee_id – O ID do funcionário que assinou o contrato em nome da nossa empresa.
• contract_type_id – Refere-se ao contract_type dicionário e indica se o contrato está relacionado à compra, venda, arrendamento ou aluguel de propriedade.
• contract_details – Uma descrição detalhada do contato, armazenada em formato de texto.
• payment_frequency_id – Refere-se à payment_frequency dicionário e define os intervalos em que as faturas devem ser enviadas.
• number_of_invoices – O número de faturas que devem ser geradas. Se a empresa pagar apenas uma vez, um valor de “1” é armazenado neste atributo e todo o payment_amount será igual ao invoice_amount .
• payment_amount – O valor total pago.
• fee_percentage – A porcentagem que cobramos do cliente. Por exemplo, podemos cobrar 5% do preço de venda de uma casa como taxa. O valor nesta coluna deve ser o mesmo que o contract_type .fee_percentage atributo para este contrato. A fee_percentage atributo será usado para calcular o fee_amount quando inserimos um valor no payment_amount atributo.
• fee_amount – O valor total da taxa que cobraremos do cliente por este contrato.
• date_signed – A data em que o contrato foi assinado.
• start_date – A data em que o contrato se torna válido (por exemplo, para um contrato de aluguel ou arrendamento).
• end_date – A data em que o contrato expira. Pode ser NULL caso assinemos um contrato sem data de término. No entanto, na maioria dos casos, saberemos a end_date com antecedência.
• transaction_id –Referencia a transaction tabela se o contrato for parte de uma transação entre dois clientes. Ele pode conter valores NULL porque não haverá um registro de transação relacionado se o contrato for diretamente entre nós e um cliente.

• contract_id – O ID do contrato relacionado.
• invoice_number – Um identificador interno exclusivo para a fatura.
• issued_by – Uma descrição de texto do emissor da fatura. Quando emitimos uma fatura, armazenamos os detalhes da nossa empresa aqui. Se o cliente emitir, seus detalhes serão armazenados aqui.
• issued_to – O oposto de issued_by . Se cobrarmos do cliente, esse atributo conterá seus detalhes; se o cliente nos cobrar, nossos dados serão armazenados aqui.
• invoice_details – Todos os detalhes do item da fatura.
• invoice_amount – O valor devido nesta fatura.
• date_created – A data real em que a fatura foi criada em nosso sistema.
• billing_date – A data em que a fatura deve ser paga.
• date_paid – A data real em que a fatura foi paga. Pode ser NULL até que a fatura seja paga.

• transaction_id – Um ID exclusivo para cada transação.
• transaction_type_id – Refere-se ao transaction_type dicionário.
• client_offered – Faz referência ao client tabela e indica quem está vendendo ou alugando uma propriedade.
• client_requested – Faz referência ao client tabela e indica quem está comprando ou alugando uma propriedade.
• transaction_date – A data em que a transação realmente acontecerá.
• transaction_details – Todos os detalhes relacionados a essa transação, armazenados em um formato de texto não estruturado.