09 - Modelagem de Dados

Modelagem de Dados
Material Teórico
Banco de Dados
Responsável pelo Conteúdo:

Prof. Esp. Hugo Fernandes
Revisão Textual:
Profa. Ms. Natalia Conti
Banco de Dados
• Evolução Histórica de Banco de Dados

• O que é um Banco de Dados
• O que é um Sistema Gerenciador de Banco de Dados
• A Importância dos Bancos de Dados
OBJETIVO DE APRENDIZADO
· Apresentar o histórico e a evolução dos bancos de dados, suas utiliza-
ções, modelos e os principais bancos de dados em uso no mercado.
UNIDADE Banco de Dados
Evolução Histórica de Banco de Dados

Os seres humanos começaram a armazenar informações há muito tempo. Há
décadas atrás, elaborados sistemas de banco de dados foram desenvolvidos por
escritórios governamentais, bibliotecas, hospitais e organizações empresariais, e
alguns dos princípios básicos desses sistemas ainda estão sendo usados hoje.
A seguir, iremos apresentar de maneira cronológica os principais destaques

ocorridos na evolução dos bancos de dados eletrônicos.
• 1960: Foi marcada pela criação de banco de dados eletrônicos. O
desenvolvimento do IMS (um banco de dados hierárquico criado pela IBM) e o
aparecimento dos primeiros sistemas de banco de dados de redes.
• 1970: Surgimento do Modelo de dados relacional e a implementação de
sistemas de banco de dados relacionais.
• 1980: SQL (Structured Query Language) se torna um padrão mundial para
os modelos relacionais. Sistemas de banco de dados orientados à aplicações
(espacial, científico, de engenharia, etc.).
• 1990: Data mining, data warehousing, bancos de dados multimídia e bases
de dados Web e os primeiros protótipos dos modelos orientados a objetos.
• Anos 2000: Gerenciamento de dados de fluxo e mineração.
»» Mineração de dados e suas aplicações
»» Tecnologia da Web
»» XML
»» Integração de dados
»» Redes Sociais
»» Computação em nuvem
»» Sistemas de informação globais
O que é um Banco de Dados

Um banco de dados é uma coleção de dados. Essa definição pode parecer muito
simples, não é mesmo? Mas resume muito bem o que qualquer banco de dados é.
Os bancos de dados suportam armazenamento e manipulação de dados, sejam eles
eletrônicos ou não.
Um banco de dados pode ser tão simples quanto um arquivo de texto com
uma lista de nomes. Ou podem ser tão complexos quanto um grande sistema de
gerenciamento de banco de dados relacional, com ferramentas embutidas para
ajudá-los a manter os dados.
8
Em nosso cotidiano interagimos com bancos de dados em muitos momentos.
Uma lista de telefones on-line, por exemplo, definitivamente usaria banco de dados
para armazenar dados relativos à pessoas, números de telefone, outros detalhes de
contato, etc.
Sua prestadora de serviços de eletricidade utiliza um banco de dados para

gerenciar o faturamento, problemas relacionados com o cliente, para lidar com
dados de panes, etc.
Consideremos também o facebook. Ele precisa armazenar, manipular e

apresentar dados relacionados a usuários, seus amigos, mensagens, anúncios e
muito mais.
Explor
Qual é o Banco de Dados mais utilizado no mundo?

https://goo.gl/bQdRET
O que é um Sistema Gerenciador

de Banco de Dados
Sistema de Gerenciamento de Banco de Dados (SGBD) é um conjunto de
programas que permitem aos seus usuários controlar o acesso ao banco de dados,
manipular dados, relatórios / representação de dados.
A seguir serão apresentados os quatro principais modelos ou tipos de SGBD.
Importante! Importante!
SGBD é o nome dado aos softwares que gerenciam bancos de dados, e não o tipo do
banco de dados.
Hierárquico
O modelo hierárquico foi desenvolvido nos anos 60 para gerenciar grandes
quantidades de dados para projetos de fabricação complexos. Sua estrutura lógica
básica é representada por uma árvore de cabeça para baixo. A estrutura hierárquica
contém níveis ou segmentos.
Um segmento é o equivalente ao tipo de registro de um sistema de arquivos.
Dentro da hierarquia, uma camada superior é percebida como o pai do segmento
diretamente abaixo dele, que é chamado de filho. O modelo hierárquico descreve
um conjunto de relações um-para-muitos (1: M) entre um pai e seus segmentos
filhos. (Cada pai pode ter muitos filhos, mas cada filho tem apenas um pai.).
O editor de registro do Windows (figura 1) é um exemplo de um banco de
dados hierárquico.
9
9
Figura 1
Um SGBD nesse modelo possui as seguintes vantagens:

• Simplicidade conceitual
• Segurança de banco de dados
• Independência dos dados
• Integridade do banco de dados
• Eficiência em lidar com uma grande base de dados
Quanto às desvantagens:
• Implementação complexa
• Difícil gerenciamento
• Falta de independência estrutural
• Limitações de implementação
• Falta de normas e padrões bem definidos
Exemplos de sistemas de gerenciamento de banco de dados hierárquico incluem

os bancos de dados Information Management System (IMS) e o SYSTEM 2000.
Rede
Consideramos o SGBD um modelo em rede, quando este organiza os dados
em uma estrutura de rede. Isso geralmente resulta em complexas estruturas de
banco de dados. Comparando como o modelo hierárquico, no modelo em Rede, o
registro filho pode possuir diversos pais, pois em uma rede os nós podem ter tantas
conexões quanto possível.
10
Figura 2
Fonte: pixabay.com
Embora o modelo de banco de dados de rede seja pouco utilizado hoje em dia,
as definições de conceitos de banco de dados que surgiram com esse modelo ainda
são usadas por modelos de dados mais modernos. Alguns conceitos importantes
que foram definidos neste momento são:
• O esquema, que é a organização conceitual de todo o banco de dados visto
pelo administrador do banco de dados.
• O subesquema, que define a parte do banco de dados “visível” pelos programas
aplicativos que produzem as informações desejadas a partir dos dados contidos
no banco de dados.
• O Data Manipulation Language (DML), que é a linguagem que define o
ambiente no qual os dados podem ser gerenciados e para trabalhar com os
dados no banco de dados.
• O Data Definition Language (DDL), uma linguagem de definição de dados
de esquema que permite ao administrador do banco de dados definir os
componentes do esquema.
Um SGDB de Rede possui as seguintes vantagens:

• Simplicidade conceitual
• Permite gerenciar uma grande quantidade de relações
• Possibilita a flexibilidade de acesso a dados
• Promove a integridade do banco de dados
• Favorece a independência dos dados
• Possui normas e padrões bem definidos
11
11
• Complexidade do sistema
• Falta de independência estrutural
O RDM Server, IDMS e TOTAL são exemplos de sistemas de gerenciamento

de banco de dados que implementam o modelo de rede.
Relacional
Esse tipo de SGBD define relações de banco de dados em forma de tabelas,
também conhecidas como relações. Ao contrário do SGBD de rede, o tipo relacional
não suporta relacionamentos do tipo muitos para muitos.
Criado na década de 1970 por Edgar Frank Codd, pesquisador da IBM, a

base do modelo relacional é um conceito matemático conhecido como relação. O
modelo de dados relacional executa as mesmas funções básicas fornecidas pelos
SGBDs dos tipos hierárquico e de rede, além de uma série de outras funções que
tornam o modelo de dados relacional mais fácil de entender e implementar. Este é
o tipo de SGBD mais popular no mercado
Explor
Conceito de relação matemática: https://goo.gl/ZWhdCM

As regras de Codd para Bancos de Dados Relacionais: https://goo.gl/o4GUvg
Uma das grandes vantagens desse modelo (SGBD-R) é a sua capacidade de

ocultar as complexidades do modelo relacional do usuário. O SGBD-R gerencia
todos os detalhes físicos, enquanto o usuário vê o banco de dados relacional como
uma coleção de tabelas nas quais os dados são armazenados. O usuário pode
manipular e consultar os dados de uma forma que parece intuitiva e lógica.
Uma tabela relacional armazena uma coleção de dados relacionados. A este

respeito, a tabela de banco de dados relacional se assemelha a um arquivo, disposta
em linhas e colunas.
Tabela 1
Id Nome Rgm Sexo DtNasc
123 João 42315 M 13/03/1985
124 Maria 42888 F 21/08/1990
Outra grande vantagem é a sua linguagem de consulta poderosa e flexível, o

Structured Query Language (SQL), que permite ao usuário especificar o que deve
ser feito sem especificar como deve ser feito. O SGBD-R usa o SQL para traduzir
consultas de usuários em instruções para recuperar os dados solicitados. O SQL
torna possível recuperar dados com muito menos esforço do que qualquer outro
banco de dados ou ambiente de arquivos.
12
O SGBD-Relacional possui as seguintes vantagens:
• A independência estrutural
• Melhor simplicidade conceitual
• Projeto, implementação, gerenciamento e uso mais simples de banco de dados
• Sistema de gerenciamento de banco de dados poderoso
Quanto às desvantagens, temos:

• Sobrecarga substancial de hardware e software de sistema
• Possibilidade de má concepção e implementação
Exemplos de sistemas de gerenciamento de banco de dados relacional incluem

banco de dados MySQL, Oracle e Microsoft SQL Server.
Orientado a Objetos
No SGBD orientado a objetos (SGBD-OO), tanto os dados como suas relações
estão contidos em uma única estrutura conhecida como objeto. Este modelo de
dados é outro método de representar objetos do mundo real. Considera cada objeto
no mundo como objetos e os isola uns dos outros.
O SGBD-OO baseia-se nos seguintes componentes:

• Um objeto é uma abstração de uma entidade do mundo real. Em termos
gerais, um objeto pode ser considerado equivalente a uma tabela do SGBD-
Relacional. Mais precisamente, um objeto representa apenas uma ocorrência
de uma entidade.
• Atributos descrevem as propriedades de um objeto. Por exemplo, um objeto
PESSOA inclui os atributos Nome, Número de Segurança Social e Data de
Nascimento.
• Objetos que compartilham características semelhantes são agrupados em
classes. Uma classe é uma coleção de objetos semelhantes com estrutura
compartilhada (atributos) e comportamento (métodos). O método de uma classe
representa uma ação no mundo real, como encontrar o nome de uma pessoa
selecionada, alterar o nome de uma pessoa ou imprimir o endereço de uma
pessoa. Em outras palavras, os métodos são o equivalente a procedimentos
em linguagens de programação tradicionais. Em termos orientado a objetos,
os métodos definem o comportamento de um objeto.
• As classes são organizadas em uma hierarquia de classes. A hierarquia de
classe se assemelha a uma árvore invertida na qual cada classe tem apenas um
pai. Por exemplo, a classe CLIENTE e a classe EMPREGADO compartilham
uma classe pai PESSOA, o que chamamos de herança.
• A herança é a capacidade de um objeto dentro da hierarquia de classe herdar
os atributos e métodos das classes acima dele. Por exemplo, duas classes,
13
13
CLIENTE e EMPREGADO, podem ser criadas como subclasses da classe

PESSOA. Nesse caso, CLIENTE e EMPREGADO herdarão todos os atributos
e métodos de PESSOA.
Pessoa
+ Id
+ nome
+ email
+ telefone
+ imprimeDados()
Cliente Empregado
+ endereçoEntrega + endereçoEntrega
+ imprimeEndereço() + setor
+ cadastraCliente(pessoa: Pessoa ) + cargo
+ salário
+ cadastraEmpregado(pessoa: Pessoa )
Figura 3
As vantagens oferecidas por esse modelo são as seguintes:

• Apresentação visual inclui conteúdo significativo
• Alta integridade do banco de dados
• Independência estrutural e de dados
• Falta de normas e padrões bem definidos
• Acesso complexo aos dados de navegação
• Curva de aprendizagem íngreme
Exemplos de sistemas de gerenciamento de banco de dados orientados a

objetos incluem os bancos de dados CACHÉ, DB4Objects, VERSANT, JASMIN
e MATISSE.
Explor
SGBD-OO - Banco de Dados Orientado a Objetos: Uma Realidade: https://goo.gl/7MtFLe
14
A Importância dos Bancos de Dados
As informações são úteis para relatar a uma organização os resultados de suas
operações atuais e colaborar com a gestão de estratégias para os negócios.
As informações organizacionais são armazenadas em um banco de dados.

Aplicativos e programas, como sistemas de gerenciamento da cadeia de suprimentos
e sistemas de gerenciamento de relacionamento com o cliente, acessam os dados
no banco de dados para que o programa possa consultá-lo e exibir de maneira
intuitiva o que está acontecendo com o negócio.
O valor da informação reside não apenas na própria informação, mas nas

ações que surgem da informação. Por exemplo, se as informações o alertarem
para a má satisfação do cliente, isso só será útil se isso criar uma mudança na
forma como o negócio lida com os clientes. Assim, o processo de informação
deve fazer parte de um processo de revisão mais amplo dentro do negócio para
obter os melhores resultados.
Nesse contexto, um banco de dados se faz importante, pois gerencia e

possibilita o acesso à informação. Elaborar como os dados serão armazenados, e
de qual forma, é parte extremamente relevante para o sucesso do gerenciamento
e manutenção do banco de dados, tão vital e essencial para a organização. Nos
capítulos seguintes, iniciaremos nossos estudos sobre a modelagem de dados.
Até breve.
15
15
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
Livros
Sistemas de Banco de Dados
Livro: Sistemas de Banco de Dados - 6ª edição
Elmasri, Ramez; Navathe, Shamkant B.
Capítulos:
1 - Banco de dados e os usuários de banco de dados
2 - Conceitos e arquitetura do sistema de banco de dados
Dominando o Oracle 9i: modelagem e desenvolvimento
Livro: Dominando o Oracle 9i: modelagem e desenvolvimento
Fanderuff, Damaris
Capítulo: 1 - Introdução a bancos de dados
Banco de Dados: princípios e prática
Livro: Banco de Dados: princípios e prática
Luciano Frontino de Medeiros
Capítulo:1 - Introdução ao banco de dados
Leitura
Histórico dos Banco de Dados
https://goo.gl/4HT1Y8
Edgar Frank Codd e o Banco de Dados Relacional: uma contribuição para a História da Computação
https://goo.gl/sKRDdj
16
Referências
Elmasri, Ramez. Sistemas de Banco de Dados. 6. ed. São Paulo: Pearson Addison
Wesley, 2011.
Fanderuff, Damaris. Dominando o Oracle 9i: Modelagem e Desenvolvimento.

São Paulo : Pearson Education do Brasil, 2003.
Júnior, E; Alonso, S. Histórico dos Banco de Dados. Disponível em:

<http://disciplinas.dcc.ufba.br/svn/MATA60/tarefa1/historico/historico.
pdf?revision=21>. Acesso em: 08 de fev. 2017.
17
17
Material Teórico
Etapas de um Projeto de Banco de Dados

Revisão Textual:
Profa. Ms. Natalia Conti
Etapas de um Projeto
de Banco de Dados
• Introdução à Modelagem de Dados

• Levantamento de Requisitos e Regras de Negócios
• Níveis de Modelagem: Modelos Conceitual, Lógico e Físico
· Apresentar o conceito de modelagem de dados e seus níveis de
abstração, bem como a importância do levantamento de requisitos
e regras de negócio para o processo de desenvolvimento do projeto
de banco de dados.
UNIDADE Etapas de um Projeto de Banco de Dados
Introdução à Modelagem de Dados

Modelagem de dados é um passo essencial no processo de criação de qualquer
software complexo. No centro da modelagem de banco de dados está a ideia
de projetar uma estrutura de banco de dados que define como as informações
armazenadas podem ser acessadas, categorizadas e manipuladas e, em última
análise, qual história essa informação dirá.
As técnicas e ferramentas de modelagem de dados capturam e traduzem projetos

de sistemas em representações de fácil compreensão dos fluxos e processos
de dados.
Se a ferramenta de software que você está usando para seus dados é o cérebro,
a modelagem de dados define como os neurônios se conectam uns aos outros.
As escolhas de modelagem de dados precisarão ser feitas no início de qualquer
implantação de software e terão grande impacto no sucesso geral do projeto.
A modelagem de dados tem como objetivos:

• Identificar os diferentes componentes de dados - considerar dados brutos e
processados, bem como entidades.
• Identificar as relações entre os diferentes componentes de dados (estes são
chamados associações).
• Identificar os usos antecipados dos dados (chamados requisitos), com o
reconhecimento de que os dados podem ser mais valiosos no futuro para usos
não previstos.
• Identificar os pontos fortes e restrições da tecnologia (hardware e software) que
você planeja usar durante o projeto.
• Construir um modelo preliminar das entidades e suas relações, tentando
manter o modelo independente de quaisquer usos específicos ou restrições
de tecnologia.
O modelo de dados é equivalente aos planos de construção de um arquiteto.
Modelos de Dados
Como destacado por Cougo (1997), um modelo é a representação abstrata e
simplificada de um sistema real. No contexto da modelagem de dados, utilizamos
modelos para representar dados em um sistema, como são gerados, se relacionam
e se transformam. O caminho do dado até sua transformação em informação.
8
Explor
Qual a diferença entre Dados, Informação e Conhecimento: https://goo.gl/nrxvjD
Para construir modelos de dados, utilizamos linguagens de modelagem de dados,

descrevendo os modelos em formatos textuais ou gráficas. Dessa forma, o mesmo
modelo pode ser apresentado de formas diferentes.
Um modelo de dados, por exemplo, pode ser pensado como um fluxograma

que ilustra as relações entre os dados. Embora capturar todas as relações possíveis
em um modelo de dados pode ser muito demorado, é um passo importante que
não deve ser apressado. Modelos de dados bem documentados permitem que os
interessados identifiquem erros e façam alterações antes de qualquer código de
programação ter sido escrito.
Como um arquiteto que planeja uma casa, que ouve e discute com seu cliente
a disposição dos cômodos e todos os outros detalhes da futura casa, o analista
responsável pela modelagem de dados deve ter em mente que os processos de
levantamento e análise de dados são indispensáveis para o seu trabalho. Sendo
capaz de observar o mundo real e em seguida materializar o objeto observado em
um modelo de dados.
Mas afinal, por que o modelo de dados é tão importante? O modelo de dados,
como já mencionado, orienta e define como os dados se comportarão em um
sistema. Além disso, serve como um marco importante dentro do ciclo de evolução
do processo de modelagem, pois por meio desse artefato, os atores envolvidos no
processo podem validar o que está sendo projetado.
Em Síntese Importante!
É nesse momento em que o analista responsável pelo planejamento do banco de da-

dos valida junto ao seu cliente o que ele observou e se o que foi observado condiz com
a realidade.
Vamos a um exemplo prático. Imagine que temos a tarefa de planejar um mo-

delo de banco de dados para um cliente que possui uma loja de Petshop. Para
o contexto desse nosso primeiro exemplo, em nossa primeira entrevista com o
cliente, temos que investigar e analisar como o negócio de nosso cliente funciona
em nível estrutural, ou seja, quais são os departamentos, suas relações e funções.
• Cliente: Minha loja possui dois setores. Um setor é a loja, onde vendo diversos
produtos para animais. No outro setor, eu ofereço os serviços de Veterinário,
banho e tosa.
9
9
A partir dessa primeira conversa, criamos nosso primeiro modelo.
PetShop
Banho e Tosa
Loja &
Veterinário
Figura 1
Em nossa disciplina, iremos abordar os três tipos de modelos de dados utilizados

no processo de modelagem de dados, que são eles: Modelo conceitual, Modelo
Lógico e Físico. Cada modelo com suas particularidades e desempenhando um
papel fundamental em fases diferentes do ciclo de evolução do processo de mode-
lagem de dados.
Antes de nos aprofundar um pouco mais sobre os modelos de dados, devemos

estudar um pouco sobre a identificação das regras de negócios e o levantamento de
requisitos. Essa análise é fundamental para que possamos criar modelos abstratos
mais fiéis ao “mundo real”.
Levantamento de Requisitos
e Regras de Negócios
Levantamento de Requisitos
Requisitos de sistemas são os artefatos que determinam o que o sistema deve
fazer. O objetivo do levantamento de requisitos é identificar a situação do mundo
real em detalhes suficientes para ser capaz de definir componentes de banco de
dados, coletando principalmente dois tipos de dados: dados naturais (entrada para
o banco de dados) e processamento de dados (saída do banco de dados).
Nessa etapa, o analista responsável deve buscar basicamente o seguinte:

• Delinear os requisitos de dados da empresa em termos de elementos de da-
dos básicos.
• Descrever as informações sobre os elementos de dados e as relações entre eles
necessários para modelar esses requisitos de dados
• Determinar os tipos de transações que se pretende executar no banco de
dados e a interação entre as transações e os elementos de dados
10
• Definir quaisquer restrições de desempenho, integridade, segurança ou
administrativas que devem ser impostas ao banco de dados resultante.
• Especificar quaisquer restrições de projeto e de implementação, como tecno-
logias específicas, hardware e software, linguagens de programação, políticas,
padrões ou interfaces externas.
Essas informações podem ser reunidas de várias maneiras:

• Revisão de documentos existentes: tais documentos incluem formulários
e relatórios existentes, diretrizes escritas, descrições de cargos, narrativas
pessoais e memorandos. A documentação em papel é uma boa maneira de
se familiarizar com a organização ou atividade que você precisa para modelar.
• Entrevistas com usuários finais: podem ser uma combinação de reuniões
individuais ou em grupo. Tente manter as sessões com grupos de até seis pes-
soas. Se possível, com pessoas que tenham/pertençam à mesma função ou
cargo em uma reunião.
• Revisão de sistemas automatizados existentes: se a organização já possui
um sistema automatizado, revise as especificações de projeto do sistema e a
documentação.
A análise e o levantamento de requisitos geralmente é feita ao mesmo tempo
que a modelagem de dados. À medida que as informações são coletadas, os
objetos de dados são identificados e classificados como entidades, atributos ou
relacionamentos. Os objetos são então modelados e analisados usando diagramas.
Esses diagramas podem ser revistos pelo analista e pelos usuários finais para
determinar sua precisão. Se o modelo não estiver correto, ele é modificado, o que
às vezes requer informações adicionais a serem coletadas. O ciclo de revisão e
edição continua até que o modelo seja certificado como correto.
Na dinâmica do levantamento e análise de requisitos, temos que ter em mente
três pontos:
1. Converse com os usuários finais sobre seus dados em termos de “mundo real”.
Os usuários não pensam em termos de entidades, atributos e relacionamentos,
mas sobre as pessoas, coisas e atividades reais que lidam diariamente.
2. Aproveite o tempo para aprender o básico sobre a organização e as atividades
que você deseja modelar. Ter um entendimento sobre os processos tornará
mais fácil a construção do modelo.
3. Os usuários finais normalmente pensam e visualizam dados de diferentes
maneiras de acordo com sua função ou cargo dentro de uma organiza-
ção. Portanto, é importante entrevistar o maior número de pessoas que o
tempo permite.
É válido ressaltar que o levantamento de requisitos aborda somente a identificação

