Apostila Banco de Dados

Fundamentos e Projeto de
Banco de Dados
Copyright 2003 – 2016

Prof. Edison Andrade Martins Morais
http://www.edison.eti.br
prof@edison.eti.br
1
Sumário
1) Dados da Disciplina ..................................................................................................... 4
Principais Referências Bibliográficas........................................................................... 4
Básica ........................................................................................................................... 4
2) Introdução..................................................................................................................... 5
2.1) Dados e Informações............................................................................................. 5
2.2) Bases e Banco de Dados........................................................................................ 5
2.3) Propriedades de um Banco de Dados.................................................................... 5
2.4) Sistema Gerenciador de Banco de Dados (SGBD) ............................................... 6
2.4.1. Objetivos do SGBD ........................................................................................ 6
2.4.2. Principais componentes de um SGBD............................................................ 7
2.4.3. Classificação dos SGBD´s.............................................................................. 7
2.5) Sistema de Banco de Dados (SBD)....................................................................... 7
2.5.1. Objetivos do SBD........................................................................................... 8
2.5.2. Vantagens do uso de SBD´s ........................................................................... 8
2.5.3. Pessoas envolvidas em um SBD..................................................................... 9
2.5.4. SBD x Arquivos Tradicionais ........................................................................ 9
2.6) Modelos de Dados............................................................................................... 10
2.6.1) Abstrações .................................................................................................... 10
2.7) Arquitetura ANSI-SPARC para BD.................................................................... 11
2.7.1) Principais características .............................................................................. 11
2.7.2) Independência de Dados .............................................................................. 11
2.8) Linguagem e Interface para BD .......................................................................... 12
2.9) Projeto de Banco de Dados ................................................................................. 12
9.1) Fases ................................................................................................................ 12
9.2) O Projeto de Banco de Dados dentro do Ciclo de Vida dos Sistemas
Informação.............................................................................................................. 13
2.10) Exercícios .......................................................................................................... 13
3) O Modelo de Dados Relacional ................................................................................. 17
3.1) Diagrama Entidade Relacionamento (DER) ....................................................... 18
3.1.1) Entidade........................................................................................................ 18
3.1.2) Relacionamento............................................................................................ 18
3.1.3) Atributo ........................................................................................................ 19
3.1.4) Dicionário de Dados..................................................................................... 21
3.1.5) Padrões de nomenclatura.............................................................................. 21
3.1.6) Tipos de Entidades ....................................................................................... 22
3.1.7) Tipos de Relacionamentos ........................................................................... 23
3.1.8) Cardinalidade dos Relacionamentos ............................................................ 24
3.1.9) Como nomear os relacionamentos ............................................................... 26
3.1.10) Grau de um Relacionamento ...................................................................... 26
3.1.11) Generalização de Entidades ....................................................................... 27
3.1.12) Agregação................................................................................................... 27
3.1.13) Auto-relacionamento.................................................................................. 28
3.1.14) Relacionamento Total e Parcial.................................................................. 28
3.1.15) Cardinalidade mínima e máxima ............................................................... 29
3.2) Mapeamento MER/Modelo Relacional............................................................... 30
3.2.1) Mapeamento de Entidades ........................................................................... 30
3.2.2) Entidade Fraca.............................................................................................. 31
3.2.3) Entidade Associativa .................................................................................... 31
2
3.2.4) Relacionamento tipo 1:1 .............................................................................. 32
3.2.5) Relacionamento tipo 1:N.............................................................................. 32
3.2.6) Relacionamento tipo N:N............................................................................. 32
3.2.7) Relacionamento múltiplo ............................................................................. 33
3.2.8) Generalização de Entidades ......................................................................... 33
3.2.9) Agregação..................................................................................................... 34
3.2.10) Auto-relacionamento.................................................................................. 34
3.2.11) Algoritmo de Mapeamento ER/Relacional ................................................ 35
3.2.12) Exemplo ..................................................................................................... 36
3.3) Dicionário de Dados............................................................................................ 38
4) Normalização ............................................................................................................. 43
4.1) 1ª FORMA NORMAL ........................................................................................ 44
4.2) 2ª FORMA NORMAL ........................................................................................ 44
4.3) 3ª FORMA NORMAL ........................................................................................ 45
5) Referências Bibliográficas ......................................................................................... 47
3
1) Conteúdo da Apostila
Conceitos Básicos
• Arquitetura de Sistemas de Bancos de Dados

• Modelos de Dados e Esquemas de Bancos de Dados
O Modelo de Dados Relacional
• Definição formal do Modelo Relacional

• Restrições de integridade em Bancos de Dados Relacionais
Projeto de Bancos de Dados Relacionais
• O Modelo de Dados Entidade-Relacionamento (MER)

• Mapeamento do MER para o Modelo Relacional
• Normalização de Banco de Dados Relacionais
Linguagens Relacionais
• SQL (Structured Query Language)
Principais Referências Bibliográficas
Básica
[1] ELMASRI, R. Sistema de Banco de Dados - Fundamentos e Aplicações - 4ª

Edição, Pearson Education.
[2] KORTH, H. F.; SILBERSCHATZ, A. Sistema de Banco de Dados. São Paulo:

Makron Books, 1995.
Complementar
[3] DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro:

Campus, 1983.
[4] HEUSER, C. A. Projeto de Banco de Dados. Porto Alegre: Sagra Luzzatto,

2000.
[5] KROENKE, D. M. Banco de Dados – Fundamentos, Projeto e Implementação.

Rio de Janeiro: LTC, 1998.
4
2) Introdução
Fundamentos
- Sistema de Banco de Dados (SBD)
- Sistema Gerenciador de Banco de Dados (SGBD)
O Modelo de Dados Relacional

- Domínios, relações, tuplas, atributos, chaves.
- Restrições de integridade: domínio, chave, referencial.
- Mapeamento do modelo E-R (Entidade-Relacionamento) para o
modelo Relacional.
A Linguagem SQL
- Definição de dados (DDL)
- Manipulação de dados (DML)
- Pratica de programação SQL
2.1) Dados e Informações
Dado: é um conjunto de símbolos sem significado intrínseco. O valor de um

dado não constitui em um conhecimento útil.
Informação: é o dado associado à sua semântica. A informação é um recurso

valioso, permitindo gerar e difundir o conhecimento.
2.2) Bases e Banco de Dados
Base de Dados: é uma coleção de dados inter-relacionados.
Banco de Dados (BD): é a Base de Dados associada à sua semântica.

É um conjunto de arquivos integrados que atendem a um conjunto de sistemas.
[HEUSER2001]
- Modelo do BD (ou Modelo de Dados):

o É a descrição formal da estrutura de um banco de dados.
o Para se construir um modelo de BD usa-se uma linguagem de
modelagem de dados.
o Pode ser representado de várias formas.
o Possui dois níveis de abstração: o modelo conceitual e o
modelo lógico.
- Esquema (ou intenção) do BD:

o É cada representação do modelo do BD.
- Instância (ou extensão, ou estado) do BD:

o São os dados contidos em uma base de dados em um
determinado instante.
2.3) Propriedades de um Banco de Dados
5
- Tem o propósito de refletir o mundo real;
- Possui semântica inerente;
- Serve para um propósito;
- Possui tamanho e complexidade variáveis;
- Compartilhamento de dados;
Ex.: uma indústria hipotética, onde as áreas de Produção, Vendas e

Compras compartilham um mesmo Banco de Dados.
Produção Vendas Compras
Base de
Banco de Dados dados de
Produtos
Produto
2.4) Sistema Gerenciador de Banco de Dados (SGBD)
Um SGBD é constituído por um conjunto de dados associados a um

conjunto de programas para acesso a esses dados.
É um software que incorpora as funções de definição, recuperação e

alteração de dados em um banco de dados [HEUSER2001].
Há vários tipos de SGDB´s no mercado. No decorrer do curso vamos nos

concentrar nos SGBD´s do tipo relacional, que é principal modelo utilizado no
mercado.
2.4.1. Objetivos do SGBD
- Criação e manutenção de Bancos de Dados

o Definição: especificação dos tipos de dados que serão
utilizados.
o Construção: armazenamento físico dos dados e metadados.
o Manutenção: evolução dos esquemas de bancos de dados.
- Manipulação de bases de dados

o Recuperação: consulta aos dados armazenados
o Atualização: modificação de dados específicos visando refletir
mudanças da realidade representada.
Exemplo: Banco de Dados de uma Universidade
- Dados do Estudante: nome, matrícula, endereço...

- Dados de Disciplina: código, nome, créditos, depto...
6
- Dados de Curso: nome, departamento, carga horária...
- Dados de Notas: turma, estudante, média...
- Dados de Professor: matrícula, nome, título...
Definição: nome = string(30); matricula = numérico(6); ....

