Modelagem de Sistemas de Informação

FACULDADE METROPOLITANA DE RIO DO SUL
UNIASSELVI - FAMESUL
Rod. Br. 470, Km 140, Nº. 5253 – B. Itoupava - Rio do Sul (SC) – 89160 000
Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Apostila da disciplina de
Modelagem de Sistemas de Informação
Prof. Cleber Nardelli1
1
Todos os direitos reservados, cópia deste material sem aviso provio é considerada uma violação dos direitos autorais.
Não asta sa er, é pre iso sa er fazer Página 1

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Índice
Introdução à Modelagem de Sistemas de Informação ........................................................................................... 5
Modelo ................................................................................................................................................................ 5
Objeto ................................................................................................................................................................. 5
Mapear Objetos do Mundo Real ........................................................................................................................ 6
A Organização e Seus Dados ................................................................................................................................... 7
Sistema de Gerencia de Banco de Dados - SGBD ................................................................................................... 9
Introdução à Modelagem Funcional ..................................................................................................................... 11
Diagrama de Fluxo de Dados – DFD .................................................................................................................. 11
Exercício 1 ..................................................................................................................................................... 15
Exercício 2 ..................................................................................................................................................... 16
Leitura complementar: Análise Essencial - Lista de Eventos ............................................................................ 17
UML ....................................................................................................................................................................... 25
Casos de Uso ..................................................................................................................................................... 26
Exercício ........................................................................................................................................................ 31
Diagrama de Classes ......................................................................................................................................... 32
Classes ........................................................................................................................................................... 33
Propriedades ................................................................................................................................................. 33
Atributos ....................................................................................................................................................... 33
Associações ................................................................................................................................................... 34
Operações ..................................................................................................................................................... 36
Generalização................................................................................................................................................ 36
Dependência ................................................................................................................................................. 37
Exercício ........................................................................................................................................................ 38

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Leitura complementar: Conceitos e Princípios da Orientação a Objeto ...................................................... 38
Introdução ao Modelo ER ..................................................................................................................................... 40
O Modelo Conceitual ............................................................................................................................................ 41
Entidades........................................................................................................................................................... 42
Relacionamentos .............................................................................................................................................. 46
Cardinalidade de Relacionamentos .................................................................................................................. 48
Cardinalidade Máxima .................................................................................................................................. 48
Cardinalidade Mínima ................................................................................................................................... 49
Exemplo do Uso de Cardinalidades nas Associações.................................................................................... 50
Atributos ........................................................................................................................................................... 50
Identificação de Entidades ................................................................................................................................ 51
Identificação de Relacionamentos .................................................................................................................... 52
Exercícios........................................................................................................................................................... 53
O Modelo Lógico ................................................................................................................................................... 56
A Abordagem Relacional ................................................................................................................................... 56
Tabela ............................................................................................................................................................ 57
Chave............................................................................................................................................................. 57
Domínios e Valores Vazios ............................................................................................................................ 60
Restrições de Integridade ............................................................................................................................. 61
Aplicação do Modelo Lógico ............................................................................................................................. 62
Implementando Tabelas ............................................................................................................................... 62
Implementando Relacionamentos................................................................................................................ 63
Implementando Atributos Multivalorados ................................................................................................... 67

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Mútua Exclusividade ......................................................................................................................................... 68
Restrições de Integridade ..................................................................................................................................... 70
Integridade de Unicidade de Valores................................................................................................................ 70
Integridade Referencial..................................................................................................................................... 71
Exclusão e Atualização de Chaves em Cascata ................................................................................................. 71
Generalização e Especialização............................................................................................................................. 73
Uma tabela por hierarquia de classes .............................................................................................................. 73
Uma tabela por entidade especializada ........................................................................................................... 74
Normalização ........................................................................................................................................................ 76
Passagem à primeira forma normal (1FN) ........................................................................................................ 76
Passagem à segunda forma normal (2FN) ........................................................................................................ 77
Passagem à terceira forma normal (3FN) ......................................................................................................... 78
Passagem à quarta forma normal (4FN) ........................................................................................................... 80
Referências............................................................................................................................................................ 82

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Introdução à Modelagem de Sistemas de Informação
Todo software para ser construído depende de uma boa modelagem da informação sobre à qual este
irá trabalhar. O Contexto da informação neste caso é algo muito importante e será conseguido através de uma
boa análise de software, etapa que obrigatoriamente deve ser realizada antes mesmo da modelagem de um
sistema de informação. Normalmente a informação a ser modelada está compreendida nos requisitos
funcionais (e até mesmo os não-funcionais) que envolvem determinada aplicação.
Inicialmente precisamos entender um pouco sobre os princípios norteadores que envolvem a
modelagem de SI.
Modelo
Inicialmente parece muito simples, porém teremos de entender mais profundamente o conceito de
modelo. A definição a seguir é mencionada por COUGO (1997):
Modelo é a represe tação abstrata e simplificada de um sistema real, com a qual se
pode expli ar ou testar o seu o porta e to, e seu todo ou e partes .
Para constatar a veracidade da expressão acima, podemos pegar uma maquete de um edifício
qualquer ou ainda uma planta baixa de uma casa, em ambos os casos temos modelos. Sendo assim podemos
sinteticamente dizer que um modelo é:
U odelo é u a represe tação a strata e si plifi ada
Um modelo não é o objeto real, apenas algo que o representa e sendo assim poderá ser realizado, isto
é, construído ou não. A ideia central é representar elementos da realidade, em escala ou não e assim
podemos percebê-los e entendê-los.
Objeto
O te o o jeto utilizado pa a ep ese tação de ual ue oisa, pessoa, a iente, conceito, etc.
Independente do paradigma utilizado para desenvolvimento, a existência e caracterização de objetos é
importante, pois sempre estamos tratando de algo.
Um objeto observado é o ponto de partida para a modelagem de dados ou não. Temos de ter um
objeto a reproduzir, seja ele concreto ou imaginário. Para a modelagem da informação faz-se necessário então
que observemos objetos do mundo real ou imaginemos objetos para modelá-los.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Por este motivo o processo de levantamento de dados (na fase de análise da aplicação), é tão
importante para a modelagem de dados. Se as informações que caracterizem os objetos não forem
leva tadas, ão o segui e os o se vá-los e logo o odelo esulta te ão os o te á.
Quando observamos um objeto no mundo real o que percebemos? Como eles nos são apresentados?
O que deveremos buscar?
Essas são algumas questões não tão complexas, porém importantes. A medida que o estudo da
modelagem prosseguir veremos que os objetos a serem modelados possuem características próprias e
comportamentos dinâmicos que alteram o valor dessas características.
Mapear Objetos do Mundo Real

Observe as figuras a seguir:
Quais são as características observadas das imagens que podemos modelar?

Na imagem 1, podemos observar: Janelas, Rodas, Porta...
Na imagem 2, podemos observar: Rodas, Banco, Volante...
Lembre-se, o que pode ser observado ou imaginado, pode ser modelado. Ou seja, na imagem 1, não se
vê, mas sabe-se que existe um volante. Em ambas as imagens, não se vê, mas sabe-se que existe motor.
Devemos ter em mente porem, que o ideal é modelar aquilo que se consegue formalmente
estabelecer, ou seja, não adianta imaginar n variáveis para uma situação, se a regra que é estabelecida para o
negócio atual não as estabelece.
Por exemplo, digamos que possuímos certa regra de negócio que refere-se ao cadastro de clientes, ela
estabelece que: O adastro de lie tes deverá ser dotado de u a odifi ação u éri a i re e tada
Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
automaticamente para cada novo cliente a ser inserido de forma sequencial sem que este se repita. Deverá
conter o nome completo do cliente, incluindo seu sobrenome. Disponibilizar também os documentos CPF e
RG. . Esta regra de negócio foi especificada pelo cliente, que não solicitou por exemplo o telefone do cliente.
Devemos inserir (imaginar) esta informação também?
De fato poderemos neste caso inseri-la, porém para cada informação nova inserida por nós, sem que
esta esteja declarada nas regras de negócio, devemos analisar primeiramente o escopo do projeto entre
outras variáveis, para analisar se é cabível ou não.
Por exemplo, no caso acima citado, digamos que o escopo do projeto trata-se de u “iste a
Co e ial pa a Pe ue as E p esas do a o va ejista , este aso, a e ia i se i este adast o o tipo
sanguíneo da pessoa?
A Organização e Seus Dados

Muitas organizações iniciam suas atividades sem que um sistema de informação esteja contemplado
em sua estrutura inicial. A organização é estabelecida e controles manuais são elaborados para que ela possa
progredir e consequentemente ter lucro. Com o passar do tempo alguns controles começam a ser
automatizados, ou seja, a organização instala um ambiente de informática (muitas vezes mínimo necessário),
para que um software possa ser instalado e comece a disponibilizar determinadas funções e controles para
uma determinada área. Este software por sua vez possui um banco de dados (muitas vezes instalado em uma
máquina qualquer), este servirá para armazenar os dados inseridos pelos usuários nas interfaces (telas)
disponibilizadas pelo software. A medida que o tempo vai passando, mais dados são inseridos e em seguida
iniciam-se as emissões de alguns relatórios. Inicialmente estes relatórios são apenas listagens para simples
conferência, por exemplo. Novos relatórios são solicitados, agora a visão começa a ser gerencial, busca-se
cruzar certos dados, disponibilizando assim informação mais elaborada para o gestor (informação esta que
poderia levar dias para ser processada).
A vida da organização segue neste ritmo, até que outra área necessite também de um certo nível de
automatização. Então inicia-se novamente o ciclo anterior para a nova tarefa, um novo software é instalado,
um banco de dados é criado (geralmente separado do banco de dados da outra área), relatórios são
solicitados, etc.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Em determinado momento percebe-se que não basta simplesmente inserir dados e gerar relatórios ou
consultas, deve-se agora cruzar os dados das diversas áreas e estabelecer controles mais eficientes
abrangendo toda a organização. E agora?
Uma empresa que possui as áreas de Produção, Vendas e Compras em funcionamento, teria nessas
condições o seguinte quadro:
Produção Vendas Compras
Arquivos produção Arquivos Vendas Arquivos Compras
Produtos Produtos Produtos

... ... ...
Figura 1 - Banco de Dados Isolado
Neste quadro teremos uma organização com bancos de dados separados, ou isolados, o que dificultará
e muito a integração entre eles. Neste caso surge o problema da redundância de dados, que ocorre quando
determinada informação está representada no SI várias vezes. A redundância de dados nem sempre é algo
ruim, tanto que podemos tela de duas formas diferentes, uma que é a controlada e outra que é a não
controlada.
A primeira forma (controlada), é de conhecimento do sistema, ou seja, ele foi construído levando-se
em conta que aquela determinada informação estaria redundante. Isto pode ocorrer em parte para melhorar
a confiabilidade ou o desempenho global do sistema. Um exemplo é um sistema distribuído, onde a
informação é armazenada em vários computadores, permitindo acesso rápido a partir de qualquer um deles.
A redundância controlada por sua vez, ocorre geralmente quando o controle de garantia da não
redundância, está com o usuário e não com o software. Este tipo deve ser evitado. Por exemplo, entrada
repetida da informação, no caso do exemplo anterior, os dados de produtos são inseridos nos três setores da
empresa. Quanto a inconsistência dos dados, no mesmo exemplo poderá ocorrer caso um determinado
produto seja alterado no setor de compras e não seja alterado nos outros setores.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
A solução mais eficiente para evitar redundância de informação é o uso de banco de dados
compartilhado ou banco de dados único. Veja exemplo na imagem a seguir:
Produção Vendas Compras
Produtos
Clientes
Banco de Dados
Figura 2 - Banco de Dados Compartilhado
O Co ju to de a uivos i teg ados ue ate de au o ju to de siste as, ha ado de Ba o de

Dados BD .
O Compartilhamento de dados por sua vez, tem reflexos na estrutura do software. A estrutura interna
dos arquivos passa a ser mais complexa, pois estes devem ser construídos deforma a atender às necessidades
dos diferentes sistemas.
Para contornar este problema faz-se necessário o uso de um Sistema de Gerencia de Banco de Dados –
SGBD.
Sistema de Gerencia de Banco de Dados - SGBD

O desenvolvimento de aplicações sofreu profundas modificações desde o início de sua existência.
Inicialmente o desenvolvimento incorporava em um único programa (ou arquivo fonte) toda a regra de
negócio, interface, cálculos e persistência.
Com o passar do tempo várias atividades comuns ao desenvolvimento, como o uso de janelas, acesso à
dados, etc., foram sendo divididas em camadas, desta forma normalmente os programas não contém todo o
código referente a tarefas como exibição dos dados na interface. Isto mudou também com a profunda
adaptação dos sistemas operacionais, que agora mais do que nunca disponibilizam funções diversas para uso
pelos sistemas aplicativos.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
O mesmo caminho foi trilhado na questão gestão dos bancos de dados. O advento de SGBDs, tirou das
aplicações tarefas básicas, porém necessárias, para trabalhar com dados, como o acesso e controle aos
arquivos de dados da estrutura antiga (isolado). Um SGBD é um software que incorpora as funções de
definição, recuperação e alteração de dados em um banco de dados.
Este assunto será melhor discutido e abordado na disciplina de banco de dados.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Introdução à Modelagem Funcional

A modelagem funcional consiste em especificar os processos que devem ocorrer no sistema, de forma
não temporal, ou seja, ele descreve como os dados são transformados, mas não quem ou quando isto
ocorrerá. De fato através da modelagem funcional é possível verificar os cálculos (ou funções) executados em
um sistema, em sua essência ele especifica o que acontece de fato dentro de um software.
O modelo funcional é basicamente composto por múltiplos DFD's (Diagramas de Fluxo de Dados), que
especificam o significado das operações e restrições.
Este modelo descreve como os valores de saída são gerados a partir dos valores de entrada e consiste
a o st ução de u odelo fu io al aseado e DFD’s pa a ep ese ta as t a sfo ações ao i te io do
sistema. O modelo funcional não tem preocupações em saber quando os valores são calculados.
Diagrama de Fluxo de Dados – DFD

Essa ferramenta estruturada de diagramação de software possui tipos diversificados de diagramas,
derivando-se (ou explodindo) em outros subseqüentes (FERREIRA, 1989).
1. Diagrama de fluxo de dados
 Imagem do sistema, projeto ou produto;
 Modelo da organização;
 Apresentação em etapas com o aumento gradativo de detalhes;
 Utilização dos princípios da modularização e da hierarquização.
2. Diagrama de contexto
 Visão global;
 Delineia o ambiente e amplitude;
 Representado pelas entidades externas e macrofluxos;
 Um único macroprocesso;
 Sem depósito de dados;
3. DFD nível zero
 Visualização clara do todo;
 Com todos os macroprocessos;
 Com entidades externas, fluxo de dados e depósito de dados principais;
4. DFD nível 1
 Explosão do nível zero;
 Com mais detalhes, mais completo;
 Com tratamento de exceções.
Obs: Na prática é utilizado apenas um destes dois (Contexto ou Nível 0).

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Simbologia:
Entidades Externas ou Atores
Figura 3 Símbolo Entidade Externa
Utilizado para representar:

 Categorias lógicas de objetos ou pessoas que representam origem ou destino de dados, que acionam um
sistema e/ou recebem informações;
 Podem ser pessoas (físicas ou jurídicas), sistemas ou unidades departamentais;
 Possuem as seguintes regras:
o X: Uma letra para identificação (não é obrigatório);
o Nome: Nome da entidade (ex.: Depto. Pessoal, Cliente, Sistema XYZ, Banco, etc);
o /: Duplicação ou repetição da entidade externa no desenho;
Fluxo de Dados
Figura 4 Símbolo Fluxo de Dados
Utilizado para representar:

 Meios por onde passam dados e informações;
o Nome: nome do dado (ex.: comandos, solicitação pedido, dados, relatório XY, etc);
o Arg: Argumento de acesso a um depósito, quando conhecido (ex.: CNPJ, CPF, matrícula, código XY,
etc.).
Os fluxos de dados sempre envolvem um processo, ou seja, não é possível enviar de:
 Entidade para Entidade;
 Entidade para depósito de dados, e vice-versa;
 Depósito de dados para depósito de dados.
Processos

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Nr.
Nr.
Nome
Nome
ou Loc.
Figura 5 Símbolos para Processos
Utilizados para representar:

 Módulos do sistema ou requisitos funcionais;
 Transformam fluxos de dados numa atividade;