dos objetos (entidades, atributos ou relacionamentos), o que o sistema deve fazer.
Como e quando os dados serão armazenados está a sob a responsabilidade da
identificação das regras de negócios.
11
11
Regras de Negócios
Uma regra de negócios é independente do paradigma de modelagem, software
ou hardware. Uma regra de negócios é uma declaração que define ou restringe
alguns aspectos do negócio.
Identificar e documentar regras de negócios é um processo muito importante para

o analista responsável pela modelagem de dados. As regras de negócios permitem
que o analista desenvolva regras e restrições de entidades e relacionamentos e crie
um modelo de dados condizente com o “mundo real”.
Regras de negócios também permitem aos analistas entender os processos de

negócios, bem como a natureza, o papel e o escopo dos dados. Elas são uma
ferramenta de comunicação entre usuários e criadores, e também ajudam a
padronizar a visão da empresa sobre os dados.
Regras de Negócios dão a classificação adequada de entidades, atributos, relações

e restrições. Fontes de regras de negócios são gerentes, gerentes de departamento,
documentação escrita, procedimentos, padrões, manuais de operação e entrevistas
com usuários finais.
Alguns exemplos de regras de negócio:

• Todo cliente deve estar cadastrado em nosso sistema.
• O CPF e e-mail devem ser campos obrigatórios no cadastro do cliente.
• Toda venda deve gerar um cupom fiscal.
• O campo CPF é obrigatório para a geração do cupom fiscal.
• Uma venda deve ser realizada somente por funcionários do departamento de
frente de caixa.
Regras de negócios faz referência a como o processo é executado e suas restrições.

Regras de negócios são independentes de sistemas informatizados, elas perten-
cem ao negócio.
É preciso ter em mente que se as regras de negócios estiverem incorretas, o

modelo de dados será incorreto e, em última instância, o sistema que irá consumir
no banco de dados não funcionará como esperado pelos usuários.
Explor
O que é Regra de Negócio? https://goo.gl/VBXloC
12
Níveis de Modelagem: Modelos
Conceitual, Lógico e Físico
O processo de modelagem de dados começa com uma visão abstrata do ambiente
geral de dados (Modelo conceitual) e ganha detalhes (Modelos lógico e Físico) à
medida que o projeto se aproxima da implementação do banco de dados.
Modelo Conceitual
Um modelo de dados conceitual identifica as relações de nível mais alto entre as
diferentes entidades.
Características do modelo de dados conceitual incluem:

• Entidades importantes e as relações entre elas.
• Nenhum atributo é especificado.
• Nenhuma chave primária é especificada.
O diagrama abaixo é um exemplo de um modelo conceitual de dados.
Proprietário Possui Animal
Compra Consulta
Produto Veterinário
Figura 2
A partir do diagrama acima, podemos ver que as únicas informações mostradas

através do modelo de dados conceitual são as entidades que descrevem os dados e
as relações entre essas entidades. Nenhuma outra informação é mostrada através
do modelo conceitual de dados.
Modelo Lógico
Um modelo de dados lógico descreve os dados com o máximo de detalhes
possível, independentemente do modo como será a implementação física no banco
de dados. As características do modelo de dados lógico incluem:
• Todas as entidades e relações entre elas.
• Todos os atributos para cada entidade especificados.
13
13
• A chave primária para cada entidade especificada.

• Especificadas as chaves estrangeiras (chaves que identificam a relação entre
diferentes entidades).
• A normalização ocorre neste nível.
As etapas para projetar o modelo de dados lógico são as seguintes:

1. Especifique chaves primárias para todas as entidades.
2. Encontre as relações entre entidades diferentes.
3. Encontre todos os atributos para cada entidade.
4. Resolva relacionamentos muitos-para-muitos.
5. Normalização.
O diagrama abaixo é um exemplo de um modelo de dados lógico.
Figura 3
14
Comparando o modelo de dados lógico, mostrado acima, com o diagrama do
modelo de dados conceitual, vemos as principais diferenças entre os dois:
• Em um modelo de dados lógico, chaves primárias estão presentes, enquanto
que em um modelo de dados conceitual, nenhuma chave primária está presente.
• Em um modelo de dados lógico, todos os atributos são especificados dentro
de uma entidade. Nenhum dos atributos são especificados em um modelo
conceitual de dados.
• As relações entre entidades são especificadas usando chaves primárias e cha-
ves estrangeiras em um modelo de dados lógico. Em um modelo de dados
conceitual, os relacionamentos são simplesmente declarados, não especifica-
dos, simplesmente sabemos que duas entidades estão relacionadas, mas não
especificamos quais atributos são usados para essa relação.
Modelo Físico
O modelo de dados físico representa como o modelo será construído no banco
de dados. Um modelo de banco de dados físico mostra todas as estruturas de
tabela, incluindo nome da coluna, tipo de dados da coluna, restrições de coluna,
chave primária, chave externa e relações entre tabelas. Os recursos de um modelo
de dados físicos incluem:
• Especificar todas as tabelas e colunas.
• Chaves estrangeiras são usadas para identificar relações entre tabelas.
• Considerações físicas podem fazer com que o modelo de dados físico seja
bastante diferente do modelo de dados lógicos.
• O modelo de dados físico será diferente para diferentes SGDBs. Por exemplo,
o tipo de dados para uma coluna pode ser diferente entre o MySQL, ORACLE,
FIREBIRD e o SQL Server.
As etapas para projetar o modelo de dados físico são as seguintes:

1. Converter entidades em tabelas.
2. Converter relações em chaves estrangeiras.
3. Converter atributos em colunas.
4. Modificar o modelo de dados físicos com base em restrições/requisitos físicos.
15
15
A figura abaixo é um exemplo de um modelo de dados físicos.
Figura 4
Comparando o modelo de dados físico mostrado acima com o diagrama do

modelo de dados lógico, vemos as principais diferenças entre os dois:
• Os nomes das entidades são agora nomes de tabelas.
• Os atributos são agora nomes de colunas.
• O tipo de dados para cada coluna é especificado. Tipos de dados podem ser
diferentes dependendo do banco de dados real sendo usado.
16
Livros
Banco de Dados: Implementação em SQL, PL/SQL e Oracle 11g
Sandra Puga, Edson França e Milton Goya
Capítulo 2 - Requisitos de sistema de software
Leitura
Requisitos Funcionais x Regras de Negócios
https://goo.gl/6oLHsl
Regra de Negócio não é Requisito de Software
https://goo.gl/y5pB7L
Modelagem de Dados: Modelo Conceitual, Modelo Lógico e Físico
https://goo.gl/MSmYIM
17
17
Referências
BARBIERE, CARLOS. Modelagem de Dados. Rio de Janeiro: Campus. 1997.
COUGO, S. Paulo. Modelagem Conceitual e Projeto de Banco de Dados. Rio

de Janeiro: IBPI press. 1994.
Fanderuff, Damaris. Dominando o Oracle 9i: Modelagem e Desenvolvimento.

São Paulo: Pearson Education do Brasil, 2003.
HEUSER, C. A. Projeto de banco de dados. 6.ed. Porto Alegre: Bookman, 2010.
18
Material Teórico
Modelo ER - Parte 1

Revisão Técnica:
Prof. Me. Douglas Almendro
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
Modelo ER - Parte 1
• Introdução ao Modelo-ER
• Entidades, Entidades Fortes e Fracas
· Estudar o Modelo de Entidade relacional, o modelo de dados mais
utilizado no mercado. Nessa primeira parte veremos os conceitos de
entidades, entidades fortes e fracas.
UNIDADE Modelo ER - Parte 1
Introdução ao Modelo-ER
O Modelo entidade-relacionamento (Modelo-ER) é a técnica mais difundida e
utilizada para modelagem de dados (HEUSER, 2010). O modelo ER foi proposto
pela primeira vez por Peter Pin-Shan Chen, do Instituto de Tecnologia de
Massachusetts (MIT), na década de 1970, e descreve o modelo conceitual de um
banco de dados, apoiando-se principalmente na representação de entidades do
mundo real e as associações entre elas.
Segundo HEUSER, 2010, podemos definir entidade como um “conjunto de objetos da

realidade modelada sobre os quais se deseja manter informações no banco de dados”
Como é mais fácil analisar as estruturas graficamente do que descrevê-las em

um texto, os projetistas de bancos de dados preferem usar uma ferramenta gráfica
na qual as entidades e seus relacionamentos são retratados. Assim, o Modelo-ER,
tornou-se um padrão amplamente aceito para modelagem de dados.
No modelo ER, a estrutura de um banco de dados é retratada como um diagrama,

chamado de diagrama de entidade-relacionamento (DER).
Embora sejam capazes de descrever qualquer sistema, os diagramas de entidade-

relacionamento são mais frequentemente associados a bancos de dados. Em
particular, os diagramas de entidade-relacionamento são comumente utilizados
durante a fase de concepção de um processo de desenvolvimento, a fim de
identificar diferentes elementos do sistema e as suas relações uns com os outros.
Os principais elementos em um DER são:

• Entidade - uma classe de objetos do mundo real com características e
propriedades comuns sobre as quais desejamos registrar informações.
• Relacionamento - uma associação entre duas ou mais entidades.
• Atributo - uma característica de uma entidade ou relacionamento.
No DER, as entidades são representadas por retângulos, os relacionamentos são

representados por losangos e atributos por círculos.
8
Atributo
(0,n) Atributo
Relacionamento Entidade
Atributo
Atributo
(0,n)
Atributo
Entidade
Atributo
Atributo
Figura 1
O DER promove aos analistas um auxílio inestimável no que diz respeito à

concepção, otimização e o desenvolvimento de um projeto de Banco de dados.
Entre as vantagens do modelo-ER, podemos destacar:

• Excepcional simplicidade conceitual
• Representação visual
• Ferramenta de comunicação eficaz
• Integrado com o modelo de banco de dados relacional
Em contrapartida, podemos destacar as seguintes desvantagens:

• Representação limitada de restrições
• Representação limitada de relacionamento
Diagramas de entidade-relacionamento (DER) constituem um quadro muito útil

para a criação e manipulação de bases de dados. Primeiramente, esses diagramas
são fáceis de compreender e não requer treinamento extensivo para poder trabalhar
com ele eficientemente. Isso significa que os projetistas podem usar diagramas de
entidade-relacionamento para se comunicar facilmente com desenvolvedores, clientes
e usuários finais, independentemente de sua proficiência em TI. Em segundo lugar,
os diagramas de entidade-relacionamento são prontamente traduzíveis em tabelas
relacionais que podem ser usadas para construir bases de dados rapidamente. Além
disso, podem ser usados diretamente pelos desenvolvedores de banco de dados como
o modelo para a implementação de dados em aplicativos de software específicos.
Por fim, os diagramas de entidade-relacionamento podem ser aplicados em

outros contextos, como descrever as diferentes relações e operações dentro de
uma organização.
Explor
Softwares livres para modelagem ER: https://goo.gl/gjcBr - https://goo.gl/kD791G
9
9
Entidades, Entidades Fortes e Fracas

Uma Entidade é um objeto de interesse para o usuário final e refere-se realmente
ao conjunto de entidades e não a uma única entidade. Em outras palavras, entidade
no MER corresponde a uma tabela.
Uma entidade pode ser uma pessoa, lugar, evento, objeto ou um conceito que é
relevante para um determinado sistema para a qual estamos modelando o projeto
de banco de dados. Por exemplo:
• Pessoa: Estudante, Empregado, Cliente.
• Lugar: Cidade, Sala, Armazém.
• Evento: Festa, Casamento, Exposição, Feira.
• Objeto: Carro, Navio, Máquina, Produto.
• Conceito: Projeto, Conta, Curso.
Essas entidades são representadas no DER por um retângulo e nomeadas,