Construção: armazenar dados de cada estudante, curso,...
Manipulação: criar um novo curso; obter nomes de disciplinas do curso
X; alterar nota do aluno Y;...
Evolução: alterar matrícula para numérico (8);
2.4.2. Principais componentes de um SGBD
- Gerenciador de Dados
o Armazenamento de dados.
o Recuperação de dados.
o Manutenção de restrições de integridade e segurança.
- Gerenciador de Transações
o Processamento e otimização de transações.
o Recuperação de falhas.
o Controle de concorrências.
2.4.3. Classificação dos SGBD´s
- Critério 1: modelo de dados

o Relacional, hierárquico, em rede, OO.
- Critério 2: número de usuários simultâneos

o Mono-usuário, multi-usuário
- Critério 3: distribuição do SBD

o Centralizado, distribuído.
- Critério 4: custo
o de $ 100 a $ 3.000,
o de $ 10.000 a $ 100.000
o acima de $ 100.000
- Critério 4: tipo de utilização

o Genéricos, de propósito específico
2.5) Sistema de Banco de Dados (SBD)
7
Usuários
SBD
Transações
SGBD
Gerenciador de Transações (TM)
Gerenciador de Acesso aos Dados (DM)
Definição do BD Dados
Armazenados
Catálogo Base de Dados
2.5.1. Objetivos do SBD
- Controlar (diminuir) redundância

o Evitar desperdício de espaço e inconsistência.
o Em certas situações é permitida a redundância controlada.
- Controlar compartilhamento de dados

o Sistemas multi-usuário exigem controle de concorrência.
- Controlar direitos de acesso

o Prover mecanismos de gerência de acesso.
o Catálogo/dicionário de dados facilita essa gerência.
- Prover múltiplas interfaces

o Oferecer diferentes tipos de interfaces para os diversos tipos
de usuários.
- Expressar relacionamentos complexos entre dados
- Garantir (preservar) restrições de integridade

o Verificar restrições de integridade automaticamente
- Prover recuperação de falhas e cópias de segurança

o Tratar falhas que podem comprometer a consistência.
2.5.2. Vantagens do uso de SBD´s
8
- Segurança e controle centralizados
o Diminui a redundância de dados. A redundância ocorre de
maneira mais controlada.
o Reduz inconsistência nos dados. Dados menos redundantes e
verificação de restrições de integridade.
o Facilita a padronização. Esta pode ser imposta pela
administração de dados e de BD.
o Aumenta flexibilidade do ambiente, pois facilita alterações
estruturais.
- Reduz o tempo de desenvolvimento

o Estima-se que com o reaproveitamento dos esquemas e dados
pode-se reduzir o tempo de desenvolvimento de 25% a 35%.
- Aumenta disponibilidade dos dados

o O usuário pode ter acesso imediato aos dados atualizados por
outro usuário devido aos mecanismos de controle de
concorrência e recuperação de falhas.
- Economia de escala
o A consolidação dos dados e aplicações permitem crescimento
coordenado, sem duplicação de esforço.
2.5.3. Pessoas envolvidas em um SBD
- Projetistas de Bancos de Dados

o Identificam dados, restrições e requisitos de desempenho.
o Definem o modelo conceitual e lógico da aplicação.
o Em algumas organizações podem definir o modelo físico.
o Precisam conhecer o negócio.
- Administradores de Banco de Dados (DBA)

o Definem critérios de acesso.
o Monitoram desempenho e definem projeto físico.
o Definem estratégia de backup e recuperação de falhas.
o Precisam conhecer o SGBD
- Usuários finais
- Analistas e programadores de aplicações
2.5.4. SBD x Arquivos Tradicionais
SBD Arquivos Tradicionais

- Um SBD é auto-contido: dados (base) - Cada usuário define e implementa
+ metadados (catálogo); uso de arquivos necessários à sua aplicação
software de propósito geral; mesmo específica; Programas separados para
repositório usado por diferentes perfis manipular dados contidos nos
de usuários. arquivos.
9
- Isolamento e independência entre - Definição dos dados é parte do
programas e dados. programa da aplicação.
- Suporta definição de múltiplas visões - Não suporta definição de múltiplas

de dados. visões.
2.5.5. Vantagens do uso de arquivos convencionais
- Aplicação com dados muito simples, bem definidos e estáveis.

o Diminui o custo, pois não exige investimento em SGBD.
- Requisitos de tempo real.

o O SGBD impõe overhead de segurança, controle de
concorrência, recuperação.
- Aplicações em que não há necessidade de acesso de múltiplos

usuários.
2.6) Modelos de Dados
É o conjunto de conceitos utilizados para descrever a estrutura de uma base de

dados: tipos de dados, relacionamentos entre eles e restrições de integridade.
A maioria dos modelos inclui também um conjunto de operações que podem ser
usadas para especificar recuperação e atualização dos dados.
São ferramentas básicas para prover diferentes níveis de abstrações (conceitual,

física) no entendimento da estrutura de dados.
2.6.1) Abstrações
- Modelo de dados conceitual (alto nível):

o Conceitos próximos da visão do usuário final;
o Baseado na descrição de objetos e seus inter-relacionamentos.
- Modelo de dados físico (baixo nível):

o Conceitos próximos da visão dos especialistas em
computação;
o Descreve detalhes do armazenamento de dados no
computador;
- Modelo de dados de implementação (nível médio):

o Conceitos compreendidos pelo usuário final, mas que
representam logicamente aos dados armazenados.
10
2.7) Arquitetura ANSI-SPARC para BD
Nível Visão
Externo externa
Mapeamento
Externo-conceitual
Nível Esquema
Conceitual Conceitual
Mapeamento
Conceitual-interno
Nível Esquema
Interno Interno
Dados
Armazenados
2.7.1) Principais características
- Provê as características da abordagem de BD

o Independência de dados; Visões múltiplas; uso de catálogo.
- Nível Interno – Esquema Interno

o Descreve as estruturas físicas de armazenamento do BD
o Usa o modelo de dados físico
- Nível Conceitual – Esquema Conceitual

o Descreve a estrutura do BD com um todo
o Usa o modelo lógico (esconde implementação física)
- Nível Externo – Visão Externa

o Visões conceituais particulares de acordo com o perfil do
usuário.
2.7.2) Independência de Dados
É a capacidade de alterar o esquema em um nível do SBD sem afetar os

esquemas nos níveis superiores.
- Independência de dados lógica

o Mudanças no esquema conceitual não afetam esquemas
externos. Exemplo: a alteração do nome do cliente não afeta
11
um esquema externo que só contém o código e o cpf do
cliente.
- Independência de dados física
o Mudanças no esquema interno não implicam em mudança nos

esquemas conceitual e externos. Exemplo: inclusão de um
índice de acesso.
2.8) Linguagem e Interface para BD
- Um SBD deve prover linguagens e interfaces apropriadas para

realizar tarefas específicas.
o Definição de Armazenamento (Storage Definition Language -

SDL)
o Definição de Dados (Data Definition Language - DDL)
o Definição de Visões (View Definition Language - VDL)
o Manipulação de Dados (Data Manipulation Language –
DML)
- As Interfaces são indicadas para usuários mais experientes ou que não

desejam conhecer os detalhes de query-languages. Estas linguagens
possuem a seguinte classificação:
o Baseadas em menu
o Gráficas
o Baseadas em formulários
o Baseados em linguagem natural
2.9) Projeto de Banco de Dados
Define as estruturas lógica e física de uma base de dados. Precisa atender

requisitos de conteúdo, compreensão, processamento e desempenho para um
determinado conjunto de usuários e aplicações.
9.1) Fases
1 – Coleta e análise requisitos;
2 – Projeto conceitual;
3 – Escolha de um SGBD;
4 – Projeto Lógico;
5 – Projeto Físico;
6 – Implementação.
12
9.2) O Projeto de Banco de Dados dentro do Ciclo de Vida dos Sistemas
Informação
Fase Funções Dados

- Análise de Viabilidade
- Análise de Requisitos Análise Funcional Projeto Conceitual
(DFD, etc...) (MER, DD)
- Projeto Projeto Funcional Projeto Operacional
(projeto dos módulos) (lógico e físico)
- Implementação Programas Criação e carga do BD
- Validação e aceitação
- Operação
- Monitoramento e
Manutenção.
2.10) Exercícios
01 - ( ) Informação é qualquer conjunto de símbolos que não possui

significado. Apesar disso, a informação representa um conhecimento útil e
valioso dentro da realidade das empresas, permitindo gerar e difundir
conhecimento.
02 - ( ) Base de Dados é um conjunto de dados inter-relacionados.
03 - ( ) Um Banco de Dados é uma base de dados associada à sua semântica.
04 - ( ) Banco de Dados são todos os arquivos contidos em um Sistema de