o Nr: número de referência do processo (ex.: nível 0 e/ou 1 = 1, 2, 3..., demais níveis = 1.1, 1.2 ...);
o Função: descrição do processo no verbo infinitivo (ex.: Registrar entradas, Manter clientes, Gerar
notas fiscais, Gerar relatórios);
o Loc.: local físico onde se desenvolve o processo (ex.: Depto. Informática, Área Contábil). Depende da
notação a ser utilizada.
Para facilitar a descoberta dos processos, pode-se relatar no mínimo os requisitos funcionais do
sistema ou software.
Depósito de Dados
Dn Nome
Figura 6 Símbolo para Depósito de Dados
Utilizados para representar:

 Locais de armazenamento de dados;
 São os arquivos propriamente ditos;
o Dn: número do depósito (ex.: nível 0 e/ou 1 = D1, D2);
o Nome: nome do depósito, significativo para o sistema e usuário (ex.: clientes, contas a pagar...);
Para facilitar a descoberta dos Depósito de Dados, consideram-se basicamente três tipos de arquivos:
 Cadastral (ex.: Cliente, Fornecedor, Itens);
 De Movimento – junção de dois ou mais depósitos (ex.: Movimento de notas fiscais, Movimento de Cálculos
Xyz, Movimento de Itens);
 Tabelas – que contém domínios, ou seja, freqüentemente com dois campos e vários registros (ex.: Tabela de
UF, Tabela de Tipos, Tabela de Estado Civil).

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
A dinâmica da lógica de funcionamento do Diagrama de Fluxo de Dados (GANE; SARSON, 1986) pode
ser assim representada:
ENTIDADE ENTIDADE
EXTERNA EXTERNA
1 2
PROCESSO PROCESSO
FLUXO DE FLUXO DE
DADOS 1 DADOS 4
1 2
FLUXO DE FLUXO DE
DADOS 2 DADOS 3
DEPÓSITO DE
DADOS
Figura 7 Dinâmica lógica do DFD
Não existe uma regra definida para elaboração e construção dos desenhos do DFD, a prática é que vai
determinando a maneira mais produtiva. Como sugestão, alguns passos:
1. Identificar e numerar os requisitos funcionais;
2. Identificar entidades externas;
3. A cada entidade externa identificada associar fluxos de dados que essas enviam, consomem ou recebem
e/ou informações;
4. Identificar as manipulações dos depósitos de dados (arquivos), associá-las às entidades externas envolvidas
e detalhar o argumento e nome do fluxo de dados que deseja receber;
5. Desenhar o primeiro DFD:
a. Iniciar no canto esquerdo com a entidade externa principal;
b. Procurar deixar todas as entidades externas nos cantos (preferencialmente à esquerda, as de
ORIGEM e à direita, as de DESTINO);
c. Desenhar fluxos necessários, os processos requeridos e os depósitos de dados para guardar os
dados e recuperar informações;
d. Não se preocupar ainda com o começo e o fim do sistema;
e. Não numerar processos ainda;
f. Verificar se todas as entradas e saídas foram incluídas;
g. Associar manipulações necessárias a depósito de dados;
h. Redesenhar o DFD minimizando as interseções de fluxos de dados;
i. Numerar os processos e depósitos de dados;
j. Discutir com o cliente e anotar as mudanças necessárias;
k. Explodir ou derivar os processos complexos em níveis inferiores, tentando resolver o tratamento de
erros e exceções e, se necessário, incorporar as mudanças ao nível superior;

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Para facilitar a diagramação do DFD recomenda-se lembrar o princípio básico de processamento de

dados: Entrada, Processamento e Saída. O exemplo do DFD do software de vídeo locadora pode contribuir
com essa lógica de atribuição de processos ou requisitos funcionais.
MANTEM CLIENTES
a. MANTEM FITAS
ADMINIST. CARTEIRINHA
SISTEMA
VÍDEO LOCA FITAS b.
VIDEO
LOCADORA CLIENTES
LOCADORA RECIBO
GERA RELATÓRIOS
Figura 8 DFD Contexto – Vídeo Locadora
a. a.
ADMINIST. 2 ADMINIST.
DOC.
VÍDEO COMANDOS MANTER VÍDEO
CONTROLE
LOCADORA FITAS LOCADORA
/ /
1 3
DADOS DADOS
COMANDOS MANTER LOCAR
FITA FITA
CLIENTES FITAS
DADOS
CLIENTE
D2 FITAS DADOS
RECIBO
LOCAÇÃO
DADOS
D1 CLIENTES
CLIENTE
DADOS
FITA
D3 MOV. FITAS
DADOS
CLIENTE RELATÓRIO XYZ
4
DADOS
GERAR
LOCAÇÃO
RELATÓRIOS
SOLICITAÇÃO
b.
CARTEIRINHA
CLIENTES
Figura 9 - DFD Nível 0 - Vídeo Locadora
Exercício 1
Uma livraria montou um site para venda de seus produtos via Internet. Ele funciona assim:
O cliente entra no site, acessa uma tela de produtos disponíveis e seleciona o produto desejado. O
sistema consulta um arquivo de produtos e exibe os dados detalhados do mesmo (foto, preço e descrição
sucinta). Se o cliente deseja comprar o produto, ele informa seu código (código do cliente) no campo
destinado a isso. O sistema consulta o arquivo de clientes. Se ele não está cadastrado ou seu código é inválido,
o sistema oferece uma tela de cadastramento que o cliente preenche, informando nome, endereço para

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
entrega, telefone, número do cartão de crédito e operadora do cartão (única forma de pagamento que a
livraria aceita para venda via Internet). O sistema fornece um código para o novo cliente.
Para cliente cadastrado, o sistema exibe uma tela com os dados do pedido para o cliente imprimir em
sua impressora ou salvar em seu disco, armazena os dados da venda num arquivo de pedidos, atualiza o saldo
do produto vendido no arquivo de produtos e a nota fiscal é automaticamente impressa na impressora
existente no setor de estoques da livraria e irá acompanhar a entrega do produto ao cliente, feita pelo
motobói ou por transportadora, que pede a assinatura do cliente no canhoto da nota fiscal para comprovar o
recebimento do produto. Este canhoto volta para o setor de estoques que o armazena numa pasta.
No final do dia, o sistema examina o arquivo de produtos e verifica quais mercadorias atingiram seu
ponto de alarme e gera, automaticamente, uma relação de reposições de estoque, que sai na impressora do
Setor de Estoques, para as providências de reposição junto aos fornecedores. Também cabe a este setor
comandar, ao sistema, o cadastramento de novos produtos que chegam ao estoque, incluindo seus dados no
arquivo de produtos.
O gerente da livraria também usa o sistema: ele pode obter, na tela ou impressora, um resumo das
vendas e outro de movimentação de clientes, ambos referentes a um período de tempo por ele informado.
Elabore um conjunto de DFDs em níveis para modelar o sistema (software) descrito, composto de
a) Diagrama de contexto;
b) Diagrama nível zero.
Exercício 2
Uma pequena empresa de turismo possui um Sistema de Viagens, em computador, que exibe uma tela
de menu com quatro opções: 1 - Manter clientes, 2 - Manter fornecedores, 3 - Emitir Passaporte e 4 - Emitir
relatórios. Se o usuário digitar uma opção inválida ela é rejeitada.
A opção 1 exibe uma tela de cliente que permite receber dados de cliente para inclusão, exclusão,
alteração ou simples consulta, acessando, sempre, o arquivo de clientes.
A opção 2 é similar a opção 1, acessando o arquivo de fornecedores.
A opção 3 exibe uma tela para preenchimento de passaporte. Nela o usuário digita o código do cliente
que está fazendo uma compra de viagem. O sistema valida o cliente no arquivo de clientes, rejeitando em caso
de cliente não existente. Se o cliente for válido, o mesmo é feito para o fornecedor do serviço, acessando,

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
obviamente, o cadastro de fornecedores. A seguir, o funcionário completa os demais campos da tela de

passaporte e o sistema emite-o na impressora, cadastrando-o no arquivo de passaportes.
A opção 4 permite emitir três relatórios: o de passaportes, o de clientes e o de fornecedores, todos em
papel, a partir dos respectivos arquivos.
a) Diagrama de contexto;
b) Diagrama nível zero.
Leitura complementar: Análise Essencial - Lista de Eventos

É uma relação dos estímulos que ocorrendo no mundo exterior implicam em alguma resposta do
sistema.
Nós analistas de sistemas, construímos sistemas para as mais diversas áreas, que tem como ponto
comum a interatividade, ou seja, esses sistemas agem sobre coisas que estão normalmente fora de seu
controle e essas mesmas coisas agem sobre o sistema. Senão, vejamos o seguinte exemplo para entender
melhor:
Os usuários de ônibus intermunicipal/interestadual que interagem com o sistema de venda de
passagens estão fora do controle dos vendedores de passagem. Um usuário pode decidir não
utilizar o ônibus num determinado dia, ou utilizar sem comprar uma passagem naquele dia. O
Vendedor das passagens não tem poder para obrigar o usuário a comprar uma passagem, ou
escolher uma das opções anteriores. Mas se um usuário resolve comprar uma passagem, ele
terá de interagir com o vendedor de passagens, fornecendo dinheiro. Como resposta o vendedor
age de uma certa forma que afeta o passageiro: ele entrega as passagens e talvez o troco em
dinheiro.
Observando esse exemplo da vida real, podemos entender que o usuário do ônibus é parte de um
determinado ambiente, que age sobre o sistema, digamos de venda de passagens e o sistema reage sobre ele.
A figura a seguir representa esse sistema e suas interações:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Escritório Movimento Diário

Rodoviária
Solicitação
de Passagem
Passagem Vendedor
de
Passagens
Passagem Usuário
Troco
Figura 10 Sistema de venda de passagens de ônibus
Na imagem abaixo, segundo McMenamin, designamos de evento e resposta as interações entre o

sistema e o ambiente.
Evento
Sistema
Ambiente
Interativo
Resposta
Figura 11 Interações entre o sistema
Vale destacar aqui que evento é alguma mudança que o ocorre no ambiente, caracterizada pela
disponibilização ou envio de uma informação, e uma resposta é um conjunto de ações executadas e um
conjunto de dados apresentados pelo sistema sempre que ocorre um determinado evento. Por exemplo, o
vendedor de passagens fornece-as e, possivel e te, o t o o o o esposta ao eve to passagei o soli ita
passage .
Observe que neste caso tempos ações e informações tanto no evento como na resposta. O importante
de entendermos o conceito aqui mostrado é que um sistema de informações é interativo, logo ele é composto
de eventos e respostas.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Podemos dizer que quando a resposta de um sistema a um evento foi determinada antes da ocorrência
do evento, então esta é uma resposta planejada. Um sistema de informação computacional, tem como
característica ser um sistema de respostas planejadas e não ad-hoc. Logo na abordagem essencial, o
fundamental no levantamento de informações para a construção de um sistema é o descobrimento dos seus
eventos e respostas.
Um sistema de respostas planejadas responde a um conjunto de eventos predefinidos, com formato de
resposta também predefinido; logo, ao modelarmos os requisitos de um sistema, podemos derivar e analisar
os fatos e ações que existem em um ambiente a ser sistêmico.
Vamos utilizar como exemplo a nossa casa. O sistema de estoques de alimentos e materiais de limpeza
de nossa casa possui quais eventos ?. Por exemplo: Verificação de quantidades em estoque;
O sistema interage com o ambiente que é a família. O sistema é delimitado pelos armários nos quais
colocamos produtos de alimentação e os materiais de limpeza, não sendo considerados pelo sistema
depósitos intermediários, tais como: baldes, saleiros, açucareiros, etc.
Um evento provoca uma resposta planejada de solicitação de compra, ou melhor, como é comum,
uma anotação na lista de compras semanal ou mensal basicamente, conforme demonstrado na imagem
abaixo:
Evento
Sistema de
Alimentos e
Mat. de Família
Limpeza
Solicitação
de Compra
Figura 12 Estrutura de eventos do sistema e compras familiar
Sempre o mais difícil é entender que evento provoca a resposta, pois o usuário apresenta-nos
normalmente em levantamentos as respostas que ele necessita e conhece, sendo muito difícil que ele nos
apresente o evento de forma destacada.
Continuando com o exemplo, que evento provoca em nossa casa, que se faça uma anotação na lista de
compras semanal, ou mensal ? Poderíamos chamar de verificação de produtos.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Se pensarmos mais um pouco, podemos verificar que existem alguns itens de compra que são
necessários (em alguns momentos) imediatamente, porém a lista de compras do mês não leva em
consideração esse fato, ela é feita baseada no consumo, no saldo em estoque e necessidade que a família tem
para um mês de consumo. Logo existe mais de um evento nesse sistema, pois dois tipos de respostas são
apresentadas:
Evento 1
Verificação de
Saldos para lista
Evento 2
Detecção de falta
Sistema de
Alimentos e
Mat. de Família
Limpeza
Solicitação de
Compra Urgente
Solicitação de
Compra mensal
Figura 13 Detecção de vários eventos
Os eventos aos quais um sistema responde são de dois tipos: eventos externos, que são iniciados por
fatos ou acontecimentos do ambiente, e os eventos temporais que são iniciados pela passagem de
determinado tempo.
O primeiro evento do exemplo, caracteriza-se por um evento externo ao sistema, e o segundo como
temporal, pois ocorre devido à passagem do tempo, normalmente no final do mês.
Ainda observando o exemplo, poderíamos criar um outro evento que seria: caso eu possua
determinado item a ser utilizado porém não possuo mais nenhum item na dispensa, posso disparar uma
compra para renovar o estoque da dispensa imediatamente.
Que evento seria esse ? É um terceiro evento ? Ou é um evento que produz duas respostas ?
Neste caso existem dois eventos somente, pois somente dois fatos externos ao sistema caracterizam-
se como eventos e obtêm resposta.
É comum, ao modelarmos um sistema, apresentarem-se fatos externos ao ambiente do sistema
inclusive. Torna-se necessária a conciliação entre o que é do escopo do sistema e o que não é.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Um evento pode ser definido informalmente como um acontecimento do mundo exterior que requer
do sistema uma resposta.
Um estímulo: É um ativador de uma função. É a forma como o evento age sobre o sistema. É a
conseqüência do fato de ter ocorrido um evento externo. É a chegada de um estímulo que indica que um
evento ocorreu e isto faz com que o sistema então ative uma função predeterminada para produzir a resposta
esperada.
Uma resposta: É o resultado gerado pelo sistema devido à ocorrência de um evento. Uma resposta é
sempre o resultado da execução de alguma função interna no sistema como conseqüência do reconhecimento
pelo sistema de que um evento ocorreu. Pode ser:
 Um fluxo de dados saindo do sistema para o ambiente externo;
 Uma mudança de estado de algum dado (o que equivale à inclusão, exclusão ou modificação de algum
registro de um arquivo);
 Um fluxo de controle saindo de uma função para ativar outra função.
Respostas de um Evento
Todo evento somente é um evento se ele fornecer respostas ao ambiente externo ao sistema.
Observando o primeiro diagrama desenhado no exemplo anterior, observa-se que o estímulo oriundo do
ambiente externo ao sistema foi uma solicitação de retirada de um produto, que provocou uma resposta do
sistema.
O importante é que não devemos procurar eventos dentro da essência de um sistema e sim no
ambiente externo a este. O que estimula um evento é uma informação que entra no sistema, no caso do
exemplo, um produto solicitado.
A existência de duas respostas caracteriza bem um evento, pois como ele é composto de vários
processos, logo pode fornecer mais de uma resposta, inclusive resultados de decisão.
Evento Estímulo Ação Resposta
Retirada de Produto Dados do Produto Verificação de Saldo Produto Fornecido
Atualização de Saldo Pedido de Compra urgente
Atividades Essenciais

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Um sistema de respostas planejadas interage com o mundo à sua volta, ou seja, seu ambiente, pela
identificação e reconhecimentos de determinados estímulos e pela execução de um conjunto de instruções
preparadas em resposta.
Este conjunto de instruções é o que chamamos de atividade essencial, e responde a um único evento
que pode ser externo ou um evento temporal.
Logo, o princípio é o evento, e depois as atividades que constituem este evento, ou melhor, que
produzem resposta a este evento. Devemos ter em mente sempre que, um evento sem resposta não é um
evento.
Dados e Memória Essencial
Nós humanos executamos diversas atividades mentalmente, ou com auxílio de papel e caneta, e
utilizamos a nossa memória para fazer cálculos e decidir quantidades a comprar. Entretanto para que um
sistema forneça uma resposta adequada, as atividades de um evento, deverá ter a sua disposição várias
informações.
No exemplo da dispensa, o nome do produto, a quantidade em estoque, a quantidade de consumo
médio no mês, etc.
O ideal no projeto de sistema, é modelarmos em primeiro lugar todos os eventos de um sistema,
porém sem detalharmos seus processos ou atividades em nível de detalhe, sempre obteremos a visão de quais
são os eventos e principais atividades sempre em visão macro.
Após o levantamento de todos os eventos, podemos então, já com a localização de alguns objetos de
dados, partir para o processo de modelagem de dados, então esmiuçando o máximo e com alto nível de
abstração para retratarmos uma realidade de um ambiente.
Imaginamos a seguinte situação: Vamos até o mercado e efetuamos as compras necessárias para a
nossa dispensa. O supermercado nos fornece uma nota fiscal, ou cupom de caixa em que estão discriminados
todos os produtos comprados e suas quantidades. Isto irá criar um evento, que consiste em movimentar os
estoques, com a entrada de produtos que adquirimos na compra.
Qual é a ação deste evento, ou quais são as suas atividades ?
Observe o diagrama de eventos e depois para um DFD com resposta:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Cupom Fiscal
Atualizar
Estoques
Quantidade em Estoque
Inventário
Figura 14 DFD (Incompleto)
Então, algo ainda está faltando neste caso.