usando substantivos singulares. Por exemplo, em um sistema escolar podemos ter
as seguintes entidades:
Aluno Professor Curso
Turma Histórico
Figura 2
É importante entender a distinção entre entidade, uma instância de entidade

e um conjunto de entidades. Uma entidade define uma coleção de entidades
que possuem os mesmos atributos. Uma instância de entidade é um único item
nesta coleção. Um conjunto de entidades é um conjunto de instâncias de entidade.
Por exemplo: ALUNO é um tipo de entidade; um aluno com o número de RGM
“151623” é uma instância de entidade; uma coleção de todos os alunos é um
conjunto de entidades.
Existem três tipos de entidades: Fortes; Fracas e Associativas.
Entidade Forte
Se uma entidade pode existir separadamente de todas as suas entidades
relacionadas, então essa entidade é classificada como uma Entidade Forte. Como
destaca Barbiere (1994), “além de independência de existência, normalmente
possuem independência de identificação dada por um ou mais atributos próprios”.
10
Segundo Barbiere (1994), as entidades fortes comumente são as primeiras a serem

identificadas no processo inicial de análise do projeto de modelagem de dados.
Por exemplo, a entidade EMPREGADO é uma entidade forte, pois não depende
de outra entidade para que exista uma instância.
Empregado
Nome_Empregado
Id_Empregado
Figura 3
Entidade Fraca
Uma entidade fraca é uma entidade que depende da existência de outra entidade.
Em termos mais técnicos, ela pode ser definida como uma entidade que não pode
ser identificada por seus próprios atributos. Uma entidade fraca é aquela que atende
a duas condições:
• A entidade fraca é dependente da existência de uma instância da entidade com
a qual tem um relacionamento.
• A entidade fraca tem uma chave primária que é parcial ou totalmente derivada
da entidade-mãe no relacionamento.
Por exemplo, temos a seguinte regra de negócio:

• Todo dependente deve estar vinculado a um empregado.
Nossa regra de negócio diz que um DEPENDENTE só pode existir/ser cadastrado

se ele estiver vinculado a um EMPREGADO, ou seja, não podemos cadastrar um
DEPENDENTE sem indicar à qual EMPREGADO esse dependente está vinculado.
Vejamos o exemplo no diagrama abaixo, temos a entidade DEPENDENTE,

podemos definir essa entidade como fraca, pois conforme nossa regra de negócio,
para existir uma instância da entidade DEPENDENTE, deve-se existir primeiro uma
instância de EMPREGADO.
11
11
Id_Dependente
(1,1) (0,n)
Empregado Possui Dependente
Id_Empregado
Nome_Empregado Nome_Dependente
Id_Empregado
Figura 4
Vejamos o exemplo do diagrama abaixo:
(0,n) Id_Pedido
(1,1)
Pedido Possui Itens_Pedidos Id_Produto
Id_ItemPedido
Nome_Dependente
ValorPedido
Id_Pedido
Figura 5
A entidade Itens_Pedido é uma entidade fraca, pois sua existência depende da

existência de uma instância da entidade Pedido, ou seja, para termos Itens de
pedidos devemos antes ter dados do Pedido.
Entidade Associativa
Onde a entidade descreve uma conexão entre duas entidades com uma relação
de muitos para muitos, por exemplo, atribuição de Empregado a Projeto (um
Empregado pode ser atribuído a mais de um Projeto e um Projeto pode ser atribuído
a mais de um Empregado).
Empregado Id_Empregado
(1,n)
(1,n) Projeto
Id_projeto
Possui
Figura 6
Se houver informações sobre o relacionamento, essas informações serão

mantidas em uma entidade associativa, por exemplo, o número de horas em que
o Empregado trabalhou em um Projeto específico é um atributo da relação entre
Empregado e Projeto, não de Empregado ou de Projeto.
12
Empregado Id_Empregado Projeto Id_Projeto
(1,1) (1,1)
Empregado_projeto
Possui
Horas_Trabalhadas
Id_Projeto
Id_Empregado
Figura 7
Uma entidade associativa é identificada unicamente por concatenação das

chaves primárias das duas entidades que ele conecta.
Leia mais sobre entidades no livro Banco de dados: Implementação em SQL, PL/SQL e
Explor
Oracle 11g - Capítulo 4.4 – Tipos de entidades – Acessível á partir da biblioteca virtual.
13
13
Sites
Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER)
https://goo.gl/ezrwLk
Livros
Banco de Dados: Princípios e Prática
Luciano Frontino de Medeiros. Capítulo:2 – O modelo entidade-relacionamento (ER)
Sandra Puga, Edson França e Milton Goya. Capítulo 4.3 – Modelo Entidade
Relacionamento (MER)
Vídeos
Introdução Modelo Entidade-Relacionamento
https://youtu.be/miw6wEjc8ZE
14
Referências
BARBIERE, CARLOS. Modelagem de Dados. Rio de Janeiro: IBPI Press. 1994.

de Janeiro: Campus. 1997.
15
15
Material Teórico
Modelo ER – Parte 2

Revisão Técnica:
Prof. Me. Douglas Almendro
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
Modelo ER – Parte 2
• Introdução;
• Relacionamento;
• Atributo;
• Notações Gráficas ER.
· Apresentar os conceitos de relacionamento, atributos e as notações
gráficas para a representação do MER.
UNIDADE Modelo ER – Parte 2
Introdução
Nessa unidade daremos sequencia ao estudo do modelo entidade-relacionamento
(Modelo-ER), estudaremos os conceitos e características de relacionamentos,
atributos e um pouco mais sobre a notação gráfica criada por Peter Chen na
década de 1970.
Relacionamento
Um relacionamento descreve uma associação entre entidades. Isto é, um
relacionamento representa a quantidade de instâncias de uma entidade em relação
à outra entidade. Por exemplo, existe uma relação entre clientes e vendedores que
pode ser descrita da seguinte forma: um vendedor pode atender muitos clientes e
cada cliente pode ser atendido por um vendedor.
Em um Diagrama de entidade-relacionamento (DER), representamos um

relacionamento por meio de um losango. No diagrama abaixo, podemos observar
o relacionamento (atende) entre as entidades Vendedor e Cliente.
Vendedor 1 Atende n Cliente
Figura 1
Trocando ideias...Importante!
Relacionamento é um conjunto de associações entre ocorrências de entidades
(HEUSER, 2010).
Antes de começar a estabelecer relações entre entidades do projeto de banco de

dados, devemos saber quais tipos de relações podem existir entre um determinado
par de entidades. Saber identificá-los adequadamente é uma habilidade inestimável
para projetar um banco de dados com êxito.
Para entender como representar um relacionamento em um modelo entidade-

relacionado, serão apresentados os conceitos de Grau de relacionamento (unário,
binário e ternário) e Cardinalidade (Máxima e Mínima).
8
Grau de Relacionamento
O número de conjuntos de entidades que participam de um relacionamento
é chamado de grau de relacionamento. Os três graus mais comuns de um
relacionamento em um banco de dados são: unário, binário e ternário.
• Relação Unária: Uma relação unária R é uma associação entre duas instân-
cias do mesmo tipo de entidade (isto é, R ∈ E1 × E1). Por exemplo, todo
empregado em uma determinada empresa possui um supervisor, e todo super-
visor é um empregado.
Empregado Supervisor
Figura 2
• Relação binária: Uma relação binária R é uma associação entre duas instâncias
de dois tipos de entidade diferentes (isto é, R ∈ E1 × E2). Por exemplo, numa
loja, existe uma relação binária entre um vendedor (entidade VENDEDOR) e
um cliente (entidade CLIENTE): Um vendedor atende um cliente.
Vendedor Atende Cliente
Figura 3
• Relação Ternária: Uma relação ternária R é uma associação entre três
instâncias de três diferentes tipos de entidade (isto é, R ∈ E1 × E2 × E3). Por
exemplo, considere um professor que leciona diversas disciplinas em diversas
turmas em uma Universidade. Neste caso, os tipos de entidade PROFESSOR,
TURMA e DISCIPLINA se relacionam entre si com relacionamentos ternários:
um professor leciona uma disciplina em uma turma.
Professor
Turma Possui Disciplina
Figura 4
9
9
Cardinalidade
Quando dizemos cardinalidade de um relacionamento, queremos dizer a
capacidade de contar o número de entidades envolvidas nesse relacionamento.
Por exemplo, se instâncias das entidades A e B estiverem conectadas por uma
relação, então a cardinalidade máxima representa o número máximo de instâncias
da entidade B que podem ser associadas a qualquer instância da entidade A.
No entanto, não é necessário atribuir um valor de número para cada nível de

conexão em um relacionamento. Na verdade, o termo cardinalidade máxima refere-
se a apenas dois valores possíveis: um (1) ou muitos (N).
Embora isso possa parecer muito simples o valor máximo de cardinalidade de

uma relação, nos permite definir os três tipos de relações possíveis entre os tipos de
entidade A e B: um-para-muitos (1:N), muitos-para-muitos (N:M) e um-para-um (1:1).
Cardinalidade é uma propriedade que especifica a quantidade de ocorrências associadas
entre duas entidades dentro de uma relação.
Relação um-para-muitos (1:N)

Uma relação 1:N descreve que uma instância do conjunto A se relaciona com
diversas instâncias do conjunto B; e uma instância do conjunto B se relacionado
com apenas uma instância do conjunto A.
Tabela 1
Conjunto A Conjunto B
Instância1
Instância1 Instância2
Instância3
Instância5
Instância3
Instância6
Considere que uma pessoa pode ter registrado em seu nome vários carros, contu-
do, um carro é registrado apenas em nome de uma pessoa. Desse modo, a pessoa
(“um”) está relacionada com carros (“muitos”). Para o seguinte exemplo, descreve-
mos a relação como “PESSOA possui CARRO” e representamos como 1:N.
Pessoa 1 Possui n Carro
Figura 5
10
Lemos esse diagrama como: “Uma pessoa pode possuir vários carros e um
carro pode ser registrado em nome de uma pessoa”.
Do mesmo modo, em nosso segundo exemplo, um cliente pode possuir vários

pedidos em uma loja, contudo, um pedido pertence apenas a um cliente. Para esse
exemplo temos o seguinte diagrama:
Cliente 1 Possui n Pedido
Figura 6
Lemos esse diagrama como: “Um cliente pode possuir vários pedidos e um
pedido pertence a um cliente”.
Relação muitos-para-muitos (N:M)

Uma relação N:M descreve que uma instância do conjunto A se relaciona com
diversas instâncias do conjunto B; e uma instância do conjunto B se relaciona com
diversas instâncias do conjunto A.
Tabela 2
Instância1
Instância3
Instância3
Instância5
Instância2
Instância5
Instância3
Instância6
Instância7
Instância5
Instância4
Instância7
Vamos a um exemplo. Um autor pode escrever vários livros e um livro pode

ser escrito por diversos autores. Assim, o autor (“muitos) está relacionado a livro
(“muitos”). Descrevemos esse relacionamento como “AUTOR escreve LIVRO” e
representamos como “N:M”.
Autor n Escreve m Livro
Figura 7
11
11
Vejamos outro exemplo. Um empregado pode trabalhar em vários projetos e um

