Importância da Modelagem de Dados para a Gestão de Informações

Prévia do material em texto

www.professormarco.com.br 
Prof. FABIO BERNARDO DA SILVA 
Cada vez mais, a necessidade de um adequado uso da tecnologia da informação tem sido preocupação das 
organizações nesse início de século XXI, sobretudo quanto à gestão do acervo de informações. 
As principais preocupações são: 
•Os sistemas de informação têm que suportar, além de processos transacionais e operacionais, também processos 
analíticos e voltados para inteligência de negócios; 
•Os sistemas de informações atuais têm a necessidade de expor os dados corporativos, e dar acesso às transações 
que os manipulam, diretamente para clientes ou fornecedores da empresa em aplicações na Internet. 
•Os investimentos em tecnologia e serviços para TI são elevadíssimos e as organizações esperam obter com isso um 
importante resultado que é o de elevar a qualidade dos serviços e produtos oferecidos com os mais baixos custos 
possíveis, para se manter competitivo. 
Dentro deste contexto a modelagem de dados assume uma importância fundamental, por ser durante o projeto de 
banco de dados definidas as informações a serem armazenadas, visando atender as atuais e futuras do negócio, com 
um alto nível de abstração da realidade. 
A compreensão dos princípios de modelagem, a utilização de mecanismo de abstração e o domínio de técnicas de 
notação, são ferramentas essenciais a qualquer profissional de TI na gerencia e execução de funções ligadas ao 
desenvolvimento de aplicações, pois não se concebe, no panorama atual, que um sistema computadorizado possa 
prescindir da utilização de banco de dados em suporte às suas atividades. 
Ao final dessa disciplina você será capaz de: 
•Citar os conceitos fundamentais de Sistemas de Banco de Dados; 
•Descrever a arquitetura e os níveis de um sistema de gerenciamento de banco de dados; 
•Explicar os tipos de modelos de dados existentes focando no modelo relacional; 
•Empregar os conceitos fundamentais de projeto de banco de dados; 
•Elaborar modelos conceituais dados; 
•Elaborar modelos lógicos de dados; 
Nesta aula, você irá: 
 
1 - Aprender a diferença entre dado e informação 
 
2 - Conceituar Banco de Dados, Sistema Gerenciador de Bancos de Dados e Sistemas de Bancos de Dados 
 
3 - Analisar as diferenças entre Sistemas de Bancos de Dados e Sistemas baseados em Arquivos 
 
4 - Conhecer a história e a evolução dos bancos de dados 
 
5 - Conhecer os usuários de um ambiente de banco de dados 
Dados x Informação 
Dados representam fatos em sua forma primária. Por exemplo, o nome de um empregado, a quantidade de horas 
trabalhadas, por cada empregado, em uma semana, os números das peças mantidas em estoque ou dos seus 
pedidos de compras. 
 
Quando este fatos são organizados ou arranjados de modo significativo, eles se tornam uma informação. 
Informação, portanto, é um conjunto de fatos organizados de tal forma que adquirem um valor adicional, além do 
valor do fato em si. Por exemplo, o total de vendas mensais pode ser mais adequado ao seu propósito, ou seja, pode 
conter mais valor, do que as vendas de cada vendedor individualmente. 
A transformação de dados em informação é um processo. Por exemplo, com os dados de peças mantidas em 
estoque, pedidos e vendedores podemos obter informações tão diferentes quanto: lista de peças que estão em falta 
no estoque, a média de venda por peça, os melhores e piores vendedores da companhia e, ainda, relacionar os 
piores e melhores vendedores com as horas trabalhadas por cada um deles. 
 De forma simples, podemos entender um sistema de informação como um conjunto de processos que transforma 
dados em informação. 
Dados -> Processo -> Informação 
Os dados relevantes para um determinado negócio se mantêm estáveis mesmo que o negócio em questão 
modifique radicalmente sua forma de operação, ou seja, os seus processos. 
 Sendo assim, podemos afirmar que dados são mais estáveis do que processos e, portanto, representam a uma das 
partes mais valiosas e importantes de um sistema de informação. 
Bancos de Dados 
De acordo com (Navathe, 2005), podemos definir um banco de dados como um conjunto de dados que se 
relacionam. Porém, o significado do termo é mais restrito do que esta definição. Um banco de dados, 
necessariamente, possui as seguintes propriedades: 
 
Sistemas Gerenciadores de Bancos de Dados e Sistemas de Banco de Dados 
Um banco de dados é criado e mantido por um conjunto de aplicações desenvolvidas especialmente para esta tarefa 
denominado “Sistema Gerenciador de Banco de Dados” (SGBD). 
Um SGBD é uma coleção de programas que permite aos seus usuários criarem e manipularem bancos de dados. O 
conjunto formado por um banco de dados e estes programas que o manipulam é chamado de Sistema de Banco de 
Dados. 
Uma característica importante da abordagem de Banco de Dados é que o SGBD não mantém somente os dados, 
mas, também, a forma como os mesmos são armazenados, através de uma descrição completa dos dados 
armazenados. Estas informações são armazenadas no catálogo ou dicionário de dados do SGBD, que contém 
informações como a estrutura de cada arquivo, o tipo e o formato de armazenamento de cada tipo de dado, 
restrições, etc. As informações armazenadas neste catálogo são chamadas meta-dados. 
 
SGBD X Sistemas de Gerenciamento de Arquivos 
A melhor maneira de entender a natureza geral e as características dos bancos de dados de hoje é olhar para as 
características dos sistemas que antecederam o uso da tecnologia de banco de dados: os Sistemas de 
Gerenciamento de Arquivos. Tais características são: 
1) Cada usuário define e implementa os arquivos necessários para uma aplicação específica, acarretando 
repetição dos dados e gerando inconsistência nas informações. Por exemplo, o salário de um funcionário 
pode ser utilizado tanto por um sistema de folha de pagamento quanto por um sistema financeiro. Se cada 
um destes sistemas possui seu próprio conjunto de arquivos, não existem garantias que a alteração do 
salário de um funcionário específico seja efetuada para os arquivos nos dois. E, esta atualização não seja 
efetivada para os dois sistemas, em algum deles, as informações geradas com base neste dado, serão 
inconsistentes. Não refletirão a realidade do negócio. 
2) O acesso aos dados está escrito nos programas que o manipulam, subordinando os programas aos arquivos. 
Isto significa que qualquer alteração na estrutura dos arquivos acarretará alterações em todos os 
programas que o acessam. Estas alterações sempre envolvem muito tempo e muito dinheiro. 
3) A manipulação dos dados contidos nos arquivos pelas aplicações específicas dificulta o desenvolvimentos de 
novos sistemas e torna a manutenção dos aplicativos difícil e cara. 
4) O Sistema possibilitas uma redundância não controlada de dados e inconsistência ao permitir que em um 
sistema um dados seja alterado e esse mesmo dado não seja alterado em outro. De forma semelhante como 
descrito no item 1). 
5) A responsabilidade sobre os procedimentos de backup e recuperação esta a cargo da aplicação. Ou seja, não 
podem ser automatizadas e, caso o responsável pela aplicação não efetue estes backups sistematicamente, 
podem ocorrer perda de dados. 
Em ambientes de SGBD 
Um arquivo(tabela) é definido uma única vez e atende a várias aplicações, ou seja, existe múltipla visão dos dados. 
Armazena-se junto com os dados todas as informações referentes à forma como estes foram estruturados e onde 
eles estão armazenados fisicamente. Essas informações estão armazenadas no catálogo, como mencionado 
anteriormente. Há separação entre programas e dados. No SGBD os acessos são escritos no banco de dados e os 
programas enviam comandos, solicitando o acesso aos dados. Esse conceitos é chamado de abstração de dados, que 
caracteriza-se por uma independência entre programas e dados e entre programas e operações de manipulação de 
dados. Observe na figura 1, que as consultas e programas de aplicação só acessamo banco de dados através do 
SGBD. Da mesma forma, todos os dados retornados pelo banco de dados, somente são disponibilizados aos usuários 
e aplicações pelo SGBD. É permitido acesso simultâneo de vários usuários ao mesmo dado. Essa simultaneidade é 
tratada através do gerenciamento da concorrência. Procedimentos de backup e recuperação são automatizados. 
Evolução dos Bancos de Dados 
Nos primeiros sistemas de informação, dados e processos eram mantidos juntos em um mesmo arquivo, como no 
esquema a seguir. 
Programa com Dados Armazenados 
A partir da observação de que os dados são muito mais estáveis que os processos, em um sistema de informação, 
iniciou-se a época de investimentos massivos no desenvolvimento de ferramentas voltados para seu tratamento 
eficiente. Gradativamente, dados e processos foram separados. Em um primeiro momento, estas ferramentas 
mantinham as funções básicas de criação e manipulação dos dados independentes das aplicações. 
DADOS - Programa com Gerência de arquivos 
Em um segundo momento, apresentando as características dos SGBDs descritas anteriormente. 
DADOS - SGBD - Programa de aplicação de BD 
A partir deste ponto, em paralelo com a evolução do hardware disponível para suportar tais aplicações, estes 
ambientes foram ganhando novas versões como representadas nos esquemas que seguem.
 