Informação, ou seja, um Sistema de Informação é constituído única e
exclusivamente por um conjunto de bases de dados, que, associados à sua
semântica constituem o Banco de Dados.
05 - ( ) Um Banco de Dados é constituído por um modelo, uma esquema e uma

instância.
06 - ( ) Um Modelo de Dados é a descrição formal da estrutura de um banco de

dados, que por sua vez é representada pelo Esquema do Banco de Dados.
07 - ( ) Além de representar a estrutura do Banco de Dados, o Esquema do

Banco de Dados também representa todos os dados contidos nas Bases de
Dados, dentro do Banco de Dados. Desta forma dados e metadados ficam
contidos em um mesmo repositório.
08 - ( ) Um Banco de Dados tem como propósito representar o mundo real.

Sendo assim, possui semântica inerente, servindo para diversos propósitos.
Além disso, possui tamanho e complexidade variáveis, além de promover o
compartilhamento de dados.
13
09 - ( ) Gerenciar compartilhamento de dados não é tarefa do Banco de Dados.
Este compartilhamento deve ser gerenciado pelo sistema que irá utilizar o Banco
de Dados, ou seja, controle de concorrência é uma tarefa do programador no
momento do desenvolvimento da aplicação.
10 - ( ) Um Sistema de Gerenciamento de Banco de Dados é um software que

incorpora as funções de definição, construção, manutenção, recuperação e
atualização de dados em um banco de dados.
11 - ( ) Os principais componentes de um SGBD são o gerenciador de dados e

o gerenciador de transações.
12 - ( ) O gerenciador de dados é responsável pelo armazenamento,

recuperação de dados, manutenção de restrições de integridade e segurança.
13 - ( ) O gerenciador de transações é responsável pelo processamento e

otimização de transações, pela recuperação de falhas e pelo controle de
concorrência.
14 - ( ) Dentre as várias classificações dos SGBD´s podemos citar: Quanto ao

modelo de dados (mono-usuário e multi-usuário), e quanto ao tipo de utilização
(centralizado e distribuído).
15 - ( ) O conceito de Sistema de Banco de Dados (SBD) está contido dentro do

conceitos de Sistema de Gerenciamento de Banco de Dados (SGBD), onde estão
contidos mecanismos de Gerenciamento de Transações (TM) e Gerenciamento
de Acesso a Dados (DM).
16 - ( ) O Gerenciador de Acesso a Dados utiliza o Catálogo com a definição

do Banco de Dados para obter informação a respeito da estrutura dos Dados
armazenados na Base de Dados contida no Banco de Dados.
17 - ( ) Redundância de dados significa existência de informações repetidas na

Base de Dados.
18 - ( ) Um dos principais objetivos de um Sistema de Banco de Dados é o

controle de redundância no armazenamento dos dados.
19 - ( ) Redundância e inconsistência são inversamente proporcionais, ou seja,

quanto maior a redundância, menor a inconsistência.
20 - ( ) Gerenciamento de compartilhamento de dados em Sistemas de Banco

de Dados mono-usuário é um dos objetivos dos SBD´s.
21 - ( ) Gerenciamento de direitos de acesso, múltiplas interfaces, garantias de

restrições de integridade, recuperação de falhas e gerenciamento de cópias de
segurança também são objetivos dos SBD´s.
22 - ( ) Os SBD´s não prevêem mecanismos para representar relacionamento

complexos entre dados.
14
23 - ( ) A segurança e o controle descentralizados dentro dos SBD´s são
utilizados no sentido de facilitar a padronização no desenvolvimento e facilitar
alterações estruturais.
24 - ( ) A utilização de SBD´s tem muitas vantagens, porém, sua principal

desvantagem está no fato de que aumenta o tempo no desenvolvimento, pois os
esquemas de Banco de Dados já existentes não podem ser reaproveitados.
25 - ( ) Existem várias pessoas, e atividades, envolvidas no desenvolvimento de

um Sistema de Banco de Dados, dentre elas, podemos citar: os usuários finais,
que são as pessoas responsáveis pela criação e definição das estrutura do Banco
de Dados, e os analistas e programadores de aplicações, que são as pessoas
responsáveis pelo implementação física de um Banco de Dados.
26 - ( ) É tarefa do Administrador de Dados (DBA) a definição do modelo

conceitual de lógico do banco de dados. Cabe a está pessoa conhecer as regras
de negócio da realidade que está modelando no sentido desenvolver um projeto
que atende as reais necessidades dos seus usuários finais.
27 - ( ) Os utilização de SBD´s se difere da utilização de arquivos tradicionais

no que diz respeito a definição dos dados. Enquanto nos SBD´s a definição dos
dados é parte do programa de aplicação, nos arquivos tradicionais existe
isolamento e independência entre programas e dados.
28 - ( ) Para descrever a estrutura de um Banco de Dados, utilizamos o

chamado Modelo de Dados. A estrutura de um Banco de Dados é definida pelo
seu conjunto de dados e seus relacionamentos, e pela definição das restrições de
integridade entre estes dados.
29 - ( ) A maioria dos Modelos de Dados prevêem um conjunto de operações

que podem ser usadas para especificar recuperação e atualização dos dados.
30 - ( ) Os modelos de dados possuem dois níveis de abstração: O Modelo de

Dados Conceitual, que descreve os detalhes de armazenamento dos dados no
computador e o Modelo de Dados Físico, baseado na descrição de objetos e seus
inter-relacionamentos.
31 - ( ) Na arquitetura ANSI-SPARC para Bancos de Dados, estão previstos

três níveis de representação do Modelo de Dados. O nível externo, que
implementa o modelo descritivo, que é baseado em visões particulares de acordo
com o perfil do usuário; O nível conceitual, que implementa o modelo relacional
e descreve a estrutura do BD como um todo; e o esquema interno, que
implementa o modelo físico e descreve as estruturas físicas de armazenamento
do Banco de Dados.
32 - ( ) A arquitetura ANSI-SPARC provês os conceitos de independência de

dados e múltiplas visões do Banco de Dados.
15
33 - ( ) Existem dois tipos de Independência de Dados: A independência de
dados física e lógica. No conceito de independência de dados lógica, mudanças
no esquema conceitual não afetam esquemas externos. Já no conceito de
independência de dados física, mudanças no esquema interno não implicam em
mudança nos esquemas conceitual e externos.
34 - ( ) Data Definition Language – DDL é a linguagem de Banco de Dados

utilizada para definição e manipulação dos dados.
35 - ( ) Alguns Sistemas de Banco de Dados provêem interfaces gráficas para

manipulação os dados. Interfaces estas que dispensam a utilização de query-
languages, tornando mais fácil a tarefa do DBA.
36 - ( ) Um projeto de Banco de Dados define as estruturas lógica e física de

uma base de dados.
37 - ( ) Requisitos de conteúdo, compreensão, processamento e desempenho

para um determinado conjunto de usuários e aplicações devem ser atendidos por
um projeto de Banco de Dados.
38 - ( ) Um projeto de Banco de Dados deve obedecer as seguintes fases,

respectivamente: 1 – Coleta e análise requisitos; 2 – Projeto conceitual; 3 –
Escolha de um SGBD; 4 – Projeto Lógico; 5 – Projeto Físico; 6 –
Implementação.
39 - ( ) Dentro do ciclo de vida de desenvolvimento de sistemas, as atividades

relacionadas a banco de dados compreendem as fases de Análise de Requisitos,
Projeto e Implementação.
16
3) O Modelo de Dados Relacional
O Modelo de Dados Relacional foi introduzido por E. F. Codd em 1970.
Representa o padrão de facto para modelo de dados, sendo implementado pela
maioria dos SGBD´s comerciais. Representa um modelo eficiente para a maioria
das aplicações comerciais.
Em uma definição informal, o Modelo Relacional é representado por tabelas,

linhas, colunas e domínios, dentro de uma única estrutura de dados.
Exemplo:
Nome CPF Sexo Data Nasc. Profissão

Edison 123456 M 07/03/77 Analista de Sistemas
Pedro 654321 M 01/12/78 Professor
Maria 299299 F 15/05/54 Bióloga
Alfredo 238838 M 13/09/70 Professor
Fátima 445355 F 19/05/78 Médica
Regina 345355 F 17/05/75 Psicóloga
Em uma analogia entre o conceito matemático de relação e a noção trivial de

tabela, temos que: cada LINHA da tabela representa uma TUPLA da relação; O
NÚMERO DE COLUNAS da tabela representa o GRAU da relação; O
NÚMERO DE LINHAS da tabela representa a CARDINALIDADE da
relação; Os VALORES PERMITIDOS em cada coluna da tabela representam
o DOMÍNIO da relação. Para o exemplo acima, temos uma relação de grau
cinco e cardinalidade seis.
O Modelo de Dados é uma representação das necessidades de dados de um

