REPÚBLICA DE ANGOLA

MINISTÉRIO DO ENSINO SUPERIOR, CIÊNCIA, TECNOLOGIA E INOVAÇÃO

UNIVERSIDADE ÓSCAR RIBAS

FACULDADE DE CIÊNCIAS E TECNOLOGIA

TRABALHO DA CADEIRA DE BASE DE DADOS I

MODELO ENTIDADE RELACIONAMENTO DE UMA IMOBILIÁRIA

LUANDA 2022
 TRABALHO DA CADEIRA DE BASE DE DADOS I

MODELO ENTIDADE RELACIONAMENTO DE UMA IMOBILIÁRIA

Primeiro trabalho apresentado na

cadeira de Base de Dados I, pelos
estudantes do 2º Ano do curso de
Engenharia Informática e
Comunicações no Iº Semestre do
ano lectivo 2022/2023.

Docente:

_____________________

(Madalena Janota)

LUANDA 2022
 Integrantes

Álvaro Sóstenes Bernardo Muondo 20211534

Lukímia Marilda Sousa Paulino 20211666

Madalena Katumbila Zua 20211520

Nataniel Adriano Daniel Filipe 20210747

 Conteúdo

1. Introdução.........................................................................................................................................5
1.1 Problemática...............................................................................................................................6
1.2 Justificativa.................................................................................................................................6
2. OBJETIVOS.....................................................................................................................................7
2.1 Objetivo Geral.............................................................................................................................7
2.2 Objetivos Específicos.................................................................................................................7
3. Fundamentação Teórica....................................................................................................................8
3.1 UML – Unified Modeling Language..........................................................................................8
3.1.1 Diagrama UML....................................................................................................................9
3.2SQL-STRUTURED QUERY LANGUAGE................................................................................9
4. Resultados.......................................................................................................................................11
5. Conclusão.......................................................................................................................................13
 1. Introdução

Uma imobiliária é uma empresa responsável por mediar a compra, venda, locação e administração
de imóveis. Sua principal função é intermediar a relação entre cliente, proprietários e instituições bancários
para garantir maior segurança e agilidade nas transações.

Os corretores, profissionais mais relevantes dentro das imobiliárias, realizam o atendimento ao

cliente oferecendo consultoria especializada. Além disso, favorecem a negociação do imóvel buscando
fechar acordos que satisfaçam os interesses de ambas as partes, cliente e proprietário.

A imobiliária é a sua melhor opção na hora de adquirir ou alugar um imóvel, ela cuida de todo o
processo de venda de um imóvel, desde a sua angariação-processo pelo qual adquire o direito de
comercializar esse bem até a entrega das chaves ao novo proprietário.

Um banco de dados é uma coleção organizada de dados ou arquivos relacionados entre si com
registros sobre pessoas, lugares ou coisas. Essas coleções se relacionam de forma a criar algum sentido
(Informação) e dar mais eficiência durante uma pesquisa ou estudo científico. São de vital importância para
empresas e há mais de duas décadas se tornaram a principal peça dos sistemas de informação e segurança.

Com o crescimento das empresas imobiliárias, torna-se necessário uma organização dos processos,
além de automatização, atendendo o cliente satisfatoriamente para que a empresa tenha o amadurecimento
de seus processos e assim possa se estabilizar e continuamente crescer.

Por isso, a implementação de bancos de dados nessa área, demonstrou ser uma mais valia, por
permitir uma melhor organização de todos os componentes presentes no sistema.

Com o este modelo visamos facilitar os processos, e a organização dessas empresas além de dar maior
segurança para sua informação.

1.1Problemática

Os Agentes imobiliários são responsáveis pela seleção de imóveis para serem apresentados para
clientes pela a imobiliária através de placas, jornais de grande circulação e sites, onde se dificulta a emissão
de relatórios e estatísticas de imóveis vendidos.

Com a ampla concorrência no ramo imobiliário contrastando relativamente com a baixa adesão os
serviços e a constante instabilidade do mercado, os desafios enfrentados na gestão de imobiliária
aumentaram gradualmente ao logo dos anos.