projeto pode alocar vários empregados. Podemos descrever esse relacionamento
como: “EMPREGADO trabalha PROJETO” e representamos como “N:M”.
Empregado n Trabalha m Projeto
Figura 8
Lemos esse diagrama como “Um empregado pode trabalhar em vários projetos
e um projeto pode alocar vários empregados”.
Relação um-para-um (1:1)

Uma relação 1:1 descreve que uma instância do conjunto A se relaciona com
apenas com uma instância do conjunto B; e uma instância do conjunto B se
relaciona apenas com uma instância do conjunto A.
Tabela 3
Vamos a mais um exemplo. Uma loja possui um departamento que é gerenciado

por apenas um empregado. Diante do cenário, podemos descrever este relacio-
namento como: “EMPREGADO gerencia DEPARTAMENTO” e representamos
como “1:1”. Veja a representação desse relacionamento no DER abaixo.
Empregado 1 Gerencia 1 Departamento
Figura 9
Podemos ler esse diagrama como: “Empregado gerência um departamento e

um departamento é gerenciado por um empregado”.
Outro bom exemplo de um relacionamento um-para-um é entre as entidades

Cliente e Login dentro de uma plataforma de vendas online. Um cliente possui
apenas um login e o login pertence a apenas um cliente. Veja a representação
desse relacionamento no DER abaixo.
12
Cliente 1 Possui 1 Login
Figura 10
Cardinalidade Mínima
O termo cardinalidade mínima refere-se ao número mínimo de instâncias de uma
entidade que deve estar associada a uma única instância de uma entidade relacionada.
Utilizamos a representação de cardinalidade mínima para expressar as restrições
mínimas de uma ocorrência em uma dada entidade. Ou seja, as cardinalidades
mínimas irão representar a obrigatoriedade ou não de uma ocorrência em uma
entidade. As cardinalidades mínimas possuem os seguintes valores possíveis: 0 e 1.
Cardinalidade mínima um (0)

Considere a seguinte regra de negócio:
• Um cliente pode possuir diversos pedidos, contudo, todo pedido deve
pertencer à somente um cliente.
Nesse cenário, sabemos que esse tipo de relacionamento é do tipo “um-para-

muitos”, ou seja, 1:N, porque um (1) cliente pode possuir diversos (N) pedidos. Já
temos a informação da cardinalidade máxima de cada entidade. Agora para obter
as informações a respeito das cardinalidades mínimas de cada entidade, devemos
nos atentar à regra de negócio e identificar às palavras que denotam restrições, que
nesse caso são: “... pode possuir...” e “... deve... somente um cliente.”. Essa
análise resulta em:
• O cliente pode ou não possuir um pedido (mínimo 0), mas todo pedido deve
pertencer a um cliente (mínimo 1).
Veja a representação desse cenário no diagrama DER abaixo.
Pedido pertence à
(0,N)
Cliente Possui Pedido
(1,1)
Cliente possui um
Figura 11
13
13
Mais uma vez é preciso lembrar que as cardinalidades máximas e mínimas de

uma entidade em relação à outra, são representadas no lado oposto à da entidade.
Lemos esse diagrama do seguinte modo:
• Um cliente pode possuir no mínimo zero (0) e no máximo diversos pedidos (N).
• Um pedido deve pertencer à no mínimo um (1) cliente e no máximo a um
(1) cliente.
O grau da cardinalidade de uma entidade é sempre representado ao lado oposto
da entidade.
Cardinalidade mínima zero (1)

Considere a seguinte regra de negócio:
• Todo cliente deve possuir um login e um login deve pertencer à somente
um cliente.
Sabemos que a cardinalidade (máxima) dessa relação é um-para-um. Contudo,

quais são as cardinalidades mínimas? As cardinalidades representam as restrições
mínimas de uma ocorrência, então, nesse caso, ao ler a sentença do cenário, po-
demos perceber que existem restrições mínimas para a ocorrência de LOGIN e
USUÁRIO (deve possuir um login... deve pertencer à somente um...). Nesse caso,
as cardinalidades representadas são 1:1 e 1:1.
Veja a representação desse cenário no diagrama DER abaixo.
Login pertence à
(1,1)
Cliente Possui Login
(1,1)
Cliente possui um
Figura 12
As cardinalidades máximas e mínimas de uma entidade em relação à outra, são

representadas no lado oposto a da entidade. Lemos esse diagrama do seguinte modo:
• Um cliente possui no mínimo um (1) login e no máximo um (1) login.
• Um Login pertence à no mínimo um (1) usuário e no máximo à um (1) usuário.
14
Atributo
Um atributo é uma propriedade ou característica de uma entidade, ou uma
relação. Por exemplo, o atributo Nome na ficha de um aluno é um atributo da
entidade ALUNO. Uma entidade pode ter tantos atributos quanto necessário. Em
um Diagrama de entidade-relacionamento (DER), representamos um atributo por
meio de uma elipse ou um circulo. No diagrama abaixo, temos um exemplo de
representação de atributos.
Entidade Atributo 1
Atributo 3
Atributo 4
Atributo 2
Figura 13
Segundo Machado (2014), podemos classificar os atributos em dois tipos:

Descritores e Identificadores.
Atributos Descritores
Todo e qualquer atributo que seja capaz de identificar e representar uma carac-
terística de um objeto. Para Cougo (1997), todo atributo pode ser considerado um
atributo descritivo, o que faz o atributo ser classificado com outro tipo é a presença
de características funcionais adicionais, por exemplo, um atributo identificador.
Atributos Identificadores
Um identificador (ou atributo-chave) é um único atributo ou uma combinação
de atributos que identificam de forma única uma instância individual de um tipo de
entidade. Por exemplo, na entidade ALUNO temos o atributo RGM como atributo
identificador (ou atributo-chave), pois esse atributo, o RGM é único para cada Aluno
(instância). No DER abaixo, vemos a representação desse cenário.
NrCelular
Aluno
Endereço
Nome
RGM
Figura 14
15
15
O atributo Nome, por exemplo, não pode ser um identificador porque dois
alunos podem ter o mesmo nome.
Às vezes, por meio de um único atributo não é possível identificar exclusivamente

uma instância de uma entidade. No entanto, nessas circunstâncias, identificamos um
conjunto de atributos que quando combinados, é exclusivo para cada instância da
entidade. Nesse caso, o atributo-chave, também conhecido como chave composta,
não é um atributo simples, mas um atributo composto que identifica exclusivamente
cada instância de entidade.
Considere as entidades EMPREGADO e DEPENDENTE, onde um empregado

pode possuir vários dependentes e um dependente deve pertencer à apenas um e
no máximo um empregado. Nesse cenário, para identificar uma ocorrência única
da entidade DEPENDENTE, utilizamos um atributo composto, formado por um
atributo-chave de cada uma das entidades. O DER abaixo apresenta esse quadro.
(1,1) (0,n) Idade

Empregado Possui Dependente
Nome
Nome Id_Empregado
Id_Empregado Id_Departamento
Figura 15
Utilizamos os atributos “Id_Departamento” e “Id_Empregado” para formar a

chave composta da entidade DEPENDENTE.
Ainda sobre o exemplo do relacionamento Empregado x Dependente. O atributo composto

Explor
servirá para tornar mais rápida e eficiente a busca de informações referentes à entidade Forte,
que nesse contexto é a entidade EMPREGADO. Em uma futura pesquisa no banco de dados,
podemos nos deparar com a necessidade em se buscar informações do Empregado, contudo,
temos inicialmente apenas informações do Dependente, e por meio da chave composta,
podemos identificar o Empregado e diante disso, todas as outras informações necessárias.
16
Notações Gráficas ER
As notações gráficas para se desenvolver um Diagrama de entidade-
relacionamento mais comumente utilizadas são as notações criadas por Peter Chen
(1990). A seguir, apresentamos os principais símbolos utilizados em um DER.
Tabela 4
Símbolo Representa
Entidade Entidade
Entidade
Entidade
Entidade
Atributo
Atributo
Atributo
Atributo
Atributo Descritor
Identificador Atributo Identificador
Identificador
Identificador
Identificador
Relação
Relação
Relação
Relação Relacionamento
17
17
Sites
Modelagem de Dados - Modelo Entidade-Relacionamento
https://goo.gl/Pasjev
Livros
Banco de Dados: Projeto e Implementação
MACHADO, F. N. R./Capítulo 4 - Modelo entidade-relacionamento, 4.3 Relaciona-
mentos, 4.4 Atributos
Sistemas de Banco de Dados
CARDOSO, Vírginia M./Capítulo 2 - O modelo entidade-relacionamento
Vídeos
Cardinalidade
https://youtu.be/bwvHTrTaYX4
18
Referências
CHEN, Peter. Modelagem de dados: Abordagem, Entidade – relacionamento
para projeto lógico. São Paulo: Makron Books, 1990.

MACHADO, F. N. R. Banco de Dados: projeto e implementação. 3.ed. São

Paulo, SP: Érica, 2014
19
19
Material Teórico
Implementando o Modelo Relacional

Revisão Textual:
Profa. Dra. Geovana Gentili Santos
Implementando o Modelo Relacional
• Normalização
· Estudaremos os conceitos de Normalização do modelo relacional,
suas regras de implantação e seus principais benefícios
UNIDADE Implementando o Modelo Relacional
Normalização
A normalização é um processo para avaliar e corrigir estruturas de tabela para
minimizar redundâncias de dados, reduzindo, assim, a probabilidade de anomalias
de dados. O processo de normalização envolve a atribuição de atributos a tabelas
com base no conceito de determinação.
O processo de normalização deve ocorrer logo após a etapa de criação do

modelo conceitual do banco de dados. Muitas vezes, após a normalização, ocorrerão
atualizações no modelo conceitual.
A normalização funciona através de uma série de estágios chamados Formas nor-

mais. Os três primeiros estágios são descritos como primeira forma normal (1NF),
segunda forma normal (2NF) e terceira forma normal (3NF). Do ponto de vista estru-
tural, podemos afirmar 2NF é melhor do que 1NF, e 3NF é melhor que 2NF.
Um problema óbvio com informações redundantes é que usamos mais memória do que
é necessário. A redundância é um exemplo de uma anomalia que pode ocorrer em um
SGBD do modelo relacional.
A Necessidade de Normalização
Existem duas situações comuns em que os projetistas de banco de dados usam
a normalização:
• Ao projetar uma nova estrutura de banco de dados com base nos requisitos
de negócios dos usuários finais, o projetista de banco de dados construirá um
modelo de dados usando o diagrama de entidade-relacionamento (DER). Após
a conclusão do projeto inicial, o projetista pode usar a normalização para ana-
lisar as relações que existem entre os atributos dentro de cada entidade, para
determinar se a estrutura pode ser melhorada através da normalização.
• Alternativamente, os projetistas de banco de dados são frequentemente soli-
citados a modificar estruturas de dados existentes que podem ser na forma de
arquivos simples, planilhas ou estruturas de banco de dados mais antigas. No-
vamente, por meio de uma análise das relações entre os atributos ou campos
na estrutura de dados, o projetista de banco de dados pode usar o processo
de normalização para melhorar a estrutura de dados existente para criar um
projeto de banco de dados apropriado.
8
Anomalias
Existem três tipos de anomalias que ocorrem quando o banco de dados não é
normalizado. Estas são:
• Inserção;
• Atualização; e
• Anomalia de Exclusão.
Vamos a um exemplo para entender isso! Suponha que em uma empresa desen-
volvedora de software, as informações dos projetos executados são armazenadas
em uma tabela chamada Projetos. Vejamos essa tabela abaixo:
Tabela 1
ID_ Nome_ ID_ Nome_ Cargo_ Horas_
Valor_Hora
projeto Projeto Empregado Empregado Empregado Trabalhadas
Programador
001 Manhattan 1 João da Silva 40.00 50
Sênior
2 Paulo Farias Analista Sênior 40.00 30
Programador
3 Carlos Alberto 40.00 50
Sênior
4 Maria Fernanda Gerente 80.00 50
Os problemas com a tabela acima são:

1. O número do projeto destina-se a ser uma chave primária, mas contém nulos.
2. A tabela exibe redundâncias de dados.
3. As entradas de tabela permitem inconsistências de dados.
4. As redundâncias de dados produzem as seguintes anomalias:
a) Anomalias de Inserção: Não podemos armazenar os detalhes do Empre-
gado até que o Projeto seja atribuído.
b) Anomalias de Atualização: Se o nome do projeto Manhattan precisar ser
alterado, essa alteração deverá ser realizada em todos os quatro registros.
c) Anomalias de Exclusão: Se excluirmos o empregado 1, também iremos
perder as informações sobre o Projeto.
Para superar essas anomalias, precisamos normalizar os dados. Nas próximas

seções, iremos discutir sobre a normalização.
A chave primária de uma relação em um SGBD

deve ser uma chave candidata, mas pode haver
várias chaves candidatas para escolher. Quando
se fala de normalização, é irrelevante qual chave
é escolhida como chave primária.
9
9
1ª Forma Normal (1FN)

Definimos que uma tabela está na primeira forma normal, se e somente se, todas
as colunas possuem um único valor, e não existam grupos repetitivos (colunas) em
uma linha ou atributos compostos. (MACHADO, 2014).
Para que uma tabela possa estar na 1FN, devemos seguir as seguintes regras:
1. Não devem existir colunas com dados repetidos ou similares;
2. Cada item de dados deve ser atômico (não possuir valores compostos);
3. Cada linha deve ser única, isto é, deve possuir uma chave primária;
4. Cada campo deve ter um nome exclusivo.
‘Atômico’ é o termo usado para descrever que um item de dados é único e indivisível.
Exemplo de dados repetidos:
Tabela 2
Tabela Cliente
Id_Cliente Nome_Cliente Telefone1 Telefone2 Telefone3
123 João da Silva 1234-2356 8945-5689 2563-8996
Neste exemplo, o banco de dados está tentando armazenar números de telefones

de contato para cada Cliente. O projetista criou três campos para manter números
de telefone. Esse é um exemplo de “colunas com dados repetidos”. Os números de
telefone são o mesmo tipo de dados.
Exemplo de dados “não atômicos”.
Tabela 3
Tabela Cliente
Id_Cliente Nome_Cliente E-mail
123 João da Silva joao@gmail.com; joaosilva@gmail.com
Por mais que a tabela acima possua um campo de chave primária (Id_Cliente)
e não existam dados repetidos, essa tabela não está na primeira forma normal
(1FN) porque, como podemos notar, o cliente possui dois endereços de e-mail
inseridos no campo “E-mail”. Desse modo, os dados inseridos neste campo não
são atômicos.
10
Levando em consideração que existe a possibilidade de o cliente possuir mais
que um (1) e-mail, a solução para esse cenário é criar uma nova entidade chamada
E-mail e usar o campo chave (Id_Cliente) como chave estrangeira para fazer a
ligação entre as duas entidades. Podemos observar o resultado nas tabelas abaixo.
Tabela 4
Tabela Cliente
Id_Cliente Nome_Cliente
123 João da Silva
125 José Ferreira
Tabela 5
Tabela E-mail
Id_Email Id_Cliente E-mail
1 123 joao@gmail.com
2 123 joaosilva@gmail.com
3 125 josefer@gmail.com
Com essa solução, não há problemas quanto a inserir mais que um (1) e-mail por
cliente e confere a fácil extração de dados de e-mail, pois, além de existir apenas
uma coluna para e-mail, todos os dados são atômicos.
Podemos afirmar que essas tabelas estão na primeira forma normal (1NF), dado
que obedecem às seguintes regras:
• Cada tabela tem uma chave primária;
• Cada nome de campo é exclusivo;
• Os dados são atômicos;
• Não possui campos repetidos / redundantes.

Uma tabela está na segunda forma normal (2FN) se estiver na 1FN e não
possuir campos que sejam funcionalmente dependentes de parte da chave primária
(MACHADO, 2014).
As regras para a segunda forma normal são:

1. A tabela deve estar já na primeira forma normal (1FN);
2. Todos os atributos não-chave devem depender da chave primária completa,
ou seja, não contenham dependência parcial.
Dependência parcial ocorre quando uma coluna depende apenas de parte de uma chave
primária composta (HEUSER, 2010).
11
11
A razão dessa regra é garantir que não haja dados redundantes sendo armazenados
no banco de dados.
Vamos a um exemplo. Considere as seguintes tabelas.
Tabela 6
Tabela Projeto
Id_Projeto Nome_Projeto
103 Manhattan
104 Houston
Tabela 7
Tabela Empregado
Id_Projeto ID_Empregado Nome_Empregado Cargo_Empregado Valor_Hora Horas_
Trabalhadas
103 1 João da Silva Programador Junior 30.00 50
103 2 Maria Fernanda Gerente 80.00 50
104 1 João da Silva Programador Junior 30.00 20
104 3 Paulo Farias Analista Sênior 40.00 10
104 4 Gustavo Fontes Analista Sênior 40.00 20
No cenário acima, podemos perceber que a tabela Projeto está na segunda

forma normal, pois todos os seus atributos dependem exclusivamente de sua chave
primária. Contudo, a tabela Empregado não, posto que os atributos “Nome_Em-
pregado”, “Cargo_Empregado” e “Valor_Hora” dependem somente do campo
chave “Id_Empregado”. São atributos que não estão ligados diretamente do campo
chave “Id_Projeto”, ou seja, são atributos que não dependem da entidade Projeto.
Por outro lado, o atributo “Horas_Trabalhadas” depende exclusivamente da chave
composta da Tabela (Id_Projeto e Id_Empregado). A informação guardada nesse
atributo permite saber quantas horas o empregado trabalhou no projeto específico.
Para que a tabela Empregado passe para a segunda forma normal (2FN), deve-
mos dividir a tabela em duas novas tabelas, criando, assim, uma nova tabela cha-
mada Projeto_Horas_Trabalhadas. Podemos conferir o resultado abaixo:
Tabela 8
Tabela Projeto
ID_Projeto Nome_Projeto
103 Manhattan
104 Houston
TABELA PROJETO_HORAS_TRABALHADAS
ID_Projeto ID_Empregado Horas_Trabalhadas
103 1 50
103 2 50
104 1 20
104 3 10
12
Podemos afirmar que as tabelas acima estão na segunda forma normal (2FN)
porque todas as tabelas estão na 1FN e, além disso, os atributos não-chave de todas
as tabelas possuem dependência exclusiva da chave primária de suas respectivas
tabelas (sendo essas chaves primárias compostas ou não).

Uma tabela encontra-se na terceira forma normal quando, além de estar na
2FN, não possua dependências transitivas.
Dependência transitiva ocorre quando uma coluna, além de depender da chave primária
da tabela, depende de outra coluna ou conjunto de colunas da tabela (HEUSER, 2010).
As regras para a terceira forma normal (3FN) são:

1. A tabela deve estar já na primeira forma normal (1FN);
2. Não existam atributos não-chave que dependam de outros atributos não-chave.
A razão dessa regra é detectar ainda outras fontes de dados redundantes. Se o

valor de um atributo pode ser obtido simplesmente fazendo uso de outro atributo
na tabela, então, ele não precisa estar na tabela. Criar uma tabela para armazenar
esse tipo de atributo, tornará o banco de dados menor.
Desse modo, a tabela Empregado obtida na segunda forma normal (2FN), ainda
possui dados redundantes. Perceba, nessa tabela, que o valor de hora de trabalho
do empregado está vinculado ao seu cargo, ou seja, a informação do atributo “Va-
lor_Hora” depende da informação contida no atributo “Cargo_Empregado”.
Nesse contexto, para que a tabela Empregado passe para a terceira forma nor-
mal (3FN), devemos dividir a tabela em duas novas tabelas, criando, portanto, uma
nova tabela chamada Cargo. Podemos conferir o resultado abaixo:
Tabela 9
TABELA EMPREGADO
ID_Empregado Nome_Empregado Id_Cargo
1 João da Silva 1
2 Maria Fernanda 2
3 Paulo Farias 3
4 Gustavo Fontes 3
13
13
Tabela 10
TABELA CARGO
Id_Cargo Cargo_Empregado Valor_Hora
1 Programador Junior 30.00
2 Gerente 80.00
3 Analista Sênior 40.00
Tabela 11
TABELA PROJETO
ID_Projeto Nome_Projeto
103 Manhattan
104 Houston
Tabela 12
TABELA PROJETO
ID_Projeto ID_Empregado Horas_Trabalhadas
103 1 50
103 2 50
104 1 20
104 3 10
Assim, podemos concluir que as tabelas acima estão na terceira forma normal
(3FN), já que todas as tabelas estão na 2FN e, além disso, os atributos não-chave de
todas as tabelas não possuem dependência transitiva de outros atributos não-chave
em suas respectivas tabelas.
Forma Normal Boyce/Codd (FNBC) e 4ª e 5ª Forma Normal

(4FN, 5FN)
Para Heuser (2010), a decomposição das tabelas até 3FN é suficiente para obter
o esquema de um banco de dados. Contudo, na literatura, nos deparamos com a
forma normal Boyce/Codd (FNBC) e 4ª e 5ª Forma Normal (4FN, 5FN).
Definimos que uma tabela está na forma normal Boyce/Codd (FNBC), se e

somente se, cada determinante é uma chave candidata. A maioria das entidades
em 3NF já estão em BCNF.
A tabela está na quarta forma normal (4FN) se nenhuma instância da tabela

do banco de dados contiver dois ou mais dados independentes e multivalorados
descrevendo a entidade relevante, então ela estará na quarta forma normal.
Uma tabela está na quinta forma normal (5FN) somente se estiver em 4NF e não
puder ser decomposta em qualquer número de tabelas menores sem perda de dados.
14
Sites
Normalização de Bancos de Dados Relacionais
https://goo.gl/F6ytEQ
Livros
Sandra Puga, Edson França e Milton Goya
Capítulo 5 – Normalização
Vídeos
Normalizacao: Primeira Forma Normal - 1FN
https://youtu.be/3kJKJNKiaD4
Normalizacao: Segunda Forma Normal - 2FN
https://youtu.be/mHoZZUYVFzk
Normalizacao: Terceira Forma Normal - 3FN
https://youtu.be/EZvrGEpyNbs
15
15
Referências
MACHADO, F. N. R. Banco de Dados: projeto e implementação. 3. ed. São

Paulo: Érica, 2014.
16
Material Teórico
Ferramenta para Modelagem ER

Revisão Textual:
Profa. Dra. Geovana Gentili Santos
Ferramenta para Modelagem ER
• Introdução
• BrModelo
• Criando um Diagrama de Entidade-Relacionamento (DER)
• MySQL Workbench
· Estudar um pouco sobre duas ferramentas CASE que auxiliam no
desenvolvimento do projeto de Modelagem de dados: BrModelo e
MySQL Workbench.
UNIDADE Ferramenta para Modelagem ER
Introdução
Nessa unidade, estudaremos sobre duas ferramentas CASE que auxiliam
no desenvolvimento do projeto de Modelagem de Dados: BrModelo e MySQL
Workbench. Mas, afinal, o que são ferramentas CASE?
O termo CASE vem do acrônimo Computer-aided software engineering, ou