Os bancos de dados crescem em volume de dados e as redes se tornam quase ilimitadas em tamanho. Para garantir 
a eficiência nestes ambientes, surge a necessidade de distribuição da própria base de dados. Surgem, então, os 
bancos de dados distribuídos. Estes bancos de dados representam, de forma bastante simplificada, a divisão do 
banco de dados por vários servidores de bancos de dados. 
 
Novas arquiteturas de BD – Datawarehouse 
 
Os bancos de dados saem do nível operacional da empresa e são agora preparados para atender níveis mais altos da 
pirâmide empresarial. Os datawarehouses, ou armazéns de dados, representam esta promoção dos bancos de 
dados. Eles contém dados como nos bancos convencionais, só que preparados para atender as necessidades de 
informação dos níveis estratégicos da organização. Eles agora são empregados na tomada de decisão dentro das 
empresas, e não apenas na viabilização do funcionamento destas no dia a dia. 
 
 
 Aprendeu a diferença entre dado e informação. 
 Aprendeu os conceitos de Banco de Dados, Sistema Gerenciador de Bancos de Dados e Sistemas de Bancos de 
Dados. 
 Analisou as diferenças entre Sistemas de Bancos de Dados e Sistemas baseados em Arquivos. 
 Conheceu um pouco da história e da evolução dos bancos de dados. 
 Foi apresentado aos usuários de um ambiente de banco de dados. 
 
1. 
 Para cada item abaixo, marque com a letra D aqueles que representam um Dado e com a letra I aqueles que 
representam uma Informação. 
 ( ) a sua matrícula na UNESA 
( ) quantidade de alunos matriculados na disciplina Modelagem de Dados 
( ) a sua nota na disciplina Modelagem de Dados 
( ) a média dos alunos da sua de turma de Modelagem de Dados 
( ) o nome do seu tutor na disciplina Modelagem de Dados 
( ) a média alcançada por cada tutor da disciplina Modelagem de Dados 
 1) I,D,I,I,D,I 
 2) I,D,D,I,D,D 
 3) D,I,I,D,D,I 
 4) D,I,D,I,D,I 
 5) D,I,I,I,D,D 
 4 
 2. 
 Um banco de dados possui as seguintes propriedades, exceto uma: 
 1) um banco de dados é uma coleção lógica coerente de dado,s com um significado inerente; uma disposição 
desordenada de dados não pode ser referenciada como um banco de dados; 
 2) um banco de dados é projetado, construído e populado com dados para um propósito específico; 
 3) dependência direta dos processos que o utilizam; 
 4) um banco de dados possui um conjunto pré definido de usuários e aplicações; 
 5) um banco de dados representa algum aspecto do mundo real, o qual é chamado de “mini-mundo” , e qualquer 
alteração efetuada neste mini-mundo é automaticamente refletida no banco de dados. 
 3 
 3. 
 São características dos ambientes dos Sistemas de Gerenciamento de Arquivos, com exceção de: 
 1) Cada usuário define e implementa os arquivos necessários para uma aplicação específica, acarretando 
repetição dos dados e gerando inconsistência nas informações. 
 2) O acesso aos dados está escrito nos programas que o manipulam, subordinando os programas aos arquivos. 
 3) A responsabilidade sobre os procedimentos de backup e recuperação esta a cargo da aplicação. 
 4) A manipulação dos dados contidos nos arquivos pelas aplicações específicas facilita o desenvolvimento de novos 
sistemas e torna a manutenção dos aplicativos mais simples. 
 5) O sistema possibilita uma redundância não controlada de dados e inconsistência ao permitir que em um sistema 
um dado seja alterado e esse mesmo dado não seja alterado em outro. 
 4 
 4. 
 É uma vantagem do uso de SGBDs: 
 
 1) Um arquivo (tabela) é definido para atender uma única aplicação. 
 2) Armazena-se em separado toda as informações referentes à forma como os dados foram estruturados e onde 
eles estão armazenados fisicamente. 
 3) Há separação entre programas e dados. No SGBD os acessos são escritos no banco de dados e os programas 
enviam comandos solicitando o acesso aos dados. Esse conceito é chamado de abstração de dados, que se caracteriza 
por uma independência entre programas e dados e entre programas e operações de manipulação de dados. 
 4) Existem uma única visão da mesma base de dados. 
 5) O acesso aos dados é único para cada usuário. 
 3 
 5. 
 Marque V (Verdadeiro) ou F (Falso) nas afirmativas abaixo: 
 
 ( ) Gradativamente, dados e processos foram separados. Em um primeiro momento, as ferramentas que surgiam 
mantinham as funções básicas de criação e manipulação dos dados independentes das aplicações. Em um segundo 
momento, as funções de criação e gerenciamento dos dados foram transferidas totalemente para os SGBDs. 
 ( ) Devido ao surgimento das redes de computadores e com a possibilidade de conexão entre diversas máquinas 
com alto poder de processamento, o banco de dados pôde ser deslocado para uma máquina específica, o servidor 
de arquivos. Programas e SGBD , então, podem funcionar em uma ou várias das outras máquinas da rede. 
 ( ) Os bancos de dados cresceram em volume de dados e as redes se tornaram quase ilimitadas em tamanho. Para 
garantir a eficiência nestes ambientes, surgiu a necessidade de distribuição da própria base de dados. 
 ( ) Os bancos de dados distribuídos representam a divisão do banco de dados por vários servidores de bancos de 
dados. 
( ) Datawarehouses são bancos de dados que atendem ao nível estratégico das empresas. 
 
 1) V,F,F,V,V 
 2) V,V,V,V,V 
 3) F,V,V,F,V 
 4) F,V,V,V,F 
 5) V,V,F,V,V 
 2 
 O SGBD e suas funcionalidades 
1. Aprender as principais características dos SGBDs. 
2. Aprender quando empregar e quando não empregar bancos de dados. 
3. Conhecer conceitos fundamentais de um ambiente com SGBD. 
 
 
Controle de Redundância 
“Redundância é armazenar o mesmo dado várias vezes, para atender diversas aplicações. Para manter a consistência 
do banco de dados, deve-se armazenar o dado uma única vez e em apenas um lugar, no banco de dados. Isto 
permite manter a consistência, economizar espaço de armazenamento.” 
” Em alguns casos, a redundância é necessária, porém ela deve ser controlada pelo sistema de gerenciamento de 
banco de dados. “(Elmasri & Navathe, 2005) 
“É um conceito representado pelo controle centralizado dos dados compartilhados por diversas aplicações, 
reduzindo a repetição de dados a um mínimo justificável e aceita apenas por questão de desempenho.” (Cerícola, 
1991) 
Problemas Da Redundância De Dados: 
 
Compartilhamento de Dados 
Permitir, a usuários diferentes, a utilização simultânea de um mesmo dado. 
As informações sobre clientes podem ser acessadas pelo sistema de vendas,de contas a receber e faturamento 
simultaneamente. 
A mesma base de dados sobre empregados pode ser usada simultaneamente pelo sistema de recursos humanos e 
pelo sistema de vendas. No primeiro caso, os dados serão utilizados no processo de pagamento e no segundo, no 
processo de alocação dos vendedores às áreas de atendimento a cliente. 
 
 
 
Mecanismos de Backup e Recuperação 
“Um SGBD deve prover facilidades para recuperação de falhas do hardware ou software.” 
 Estes mecanismos evitam que cada aplicação tenha que projetar e desenvolver seus próprios controles contra a 
perda de dados. Exemplo: 
 Se o sistema falha no meio de um programa de alteração complexo, o mecanismo de recuperação é responsável por 
assegurar que o banco de dados será restaurado para o estágio que ele se encontrava antes do início da execução do 
programa. 
Múltiplas Interfaces 
Um ambiente de banco de dados é acessado por variados tipos de usuários, com variadas necessidades de 
informação e com diferentes níveis de conhecimento técnico. Para atender esta diversidade usuários, o SGBD deva 
fornecer diferentes tipos de interfaces. Sendo assim ,este ambiente disponibiliza: 
 