Mentalmente quando colocamos os produtos comprados no armário, realizamos uma contagem de
cada um, obtendo o número final em estoque. Essa lista mental de quantidades atualizadas em estoque
também deve ser a resposta de nosso evento, ficando desta forma caracterizada uma resposta do sistema ao
ambiente:
Cupom Fiscal
Quantidades
Atualizadas
Atualizar
Estoques
Quantidade em Estoque
Inventário
Figura 15 DFD Completo (com resposta)
Abaixo está discriminada uma lista de eventos para que possamos abstrair e visualizar principalmente
as diferenças entre o ambiente externo a um sistema e as funções de um sistema, assim como identificar o
conceito de resposta a um evento.
Nr. do Evento Estímulo Ação Resposta
Evento

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
1 Cliente Faz pedido Pedido Registrar pedido Pedido registrado

2 Cliente cancela pedido Pedido de Cancelar pedido Pedido cancelado
cancelamento
3 Cliente envia Cheque Emitir recibo de Recibo de Pagamento
pagamento pagamento
4 É hora de verificar Solicitação de Relatório Verificar e emitir Relatório de pedidos em
pedidos em atraso de Pedidos em atraso relatório atraso
5 Verificação de Solicitação de Verificar nível de Solicitação de compra
suprimento verificação de nível de suprimento
suprimento Emitir solicitação de
compra

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
UML
Não poderemos iniciar o estudo de diagramas como caso de uso, sequencia, classes, etc., sem antes
conhecer um pouco sobre a UML. UML vem da sigla em inglês Unified Modeling Language, trata-se de uma
família de notações gráficas, apoiada por um metamodelo único, que ajuda na descrição e no projeto de
sistemas de software, particularmente daqueles construídos utilizando o estilo orientado a objetos (OO).
A UML é um padrão relativamente aberto criado pela OMG (Object Management Group), um consórcio
aberto de empresas. O OMG foi formado para estabelecer padrões que suportassem interoperabilidade,
especificamente a de sistemas orientados a objetos.
A UML nasceu da unificação de diversas linguagens gráficas de modelagem orientadas a objetos que
floresceram no final dos anos oitenta, início dos noventa. Desde sua aparição em 1997, ela fez com que essa
torre de Babel fosse resolvida.
Embora a UML possa ser utilizada como forma de projeto e até linguagem de desenvolvimento, a sua
principal forma de uso é para a elaboração de esboços. Nessa utilização, os desenvolvedores usam a UML para
ajudar a transmitir alguns aspectos de um sistema.
Resumidamente a UML é uma linguagem visual para especificação de software, independentemente
da tecnologia de desenvolvimento utilizada (linguagens) e também independente do processo de
desenvolvimento utilizado. A UML não é uma linguagem de programação bem como também não é uma
técnica de modelagem.
Um processo de desenvolvimento que utilize a UML como linguagem de modelagem envolve a criação
de diversos documentos, que podem ser textuais ou gráficos e são denominados de artefatos de software. Os
conjuntos desses artefatos compõem as visões do sistema. Os artefatos gráficos são produzidos através da
utilização dos diversos diagramas da UML.
As visões UML podem ser divididas em três grupos
Estática ou Estrutural Comportamental Arquitetura Física
Diagrama de Classes Diagrama de Casos de Uso Diagrama de Componentes
Diagrama de Objetos Diagrama de Sequencia Diagrama de Implantação.
Diagrama de Colaboração
Diagrama de Estados
Diagrama de Atividades

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Casos de Uso
Os casos de uso são uma técnica para capturar os requisitos funcionais de um sistema. Eles
basicamente descrevem as interações típicas entre os usuários de um sistema e o próprio sistema, fornecendo
uma narrativa sobre como o sistema é utilizado.
Trata-se de um modelo comportamental, que essencialmente (assim como em um DFD) especifica
como os valores são processados sem preocupações como, ordenação das ações (quando ocorrem), as
decisões ou as estruturas de objetos.
Nós vimos que na modelagem funcional são executadas algumas etapas, sendo elas: Identificar as
requisições de entrada e saída (para usuários e/ou envolvendo outros sistemas), construir diagramas
mostrando as dependências funcionais (até mesmo um fluxograma pode ser utilizado para expressar isto),
descrever as funções (DFD ou Caso de uso) e identificar as restrições.
O caso de uso neste cenário exerce um papel fundamental na medida em que: É o principal diagrama
para ser utilizado no diálogo com o usuário na descoberta e validação de requisitos e também constituem
elementos que estruturam todas as etapas do processo de software.
A UML não descreve como devemos capturar o conteúdo de um caso de uso, apenas indica como um
diagrama de casos de uso é e funciona. Praticamente todo o valor do caso de uso reside no conteúdo e o
diagrama é de valor bastante limitado.
Um caso de uso trata basicamente das seguintes dimensões:
Sistema
Eventos
Dados
Funções
Figura 16 - Dimensões do Caso de Uso
Um caso de uso poderia ser descrito através de uma metodologia conforme mostrado a seguir. A sua
construção deve ser iniciada através da escolha de um cenário e domando este como cenário principal de
sucesso. Este cenário deve ser descrito como uma sequencia de passos enumerados. Os demais cenários são

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
descritos como extensões, que são as variações em relação ao cenário principal. Essas extensões podem ser
bem-sucedidas ou falhas.
Cada caso de uso tem um ator principal, que pede ao sistema para que execute um serviço. O ator
principal é aquele cujo objetivo do caso de uso está tentando satisfazer, normalmente é ele quem inicia a
execução de um caso de uso. Outros atores podem existir, com os quais o sistema se comunica que são
conhecidos como atores secundários.
Cada passo em um caso de uso é um elemento da interação entre um ator e o sistema. Cada passo
deve ser uma declaração simples e deve mostrar claramente que está executando o passo, ele deve mostrar
também a intenção do ator e não os mecanismos do que o ator faz, ou seja, detalhes da interface não devem
ser descritos no caso de uso.
A estrutura do caso de uso é uma excelente maneira de criar alternativas ao cenário principal de
sucesso. Para cada passo, perguntas do tipo: como isso poderia ser feito de uma forma diferente? O que
poderia dar errado? devem ser feitas.
Abaixo é mostrado um estilo comum para escrita do caso de uso:
Compra de Um Produto
Cenário Principal de Sucesso:
1. O cliente navega pelo catalogo e seleciona itens para comprar;
2. O cliente vai para o caixa;
3. O cliente preenche o formulário de remessa (endereço para entrega, opção de entrega imediata ou em três dias);
4. O sistema apresenta a informação completa do faturamento, incluindo a remessa;
5. O cliente preenche a informação do cartão de crédito;
6. O sistema autoriza a compra;
7. O sistema confirma imediatamente a venda;
8. O sistema envia uma confirmação para o cliente por e-mail;
Extensões:
3. Cliente Regular
1. O sistema mostra a informação atual da remessa, a informação de preço e a informação de cobrança;
2. O cliente pode aceitar ou escrever por cima desses padrões, retornando ao CPS, no passo 6;
6. O sistema falha na autorização de compra a crédito

1. O cliente pode inserir novamente a informação do cartão de crédito ou cancelar
Figura 17 - Exemplo de Caso de Uso

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Embora o diagrama de caso de uso seja útil, não é obrigatório. É mais importante que nos
concentremos no conteúdo textual de um caso de uso, do que no diagrama. O diagrama de caso de uso é
basicamente um sumário gráfico do conjunto de casos de uso.
O diagrama de casos de uso em si é muito semelhante ao diagrama de contexto (DFD), pois mostra o
limite do sistema e as interações com o mundo exterior.
O diagrama de casos de uso mostra os atores, os casos de uso e os relacionamento entre eles:
 Quais atores realizam quais casos de uso;
 Quais casos de uso incluem outros casos de uso;
Caixa Eletrônico
Consultar Saldo Abastecer Dinheiro
Solicitar Extrato Recolher Envelopes

de Depósitos
Cliente Realizar Saque Funcionário
Realizar Depósito
Figura 18 - Exemplo de Diagrama de Caso de Uso
Notação básica:
Objeto Nome Descrição
Ator Elemento externo do sistema que sempre inicia o uso ou
recebe um valor do caso de uso.
Cliente

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Caso de Uso Serviço que o sistema fornece aos usuários

Consultar Saldo
__________ Interação/Associação Estímulos recebidos pelo sistema.

Sistema Contexto onde o caso de uso é utilizado (corresponde a
Caixa Eletrônico
uma classe ou conjunto de classes).
Os tipos de interação existentes são os mesmos encontrados em um modelo UML, basicamente

genralização, especialização (sub-tipos de caso de uso) e herança.
Efetua Pagamento Super tipo
Cliente
Cartão Débito em Conta
Sub tipos
Figura 19 - Tipos de Interação no Caso de Uso
Existem também diferentes tipos de associação: de Comunicação, de Extensão, de Inclusão e Herança.

Comumente usamos a extensão e a inclusão, que respectivamente significam, quando um caso de uso
associado a outro pode ser executado sem que o outro seja (extensão) e no caso da inclusão quando para
executar um caso de uso, deve-se executar o outro associado.
Figura 20 - Exemplo de Associação

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Os diagramas de caso de uso e os DFDs são bem similares. Os DFDs geralmente são mais complexos em
virtude da maior quantidade de itens (Entidades Externas, Depósitos de Dados e Fluxo de Dados). Os casos de
uso não descrevem os fluxos de dados.
Figura 21 - Transformação de um DFD para Diagrama de Caso de Uso
Escrever casos de uso implica em: Identificar atores, identificar objetivos, objetivos se tornam casos de
uso. Escrever cenários implica em: identificar fluxo normal, identificar fluxos alternativos, identificar fluxos de
erro.
Abaixo algumas dicas sobre como encontrar os atores dos casos de uso:
 Quem usa o sistema?
 Quem instala/mantém o sistema?
 Quem inicia/desliga o sistema?
 Que outros sistemas usam o sistema?


Quem recebe informação do sistema?
Quem provê informação ao sistema?
No exemplo a seguir podemos observar generalizações entre atores e casos de uso, bem como
associação entre casos de uso de extensão.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Figura 22 - Exemplo de Diagrama de Caso de Uso
Exercício
Construa um diagrama de caso de uso para um sistema de controle de bibliotecas para universidades, onde um
bibliotecário precisa realizar as seguintes operações:
 Cadastrar novos livros;
 Dar baixa em livros inutilizáveis;
 Registrar livros que são levados pelos alunos e professores, podendo ser no máximo 3 livros por vez;
 Registrar a devolução dos livros levados;
 Solicitar ao depto. de compras novos títulos a comprar;
 Possibilitar a consulta a base cadastral do sistema de RH para verificar se o professor está ativo para levar
materiais da biblioteca;
 Um bibliotecário, também poderá ser um aluno;
 Um bibliotecário para fazer uso do sistema deverá realizar login, através de sua identificação (usuário e senha);

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Diagrama de Classes
O Diagrama de classes é o principal diagrama implementado pela UML. Um diagrama de classes típico
descreve os tipos de objetos presentes no sistema e os vários tipos de relacionamentos estáticos existentes
entre eles. Os diagramas de classes também mostram as propriedades e as operações de uma classe e as
aplicam à maneira como os objetos estão conectados. A UML utiliza a palavra característica como um termo
geral que cobre as propriedades e operações de uma classe.
Em um diagrama de classes podem ser encontrados diversos tipos de ligação entre os objetos, diversos
tipos de objetos, ele não é apenas amplamente utilizado, mas também está sujeito à maior variação de
conceitos de modelagem.
A seguir é mostrado um exemplo simples de diagrama de classes.
Pedido
-datadeRecebimento Cliente
Associação
-éPré-pago
-nome Classe
-número
-endereço
-preço * 1
Multiplicidade +obterClassedeCrédito()
+expedir()
+encerrar()
{sePedido.cliente.obterClassedeCredito
1 Restrição é "ruim", então
Pedido.éPré-pago deve ser "Verdadeiro"} Generalização
* -itensdeLinha
Linha de Pedido Nome do papel

Cliente Corporativo
-quantidade
-preço Atributos -nomedeContato Cliente Pessoal
-classedeCrédito
-limitedeCrédito -NúmerodoCartãodeCrédito
Operações
+faturaMensal()
* +aviso()
Navegável
1 *
0..1 -rep. de vendas {obterClassedeCredito() == "ruim"}
Produto
Funcionário
Figura 23 - Exemplo de Diagrama de Classe
Vejamos a seguir de forma mais detalhada os elementos de uma classe:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Classes
Uma classe representa um grupo de objetos semelhantes. Esses objetos são descritos através de
propriedades/atributos e operações. Os atributos correspondem às informações que um objeto armazena, já
as operações correspondem às ações que um objeto sabe realizar.
A classe é representada através de uma caixa, as quais estão divididas em três compartimentos: o
nome da classe (em negrito), seus atributos e suas operações. Neste modelo também é exibido dois tipos de
relacionamento entre as classes: associação e generalização.
Nomeclatura:
 Nome de classes e relacionamentos:
o Cliente, ItemPedido, ContaBancaria
 Nome de Atributos e Operações:
o Nome, DataNascimento, ObterTotal
 Nome de Operações: Utilizar verbos (acreditar, debitar, sacar, etc).
Propriedades
Representam as características estruturais de uma classe. De uma forma mais genérica podemos
considerar as propriedades como sendo os campos de uma classe. As propriedades são um conceito simples,
mas elas aparecem em duas notações bastante distintas: atributos e associações, que, embora pareçam
bastante diferentes em um diagrama, na realidade são a mesma coisa.
Atributos
Descreve uma propriedade como uma linha de texto dentro da caixa de classe em si. A forma completa
de um atributo é: visibilidade nome: tipo multiplicidade = valor-por-omissão { lista
de propriedades }
Exemplo:
- nome : String[1] = “Sem Título” { readonly }
Somente o nome é necessário.
 O marcador de visibilidade indica se o atributo é público (+) ou privado (-);
 O nome do atributo – como a classe se refere ao atributo;
 O tipo do atributo indica uma restrição sobre o tipo de objeto que pode ser colocado no atributo;
 A multiplicidade indica quantos objetos podem preencher a propriedade. As multiplicidades mais comuns
são: 1 (Um pedido deve ter exatamente um cliente), 0..1 (Um cliente corporativo pode ter ou não um único

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
representante de vendas) e * (Um cliente não precisa fazer um Pedido e não existe nenhum limite superior
para o número de Pedidos que um Cliente pode fazer – zero ou mais pedidos).
Cliente Pedido
1 0..*
Figura 24 - Exemplo de Multiplicidade
Neste exemplo observa-se que pode haver um cliente que esteja associado a vários pedidos. Pode
haver também um cliente que não esteja associado a pedido algum. E também um pedido está
associado a um e somente um cliente.
Associações
Uma outra maneira de anotar uma propriedade é como uma associação. Praticamente as mesmas
informações que pode-se exibir em um atributo aparecem em uma associação.
Uma associação é representada por uma linha cheia entre duas classes, direcionada da classe de
origem para a classe de destino. O nome da propriedade fica no destino final da associação junto com sua
multiplicidade. O destino final da associação vincula à classe que é o tipo da propriedade.
Quando usar atributo e quando usar associação? A tendência natural é que para tipos de dados
básicos, como datas, tipos booleanos, normalmente tipos de valor, seja utilizada a propriedade. Já as
associações para situações mais significativas, como clientes e pedidos.
As associações mostradas até aqui são as unidirecionais. Um outro tipo comum de associação é a
bidirecional, que consiste em um par de propriedades inversamente vinculadas. A classe Carro tem a
propriedade proprietário:Pessoa[1] e a classe Pessoa tem uma propriedade carros:Carro[*],
conforme mostrado no exemplo a seguir:
-proprietario
Pessoa Carro
0..1 *
Figura 25 - Exemplo de Associação Binária
Uma outra forma de representar esta situação é rotular uma associação utilizando um verbo para que
o relacionamento possa ser utilizado em uma frase. Isso é válido e pode-se adicionar uma seta na associação
para evitar ambiguidade, conforme exemplo abaixo:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Papel Nome da Dieração de Papel