traduzindo, Engenharia de Software Auxiliada por Computador. A utilização de
ferramentas CASE permite que os projetistas e outros atores envolvidos no processo
de desenvolvimento do projeto de banco de dados compartilhem uma visão comum
de cada estágio de desenvolvimento. Ferramentas CASE ajudam a garantir um
processo disciplinado além de retratar o progresso (ou falta dele) graficamente.
Alguns dos benefícios que as ferramentas CASE e as abordagens semelhantes

trazem, é a possibilidade de fazer com que o cliente faça parte do processo (através
de diagramas ou análise de regras de negócios) de uma forma mais dinâmica e
assertiva. Tornando, assim, o objeto modelado o mais próximo à necessidade e à
realidade do cliente.
Como esse tipo de abordagem enfatiza o teste e o redesenho, o custo de manu-

tenção de um produto ao longo de sua vida útil pode ser reduzido consideravelmen-
te. Uma abordagem organizada para o desenvolvimento incentiva a reutilização de
código e design, reduzindo custos e melhorando a qualidade.
No estudo sobre Modelagem de Dados, estudaremos, especificamente, ferra-

mentas que auxiliam na concepção, desenvolvimento e implementação de sistemas
de banco de dados.
Uma das grandes vantagens oferecidas pelas ferramentas CASE de banco de

dados é a possibilidade de criar scripts SQL a partir de um diagrama de entidade-
relacionamento (DER).
O SQL (Structure Query Language) é uma linguagem de programação usada

para armazenar e gerenciar dados no SGBD (MySql, Oracle, SqlServer). SQL foi
a primeira linguagem comercial introduzida para o modelo relacional do E. Codd.
Hoje, quase todo o SGBD usa o SQL como a linguagem de banco de dados padrão.
SQL é usado para executar todo o tipo de operações de dados, como criar e excluir
tabelas; inserir, atualizar e excluir dados, e selecionar e exibir dados em um SGBD.
Nos exemplos práticos a seguir, demonstraremos como criar diagramas de

entidade-relacionamento (DER) e, em seguida, exportar esse esquema em formato
SQL, pronto para ser utilizado na criação de tabelas em um banco de dados.
O que é SQL e por que você deve estudá-lo?

Explor
Autor: Paulo Oliveira

https://goo.gl/AfszrU
8
BrModelo
A ferramenta BrModelo é uma ferramenta freeware que possibilita o desenvol-
vimento de diagramas DER, modelo lógico, e exportar esses artefatos em formato
de script SQL para criação de tabelas no banco de dados (CÂNDIDO, 2007).
O software BrModelo 3.0 pode ser baixado e executado apenas nos sistemas operacionais
Explor
Windows: https://goo.gl/fxFXg1
Visão Geral da Ferramenta

A ferramenta BrModelo utiliza o padrão de desenvolvimento drag and drop, ou
seja, você arrasta e solta objetos para dentro do palco do software. Abaixo, temos
a visão geral da ferramenta.
Figura 1
Em destaque, temos três áreas da ferramenta.

• Área 1. É o palco do software. É, nesse espaço, que é organizado os objetos
do DER.
• Área 2. Aqui, estão dispostos os principais objetos do DER (entidade, relacio-
namento, atributos), esses objetos são arrastados para o palco do software.
• Área 3. Refere-se à tela de propriedades de objeto, ao selecionar algum objeto
no palco, essa tela apresenta as propriedades do objeto.
9
9
Criando um Diagrama de Entidade-

Relacionamento (DER)
Nessa sessão, criaremos um DER a partir do seguinte cenário:
• Um funcionário deve possuir no mínimo zero dependente e no máximo muitos
dependentes.
• Um dependente deve pertencer, no mínimo, a 1 funcionário e, no máximo, a
1 funcionário.
A partir dessas assertivas, verificamos que existe um relacionamento entre duas

entidades: “Funcionário” e “Dependente”, bem como sua cardinalidade.
Nesse contexto, criaremos o DER nos passos a seguir.
Passo 1 – Clique no objeto “Entidade” e, em seguida, selecione Entidade.
Figura 2
Passo 2 – Arraste o objeto para o palco e com o objeto selecionado, altere

a propriedade nome para: Funcionario (sem acento) e, em seguida, pressione
“Enter” no teclado.
10
Figura 3
Passo 3 – Clique no objeto “Entidade” e, em seguida, selecione Relação.
Figura 4
11
11
Passo 4 – Arraste o objeto para o palco e, com o objeto selecionado, altere a

propriedade nome para: possui e, em seguida, pressione “Enter” no teclado.
Figura 5
Passo 5 – Adicione um objeto “Entidade” ao palco e altere a propriedade nome

para: Dependente e, em seguida, pressione “Enter” no teclado.
Figura 6
12
Para representar os graus de relacionamento e sua as cardinalidades (mínimas e
máximas), utilizamos o objeto “Ligar Objetos”, destacado na imagem abaixo.
Figura 7
Nos próximos passos, ligaremos os objetos e indicaremos seu grau de relaciona-

mento e suas cardinalidades.
Passo 6 – Selecione o objeto “Ligar Objetos” e, com o objeto selecionado, clique

com o botão esquerdo do mouse primeiro no objeto “Funcionário” e, depois, no
objeto “possui”. Essa ação irá gerar uma “linha” interligando os dois objetos.
Figura 8
Antes de configurar o grau e a cardinalidade do relacionamento. Faça a ligação

entre os objetos Dependente e possui.
Passo 7 – Selecione o objeto “Ligar Objetos”, com o objeto selecionado, clique

com o botão esquerdo do mouse primeiro no objeto “Dependente” e, depois, no
objeto “possui”. Essa ação irá gerar uma “linha” interligando os dois objetos.
13
13
Figura 9
O próximo passo será configurar o grau e cardinalidade do relacionamento

entre as duas entidades.
Relembrando o cenário:
• Um funcionário deve possuir, no mínimo, zero dependente e, no máximo,
muitos dependentes.
• Um dependente deve pertencer, no mínimo, a 1 funcionário e, no máximo, a
1 funcionário.
Devemos também lembrar que a representação das cardinalidades deve ser

informada no lado oposto ao da entidade.
(0,n)
Funcionário (0,n) Dependente
possui
Figura 10
Passo 8 – Para configurar o grau e a cardinalidade da entidade FUNCIONARIO,

selecione a cardinalidade ao lado da entidade DEPENDENTE, com a cardinalidade
selecionada, altere a propriedade “Cardinalidade” para “0,n”.
14
Figura 11
Passo 9 – Para configurar o grau e a cardinalidade da entidade DEPENDENTE,

selecione a cardinalidade ao lado da entidade FUNCIONARIO, com a cardinalidade
selecionada, altere a propriedade “Cardinalidade” para “1,1”.
Figura 12
15
15
Podemos observar o resultado da implementação do cenário de exemplo no

DER abaixo.
(1,1)
possui
Figura 13
Onde:
• Um funcionário possui no mínimo zero e no máximo vários dependentes e;
• Um dependente está ligado, no mínimo, a um e, no máximo, a um funcionário.
Antes de criarmos o modelo lógico, devemos adicionar atributos às entidades.

Para adicionar atributos, basta clicar no objeto “Atributo”, selecionar o atributo
desejado e, em seguida, clicar no objeto no qual queremos adicionar o atributo.
Em nosso exemplo, utilizaremos os atributos do tipo “Atributo” e “Atributo
Identificador”.
Figura 14
16
Passo 10 – Clique no objeto “Atributo”, selecione o objeto “Atributo” e, em
seguida, clique na entidade FUNCIONARIO. Com o objeto “Atributo” selecionado,
altere a propriedade nome para: Nome e pressione “Enter” no teclado.
Figura 15
Passo 11 – Clique no objeto “Atributo”, selecione o objeto “Atributo Identificado”

e, em seguida, clique na entidade FUNCIONARIO. Com o objeto “Atributo”
selecionado, altere a propriedade nome para: Id_Funcionario e pressione “Enter”
no teclado.
Figura 16
17
17
Passo 12 – Adicione dois atributos à entidade DEPENDETE, um atributo (não-

Identificador) com o nome: Nome_Dependente e um atributo Identificador com
o nome: Id_Dependente.
O resultado esperado é o DER exibido abaixo.
Nome_Dependente
(1,1)
possui Id_Dependente
Id_Funcionario
Nome
Figura 17
Gerando o esquema Lógico a partir do DER

Para gerar o esquema lógico (modelo lógico) a partir de um DER no BrModelo,
basta clicar com o botão direito do mouse sobre um local vazio no palco. Em
seguida, clique na opção “Gerar esquema lógico”.
Figura 18
18
Essa ação irá gerar um esquema lógico que podemos observar na imagem abaixo.
Figura 19
Figura 20
Percebam que, ao criar o modelo lógico, o software BrModelo gerou auto-

maticamente a chave estrangeira “Id_Funcionario” na entidade DEPENDENTE,
bem como toda a estrutura de dados do modelo físico (nomes das tabelas, nome de
campos e tipo de dados).
É, nessa etapa, que no BrModelo, temos a possibilidade de alterar o tipo de

dado para determinado Banco de dados.
Caso queira gerar um script para banco de dados Oracle, deve-se alterar os tipos de
dados especificamente para Oracle e, assim, por diante.
19
19
Para nosso estudo, iremos gerar o script SQL com os tipos de dados da confi-
guração padrão do BrModelo. Esse padrão gera scripts com a sintaxe do banco
de dados SQLite.
SQLite é o SGBD de código aberto e o mais utilizado nos ambientes mobile.

Explor
https://goo.gl/h1lcMc
Gerando o script SQL

Para gerar o script SQL referente ao DER que criamos e o modelo lógico que
criamos, até agora, no BrModelo, basta clicar com o botão direito do mouse sobre
um local vazio no palco. Em seguida, clique na opção “Gerar esquema Físico”.
Figura 21
Na tela a seguir, clique no botão “Gerar Modelo Físico”.
Figura 22
20
Essa ação irá gerar um script SQL, que poderá ser salvo em um arquivo do
formato .sql.
Figura 23
Explor
Podemos testar o script gerado na plataforma SQLFiddle: http://sqlfiddle.com/
Figura 24
Explor
O teste do script pode ser acessado em: http://sqlfiddle.com/#!7/05116
21
21
MySQL Workbench
A ferramenta MySQL Workbench é uma ferramenta CASE gratuita, que
oferece as seguintes funcionalidades:
• Desenvolvimento SQL: Funcionalidade para consultas MySQL. Permite
que o usuário se conecte a um banco de dados existente, edite e execute
consultas SQL.
• Modelagem de Dados: Permite a modelagem visual de banco de dados
(criação do modelo lógico e físico).
• Administração de Banco de Dados: Funcionalidade de administrador do
MySQL. Possui uma Interface gráfica para iniciar / parar servidores, criar
contas de usuário, editar arquivos de configuração etc.
O MySQL Workbench pode ser baixado pelo link a seguir, a ferramenta pode ser instalada
Explor
nos sistemas operacionais Windows, Mac OS X, e nas principais distribuições Linux.

https://goo.gl/YGgkwy
Para fazer o download da ferramenta, é preciso possuir uma conta Oracle, para criar uma
conta Oracle: https://goo.gl/s9cHx
No contexto de nossa disciplina, focaremos no desenvolvimento do modelo

lógico/físico e, em seguida, geraremos um script SQL.
Visão Geral da Ferramenta