Benefícios no Uso de SGBDs 
Os ambientes de bancos de dados fornecem uma série de vantagens na sua adoção: 
1- Potencial para o estabelecimento e o cumprimento de padrões; 
2- Flexibilidade de mudanças; 
3- Redução no tempo de desenvolvimento de novas aplicações; 
4- Disponibilidade de informação atualizada; 
5- Economia de escala. 
Bancos de dados NÃO são sempre a solução!!! 
Apesar das vantagens de utilização, a escolha por uma ambiente de banco de dados tem um alto custo atrelado. A 
sua adoção deve, então, compensar ou ser compatível com este custo. 
Sobrecustos vinculados 
- Alto investimento inicial em software, pela aquisição do banco de dados e licenças, e em hardware que suporte 
este ambiente. 
- Custo da generalidade do SGBD, ou seja, na definição e no processamento dos dados. 
- “Overhead” de processamento. Neste ambiente, overhead significa tudo aquilo que o SGBD tem que fazer além de 
gerenciar os dados. Isto envolve tarefas, tais como: garantir segurança, controlar concorrência (utilização do mesmo 
dado por aplicações e usuários distintos simultaneamente), recuperação de falhas e garantia de integridade. 
 
Quando NÃO usar bancos de dados 
 - Volume de dados pequeno, aplicações simples, bem definidas. 
 - Mudanças não são esperadas. 
 - Ambientes de sistemas que exijam resposta em tempo real. 
 - Acessos múltiplos e concorrentes não são necessários. 
Nesta aula, você: 
 Aprendeu as principais funcionalidades dos SGBDs. 
 Aprendeu quando empregar e quando não empregar bancos de dados. 
 Aprendeu conceitos fundamentais de um ambiente de SGBDs. 
 
1. 
 É uma funcionalidade fornecida por um SGBD, EXCETO: 
 1) independência de Dados; 
 2) aplicação de Redundância; 
 3) compartilhamento de Dados; 
 4) restrições de Integridade; 
 5) múltiplas Interfaces. 
 2 
 2. 
 Bancos de dados devem ser utilizados quando: 
 1) volume de dados pequeno, aplicações simples, bem definidas; 
 2) mudanças não são esperadas; 
 3) ambientes de grande volume de dados e acessível por muitos usuários; 
 4) ambientes de sistemas que exijam resposta em tempo real; 
 5) acessos múltiplos e concorrentes não são necessários. 
 3 
 3. 
 São problemas causados pela redundância de dados, EXCETO: 
 1) duplicação de esforço para manter os dados atualizados; 
 2) facilidade de manipulação dos dados; 
 3) desperdício de espaço de armazenamento; 
 4) possibilidade de inconsistência dos dados; 
 5) dificuldade de manipulação dos dados. 
 2 
 4. 
 Não devemos utilizar bancos de dados quando: 
 1) existe a possibilidade de acesso de múltiplos usuários; 
 2) existe alto grau de concorrência entre as aplicações disponíveis no ambiente; 
 3) aplicações complexas, com grande volume de dados; 
 4) se trata de um sistema de tempo real; 
 5) os processo são modificados com freqüência. 
 4 
 5. 
 Não é um sobrecusto vinculado ao overhead de processamento em um ambiente de banco de dados: 
 1) garantia da segurança dos dados; 
 2) controle de concorrência; 
 3) especificação do modelo; 
 4) recuperação de falhas; 
 5) garantia de integridade dos dados. 
 3 
Aula 3: Modelagem Conceitual – Percepção do Mundo Real 
Nesta aula, você irá: 
 
1. Conhecer a arquitetura de 3 esquemas (conceitual, lógico e físico). 
 
2. Aprender o conceito e o processo de abstração de dados. 
 
3. Identificar os principais objetos conceituais (entidades, relacionamentos e atributos). 
 
4. Conhecer as representações básicas destes objetos conceituais. 
O projeto de um banco de dados envolve a produção de 3 modelos que definem uma arquitetura de 3 esquemas 
(conceitual, lógico e físico). 
Na fase inicial do processo, o mundo real ou mini-mundo deve ser entendido e seus objetos conceituais 
identificados. A este entendimento e identificação chamamos abstração de dados e o modelo produzido após esta 
fase chamamos modelo conceitual. Após a sua confecção e pela a aplicação de regras específicas, um modelo lógico 
é produzido. Este modelo está vinculado ao modelo de dados adotado pelo SGBD. Na etapa final, o modelo lógico dá 
origem ao modelo físico, efetivamente armazenado no banco de dados. 
 
Percepção do Mundo Real 
Toda realidade é, em princípio, bastante nebulosa e informal. Através da observação podemos extrair desta 
realidade fatos que nos levam a conhecê-la de uma forma mais organizada. Em um negócio, existem fatos que, 
observados e modelados, dizem algo a respeito do funcionamento deste negócio. Estes fatos estão ligados 
diretamente ao funcionamento da realidade, a qual temos interesse em compreender e manter. Para que possamos 
retratar estes fatos e que os mesmos possam nos levar a futuras decisões e ações, se faz necessário então registrá-
los. Este registro é feito através da criação de um MODELO, isto é, algo que nos mostre como as informações estão 
relacionadas. 
Ao coletar e relacionar os fatos relevantes, devemos identificar os elementos geradores de informação, as leis que 
regem esta realidade, bem como as operações que incidem sobre os elementos básicos (dados). O que se quer criar 
é uma ABSTRAÇÃO da realidade, que seja capaz de registrar os acontecimentos da mesma, de modo que se possa 
implementar um sistema automatizado que atenda às reais necessidades de informação. 
 
Elementos de Abstração 
Minimundo: Porção específica da realidade, captada pelo analista, objeto de observação detalhada. Caso a análise 
do minimundo torne-se muito complexa, o analista pode subdividi-lo em pontos menores, chamados de “visões”. 
Banco de Dados: Coleção de fatos registrados que refletem certos aspectos de interesse do mundo real. Cada 
mudança, em algum item do banco de dados, reflete uma mudança ocorrida na realidade. 
Modelo Conceitual: Representa e/ou descreve a realidade do ambiente, constituindo uma visão global dos principais 
dados e relacionamentos (estruturas de informação), independente das restrições de implementação. Descreve as 
informações contidas em uma realidade, as quais irão estar armazenadas em um banco de dados. 
Modelo Lógico: Descreve as estruturas que estarão contidas no banco de dados, considerando o modelo de dados 
do Sistema Gerenciador de Banco de Dados (SGBD), resultando em um esquema lógico de dados. Tem seu início a 
partir do Modelo Conceitual. 
Modelo Físico: Descreve as estruturas físicas de armazenamento de dados, tais como: tamanho dos campos, índices, 
tipo de preenchimento destes campos, etc... Tem origem no Modelo Lógico e detalha o estudo dos métodos de 
acesso ao SGBD. 
O Projeto do Banco de Dados 
Todo projeto de um sistema de aplicação para banco de dados necessita de um coração, um centro nervoso do 
mesmo. A modelagem de um sistema atravésda abordagem Entidades-Relacionamentos representa este ponto 
central no projeto conceitual de um sistema. 
 
O objetivo da Modelagem de Dados é transmitir e apresentar uma representação única, não redundante e resumida, 
dos dados de uma aplicação. Em projetos conceituais de aplicação, em banco de dados, o Modelo Entidades-
Relacionamentos é o mais largamente utilizado para representação e entendimento dos dados que compõe um 
sistema. 
Desenvolvida na década de 70, possui paternidade discutível: Charles Bachman, James Martin, Peter Chen e outros. 
É de Peter Chen o rótulo MER (Modelo Entidades-Relacionamentos) que se transformou em, praticamente, sinônimo 
da técnica de Modelagem de Dados. 
Um Modelo de Dados é uma forma de representação gráfica do conhecimento que se tem sobre um ambiente 
qualquer. Mostra uma visão das informações de interesse e dos vínculos existentes entre elas, em um determinado 
momento. Quando Peter Chen formulou a proposta do Modelo Entidades-Relacionamentos , baseou-se na 
compreensão da realidade em que se situava o problema. Como iremos projetar um sistema se não entendemos o 
negócio para o qual será realizado? Chen dedicou-se a destacar a importância de reconhecer os objetos que 
compõem este negócio, independentemente das formas de tratamento das informações, procedimentos, programas 
etc. Estes objetos que desejamos conhecer e modelar foram classificados em dois grupos: Entidades e 
Relacionamentos. 
A imagem seguinte representa um fato comum que pode ser representado através dos elementos básicos que 
compõem o Modelo Entidades-Relacionamentos: 
 
