Modelagem de dados / MER - Sistema Imobiliário

Introdução

Os sistemas de banco de dados são essenciais para a organização, o armazenamento e a recuperação eficiente de informações, especialmente em ambientes empresariais que lidam com grande volume de dados. Nesse contexto, a correta modelagem das informações torna-se um fator crítico para o sucesso de qualquer sistema informatizado. O Modelo de Entidade-Relacionamento (MER) é uma ferramenta fundamental nesse processo, pois permite representar graficamente os principais elementos de um negócio, bem como suas características e interações. Por meio do MER, é possível compreender de forma clara como os dados se relacionam, reduzindo ambiguidades e prevenindo falhas estruturais no banco de dados.

No setor imobiliário, onde há um alto volume de cadastros, contratos e transações, a ausência de uma estrutura adequada para os dados pode gerar diversos problemas, como informações duplicadas, inconsistentes ou de difícil acesso. A dependência de registros manuais compromete a agilidade nas consultas, a confiabilidade dos relatórios e a tomada de decisões estratégicas.

Diante desse cenário, considere a seguinte situação: uma imobiliária enfrenta dificuldades na organização de seus registros, pois os dados de imóveis, clientes, contratos e corretores são armazenados manualmente. Essa prática torna o processo lento, suscetível a erros e pouco eficiente. Com o objetivo de informatizar suas operações, a empresa necessita de um modelo de banco de dados bem estruturado, iniciando pelo desenvolvimento de um Modelo de Entidade-Relacionamento.

A utilização do MER no início do projeto é essencial, pois permite identificar claramente as entidades do negócio, como imóveis, clientes, corretores e contratos os atributos que caracterizam cada entidade e os os relacionamentos existentes entre essas informações. Dessa forma, o MER não representa o sistema final, mas sim o primeiro e mais importante passo para a construção de uma solução eficiente. Somente após essa etapa é possível avançar para o modelo lógico, a implementação física do banco de dados, o desenvolvimento do sistema, a migração dos dados manuais e a criação de consultas e relatórios confiáveis. Assim, o Modelo de Entidade-Relacionamento se estabelece como a base para a organização dos dados, garantindo maior consistência, redução de erros e uma estrutura sólida para o crescimento futuro do sistema da imobiliária.

Implementação do MER:

Um cliente pode alugar ou comprar um imóvel? Um corretor pode intermediar vários contratos? Um contrato envolve um cliente, um imóvel e um corretor? É importante destacar para a empresa que o MER não é o sistema final, mas sim o primeiro passo para o projeto. Somente após o MER podemos iniciar a criação do modelo lógico do banco de dados.

Assim os dados passam a ser organizados e padronizados. As consultas se tornam rápidas e confiáveis. Os relatórios clarros para tomada de decisão e há redução de erros manuais tendo uma base sólida para crescimento futuro do sistema. Portanto, o Modelo Entidade-Relacionamento é essencial para compreender e estruturar as informações do negócio, sendo o ponto de partida para a migração de processos manuais para um sistema digital eficiente e confiável.

Modelo de Entidade-Relacionamento (MER) – Sistema Imobiliário

Com base nas regras de negócio apresentadas, é elaborado um Modelo de Entidade-Relacionamento (MER) com o objetivo de representar de forma clara e organizada as entidades, seus atributos e os relacionamentos existentes no sistema da imobiliária.

Entidades Identificadas:

A partir da análise do negócio, foram identificadas as seguintes entidades principais:

Cliente
Imóvel
Proprietário
Corretor
Contrato

Atributos das Entidades:

Cliente

id_cliente (PK)
nome
CPF
telefone
endereço

Proprietário

id_proprietario (PK)
nome
CPF
telefone

Imóvel

id_imovel (PK)
endereço
tipo_imovel
valor_base
id_proprietario (FK)

Corretor

id_corretor (PK)
nome
CRECI
telefone

Contrato

id_contrato (PK)
tipo_contrato (aluguel ou venda)
valor_transacao
data_assinatura
id_cliente (FK)
id_imovel (FK)
id_corretor (FK)

Relacionamentos e Cardinalidades:

Cliente – Contrato
- Um cliente pode firmar vários contratos ao longo do tempo.
- Cada contrato está associado a um único cliente.
- Cardinalidade: 1:N
Imóvel – Contrato
- Um imóvel pode participar de vários contratos ao longo do tempo (aluguéis ou vendas).
- Cada contrato refere-se a um único imóvel.
- Cardinalidade: 1:N
Corretor – Contrato
- Um corretor pode intermediar vários contratos.
- Cada contrato é intermediado por um único corretor.
- Cardinalidade: 1:N
Proprietário – Imóvel
- Um proprietário pode possuir vários imóveis.
- Cada imóvel pertence a um único proprietário.
- Cardinalidade: 1:N