Página | 5
 Para ter sucesso nesse ramo não basta apenas possuir muitos imóveis ou uma boa equipe de Agentes
imobiliários.

A qualidade no atendimento aos clientes é um dos problemas enfrentados na gestão de imobiliária

que merece destaque. A utilização de opções obsoletas para controlar o atendimento, como efetuar
anotações manuais de dados e informações sobre os clientes, as chances de ocorrerem falhas são bem
maiores. Desde a troca de informações até o esquecimento de dados cruciais para o fechamento do negócio.

Outro dos problemas enfrentados pelas imobiliárias é pelo controle da sua operação como um todo.

1.2Justificativa

Com a criação de um BD para cadastro de imóveis onde os agentes imobiliários irão cadastrar os
imóveis no sistema para agilizar o processo de busca de imóvel.

Será feito também o cadastro de clientes, agentes imobiliários e os proprietários dos imoveis no
sistema, onde facilitará firmação de contratos.

2. OBJETIVOS

2.1Objetivo Geral

Criar um sistema de cadastro de clientes, imóveis, agentes e proprietários para o gerenciamento dos
mesmos, através do sistema assim agilizando a busca, a venda ou o aluguel de imóveis.

2.2Objetivos Específicos

• Cadastro do agente imobiliário incluindo os seus dados, possibilitando a associação da venda de um

imóvel ao seu ID.
• Cadastro do proprietário incluindo os seus dados, possibilitando a associação de um imóvel.
• Cadastro de cliente e inclusão de dados, possibilitando a compra ou aluguel de um imóvel.
• Cadastro de imóveis e os respetivos dados, possibilitando uma agilidade na busca de um imóvel
pelo agente e pelo cliente.

Página | 6
 3. Fundamentação Teórica

Um Modelo Entidade Relacionamento (MER) é um modelo conceitual utilizado na engenharia de

Software para descrever os objetos (entidades) envolvidos em um domínio, com suas características
(atributos) e como eles se relacionam.

Este modelo representa de forma abstrata a estrutura que possuíra o banco de dados da aplicação.

O Diagrama Entidade Relacionamento (DER) é a representação gráfica de um MER, já que sem uma forma
de visualizar as informações o MER pode ficar abstrato demais para auxiliar no desenvolvimento do
sistema.

3.1UML – Unified Modeling Language

UML é uma linguagem para especificar documentação, visualização e desenvolver sistemas

orientados a objetos. Une os principais métodos existentes, sendo considerada uma das linguagens mais
expressivas para modelar sistemas orientados a objetos.

Ela pode ser utilizada para representar fases dos sistemas, desde os primeiros contatos até a
programação, aplicada em qualquer tipo de sistemas em termos de diagramas de orientação a objeto. Uma
modelagem UML possibilita uma visão dos sistemas, que é extremamente necessária para a compreensão,
documentação e organização dos sistemas.

Por meio de diagramas, é possível representar graficamente os sistemas de diversas formas de

visualização, que facilita o entendimento do sistema que está sendo desenvolvido. Basicamente a UML é
composta de cinco fases no desenvolvimento de software: análise de requisitos, análise, design (projeto),
programação e testes.

Análise de requisitos: deve ser a primeira fase a ser realizada no desenvolvimento de software, pois
visa buscar as funcionalidades do sistema e a necessidade do usuário, que são expressas através das funções
de “Caso de Uso”.

Análise: esta fase faz as abstrações de classes e objetos e outros mecanismos que possam estar
presentes. As classes são modeladas e ligadas através de relacionamentos com outras classes e descritas no
diagrama de classe. Classes que gerenciam o banco de dados, interface, concorrência e outros não estarão
presentes neste diagrama.

Página | 7
 Design (projeto): Nesta fase novas classes são criadas para representar uma infraestrutura interface
do usuário e de periféricos, gerenciamento de banco de dados, comunicação com outros sistemas, dentre
outros.

Programação: Nesta fase as classes criadas na fase do design são convertidas para a linguagem de
programação orientada a objeto.