associação leitura
contratante Contrata contratado
Organização Indivíduo
* *
Figura 26 - Exemplo de Associação com Papeis
Observa-se também aqui o uso de papéis, que são utilizados para representar um papel especifico em
uma associação (rótulos na ponta da associação).
Observando-se o exemplo abaixo percebe-se uma situação onde Pessoa pode ser empregado de
diversas empresas e uma empresa pode possuir diversos empregados:
Pessoa
-empregado -empregador Empresa
-nome
-razãoSocial
-telefone
-endereço
-endereço * *
Figura 27 - Exemplo de Associacão muitos-para-muitos
Como forma de solucionar esta situação podemos criar uma terceira classe chamada classe associativa.
Esta classe está ligada a uma associação, ao invés de estar ligada a outras classes. Faz-se necessário quando
duas ou ais lasses estão ligadas e e essá io a te os dados so e esta ligação :
Empregador
-Salário
-dataContratação
Pessoa
* * Empresa
-nome
-razãoSocial
-telefone
-endereço
-endereço -empregado -empregador
Figura 28 - Exemplo de Classe Associativa
Para associar objetos de mesma classe utiliza-se u tipo de asso iação ha ada efle iva , o de ada
objeto tem um papel distinto na associação. Uma associação reflexiva não indica que um objeto se associa
com ele próprio, ao contrario indica que objetos de uma mesma classe se associam:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Supervisão
1 -supervisor
Empregado
* -supervisionado
Figura 29 - Exemplo de Associação Reflexiva
Operações
São as ações que uma classe sabe realizar. As operações correspondem claramente aos métodos
presentes em uma classe. Normalmente as operações que manipulam propriedades não são exibidas no
modelo pois são na maioria das vezes inferidas automaticamente.
A sintaxe completa da UML para uma operação é:
Visibilidade nome (lista-de-parâmetros) : tipo-de-retorno { lista-de-propriedades }
Onde:
 O marcador visibilidade é público (+) ou privado (-);
 O nome é uma sequencia de caracteres para indicar a operação/método;
 A lista-de-parâmetros é a lista de parâmetros de entrada da operação;
 O tipo-de-retorno é o tipo do valor retornado, se houver um;
 A lista-de-propriedades indica os valores de propriedade que se aplicam à operação dada.
Generalização
Um exemplo prático de generalização é o que envolve clientes e pessoas físicas e jurídicas de uma
empresa. Neste exemplo as pessoas têm diferenças, porém tem também muitas semelhanças. As
semelhanças podem ser colocadas em uma classe geral Cliente (ou supertipo), com Cliente Pessoa Física e
Cliente Pessoa Jurídica como subtipos.
Esse fenômeno também está sujeito a várias interpretações em diferentes perspectivas de modelagem.
Conceitualmente podemos dizer que Cliente Pessoa Jurídica é um subtipo de Cliente, se todas as instâncias de
Cliente Pessoa Jurídica também o são, por definição instâncias de Cliente. A ideia principal é a de que tudo que
dissermos sobre um Cliente – associações, atributos, operações – também é verdadeiro para um Cliente
Pessoa Jurídica.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Em uma perspectiva de software, a interpretação óbvia é a herança: o Cliente Pessoa Jurídica é uma
subclasse de Cliente. Nas principais linguagens orientadas a objetos, a subclasse herda todos os recursos da
superclasse e pode sobrepor todos os métodos da superclasse.
Dependência
Uma dependência entre dois elementos existe se mudanças na definição de um elemento (o
fornecedor) podem causar mudanças ao outro (o cliente). Nas classes, as dependências existem por várias
razões: uma classe envia uma mensagem para outra; uma classe tem outra como parte de seus dados; uma
classe menciona uma outra como parâmetro de uma operação. Se uma classe muda a sua interface, qualquer
mensagem enviada para essa classe pode não ser mais válida.
A UML permite representar dependências entre todos os tipos de elementos. Dependências são
utilizadas quando se quer mostrar como as mudanças em um elemento podem alterar outros elementos.
O exemplo a seguir mostra algumas dependências que poderiam ser encontradas em um aplicativo de
múltiplas camadas. A classe Plano de Benefícios é dependente da classe Funcionários.
Cliente Entrada de Dados

Fornecedor
de Funcionários
Plano de Benefícios Funcionário
Entrada de Dados
Dependência de Benefícios
Figura 30 - Exemplo de Dependência
Neste exemplo percebe-se claramente uma ideia de separação entre a apresentação e a lógica do
domínio da aplicação, isto é uma regra valiosa a ser seguida. Percebe-se que não existe nenhuma dependência
direta da classe Plano de Benefícios para as duas classes de Entrada de Dados. Se essas classes mudarem,
talvez a classe Funcionários tenha que mudar, porém se a mudança for apenas na implementação da classe
Funcionário e não em sua interface, não há o que mudar nas classes de entrada de dados.
O problema com os diagramas de classes é que eles são tão ricos que pode ser complexos de mais para
usar. Algumas dicas úteis na hora escrever um:
 Não tente utilizar todas as notações de que você dispõe. Comece com o material simples: classes,
associações, atributos, generalização e restrições;
 Diagramas de classes conceituais são muito úteis na exploração da linguagem de negócio;

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
 Não desenhar modelos para tudo; em vez disso, concentre-se nas áreas principais. É melhor ter poucos
modelos porém atualizados do que um monte de modelos esquecidos e obsoletos.
Exercício
Desenhe um diagrama de classes que atenda as seguintes requisitos:
Escopo: Controle de Contas Correntes Bancárias;
Definição: O banco x possui um serviço prestado aos seus clientes de conta corrente bancária, que
consiste basicamente na abertura de contas correntes, que poderá ser conta corrente normal, conta
universitária e conta corrente empresarial. A diferença básica entre elas é que a conta corrente normal não
possui limite de crédito e o valor das taxas é normal, já a conta universitária também não possui limite de
crédito, porém a taxa de manutenção possui um desconto de 50% em relação à normal. A conta corrente
empresarial disponibiliza ao cliente um limite de 10.000,00 e a taxa é igual à taxa normal mais 20% de
acréscimo.
Para abrir uma conta corrente no banco x é necessário que o cliente leve seus dados pessoais que são:
Nome, Endereço, CPF/CNPJ e Telefone de Contato. Caso ele seja estudante deverá informar também a
universidade na qual está ligado bem como o período e qual curso está cursando.
As operações disponibilizadas para todos os clientes, independentemente do tipo de conta corrente
são: Depositar (Depositar na conta um valor qualquer), Sacar (Sacar da conta um valor qualquer), Consultar
Saldo (consultar em tela ou impresso o saldo da conta corrente), Consultar Extrato (Consultar extrato com as
movimentações realizadas na conta corrente) e Transferir (Transferir um valor qualquer de uma conta
corrente para outra conta corrente).
Leitura complementar: Conceitos e Princípios da Orientação a Objeto

a) Objeto: É qualquer coisa, real o abstrata, sobre a qual se armazenam dados e operações que manipulam os
dados. Pode ser composto de outros objetos. É uma entidade independente, assíncrona e concorrente que
sa e oisas a aze a dados , ealiza t a alho e apsula se viços e ola o a o out os o jetos
(por meio de troca de mensagens) para executar as funções finais do sistema modelado;
b) Operações: São usadas para ler ou manipular os dados de um objeto. As operações em um tipo de objeto se
referem apenas às estruturas de dados daquele tipo de objeto;
c) Métodos: Especificam a maneira como as operações são codificadas no software;
d) Solicitações: Uma solicitação pede que uma operação especificada seja ativada, usando um ou mais objetos
como parâmetro;

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
e) Classe: É uma implementação de um tipo de objeto. Tem uma estrutura de dados e métodos que
especificam as operações que podem ser feitas com aquela estrutura de dados. Como exemplo, os animais
são classificados ou distribuídos em diversas classes.
O Objeto em que estamos sentados é um membro ou instância: cadeira. A cadeira pertence a uma classe
muito maior de objetos: mobiliário. Um conjunto de atributos genéricos pode ser associado a cada objeto
da classe mobiliário: custo, dimensões, peso, localização, cor, etc. A cadeira herda todos os atributos
definidos para a classe, sendo a cadeira membro tal como a mesa, o sofá e o armário.
Exemplo:
Classe: mobiliário
(custo, dimensões, peso,
localização, cor, etc);
objeto: cadeira
(custo, dimensões, peso,
localização, cor, etc.)
Quando a classe é definida, os atributos podem ser reusados quando novas instâncias ou membros de
classe são criados. Um atributo pode ser composto. Por exemplo: localização = prédio + andar + sala.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Introdução ao Modelo ER
Após a pu li ação de u t a alho i titulado The E tit -Relationship Model: Toward the unified view
of data , e po tugu s O Modelo E tidade-Relacionamento: U a te tativa de visão u ifi ada de dados , em
1976, Peter Chen passou a definir uma possível abordagem para o processo de modelagem dos dados. Após
publicado este trabalho passou a ter não só ampla aceitação como é considerado um referencial até os dias
atuais para o processo de modelagem de dados.
A abordagem entidade-relacionamento (E-R), abordada por Peter Chen, defende basicamente, a
elaboração de um modelo que represente os objetos observados e seus relacionamentos,
independentemente da preocupação tecnológica da coisa, como implementações lógica e física. Ele entende
que os aspectos lógicos e físicos devem ser agregados depois, pois são alheios à estrutura inerente dos dados
observados em um ambiente ou conjunto de objetos.
Essa forma de pensar na modelagem de sistemas de informação está em total acordo com o padrão
estabelecido pelo grupo ANSI-X3-SPARK. Através da sua aplicação levará durante o ciclo de desenvolvimento a
convivência com três tipos distintos de modelos de dados: o modelo conceitual de dados (MCD), o modelo
lógico de dados (MLD) e o modelo físico de dados (MFD).
A abordagem E-R, é composta de uma técnica de diagramação e de um conjunto de conceitos que
devem ser entendidos e respeitados. A técnica é bastante simples e serve como meio de representação dos
próprios conceitos por ela manipulados.
Esta técnica utiliza basicamente um retângulo para representar as entidades, um losango para
representar os relacionamentos e balões para indicar e alocar os atributos, conforme mostrado a seguir:
Entidade 1 Relacionamento Entidade 2
Atributo 1
Atributo 2
Figura 31- Abordagem Entidade-Relacionamento
Em resumo o modelo E-R é muito simplificado e por isto mesmo sua grande aceitação até hoje. Ele
baseia-se e u a p e issa atizada de Lei do Mu do :

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
A Lei do Mundo: O mundo está cheio de coisas que possuem características próprias e que se
relacionam entre si.
Baseando-se nesta premissa extremamente simples, mas ao mesmo tempo muito completa, Chen
p o u ou ão usa o te o oisas , o ual to a ia sua p oposta uito i fo al, ao i v s disto ele su stituiu
po E tidades , ue ost a da es a fo a os o jetos ou ele e tos o se vados.
Uma integração entre a abordagem de modelos conceitual, lógico e físico e a proposta do grupo ANSI-
X3-SPARK é possível se forem estabelecidos os seguintes níveis de projeto, conforme imagem a seguir:
Schema
Conceitual
Objetos de Modelo Relacioname

Entidade 1 Entidade 2
Interesse Conceitual nto
Schema Tab X Tab Y

Externo
Id Id
Modelo Lógico Nome Preço
Schema
Interno
Modelo Físico
Figura 32 - Níveis de Projeto de Banco de Dados
A cada um desses níveis de modelagem serão associadas técnicas de representação gráfica e métodos
de especificação de schemas. Para cada novo nível de especialização serão necessários conhecimentos
específicos para o entendimento e manipulação dos elementos envolvidos.
O Modelo Conceitual
Define-se como modelo conceitual aquele em que os objetos, suas características e relacionamentos
têm a representação fiel do ambiente observado, independentemente de limitações quaisquer impostas por
tecnologias, técnicas de implementação ou dispositivos físicos. Nele precisamos representar os conceitos e
características observados em um dado ambiente, voltando-se simplesmente ao aspecto conceitual.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
A importância do modelo conceitual está justamente em não se preocupar com aspectos técnicos de
desenvolvimento, sendo assim ele torna-se imutável tanto se vier a ser implementado em um SGBD relacional,
como em um SGBD hierárquico. Um outro fator importante para o uso da modelagem conceitual é a
construção de DataWarehouse ou DataMarts. Como eles são construídos através da integração de diversas
bases de dados separadas, faz-se importante que consigamos visualizar o conceitual de cada uma delas antes
de começar a construir um processo de ETL. Além disso o esforço necessário para a construção de um modelo
conceitual é igual ou muitas vezes, menor que o realizado para gerar o modelo lógico de dados.
Ele normalmente é implementado por ferramentas case e jamais virá nas fases de projeto de
construção de sistemas e sim nas fases de análise. Quanto ao uso de ferramentas case, para este tipo de
necessidade são conhecidas como UPPPER-CASE, pelo fato de atuarem em etapas que antecedem o próprio
ciclo de desenvolvimento.
Devemos sempre estar atentos para não construir modelos já como modelos lógicos de dados. Isto é
possível e em muitos casos induzido por algumas ferramentas CASE, mas devemos mesmo que num primeiro
instante nos limitar a construção de modelos conceituais.
Para a construção de um modelo conceitual, p e isa os defi i uais são as oisas ou entidades,
como elas se relacionam e quais são as suas características ou atributos.
Entidades
O conceito fundamental da abordagem E-R é o conceito de entidade, que dentre outras coisas poderia
se : Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de
dados . Em outras palavras uma entidade representa um conjunto de objetos da realidade modelada.
Como o objetivo de um modelo E-R é modelar de forma abstrata um BD interessam-nos somente os
objetos sobre os quais deseja-se manter informações. Por exemplo, em um sistema de contas correntes,
algumas entidades podem ser os clientes, as contas correntes, os cheques e as agências.
Deve-se observar que uma entidade pode representar tanto objetos concretos da realidade (uma
pessoa, um automóvel), quanto objetos abstratos (um departamento, um endereço). Em um DER (Diagrama
Entidade-Relacionamento), uma entidade é representada por um retângulo que contém o nome da entidade.
Pessoa Departamento
Figura 33 - Exemplos de Entidades de um DER

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
No exemplo anterior, o retângulo pessoa identifica a entidade pessoa, a qual designa o conjunto de
todas as pessoas sobre as quais se deseja manter informações no banco de dados, enquanto o retângulo
Depa ta e to , desig a o o ju to de todos os depa ta e tos so e os uais se deseja a te
informações. Também podemos no modelo referenciar um objeto particular (como uma pessoa determinada),
sendo assim estamos definindo uma ocorrência ou instância de entidade.
O exemplo trata apenas de quais são os conjuntos de objetos sobre os quais deseja-se manter
informações, mas não trata de quais são essas informações. As informações aqui são mantidas pela definição
das propriedades de cada entidade, dadas pelos relacionamentos, atributos e generalizações/especializações.
Identificação de Objetos (Entidades ou Classes)
Existem diversas estratégias para a obtenção das entidades ou classes de um ambiente qualquer.
Shlaer & Mellor, definem que poderá ser possível o reconhecimento de objetos através de uma classeificação
em cinco grandes grupos:
 As coisas tangíveis;
 As funções exercidas por elementos;
 Eventos ou ocorrências;
 Interações;
 Especificações;