Na tela principal da ferramenta, clique em “File/New Model”.
Figura 25
22
Na tela a seguir, clique no botão “Add Diagram”.
Figura 26
Essa ação leva à tela principal para o desenvolvimento do modelo lógico.
Figura 27
23
23
Em destaque, temos três áreas da ferramenta:

• Área 1. É o palco do software. É, nesse espaço, que é organizado os objetos
do DER.
• Área 2. Aqui, estão dispostos os principais objetos do DER (entidade, relacio-
namento, atributos), esses objetos adicionados ao palco do software.
• Área 3. Refere-se à tela de visualização rápida dos diversos objetos e proprie-
dades do modelo em desenvolvimento.
Criando o Modelo Lógico

Nessa sessão, criaremos um DER levando em consideração o mesmo cenário
utilizado anteriormente.
• Um funcionário deve possuir, no mínimo, zero dependente e, no máximo,
muitos dependentes.
• Um dependente deve pertencer, no mínimo, a 1 funcionário e, no máximo, 1
funcionário.
Nesse contexto, iremos criar o modelo lógico nos passos a seguir.
Passo 1 – Clique no objeto “New Table” e, em seguida, clique em uma área

vazia do palco. Essa ação irá adicionar um objeto “Table”.
Figura 28
24
Figura 29
Passo 2 – Clique com o botão esquerdo do mouse duas vezes no objeto

“Table1”. Essa ação irá habilitar uma tela de propriedades, nessa tela, altere o
nome da propriedade “Table Name” para: Funcionario.
Figura 30
25
25
Passo 2 – Adicionando um atributo. Na tela de propriedades, logo abaixo da

propriedade “Table Name”, clique duas vezes com o botão esquerdo mouse na
célula abaixo da coluna “Column Name”. Em seguida, altere o nome do atributo
para: id_Funcionario.
Figura 31
Para cada atributo criado na tabela, existem diversas propriedades, como

podemos verificar na imagem abaixo.
Figura 32
Onde, cada propriedade, quando selecionada, atribui uma funcionalidade ao

atributo, essas propriedades são:
• PK: Chave primária (O atributo é uma chave primária).
• NN: Não nulo (o atributo não pode ficar vazio).
• UQ: Único (o valor do atributo deve ser único em toda a tabela)
• BIN: Binário (o atributo só aceita valores binários).
• UN: Unsigned (não permite valores negativos no atributo).
• ZF: Zero fill (preenche os espaços vazios com zero à esquerda até o tamanho
padrão do campo).
• AI: Autoincremento (o valor do atributo é gerado automaticamente pelo SGBD).
26
Para concluir, a configuração do atributo “id_Funcionario”, selecione as opções
“PK” e “NN”.
Passo 3 – Adicione o atributo “Nome”. Clique duas vezes com o botão esquerdo
mouse na célula abaixo do atributo “id_Funcionario”. Em seguida, altere o nome
do atributo para: nome.
Figura 33
O tipo de dado do campo (coluna Datatype) por padrão é VARCHAR(45), para

o nosso exemplo não é preciso alterar. Mas, vale salientar, que é nessa propriedade
que se pode alterar o tipo e o tamanho do atributo.
Passo 4 – Adicione a tabela Dependente. Para isso, clique no objeto “New

Table” e, em seguida, clique em uma área vazia do palco. Essa ação irá adicionar
um objeto “Table”.
Em seguida, clique com o botão esquerdo do mouse duas vezes no objeto

“Table1”. Essa ação irá habilitar uma tela de propriedades, nessa tela, altere o
nome da propriedade “Table Name” para: Dependente.
Figura 34
27
27
Passo 5 – Adicione o atributo chave. Na tela de propriedades, logo abaixo da

propriedade “Table Name”. Clique duas vezes com o botão esquerdo mouse na
célula abaixo da coluna “Column Name”. Em seguida, altere o nome do atributo
para: id_Dependente e selecione as opções “PK” e “NN”.
Figura 35
Passo 6 – Adicione o atributo Nome_Dependente. Clique duas vezes com

o botão esquerdo do mouse na célula abaixo do atributo “id_Funcionario”. Em
seguida, altere o nome do atributo para: Nome_Dependente.
Figura 36
Passo 7 – Adicionando o grau de relacionamento. A ferramenta dispõe de seis

(6) possibilidades para configuração do grau de relacionamento entre tabelas, como
destacado na imagem abaixo.
28
Figura 37
Na sequência (de cima para baixo), esses relacionamentos significam:

• Relacionamento um-para-um (1:1) sem adicionar atributo chave-composto na
entidade fraca.
• Relacionamento um-para-muitos (1:n) sem adicionar atributo chave-composto
na entidade fraca.
• Relacionamento um-para-um (1:1) adicionando atributo chave-composto na
entidade fraca.
• Relacionamento um-para-muitos (1:n) adicionando atributo chave-composto
na entidade fraca.
• Relacionamento muito-para-muitos (n:m).
É importante ressaltar que a notação gráfica utilizada pela ferramenta é a no-

tação engenharia de informações ou notação James Martin (MACHADO, 2014).
Recordando o cenário de nosso exemplo, temos um grau de relacionamento

(1:n). Onde um funcionário pode possuir diversos dependentes, mas um dependente
deve estar vinculado a somente um funcionário.
29
29
Nesse contexto, selecione a relação “one to many identifying relationship”

(Relacionamento um-para-muitos).
Figura 38
Com a ferramenta selecionada, clique primeiro na entidade fraca, nesse

caso, clique na tabela DEPENDENTE, em seguida, por último, clique na tabela
FUNCIONARIO.
O resultado dessa ação pode ser observado na imagem abaixo.
Figura 39
Percebam que, ao configurar o relacionamento, o software criou automati-

camente a chave estrangeira “Funcionario_Id_Funcionario” na entidade DE-
PENDENTE.
Gerando o script SQL

Para gerar o script SQL referente ao modelo lógico que criamos, clique no
“File\ Export\ Forward Enginner SQL CREATE Script ...”.
30
Figura 40
Na tela seguinte, marque as opções: Omit Schema Qualifier in Object Names;

Do Not Create Users. Only Export Privileges e Don’t create view placeholder
tables. Avance, clicando no botão “Next”.
Figura 41
31
31
Na tela seguinte, marque a opção “Export MySQL Table Objects” e avance

clicando no botão “Next”.
Figura 42
Por fim, é gerado um script SQL na sintaxe MySQL para criação das tabelas
referente ao modelo lógico criado pela ferramenta. O script gerado poderá ser
salvo em um arquivo do formato .sql.
Figura 43
32
Explor
Podemos testar o script gerado na plataforma SQLFiddle http://sqlfiddle.com
Figura 44
Explor
O teste do script pode ser acessado em: http://sqlfiddle.com/#!9/378711
33
33
Sites
Manual oficial do MySQL Workbench (em Inglês)
https://goo.gl/oxFJAL
Livros
Banco de dados: Implementação em SQL, PL/SQL e Oracle 11g
Sandra Puga, Edson França e Milton Goya. Capítulo 7.1 - Introdução à linguagem SQL
Banco de dados: Implementação em SQL, PL/SQL e Oracle 11g
Sandra Puga, Edson França e Milton Goya. Capítulo 4.6 - Notação
Vídeos
Usando o brModelo
https://youtu.be/dk1-y0PnjuU
34
Referências
CÂNDIDO, C. H. BrModelo 2.0. 2007. Disponível em: <http://sis4.com/
brModelo/>. Acesso em abr. 2017.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2010.
MACHADO, F. N. R. Banco de Dados: projeto e implementação. 3. ed. São

Paulo, SP: Érica, 2014.
35
35

09 - Modelagem de Dados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

09 - Modelagem de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Modelagem de Dados

Responsável pelo Conteúdo:

• Evolução Histórica de Banco de Dados

Evolução Histórica de Banco de Dados

A seguir, iremos apresentar de maneira cronológica os principais destaques

O que é um Banco de Dados

Sua prestadora de serviços de eletricidade utiliza um banco de dados para

Consideremos também o facebook. Ele precisa armazenar, manipular e

Qual é o Banco de Dados mais utilizado no mundo?

O que é um Sistema Gerenciador

A seguir serão apresentados os quatro principais modelos ou tipos de SGBD.

Um SGBD nesse modelo possui as seguintes vantagens:

Exemplos de sistemas de gerenciamento de banco de dados hierárquico incluem

Um SGDB de Rede possui as seguintes vantagens:

O RDM Server, IDMS e TOTAL são exemplos de sistemas de gerenciamento

Criado na década de 1970 por Edgar Frank Codd, pesquisador da IBM, a

Conceito de relação matemática: https://goo.gl/ZWhdCM

Uma das grandes vantagens desse modelo (SGBD-R) é a sua capacidade de

Uma tabela relacional armazena uma coleção de dados relacionados. A este

Outra grande vantagem é a sua linguagem de consulta poderosa e flexível, o

Quanto às desvantagens, temos:

Exemplos de sistemas de gerenciamento de banco de dados relacional incluem

O SGBD-OO baseia-se nos seguintes componentes:

CLIENTE e EMPREGADO, podem ser criadas como subclasses da classe

As vantagens oferecidas por esse modelo são as seguintes:

Exemplos de sistemas de gerenciamento de banco de dados orientados a

SGBD-OO - Banco de Dados Orientado a Objetos: Uma Realidade: https://goo.gl/7MtFLe

As informações organizacionais são armazenadas em um banco de dados.

O valor da informação reside não apenas na própria informação, mas nas

Nesse contexto, um banco de dados se faz importante, pois gerencia e

Fanderuff, Damaris. Dominando o Oracle 9i: Modelagem e Desenvolvimento.

Júnior, E; Alonso, S. Histórico dos Banco de Dados. Disponível em:

Responsável pelo Conteúdo:

• Introdução à Modelagem de Dados

Introdução à Modelagem de Dados

As técnicas e ferramentas de modelagem de dados capturam e traduzem projetos

A modelagem de dados tem como objetivos:

O modelo de dados é equivalente aos planos de construção de um arquiteto.

Para construir modelos de dados, utilizamos linguagens de modelagem de dados,

Um modelo de dados, por exemplo, pode ser pensado como um fluxograma

É nesse momento em que o analista responsável pelo planejamento do banco de da-

Vamos a um exemplo prático. Imagine que temos a tarefa de planejar um mo-

A partir dessa primeira conversa, criamos nosso primeiro modelo.

Em nossa disciplina, iremos abordar os três tipos de modelos de dados utilizados

Antes de nos aprofundar um pouco mais sobre os modelos de dados, devemos

Nessa etapa, o analista responsável deve buscar basicamente o seguinte:

Essas informações podem ser reunidas de várias maneiras:

É válido ressaltar que o levantamento de requisitos aborda somente a identificação

Identificar e documentar regras de negócios é um processo muito importante para

Regras de negócios também permitem aos analistas entender os processos de

Regras de Negócios dão a classificação adequada de entidades, atributos, relações

Alguns exemplos de regras de negócio:

Regras de negócios faz referência a como o processo é executado e suas restrições.

É preciso ter em mente que se as regras de negócios estiverem incorretas, o

O que é Regra de Negócio? https://goo.gl/VBXloC

Características do modelo de dados conceitual incluem:

O diagrama abaixo é um exemplo de um modelo conceitual de dados.

Proprietário Possui Animal

A partir do diagrama acima, podemos ver que as únicas informações mostradas

• A chave primária para cada entidade especificada.

As etapas para projetar o modelo de dados lógico são as seguintes:

O diagrama abaixo é um exemplo de um modelo de dados lógico.

As etapas para projetar o modelo de dados físico são as seguintes:

A figura abaixo é um exemplo de um modelo de dados físicos.