Testes: Esta fase realiza testes de unidades que são para classes individuais ou grupo de classes,
integração que são aplicados usando as classes e componentes integrados para verificar se as mesmas estão
cooperando umas com as outras como especificado no modelo e aceitação que verifica se o sistema está
funcionando como especificados nos diagramas de “Caso de Uso” (SILVA, 2009).

3.1.1 Diagrama UML

Os diagramas são representações gráficas do modelo que simplificam e melhoram o entendimento

do sistema a ser desenvolvido.

Os relacionamentos são representados por meio de associações, herança, generalização ou refinamento.

Dentre os vários tipos de diagramas da UML, podem-se destacar cinco deles: classes, Caso de Uso,
sequência, colaboração e componentes.

Diagrama de Estados (Máquina de estados)

O diagrama de máquina de estados tem como elementos principais o estado, que modela uma
situação em que o elemento modelado pode estar ao longo de sua existência, e a transição, que leva o
elemento modelado de um estado para o outro.

O diagrama de máquina de estados vê os objetos como maquinas de estados ou autômatos finitos

que poderão estar em um estado pertencente a uma lista de estados finita e que poderão mudar o seu estado
através de um estimulo pertencente a um conjunto finito de estímulos. Ou seja, é utilizado para acompanhar
as mudanças que aconteceram em um determinado objeto dentro de um processo que está sendo executado
no sistema, sendo este um diagrama do tipo comportamental.

Diagrama de Atividades

O diagrama de atividades representa a execução das ações e as transições que são acionadas pela
conclusão de outras ações ou atividades. Uma atividade pode ser descrita como um conjunto de ações e um
conjunto de atividades. A diferença básica entre os dois conceitos que descrevem comportamento e que a

Página | 8
ação e atômica, admitindo particionamento, o que não se aplica a atividade, que pode ser detalhada em
atividades e ações (SILVA, 2007). Tem como objetivo demonstrar o fluxo de atividades de um único
processo e também mostrando como uma atividade depende da outra. Um diagrama de atividade ilustra a
natureza dinâmica de um sistema pela modelagem do fluxo de controle de atividade à atividade. Uma
atividade representa uma operação em alguma classe no sistema que resulta em uma mudança no estado do
sistema. Tipicamente, diagramas de atividades são usados para modelar fluxos de processos, processos de
negócios ou operações internas.

Diagrama de Componentes

O diagrama de componentes e um dos dois diagramas de UML voltados a modelar software baseado
em componentes. Tem por finalidade indicar os componentes do software e seus relacionamentos. (CLAIR
2010) Este diagrama mostra os artefatos de que os componentes são feitos, como arquivos de código fonte,
bibliotecas de programação ou tabelas de bancos de dados. As interfaces e que possibilitam as associações
entre os componentes. Concluindo, tem por finalidade indicar os componentes de software que o sistema
possuirá e também seus relacionamentos, onde são determinadas as configurações de hardware e também
os componentes de software.

Diagrama de Classe

Um diagrama de classes é um modelo fundamental de uma especificação orientada a objetos.

Produz a descrição mais próxima da estrutura do código de um programa, ou seja, mostra o conjunto de
classes com seus atributos e métodos e os relacionamentos entre classes. Classes e relacionamentos
constituem os elementos sintáticos básicos do diagrama de classes (SILVA, 2007). Um diagrama de classes
modela as classes do sistema, bem como seus relacionamentos. Nele, definimos nossas classes, atributos,
métodos, interfaces, heranças, e etc.

Diagrama Entidade Relacionamento

Normalização

A normalização é o processo de organização de dados numa base de dados. Isto inclui criar tabelas e
estabelecer relações entre essas tabelas de acordo com regras concebidas para proteger os dados e para
tornar a base de dados mais flexível eliminando redundância e dependência inconsistente.

Página | 9
 Os dados redundantes ocupam espaço em disco e criam problemas de manutenção. Se os dados
existentes em mais do que um local precisarem de ser alterados, os dados têm de ser alterados exatamente
da mesma forma em todas as localizações

As dependências inconsistentes podem dificultar o acesso aos dados porque o caminho para
encontrar os dados pode estar em falta ou pode estar danificado.