determinado ambiente e de como esses dados se relacionam. É uma das
primeiras atividades que devem ser executadas ao longo do processo de
identificação e compreensão de um ambiente, tendo em vista necessidades de
automatização.
É um dos produtos da fase de Análise do Ciclo de Vida de um projeto de

desenvolvimento de um sistema. O Modelo entidade-relacionamento (MER) é
representado através de Diagrama Entidade Relacionamento (DER). Os
próximos itens deste texto detalham cada um de seus componentes.
Construir um Modelo de Dados significa:
- Coletar e documentar informações relevantes do ambiente estudado;
- Representar as informações, de forma clara e objetiva, e num formato padrão

que possa facilitar o entendimento dos participantes do processo;
- Definir, de maneira clara, o escopo do ambiente modelado;
- Adquirir o entendimento do ambiente através de refinamentos sucessivos

do modelo;
17
- Representar graficamente as necessidades de informação independente do
Software e do Hardware a serem usados na implementação do Sistema.
3.1) Diagrama Entidade Relacionamento (DER)
3.1.1) Entidade
É o conjunto de objetos da realidade modelada sobre os quais deseja-

se manter informações no banco de dados. [HEUSER2001]
Chamamos de entidade, qualquer coisa real ou abstrata, de um

determinado ambiente, sobre a qual precisamos guardar informações.
[ALVES2003]
Quando estamos modelando o ambiente de uma biblioteca, por

exemplo, então as informações a respeito dos livros devem estar
representadas pela entidade: Livro. As informações relativas aos usuários
da biblioteca poderiam ser representadas pela entidade: Cliente. As
informações relativas ao empréstimo de livros seriam representadas pela
entidade: Empréstimo. As reservas de livros por: Reserva, e assim por
diante. Nesse ambiente as informações da entidade Livro poderiam ser:
nome do livro, ISBN do livro, e título do livro. Para a entidade Cliente
poderíamos ter: cpf, nome, endereço e telefone. Para a entidade
Empréstimo: data do empréstimo, data provável de devolução e taxa de
multa para o caso de devolução com atraso. A entidade Reserva poderia
ter: data da reserva, e data provável de disponibilidade do livro.
É claro que as informações representadas por uma entidade depende

do ambiente onde ela está inserida. Por exemplo: uma pessoa para o
Ministério da Fazenda é vista como um contribuinte de impostos. E
dentro deste contexto as informações relevantes de pessoa seriam: cpf,
renda anual, despesas médicas, despesas com instrução, etc. Já o
Ministério da Educação poderia ter outras necessidades de informações
sobre uma pessoa, como por exemplo: cpf, nível de escolaridade, idade,
data de nascimento, etc. O Ministério da Saúde, certamente teria
interesse em informações sobre saúde: tipo sanguíneo, data de
nascimento, etc. Podemos concluir que, uma entidade só deve conter
informações que dizem respeito, ou que são necessárias, ao ambiente que
representa.
Representação Gráfica:
LIVRO CLIENTE EMPRÉSTIMO
3.1.2) Relacionamento
É o conjunto de associação entre entidades. [HEUSER2001]
18
Chamamos de relacionamento a associação entre duas entidades ou
entre uma entidade e ela mesma. Para expressar, em um modelo, quais as
disciplinas nas quais um aluno está matriculado nós poderíamos definir o
relacionamento: O aluno está matriculado em... O relacionamento para
expressar os dependentes de um determinado empregado seria:
Empregado tem dependentes. [ALVES2003]
EMPREGADO TEM DEPENDENTE
3.1.3) Atributo
É o dado que é associado a cada ocorrência de uma entidade ou de

um relacionamento. [HEUSER2001]
São partes específicas de uma determinada entidade. [ALVES2003]
Poderiam ser atributos de uma entidade Aluno: nome, número da

matrícula, cpf, data de ingresso no curso, endereço, telefone e data de
nascimento. Uma entidade Fornecedor poderia ter como atributos: Cgc,
nome, Razão Social, Endereço, e Capital Social. Cada entidade tem
valores específicos para seus atributos que diferir ou ser iguais aos
valores dos atributos de outras entidades de um mesmo tipo de entidade.
Valor de um atributo:
Chamamos valor de um atributo ao conteúdo que um atributo pode

Ter. Marcos Ferreira, Rosa Cristina, Deusdete da Cunha poderiam ser
valores da entidade Aluno. Casas Bahia, Carrefour, C&A seriam valores
do atributo nome da entidade Fornecedor
Domínio de um atributo:
É o conjunto de valores que um atributo pode assumir. Exemplo:

Masculino, Feminino são o domínio do atributo Sexo da entidade Aluno.
O atributo Nota da entidade aluno tem o domínio: {número reais de 0 a
10).
ALUNO
Nome
Matrícula
19
Características dos Atributos de uma entidade:
Único: cada entidade tem um valor diferente para este atributo. A

matrícula de um aluno em um curso é um atributo único porque não
existe outro aluno matriculado com o mesmo número de matrícula.
Não-Único: quando o valor pode se repetir em várias entidades. Por

exemplo, o aproveitamento de um aluno. Mais de uma aluno pode Ter a
mesma nota.
Obrigatório: quando tem que existir um valor para este atributo em

toda entidade. Por exemplo, o nome do aluno na entidade ALUNO.
Simples: quando possui um domínio simples. Por exemplo, o

atributo sexo tem um domínio simples pois é formado pelo conjunto
(único) das letras F e M.
Composto: quando possui mais de um domínio simples. Endereço de

uma pessoa, por exemplo. Ele é formado pelos domínios, simples, dos
Logradouros, dos Bairros, das Cidades, dos Estados e dos Cep´s.
Endereço
Rua Quadra Lote
Univalorado: quando tem um único valor para cada entidade. Por

exemplo, o número de matrícula de um aluno. Cada aluno tem um único
número de matrícula.
Multivalorado: quando pode ter mais de um valor para cada

entidade. Por exemplo, o telefone de uma pessoa. Uma pessoa pode ter
mais de um telefone. O do trabalho e da residência.
Telefone
Derivado: quando o seu conteúdo depende do conteúdo de outros

atributos. Por exemplo, o total de uma nota fiscal é formado pela soma
dos totais de cada item componente da nota fiscal.
Total da Nota
20
Não derivado: quando ele não pode ser obtido a partir de outros
atributos. Por exemplo, nome de um aluno.
Identificador: é o atributo ou atributos que identificam uma entidade

de um tipo de entidade de maneira única. Por exemplo, a matrícula do
estudante. Ou a matrícula do aluno e o código da disciplina no tipo de
entidade APROVEITAMENTO.
Matrícula
Em sua representação gráfica, o atributo do tipo identificador deve

aparecer sublinhado.
Existem seis tipos de atributos identificadores, também chamados de

chaves ou índices. Os atributos componentes dos campos chave não
devem permitir valores nulos.
Chave Descrição
Super chave É qualquer subconjunto de atributos que
identifica univocamente uma tupla da relação.
Chave É a super chave minimal. Não se pode tirar
nenhum dos seus atributos componentes sem
perder a unicidade.
Chave candidata Qualquer combinação de atributos que pode
(alternativa) ser chave da relação.
Chave primária Chave candidata considerada principal.
Determina a ordenação lógica das tuplas na
relação.
Chave alternativa Chave candidata que não foi designada como
(única) primária.
Chave estrangeira Permite associação lógica entre tuplas de duas
(chave externa) relações. (é a chave primária da outra relação).
Não Identificador: quando o identificador não identifica por si só

uma entidade dentro de um tipo de entidades. Por exemplo, o nome do
aluno não identifica o aluno dentro to tipo de entidade ALUNO.
3.1.4) Dicionário de Dados
O dicionário de dados contém as definições das entidades, dos

relacionamentos e dos atributos de um modelo de dados. [ALVES2003]
3.1.5) Padrões de nomenclatura
Nome do Tipo de Entidade: Letras maiúsculas e no singular.
21
Nome de Relacionamento: Letras maiúsculas e no singular.
Nome de Atributo: Inicia com letra maiúscula e o restante minúsculo.
3.1.6) Tipos de Entidades
Entidade Primária
É a entidade que existe por si mesma. Sua identificação completa é

feita pelos seus próprios atributos. [ALVES2003]
Ex.: A Entidade ALUNO é uma entidade primária porque é

identificada pelos seus próprios atributos. O seu identificador pode ser o
atributo Matrícula do aluno.
ALUNO
Nome
Matrícula
Entidade Fraca ou Dependente
É a entidade cuja identificação não pode ser feita por seus próprios
atributos. Para sua identificação completa precisamos de atributos de
outra entidade. [ALVES2003]
Ex.: A entidade DEPENDENTE é uma entidade fraca pois para a sua

