Modelagem de

Dados
A Importância da Modelagem
Conteúdo
◼ Modelagem de Dados - A Importância da
Modelagem
◼ Tipos de Relação
◼ Levantamento de Dados
◼ Declaração de Escopo
A Importância da Modelagem
◼ A modelagem de bancos de dados é
necessária para que se diminua ao
mínimo possível a possibilidade de erros e
inconsistências no banco de dados.
◼ A modelagem pode ser feita manualmente
ou por meio de softwares específicos que
podem utilizar a simbologia conhecida
como Cross Foot (pé-de galinha).
◼ A Modelagem de Dados pode ser
considerada a etapa mais importante para
desenvolver um Banco de Dados, pois é
aqui que fazemos o Levantamento dos
Requisitos para construção do BD e muito
mais que isso, no caso de vocês é aqui
que começa o Projeto do curso!
Levantamento de Dados
(ou Levantamento de Requisitos)
Para se desenvolver um sistema de banco de dados,
não basta apenas ter conhecimento das técnicas de
modelagem. É necessário que se conheçam as
regras do problema que o sistema se propõe a
automatizar. Assim, a fase primordial do
desenvolvimento de um sistema de banco de dados
é o levantamento de dados. Nesta fase, o
projetista do sistema faz a coleta das informações
que julgar relevantes ao desenvolvimento do banco
de dados por meio de várias técnicas, dentre as
quais destacam-se questionários, análise de
sistemas anteriores e entrevistas.
O levantamento de requisitos é umas das partes mais
importantes do processo que resultará no desenvolvimento
de um sistema. Entender aquilo que o cliente deseja ou o
que o cliente acredita que precisa e as regras do negócio ou
processos do negócio.

São as necessidades do Cliente!

Por isso que devemos conhecer as suas necessidades e

documentar, isso é o primeiro passo para desenvolver um
projeto.

Existem diversas técnicas que podem ser utilizadas para o

Levantamento dos Requisitos, iremos citar 3 das mais
usadas.
Questionários
Essa técnica tem como ponto positivo o fato de
que o usuário ou cliente não tem a necessidade
de interromper seus afazeres para atender ao
desenvolvedor, podendo respondê-lo no
momento que julgar mais apropriado; porém
essa “ausência” do desenvolvedor pode fazer
com que a pessoa não leve o questionário a
sério, respondendo de forma displicente ou
simplesmente deixando de responder parte ou
totalidade das questões.
Análise de Sistemas Anteriores

◼ Se a empresa já possui um sistema

informatizado, a observação de telas de
preenchimento, coleta e exibição de
dados e de relatórios impressos pode dar
ao desenvolvedor informações inerentes
ao que se deseja para o nome banco de
dados.
Entrevistas
◼ Sem sombra de dúvida, as entrevistas são
o meio mais eficaz de se obterem os
dados relevantes ao desenvolvimento de
um novo sistema, mas deve-se levar em
consideração a necessidade de se
entrevistar a pessoa certa.
Declaração de Escopo
◼ Contém toda a especificação que o usuário
deseja de como os dados e procedimentos
devem ser trabalhados no sistema.
◼ Depois de ter a Declaração de Escopo
devidamente avaliada e aprovada por parte
dos usuários, passa-se ao processo de
Modelagem do Banco de Dados do
Sistema.
◼ Portanto, é de grande importância termos
o conhecimento da regra do negócio,
como funciona cada etapa com seus
detalhes e particularidades, assim
podemos abstrair e começar a
desenvolver o BD e o sistema em si
próprio.
 Modelo Conceitual – Entidades e
Atributos
◼ Devemos nessa primeira parte ter conhecimento do
problema (levantamento dos requisitos), após isso
passamos para o Modelo Conceitual, Lógico e por último o
Físico.
◼ Modelo Conceitual – Apresenta a estrutura dos dados que
podem aparecer no banco de dados, independente do
aplicativo que será utilizado (SGBD)
◼ Modelo Lógico – Apresenta o nível de abstração visto pelo
usuário do SGBD, portanto depende do aplicativo que será
utilizado.
◼ Modelo Físico – Apresenta os detalhes de armazenamento
interno de informações que, apesar de não influenciarem a
programação de aplicações, influenciam a performance
delas.
Modelo Entidade-
Relacionamento (MER)
◼ O Modelo Entidade-Relacionamento (MER) foi
criado em 1976 por Peter Chen. É o modelo
mais utilizado atualmente, devido,
principalmente, à sua simplicidade e eficiência.
Baseia-se na percepção do mundo real, que
consiste em uma coleção de objetos básicos,
chamados Entidades, e em Relacionamentos
entre esses objetos.
◼ Uma entidade é um objeto do mundo real
que pode ser distinguido de outros
objetos.

◼ Toda entidade tem seus respectivos

atributos.
Entidade e Atributos

Melhor assim...
◼ Além de determinar quais são as
entidades que existirão no banco de
dados e seus atributos, o Diagrama de
Entidade e Relacionamento (feito por
meio do modelo de entidade e
relacionamento) deve também indicar os
relacionamentos entre estas entidades.
Entidades
◼ Conjunto de objetos da realidade modelada sobre
os quais deseja-se manter informações no banco
de dados. É algo no ambiente do domínio do
problema.

◼ Exemplo: Em um sistema de um Banco, as