ENTIDADES 
Define-se Entidade como aquele objeto que existe no mundo real, com identificação distinta e com um significado 
próprio. São as “coisas” que existem no negócio, ou ainda, descrevem o negócio em si. A representação de uma 
entidade no MER é feita através de um retângulo, com o nome da entidade em seu interior. 
ATRIBUTOS 
Todo objeto para ser uma entidade possui propriedades que são descritas por atributos e valores. Estes atributos e 
valores, juntos, descrevem as instâncias de uma entidade. O que descreve CLIENTE ? Cliente é descrito por um 
código de identificação, nome, endereço, telefone de contato, CGC ou CPF etc. A representação de um atributo no 
MER é feita através de uma elipse com o nome do atributo em seu interior. 
 
 
Relacionamentos 
Um relacionamento é uma associação entre duas entidades cujo significado seja de interesse para a realidade 
analisada. Os relacionamentos estão intimamente ligados às ações realizadas pelos processos sobre os dados e 
representam os caminhos de navegação ou rotas de acesso do Modelo de Dados. Existem várias formas de se 
representar graficamente um relacionamento, Por exemplo, Peter Chen utiliza um losango para desenhar uma 
associação entre entidades, outros autores a representam através de um traço unindo as entidades. 
 
EXERCÍCIO 
Identifique as entidades, atributos e relacionamentos existentes no mini mundo descrito a seguir: 
 Suponha que estamos fazendo a análise de dados da área de Recursos Humanos da empresa ABC e tenhamos 
obtido as seguintes informações: 
 “Cada funcionário é lotado em um departamento e tem um cargo de carreira. Para o cadastramento do funcionário. 
são registrados: nome, endereço, telefone, cargo, departamento, salário, horário, filiação, idade, CPF, identidade e 
nacionalidade. Para cada dependente do funcionário, são registrados: nome, idade, parentesco e sexo. Para cada 
departamento, deseja-se saber: nome, sigla, nome do chefe, número de funcionários. Para cada cargo, deseja-se 
saber: nome, sigla e salário base. 
Sabemos, também, que não é armazenado o histórico de cargos dos funcionários e que nem todos os funcionários 
possuem dependentes e que, também, caso um funcionário seja casado com outro funcionário, o dependente 
oficialmente pertencerá a apenas um deles. Podemos ter departamentos momentaneamente sem nenhum 
funcionário.” 
 
Nesta aula, você: 
 Foi apresentado a arquitetura de 3 esquemas. 
 Aprendeu sobre o conceito e o processo de abstração de dados. 
 Aprendeu a identificar os principais objetos conceituais (entidades, relacionamentos e atributos). 
 Conheceu as representações básicas destes objetos conceituais. 
Na próxima aula: 
 Apresentar em detalhes o Modelo ou Diagrama de Entidades e Relacionamentos 
 Representação de Entidades. 
 Representação de Atributos. 
 Representação de Relacionamentos. 
 
1. 
 O modelo que descreve as estruturas que estarão contidas no banco de dados, sem considerar nenhuma característica 
específica de um SGBD é: 
 1) modelo lógico; 
 2) modelo conceitual; 
 3) modelo físico; 
 4) modelo de dados; 
 5) modelo essencial. 
 2 
 2. 
 No processo de ____________ de dados, são identificadas as relações entre os elementos dos dados. Cada modelo de 
dados define as relações lógicas entre os elementos dos dados para apoiar um processo empresarial. 
 1) levantamento de requisitos; 
 2) análise de dados; 
 3) abstração de dados; 
 4) modelagem de dados; 
 5) coleta de dados 
 3 
 3. 
 Um(a)_________________________ é um modelo utilizado para representar as relações entre as muitas entidades 
envolvidas nos processos empresariais. 
 1) dado; 
 2) Informação; 
 3) entidade; 
 4) atributo; 
 5) relacionamento. 
 5 
 4. 
 Um(a)_________________________ representa uma característica de uma entidade. 
 1) dado; 
 2) informação; 
 3) entidade; 
 4) atributo; 
 5) relacionamento. 
 4 
 5. 
 Um(a)_________________________ é um conjunto de atributos. 
 1) dado; 
 2) informação; 
 3) entidade; 
 4) atributo; 
 5) relacionamento; 
 3 
 
Nesta aula, você será capaz de: 
 
1. Aprofundar seus conhecimentos sobre o Modelo Entidade Relacionamento. 
2. Aprender a identificar os principais objetos conceituais. 
3. Aprender a criar um modelo para o negócio. 
Modelagem Conceitual - Modelo Entidade Relacionamento 
Agora que já conhecemos os objetos conceituais que compõem o modelo entidade relacionamento, podemos 
detalhá-los um pouco mais. 
Mais Sobre Entidades ... 
Entidades podem ser tangíveis: Pessoas, Edifícios. 
Entidades podem ser intangíveis: Setor, Reserva de um vôo. 
Entidades fraca: Não existe, se não estiver relacionada a outra, isto é, ela é logicamente dependente da outra. Por 
exemplo, um apartamento dentro de um edifício, um dependente em relação a um funcionário em uma empresa. 
Mais Sobre Atributos ... 
Atributos Compostos: Exemplo: Endereço é formado pelos atributos: rua, bairro, cidade, estado, CEP. 
Atributos Simples ou Atômicos: Atributos que não são divisíveis em unidades dados mais simples. Exemplo: data de 
nascimento, numero de fatura, valor total de venda. 
Domínios de um atributo: Descrição de possíveis valores permitidos para um atributo. Exemplo: domínio do atributo 
cor de peça: azul, amarelo, verde, vermelho, branco. 
Valores nulos: Atributo sem valor. Um valor nulo pode ocorrer quando o atributo não é relevante para descrever 
uma entidade em particular. 
Atributos identificadores: Atributos que identifica, de forma única, as instâncias de uma entidade.Exemplo: uma 
matrícula identifica um aluno e um CPF identifica um cliente. 
Modelando O Negócio 
Em um primeiro contato com o negócio de uma empresa, podemos não possuir o conhecimento necessário sobre o 
mesmo. Portanto, é fundamental que procuremos conhecer seus objetos principais. Ao descrevermos textualmente 
a realidade analisada, as entidades podem ser identificadas por similaridade com a análise sintática das linguagens 
naturais. Nesse caso, algumas regras podem ser aplicadas: o sujeito e o objeto da sentença são, provavelmente, 
entidades; os verbos podem sugerir relacionamentos, por exemplo: 
“Um país participa das Olimpíadas” 
A frase sugere de imediato a garimpagem de PAÍS e OLIMPÍADAS como entidadese o verbo “PARTICIPA” como o 
relacionamento entre elas. Nos relacionamentos entre objetos de diferentes tipos, associamos instâncias de um 
objeto de um tipo a outras de outro tipo. 
Exemplo: 
O relacionamento entre PESSOA e VEICULO com a finalidade de expressar o conceito de propriedade. 
 Assim, se desejamos ter, conceitualmente, representado um ambiente observado onde “joão é proprietário de um 
jipe amarelo”, poderemos nos valer da seguinte estratégia: 
1 - Identificar os objetos envolvidos 
Pessoa, com a instância “João”. Veículo, com a instância “jipe”. 
2 - Caracterizar os objetos: 
Pessoa: Caracterizado por: nome, data de nascimento, sexo, CPF; 
Veículo: Caracterizado por: marca cor, ano de fabricação, número do chassis; 
3 - Representar os objetos: 
PESSOA - VEÍCULO 
4- Identificar o relacionamento entre os objetos: 
PESSOA é proprietária de VEÍCULO. 
5 - Caracterizar o relacionamento entre os objetos: 
1 - Nem toda PESSOA é proprietária de um VEÍCULO. 
2 - Um VEÍCULO pode pertencer a uma PESSOA ou não. 
3 - Algumas PESSOA possuem mais de um VEÍCULO. 
4 - Se um VEÍCULO pertence a uma PESSOA, ele não pertence a mais ninguém. 
6 - Representar o relacionamento 
 
Este processo pode ser utilizado para mapear qualquer relacionamento entre dois, ou mais tipos de objetos e, 
também, entre os mesmos objetos. Assim, se necessitamos expandir nosso modelo representando também as 
observações: 
Um VEICULO é de propriedade de uma PESSOA, mas pode ser utilizado por diversas PESSOAS para locomoção; 
Uma PESSOA utiliza um IMÓVEL para morar. 
Teríamos que repetir os passos de 1 a 6 para cada nova observação. 
1 - Identificar os objetos envolvidos 
2- Caracterizar os objetos: PESSOA: Caracterizado por: nome, data de nascimento, sexo, CPF; 
2.1 – Identificar os atributos identificadores dos objetos: PESSOA: CPF; 
3 –Representar os objetos: “PESSOA” 
4 – Identificar os novos relacionamentos entre os objetos: 
 
5 – Caracterizar o relacionamento entre os objetos: 
1 - Nem toda PESSOA utiliza um VEICULO. 
2 - Um VEICULO pode ser utilizado por mais de uma PESSOA. 
3 - Algumas PESSOA utilizam mais de um VEICULO. 
4 - Um VEICULO sempre será utilizado por, pelo menos, uma PESSOA. 
5 - Toda PESSOA utiliza um, e somente um, IMOVEL para morar. 
6 - Um IMOVEL pode ser utilizado por uma ou mais PESSOA. 
7 - Um IMOVEL nem sempre é utilizado por uma PESSOA. 
6 – Representar os relacionamentos: 
 