Justificativa do Modelo:

O uso da entidade Contrato como elemento central do modelo permite registrar o histórico de negociações, respeitando a regra de que um imóvel pode ser alugado ou vendido para diferentes clientes ao longo do tempo. Além disso, o modelo garante integridade e organização dos dados, evitando duplicidade de informações e facilitando a geração de relatórios e consultas.

Considerações finais sobre o projeto:

O Modelo de Entidade-Relacionamento proposto atende às regras de negócio da imobiliária, proporcionando uma visão clara das informações e de seus relacionamentos. Esse modelo serve como base para a criação do modelo lógico e físico do banco de dados, além de apoiar a informatização segura e eficiente dos processos da empresa.

Entidade Contrato é essencial porque representa eventos ao longo do tempo, permite histórico de vendas e aluguéis e resolve relacionamentos muitos-para-muitos. Centraliza dados da transação e sem a entidade Contrato, o sistema não teria histórico, não conseguiria gerar relatórios e ficaria conceitualmente incorreto. O Modelo Entidade-Relacionamento proposto estrutura os dados da imobiliária de forma coerente com suas regras de negócio, utilizando a entidade associativa. Contrato para representar as transações entre clientes, imóveis, corretores e proprietários. Esse modelo garante integridade dos dados, histórico das negociações e base sólida para implementação do banco de dados relacional.

O modelo de Entidade e Relacionamento (MER) é uma ferramenta essencial na modelagem de bancos de dados, pois permite representar visualmente os dados e suas interações. Ele ajuda a identificar entidades, atributos e relacionamentos, facilitando o planejamento e a implementação de sistemas. Entre os tipo de MER, destacam-se o modelo de Peter Chen e os modelos de James Martin, que simplifica a representação com retângulos e linhas, tornando a leitura mais direta.

Já o modelo de James Martin, desenvolvido na década de 1980, simplifica mais ainda a notação visual, eliminando os losangos e usando apenas retângulos para entidades e linhas para relacionamentos. O modelo de Peter Chen é ideal para documentação detalhada enquanto o modelo de James Martin é mais prático para projetos que precisam de uma visualização rápida e organizada.

DB Designer Web-Plataforma de Modelagem de Banco de Dados

O DB Designer Web é uma ferramenta online voltada para a modelagem visual de bancos de dados, amplamente utilizada para a criação de Modelos Entidade-Relacionamento (MER) e diagramas físicos de forma intuitiva e padronizada.

No contexto deste projeto, a plataforma foi utilizada para planejar, estruturar e validar o modelo de dados antes da implementação física do banco, garantindo maior organização, integridade e aderência às boas práticas de engenharia de dados.

BR Modelo Web — Modelagem Conceitual (MER)

O BR Modelo Web é uma plataforma online voltada para a modelagem conceitual de bancos de dados, amplamente utilizada no ensino e na prática de modelagem por seguir rigorosamente o Modelo Entidade-Relacionamento (MER) de Peter Chen.

Neste projeto, a ferramenta foi utilizada para representar o domínio do negócio imobiliário em alto nível de abstração, priorizando o entendimento das entidades, seus atributos e os relacionamentos entre elas, de forma independente de qualquer tecnologia ou SGBD.

A modelagem conceitual desenvolvida no BR Modelo Web serviu como base inicial do projeto, permitindo validar as regras de negócio antes da evolução para os modelos lógico e físico. Essa etapa foi essencial para garantir clareza, coerência e alinhamento entre a visão do negócio e a implementação técnica posterior.

Elementos de Modelo de Entidade e Relaciomento

São constituidos por três elementos básicos: entidades, atributos e relacionamentos. Existem dois tipos de entidades que são divididas em lógicas e físicas.

Entidades Físicas:

Correspondem aos objetos envolvidos em um ambiente. Esses objetos irão realizar conexões com outros objetos para trocar informações necessárias para o correto funcionamento do sistema que será construído. As entidades podem ser divididas em físicas ou lógicas. As entidades físicas são aquelas que existem no mundo real. Assim também como ativos de um empresa como inventário, produtos são objetos e são propriedades da empresa.

Entidades lógicas:

Essa necessidade se dá em virtude dos relacionamentos ou da classificação sobre outras entidades ou conexão entre elas. São exemplos de entidades lógicas a venda de um produto ou a classificação de um objeto do mundo real da empresa (modelo de cadeira, função de um usuário do sistema). Exemplos de entidades lógicas podem ser grupos de usuários do sistema, venda, relatório, etc. A entidade grupos de usuários do sistema existe para regular as permissões dos usuários ao sistema; a entidade venda é necessária para relacionar a conexão de entrega de algo da entidade física produto para alguma pessoaou empresa da entidade física cliente, guardando os dados dessa entrega, como valores, data, etc.; por fim, a entidade relatório existe para puxar informações da própria entidade lógica venda e apresentar os dados ao usuário ou gerente que a solicitou.