identificação há que se utilizar atributos da entidade EMPREGADO (A
Matrícula do empregado, por exemplo). Ou seja, quando falamos, João
Viera (DEPENDENTE) precisamos dizer de quem ele é dependente
(EMPREGADO) para que se possa identificá-lo completamente. Assim:
João Vieira é dependente de Francisco da Rocha (EMPREGADO).
Nome Código
Matrícula Data Nascimento
Entidade Associativa
É a entidade que não se identifica por se mesma e sua existência

depende da existência de duas ou mais outras entidades. Compõem seu
22
identificador os identificadores das entidades que se associaram para lhe
dar origem. [ALVES2003]
Ex.: No diagrama abaixo a entidade, APROVEITAMENTO é uma

entidade associativa porque a sua identificação só possível a partir da
Matrícula, identificador da entidade ALUNO e de Código, identificador
da entidade DISCIPLINA. Ou sejam, quando nos referimos ao
aproveitamento 7,3, por exemplo, ele só tem sentido quando associado a
uma aluno e a uma disciplina. Assim: João Ribeiro Ferraz (ALUNO)
obteve a nota 7,3 (APROVEITAMENTO) em Banco de Dados
(DISCIPLINA).
ALUNO DISCIPLINA
1 1
N N
APROVEITAMENTO
3.1.7) Tipos de Relacionamentos
Relacionamento Tipo Dependência
Chamamos de Relacionamento de Dependência ao relacionamento

entre um tipo de entidade primária e um tipo de entidade dependente
(fraca). [ALVES2003]
Ex.: O Tipo de entidade EMPREGADO compõe-se de entidades

primárias porque essas entidades são identificadas completamente por
seus atributos. É razoável imaginarmos que numa mesma empresa não
existam empregados com a mesma matrícula. Já a as entidades de
DEPENDENTE são do tipo fraca porque os seus atributos não as
identificam completamente. Suponhamos que Pedro Rodrigues seja filho
de Francisco Moreira, cujo número de matrícula seja 10. Se falamos
apenas Pedro Rodrigues, não o identificamos, porque pode existir outros
Pedro Rodrigues filhos de outros empregado que não seja o Francisco
Moreira de matrícula 10. Para que Pedro Rodrigues seja completamente
identificado precisamos associá-lo ao empregado do qual ele é
dependente. Então dizemos: Pedro Rodrigues é dependente de Francisco
Moreira de matrícula 10.
23
1 N
EMPREGADO DEPENDENTE
Tipo de Entidade Primária Tipo de Entidade Fraca
Relacionamento Tipo Associativo
Um relacionamento é do tipo associativo se ele relaciona uma

entidade primária a uma entidade associativa. [ALVES2003]
Ex.: Tanto o relacionamento entre ALUNO e APROVEITAMENTO

como o relacionamento entre DISCIPLINA e APROVEITAMENTO são
do tipo associativo pois ambos relacionam entidades primárias de
ALUNO e DISCIPLINA à entidade do tipo associativa
APROVEITAMENTO.
1 N N 1
ALUNO APROVEITAMENTO DISCIPLINA
Entidade Primária Entidade Associativa Entidade

Primária
3.1.8) Cardinalidade dos Relacionamentos
Havendo um relacionamento entre entidades, é necessário identificar

a cardinalidade, ou seja, quantas tuplas da entidade A podem estar
associadas com uma tupla da entidade B e vice-versa.
A partir desta verificação, podemos definir os seguintes tipos de

relacionamentos:
Relacionamento 1:1
Um elemento de um conjunto de entidades se relaciona apenas com

um elemento do outro conjunto.
1 1
HOMEM MULHER
Homem Casa Mulher
24
João r1 Maria
Adão r2 Eva
Rui Ana
r3
Relacionamento 1:N
Ocorre quando uma ocorrência de entidade se relaciona com várias

ocorrências da outra entidade.
1 N
DEPTO FUNCIONARIO
Possui
Depto Funcionários
Vendas r1 Maria
r2 Eva
Contabili r3 Ana
dade
Rui
r4
Ivo
r5
Relacionamento N:N
Nesse tipo de relacionamento, cada elemento de uma relação X, pode

corresponder a vários elementos de uma relação Y, e cada elemento da
relação Y pode corresponder a vários elementos da relação X.
Em relacionamento N:N, o relacionamento pode ter ou não atributos.

No exemplo abaixo o atributo do relacionamento curso poderia ser a nota
do aluno.
25
N N
ALUNO DISCIPLINA
Cursa
Aluno Disciplina
José r1
r2 Matemática
Maria r3
r4 Estatística
João
r5
Física
r6
3.1.9) Como nomear os relacionamentos
Substantivo
Utilizar um substantivo que represente a forma como as entidades de

associam.
N 1
FUNCIONÁRIO LOTAÇÃO DEPARTAMENTO
Verbo
Utilizar um verbo que indica uma ação em que uma das entidades é o
sujeito e a outra é o objeto.
N N
FORNECEDOR FORNECE PRODUTO
DEPARTAMENTO
Nome das Entidades
Utilizar os nomes das entidades envolvidas no relacionamento.
1 N
CLIENTE
CLIENTE PEDIDO PEDIDO
3.1.10) Grau de um Relacionamento
O grau de um relacionamento é determinado pelo número de

entidades que participam do relacionamento.
26
Quando ocorre um relacionamento que envolve associação entre três
ou mais entidades (portanto com grau maior que 2), dizemos haver um
relacionamento múltiplo.
Exemplo de relacionamento de grau três:
PRODUTO
N N
DEPÓSITO ENTREGA CLIENTE
3.1.11) Generalização de Entidades
Certos conjuntos de entidades de dados (supertipos) podem ser

subdivididos em diversas categorias de elementos (subtipos), cada uma
se caracterizando por atributos específicos. A este processo
denominamos particionamento de conjunto de entidades.Como exemplo
poderíamos citar o caso em que a entidade Funcionário pode ser
subdividida numa categoria de Professores, em outra de Engenheiros e
em outra de Técnicos.
FUNCIONARIO
PROFESSOR TECNICO ENGENHEIRO
3.1.12) Agregação
A agregação é uma extensão do modelo proposto por Peter Chen de

forma a permitir o registro do relacionamento de uma entidade com um
relacionamento anteriormente criado.
27
N N
CORRENTISTA POSSUI CONTA CORRENTE
PERTENCE
CARTAO MAGNETICO
3.1.13) Auto-relacionamento
É comum encontrarmos, durante o processo de modelagem,

associações de ocorrências de entidades com outras ocorrências do
mesmo tipo, o que chamamos de auto-relacionamento. É o caso, por
exemplo, de peças que são compostas por partes de outras peças.
Um auto-relacionamento, portanto, é o relacionamento estabelecido

entre uma entidade e ela mesma.
Exemplo: chefia é o relacionamento estabelecido entre a entidade

funcionário e ela própria, uma vez que tanto o chefe quanto seus
subordinados fazem parte do mesmo corpo funcional de uma empresa.
FUNCIONARIO
1 N
CHEFIA
3.1.14) Relacionamento Total e Parcial
Podemos classificar os relacionamentos em totais ou parciais. Os

relacionamentos totais (ou obrigatórios) são aqueles que participam todas
as tuplas de uma entidade. Os relacionamentos parciais (ou opcionais)
são aqueles em a participação de todas as tuplas da entidade não é
obrigatória.
28
Parcial
1 N
AGÊNCIA COBRA FATURA
Uma agência pode ter muitas faturas em cobrança, ou pode não ter
nenhuma. Uma fatura fica em cobrança em uma agência, pode haver
fatura não colocada em agência.
Parcial x Total
1 N
DEPARTAMENTO POSSUI DIVISAO
Um determinado departamento pode ter muitas divisões, e pode não

ter nenhuma divisão. Uma divisão tem que estar sempre ligada a um só
departamento.
Total
1 1
CANDIDATO PERTENCE FICHA INSCRIÇÃO
Um candidato tem que ter uma, e só uma ficha de inscrição. Uma

ficha de inscrição tem que pertencer a um, e só um, candidato.
3.1.15) Cardinalidade mínima e máxima
A cardinalidade mínima é máxima de um relacionamento também

pode ser representada no diagrama.
Exemplo: Um funcionário de uma empresa pode possuir zero ou mais

dependentes. Cada dependente está relacionado a uma, e somente uma
pessoa.
1,1 0,N
FUNCIONARIO POSSUI DEPENDENTE
No exemplo acima, a cardinalidade mínima do funcionário em

relação ao seus dependentes é zero e a máxima é N. A cardinalidade mínima do
dependente em relação ao funcionário é um e a máxima também é 1.
29
3.2) Mapeamento MER/Modelo Relacional
3.2.1) Mapeamento de Entidades
- Entidade Primária
Modelo E/R
ALUNO
Nome
Matrícula
Modelo Relacional
ALUNO(Matricula, Nome)
* O atributo identificador da entidade primária deve ser sublinhado. Se a