Exercício 
Construa o Modelo Entidades-Relacionamentos para o mini-mundo descrito a seguir: 
 Suponha que estamos fazendo a análise de dados da área de Recursos Humanos da empresa ABC e tenhamos 
obtido as seguintes informações: 
“Cada funcionário é lotado em um departamento e tem um cargo de carreira. Para o cadastramento do funcionário 
são registrados: nome, endereço, telefone, cargo, departamento, salário, horário, filiação, idade, CPF, identidade e 
nacionalidade. Para cada dependente do funcionário são registrados: nome, idade, parentesco e sexo. Para cada 
departamento deseja-se saber: nome, sigla, nome do chefe, número de funcionários. Para cada cargo deseja-se 
saber: nome, sigla e salário base. 
Sabemos, também, que não é armazenado o histórico de cargos dos funcionários e que nem todos os funcionários 
possuem dependentes e que, também, caso um funcionário seja casado com outro funcionário, o dependente 
oficialmente pertencerá a apenas um deles. Podemos ter departamentos momentaneamente sem nenhum 
funcionário.” 
Nesta aula, você: 
 Aumentou seus conhecimentos sobre o Modelo Entidade Relacionamento. 
 Aprendeu a identificar os principais objetos conceituais. 
 Aprendeu a criar um modelo para o negócio. 
Na próxima aula: 
 Definir e exemplificar o conceito de cardinalidade. 
 Apresentar possibilidades e critérios para nomear os relacionamentos. 
 Apresentar e exemplificar limites mínimos e máximos. 
 Apresentar e exemplificar os relacionamentos recursivos. 
 Discutir sobre atributos em relacionamentos. 
 
1. 
 Pode ser um exemplo de atributo composto: 
 1) nome completo de uma pessoa; 
 2) sigla de um estado; 
 3) marca de um carro; 
 4) matrícula de aluno; 
 5) CEP de uma residência. 
 1 
 2. 
 Não é exemplo de entidade: 
 1) aluno; 
 2) curso; 
 3) professor; 
 4) nome do aluno; 
 5) cliente. 
 4 
 3. 
 Descreve um relacionamento: 
 1) um departamento; 
 2) um carro; 
 3) uma matrícula; 
 4) um cliente; 
 5) um professor. 
 3 
 4. 
 Não pode ser um atributo identificador: 
 1) o nome de um cliente; 
 2) a matrícula de um aluno; 
 3) o CRM de um médico; 
 4) o CPF de professor; 
 5) a placa de um carro. 
 1 
 5. 
 Coloque em ordem os principais passos do processo para a criação do modelo conceitual de dados. 
 ( ) Identificar os relacionamentos entre os objetos ou entidades. 
( ) Identificar e caracterizar os objetos ou entidades do problema. 
( ) Representar os relacionamentos. 
( ) Representar os objetos ou entidades. 
( ) Identificar atributos identificadores. 
 1) 2, 1, 3, 4, 5 
 2) 4, 1, 3, 2, 5 
 3) 5, 4, 2, 3, 1 
 4) 4, 1, 5, 3, 2 
 5) 2, 1, 5, 4, 3 
 4 
Aula 5: Modelagem Conceitual – Mais Sobre Relacionamentos 
Nesta aula, você irá: 
 
1. Definir e exemplificar o conceitos de cardinalidade. 
2. Conhecer as possibilidades e critérios para nomear os relacionamentos. 
3. Aprender sobre limites mínimos e máximos. 
4. Aprender sobre relacionamentos recursivos. 
5. Aprender sobre atributos em relacionamentos. 
Uma relação entre duas entidades pode ser descrita em termos da sua cardinalidade. 
Um para Um 1:1 - Um empregado pode ser atribuído a um carro. Um carro pertence a um empregado. 
Um para Muitos 1:N - Um cliente pode tomar emprestado vários DVDs de vídeo. Cada DVD só pode ser emprestado 
a um cliente (por vez). 
Muitos para Muitos N:M - Um estudante pode fazer várias disciplinas. Uma disciplina pode ser cursada por vários 
estudantes 
A cardinalidade é determinada pelas “regras de negócio” criadas pela organização. São os usuários e a 
documentação da organização que determinam a cardinalidade existente entre entidades e seus atributos. 
CARDINALIDADE 1:1 
Cada instância de uma das entidades se relaciona com uma única instância da outra entidade do relacionamento. 
 
CARDINALIDADE 1:N 
Cada instância da entidade que representa o lado 1 do relacionamento pode se relacionar com N instâncias da 
entidade que representa o lado N. Por outro lado, cada instância da entidade representante do lado N, relaciona 
com apenas 1 instância da entidade representante do lado 1. 
 
CARDINALIDADE N:M 
Cada instância da entidade que representa o lado N do relacionamento pode se relacionar com M instâncias da 
entidade que representa o lado M. O mesmo acontece quando o relacionamento é analisado no sentido oposto. 
 
Escolhendo Nomes Para Os Relacionamentos 
Relações podem ser nomeadas por verbos ou palavras agregadas, como nos exemplos abaixo: 
 
AS RELAÇÕES PODEM TER LIMITES MÍNIMOS E MÁXIMOS 
Além do grau de cardinalidade máxima, já mencionado anteriormente, podemos identificar limites mínimos para as 
cardinalidades. Por exemplo: 
 Um professor pode ensinar de 0 a 4 disciplinas (limite inferior é 0 e limite superior é 4); e um uma disciplina pode 
ser ministrada por 0 a 1 professor (limite inferior é 0 e o limite superior é 1) 
1- Quando o limite inferior da cardinalidade for 0, o relacionamento é definido como “opcional” 
2- Quando o limite inferior da cardinalidade for 1, o relacionamento é definido como “obrigatório” 
 
Relações Podem Ser Recursivas 
- Ocorre quando uma entidade possui relacionamento com ela mesma 
- Os relacionamentos recursivos podem também ter limites inferiores e superiores 
- Exemplo: Uma organização possui uma entidade "Empregado" e que guardar a informação sobre quais 
empregados são casados entre si. 
Esse é um relacionamentorecursivo 1:1 onde a entidade "Empregado" se relaciona consigo mesmo. 
 
Relacionamentos Recursivos 1:1 
 
Limites inferiores e superiores em um relacionamento 1:1 recursivo 
 
Atributos Em Relacionamentos 
Os atributos de relacionamento são possíveis quando o grau do relacionamento for N : M ( muitos para muitos) 
 
Exercício 
Identifique as cardinalidades do Modelo Entidades-Relacionamentos construído para o mini-mundo descrito a 
seguir: 
 
Suponha que estamos fazendo a análise de dados da área de Recursos Humanos da empresa ABC e tenhamos obtido 
as seguintes informações: 
 “Cada funcionário é lotado em um departamento e tem um cargo de carreira. Para o cadastramento do funcionário 
são registrados: nome, endereço, telefone, cargo, departamento, salário, horário, filiação, idade, CPF, identidade e 
nacionalidade. Para cada dependente do funcionário são registrados: nome, idade, parentesco e sexo. Para cada 
departamento deseja-se saber: nome, sigla, nome do chefe, número de funcionários. Para cada cargo deseja-se 
saber: nome, sigla e salário base. 
Sabemos também que não é armazenado o histórico de cargos dos funcionários e que nem todos os funcionários 
possuem dependentes e que, também, caso um funcionário seja casado com outro funcionário, o dependente 
oficialmente pertencerá a apenas um deles. Podemos ter departamentos momentaneamente sem nenhum 
funcionário.” 
 
Nesta aula, você: 
 Definir e exemplificar o conceitos de cardinalidade. 
 Conhecer as possibilidades e critérios para nomear os relacionamentos. 
 Aprender sobre limites mínimos e máximos. 
 Aprender sobre relacionamentos recursivos. 
 Aprender sobre atributos em relacionamentos. 
Na próxima aula: 
 Apresentar e exemplificar o MER estendido. 
 Generalizações. 
 Agregações. 
 
 
 
 Utilize o modelo acima nos exercícios que seguem: 
 O relacionamento, onde cada instância de entidade se relaciona com um única instância da outra entidade no 
relacionamento, é:[aqui, não há concordância da resposta com o verbo do enunciado- favor rever a intenção do 
enunciado 
 1) GERA 
 2) ENVIADOS 
 3) PRODUZEM 
 4) POSSUEM 
 5) CADASTRA 
 1 
 2. 
 O relacionamento, onde cada instância de entidade se relaciona com várias instâncias da outra entidade no 