Classificação das entidades:

São classificadas em três grupos distintos de entidades, conforme a necessidade de sua existência:

A entidade forte:

São objetos do mundo real que não dependem de outros fatores ou entidades para existirem. Em uma empresa imobiliária temos o cliente como entidade forte que não depende de nenhuma outra para justificar sua existência. O cliente irá comprar o imóvel através de um contrato. Em um sistema de controle de estoque, a entidade produto é uma entidade forte, já que não depende de nenhuma outra para justificar sua existência no Modelo Entidade Relacionamento do sistema em questão.

A entidade fraca:

São aquelas cuja a existência a dependência de outra entidade no Modelo Entidade Relacionamento.Nesse mesmo sistema de controle de estoque, a entidade fornecedor existe somente em virtude da existência da entidade produto. Não faz sentido deixar no sistema um fornecedor que não provê algum dos produtos comercializados pelo sistema. No exemplo de um negócio imobiliário, não há existência de entidades fracas. Os corretores tem existência própria e autonomia para vender imóveis.

A entidade associativa:

São as entidades que existem somente se alguma associação ao relacionamento for necessária. É o caso da entidade contrato, no ramo imobiliário:

Um cliente pode assinar vários contratos e cada contrato pertence a um único cliente.

Um imóvel pode ser alugado ou vendido várias vezes ao longo do tempo e cada contrato se refere a um único imóvel.

Um corretor pode intermediar vários contratos e cada contrato é intermediado por um corretor.

Relacionamentos:

Existem 3 tipos de relacionamentos dentro de umm modelo MER.

1º tipo de relacionamento: (1-1)

O tipo de relacionamento 1 para 1 a regra de relação sempre se dá em um objeto da entidade A com um objeto da entidade B. A relação entre eles é de posse. Cada pessoa do mundo real possui um relógio ou que um relógio possui um único dono, a pessoa. A regra não permite que a pessoa do mundo real tenha mais de um relógio no pulso e o relógio só pertence a um único dono, não podendo pertencer a mais ninguém.

2° tipo de relacionamento: (1-N)

Neste tipo de relaciomento, a regra de relação se dá por um objeto da entidade A relacionando com mais de um objeto da entidade B. Um carro, objeto do mundo real B só pode ter um único proprietário, mas o proprietário, entidade A, pode ter vários carros da entidade B.

3° tipo de relacionamento: (N-N)

Já neste tipo de relacionamento, a quantidade é de um ou mais objetos da entidade A relacionando-se com um ou mais objetos da entidade B.Segue exemplo da entidade B clientes podem ter vários operadoras de telefone da entidade A, da mesma forma a entidade A podem possuir um ou mais clientes da entidade B.

Atributos:

Aqui são identificados e inseridos no Modelo Entidade Relacionamento os atributos, isto é, as características de cada entidade pertinentes ao sistema. Por exemplo, para a entidade cliente para um sistema de vendas, são necessários dados como nome, endereço, telefone e CPF.

Os atributos podem ser divididos em três tipos:

1. Descritivos: aqueles que, por si só, descrevem alguma característica da entidade. Exemplo: nome.

2. Nominativos: aqueles que, mesmo tendo a função de descrever a entidade, também a identificam como única. Exemplo: código de cliente.

3. Referenciais: representam uma entidade na relação com outra entidade no banco de dados. Exemplo: CPF do vendedor que se relaciona com a entidade vendas.

Já a classificação dos atributos pode ser realizada em duas frentes:

1. Simples: atributo sozinho define uma característica. Exemplo: nome.

2. Compostos: atributos combinados que definem uma característica. Exemplo: endereço composto por rua, número, bairro, cidade e estado.

Alguns atributos representam valores únicos que identificam a entidade dentro de uma tabela e não podem se repetir. Em um cadastro de clientes, por exemplo, esse atributo poderia ser o CPF. A estes chamamos de Chave Primária. As chaves estrangeiras sinalizam conexão de chave primária para uma outra entidade. A entidade vendedores tem como chave primária seu CPF, assim, a entidade vendas possui também um campo “CPF do vendedor”, que se relaciona com o campo CPF da entidade vendedor.

Database Markup Language

O Database Markup Language (DBML) será utilizado na modelagem de dados do projeto imobiliário por ser uma linguagem simples, padronizada e visualmente orientada, que facilita a representação da estrutura do banco de dados de forma clara e objetiva.