entidade possuir mais de 1 atributo identificador, estes deverão ser
sublinhados.
- Entidade Primária com atributo composto
Modelo E/R
ALUNO
Endereço
Nome
Matrícula Rua Quadra Lote
Modelo Relacional
ALUNO(Matricula, Nome, Rua, Quadra, Lote)
- Entidade Primária com atributo multivalorado
Modelo E/R
30
ALUNO Endereco(0,N)
Telefone(0,3)
Nome
Matrícula
Modelo Relacional
ALUNO(Matricula, Nome, Telefone1, Telefone2, Telefone3)

ALUNOENDERECO(Matricula, Endereço)
3.2.2) Entidade Fraca
Modelo E/R
Nome Código
Matrícula Data Nascimento
Modelo Relacional
EMPREGADO(Matricula, Nome)
DEPENDENTE(Matrícula, Código, Data Nascimento)
* O atributo Matrícula na entidade DEPENDENTE é chamado de chave

estrangeira.
* A chave primária da entidade DEPENDENTE é a o conjunto de
atributos Matrícula e Código.
3.2.3) Entidade Associativa
Modelo E/R
ALUNO DISCIPLINA
APROVEITAMENTO
Modelo Relacional
31
DISCIPLINA(Código, Nome)
APROVEITAMENTO(Matricula, Código, Nota, Freqüência)
3.2.4) Relacionamento tipo 1:1
Modelo E/R
0,1 0,1
HOMEM MULHER
Modelo Relacional
HOMEM(Cod_H, Nome)
MULHER(Cod_M, Nome, Cod_H)
Ou
HOMEM(Cod_H, Nome, Cod_M)

MULHER(Cod_M, Nome)
3.2.5) Relacionamento tipo 1:N
Modelo E/R
DEPTO 1,1 0,N FUNCIONARIO
Modelo Relacional
DEPTO(Cod_Depto, Nome)
MULHER(Cod_Func, Nome_Func, Codg_Depto)
3.2.6) Relacionamento tipo N:N
Modelo E/R
1,N 1,N
ALUNO DISCIPLINA
Modelo Relacional
DISCIPLINA(Código, Nome)
ALUNODISCIPLINA(Matricula, Código, Nota, Freqüência)
* O atributo identificador da entidade ALUNODISCIPLINA é formado

pelos atributos identificadores das entidades envolvidas na relação.
32
3.2.7) Relacionamento múltiplo
Modelo E/R
PRODUTO
0,N
0,N 0,N
DEPÓSITO ENTREGA CLIENTE
Modelo Relacional
DEPOSITO(Codg_Dep, Nome)
PRODUTO(Codg_Prod, Nome)
CLIENTE(Codg_Cli, Nome)
ENTREGA(Codg_Dep, Codg_Prod, Codg_Cli, Quantidade, Valor)
3.2.8) Generalização de Entidades
Modelo E/R
FUNCIONARIO
PROFESSOR TECNICO ENGENHEIRO
Modelo Relacional
FUNCIONARIO(Codg_Func, Nome, Tipo)

PROFESSOR(Codg_Func, Titulação)
TECNICO(Codg_Func, Grau_de_Instrução)
ENGENHEIRO(Codg_Func, Especialização)
Ou,
FUNCIONARIO(Codg_Func, Nome, Tipo, Titulação,

Grau_de_Instrução, Especialização)
* Nome segundo modelo algumas tuplas poderão ter os atributos

Titulação, Grau de Instrução e Especialização com valores nulos.
33
3.2.9) Agregação
Modelo E/R
0,N 0,N
CORRENTISTA POSSUI CONTA CORRENTE
1,1
PERTENCE
0,1
CARTAO MAGNETICO
Modelo Relacional
CORRENTISTA(Codg_Cor, Nome)
CONTACORRENTE(Codg_CCR, Tipo)
CORRENTISTACCR(Codg_Cor, Codg_CCR, Número, Saldo)
CARTAOMAGNETICO(Codg_CM, Número)
CORRENTISTACCRCM(Codg_Cor, Codg_CCR, CodgCM, Validade)
3.2.10) Auto-relacionamento
Modelo E/R
FUNCIONARIO
1 N
CHEFIA
Modelo Relacional
FUNCIONARIO(Codg_Func, Nome)
CHEFIA(Codg_Func, Codg_FuncChefe)
* Na relação CHEFIA, os atributos Codg_Func e Codg_FuncChefe são

chaves estrangeiras da relação funcionário. O conjunto dos dois atributos
compõe o atributo identificador da relação.
34
Ou,
FUNCIONARIO(Codg_Func, Nome, Codg_FuncChefe)
* Neste caso o atributo Codg_FuncChefe poderá permitir valores nulos

para os casos em que um funcionário não possuir chefe.
3.2.11) Algoritmo de Mapeamento ER/Relacional
Passo 1 – Para cada tipo de entidade forte E no esquema ER, crie uma
relação R inclua todos os atributos simples de E. Inclua somente os atributos
componentes simples de cada atributo composto. Escolha uma dos atributos
chave de E como chave primária de R. Se a chave escolhida for composta, o
conjunto de atributos simples que a formam juntos formarão a chave primária de
R.
Passo 2 – Para cada tipo de entidade fraca F no esquema ER cujo tipo de

entidade forte identificadora é E, crie uma relação R, e inclua todos os atributos
simples (ou componentes simples de atributos compostos) de F como atributos
de R. Além disso, inclua como chave estrangeira em R os atributos que formam
a chave(s) primária(s) da(s) relação(ões) que correspondem ao tipo de entidade
forte identificadora. Esse procedimento mapeia o relacionamento identificador
de F. A chave primária de R é a combinação da(s) chave(s) primária(s) da(s)
entidade(s) forte(s) e da chave parcial do tipo de entidade fraca F, se existir.
Passo 3 – Para cada tipo de relacionamento R binário 1:1 no esquema ER,

identifique as relações S e T que correspondam aos tipos de entidades
participantes de R. Escolha uma das relações – digamos, S – e inclua como
chave estrangeira em S a chave primária de T. É melhor escolher um tipo de
entidade com participação total em R para desempenhar o papel de S. Inclua
todos os atributos simples (ou componentes simples de atributos compostos) do
tipo de relacionamento R 1:1 como atributos de S.
Passo 4 – Para cada tipo de relacionamento binário R 1:N que não seja
identificador de entidade fraca, identifique a relação S que representa o tipo de
entidade participante no lado N do tipo de relacionamento. Inclua como chave
estrangeira de S a chave primária da relação T que representa o outro tipo de
entidade participante de R; isto se deve ao fato de que cada instância de entidade
do lado N se relaciona a, no máximo, uma instância de entidade do lado 1 do
tipo de relacionamento. Inclua todos os atributos simples (ou componentes
simples de atributos compostos) do tipo de relacionamento 1:N como atributos
de S.
Passo 5 – Para cada tipo de relacionamento binário R M:N, crie uma nova
relação S para representar R. Inclua como chaves estrangeiras em S os atributos
que formam as chaves primárias das relações que representam os tipos de
entidades participantes de R; a combinação dessas chaves estrangeiras formarão
a chave primária de S. Também inclua todos os atributos simples do tipo de
35
relacionamento M:N (ou componentes simples de atributos compostos) como
atributos de S.
Passo 6 – Para cada atributo multivalorado A, crie uma nova relação R que
inclui um atributo correspondente a A mais a chave primária K (como chave
estrangeira em R) da relação que representa o tipo de entidade ou tipo de
relacionamento que tem A como atributo. A chave primária de R é a combinação
de A com K. Se o atributo multivalorado é composto, então inclua somente seus
componentes simples.
Passo 7 – Para cada tipo de relacionamento n-ário R, com n > 2, crie uma
nova relação S para representar R. Inclua como chaves estrangeiras em S as
chaves primárias das relações que representam os tipos de entidades
participantes de R. Também inclua todos os atributos simples (ou componentes
simples de atributos compostos) como atributos de S. A chave primária de S é,
normalmente, a combinação de todas as chaves estrangeiras que referenciam as
relações que representam os tipos de entidades participantes de R. No entanto, se
a restrição de participação (min,max) de um dos tipos de entidades participantes
de R (digamos, E) tiver max = 1, então a chave primária de S pode ser
simplesmente a chave estrangeira que referencia a relação E’ correspondente a
E, pois, nesse caso, cada entidade e em E participará em, no máximo, uma
instância de relacionamento de R e, portanto, pode identificar unicamente essa
instância de relacionamento.
Passo 8 – Converta cada especialização com m subclasses {S1,S2,...,Sm} e