Existem algumas regras para a normalização de bases de dados. Cada regra é denominada
"formulário (ou forma) normal". Se a primeira regra for observada, a base de dados diz que está no
"primeiro formulário normal". Se as primeiras três regras estiverem observadas, a base de dados é
considerada como "terceira forma normal". Embora sejam possíveis outros níveis de normalização, o
terceiro formulário normal é considerado o nível mais elevado necessário para a maioria das aplicações.

Tal como para muitas regras e especificações formais, os cenários do mundo real nem sempre
permitem uma conformidade perfeita.

Primeira forma normal

Para se alcançar a primeira Forma normal deve se eliminar grupos repetidos em tabelas individuais.
Cria-se uma tabela separada para cada conjunto de dados relacionados, identificando cada conjunto de
dados relacionados com uma chave primária.

Não se utilizam vários campos numa única tabela para armazenar dados semelhantes. Por exemplo,
para seguir um item de inventário que possa ter duas origens possíveis, um registo de inventário pode
conter campos para o Código do Fornecedor 1 e o Código do Fornecedor 2.

Segunda forma normal

Para se atingir a Segunda Forma Normal Criam-se tabelas separadas para conjuntos de valores que
se aplicam a registos diversos, relacionando estas tabelas com uma chave externa. Os registos não devem
depender de nada além da chave primária de uma tabela (uma chave composta, se necessário).

Terceira forma normal

Para a Terceira Forma Eliminam-se os campos que não dependem da chave. Os valores num registo
que não façam parte da chave do registo não pertencem na tabela. Em geral, sempre que os conteúdos de
um grupo de campos possam ser aplicados a mais do que um único registo na tabela, considere colocar
esses campos numa tabela separada.

Página | 10
 EXCEÇÃO: A adesão à terceira forma normal, apesar de teoricamente desejável, nem sempre é
prática. Se tiver uma tabela Clientes e pretender eliminar todas as dependências entre campos possíveis,
deverá criar tabelas separadas para cidades, códigos postais, representantes de vendas, classes de clientes e
qualquer outro fator que possa ser duplicado em múltiplos registos. Teoricamente, vale a pena tentar a
normalização. No entanto, muitas tabelas pequenas podem afetar o desempenho ou exceder as capacidades
de ficheiros abertos e de memória.

Poderá ser mais viável aplicar a terceira forma normal apenas aos dados que são alterados
frequentemente. Se forem mantidos alguns campos dependentes, programe a sua aplicação para requerer
que o utilizador verifique todos os campos relacionados quando um deles for alterado.

Página | 11
 4. Resultados

Para a criação do nosso modelo começamos por fazer a criação de 5 tabelas (entidades) utilizando
o Excel. A planilha possui 5 tabelas que são: Proprietário, Imóvel, Cliente, Agente Imobiliário
(corretor) e Contrato.

Todas as entidades são físicas, porque existem e são palpáveis.

A Entidade Proprietário é uma entidade forte (independe de outras para existir): e possui como atributos
id_Proprietario, Nome, Email, BI e Telefone.

A Entidade Imóvel é uma entidade forte e possui como atributos: id_Imovel, Descrição, Localização,
Preço e Estado.

A Entidade Cliente é uma entidade forte e possui como atributos: id_Cliente, Nome, Email, BI e Telefone.

A Entidade Agente Imobiliário é uma entidade forte e possui como atributos: id_Agente, Nome, Comissão,
BI e Contactos.

A Entidade Contrato é uma entidade fraca (depende de outras para existir) e possui como atributos
id_Contrato, Tipo, Valor, Clausulas e Data.

Página | 12
Utilizando o Workbench criamos a base de dados da Agência.

Página | 13
 5. Conclusão

Durante as pesquisas realizadas podemos desenvolver uma solução para determinada gama de
profissionais.

Tem a finalidade de auxiliar esses profissionais, ou seja, não existe pretensão de substituir o
trabalho humano, mas sim, tentar dar mais agilidade e precisão para reduzir perca de tempo e
informação.

Com o modelo proposto todos os dados são de fácil inserção e consulta, promovendo assim um melhor
poder de analise sobre tais informações.

Vale ressaltar que os modelos foram feitos com a utilização das ferramentas StarUML e Workbench.

Página | 14