Coisas Tangíveis: Como o próprio nome sugere trata-se de tudo aquilo que ser tocado. Assim, o grupo
de oisas ta gíveis e glo a todos os ele e tos ue te ha e ist ia o eta, ue seja a ipuláveis,
que possam ser tocados, etc.
Por exemplo: Um avião a jato, um cavalo puro-sangue, um livro de ficção, uma garrafa térmica, uma
chave de porta de entrada, um lápis preto, sua borracha usada, os computadores da rede, um quadro-negro,
sua máquina de escrever, o cachorro do vizinho, a mesa de trabalho, o seu carro, sua agenda de
compromissos, os elefantes do circo, uma mesa de cozinha, um telefone fixo, sua mala, etc.
O agrupamento desses objetos (entidades ou classes) em conjuntos dependerá do ponto de vista de
cada um, dependendo basicamente do nível de abstração adotado, maior ou menor.
Com um nível de abstração maior, ou seja, desconsiderando maiores detalhes, podemos definir os
seguintes conjuntos:
Conjunto (entidade / classe) Objetos que Pertencem
Meio de Transporte O avião, o seu carro
Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Animal O cavalo, os elefantes, o cachorro

Utensílio Doméstico A garrafa, a mesa, o telefone
Utensílio Escolar O livro, o lápis, a borracha, o quadro-negro
Equipamento Os computadores, a máquina de escrever
Pertence Pessoal A chave, a agenda, a mala.
Em um nível de abstração mais generalista, poderíamos ter a seguinte classificação:

Conjunto (entidade / classe) Objetos que Pertencem
Utensílios A garrava, a mesa, o telefone, o livro, o lápis, a
borracha, o quadro, a chave, a mala, a agenda.
Animais O cavalo, os elefantes, o cachorro.
Produtos O avião, o automóvel, os computadores a máquina de
escrever.
Esta verificação de diferentes níveis de abstração nos leva a refletir que mesmo dentro do grupo de
COISAS TANGÍVEIS, que será aquele que teremos maior facilidade em especificar, existem diferentes níveis de
abstração. O nível de abstração é o que nos guiará a diferentes níveis de agregação dos objetos, deverá ser
definido em função da abrangência definida na especificação de requisitos, nas fases iniciais de especificação
do sistema.
Funções: Pelas funções definiremos todo tipo de papel, atribuição, classificação, capacitação, ou outra
característica qualquer que, para um dado elemento especifique não sua existência, mas sua atuação no
ambiente em que está inserido.
Exemplo: O médico cirurgião, um engenheiro naval, um departamento de compras, seu professor de

inglês, o autor de um livro, a gerência de suporte técnico, a recepcionista do hotel, um médico pediatra, a
seção de despachos de material, o gerente do hotel, um paciente que é atendido, os alunos de uma escola,
etc.
Também neste caso a abstração nos dirá o nível de classificação a ser utilizada, por exemplo em um
alto nível de abstração poderíamos ter:
Conjunto (entidade / classe) Objetos que Pertencem Coisas Tangíveis mapeadas
como FUNÇÃO
Especialista O médico cirurgião, o médico Pessoa
pediatra, o engenheiro naval, o autor
de um livro
Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Organização Um departamento de compras, a Órgão Funcional

gerência de suporte técnico, a seção
de despachos de mercadorias
Atendente O professor de inglês, o gerente do Pessoa
hotel, a recepcionista do hotel
Cliente Os alunos, o paciente. Pessoa
Eventos ou Ocorrências: Alguns objetos somente podem ser percebidos quando uma ação se
desenrola, ou seja, quando alguma ação ou fato ocorre conseguimos definir características que os tornam
materializáveis.
Exemplos: Um voo comercial, um acidente de trânsito, uma apresentação técnica de um fornecedor,

uma festa beneficente, uma gincana esportiva, um jogo de futebol, etc.
Cada evento do exemplo possui poucos dados próprios. A maioria dos dados a eles pertencentes são
na verdade dados de outros objetos participantes do próprio evento. No caso de uma apresentação técnica de
um fornecedor teríamos como dados da própria apresentação: Data de Realização, Horário de início
programado, Horário de inicio efetivo, Duração prevista, Duração efetiva e Tema.
É importante que identifiquemos que outros dados poderão ser definidos como relevantes e agregados
ao modelo.
Dados Relevantes Conjunto ao Qual Pertence
Nome do Apresentador Pessoa
Especialidade do Apresentador Pessoa
Telefone para confirmação da presença Fornecedor
Endereço da apresentação Hotel
Nome do produto apresentado Produto
Finalidade do produto apresentado Produto
Mesmo que em nível conceitual deveremos sempre buscar pela definição de conjuntos
(entidades/classes) adequados.
Interações: São resultantes da associação de objetos em função de um processo executado. Os

chamados objetos-interação passam a existir de maneira individualizada, além dos objetos que participam

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
dessa interação. Se conveniente podem ser substituídos por associações (relacionamentos) entre objetos, por
coisas tangíveis ou por eventos.
Exemplos: A compra de um imóvel, uma adoção de uma criança por um casal, uma venda realizada por
um fornecedor, etc.
Em todos os exemplos existem interações entre os objetos, sendo materializadas como novos objetos.
Podemos também substituí-las por outras representações:
Objeto-Interação Objetos que participam Substituição Possível
A compra de um imóvel Comprador, Imóvel, Proprietário, - ela io a e to o p ado
Corretor, Agente Financeiro po
- eve to a uisição
- oisa ta gível o t ato de
o pa
Uma adoção de uma criança Família Cedente, Família Receptora, - ela io a e to adotada
Criança, Órgão Regulamentador po
- eve to adoção
- oisa ta gível egist o de
adoção
Uma venda realizada por um Fornecedor, Produto, Cliente - ela io a e to ve dido
fornecedor po
- eve to ve da
- oisa ta gível ota de ve da
Especificações: Nesse conjunto aparecem os elementos que definem características de outros objetos.
Eles, isoladamente não representam objetos mas sim especificações que quando aplicadas ou seguidas darão
origem a objetos. Como o modelo conceitual não necessita normalização alguma, este tipo de elemento pode
ser suprimido neste modelo, aparecendo necessariamente no modelo lógico.
Relacionamentos
Uma das propriedades sobre as quais pode ser desejável manter informações é a associação entre
objetos. Exemplificando, pode ser desejável saber quais pessoas estão associadas a quais departamentos em
uma organização. Para a associação entre objetos damos o nome de relacionamento. Podemos de forma
simplificada conceituar um relacionamento como sendo um conjunto de associações entre ocorrências de
entidades.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Em um DER um relacionamento é representado através de um losango, ligado por linhas aos

retângulos representativos das entidades que participam do relacionamento. A seguir é exibido um exemplo
de um DER contendo as entidades Pessoa e Departamento, um relacionamento Lotação:
Pessoa Lotação Departamento
Figura 34 - Exemplo de relacionamento em um DER
Este modelo exemplo expressa que o Banco de Dados contém informações sobre:
 Um conjunto de objetos classificados como pessoas (entidade Pessoa);
 Um conjunto de objetos classificados como departamentos (entidade Departamento);
 Um conjunto de associações, cada uma ligando um departamento a uma pessoa (relacionamento Lotação);
Uma associação em particular é chamada de instância ou ocorrência. No caso do exemplo anterior uma
ocorrência seria obtida por um par específico formado por uma determinada pessoa e um determinado
departamento.
Podemos representar estas ocorrências ou instâncias através do diagrama de ocorrência (apenas para
fins didáticos), conforme exemplo a seguir:
P2 P6
P1 P5
P3 P4 P7 P8
P1.. P4..
D1 D2
P2.. P7..
D1 D3
D1 D2 D3
Figura 35- Diagrama de Ocorrência
Um relacionamento poderá ocorrer entre a mesma entidade, estabelecendo assim o que chamamos de
auto-relacionamento. No exemplo a seguir, observamos que uma ocorrência de pessoa exerce o papel marido
e outra exerce o papel de esposa. Neste exemplo verificamos também os papéis e a forma como eles são

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
anotados. No caso de relacionamentos com entidades diferentes não há a necessidade de mostrar os papéis
pois eles são óbvios.
Pessoa
Marido Esposa
Casamento
Figura 36 - Exemplo de Auto-Relacionamento
Cardinalidade de Relacionamentos
É importante para o estabelecimento de um relacionamento que saibamos quantas ocorrências de
determinada entidade podem estar associadas a uma determinada ocorrência através do relacionamento.
Este é o trabalho da cardinalidade. É importante que saibamos a cardinalidade máxima e a cardinalidade
mínima.
Em outras palavras a cardinalidade é o número (máximo, mínimo) de ocorrências de uma entidade
associadas a uma ocorrência da entidade em questão através do relacionamento.
Cardinalidade Máxima
Considere o DER (incompleto) a seguir:
2 1
Piloto Temporada Equipe
Figura 37 - Exemplo p/ Estudo da Cardinalidade
Para o exemplo mostrado na figura anterior podemos dizer que:

 Entidade Piloto tem cardinalidade máxima um no relacionamento Temporada;
Isto significa que uma ocorrência de piloto pode estar associada a no máximo uma ocorrência de
equipe, ou seja, um piloto poderá estar em uma temporada em apenas uma equipe.
 Entidade Equipe tem cardinalidade máxima dois para o relacionamento Temporada;
Isto significa que uma ocorrência de equipe pode estar associada à no máximo duas ocorrências de piloto,
ou seja, uma equipe poderá ter no máximo dois pilotos por temporada.
A cardinalidade máxima pode ser utilizada para classificar relacionamentos binários. Um

relacionamento binário é aquele cujas ocorrências contém duas ocorrências de entidade. Podemos classificar

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
os relacionamentos binários em n:n, 1:n e 1:1. No caso do exemplo do casamento, podemos dizer que uma
pessoa pode ter no máximo um marido e que uma pessoa também pode ter no máximo uma esposa.
Exercício: Elaborar exemplos de DER contendo no mínimo duas entidades relacionadas e cuja os
relacionamentos possuam as cardinalidades máximas n:n, 1:n e 1:1.
A abordagem ER permite que sejam definidos relacionamentos de grau maior do que dois
(relacionamentos ternários, quaternários, ...). A seguir é exibido um exemplo de um relacionamento ternário:
Cidade Distribuidor
n 1
Distribuição
Produto
Figura 38 - Exemplo de Relacionamento Ternário
No exemplo anterior temos que:

 Um distribuidor distribui em uma cidade N produtos;
 Um distribuidor distribuir um produto em N cidades;
Cardinalidade Mínima
Trata-se do número mínimo de ocorrências de uma entidade associadas a uma ocorrência de uma
outra entidade através de um relacionamento. Para fins de projeto consideram-se apenas duas cardinalidades
í i as: a a di alidade í i a ta o he ida o o associação opcional e a cardinalidade mínima
ta o he ida o o asso iação o rigatória ).
(0,1) (1,1)
Empregado Alocação Mesa
Figura 39 - Exemplo de Cardinalidade Mínima
Neste exemplo está especificado que cada empregado deve ter a ele alocada obrigatoriamente uma
mesa e que uma mesa pode existir sem que a ela esteja alocada um empregado.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Exemplo do Uso de Cardinalidades nas Associações

Uma universidade pretende criar um sistema para controlar basicamente os cursos, as disciplinas dos
cursos, cuja um departamento responsável deve ser nomeado e os alunos que estarão cursando as disciplinas.
Algumas regras devem ser seguidas:
 Um aluno poderá estar inscrito em um e somente um curso;
 Um curso, poderá possuir nenhum ou muitos alunos inscritos;
 Um curso, poderá ter nenhuma ou muitas disciplinas relacionadas em sua grade;
 Uma disciplina poderá estar relacionada a nenhum ou muitos cursos;
 Uma disciplina deverá possuir um responsável;
 Um departamento é responsável por nenhuma ou muitas disciplinas;
 Uma disciplina poderá possuir nenhum ou muitas outras como pré-requisito, para liberação da sua
execução;
Atributos
Um DER permite que sejam especificados em suas entidades os atributos ou propriedades de cada uma
delas. Uma propriedade pode surgir de um relacionamento ou ser um atributo de uma entidade. Em síntese
um atributo é um dado que é associado a cada ocorrência de uma entidade ou de um relacionamento.
Os atributos são representados graficamente conforme mostra o exemplo a seguir:
Projeto
tipo
código
nome
Figura 40 - Exemplo de Representação Gráfica de Atribtutos
Na prática muitas vezes os atributos não são representados nos diagramas de modelo conceitual para
não sobrecarregá-los. Podemos utilizar uma representação textual denominada dicionário de dados. A
representação gráfica dos atributos também pode mudar dependendo da notação utilizada, principalmente
quando se utiliza uma ferramenta case, como o PowerArchitect.
O conjunto de valores que um determinado atributo pode assumir é chamado de domínio do atributo.
Esse conjunto de valores é responsável por determinar características do atributo como tamanho em
caracteres, tipo de valores (número, data, ...), enumeração de valores válidos, etc.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Um atributo também pode assumir uma cardinalidade, assim como uma entidade em um
relacionamento. A cardinalidade neste caso serve para definir quantos valores deste atributo pode estar
associados a uma ocorrência da entidade/relacionamento a qual ele pertence. No exemplo abaixo é exibido a
situação onde o atributo telefone poderá possuir nenhum (opcional) ou vários valores e sendo assim chamado
de multivalorado.
Cliente
Telefone (0,n)
código
nome
Figura 41 - Cardinalidade de Atributos
Cardinalidades (1,1) podem ser omitidas. Ainda no exemplo ele expressa que nome e código são
atributos obrigatórios (cardinalidade mínima 1 – cada ocorrência da entidade deverá conter no mínimo um
valor informado) e monovalorados (cardinalidade máxima 1 – poderá existir apenas uma ocorrência do valor
para a entidade).
Assim como em entidades, uma associação também poderá possuir atributos. Conforme mostrado no
exemplo a seguir, nenhum ou vários engenheiros podem ter atuação em nenhum ou vários projetos. Para
cada atuação realizada, ele poderá ter várias funções, portanto Fu ção ão pode á se o side ado at i uto
de engenheiro nem de projeto.
(0,n) (0,n)
Engenheiro Atuação Projeto
Nome código
Código Função Código
Figura 42 - Atributo de Relacionamento tipo n:n
Identificação de Entidades
Cada entidade deve possuir um identificador. Um conjunto de um ou mais atributos e relacionamentos
cujos valores servem para distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade.
Em síntese ele identifica de forma única uma ocorrência em uma entidade ou um relacionamento.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
O caso mais simples é quando uma entidade possui um único atributo como identificador, conforme
mostrado no exemplo a seguir, onde o código é o identificador de pessoa. No DER um atributo que faz parte
da identificação de uma entidade possui na extremidade da linha um círculo fechado.
Pessoa
endereço
Nome
Código
Figura 43 - Identificador Simples da Entidade
Existem também identificadores de entidade compostos, ou seja, existem para uma entidade dois ou
mais atributos que compõe a identificação. No exemplo a seguir podemos constatar que a entidade prateleira
é identificada pelo número do corredor e pelo número da prateleira.
Prateleira
capacidade
Número do corredor
Número da preteleira
Figura 44 - Identificador Composto
Identificação de Relacionamentos
Assim como em entidades há também a identificação de relacionamentos. Podemos ter identificações
de relacionamentos da forma em que poderá existir apenas uma ocorrência do par de ocorrências que estão
envolvidas no relacionamento. No exemplo abaixo, verifica-se que existe para cada par (engenheiro, projeto)
há no máximo um relacionamento de alocação.
n n
Engenheiro Atuação Projeto
Figura 45 - Exemplo de Identificação de relacionamento entre duas entidades
Existem casos também onde para cada relacionamento de entidades podem ocorrer diversas
ocorrências de relacionamento. No exemplo a seguir, observa-se que para cada relacionamento entre médico
e paciente, podem ocorrer diversas ocorrências de consulta.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
n n
Médico Consulta Paciente
data/hora
Figura 46 - Exemplo de relacionamento com identificação própria.
Neste caso se faz necessária a identificação de forma única de cada consulta. O atributo data/hora
neste caso, irá diferenciar uma consulta de outra. De forma geral um relacionamento é identificado pelas
entidades dele participantes, bem como dos atributos identificadores (quando existir necessidade).
Exercícios
1. Em um contexto de empresa de transporte aéreo, imagine as situações necessárias (funções,
procedimentos, papéis, pessoas, controles, etc) necessários para gerenciá-la. A partir disto crie uma
tabela contendo duas colunas sendo que na primeira coluna indique as entidades e na segunda a
descrição clara de cada uma delas, conforme mostrado no primeiro item da lista abaixo como exemplo.
Entidade Descrição
Avião Entidade responsável por armazenar e controlar toda a frota de
aviões da companhia. Entre outras coisas armazena, nome do avião,
número de série, marca, capacidade de assentos, autonomia, ano de
fabricação, revisões periódicas, etc.
O s: Vale le a ue a ideia de i agi a as e essidades se ve ape as o o fo a de