Diferentemente de diagramas feitos apenas de forma gráfica, o DBML permite descrever o modelo de dados por meio de texto estruturado, representando tabelas, campos, chaves primárias, chaves estrangeiras e relacionamentos de maneira organizada e legível. Isso torna o processo de modelagem mais acessível tanto para desenvolvedores quanto para analistas de dados.

No contexto do sistema imobiliário, que envolve entidades como clientes, imóveis, proprietários, corretores e contratos, o DBML possibilita documentar claramente como essas entidades se relacionam, garantindo que as regras de negócio sejam corretamente traduzidas para a estrutura do banco de dados.

Além disso, o DBML contribui diretamente para a redução de erros na fase de implementação, pois o modelo textual serve como uma fonte única de verdade para a criação do banco de dados. A partir dele, é possível gerar automaticamente diagramas visuais e scripts SQL, assegurando consistência entre o modelo conceitual, lógico e físico.

Outro fator relevante é a facilidade de manutenção e evolução do sistema. Em um projeto imobiliário, novas regras de negócio podem surgir, como novos tipos de contrato ou alterações nos dados dos imóveis. Com o DBML, essas mudanças podem ser feitas rapidamente no modelo, mantendo a documentação sempre atualizada.

SQLAlchemy no projeto imobiliário:

O SQLAlchemy é um framework ORM (Object-Relational Mapping) que permite trabalhar com bancos de dados relacionais utilizando objetos Python, mantendo total controle sobre a modelagem e as regras de negócio. No projeto da imobiliária, onde há entidades como Clientes, Imóveis, Corretores, Proprietários e Contratos, o uso do SQLAlchemy traz diversas vantagens.

Alinhamento direto com o MER e o Modelo Lógico:

Cada entidade definida no Modelo Entidade-Relacionamento (MER) pode ser representada como uma classe Python no SQLAlchemy:

Entidade → Classe
Atributo → Coluna
Relacionamento → relationship()
Chaves → PrimaryKey, ForeignKey

Isso garante que o modelo lógico em SQL seja uma tradução fiel do modelo conceitual.

Independência do banco de dados (portabilidade):

O SQLAlchemy permite trocar o banco sem reescrever o código:

SQLite (desenvolvimento)
PostgreSQL (produção)
MySQL
SQL Server

Isso é essencial para o projeto imobiliário, que pode começar simples e evoluir.

Relacionamentos ricos e navegação entre objetos:

O SQLAlchemy permite navegar naturalmente entre entidades:


contrato.cliente.nome
contrato.imovel.endereco
contrato.corretor.nome

Isso reflete exatamente o relacionamento definido no MER, tornando o código intuitivo e alinhado ao negócio.

Controle explícito das regras de negócio:

Você pode aplicar regras diretamente no modelo:

Campos obrigatórios (nullable=False)
Tipos corretos (Integer, String, Date, Float)
Regras de unicidade
Validações e constraints

Facilita testes, manutenção e evolução do sistema:

Modelos isolados
Fácil criação de testes unitários
Código organizado por domínio (models/, services/, repositories/)
Evolução natural para frameworks como FastAPI ou Flask

O SQLAlchemy foi escolhido por permitir a implementação do modelo lógico do banco de dados de forma alinhada ao Modelo Entidade-Relacionamento, utilizando classes Python que representam as entidades do sistema. Essa abordagem melhora a legibilidade, a manutenção do código, garante integridade dos dados e oferece flexibilidade para evolução futura do sistema.

Segue abaixo o link do projeto:

https://github.com/userdanixdev/project_imobiliaria

Referências:

FILETO, R. O Modelo Entidade-Relacionamento. 2006.
Disponível em: <www.inf.ufsc.br/~r.fileto/Disciplinas/INE5423-2010-1/Aulas/02-MER.pdf>.
Acesso em: 25 jun. 2018.

MIAMOTO, C. V. P. Refinamento de um Diagrama Entidade-Relacionamento: estudo de caso em um sistema ERP. 2012. 24 f. Monografia (Curso de Especialização em Informática com ênfase em Análise Orientada à Objetos) - Universidade Federal do Paraná, Curitiba, 2012. Disponível em: <https://acervodigital.ufpr.br/bitstream/handle/1884/38542/R%20-%20E%20-%20CRISTIANE%20VIEIRA%20PROENCA%20MIAMOTO.pdf?sequence=1&isAllowed=y>. Acesso em: 25 jun. 2018.

RODRIGUES, J. Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER). 2014. Disponível em: <https://www.devmedia.com.br/modelo--entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332>.
Acesso em: 25 jun. 2018.

Pesquisar este blog

Works on