superclasse C, onde os atributos de C são {k,a1,...,an} e k é a chave primária, em
esquemas de relação usando uma das quatro seguintes opções:
Opção 8.1 – Crie uma relação L para C com atributos Atrs(L) = {k,a1,...,an}
e PK(L) = k. Crie uma relação Li para cada subclasse Si, 1 ≤ i ≤ m, com os
atributos Atrs(Li) = {k} ∪ {atributos de Si} e PK(Li) = k.
Opção 8.2 – Crie uma relação Li para cada subclasse Si, 1 ≤ i ≤ m, com
atributos Atrs(Li) = {atributos de Si} ∪ {k,a1,...,an} e PK(Li) = k.
Opção 8.3 – Crie uma única relação L com atributos Atrs(L) = {k,a1,...,an}
∪ {atributos de S1} ∪ ... ∪ {atributos de Sm} ∪ {t} e PK(L) = k. Esta opção é
para especializações cujas subclasses são disjuntas, e t é um atributo que indica a
subclasse à qual cada tupla pertence, se for o caso. Esta opção pode gerar um
grande número de valores nulos.
Opção 8.4 – Crie uma única relação L com atributos Atrs(L) = {k,a1,...,an} ∪
{atributos de S1} ∪ ... ∪ {atributos de Sm} ∪ {t1,t2,...,tm} e PK(L) = k. Esta
opção é para especializações cujas subclasses são sobrepostas, e cada ti, 1 ≤ i ≤
m, é um atributo booleano que indica se a tupla pertence à subclasse Si.
3.2.12) Exemplo
36
No exemplo acima, temos o seguinte Modelo Relacional:
CONSTRUTORA(Numr_Const, Nome_Const);
DEPARTAMENTO(Numr_Const, Codg_Depto, Nome_Dpto, Qtdade_Func);
PROJETO(Numr_Depto, Codg_Proj, Nome_Proj, Data_Inicio, Data_Fim);
37
MATERIAL(Codg_Mat, Nome_Mat);
PROJETO_MATERIAL(Codg_Proj, Codg_Mat, Quantidade);
FORNECEDOR(Codg_Forn, Nome_Forn, Logradouro, Cidade, UF);
FORNECEDOR_MATERIAL(Codg_Forn, Codg_Mat, Quantidade, Data, Valor);
FUNCIONARIO(Codg_Func, Nome, Data_Nascimento);
LIDER(Codg_Func, Gratificação);
FUNCIONARIOLIDER(Codg_Func, Codg_Projeto);
FUNCIONARIOPARTICIPA(Codg_Func, Codg_Proj, Função, Data_Inicio,
Data_Fim);
HABILIDADE(Codg_Func, Descrição);
3.3) Dicionário de Dados
Este dicionário de dados tem como objetivo descrever as entidades e os

relacionamentos identificados no DER/Modelo Relacional. A seguir, é
apresentada uma notação utilizada na taxonomia dos atributos das entidades
identificadas. Tal notação será utilizada em todo restante deste curso para
descrever os atributos. Posteriormente, as entidades são apresentadas, juntamente
com seus respectivos atributos e, em seguida, são listados os relacionamentos
entre estas entidades.
Notação utilizada para taxonomia dos atributos.
Entidade <Nome da Entidade>: <Descrição da Entidade>
Nome Descrição Tipo MV CP DV Observações
Nome: Nome do atributo. Obs.: O Atributo identificador deve ser

Sublinhado e em negrito. A Cardinalidade de Atributo [<Nome do atributo>
(cardinalidade mínima, cardinalidade máxima)] também deve ser representada.
Quando não for descrita, o valor assumido será (1,1), ou seja, o atributo é
obrigatório e monovalorado.
Ex.: Telefone(0,2). A entidade que possuir este atributo possui no mínimo 0

e no máximo 2 telefones. Sendo que o telefone não é obrigatório.
Descrição: descrição do valor do atributo
Tipos dos atributos:

-T(n): Texto com n caracteres
- I(n): Número inteiro com n algarismos
- N(n,d): Número decimal com n algarismos no total, sendo d decimais
- S/N: Lógico (Sim, Não)
- D: Data
- M: Campo texto longo
38
MV: Atributo multivalorado? Seus valores devem ser colocados na coluna
observação;
CP: Atributo composto? A composição do atributo deve ser colocada na

coluna observação;
DV: Atributo derivado? A derivação do atributo deve ser colocada na coluna

observação;
Observações: Toda e qualquer observação a respeito dos atributos.
Ex.: Criar um dicionário de dados a partir do modelo descritivo abaixo:
Uma firma vende produtos de limpeza. Cada produto é caracterizado por um

código único, nome do produto, categoria (e.g. detergente, sabão em pó,
sabonete, etc), e seu preço. A categoria é uma classificação criada pela própria
firma. A firma possui informações sobre todos seus clientes. Cada cliente é
identificado por um código único (também interno à firma), o nome do cliente,
endereço (rua, numero, sala, cidade, CEP, UF), telefone, o status do cliente
("bom", "médio", "ruim"), e o seu limite de crédito. Guarda-se igualmente a
informação dos pedidos feitos pelos clientes. Cada pedido possui um número, e
guarda-se a data de elaboração do pedido. Cada pedido pode envolver de 1 a
vários produtos, e para cada produto, indica-se a quantidade deste pedida e o
valor total desta quantidade.
1º Passo – Criação do DER
39
2º Passo – mapeamento para o modelo relacional
CLIENTE(Código, Nome, Classificação, Limite de Crédito, Rua, Número, Sala,

Cidade, UF, CEP, Telefone)
PRODUTO(Código, Nome, Tipo, Preço)
PEDIDOCLIENTE(CódigoCliente, Número, Data)
PEDIDOPRODUTO(CódigoCliente, NúmeroPedidoCliente,
NumeroProduto,Quantidade, Valor_Total)
3º Passo – Criação do Dicionário de Dados
a) Descrição das entidades
Entidade CLIENTE: Representa todos os clientes da firma.
40
Código Código do cliente I(4) N N N Quando um novo
para controle cliente é cadastrado
interno da firma. na firma ele recebe
uma nova numeração.
Nome Nome completo do T(50) N N N
cliente.
Classificação Tipo do cliente I(1) N N N 0 – Bom, 1 – Médio,
2 – Ruim. Só pode
receber os valores 0, 1
e 2.
Limite de Crédito Limite de crédito N(8,2) N N N Calculado de acordo
do cliente. com a classificação:
Ruim <= R$ 500,00
Médio <= R$ 1000,00
Bom – Qualquer
valor.
Endereço Endereço completo S N N
do Cliente
Rua Rua em que o T(50) N N N
cliente reside
Número(0,1) Número na rua em I(5) N N N
que o cliente reside
Sala (0,1) I(5) N N N
Cidade Cidade em que o T(50) N N N
cliente reside
UF UF em que o T(2) N N N
cliente reside
CEP(0,1) CEP do endereço T(10) N N N Formato 99.999-999
do cliente
Telefone(0,2) Telefone(s) do T(17) N N N Formato (0xxxx)
Cliente 9999-9999.
Entidade PRODUTO: Representa todos os produtos que a firma comercializa.

Código Código do produto I(4) N N N Quando um novo
para controle interno produto é cadastrado
da firma. na firma ele recebe
uma nova numeração.
Nome Nome completo do T(50) N N N
produto.
Tipo Tipo do produto I(1) N N N 0 – Sabão em pó, 1 –
Detergente, 2 –
Sabonete. Só pode
receber os valores 0, 1
e 2.
Preço Valor do produto N(8,2) N N N O valor do produto é
definido pela tabela de
preços da firma no
momento do seu
cadastro.
Entidade PEDIDOCLIENTE: Representa todos os pedidos efetuados pelo

cliente.
41
Número Número do pedido I(4) N N N Quando um novo
para controle interno pedido é cadastrado na
da firma. firma ele recebe uma
nova numeração.
Data Data do Pedido D N N N Formato dd/mm/yyyy
Entidade PEDIDOPRODUTO: Representa todos os produtos existentes em um

pedido.

Quantidade Quantidade do I(5) N N N
produto dentro do
pedido.
Valor_Total Valor do produto de N(8,2) N N S Quantidade * Valor
acordo com a do Produto.
quantidade
b) Descrição dos relacionamentos
FAZ: Representa o fato de um cliente fazer 0 ou vários pedidos e um pedido ser

feito por 1 e somente 1 cliente.
POSSUI: Representa o fato de um Pedido, que possui um cliente relacionado

possuir 1 ou vários produtos e um produto fazer parte de 0 ou vários Pedidos.
42
4) Normalização
A teoria da normalização foi escrita por E.F. Codd em 1970 e consistia em 3
formas normais, ou 3 etapas de normalização onde, em cada etapa, uma relação passa a
satisfazer um conjunto de restrições estabelecidas. Posteriormente, a teoria foi estendida
pelo autor até a quinta forma normal.
Objetivos da normalização:
- Minimização de redundâncias e inconsistências;