exercício, sendo que jamais um analista poderá imaginar situações para desenvolver.
2. Quais são as entidades necessárias para que seja estabelecido um casamento?

3. Quais são as entidades necessárias para que seja estabelecida a venda de uma casa?
4. Quais são as entidades necessárias para que seja estabelecida a venda de um carro?
5. A partir do exemplo do auto-relacionamento de um casamento, construa um diagrama de ocorrências
possível;
6. Rep ese te o eitual e te at av s de u odelo DER o segui te a ie te: José é proprietário de
uma van preta . Espe ifi ue as entidades e o relacionamento entre elas incluindo a cardinalidade da
associação;
7. Rep ese te o eitual e te at av s de u odelo DER o a ie te: Um carro é de propriedade de
uma pessoa, mas pode ser utilizado por diversas outras para locomoção e uma pessoa utiliza um imóvel
para morar . Espe ifi ue as e tidades e os ela io a e tos e t e elas i lui do a a di alidade das
associações;
8. De acordo com o DER (incompleto) abaixo, descreva todos os relacionamentos incluindo detalhes de
cardinalidade:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
substitui
1.N
1.N 0.N
Empregado Trabalha Empresa
0.1
Exemplo: 1 – Um empregado pode substituir um ou mais empregados.

9. Explique o significado das cardinalidades mínima e máxima para o DER abaixo:
(0,n) (1,n)
Fornecedor Fabricante
(1,1) (1,1)
(0,n) (0,n)
(0,n) (1,n)
Lote Produto
10. Com base no DER apresentado no exercício 9, defina os nomes dos relacionamentos existentes.
11. Considere o DER apresentado no exemplo da figura 36 (exemplo do casamento). Segundo ele responda:
- O banco de dados poderia ter um casamento em que a pessoa estivesse casada consigo mesma?
- É permitido que a mesma pessoa apareça em dois casamentos diferentes?
Em caso afirmativo para a(s) questões acima, reescreva o der para suportar tal situação.
12. Elabore uma proposta de um DER para uma partida de futebol. Imagine as possíveis situações, os
possíveis participantes e crie um DER contendo todas entidades, os relacionamentos e as devidas
cardinalidades. Não é necessário informar os atributos.
13. Dese he u DER pa a ealiza a segui te situação: U a fi a ei a ealiza fi a ia e tos pa a ve das
realizadas. Cada financiamento deverá possuir definido o número de parcelas e a taxa de juros. Lembre-
se de que uma financeira poderá financiar nenhuma ou várias vendas, porém uma venda poderá ser
fi a iada po e hu a ou u a fi a ei a . Des eva as e tidades, o ela io a e to e os at i utos
necessários.
14. Desenhe um DER especificando as entidades, seus atributos (incluindo os identificadores) e seus
ela io a e tos pa a a segui te situação: Um grupo de empresas poderá possuir nenhuma ou várias
empresas. A empresa poderá possuir nenhuma ou muitas filiais. Uma filial deverá possuir uma matriz
obrigatoriamente. Uma empresa deverá ser de um grupo de empresas .
15. Considere que um cliente poderá possuir: Diversos telefones de contato e Diversos endereços. Elabore
um DER contemplando esta situação, identificando as entidades necessárias, os relacionamentos entre
elas e a cardinalidade deles. Caso seja necessário especificar também os atributos identificadores.
16. Explique a diferença entre uma entidade e uma ocorrência de entidade. Exemplificar.
17. Para o DER abaixo, especificar atributos opcionais de acordo com o contexto das entidades e/ou dos
relacionamentos:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Jogador Equipe Time
18. Para o mesmo DER do exercício anterior, especifique a cardinalidade necessária para as seguintes
situações:
- Um jogador poderá fazer parte da equipe de apenas um time por temporada;
- Um time, poderá formar uma equipe com nenhum (no caso de não participar da temporada) ou vários
jogadores. O limite de inscritos por time para a temporada será de 22 jogadores.
19. Ainda com base no DER do exercício 15, especifique quais seriam os atributos identificadores
necessários para as entidades e para o relacionamento.
20. De acordo com o DER apresentado no exercício 9, especificar os atributos opcionais bem como os
atributos identificadores para as entidades e os relacionamentos (quando necessário).

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
O Modelo Lógico
O modelo lógico é uma derivação do modelo conceitual. Para a obtenção deste devem ser aplicadas
algumas regras bem definidas e objetivas no modelo conceitual. Estas regras visam a resolução de algumas
particularidades que tecnicamente falando tornariam o modelo conceitual impossível de ser desenvolvido.
As regras a serem abordadas visarão à geração de um modelo lógico baseado na abordagem relacional.
Como anteriormente exposto o modelo conceitual é independente de tecnologia, enquanto o modelo
lógico será uma adaptação do modelo conceitual porém preocupando-se com a tecnologia a ser empregada
na modelagem, que no caso utilizaremos a tecnologia relacional. Podemos definir que o processo de obtenção
de um modelo lógico a partir de um modelo conceitual segue os seguintes passos:
1. Obter o modelo conceitual;
2. Definir o tipo de implementação (rede-codasyl, relacional, O-O);
3. Aplicar as regras de derivação específicas;
4. Adaptar o modelo às necessidades de negócio.
Desta forma a elaboração de um modelo lógico, como guia para a construção de uma estrutura de
armazenamento de dados da aplicação se torna mais confiável e menos imprevisível.
Os passos de 1 a 3 servem como guia para a elaboração de um modelo lógico que atenda as
necessidades do dia-a-dia de uma aplicação, nos dias atuais quesitos como desempenho, flexibilidade,
independência e segurança, por exemplo, tem sido pontos críticos na definição de modelo lógico. O uso de
recursos como a inserção proposital de pequenas redundâncias, desnormalização, seccionamento de
modelos, a inserção de controles adicionais de segurança e recuperação de dados, tem sido de grande ajuda
para isto.
E t eta to esses ajustes p opositais , deve se i ple e tados apenas no modelo lógico e em sua
fase final (de acabamento). Pensar nesses detalhes ou até mesmo prevê-los no modelo conceitual, pode ser
desastroso até para o mais habilidoso dos analistas.
A Abordagem Relacional
Para a criação de um modelo lógico, utilizaremos a abordagem relacional. Existem outras, porém a
mais comumente utilizada pela maioria dos SGBDs é o tipo relacional. Um Sistema Geranciador de Banco de
Dados (SGBD) é composto de tabelas (ou relações).

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Tabela
Uma tabela é um conjunto não ordenado de linhas (ou tuplas). No modelo conceitual, uma tabela é
representada por entidades, mas também podem surgir tabelas a partir de relacionamentos e atributos
multivalorados. Como forma de exemplificação, uma tabela de um modelo relacional pode ser considerada
uma como sendo uma planilha do Excel.
Cada linha da tabela é composta por uma série de campos (ou atributos).
No exemplo a seguir, sugere-se uma tabela para a entidade extraída do modelo conceitual chamada
Empregado. A tabela armazena dados sobre empregados de uma organização qualquer. Cada linha da tabela
corresponde a um empregado e cada campo é uma informação referente a este empregado (seu código, seu
nome, ...).
Empregado
CodigoEmp Nome CodigoDepto CategFuncional
E5 Souza D1 C5
E3 Santos D2 C5
E2 Silva D1 C2
E1 Soares D1 --
Tabela 1 - Exemplo de Tabela no Modelo Relacional
Algumas características de uma tabela de um banco de dados relacional a serem consideradas:

1. As linhas de uma tabela não tem ordenação definida. A menos que uma condição de ordenação seja
estabelecida durante a recuperação de dados, a ordenação será arbitrária podendo variar entre um SGBD e
outro;
2. Os valores de um campo de uma tabela são atômicos (o campo não é composto de outros) e
monovalorados (poderá ser definido apenas um valor para cada campo em linha específica);
3. As linguagens de consulta a bases de dados relacionais permitem acesso por qualquer critério necessário
envolvendo campos de uma ou mais linhas, entre uma ou mais tabelas, podendo inclusive fazer uso de
cálculos.
Chave
O conceito básico para identificar linhas e estabelecer relações entre linhas de tabelas de um banco de
dados relacional é o da chave. Em um banco de dados relacional existem ao menos três tipos de chaves à
considerar: Chave Primária, Chave Alternada e Chave Estrangeira.
Chave Primária

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Trata-se de uma coluna ou uma combinação de colunas cujos valores distinguem uma linha das demais
dentro de uma tabela. Por exemplo, na tabela do exemplo anterior o campo CodigoEmp é considerado o
campo que define a chave primária da tabela empregado.
No exemplo a seguir, temos uma chave primária composta de dois campos CodEmp e NoDepen. Neste
caso nenhum dos dois campos isolados é suficiente para distinguir uma linha das demais, já que tanto um
código de empregado (CodEmp) pode aparecer em várias linhas, quanto um número de dependente
(NoDepen), também pode. Neste caso faz-se necessário considerar ambos os valores (CodEmp e NoDepen)
para identificar uma linha da tabela, ou seja, neste caso um dependente.
Dependente
CodEmp NoDepen Nome Tipo DataNasc
E1 01 João Filho 12/01/2001
E1 02 Maria Filha 20/10/2003
E2 01 Ana Esposa 12/12/1970
E5 01 Paula Esposa 14/08/1981
E5 02 José Filho 03/05/1985
Tabela 2 - Chave Primária Composta
Neste caso para determinar a chave primária, devemos observar o princípio da minimalidade. Uma
chave é mínima quando todas as suas colunas forem efetivamente necessárias para garantir o requisito de
unicidade de valores da chave. Por exemplo, poderíamos ter na tabela a cima a chave primária sendo
composta por CodEmp, NoDepen e Tipo, porém o campo Tipo não se faz necessário e sendo assim este chave
não seria mínima, já que CodEmp e NoDepen combinados garantem outro requisito, o da atomicidade.
Com a chave primária estamos apenas garantindo a uma restrição de integridade na estrutura de
dados e não um meio de acesso. Neste caso a regra é unicidade de valores nas colunas que compõe a chave.
Chave Estrangeira
Trata-se de uma coluna ou uma combinação de colunas, cujos valores aparecem necessariamente na
chave primária de uma tabela. É o mecanismo que permite a implementação da integridade de
relacionamentos em um banco de dados relacional.
No exemplo a seguir temos as tabelas Emp e Dept, cuja o campo que compõe sua chave primária está
inserido na tabela Emp. Com isto podemos dizer que a coluna CodigoDepto da tabela Emp é uma chave
estrangeira em relação a chave primária da tabela Dept. A interpretação desta restrição é que todo
empregado deve estar associado a um departamento.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Dept
CodigoDepto NomeDepto
D1 Compras
D2 Engenharia
D3 Vendas
Tabela 3 - Tabela de Departamentos
Emp
CodEmp Nome CodigoDepto CategFuncional CPF
E1 Souza D1 -- 113.112.123-99
E2 Santos D2 C5 132.554.677-87
E3 Silva D2 C5 145.752.982-01
E5 Soares D1 C2 312.672.991-91
Tabela 4 - Tabela de Empregados
A existência de chaves estrangeiras devem garantir certas restrições de integridade ao se executar

operações de alteração ou inclusão no banco de dados:
1. Quando da inclusão de uma linha na tabela que contém a chave estrangeira:
Deve ser garantido que o valor da chave estrangeira apareça na coluna da chave referenciada. No caso do
exemplo anterior, significa que um novo empregado deve estar em um departamento já existente no banco
de dados;
2. Quando da alteração do valor da chave estrangeira:
Um novo valor de uma chave estrangeira deverá aparecer na coluna da chave primária referenciada;
3. Quando da exclusão de uma linha da tabela que contém a chave primária referenciada pela chave
estrangeira:
Deve ser garantido que, na coluna chave estrangeira, não apareça o valor da chave primária que está sendo
excluída. No caso anterior, significa que um departamento não pode ser excluído, caso à ele existam
empregados relacionados.
4. Quando da alteração do valor da chave primária referenciada pela chave estrangeira:
Deve ser garantido que, na coluna chave estrangeira, não apareça o antigo valor da chave primária que está
sendo alterada. No caso anterior, significa que caso um departamento possua empregados, seu código não
pode ser modificado.
Uma chave primária pode referenciar uma chave primária da própria tabela, criando assim uma chave
estrangeira da tabela, comumente conhecido como auto-relacionamento. Um auto-relacionamento é
interessante por exemplo em estruturas hierárquicas, como estruturas de pastas. No exemplo abaixo na
tabela Emp fora adicionado o campo CodEmpGerente, que identifica um outro empregado. Como todo
gerente também é um empregado, deve existir a restrição de que todo valor atribuído para CodEmpGerente

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
deve estar em CodEmp na mesma tabela. Assim a coluna CodEmpGerente é chave estrangeira em uma relação
a chave primária da própria tabela Emp.
Emp
CodEmp Nome CodigoDepto CodEmpGerente
E1 Souza D1 --
E2 Santos D2 E5
E3 Silva D2 E5
E5 Soares D1 E2
Tabela 5 - Auto-Relacionamento
Chave Alternada
Além da chave primária, podemos utilizar as chaves alternadas para distinguir uma linha das demais.
No exemplo a seguir na tabela Emp a coluna CodEmp é chave primária (distingue um empregado dos demais).
Porém a coluna CPF também distingue um empregado do outro, sendo assim a ela damos o nome de chave
alternada.
Emp
CodEmp Nome CodDepto CategFuncional CPF
E1 Souza D1 -- 124.135.982-09
E2 Santos D2 C5 837.135.982-01
E3 Silva D2 C5 123.998.019-76
E5 Soares D1 C2 778.123.017-87
Tabela 6 - Chave Alternada
Qua do isto o o e o al ue su ja a segui te uestão: Qual das possíveis olu as ou o i ação

delas se á utilizada o o have p i á ia . Po ue a olu a CodE p foi usada o o have p i á ia e ão a
coluna CPF? Por que CPF não foi usado como chave primária e CodEmp como chave alternada? Nesta situação
é importante verificarmos o ambiente como um todo, ao avaliarmos a tabela Emp por si só não faz sentido,
porém devemos lembrar que o(s) campo(s) da chave primária de uma tabela determina(m) o(s) campos de
chaves estrangeiras, sendo assim CodEmp torna-se um melhor candidato para chave primária.
Domínios e Valores Vazios

Quando uma tabela é definida, para cada coluna que a compõe deve-se especificar um conjunto de
valores (alfanumérico, numérico, ...) que os campos da respectiva coluna podem assumir. A este conjunto de
valores damos o nome de domínio da coluna ou domínio do campo.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Al disso deve os espe ifi a se valo es dos a pos pode se vazios ull e i gl s ou ão.
Estar vazio significa que o campo não recebeu nenhum valor do seu domínio. Um espaço em branco para um
campo alfanumérico ou um 0 para um campo numérico, indicam que este não é nulo. No exemplo da chave
alternada (tabela 6), o empregado E1 não possui CategFuncional informada, isto significa que ele não possui
categoria funcional ou a mesma ainda não foi informada para ele. Quando não admite-se valores vazios para
uma coluna, dizemos que ela é obrigatória. Normalmente as colunas que compõe a chave primária são
obrigatórias.
Restrições de Integridade
Um dos principais objetivos de um SGBD é dar suporte às restrições de integridade necessárias para o
banco de dados. Uma restrição de integridade é uma regra de consistência de dados que é garantida pelo
próprio SGBD. Na abordagem relacional temos normalmente as seguintes categorias de integridade:
 Domínio: Especificam que o valor de um campo deve obedecer a definição de valores admitidos para a
coluna (o domínio da coluna). Podem ser utilizados domínios pré-definidos (número inteiro, número
real, alfanumérico) ou então podem ser criados outros domínios (dependendo do SGBD);
 Vazio (Nulo): Especifica se os campos de uma coluna podem ser ou não vazios (se a coluna é obrigatória
ou não). Esta regra não se aplica a campos da chave primária, haja vista que estes devem ter valor;
 Chave: Define que os valores de uma chave primária ou alternada devem ser únicos;
 Integridade Referencial: Define os valores dos campos que aparecem em uma chave estrangeira devem
aparecer na chave primária da tabela referenciada.
Mais a frente este assunto será melhor abordado.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Aplicação do Modelo Lógico