relacionamento, mas no sentido inverso a quantidade de instância é de apenas 1, é: 
 1) GERA 
 2) ENVIADOS 
 3) PRODUZEM 
 4) POSSUEM 
 5) CADASTRA 
 5 
 3. 
 A descrição do relacionamento em relação a sua cardinalidade feita de forma INCORRETA é: 
 1) Uma fabrica cadastra várias lojas que são cadastradas por uma única fábrica. 
 2) Pedidos são enviados a várias fábricas, assim como uma fábrica envia vários pedidos. 
 3) Cada pedido gera uma nota fiscal, assim como cada nota fiscal se relaciona a um pedido. 
 4) Cada tecido produz várias roupas e cada roupa possui um único tecido. 
 5) Cada fábrica produz várias roupas e cada roupa é produzida em várias fábricas. 
 4 
 4. 
 Identifique o relacionamento descrito de forma INCORRETA. 
 1) Toda roupa possui tecido. 
 2) Toda fábrica cadastra loja. 
 3) Toda loja faz pedido. 
 4) Todo pedido gera nota fiscal. 
 5) Toda roupa é produzida em um fábrica. 
 3 
 5. 
 Se desejássemos representar que cada loja cadastrada no banco de dados deve obrigatoriamente fazer, no mínimo, um 
pedido e, no máximo, vários , que alteração deveríamos fazer no modelo? 
 1) Altera a cardinalidade do lado da entidade LOJA para (0,n). 
 2) Altera a cardinalidade do lado da entidade LOJA para (1,1). 
 3) Altera a cardinalidade do lado da entidade PEDIDO para (1,n). 
 4) Altera a cardinalidade do lado da entidade LOJA para (1,1). 
 5) Nenhuma das alternativas anteriores. 
 3 
Aula 6: Modelagem Conceitual – Modelo Entidade Relacionamento Estendido 
1. Conhecer as extensões do Modelo Entidade Relacionamento 
 Generalizações. 
 Agregações. 
Modelagem Conceitual – Mer Estendido 
Os conceitos básicos do Modelo Entidade Relacionamento são suficientes para modelar grande parte dos bancos de 
dados. Entretanto, algumas extensões, introduzidas posteriormente ao seu surgimento, permitiram refinamentos 
bastante significativos. 
Estrutura de Generalização-Especialização “É-um” 
Entidades podem ter subtipos ou subclasses e supertipos ou superclasses. 
Um entidade supertipo é uma generalização de uma entidade subtipo “especializada”. 
Cada entidade subtipo herda os atributos de sua entidade supertipo. 
Cada entidade supertipo tem seus próprios atributos únicos. 
A relação entre um subtipo de entidades e seu par é referenciada por uma relação “É-um” 
Num diagrama ER um relacionamento “É-um” conecta uma entidades mais especializada a uma entidade 
generalizada [sem sentido] pode ser escrita como um triângulo invertido ou um losango com o label “É-um” 
 
Exemplo 
 
Observe que os atributos que descrevem o cliente individual, o cliente associado e o cliente corporação não são 
exatamente mesmos e são específicos de cada categoria ou classe de cliente. Os atributos de cliente, na superclasse, 
são compartilhados por todos os elementos das subclasses. Sendo assim, por exemplo, um cliente individual é 
descrito pelos atributos NúmeroCliente, NomeCliente, ValorDevido, Endereço e NúmeroIdentidade. 
Estrutura de Agregação“Faz_parte_de” 
O Modelo Entidade Relacionamento não é capaz de representar relacionamentos entre relacionamentos. Uma 
agregação é uma abstração através da qual os relacionamentos são tratados como entidades de mais alto nível 
Neste caso, a entidade Máquina se relaciona com os funcionários trabalhando em um projeto. Máquinas não se 
relacionam com funcionários e nem projetos em separado, mas sim com o relacionamento que estas entidades 
mantêm. 
 
 
Outra Representação ... 
 
Exercício 
Construa o MER para os minimundos a seguir: 
a) Em uma seguradora de automóveis, um cliente tem pelo menos um carro e um carro pertence a um 
único cliente. Cada carro possui um número de acidentes associados a ele, devendo ser 
armazenados a data, o local e uma descrição do acidente. O acidente pode ser com vítima ou sem 
vítima. Se for com vítima, devem ser armazenados um histórico (contendo os nomes das vítima e o 
tipo de lesão sofrida) e o valor gasto com indenização das vítimas. Se for sem vítima deve ser 
armazenado o valor gasto com danos morais. 
 
b) Em um hospital, um paciente pode realizar consultas com vários médicos. Cada consulta pode ter 
vários exames realizados. Devem ser armazenados os dados da consulta (data, horário e motivo) e 
os dados dos exames (descrição e resultado). 
 
c) Em uma biblioteca há vários tipos de materiais (livros, revistas e audiovisual). Para os livros são 
armazenados o autor e a editora; as revistas têm número, volume e data; os materiais audiovisuais 
têm o nome do diretor e o tempo de duração. Um cliente pode retirar vários materiais e um material 
pode ser retirado por vários clientes. Para toda retirada devem ser armazenadas a data de retirada e 
a data de devolução. 
 
Na próxima aula: 
 Apresentar a base conceitual para Modelo Relacional. 
 Introduzir os conceitos de chave: candidata, primária e estrangeira. 
 Conceituar e exemplificar as restrições de integridade. 
 
 
1. 
 Identifique a afirmação FALSA. 
 1) Entidades podem ter subtipos ou subclasses e supertipos ou superclasses. 
 2) Um entidade supertipo é uma especialização de uma entidade subtipo. 
 3) Cada entidade subtipo herda os atributos de sua entidade supertipo. 
 4) Cada entidade supertipo tem seus próprios atributos únicos. 
 5) Generalizações e especializações representam conceitos semelhantes observados sob óticas distintas. 
 2 
 2. 
 Uma agregação: 
 1) é uma abstração através da qual os relacionamentos são tratados como atributos de mais alto nível; 
 2) é uma abstração através da qual os atributos são tratados como entidades de mais altonível; 
 3) é uma abstração através da qual as entidades são tratados como atributos de mais alto nível; 
 4) é uma abstração através da qual os relacionamentos são tratados como entidades de mais alto nível; 
 5) é uma abstração através da qual as cardinalidades são tratadas como entidades de mais alto nível. 
 4 
Aula 7: Modelagem Lógica – O Modelo Relacional 
Nesta aula, você irá: 
 
1. Aprender sobre a modelagem lógica dos dados. 
2. Conhecer os modelos lógicos de dados existentes. 
3. Aprender a base conceitual para Modelo Relacional. 
4. Conhecer os conceitos de chave candidata, primária e estrangeira. 
5. Compreender as restrições de integridade. 
Modelagem Lógica De Dados 
O Modelo Lógico de Dados Lógico descreve os componentes do Modelo Conceitual de Dados, aproximando-o do 
ambiente computacional, onde este será trabalhado. Existem vários modelos de dados: 
Modelo de Rede: Os dados são representados por uma coleção de registros e os relacionamentos entre os dados são 
representados por meio de links. 
Modelo Hierárquico: Apresenta a mesma estrutura do modelo de rede, diferindo apenas na organização dos 
registros. Tais registros são organizados com coleções de árvores em vez de grafos aleatórios. 
Modelo Relacional: Os dados são representados através de tabelas. Por se tratar do modelo mais usual, é o foco 
deste curso. Iremos detalhá-lo mais adiante. 
Modelo Orientado a Objetos: Surgiu em virtude da necessidade de se acompanhar o aumento na complexidade dos 
dados. Quando o modelo relacional foi sugerido, dados como imagens ou som não foram considerados na sua 
estrutura. Atualmente, dados deste tipo são bastante comuns, até mesmo nas aplicações mais simples e o modelo 
relacional não é suficiente para este tipo de modelagem. De modeo geral, no modelo orientado a objeto as 
entidades do modelo conceitual são objetos que encapsulam tanto dados quanto o código associado a este objeto. 
Modelo Relacional Objeto: Um extensão do modelo relacional, que inclui orientação a objeto e permite o 
tratamento de dados complexos. 
 
 
 
 
 
Chave Candidata 
 Deve ser única, ou seja, nenhuma tupla de uma mesma relação, pode ter o mesmo valor para o atributo escolhido 
como chave candidata 
Deve ser irredutível, nenhum subconjunto da chave candidata, pode ter sozinho a propriedade de ser único. 
Pode ser : 
Simples : quando é composta por apenas um atributo 
Composta : quanto possui mais de um atributo para formar a chave 
Chave primária 
 É um caso especial da chave candidata. É a escolhida entre as candidatas para identificar unicamente uma tupla. 
Chave estrangeira 
 É quando um atributo de uma relação é chave primária em outra. 