seguintes entidades são possíveis:

· Clientes
· Contas correntes
· Transações
· Agências
Entidades
◼ A entidade pode ser:
· Objeto Concreto – pessoa, automóvel, etc.
· Objeto Abstrato – departamento,
qualidade, etc.
Simbologia – retângulo com o nome da
entidade.

Cliente
Entidades
◼ A entidade isoladamente não informa
nada, por isso possuem propriedades, tais
como:
· Atributos
· Relacionamentos
· Generalizações / Especializações
Atributos
◼ Dado, ou informação, que é associada a
cada ocorrência de uma entidade ou de
um relacionamento. Ele descreve a
entidade.

◼ Simbologia – atributos são representados

apenas pelo seu nome ligado à entidade
por uma linha reta.
nome
Cliente
Atributos – Chave Primária
◼ No caso de chave primária, para
identifica-la, basta sublinhar.

cod_cliente
Cliente
nome
Diagrama de Entidade e
Relacionamento - ER
◼Denominação dos Relacionamentos –
Basicamente, um relacionamento é
expresso através de uma construção
verbal.
Ex: Relacionamento entre os objetos
CARRO e PESSOA.
PESSOA utiliza CARRO ou CARRO é
utilizado por PESSOA.
Relacionamentos
◼ Representar os novos relacionamentos no
modelo – utiliza-se o verbo de ligação.
◼ Simbologia:

utiliza
Exemplo – Entidade e
Relacionamento - ER

Pessoa utiliza Carro

Como convenção, adota-se que o relacionamento deve

ser entendido da esquerda para a direita ou de cima
para baixo.
Ex: PESSOA utiliza o CARRO, e não vice-versa.
 Outros Exemplos

Processo pertence Documento

Empregado gerencia Departamento

Cardinalidade ou Grau do
Relacionamento
◼ Outro aspecto importante na modelagem
de bancos de dados é a cardinalidade.
◼ A Cardinalidade apresenta o número de
entidades com as quais uma outra
entidade se relaciona ou, simplificando,
quantas linhas de uma tabela se
relacionam com as linhas de outra tabela.
◼ Esse requisito procura apresentar regras
para o estabelecimento das associações
entre os elementos.
◼ Essas regras não devem ser impostas,
mas sim observadas no ambiente em
questão.
◼:
◼ Genericamente, temos:

◼ Devemos responder às seguintes perguntas:

1. Com quantos elementos do tipo B pode se
relacionar cada um dos elementos do tipo A?
2. Dado um elemento do tipo B, com quantos
elementos do tipo A ele se relaciona?
◼ Exemplo: Vamos utilizar o relacionamento entre
PESSOA e CARRO, apresentado anteriormente.

◼ Quantos CARROS utiliza cada uma das

PESSOAS?

◼ R: Uma PESSOA utiliza vários CARROS, um de

cada vez.

◼ Dado um CARRO, por quantas PESSOAS ele pode

ser utilizado?

◼ R: Um CARRO é utilizado por uma única PESSOA,

em nosso caso.
◼ A representação desse relacionamento é:

N
◼ O raciocínio seguido é:

“Uma Pessoa utiliza N Carros, um Carro é utilizado só por 1 Pessoa”

Cardinalidade
◼ Os graus de relacionamento, ou
cardinalidade, podem ser dos seguintes
tipos:
· 1:1 (Um para Um)
· 1:N (Um para Muitos)
· M:N (Muitos para Muitos)
 Outros Exemplos
1 1
Empregado gerencia Departamento

N N
Empregado participa Projetos

1 N
Empregado coordena Projetos
 Grau de Cardinalidade
◼ Outro aspecto importante, sobre relacionamentos,
que deve ser levado em consideração quando da
modelagem conceitual, é a obrigatoriedade ou não
da participação dos elementos nas associações.

◼ O Cardinalidade (Grau) Máximo é representado

pelo Cardinalidade (Grau) que representamos até
agora, podendo ser 1:1, 1:N ou M:N.

◼ O Cardinalidade (Grau) Mínimo indica o menor

valor possível de participação dos elementos do
conjunto A e B no relacionamento.
Exemplo
◼ Observemos o exemplo das entidades
ESCOLA e ALUNO:

Escola atende Alunos

◼ Analisemos o caso:
· Uma ESCOLA atende no mínimo (pelo menos) 1
ALUNO e no máximo (até) N ALUNOS.
· Um ALUNO é atendido no mínimo (pelo menos) por 1
ESCOLA e no máximo (até) por 1 ESCOLA.
◼ A representação dos graus mínimo e
máximo do relacionamento é:

A Cardinalidade (Grau) Mínimo pode assumir dois valores:

· 0 (zero) – indica a possibilidade de não participação ou opcionalidade
· 1 (um) – indica a obrigatoriedade de participação
Referências
[YOURDON e COAD] Edward Yourdon e Peter Coad. Análise
Baseada em Objetos. Ed. Campus. 2008 São Paulo/SP

◼ http://www.baguete.com.br/artigos/296/ricardo-
verissimo/05/11/2007/levantamento-de-requisitos-e-mapeamento-
de-processos

◼ http://www.cpdti.com.br/portal/forum/index.php?topic=53.0

◼ http://www.assembla.com/spaces/modelo_projeto_uml/wiki/Diagram
as/print