- Facilidade de manipulação do banco de dados (alteração e recuperação
dos dados);
- Facilidade de manutenção dos Sistemas de Informação.
Resultados esperados com a normalização
- Lista de relações necessárias e seus atributos;

- Relações estáveis capazes de suportar mudanças.
Exemplo de normalização
Para podermos aqui estudar a técnica de normalização, tomaremos como

exemplo uma estrutura de dados correspondente a um pedido de compra de um cliente
para um fornecedor. Temos então como estrutura do pedido:
PEDIDO
Nº DO PEDIDO: DATA DO PEDIDO: DATA DA ENTREGA:
CGC DO CLIENTE: NOME DO CLIENTE:
ENDEREÇO DO CLIENTE
CÓD. DO NOME DO QUANTIDADE PREÇO PREÇO

ITEM ITEM UNITÁRIO TOTAL
TOTAL DO PEDIDO:
Notação da relação pedido não normalizada:
43
PEDIDO(Numero, Data, Data_Entrega, CGC_Cliente, Nome_Cliente,
Endereço_Cliente, Código_Item, Nome_Item, Quantidade, Preço_Unitário,
Preço_Total, Total_Pedido).
Instâncias da relação pedido não normalizada:
PEDIDO
1 11/10 15/10 111 Cli 1 E1 1 Item 1 10 50,00 500,00 660,00
1 11/10 15/10 111 Cli 1 E1 2 Item 2 5 10,00 50,00 660,00
1 11/10 15/10 111 Cli 1 E1 3 Item 3 6 5,00 30,00 660,00
1 11/10 15/10 111 Cli 1 E1 4 Item 4 8 10,00 80,00 660,00
4.1) 1ª FORMA NORMAL
Uma relação está na primeira forma normal se não contiver grupos de repetição.
Solução: devemos desmembrar a relação em uma ou mais relações sem grupos

de repetição;
Passos:
1 – Determinar a chave da relação original e a chave de cada grupo de repetição;
2 – Retirar da relação original os grupos de repetição;
3 – Criar nova relação com a chave da relação original e demais atributos do
grupo de repetição;
4 – Repetir o passo 3 para cada grupo de repetição.
Notação da relação pedido na primeira forma normal:

Endereço_Cliente, Total_Pedido).
ITENSDOPEDIDO(Numero do Pedido, Código_Item, Nome_Item,

Quantidade, Preço_Unitário, Preço_Total).
Instâncias da relação pedido na primeira forma normal:
PEDIDO
1 11/10 15/10 111 Cli 1 E1 660,00
ITENSDOPEDIDO
1 1 Item 1 10 50,00 500,00
1 2 Item 2 5 10,00 50,00
1 3 Item 3 6 5,00 30,00
1 4 Item 4 8 10,00 80,00
Uma relação está na segunda forma normal se estiver na primeira forma normal
e se todos os atributos não chaves são dependentes de toda chave e não apenas parte da
chave.
44
Solução: desmembrar a relação de modo que não haja atributo não chave
dependente de apenas parte da chave;
Passos:
1 – Retirar da relação original o atributo que dependa de parte da chave;
2 – Criar nova relação com a chave da relação original da qual o(s) atributo(s)
depende(m) e o(s) atributo(s) que depende(m) dessa chave.
Notação da relação pedido na segunda forma normal:

Endereço_Cliente, Total_Pedido).
ITENSDOPEDIDO(Numero do Pedido, Código_Item, Quantidade,

Preço_Total).
ITEM(Código_Item, Nome_Item, Preço_Unitário).
PEDIDO
1 11/10 15/10 111 Cli 1 E1 660,00
ITENSDOPEDIDO
1 1 10 500,00
1 2 5 50,00
1 3 6 30,00
1 4 8 80,00
ITEM
1 Item 1 50,00
2 Item 2 10,00
3 Item 3 5,00
4 Item 4 10,00
Uma relação está na terceira forma normal se estiver na segunda forma normal e
se todos os atributos não chave forem independentes entre si.
Solução: desmembrar a relação de modo que os atributos não chave sejam

dependentes exclusivamente da chave.
Passos:
1 – Retirar da relação original os atributos que dependam de outro atributo não
chave;
2 – Criar uma nova relação para cada atributo que possui outro(s) atributo(s)
dependente(s) dele.
45
Notação da relação pedido na terceira forma normal:
PEDIDO(Numero, Data, Data_Entrega, CGC_Cliente, Total_Pedido).
CLIENTE (CGC_Cliente, Nome_Cliente, Endereço_Cliente).
ITENSDOPEDIDO(Numero do Pedido, Código_Item, Quantidade,

Preço_Total).
ITEM(Código_Item, Nome_Item, Preço_Unitário).
PEDIDO
1 11/10 15/10 111 660,00
CLIENTE
111 Cli 1 E1
ITENSDOPEDIDO
1 1 10 500,00
1 2 5 50,00
1 3 6 30,00
1 4 8 80,00
ITEM
1 Item 1 50,00
2 Item 2 10,00
3 Item 3 5,00
4 Item 4 10,00
46
5) Referências Bibliográficas
[1] ELMASRI, R. Sistema de Banco de Dados - Fundamentos e Aplicações - 4ª

Edição, Pearson Education.
[2] KORTH, H. F.; SILBERSCHATZ, A. Sistema de Banco de Dados. São Paulo:

Makron Books, 1995.
[3] DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro:

Campus, 1983.
[4] HEUSER, C. A. Projeto de Banco de Dados. Porto Alegre: Sagra Luzzatto,

2000.
[5] KROENKE, D. M. Banco de Dados – Fundamentos, Projeto e Implementação.

Rio de Janeiro: LTC, 1998.
47

Apostila Banco de Dados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamentos e Projeto de

Copyright 2003 – 2016

• Arquitetura de Sistemas de Bancos de Dados

O Modelo de Dados Relacional

• Definição formal do Modelo Relacional

Projeto de Bancos de Dados Relacionais

• O Modelo de Dados Entidade-Relacionamento (MER)

• SQL (Structured Query Language)

Principais Referências Bibliográficas

[1] ELMASRI, R. Sistema de Banco de Dados - Fundamentos e Aplicações - 4ª

[2] KORTH, H. F.; SILBERSCHATZ, A. Sistema de Banco de Dados. São Paulo:

[3] DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro:

[4] HEUSER, C. A. Projeto de Banco de Dados. Porto Alegre: Sagra Luzzatto,

[5] KROENKE, D. M. Banco de Dados – Fundamentos, Projeto e Implementação.

O Modelo de Dados Relacional

2.1) Dados e Informações

Dado: é um conjunto de símbolos sem significado intrínseco. O valor de um

Informação: é o dado associado à sua semântica. A informação é um recurso

2.2) Bases e Banco de Dados

Base de Dados: é uma coleção de dados inter-relacionados.

Banco de Dados (BD): é a Base de Dados associada à sua semântica.

- Modelo do BD (ou Modelo de Dados):

- Esquema (ou intenção) do BD:

- Instância (ou extensão, ou estado) do BD:

2.3) Propriedades de um Banco de Dados

Ex.: uma indústria hipotética, onde as áreas de Produção, Vendas e

Produção Vendas Compras

2.4) Sistema Gerenciador de Banco de Dados (SGBD)

Um SGBD é constituído por um conjunto de dados associados a um

É um software que incorpora as funções de definição, recuperação e

Há vários tipos de SGDB´s no mercado. No decorrer do curso vamos nos

2.4.1. Objetivos do SGBD

- Criação e manutenção de Bancos de Dados

- Manipulação de bases de dados

Exemplo: Banco de Dados de uma Universidade

- Dados do Estudante: nome, matrícula, endereço...

Definição: nome = string(30); matricula = numérico(6); ....

2.4.2. Principais componentes de um SGBD

2.4.3. Classificação dos SGBD´s

- Critério 1: modelo de dados

- Critério 2: número de usuários simultâneos

- Critério 3: distribuição do SBD

- Critério 4: tipo de utilização

2.5) Sistema de Banco de Dados (SBD)

Gerenciador de Acesso aos Dados (DM)

Catálogo Base de Dados

2.5.1. Objetivos do SBD

- Controlar (diminuir) redundância

- Controlar compartilhamento de dados

- Controlar direitos de acesso

- Prover múltiplas interfaces

- Expressar relacionamentos complexos entre dados

- Garantir (preservar) restrições de integridade

- Prover recuperação de falhas e cópias de segurança

2.5.2. Vantagens do uso de SBD´s

- Reduz o tempo de desenvolvimento

- Aumenta disponibilidade dos dados

2.5.3. Pessoas envolvidas em um SBD

- Projetistas de Bancos de Dados

- Administradores de Banco de Dados (DBA)

- Analistas e programadores de aplicações

2.5.4. SBD x Arquivos Tradicionais

SBD Arquivos Tradicionais

- Suporta definição de múltiplas visões - Não suporta definição de múltiplas