Constitui um conceito de vital importância no modelo relacional: é o elo de ligação lógica entre as tabelas 
(relacionamentos) 
Através das operações com as chaves estrangeiras que se garante a INTEGRIDADE REFERENCIAL do banco de dados. 
 
 
Regras de Integridade 
Regras que devem ser obedecidas em todos os estados válidos da base de dados (podem envolver uma ou mais 
linhas de uma ou mais tabelas). 
Integridade da Entidade 
O valor da chave não pode ser vazio. 
A chave primária serve como representante na base de dados de uma entidade – se a chave primária for vazia, a 
linha não corresponde a nenhuma entidade . 
Integridade de Chave Primária 
A chave primária tem que ser única. 
Integridade Referencial 
As chaves estrangeiras têm que ser respeitadas, ou seja, se existe um determinado valor para o atributo na tabela 
onde ele é chave estrangeira, este valor deve existir na tabela onde ele é chave primária 
Restrições de Integridades Semânticas 
Todas as demais regras que devem ser obedecidas por todos os estados válidos da base de dados. 
Nesta aula, você: 
 Aprendeu sobre os modelos lógicos de dados. 
 Conheceu a base conceitual para o Modelo Relacional. 
 Foi apresentado aos conceitos de chave candidata, primária e estrangeira. 
 Conheceu as restrições de integridade. 
 
 
 
 
 
1. 
 O modelo de dados representa: 
 1) a visão dos usuários. 
 2) os conceitos do mini-mundo em questão. 
 3) elementos do modelo conceitual, de forma que estes possam ser manipulados por um computador. 
 4) o meio de armazenamento dos dados. 
 5) não faz parte do projeto de um banco de dados. 
 3 
2. 
 No modelo de dados relacional, os dados são representados por meio de: 
 1) matrizes tridimensionais. 
 2) listas. 
 3) tabelas. 
 4) vetores. 
 5) ponteiros. 
 3 
3. 
 Analise as seguintes assertivas, relativas ao conceito de chave primária: 
i. Pode ser composta por um ou vários atributos. 
ii. Não admite duplicidade de valores, exceto no caso de valores nulos. 
iii. Deve ser definida durante a construção do modelo de E-R. 
Marque a alternativa correta (apenas uma opção). 
 1) Apenas as assertivas I e III são corretas. 
 2) Apenas as assertivas I e II são corretas. 
 3) Apenas as assertivas II e III são corretas. 
 4) As assertivas II e III são falsas. 
 5) Todas as assertivas são corretas. 
 4 
4. 
 Trata-se da restrição de integridade da ENTIDADE: 
 1) A chave primária deve ser única. 
 2) O valor da chave não pode ser vazio. 
 3) Deve existir uma chave. 
 4) A chave deve ser nula. 
 5) Nenhuma das opções acima. 
 2 
 
5. 
 Trata-se da restrição de integridade da CHAVE PRIMÁRIA: 
 1) O valor da chave não pode ser vazio. 
 2) Deve existir uma chave. 
 3) A chave deve ser nula. 
 4) A chave primária deve ser única. 
 5) Nenhuma das opções acima. 
 4 
Aula 8: Modelagem Lógica – O Modelo Relacional 
1. Aprender um método de conversão do modelo conceitual para o modelo relacional. 
Regras simples, baseadas na cardinalidade dos relacionamentos, são aplicadas para converter entidades e 
relacionamentos em tabelas relacionais. 
Nesta aula conheceremos essas regras. 
Convertendo o diagrama ER para tabelas relacionais 
Em cada entidade onde o limite inferior para a cardinalidade é 0 e o limite superior é 1, temporariamente classifique 
o limite superior como N. 
 A partir destas alterações, aplique as regras a seguir, observando apenas os valores máximos para as cardinalidades: 
Para cardinalidade 1:1 
Incluir todos os atributos numa tabela simples. O nome da tabela relacional pode ser o nome de uma das entidades 
que participam do relacionamento, um nome composto formado pela combinação dos nomes das duas entidades ou 
um novo nome que represente o significado dos dados na tabela. 
 
 
 
Para cardinalidade 1:N 
Incluir o “identificador” do lado “um”, como um atributo no lado “muitos”. O identificador colocado do lado 
“muitos” é chamado de chave estrangeira. 
 
Para cardinalidade N:M 
Criar uma nova tabela e colocar as chaves primárias de cada uma das entidades como atributos na nova tabela. A 
nova tabela é chamada de tabela associativa. O identificador da tabela é uma chave composta, formada pelas 
chaves primárias das duas tabelas que participam do relacionamento. Cada identificador colocado na nova tabela é 
uma chave estrangeira. 
 
 
 
Exercício - Converta o modelo relacional para tabelas relacionais. 
 
Nesta aula, você: 
 Aprendeu um método para conversão do modelo conceitual em tabelas relacionais. 
 
 
1. 
 O processo de conversão do modelo conceitual para o modelo relacional de um relacionamento 1:1 gera: 
 1) duas tabelas, sendo que a tabela que representa o lado N herda a chave primária da tabela que representa a entidade 
do lado 1, como chave estrangeira. 
 2) uma tabela contendo os atributos das duas entidades que participam do relacionamento. 
 3) três tabelas, sendo uma para cada entidade e uma para o relacionamento. Essa última é denominada tabela 
associativa. 
 4) mais do que 3 tabelas. 
 5) nenhuma tabela. Não é possível fazer a conversão. 
 2 
2. 
 O processo de conversão do modelo conceitual para o modelo relacional de um relacionamento N:Ngera: 
 1) duas tabelas, sendo que a tabela que representa o lado N herda a chave primária da tabela que representa a entidade 
do lado 1, como chave estrangeira. 
 2) uma tabela contendo os atributos das duas entidades que participam do relacionamento. 
 3) três tabelas, sendo uma para cada entidade e uma para o relacionamento. Esta última é denominada tabela 
associativa. 
 4) mais do que 3 tabelas. 
 5) nenhuma tabela. Não é possível fazer a conversão. 
 3 
3. 
 O processo de conversão do modelo conceitual para o modelo relacional de um relacionamento 1:N gera: 
 1) duas tabelas, sendo que a tabela que representa o lado N herda a chave primária da tabela que representa a 
entidade do lado 1, como chave estrangeira. 
 2) uma tabela contendo os atributos das duas entidades que participam do relacionamento. 
 3) três tabelas, sendo uma para cada entidade e uma para o relacionamento. Esta última é denominada tabela 
associativa. 
 4) mais do que 3 tabelas. 
 5) nenhuma tabela. Não é possível fazer a conversão. 
 1 
 
 
 
 
Aula 9: Modelagem Lógica - Relacionamentos Recursivos e Extensões 
Aprender o método de conversão do modelo conceitual para o relacional. 
 
Relacionamentos Recursivos 
No exemplo, o atributo matricula é duplicado na tabela casado_com, para representar a matrícula do marido e de 
sua esposa. 
 
Novamente, o atributo que representa a matrícula foi duplicado para representar o supervisor e o supervisionado. 
 
 
Generalizações 
 
Agregações 
 
 
 
 
 
 
 
 
Relacionamentos n-ários 
 
Nesta aula, você: 
 Aprendeu um método para conversão do modelo conceitual em tabelas relacionais para os relacionamentos 
recursivos, as generalizações, as agregações e os relacionamentos n-ários. 
 
Na próxima aula: 
 
Apresentar o conceito de normalização. 
 Apresentar e exemplificar a 1ª forma normal. 
 Apresentar e exemplificar a 2ª forma normal. 
 Apresentar e exemplificar a 3ª forma normal. 
 Apresentar e exemplificar a forma normal de Boyce-Codd. 
 
 
 
 
 
 
 
 
 
 
1. 
 O processo de conversão do modelo conceitual para o modelo relacional de um relacionamento recursivo 1:1 gera: 
 1) duas tabelas, sendo que a tabela que representa o lado N herda a chave primária da tabela, que representa a entidade 
do lado 1 como chave estrangeira. 
 2) uma tabela, contendo os atributos das duas entidades que participam do relacionamento, sendo que a chave 
primária é duplicada para possibilitar a existência duas instâncias da tabela. 
 3) três tabelas, sendo uma para cada entidade e uma para o relacionamento. Essa última é denominada tabela 
associativa. 
 4) mais do que 3 tabelas. 
 5) nenhuma tabela. Não é possível fazer a conversão. 
 2 
2. 
 O processo de conversão do modelo conceitual para o modelo relacional de um relacionamento recursivo N:N gera: 
 1) duas tabelas, sendo que a tabela que representa o lado N herda a chave primária da tabela, que representa a entidade 
do lado 1 como chave estrangeira. 
 2) uma tabela contendo os atributos das duas entidades que participam do relacionamento. 
 3) três tabelas, sendo uma para cada entidade e uma para o relacionamento. Essa última é denominada tabela 