A abordagem relacional modela os dados no nível de SGBD relacional. Para um modelo neste nível
abstração damos o nome de lógico. O modelo lógico é elaborado a partir da transformação de um modelo ER
em uma derivação, levando-se em conta algumas regras de derivação conforme mencionados anteriormente.
Em outras palavras saímos de um modelo mais abstrato para um modelo que tem mais detalhes de
implementação, ou seja, mais próxima da realidade necessária para a implementação do banco de dados.
Em linhas gerais a derivação do nível conceitual para o nível lógico, concentra-se em:
 Obter um banco de dados que tenha boa performance, ou seja, que gere pouco acesso a disco, cuja o
impacto de performance é maior;
 Obter um banco de dados que simplifique o desenvolvimento e a manutenção;
 Obter um banco de dados que ocupe pouco espaço em disco (armazenando somente o que é necessário);
Implementando Tabelas
Este passo consiste em definir as tabelas do modelo. Basicamente cada entidade é traduzida para uma
tabela. Neste processo cada atributo da entidade define uma coluna desta tabela. Os atributos identificadores
definem que colunas irão compor a chave primária da tabela.
Neste ponto temos apenas uma abordagem inicial, será necessário porém que mais à frente passemos
pelo passo chamado de normalização onde definiremos como serão modelados os relacionamentos, campos
multi-valorados, etc.
Na imagem a seguir é exibido um exemplo de transformação de uma entidade em uma tabela. Nela é
exibido o DER (conceitual) e o esquema relacional (lógico) correspondente feito na ferramenta case Power
Architect. A entidade pessoa, com seus atributos código, nome, endereço e data de nascimento é
transformada na tabela denominada Pessoa com colunas denominadas CodigoPess, Endereco, DataNasc e
DataAdm. O atributo código é identificador no modelo conceitual, logo no modelo lógico será a definição da
chave primária.
Modelo Conceitual Modelo Lógico

data de
nascimento
nome
PESSOA
código endereço
Figura 47 - Modelo Conceitual x Modelo Lógico

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Outra forma de representar é através do esquema relacional, que neste caso seria:
Pessoa (CodigoPess, Nome, Endereco, DataNasc)
Algumas regras para a definição de nomes de colunas são válidas:
 Não é aconselhável simplesmente transcrever os nomes de atributos para nomes de colunas. É importante
que sejam definidos nomes curtos, precedidos de uma sigla que identifique de qual tabela são, não pode
conter espaços em branco nem hífens, bem como não podem possuir acentuação gráfica;
 Nomes de atributos compostos de diversas palavras devem ser abreviados. Alguns autores entendem que
apenas as colunas que fazem parte da chave primária devem possuir a sigla como prefixo do nome;
Exercícios
1. De acordo com o DER conceitual abaixo, elabore o modelo lógico (relacional):
Código
(0,n) (1,n) Código
Nome Fornecedor Fabricante Nome
Endereço Endereço
CNPJ Tem Forenecedor
(1,1) (1,1) CNPJ
(0,n)
Fornecedor (0,n)
Número (0,n) (1,n) Código EAN13
Espécie Lote Produto Descrição
Data de Fabricação Preço UN.
Data de Validade
Qtd. Estoque
Data de Entrega Unidade Med.
2. De acordo com o modelo lógico (relacional) abaixo, onde apenas as tabelas são evidenciadas, defina as
colunas (possíveis) para cada uma delas, incluindo as chaves primárias (identificadores):
TIPO DE FORMA DE
VEICULO PESSOA FORNECEDOR
VEICULO PAGAMENTO
3. Elabore o modelo conceitual e em seguida derive-o para o modelo lógico da seguinte situação (excluindo-se
a derivação dos relacionamentos e cardinalidades:
U a e p esa fa i a p odutos, esta e p esa possui filiais uja os p odutos são dist i uídos. Os
produtos são vendidos para pessoas (físicas ou jurídicas) apenas nas filiais, cuja atividade exclusiva é a
venda. No final do mês a empresa (matriz) deseja receber um relatório de cada filial, indicando o montante
ve dido.
Implementando Relacionamentos
O fator mais importante da derivação de relacionamentos é a cardinalidade máxima e mínima. Existem
algumas alternativas válidas para esta situação:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Relacionamento Identificador: A regra para implementação de relacionamentos identificadores é a

seguinte:
 Para cada relacionamento identificador, é criada uma chave estrangeira na tabela que implementa a
entidade identificada pelo relacionamento identificador. Esta chave estrangeira é formada pelas colunas que
compõe a chave primária da tabela referenciada;
 A chave primária da tabela que implementa a entidade identificada pelo relacionamento identificador é
formada por:
o Colunas correspondentes aos atributos identificadores;
o Colunas que formam as chaves estrangeiras de relacionamentos identificadores.
Na imagem a seguir é exibido um exemplo que ilustra esta situação, envolvendo as tabelas Empregado
e Dependente, onde um empregado pode ter nenhum ou vários dependentes:
Modelo Conceitual
(1,1) (0,N)
EMPREGADO DEPENDENTE
Código Número de
Nome Sequencia Nome
Modelo Lógico
Figura 48 - Relacionamento Identificador
Tabela própria: O relacionamento é implementado através da criação de uma tabela própria. Esta
tabela contém as seguintes colunas: Colunas correspondentes aos atributos identificadores das entidades
relacionadas e colunas referentes ao relacionamento propriamente dito.
Caso este relacionamento seja n:n a chave primária da tabela a ser formada é composta pelas colunas
da chave primária das tabelas relacionadas e pelas colunas correspondentes aos atributos identificadores do
relacionamento, caso existam.
Conforme mostrado no exemplo a seguir, no DER (conceitual) é exibida uma estrutura formada pelas
entidades Engenheiro e Projeto, completando-se com o relacionamento entre elas chamado Atuação. A
cardinalidade do relacionamento é chamada de n:n, neste caso é criada uma nova tabela chamada Atuação:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Modelo Conceitual
(0,N) (0,N)
ENGENHEIRO ATUAÇÃO PROJETO
Código Código
Nome Função Título
Modelo Lógico
Figura 49 - Implementação de Relacionamentos
Adição de Colunas: Quando a cardinalidade máxima de uma das pontas do relacionamento é 1,

podemos implementar o relacionamento através da adição de colunas em uma das tabelas que participam do
relacionamento. Este tipo de abordagem consta basicamente em inserir na tabela correspondente à entidade
com cardinalidade máxima 1 as seguintes colunas:
 Colunas correspondentes ao identificador da entidade relacionada. Estas colunas formam a chave
estrangeira em relação à outra tabela do relacionamento;
 Colunas correspondentes aos atributos do relacionamento (que neste caso sempre existirão).
Modelo Conceitual
(1,1) (0,N)
DEPARTAMENTO LOTAÇÃO EMPREGADO
Código Código
Nome Data Lotação Título
Modelo Lógico
Figura 50 - Implementação de Relacionamentos Card. Máxima 1
Fusão de Tabelas de Entidades: Uma outra forma de implementar um relacionamento é através da

fusão das tabelas referentes às entidades envolvidas no relacionamento. Esta forma somente está disponível

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
para relacionamentos 1:1. Ela considera implementar em uma única entidade, todos os atributos de ambas as
entidades, bem como os do relacionamento que as envolve:
(1,1) (1,1)
TITULOS DETALHES DO
PAGAMENTO
PAGAMENTO
Número Valor a
Pagar Data de Valor Juros Multa
Pagamento Pago Pago Pago
Figura 51 - Implementando Relacionamentos 1:1
Exercícios
1. Através do DER (conceitual) a seguir, elabore o modelo relacional (lógico) referente, observando-se os
relacionamentos existentes, suas cardinalidades, aplicando as regras de derivação conforme necessidade:
(1,1) (0,N) (1,1) (0,N)

GRUPO EMPRESA EMPREGADO
(1,1)
(0,N)
DEPENDENTE
2. Ela o e o odelo ela io al lógi o pa a a segui te situação: Um carro possui várias peças, uma peça está
presente em vários carros. Uma montadora deseja controlar o montante de carros produzidos, incluindo a
quantidade de peças utilizadas por cada carro. Ela deseja também manter uma rastreabilidade por peça, ou
seja, deve á esta a aze ado e seu a o de dados u a efe e ia pa a ada peça e ada a o. ;
3. Ela o e o odelo ela io al lógi o pa a a segui te situação: A g ade curricular de um curso é formada por
dis ipli as e u a dis ipli a le io ada po p ofesso es e dias disti tos po se est e letivo. ;
4. De acordo com o DER (conceitual) a seguir, implemente o modelo relacional (lógico):
(1,1) (1,1)
CORRIDA EXECUÇÀO ORGANIZAÇÃO
Etapa País Data de

Local Data Regras
Execução definição gerais
5. De acordo com o DER (conceitual a seguir, implemente o modelo relacional (lógico):

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
(1,1) (0,1) CARTÃO

CORRENTISTA
MAGNÉTICO
Código Nome Código Data Exp.
6. Para o modelo casamento, onde temos uma entidade homem e outra mulher, sendo que um homem
poderá estar casado com nenhuma ou uma mulher e uma mulher poderá estar casada com nenhum ou um
homem, implemente o modelo lógico;
7. Para o modelo apartamentos de edifício, onde um edifício poderá ter um ou vários apartamentos e um
apartamento está em um edifício, implemente o modelo lógico;
8. Discussão em sala: Qual a principal forma de definir quando um relacionamento não n:n, deve gerar uma
nova tabela?
Implementando Atributos Multivalorados

Na abordagem relacional não existem colunas multivaloradas. Na imagem a seguir, é exibido um DER
contendo um atributo multivalorado (telefone).
CLIENTE
Código
Nome Número de
telefone (0,n)
Figura 52 - Implementando Atributos Multivalorados
No entanto esta implementação pode trazer certos problemas de performance, haja visto que o banco
de dados deverá ler linha-a-linha todos os telefones que o cliente possuir, tantos quantos forem necessários.
Em alguns casos (como este do exemplo anterior), é possível conceber uma implementação
simplificada, que atenda com melhor desempenho às buscas aos telefones de um cliente, considerando que:
 São raros os clientes que possuem mais que dois telefones. Quando isto ocorrer, dois telefones são
suficientes;
 Não existem consultas ao banco de dados utilizando o número de telefone como critério de busca;
Quando isto ocorrer (e as definições acima forem suficientes) podemos recorrer a uma implementação
des o alizada do odelo:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Figura 53 - Implementando Atributos Multivalorados - Desnormalizado
Mútua Exclusividade
Ocorre quando uma entidade participa de forma mutuamente exclusiva de dois ou mais
relacionamentos. Esta é mais uma regra que pode ser aplicada para implementação de relacionamentos,
diferente das demais anteriormente mencionadas.
Isto significa que uma ocorrência da entidade participa que participa de um dos relacionamentos, não
participa de nenhum dos demais relacionamentos. No exemplo abaixo onde são exibidas as entidades Pessoa
Física, Venda e Pessoa Jurídica relacionadas, podemos constatar através da cardinalidade exibida que uma
pessoa física participa de nenhuma ou várias vendas e que pessoa jurídica também participa de nenhuma ou
várias vendas, por outro lado, a venda é realizada para nenhuma ou uma das duas pessoas.
(0,1) (0,n) (0,n) (0,1)
Pessoa Física Venda Pessoa Jurídica
CPF Nro. CNPJ

nome Data Razão
social
Figura 54 - Exemplo de relacionamento de mutua-exclusivida
A primeira alternativa seria a implementação do modelo lógico tradicional, onde criaríamos os campos
CPF e CNPJ definidos como opcionais, sendo assim a chave estrangeira seria não identificadora (não faria parte
da chave primária na tabela de relacionamento – venda). O diagrama abaixo ilustra esta situação.
Figura 55 - Alternativa 1 - muta exclusividade
A segunda alternativa para esta situação é a criação de um único campo no qual os valores para CPF e
CNPJ possam ser inseridos. Além disto deve-se criar um campo novo que informa se o comprador é uma

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
pessoa física ou pessoa jurídica, assim saberíamos se o valor do campo trata-se de um CPF ou CNPJ, conforme
mostrado no modelo lógico abaixo:
Figura 56 - Alternativa 2 - mutua exclusividade
A segunda alternativa porém tem uma desvantagem em relação à primeira, quando trata-se de chaves
estrangeiras, já que não será possível definir uma chave estrangeira ligando venda com pessoa física ou
jurídica já fora realizada a fusão dos campos CPF e CNPJ.
Exercícios
1. Elabore um modelo relacional (DER) lógico da seguinte situação: uma oficina mecânica presta serviço de
manutenção e também venda de peças. Uma venda poderá conter serviço e peça, sendo que serviço deverá
ter no mínimo as seguintes informações: código, descrição, qtd. Horas, nível complexidade e garantia, já
peças deve ter no mínimo as seguintes informações: código do fabricante, descrição, unidade medida (peça,
litro, quilo, mt, cm, etc) e valor unitário . Implemente o modelo utilizando as duas alternativas apresentadas.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Restrições de Integridade
A implementação física de um banco de dados passa pela seleção da melhor solução de SGBD, em
outras palavras o SGBD que melhor implementa o controle das regras de integridade do banco de dados.
Ainda existem alguns SGBDs que não as implementam, passando assim a responsabilidade deste serviço para
as aplicações que manipulam as estruturas de dados.
Existem algumas formas de integridade que os SGBDs devem (ou deveriam) no mínimo implementar,
dentre elas destacam-se:
Integridade de Unicidade de Valores

Neste caso devemos analisar a aplicação desta integridade sob dois enfoques: O primeiro deles trata-se
da aplicação e uso efetivo das chaves primárias. Como sabemos uma tabela poderá conter uma chave
primária, a qual identifica de maneira única um registro (linha) em uma tabela de dados. Todos os bancos de
dados que são denominados relacionais, devem implementar no mínimo esta característica, pois caso não
implementassem não poderiam ser assim chamados.
O segundo enfoque está relacionado às colunas não pertencentes a chave primária de uma tabela,
sendo que neste caso não tem aspectos de implementação tecnológica e sim conceituais.
Um exemplo seria um cadastro de veículos, onde teríamos o número do chassi como chave primária,
composto também pelas colunas cor, modelo, ano de fabricação e número da placa. Conceitualmente fica
claro que não podem existir veículos com placas iguais. Porém o campo número da placa não faz parte (ou é)
da chave primária, e portanto, não existem restrições que impeçam a inserção de veículos com placas iguais.
Figura 57 - Aplicação de Regra de Unicidade
Neste caso deveremos definir no modelo lógico que o campo placa do veículo é único, ou seja,
implementar a restrição de unicidade para este campo através da criação de uma chave alternada definida
como única. Alguns SGBDs permitem aplicar regra de unicidade sobre uma coluna diretamente.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Integridade Referencial
A implementação de relacionamentos em um modelo de abordagem entidade relacionamento
(relacional), visa em sua plenitude cumprir critérios de integridade referencial. Isto significa que, , isto deverá
ser garantido através de dados contidos nessas tabelas. Para isto cada SGBD dever implementar mecanismos
que garantam a integridade dos relacionamentos e ão dei e ausa ue as de i teg idade .
Por definição uma chave estrangeira é uma chave primária de uma tabela migrada para outra tabela a
fim de estabelecer vínculo com a primeira. Esse vínculo é estabelecido através de valores comuns entre as
tabelas. E out as palav as deve os possui a ta ela efe e iada u apo ta e to pa a a ta ela de
referencia. Na imagem abaixo é ilustrada esta situação:
Figura 58 - Exemplo de "Quebra de Integridade"
Exclusão e Atualização de Chaves em Cascata

Caso e ista e ossos odelos est utu as do tipo hie a uia o ue asta te o u ,
deve e os assegu a at av s de “GBD ou via p og a ação, ue a e lusão de u pai a est utu a, eflita,
ua do e essá io, a e lusão dos filhos e assim por diante.
E e tos asos a e lusão de pais ão i pli a a e lusão de filhos . Deve os a alisa aso a aso
e ve ifi a ual a adeia de e lusão e essá ia.
Da mesma forma a regra vale também para as atualizações, quando os valores de um dos campos da
have p i á ia da ta ela ou egist o da elação pai fo alte ado, deve á se assegu ado ue os valo es de
efe ia das haves est a gei as das ta elas filhas se ão atualizados auto ati a e te seja via “GBD ou
via aplicação.
Em ambos os asos e iste situações ue o e u so e as ata ão pode á se utilizado, este aso
deverá ser gerada uma exceção (falha) seja via SGBD ou aplicação e enviada para o usuário a fim de notificá-lo
de que a linha/registro está sendo referenciado em uma relação.
Exercícios
Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
1. Implemente um modelo lógico que trata da seguinte situação: Em um concurso público os candidatos devem
se inscrever pelo site informando: nome, CPF, RG, endereço e telefone. Para cada inscrito será gerado um
código de inscrição que deverá ser a identificação primária do registro. Implemente o modelo verificando as
regras necessárias para garantir que não existirão pessoas com CPF iguais bem como RG;
2. De acordo com o modelo lógico abaixo, é possível implementar regras de exclusão ou atualização em
cascata?

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Generalização e Especialização
Uma estrutura de generalização/especialização pode ser implementada na abordagem relacional de
duas formas: 1 – uso de uma tabela por entidade/classe ou 2 – uso de uma única tabela para toda a hierarquia
de entidades/classes.
Uma tabela por hierarquia de classes

Nesta forma todas as tabelas referentes às especializações de uma entidade genérica são fundidas em
uma única tabela. Normalmente esta tabela será composta por no mínimo:
 Chave primária: correspondente ao identificador da entidade mais genérico;
 Caso não exista, uma coluna tipo que identifica que tipo de entidade especializada está sendo representada
por cada linha da tabela;
 Uma coluna para cada atributo de entidade genérica;
 Colunas referentes aos relacionamentos dos quais participa a entidade genérica e que sejam implementados
através da alternativa de adicionar colunas à tabela da entidade genérica;
 Uma coluna para cada atributo de cada entidade especializada, estas colunas são opcionais por estarem
implementadas na classe especializada;
 Colunas referentes aos relacionamentos dos quais participa cada entidade especializada e que sejam
implementados através da alternativa de adicionar colunas à tabela da entidade, também definidas como
opcionais;
Podem ocorrer casos onde a entidade especializada não gere nenhuma coluna na implementação, isto
ocorre quando a entidade especializada não tem atributos e todos os relacionamentos que ela participa sejam
implementados por tabelas próprias.
No exemplo a seguir do modelo conceitual a entidade empregado e suas especializações são
implementadas em uma única tabela no modelo lógico. Neste caso a tabela empregado deverá conter no
mínimo as seguintes colunas:
 EmpCodigo, que é a chave primária da tabela;
 EmpTipo, EmpNome e EmpCPF que são referentes aos atributos da entidade genérica;
 DepCodigo que implementa a relação lotação com a entidade Departamento.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Figura 59 - Exemplo de Implementação de Generalização/Especialização – Tabela única
Uma tabela por entidade especializada

Uma outra alternativa é criar uma tabela para cada entidade especializada, utilizando todas as regras já
aplicadas anteriormente, porém adicionando uma chave primária para cada tabela que compõe a hierarquia.
No exemplo mencionado anteriormente, o modelo lógico resultante seria:
Figura 60 - Modelo lógico de implementação generalização/especialização - uma tabela por entidade especializada
Existe uma terceira forma de implementação que também refere-se à implementação de uma tabela
para cada entidade especializada, porém as tabelas não tem relacionamento entre si e cada tabela
implementa todos os atributos das entidades especializadas e genéricas. Não é a melhor alternativa para o
modelo relacional.
Considera-se a aplicação das alternativas 1 e 2 para os casos do exemplo anterior.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Exercício
Implemente o modelo lógico do modelo conceitual a seguir, utilizando a primeira e segunda formas de
resolução apresentadas.
Número
(0,n) (1,n)
Conta Correntista Pessoa
CPF
Banco código nome
Agencia
Conta Corrente Poupança Investimento
Rendimento %
Limite Tx. Juro Prazo
Especial Universitária
Dias s/Juro Taxa Manutenção

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Normalização
Este processo baseia-se no conceito de forma normal. Uma forma normal é uma regra que deve ser
o ede ida po u a ta ela pa a ue esta seja o side ada e p ojetada . E iste dive sas fo as o ais,
isto é diversas regras, cada vez mais rígidas, para verificar tabelas relacionais.
Iremos considerar aqui quatro formas normais, elas são denominadas simplesmente de primeira forma
normal, segunda, terceira e quarta, ou abreviadamente 1FN, 2FN, 3FN e 4FN.
Um modelo de dados para estar completo, precisa ser validado anteriormente pelas formas normais,
caso contrário diversos problemas de implementação podem ocorrer durante o ciclo de desenvolvimento.
Além disso a manutenção de uma aplicação regimentada por uma estrutura de dados assim é mais complexa.
Um exemplo de estrutura não normalizada poderia ser demonstrado de acordo com a tabela abaixo:
Emp
CodProj Tipo Descr
CodEmp Nome Cat Sal DataIni TempAl
LSC001 Novo Sistema de 2146 João A1 4 01/11/2010 24
Desenv. Estoque 3145 Silvio A2 4 12/11/2010 24
6126 José B1 5 01/12/2010 32
1214 Carlos C1 6 10/10/2010 20
8191 Mário A1 4 01/10/2010 10
PAG02 Manutenção Sistema de 8191 Mário A1 4 01/11/2010 12
RH 6126 José B1 6 05/12/2010 24
Passagem à primeira forma normal (1FN)

Quando um modelo não possuir mais tabelas aninhadas, considera-se que ele esteja na 1FN. Na tabela
anterior, os dados referente aos empregados estão aninhados para cada linha de projeto. O conceito de tabela
aninhada aqui, seria o mesmo que uma estrutura de a a e Java.
Para isto temos duas alternativas básicas:
 Construir uma única tabela com redundância de dados
Neste caso cria-se uma tabela na qual os dados das linhas externas à tabela aninhada são
repetidos para cada linha da tabela aninhada. Para o exemplo apresentado na tabela anterior o
esquema lógico resultante seria:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Figura 61 - Passagem à 1FN - Forma 1
 Construir uma tabela para cada tabela aninhada

Cria-se uma tabela referente à própria tabela que está sendo normalizada e uma tabela para cada tabela
aninhada. No caso do exemplo da tabela anterior, o esquema lógico resultante seria:
Figura 62 - Passagem à 1FN - Forma 2
Exercício
Implemente o modelo lógico normalizado na primeira forma normal (1FN) da seguinte tabela de dados:
Código Telefones
Nome da
da Endereço Num. Telefone Tipo Descr. Telefone
Pessoa
Pessoa
1 Carlos Rua X (47) 3521-2203 1 Residencial
(47) 8829-2939 2 Celular
(47) 3132-2921 3 Comercial
2 João Rua Carlos (47) 3320-3920 1 Residencial
Gomes (47) 3392-9283 1 Residencial
Passagem à segunda forma normal (2FN)

Esta forma normal objetiva eliminar certos tipos de redundância de dados. No exemplo da tabela
ProjEmp, os dados referentes a empregados (Nome, Cat e Sal) estão redundantes, para os empregados que
trabalham em mais de um projeto. Um exemplo é o empregado 8191. A passagem a segunda forma normal
objetiva eliminar este tipo de redundância de dados.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Em outras palavras, dis-se que uma tabela está na 2FN quando além de estar na 1FN, não contém
dependências parciais. Uma dependência parcial por sua vez, ocorre quando uma coluna depende apenas de
parte de uma chave primária composta.
Após o modelo estar na 1FN devemos analisar as tabelas resultantes em busca de chaves compostas de
mais de um campo. No exemplo anterior a tabela TbProj encontra-se na 2FN por possuir uma chave simples
(composta de apenas uma coluna).
Já a tabela TbProjEmp deve ser examinada. As colunas EmpNome, EmpCat e EmpSal dependem cada
uma, apenas da coluna EmpCodEmp, já que nome, categoria funcional e salário são determinados apenas pelo
código do empregado. Já as colunas EmpDataIni e EmpTempAl, dependem da chave primária completa.
Para passar este modelo para a 2FN deve-se dividir a tabela TbProjEmp em duas tabelas como no
modelo lógico representado a seguir:
Figura 63 - Passagem à 2FN
Exercício
Observe o exercício proposto anteriormente e verifique a necessidade de passagem do modelo resultante
para a 2FN, caso necessário implemente.
Passagem à terceira forma normal (3FN)

A terceira forma normal visa eliminar um outro tipo de redundância. Uma tabela está na 3FN se ela
estiver na 2FN e se nenhuma coluna não-chave depender de outra coluna não-chave.
Na terceira forma normal temos que eliminar aqueles campos que podem ser obtidos pela equação de
outros campos da mesma tabela. Os procedimentos básicos são:
a) Identificar todos os atributos que são funcionalmente dependentes de outros atributos não chave;
b) Removê-los.
A chave primária da nova entidade será o atributo do qual os atributos removidos são funcionalmente
dependentes. A regra aplicada para a passagem para a 3FN é muito parecida com a da 2FN, temos de ter
cuidado ao verificar os atributos funcionalmente dependentes.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Como exemplo considere a tabela a seguir:

Pedido Codigo Produto Quant Valor Unit SubTotal
1005 1-934 3 1000 3000
1005 1-298 5 500 2500
1005 1-345 3 150 450
1006 1-879 2 1000 2000
1007 1-667 3 300 900
Esta tabela não está na 3FN, pois a coluna SubTotal é o resultado da equação Quant * Valor Unit.,
desta forma a coluna subtotal depende de outras colunas não-chave. Para normalizar esta tabela na terceira
forma normal, devemos remover o campo SubTotal.
Levando-se em conta o exemplo da alocação de pessoas à projetos, podemos verificar que o modelo
está na 2FN, porém a tabela TbEmp ainda possui dependências funcionais transitivas (que ocorrem quando
uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas
da tabela), sendo assim ela deve ser passada para 3FN, o conteúdo da tabela TbEmp seria o seguinte:
CodEmp Nome Cat Sal
2146 João A1 4
3145 Silvio A2 4
6126 José B1 5
1214 Carlos C1 6
8191 Mário A1 4
A transição do modelo que está na 2FN para a 3FN pode ser verificada a seguir:
Figura 64 - Passagem para a 3FN
Deve-se observar que, diferentemente da 2FN, a regra para a 3FN aplica-se também à colunas não
dependentes de chave primária.

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Passagem à quarta forma normal (4FN)

Uma tabela encontra-se na 4FN quando além de estar na 3FN, não possui dependências
multivaloradas.
No exemplo a seguir é exibida uma estrutura ER que está na 3FN porém existe uma situação de coluna
multivalorada.
Figura 65 - Exemplo de 3FN -> 4FN
O conteúdo da tabela abaixo, ilustra esta situação:

EstNumero LivISBN AutCodigo
E1 L1 A1
E1 L1 A2
E1 L2 A7
E1 L2 A8 LivISBN = L1 AutCodigo = {A1, A2}
E1 L2 A9
E2 L1 A1 LivISBN = L2 AutCodigo = {A7, A8, A9}
E2 L1 A2
E3 L2 A7
E3 L2 A8
E3 L2 A9
Neste caso observa-se que a coluna LivISBN (L1), possui dependência multivalorada para os AutCodigo
(A1 e A2), ou seja, o livro cuja o ISBN é L1 é escrito pelos autores A1 e A2, da mesma forma que L2 é escrito
por A7, A8 e A9.
Ocorre que na estrutura da tabela acima, está se vinculando além dos dados os autores dos livros, as
estantes na qual os livros estão contidos.
Neste caso ao aplicar a 4FN temos o seguinte modelo:

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Figura 66 - Exemplo de Modelo na 4FN
Exercício
Com base no relatório emitido por um sistema de hospedagem para o proprietário do hotel,
desenvolva o modelo lógico observando as regras de normalização da 1FN até a 4FN:
Quarto: 101 Tipo: AD – Apto Duplo Andar: 1
Hóspedes:
Nome: João Silva CPF: 1111100000 Entrada: 15/11/2010 SaídaPrevista: 17/11/2010
Nome: Mário Sá CPF: 1111111110 Entrada: 15/11/2010 SaídaPrevista: 16/11/2010
Consumo:
Data: 15/11/2010 Item: 01 – Almoço Valor: R$ 15,00
Data: 15/11/2010 Item: 22 – Refrigerante Valor: R$ 1,50
Data: 16/11/2010 Item: 06 – Caviar Valor: R$ 18,50
Total: R$ 35,00
Quarto: 102 Tipo: AS – Apto Simples Andar: 1
Hóspedes:
Nome: Maria Souza CPF: 1010101010 Entrada: 14/11/2010 SaídaPrevista: 18/11/2010
Consumo:
Data: 16/11/2010 Item: 01 – Almoço Valor: R$ 15,00
Total: R$ 19,50

Fone 047 35218510/ Fax 047 3521 9299 - CNPJ 07162848/0001-66
Referências
COUGO, Paulo Sérgio. Modelagem conceitual e projeto de banco de dados. Rio de Janeiro: Campus, 1997;
HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre: Sagra Luzzato, 2000.

Modelagem de Sistemas de Informação

Enviado por

Dados do documento

Descrição original:

Título original

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

Modelagem de Sistemas de Informação

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE METROPOLITANA DE RIO DO SUL

Prof. Cleber Nardelli1

Não asta sa er, é pre iso sa er fazer Página 1

Mapear Objetos do Mundo Real ........................................................................................................................ 6

A Organização e Seus Dados ................................................................................................................................... 7

Sistema de Gerencia de Banco de Dados - SGBD ................................................................................................... 9

Introdução à Modelagem Funcional ..................................................................................................................... 11

Diagrama de Fluxo de Dados – DFD .................................................................................................................. 11

Leitura complementar: Análise Essencial - Lista de Eventos ............................................................................ 17

Casos de Uso ..................................................................................................................................................... 26

Diagrama de Classes ......................................................................................................................................... 32

Não asta sa er, é pre iso sa er fazer Página 2

Leitura complementar: Conceitos e Princípios da Orientação a Objeto ...................................................... 38

Introdução ao Modelo ER ..................................................................................................................................... 40

O Modelo Conceitual ............................................................................................................................................ 41

Cardinalidade de Relacionamentos .................................................................................................................. 48

Cardinalidade Máxima .................................................................................................................................. 48

Cardinalidade Mínima ................................................................................................................................... 49

Exemplo do Uso de Cardinalidades nas Associações.................................................................................... 50

Identificação de Entidades ................................................................................................................................ 51

Identificação de Relacionamentos .................................................................................................................... 52

O Modelo Lógico ................................................................................................................................................... 56

A Abordagem Relacional ................................................................................................................................... 56

Domínios e Valores Vazios ............................................................................................................................ 60

Restrições de Integridade ............................................................................................................................. 61

Aplicação do Modelo Lógico ............................................................................................................................. 62

Implementando Tabelas ............................................................................................................................... 62

Implementando Atributos Multivalorados ................................................................................................... 67

Não asta sa er, é pre iso sa er fazer Página 3

Mútua Exclusividade ......................................................................................................................................... 68

Restrições de Integridade ..................................................................................................................................... 70

Integridade de Unicidade de Valores................................................................................................................ 70

Exclusão e Atualização de Chaves em Cascata ................................................................................................. 71

Uma tabela por hierarquia de classes .............................................................................................................. 73

Uma tabela por entidade especializada ........................................................................................................... 74

Passagem à primeira forma normal (1FN) ........................................................................................................ 76

Passagem à segunda forma normal (2FN) ........................................................................................................ 77

Passagem à terceira forma normal (3FN) ......................................................................................................... 78

Passagem à quarta forma normal (4FN) ........................................................................................................... 80

Não asta sa er, é pre iso sa er fazer Página 4

Introdução à Modelagem de Sistemas de Informação

Não asta sa er, é pre iso sa er fazer Página 5

Mapear Objetos do Mundo Real

Quais são as características observadas das imagens que podemos modelar?

A Organização e Seus Dados

Não asta sa er, é pre iso sa er fazer Página 7

Produção Vendas Compras

Arquivos produção Arquivos Vendas Arquivos Compras

Produtos Produtos Produtos

Figura 1 - Banco de Dados Isolado

Não asta sa er, é pre iso sa er fazer Página 8

Produção Vendas Compras

Figura 2 - Banco de Dados Compartilhado

O Co ju to de a uivos i teg ados ue ate de au o ju to de siste as, ha ado de Ba o de

Sistema de Gerencia de Banco de Dados - SGBD

Não asta sa er, é pre iso sa er fazer Página 9

Não asta sa er, é pre iso sa er fazer Página 10

Introdução à Modelagem Funcional

Diagrama de Fluxo de Dados – DFD

Obs: Na prática é utilizado apenas um destes dois (Contexto ou Nível 0).

Não asta sa er, é pre iso sa er fazer Página 11

Entidades Externas ou Atores