associativa. Nessa tabela, a chave primária é duplicada para possibilitar a existência duas instâncias. 
 4) mais do que 3 tabelas. 
 5) nenhuma tabela. Não é possível fazer a conversão. 
 3 
3. 
 O processo de conversão do modelo conceitual para o modelo relacional de uma generalização gera: 
 1) duas tabelas, sendo que a tabela que representa o lado N herda a chave primária da tabela, que representa a entidade 
do lado 1 como chave estrangeira. 
 2) uma tabela, contendo os atributos das duas entidades que participam do relacionamento. 
 3) três tabelas, sendo uma para cada entidade e uma para o relacionamento. Essa última é denominada tabela 
associativa. 
 4) depende do tipo da generalização 
 5) nenhuma tabela. Não é possível fazer a conversão. 
 4 
Aula 10: Modelagem Lógica – Normalização 
Normalização 
O processo de normalização de dados representa uma série de passos que se seguem no projeto de um banco de 
dados, que permitem um armazenamento consistente e o eficiente acesso aos dados de um banco de dados 
relacional. Esses passos reduzem a redundância de dados e, consequentemente, as chances de ocorrerem 
inconsistências. 
Características de um mau projeto 
 
 
 
 
 
 
Dependência funcional 
Determina um restrição entre dois conjuntos de atributos de um BD Relacional. 
Denotado pelo símbolo  , onde X  Y significa o atributo X determina funcionalmente o atributo Y ou ainda, 
o atributo Y é dependente funcional do atributo X. 
 
Formas normais 
O conceito de normalização foi introduzido por E. F. Codd em 1972. Inicialmente, Codd criou as três primeiras 
formas de normalização, chamando-as de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira 
forma normal (3NF). 
Uma definição mais forte da 3NF foi proposta depois por Boyce-Codd, e é conhecida como forma normal de Boyce-
Codd (FNBC). 
Através do processo de normalização, pode-se, gradativamente, substituir um conjunto de entidades e 
relacionamentos por um outro, o qual se apresenta "purificado" em relação às anomalias de atualização (inclusão, 
alteração e exclusão), as quais podem causar certos problemas, tais como: 
 
Normalização de relações é, portanto, uma técnica que permite depurar um projeto de banco de dados, através da 
identificação de inconsistências (informações em duplicidade, dependências funcionais mal resolvidas etc.). 
À medida que um conjunto de relações passa para uma forma normal, vamos construindo um banco de dados mais 
confiável. O objetivo da normalização não é eliminar todos as inconsistências, e sim controlá-las. 
 
 
Descrição das formas normais 
Primeira forma normal: 
Uma relação está na primeira forma normal, se todos os seus atributos são monovalorados e atômicos. 
 Quando encontrarmos um atributo multivalorado, devemos criar um novo atributo que individualize a informação 
que esta multivalorada: 
HISTÓRICO = {matricula-aluno, código-disciplina, notas} 
No caso acima, cada nota seria individualizada identificando a prova a qual aquela nota se refere: 
HISTÓRICO = {matrícula-aluno, código-disciplina, número-prova, nota} 
Quando encontrarmos um atributo não atômico, devemos dividi-lo em outros atributos que sejam atômicos: 
PESSOA = {CPF, nome-completo} 
Vamos supor que, para a aplicação que utilizará esta relação, o atributo nome-completo não é atômico, a solução 
então será: 
PESSOA = {CPF, nome, sobrenome} 
Segunda Forma normal: 
Uma relação está na segunda forma normal, quando duas condições são satisfeitas: 
1- A relação estiver na primeira forma normal. 
2 - Todos os atributos primos dependerem funcionalmente de toda a chave primária. Observe a relação abaixo: 
HISTÓRICO = {matrícula-aluno, código-matéria, número-prova, nota, data-da-prova, nome-aluno, endereço-aluno, 
nome-matéria} 
Fazendo a análise da dependência funcional de cada atributo primo, chegamos às seguintes dependências 
funcionais: 
- matrícula-aluno, código-matéria, número-prova -> nota 
- código-matéria, número-prova -> data-da-prova 
- matrícula -aluno -> nome-aluno, endereço-aluno 
- código-matéria -> nome-matéria 
Concluímos então que apenas o atributo primo nota depende totalmente de toda chave primária. Para que toda a 
relação seja passada para a segunda forma normal, devem-se criar novas relações, agrupando os atributos de acordo 
com suas dependências funcionais: 
BOLETIM = { matrícula -aluno, código-matéria, número-prova, nota} 
PROVA = { código-matéria, número-prova, data-da-prova} 
ALUNO = { matrícula -aluno, nome-aluno, endereço-aluno} 
MATÉRIA = { código-matéria, nome-matéria} 
O nome das novas relações deve ser escolhido de acordo com a chave. 
Terceira forma normal 
Uma relação está na terceira formanormal, quando duas condições forem satisfeitas: 
1 - A relação estiver na segunda forma normal. 
2 - Todos os atributos primos dependerem não transitivamente de toda a chave primária. 
 Observe a relação abaixo: 
PEDIDO = {número-pedido, código-cliente, data-pedido, nome-cliente, código -cidade-cliente, nome-cidade-cliente} 
Fazendo a análise da dependência funcional de cada atributo primo, chegamos às seguintes dependências 
funcionais: 
- número-pedido -> código-cliente 
- número-pedido -> data-pedido 
- código -cliente -> nome-cliente 
- código-cliente -> código-cidade-cliente 
- código-cidade-cliente -> nome-cidade-cliente 
Concluímos então que apenas os atributos primos código-cliente e data-pedido dependem não transitivamente 
totalmente de toda chave primária. 
Observe que: 
número-pedido -> código-cliente -> nome-cliente 
número-pedido -> código-cliente -> código-cidade-cliente 
número-pedido -> código-cliente -> código-cidade-cliente -> nome-cidade-cliente 
Isso é dependência transitiva; devemos resolver inicialmente as dependências mais simples, criando uma nova 
relação onde código-cliente é a chave, o código-cliente continuará na relação PEDIDO como atributo primo, porém, 
os atributos que dependem dele devem ser transferidos para a nova relação: 
PEDIDO = {número-pedido, código-cliente, data-pedido} 
CLIENTE = {código-cliente, nome-cliente, código-cidade-cliente, nome-cidade-cliente} 
As dependências transitivas da relação PEDIDO foram eliminadas, porém, ainda, devemos analisar a nova relação 
CLIENTE: 
código-cliente -> código-cidade-cliente -> nome-cidade-cliente 
Observe que o nome-cidade-cliente continua com uma dependência transitiva, vamos resolvê-la da mesma maneira: 
PEDIDO = {número-pedido, código-cliente, data-pedido} 
CLIENTE = { código-cliente, nome-cliente, código-cidade-cliente} 
CIDADE = {código-cidade-cliente, nome-cidade-cliente} 
O nome das novas relações deve ser escolhido de acordo com a chave. 
Regra geral da normalização 
“Todo item de dados em uma relação é dependente da chave, da chave toda e de nada mais do que a chave” 
[James Martin, 1991] 
“Um bom modelo de dados gera relações em 3FN” 
Pesquise sobre as demais formas normais (Boyce_Codd, 4ª e 5ª formas normais), nos livros de referência. 
Nesta aula, você: 
 Aprendeu o conceito de normalização. 
 Aprendeu o conceito de dependência funcional. 
 Aprendeu a identificar as 1ª, 2ª e 3ª formas normais. 
 Aprendeu a criar tabelas que cumprem as regras desta formas normais. 
 
1. 
 “Todos os atributos da tabela são monovalorados e atômicos”. A afirmação compõe parte ou totalmente a regra para: 
 1) 1ª Forma Normal (1FN). 
 2) 2ª Forma Normal (2FN). 
 3) 3ª Forma Normal (3FN). 
 4) 4ª Forma Normal (4FN). 
 5) 5ª Forma Normal (5FN). 
 1 
 2. 
 “Não existe transitividade entre os atributos chave e não chave". A afirmação compõe parte ou totalmente a regra 
para: 
 1) 1ª Forma Normal (1FN). 
 2) 2ª Forma Normal (2FN). 
 3) 3ª Forma Normal (3FN). 
 4) 4ª Forma Normal (4FN). 
 5) 5ª Forma Normal (5FN). 
 3 
 3. 
 “Os atributos não chave são dependentes de toda a chave primária”. A afirmação compõe parte ou totalmente a regra 
para: 
 1) 1ª Forma Normal (1FN). 
 2) 2ª Forma Normal (2FN). 
 3) 3ª Forma Normal (3FN). 
 4) 4ª Forma Normal (4FN). 
 5) 5ª Forma Normal (5FN). 
 2