Buscar

Apostila Banco de Dados 2008-1(1)

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 164 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 164 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 164 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

Banco de Dados Profª. Rossana Junqueira 1
Disciplina: Banco de 
Dados
Profa. Rossana de Paula Junqueira
Almeida
Ciência da Computação - 4° 
Período
Banco de Dados Profª. Rossana Junqueira 2
Capítulo 1: Conceitos 
Básicos
Banco de Dados Profª. Rossana Junqueira 3
Como Informática é adotada em 
organizações
z Informática é implementada gradativamente;
z Exemplo: uma empresa
z Implementa gradativamente sistemas para:
z Vendas
z Produção
z Compras
z Onde ficam os dados dos produtos?
z Usados em várias funções
z Pode ocorrer que, para casa uma das funções, seja criado um 
arquivo separado de produtos.
Banco de Dados Profª. Rossana Junqueira 4
Sistemas isolados – Dados não 
compartilhados
z Problema: redundância de dados
z Tipos de redundância da dados:
z Redundância controlada de dados
z Quando o software tem conhecimento da múltipla representação da 
informação e garante a sincronia entre as diversas representações.
Banco de Dados Profª. Rossana Junqueira 5
Sistemas isolados – Dados não 
compartilhados
z Redundância não controlada de dados
z O usuário gerencia a redundância
z Dever ser evitado
z Problemas:
ƒ Entrada repetida da mesma informação
ƒ Inconsistência de dados
z Como evitar:
ƒ Compartilhamento dos dados
ƒ Cada informação é armazenada uma única vez
ƒ Usar o conceito de Banco de Dados
Banco de Dados Profª. Rossana Junqueira 6
Banco de Dados
z Conjunto de arquivos integrados que atendem a um conjunto de 
sistemas
z O compartilhamento de dados tem reflexos na estrutura do software:
z A estrutura interna dos arquivos para a ser mais complexa
z Devem atender às necessidades dos diferentes sistemas
z Solução:
z Usar sistema de gerência de banco de dados
Banco de Dados Profª. Rossana Junqueira 7
Sistema de gerência de banco 
de dados
z Início da programação de aplicações
z Programa continha todas operações
z Interface de usuário
z Transformação de dados e cálculos
z Operações de armazenamento de dados
z Tarefas de comunicação com outros sistemas e programas
z Evolução da programação:
z Foram identificadas funcionalidades comuns a muitos programas
z Exibição dos dados na interface
ƒ Gerenciadores de interface do usuário
z Comunicação com processos remotos
ƒ Gerenciadores de comunicação
z Manutenção de grandes repositórios compartilhados de dados
ƒ Sistemas de Gerência de Banco de Dados (SGBD)
Banco de Dados Profª. Rossana Junqueira 8
Sistema de gerência de banco 
de dados
z Software que incorpora as funções de definição, recuperação e 
alteração de dados em um banco de dados
z Facilita o desenvolvimento de aplicações de BD
z Manutenção de programas torna-se mais simples
z Produtividade de programadores aumenta
Banco de Dados Profª. Rossana Junqueira 9
z Sistema de Banco de 
Dados:
z Apenas um sistema 
computadorizado de 
manutenção de registros
ou
z Sistema computadorizado 
cuja finalidade geral é
armazenar informações e 
permitir que os usuários 
busquem e atualizem 
essas informações 
quando as solicitar.
z Tal sistema envolve quatro 
componentes principais: Dados, 
Hardware, Software e Usuários.
Sistema de gerência de banco 
de dados
Banco de Dados Profª. Rossana Junqueira 10
z Sistema de Banco de Dados:
z Dados:
ƒ Sistema Monousuário: sistema em que no máximo um usuário 
pode acessar o banco de dados em determinado momento;
ƒ Sistema Multiusuário: é aquele em que muitos usuários podem 
acessar o banco de dados ao mesmo tempo.
ƒ Dados Integrados: BD pode ser considerado como uma unificação 
de vários arquivos que, de outro modo, seriam distintos, com a 
eliminação de qualquer redundância parcial ou total entre esses 
arquivos.
ƒ Dados Compartilhados: BD pode ser compartilhado entre 
diferentes usuários, no sentido de que diferentes usuários podem 
ter acesso aos mesmos dados, possivelmente ao mesmo tempo.
Sistema de gerência de banco 
de dados
Banco de Dados Profª. Rossana Junqueira 11
z Sistema de Banco de Dados:
z Hardware:
ƒ Volumes de armazenamento, processadores de hardware e 
memória.
z Software:
ƒ SGBD: Trata todas as requisições de acesso ao BD (acrescentar 
novos arquivos, inserir , buscar, excluir, alterar dados em arquivos 
existentes e remover arquivos existentes do banco de dados);
ƒ SGBD ≠ BD
z Usuários:
ƒ Programadores de aplicações: responsáveis pela escrita de 
programas de aplicações de banco de dados em alguma 
linguagem de programação;
ƒ Usuários finais: que acessam o banco de dados através de uma 
aplicação;
ƒ Administrador de banco de dados (DBA).
Sistema de gerência de banco 
de dados
Banco de Dados Profª. Rossana Junqueira 12
Modelo de Dados
z Modelo de (banco) de dados
z Descrição dos tipos de informações que estão armazenadas em um 
banco de dados
z Exemplo da indústria:
z Modelo de dados informa:
ƒ São armazenadas informações sobre produtos
ƒ Para cada produto, são armazenados seu código, preço e descrição
z Modelo de dados não informa:
ƒ Quais os produtos que estão armazenados no banco de dados
Banco de Dados Profª. Rossana Junqueira 13
Esquema de banco de dados
z Para construir um modelo de dados 
usa-se:
z Linguagem de modelagem de dados:
z Textual
z Gráfica
z Um modelo de dados pode ser 
apresentado de várias formas (texto, 
figura, ...)
z Cada apresentação do modelo recebe a 
denominação esquema de banco de 
dados
Níveis de Abstração:
Banco de Dados 14
Modelo Conceitual
z Independente do tipo de SGBD
z Registra:
z Que dados podem aparecer no banco de dados
z Não registra:
z Como estes dados estão armazenados a nível de SGBD
z Técnica mais difundida na modelagem conceitual
z Abordagem entidade-relacionamento (ER)
z Modelo conceitual é representado através de diagrama 
entidade-relacionamento (DER)
Banco de Dados
Modelo Lógico
z Nível de abstração visto pelo usuário do SGBD
z Depende do tipo particular de SGBD que está sendo usado
z Em um SGBD relacional, os dados estão organizados na forma 
de tabelas
Banco de Dados Profª. Rossana Junqueira 16
Modelo Físico
z Contém detalhes de armazenamento interno de informações
z Detalhes que:
z Não têm influencia sobre a programação de aplicações no SGBD
z Influenciam na performance das aplicações
z Usados por profissionais que fazem sintonia de performance em 
banco de dados, procurando otimizar o desempenho.
Banco de Dados Profª. Rossana Junqueira 17
Modelo conceitual como 
modelo de organização
z Constatação
z Um arquivo em computador contém informações sobre um conjunto 
de objetos ou entidades da organização que é atendida pelo 
sistema em computador
z Exemplo da indústria
z Um arquivo para armazenar dados de produtos, outro para 
armazenar dados de vendas, outro para dados de ordem de serviço 
e assim por diante
z Idéia fundamental do projeto de banco de dados:
z Através da identificação das entidades que terão informações 
representadas no banco de dados, é possível identificar os arquivos 
que comporão o banco de dados
Banco de Dados Profª. Rossana Junqueira 18
Modelo conceitual como 
modelo de organização
z Modelo conceitual tem dupla interpretação:
z Modelo da organização
z Define as entidades da organização que tem informações 
armazenadas no banco de dados
z Exemplificando:
ƒ O diagrama nos informa que na organização há produtos e tipos de 
produtos, que associado a cada tipo de produto há um código do tipo e 
uma descrição e assim por diante.
z Modelo do banco de dados
z Define que arquivos (tabelas) farão parte do banco de dados
z Exemplificando:
ƒ O diagrama nos informa que o banco de dados contém um arquivo com 
dados de produtos e tipos de produtos, que para cada tipo de produto 
são armazenados seu código e sua descrição e assim por diante.
Banco de Dados Profª. Rossana Junqueira 19
Projeto de banco de dados
z 3 fases:
z Modelagem conceitual
z Construído um modelo conceitual, na forma de um diagrama 
entidade-relacionamento.
z Modelo lógico
z Objetiva transformar o modelo conceitual obtido na primeira faze em 
um modelo lógico.
z Projeto físico
z O modelo é enriquecidocom detalhes que influenciam no 
desempenho do banco de dados, mas não interferem em sua 
funcionalidade
Banco de Dados Profª. Rossana Junqueira 20
Capítulo 2: Abordagem 
entidade - 
relacionamento
Banco de Dados Profª. Rossana Junqueira 21
Abordagem entidade- 
relacionamento
z Técnica para construir modelos conceituais de bases de dados
z Técnica de modelagem de dados mais difundida e utilizada
z Criada em 1976 por Peter Chen
z Padrão de fato para modelagem conceitual
z Não é única:
z NIAM/ORM (técnica européia da década de 70)
z UML (Técnica para modelos Orientados a Objetos)
z Técnicas de modelagem orientada a objetos (UML) baseiam-se 
nos conceitos da abordagem ER
z Modelo de dados é representado através de um
z modelo entidade-relacionamento (modelo ER)
z Modelo ER é representado graficamente
z diagrama entidade-relacionamento (DER)
Banco de Dados Profª. Rossana Junqueira 22
Entidade
z Conjunto de objetos da realidade modelada sobre os quais 
deseja-se manter informações no banco de dados
z Exemplos:
z Sistema de informações industrial:
z Produtos
z Tipos de produtos
z Vendas
z Compras
z Sistemas de contas correntes:
z Clientes
z Conta correntes
z Cheques
z Agências
Banco de Dados Profª. Rossana Junqueira 23
Entidade
z Representada através de um retângulo
z Retângulo contem o nome da entidade
z Entidade = conjunto de objetos
z Para se referir a um objeto em particular fala-se em instância
ou ocorrência da entidade
z Entidade isoladamente não informa nada, é necessário saber 
quais as informações que devem ser mantidas para cada 
objeto, ou seja, atribuir propriedades às entidades
z Propriedades são especificadas na forma de: relacionamentos, 
atributos e generalizações/especializações
Pessoa Departamento
Banco de Dados Profª. Rossana Junqueira 24
Relacionamento
z Conjunto de associações entre entidades sobre as quais 
deseja-se manter informações na base de dados
z Relacionamento é um conjunto de associações entre instâncias 
de entidades
z Uma instância (ocorrência) é uma associação específica entre 
determinadas instâncias de entidade
z Exemplo (relacionamento LOTAÇÃO)
z ocorrência = par específico formado por uma ocorrência de 
PESSOA e uma ocorrência de DEPARTAMENTO
25
Relacionamento
z Auto-relacionamento:
z Relacionamento de casamento
z Uma ocorrência de pessoa exerce o papel de marido
z Uma ocorrência de pessoa exerce o papel de esposa
z Relacionamento entre entidades diferentes não é necessário 
indicar os papéis das entidades
Banco de Dados Profª. Rossana Junqueira 26
Cardinalidade de relacionamentos
z Propriedade importante de um relacionamento
z Quantas ocorrências de uma entidade podem estar associadas a 
uma determinada ocorrência de entidade através do 
relacionamento
z Chamada de cardinalidade de uma entidade em um 
relacionamento
z Cardinalidade máxima:
27
Cardinalidade de relacionamentos
z Relacionamento de 1:1 z Relacionamento de 1:n
z Relacionamento de n:n
Banco de Dados Profª. Rossana Junqueira 28
Cardinalidade de relacionamentos
z Cardinalidade mínima:
z Número mínimo de ocorrências de entidade que são associadas a 
uma ocorrência de uma entidade através de um relacionamento
z Para fins de projeto de BD, consideram-se apenas duas 
cardinalidades mínimas
z cardinalidade mínima 0
z cardinalidade mínima 1
z Denominação alternativa:
z cardinalidade mínima 1 = “associação obrigatória”
z cardinalidade mínima 0 = “associação opcional”
Banco de Dados Profª. Rossana Junqueira 29
Exemplos de entidades e 
relacionamentos
Banco de Dados Profª. Rossana Junqueira 30
Atributo
z Dado ou informação que é associado a cada ocorrência de 
uma entidade ou de um relacionamento
Banco de Dados Profª. Rossana Junqueira 31
Atributo
z Cada entidade deve possuir um identificador
z Identificador = conjunto propriedades de uma entidade (atributos e 
relacionamentos) cujos valores servem para distinguir uma 
ocorrência da entidade das demais ocorrências da mesma 
entidade
Profª. Rossana Junqueira 32
Generalização e Especialização
z Este conceito permite atribuir propriedades particulares a um 
subconjunto das ocorrências (especializadas) de uma entidade 
genérica.
z Associada ao conceito
de generalização/
Especialização está
 
a idéia
de herança de propriedades.
z Herdar propriedades significa
que cada ocorrência da entidade
especializada possui:
z Além de suas próprias propriedades
z Também as propriedades da ocorrência da entidade genérica 
correspondente
Banco de Dados
Generalização e Especialização
z Especialização total ou parcial
Banco de Dados 34
Entidade associativa
z É necessário saber que medicamentos 
foram prescritos em cada consulta.
z Uma entidade associativa
nada mais é
 
que a redefinição
de um relacionamento, que
passa a ser tratado como se
fosse também uma entidade.
Banco de Dados Profª. Rossana Junqueira 35
Entidade associativa
Banco de Dados Profª. Rossana Junqueira 36
Capítulo 3: Construindo 
modelos entidade- 
relacionamento
Banco de Dados Profª. Rossana Junqueira 37
Propriedades de modelos ER
z É um modelo formal, preciso, não ambíguo.
z Isto significa que diferentes leitores de um mesmo modelo ER 
devem sempre entender exatamente o mesmo.
z DER pode ser usado como entrada a uma ferramenta CASE.
z Fundamental: todos os envolvidos devem estar treinados na sua 
perfeita compreensão.
z Risco: sub-utilização
z Modelos ER têm poder de expressão limitado
z Modelo ER apresenta apenas algumas propriedades de um banco 
de dados
z Foi concebido para o projeto da estrutura de um BD relacional
z Pouco poderoso para expressar restrições de integridade (regras 
de negócio)
Banco de Dados Profª. Rossana Junqueira 38
Equivalência entre modelos
z Dois modelos diferentes podem se equivalentes
z Modelos equivalentes:
z expressam o mesmo
z modelam a mesma realidade
z Para fins de projeto de banco de dados, dois modelos ER são 
equivalentes, quando ambos geram o mesmo esquema de 
banco de dados
z Para analisar se dois modelos são equivalentes, é necessário 
considerar um conjunto de regras de tradução de modelos ER 
para modelos lógicos de banco de dados
Banco de Dados Profª. Rossana Junqueira 39
Exemplo de equivalência entre 
modelos
z CONSULTA como relacionamento n:n
z CONSULTA como entidade
Banco de Dados Profª. Rossana Junqueira 40
Exemplo de equivalência entre 
modelos
z A determinação de que construção da abordagem ER 
(entidade, relacionamento, atributo,...) será usada para 
modelar um objeto de uma realidade
z não pode ser feita através da observação do objeto isoladamente
z é necessário conhecer o contexto (modelo dentro do qual o objeto 
aparece)
z Decisão por uma construção para a modelagem de um objeto 
está sujeita a alteração durante a modelagem
z Não despender um tempo excessivo em longas discussões 
sobre como modelar um objeto
z O próprio desenvolvimento do modelo e o aprendizado sobre a 
realidade irão refinando e aperfeiçoando o modelo
z Existem critérios alguns critérios para escolha de construções 
de modelagem
Banco de Dados Profª. Rossana Junqueira 41
Atributo versus entidade 
relacionada
z Alguns critérios para esta decisão são:
z Objeto está vinculado a outros objetos
deve ser modelado como entidade
z Caso contrário pode ser modelado como
atributo
z Conjunto de valores de um determinado objeto é fixo, pode ser 
modelado como atributo
z Existem transações no sistema que alteram o conjunto de valores 
do objeto, não deve ser modelado como atributo
Banco de Dados Profª. Rossana Junqueira 42
Atributo versus 
generalização/especialização
z Questão:
z Modelar um determinado objeto (por exemplo, a categoria 
funcional de cada empregado de uma empresa) como atributo ou 
como especialização?
z Especialização deve ser usada quando as classes especializadas 
de entidades possuem propriedades particulares 
43
Verificação do modelo
z Uma vez construído, um modelo ER dever ser validado e 
verificado.
z A verificação é o controlede qualidade que procura garantir 
que o modelo usado para a construção do banco de dados 
gerará um bom produto.
z Um modelo para ser considerado bom, deve preencher uma 
série de requisitos, como ser completo, ser correto e não 
conter redundância.
z Modelo CORRETO
z Dois tipos de erros: sintáticos e semânticos
z Sintáticos ocorrem quando o modelo não respeita as regras de 
construção de um modelo ER
z Semânticos ocorrem quando o modelo, apesar de estar 
sintaticamente correto, reflete a realidade de forma inconsistente.
ƒ Estabelecer associações incorretas
ƒ Usar uma entidade do modelo como atributo de outra entidade
Banco de Dados Profª. Rossana Junqueira 44
Verificação do modelo
z Modelo COMPLETO
z Deve fixar todas as propriedades desejáveis do banco de dados.
z Somente pode ser verificado por alguém que conhece 
profundamente o sistema a ser implementado.
z Forma de verificar:
z Todos os dados que devem ser obtidos do banco de dados estão 
presentes?
z Todas as transações de modificação do banco de dados podem 
ser executadas sobre o modelo?
z Este requisito é aparentemente conflitante com a falta de poder de 
expressão de modelos ER.
Banco de Dados 45
Verificação do modelo
z Modelo deve ser livre de REDUNDÂNCIAS
z Modelo deve ser mínimo, isto é não deve conter conceitos 
redundantes
z Tipos de redundância:
z Relacionamentos redundantes Æ são relacionamentos que são 
resultados da combinação de outros relacionamentos entre as 
mesmas entidades.
ƒ Um relacionamento é redundante,
quando é
 
possível eliminá-lo do 
modelo ER, sem que haja perda 
de informações no banco de dados.
Banco de Dados Profª. Rossana Junqueira 46
Verificação do modelo
z Atributos redundantes Æ são atributos deriváveis a partir da 
execução de procedimentos de busca de dados e/ou cálculos 
sobre o banco de dados.
Banco de Dados Profª. Rossana Junqueira 47
Verificação do modelo
z Modelo deve refletir o aspecto temporal
z Dados temporais
z Dados que mudam ao longo do tempo e para as quais o BD 
mantém histórico
z Tipos de dados temporais:
z Atributos cujos valores modificam ao longo do tempo
z Relacionamentos que modificam ao longo do tempo
48
Verificação do modelo
z Consultas a dados referentes ao passado
z Muitas vezes, informações referentes ao passado são eliminadas 
da base de dados (arquivamento)
z Podem ser necessárias no futuro:
ƒ Por motivos legais
ƒ Para realização de auditorias
ƒ Para tomada de decisões
z Dados referentes ao passado – planejar arquivamento
z Solução que poderia ser considerada
ƒ Reincluir as informações no banco de dados, quando elas forem 
necessárias
ƒ Problema: restrições de integridade referencial
z Planejar informações estatísticas
ƒ Quando informações antigas são necessárias apenas para tomada de 
decisões
ƒ Pode ser conveniente manter no banco de dados informações 
compiladas e eliminar as informações usadas na compilação
Banco de Dados Profª. Rossana Junqueira 49
Verificação do modelo
z Entidade isolada e entidade sem atributos
z Caso raro, mas não incorreto
z Entidade que muitas vezes aparece isolada
z Caso típico:
z Entidade que modela a organização na qual o sistema 
implementado pelo BD está embutida
z Exemplo: BD de uma universidade
z A entidade UNIVERSIDADE pode ser necessária, caso se deseje 
manter no BD alguns atributos da universidade
z O modelo não deveria conter o relacionamento desta entidade com 
outras, como ALUNO ou CURSO
ƒ BD modela uma única universidade
ƒ Não é necessário informar no BD em que universidade o aluno está
inscrito ou a qual universidade o curso pertence
Banco de Dados 50
Estabelecimento de padrões
z Modelos de dados são usados para comunicação com:
z Pessoas da organização (usuários, analistas, programadores, ...)
z Programas (ferramentas CASE, geradores de código, ...)
z É necessário estabelecer padrões de confecção de modelos
z Na prática e na literatura aparecem muitas versões, que 
distinguem-se umas das outras não só na representação 
gráfica, isto é em sua sintaxe, mas também na semântica
z Variantes de abordagem ER
z Peter Chen (acadêmica)
z Engenharia de informações
z UML
z Merise (notação Européia)
Banco de Dados Profª. Rossana Junqueira 51
Estratégias de modelagem
z Uma seqüência de passos (uma “receita de bolo”) de 
transformação de modelos desde o modelo inicial de 
modelagem até o final
z Diferentes estratégias:
z Bottom-up Æ Parti de conceitos mais detalhados e abstrai 
gradativamente. Inicia com a identificação de atributos
z Top-down Æ Parti de conceitos mais abstratos e vai 
gradativamente refinando estes conceitos em conceitos mais 
detalhados. Inicia com a identificação de entidades genéricas
z Inside-out Æ De dentro pra fora. Parti de conceitos considerados 
importantes e vai gradativamente adicionando conceitos 
periféricos a eles relacionados
Banco de Dados Profª. Rossana Junqueira 52
Definição da estratégia de 
modelagem
z Na prática
z Nenhuma das estratégias propostas na literatura é universalmente 
aceita
z Normal
z Combinação das diversas estratégias de modelagem
z Compreensível
z Processo de modelagem é um processo de aprendizagem
Banco de Dados Profª. Rossana Junqueira 53
Capítulo 4: 
Abordagem relacional
Banco de Dados Profª. Rossana Junqueira 54
Abordagem Relacional
z Abordagem de modelagem de dados usada nos sistemas de 
gerência de banco de dados do tipo relacional;
z Composição de um banco de dados relacional:
z Tabelas
z Compostas de: linhas, colunas e chaves primárias
z Relacionadas através de chaves estrangeiras
z Terminologias:
Profissional Acadêmica
Tabela Relação
Linha Tupla
Coluna Atributo
Valor de campo Valor de atributo
Banco de Dados Profª. Rossana Junqueira 55
Abordagem Relacional
Banco de Dados Profª. Rossana Junqueira 56
Abordagem Relacional
z Características das tabelas:
z As linhas de ma tabela não têm ordenação
z Valores de campo:
z Atômicos Æ o campo não pode ser composto de outros
z Monovalorados Æ o campo possui um único valor
z Acesso por quaisquer critérios envolvendo os campos de uma ou 
mais linhas
z Programadores escrevem consultas sem considerar a existência de 
caminhos de acesso
z Caminho de acesso:
ƒ estrutura auxiliar (índice, cadeia de ponteiros,...)
ƒ acelera a recuperação de registros por determinados critérios
ƒ evita a leitura exaustiva de todos registros de um arquivo
Banco de Dados 57
Abordagem Relacional
z Chave Æ conceito usado para identificar e estabelecer 
relações entre linhas de tabelas de um banco de dados 
relacional.
z Três tipos:
z Chave Primária
z Chave Alternativa
z Chave Estrangeira
z Chave Primária Æ é uma coluna ou uma combinação de 
colunas cujos valores distinguem uma linha das demais dentro 
de uma tabela.
Banco de Dados Profª. Rossana Junqueira 58
Abordagem Relacional
z Chave Estrangeira Æ Uma coluna ou uma combinação de 
colunas, cujos valores aparecem necessariamente na chave 
primária de uma tabela
z Mecanismo que permite a implementação de relacionamentos em um 
banco de dados relacional
Abordagem Relacional
z Restrições que devem ser garantidas ao executar diversas 
operações de alteração do banco de dados:
z Quando da inclusão de uma linha na tabela que contém a chave 
estrangeira: o valor da chave estrangeira deve aparecer na coluna da 
chave primária referenciada
Ex: Um novo empregado deve atuar em um departamento já
 
existente no 
banco de dados.
z Quando da alteração do valor da chave estrangeira: o novo valor de uma 
chave estrangeira deve aparecer na coluna da chave primária 
referenciada
z Quando da exclusão de uma linha da tabela que contém a chave primária 
referenciada pela chave estrangeira: na coluna chave estrangeira não 
deve aparecer o valor da chave primária que está sendo excluída
Ex: Um departamento não pode ser excluído, caso nele ainda existirem 
empregados
z Quando da alteração do valor da chave primária referenciada pela chave 
estrangeira: na coluna chave estrangeira, não apareça o antigo valor da 
chaveprimária que está sendo alterada
Ex: Caso um departamento possua empregados, seu código não pode ser 
modificado
Banco de Dados Profª. Rossana Junqueira 60
Abordagem Relacional
z A palavra “estrangeira” pode levar a crer que a chave estrangeira 
sempre referencia uma chave primária de outra tabela.
z Esta restrição não existe.
z Um chave primária pode referenciar a chave primária da própria 
tabela.
61
Abordagem Relacional
z Chave Alternativa Æ Mais de uma coluna ou combinações de 
colunas podem servir para distinguir uma linha das demais
z Uma das colunas (ou combinação de colunas) é escolhida como 
chave primária
z As demais colunas ou combinações são denominadas chaves 
alternativas
Banco de Dados Profª. Rossana Junqueira 62
Abordagem Relacional
z Domínio de coluna Æ conjunto de valores que podem 
aparecer em uma coluna (atributo)
z Valor vazio:
z Um valor de campo pode assumir o valor especial vazio (“null” em 
inglês)
z Colunas nas quais não são admitidos valores vazios são chamadas 
de colunas obrigatórias
z Colunas nas quais podem aparecer campos vazios são chamadas de 
colunas opcionais
z Abordagem relacional:
z todas colunas que compõem a chave primária devem ser obrigatórias
z demais chaves podem conter colunas opcionais
Banco de Dados Profª. Rossana Junqueira 63
Abordagem Relacional
z Restrições de Integridade:
z Objetivo primordial de um SGBD é garantir a integridade de dados
z Dados refletem corretamente a realidade representada pelo bando de 
dados e que são consistentes entre si
z Para garantir a integridade de um banco de dados, SGBD oferecem o 
mecanismo de restrições de integridade
z Uma restrição de integridade é uma regra de consistência de dados 
que é garantida pelo próprio SGBD
z São classificadas nas seguintes categorias:
z Integridade de domínio Æ o valor de um campo deve obedecer a definição 
de valores admitidos para a coluna
z Integridade de vazio Æ é especificado se os campos de uma coluna 
podem ou não ser vazios.
Banco de Dados Profª. Rossana Junqueira 64
Abordagem Relacional
z Integridade de chave Æ define que os valores da chave primária e 
alternativa devem ser únicos
z Integridade referencial Æ define que os valores que aparecem em uma 
chave estrangeira devem aparecer na chave primária da tabela 
referenciada
z Restrições acima são garantidas automaticamente por um SGBD 
relacional
z Não é exigido que o programador escreva procedimentos para 
garanti-las explicitamente
z Restrições de integridade semânticas:
z Restrições de integridade que não se encaixam nas categorias 
básicas
z Exemplos de restrições semânticas:
z Um empregado do departamento denominado “Finanças” não pode ter a 
categoria funcional “Engenheiro”.
z Um empregado não pode ter um salário maior que seu superior 
imediato.
Banco de Dados Profª. Rossana Junqueira 65
Abordagem Relacional
z Modelo de banco de dados relacional
z A especificação de um banco de dados relacional, ou seja um 
modelo de banco de dados relacional (chamada de esquema do 
banco de dados) deve conter no mínimo a definição do seguinte:
z Tabelas que formam o banco de dados
z Colunas que as tabelas possuem
z Restrições de integridade
Banco de Dados Profª. Rossana Junqueira 66
Abordagem Relacional
z Esquema textual de BD relacional
Banco de Dados Profª. Rossana Junqueira 67
Abordagem Relacional
z Esquema diagramático de 
BD relacional
Banco de Dados Profª. Rossana Junqueira 68
Abordagem Relacional
z Consulta sobre o banco de dados:
z Na instrução SQL, o programador não faz referência a nenhum tipo 
de caminho de acesso. Quem decide que caminhos de acesso serão 
eventualmente usados quando da execução da instrução é o SGBD.
Banco de Dados Profª. Rossana Junqueira 69
Capítulo 5: 
Transformação entre 
modelos
Banco de Dados 70
Transformação entre modelos
z Dois processos de transformação de modelos:
z Visão geral do projeto lógico:
Banco de Dados Profª. Rossana Junqueira 71
Transformação entre modelos
z Transformação ER para relacional:
z Objetivos básicos:
z Boa performance;
z Simplificar o desenvolvimento;
z Ocupar pouco espaço em disco;
z Evitar junções :
ƒ Operação para buscar dados de diversas linhas associadas pela igualdade 
de campos
ƒ Exemplo:
ƒ buscar os dados de um empregado e os dados de seu departamento 
(duas tabelas diferentes)
ƒ SGBD relacional normalmente armazena os dados de uma linha 
contiguamente em disco
ƒ Junção envolve diversos acessos a disco
ƒ Preferível: ter os dados necessários a uma consulta em uma única linha
Banco de Dados Profª. Rossana Junqueira 72
Transformação entre modelos
z Chave e índice:
ƒ Implementação eficiente do controle de chaves: SGBD usa um índice –
Índices tendem a ocupar espaço considerável em disco
ƒ Inserção e remoção de entradas em um índice – Podem exigir diversos 
acesso a disco
ƒ Usar implementações com menos chaves
ƒ Exemplo:
Cliente (CodCliente,Nome,NomeContato,Endereço,Telefone)
ou
Cliente (CodCliente,Nome,NomeContato)
ClienteEnder (CodCliente,Endereço,Telefone)
CodCliente referencia Cliente
Banco de Dados Profª. Rossana Junqueira 73
Transformação entre modelos
z Campos Opcionais:
ƒ Campo opcional = campo que podem assumir o valor VAZIO (NULL em 
SQL).
ƒ SGBD relacional não desperdiça espaço pelo fato de campos de uma linha 
estarem vazios
ƒ Campo opcional não tem influência na performance
ƒ Controle de campo opcional pode complicar programação – Verificar quais 
campos podem estar vazios, quando isto depende do tipo de linha
z Passos da transformação ER para relacional:
z Tradução inicial de entidades e respectivos atributos
z Tradução de relacionamentos e respectivos atributos
z Tradução de generalizações/especializações
Banco de Dados Profª. Rossana Junqueira 74
Transformação entre modelos
z Implementação inicial de entidades
z Cada entidade é traduzida para uma tabela.
z Cada atributo da entidade define uma coluna desta tabela.
z Atributos identificadores da entidade correspondem a chave primária 
da tabela.
z Tradução inicial – Regras que seguem, as tabelas definidas nessa 
etapa ainda poderão ser fundidas.
z Ex:
Pessoa
código
nome
endereço
Data admissão
Data nascimento
Pessoa (CodPess, Nome, Endereço, Data Nasc, DataAdm)
Banco de Dados Profª. Rossana Junqueira 75
Transformação entre modelos
z Nome de atributos e Nomes de Colunas:
z Referenciados freqüentemente em programas e outras formas de texto em 
computador
z Para diminuir o trabalho de programadores – manter os nomes de colunas 
curtos.
z SGBD relacional – nome de uma coluna não pode conter brancos
z Não transcrever os nomes de atributos para nomes de colunas
z Nomes de atributos compostos de diversas palavras devem ser abreviados
z Nomes de colunas não necessitam conter o nome da tabela – Preferível 
usar o nome de coluna Nome a usar os nomes de coluna NomePess ou
NomePessoa
z SQL já exige muitas vezes formar - Pessoa.Nome
z Chave primária – pode aparecer em outras tabelas na forma de chave 
estrangeira
z Recomendável – nomes das colunas que compõem a chave primária 
sufixados ou prefixados com o nome ou sigla da tabela na qual aparecem 
como chave primária
z Exemplo: CodigoPess
Banco de Dados Profª. Rossana Junqueira 76
Transformação entre modelos
z Implementação de relacionamento
z Alternativas:
z Tabela própria
z Adição de colunas a uma das tabelas
z Fusão de tabelas
Alternativa depende da cardinalidade (máxima e mínima do relacionamento)
z Tabela própria
Engenheiro ProjetoAtuaçãon n
código
nome
função código
título
Engenheiro (CodEng, Nome)
Projeto (CodProj, Título)
Atuação (CodEng, CodProj, Função)
CodEng referencia Engenheiro
CodProj referencia Projeto
Banco de Dados Profª. Rossana Junqueira 77
Transformação entre modelos
z Adição de colunas
Departamento EmpregadoLotação1 n
código
nome
data lotação código
nome
Departamento (CodDept, Nome)
Empregado (CodEmp, Nome, 
CodDept, DataLota)
CodDept referencia Departamento
z Fusão de tabelas
Conferência ComissãoOrganização11
código
nome
Data instalação
ender
Conferência (CodConf, Nome, 
DataInstComOrg, EnderComOrg)
Banco de Dados Profª. Rossana Junqueira 78
Transformação entre modelos
z Implementação de relacionamentos Æ 1:1
Banco de Dados Profª. Rossana Junqueira 79
Transformação entre modelos
z 1:1 – Ambas entidades opcionais
Homem MulherCasamento
(0,1) (0,1)
identidade
nome
data identidade
títuloregime
Adição de colunas:
Mulher (IdentM, Nome, IdentH, Data, Regime)
IdentH referencia Homem
Homem (IdentH, Nome)
Tabela própria:
Mulher (IdentM, Nome)
Homem (IdentH, Nome)
Casamento (IdentM, IdentH, Data, 
Regime)
IdentM referencia Mulher
IdentH referencia HomemFusão de Tabelas: (NÃO USAR)
Casamento (IdentM, IdentH, NomeM, NomeH, Data, Regime)
Banco de Dados Profª. Rossana Junqueira 80
Transformação entre modelos
z 1:1 – Ambas entidades opcionais
z Solução por fusão de tabelas é inviável – Chave primária artificial
z Solução por adição de colunas: melhor opção
z Menor número de junções
z Menor número de chaves
z Solução por tabela própria: opção aceitável
Banco de Dados Profª. Rossana Junqueira 81
Transformação entre modelos
z 1:1 – Uma entidade opcional outra obrigatória
Correntista Cartão Magnético
(1,1) (0,1)
código
nome
código
Data expedição
Adição de colunas:
Correntista (CodCorrent, Nome)
Cartão (CodCartão, DataExp, CodCorrent)
CodCorrent referencia Correntista
Tabela própria: (NÃO USAR)
Correntista (CodCorrent, Nome)
Cartão (CodCartão, DataExp)
CartãoCorrentista (CodCartão, 
CodCorrent)
CodCorrent
 
referencia 
Correntista
CodCartão referencia Cartão
Fusão de Tabelas:
Correntista (CodCorrent, Nome, CodCartão, DataExp)
Banco de Dados Profª. Rossana Junqueira 82
Transformação entre modelos
z 1:1 – Uma entidade opcional outra obrigatória
z Solução por tabela própria é pior que a solução por adição de 
colunas
z Maior número de junções
z Maior número de índices
z Nenhuma têm problema de campos opcionais
z Adição de colunas versus fusão de tabelas
z Fusão de tabelas é melhor em termos de número de junções e número de 
chaves
z Adição de colunas em melhor em termos de campos opcionais
z Fusão de tabelas é considerada a melhor opção e adição de colunas é
aceitável
Banco de Dados Profª. Rossana Junqueira 83
Transformação entre modelos
z 1:1 – Ambas entidades tem participação obrigatória
Fusão de Tabelas:
Conferência (CodConf, Nome, DataInstComOrg, EnderComOrg)
Conferência ComissãoOrganização
(1,1) (1,1)
código
nome
Data instalação
ender
z Nenhuma das demais alternativas atende plenamente
z Entidades que participam do relacionamento seriam representadas 
através de duas tabelas distintas
z Estas tabelas teriam a mesma chave primária e relação um-para-um entre 
suas linhas
z Maior número de junções
z Maior número de chaves primárias
Banco de Dados Profª. Rossana Junqueira 84
Transformação entre modelos
z Implementação de relacionamentos Æ 1: n
Banco de Dados 85
Transformação entre modelos
z 1:n – A entidade que tem cardinalidade máxima 1 é obrigatória
Departamento EmpregadoLotação
(1,1) (0,n)
código
nome
data lotação código
nome
Adição de Colunas:
Departamento (CodDept, Nome)
Empregado (CodEmp, Nome, CodDept, DataLota)
CodDept referencia Departamento
Tabela própria:
Departamento (CodDept, Nome)
Empregado (CodEmp, Nome)
Lotação (CodEmp, CodDept, DataLota)
CodDept referencia Departamento
CodEmp referencia Empregado
Banco de Dados Profª. Rossana Junqueira 86
Transformação entre modelos
z 1:n – A entidade que tem cardinalidade máxima 1 é obrigatória
z Fusão de tabelas
z Não se aplica
z Implicaria em:
ƒ redundância de dados de departamento, ou
ƒ tabela aninhada
z Adição de colunas é melhor que tabela própria:
ƒ Menor número de chaves
ƒ Menor número de junções
ƒ Não há o problema de campos opcionais
Banco de Dados 87
Transformação entre modelos
z 1:n – A entidade que tem cardinalidade máxima 1 é opcional
Financeira VendaFinanciam
(0,1) (0,n)
código
nome
taxa de juros id
data
Adição de Colunas:
Financeira (CodFin, Nome)
Venda (IdVend, Data, CodFin, NoParc, TxJuros)
CodFin referencia Financeira
Tabela própria:
Financeira (CodFin, Nome)
Venda (IdVend, Data)
Financiam (IdVend, CodFin, NoParc, TxJuros)
IdVend referencia Venda
CodFin referencia Financeira
nº
 
de
parcelas
z Implementação por tabela 
própria também é
aceitável:
z É melhor em relação a 
campos opcionais
z Perde em relação a 
junções e número de 
chaves
Banco de Dados Profª. Rossana Junqueira 88
Transformação entre modelos
z Implementação de relacionamentos Æ n : n
Banco de Dados 89
Transformação entre modelos
z n:n
Tabela própria:
Engenheiro (CodEng, Nome)
Projeto (CodProj, Título)
Atuação (CodEng, CodProj, Função)
CodEng referencia Engenheiro
CodProj referencia Projeto
Engenheiro ProjetoAtuação
(0,n) (0,n)
código
nome
função código
título
Banco de Dados 90
Transformação entre modelos
z Relacionamentos de grau maior que 
dois
z Não são definidas regras específicas
z O relacionamento é transformado em 
uma entidade
Produto (CodProd, Nome)
Cidade (CodCid, Nome)
Distribuidor (CodDistr, Nome)
Distribuição (CodProd, CodDistr, CodCid, 
DataInicio)
CodProd referencia Produto
CodDistr referencia Distribuidor
CodCid referencia Cidade
Banco de Dados 91
Transformação entre modelos
z Implementação de 
generalização / especialização
z Duas alternativas básicas:
z uso de uma tabela para cada 
entidade
z uso de uma única tabela para 
toda hierarquia
z Outra alternativa (exótica): 
Subdivisão de entidade genérica
Banco de Dados 92
Transformação entre modelos
z Implementação de generalização / especialização
z Uma tabela por hierarquia:
z Todas as tabelas referentes às especializações são fundidas em uma 
única tabela
z Tabela contém:
ƒ Chave primária correspondente ao identificador da entidade mais 
genérica
ƒ Caso não exista, adicionar uma coluna Tipo
ƒ Uma coluna para cada atributo da entidade genérica
ƒ Colunas referentes aos relacionamentos dos quais participa a entidade 
genérica e que sejam implementados através da alternativa de adicionar 
colunas à tabela da entidade genérica
ƒ Uma coluna para cada atributo de cada entidade especializada (opcional)
ƒ Colunas referentes aos relacionamentos dos quais participa cada 
entidade especializada e que sejam implementados através da alternativa 
de adicionar colunas à tabela da entidade (campo opcional)
Banco de Dados 93
Transformação entre modelos
z Implementação de generalização / especialização
z Uma tabela por hierarquia:
Emp (CódigoEmp, Tipo, Nome, CIC, CodigoDept, CartHabil, CREA, 
CódigoRamo)
CódigoDept referencia Depto
CódigoRamo referencia Ramo
Depto (CódigoDept, Nome)
Ramo (CódigoRamo, Nome)
ProcessTexto (CódigoProc, Nome)
Domínio (CódigoEmp, CódigoProc)
CódigoEmp referencia Emp
CódigoProc referencia ProcessTexto
Projeto (CódigoProj, Nome)
Participação (CódigoEmp, CodigoProj)
CódigoEmp referencia Emp
CódigoProj referencia Projeto
Banco de Dados 94
Transformação entre modelos
z Implementação de 
generalização/especializaç
ão
z Uma tabela por entidade 
especializada:
z Criar uma tabela para cada 
entidade que compõe a 
hierarquia
z Incluir a chave primária da 
tabela correspondente à
entidade genérica, em cada 
tabela correspondente a 
uma entidade especializada
Emp (CódigoEmp, Tipo, Nome, CIC,
 
 
CódigoDept)
CódigoDept referencia Depto
Motorista (CódigoEmp, CartHabil)
CódigoEmp referencia Emp
Engenheiro (CódigoEmp, CREA,
 
 
CódigoRamo)
CódigoEmp referencia Emp
CódigoRamo referencia Ramo
Depto (CódigoDept, Nome)
Ramo (CódigoRamo, Nome)
ProcessTexto (CódigoProc, Nome)
Domínio (CódigoEmp, CódigoProc)
CódigoEmp referencia Emp
Código Proc referencia 
ProcessTexto
Projeto (CódigoProj, Nome)
Participação (CódigoEmp, CódigoProj)
CódigoEmp referencia Engenheiro
CódigoProj referencia Projeto
Banco de Dados Profª. Rossana Junqueira 95
Transformação entre modelos
z Implementação de generalização / especialização
z Vantagens da implementação com tabela única:z Dados referentes à entidade genérica + dados referentes às 
especializações – em uma única linha
z Minimiza junções
z Menor número de chaves
z Vantagens da implementação com uma tabela por entidade 
especializada:
z Colunas opcionais – apenas aquelas referentes a atributos que podem 
ser vazios do ponto de vista da aplicação
Banco de Dados Profª. Rossana Junqueira 96
Transformação entre modelos
z Refinamento do modelo relacional
z Projeto (engenharia) em geral – compromisso entre o ideal e o 
realizável dentro das restrições de recursos impostas pelas prática
z Projeto de banco de dados – compromisso entre o ideal (regras de 
implementação) e o alcançável frente a limitações de performance
z Algumas vezes – esquema de BD criado através do uso das regras 
acima não atende requisitos de performance impostos ao sistema
z Necessário buscar alternativa que resulte em melhor performance 
do sistema
z Alternativas somente devem ser tentadas em último caso - do 
ponto de vista da programação são sempre piores
z Exemplos: Relacionamentos mutuamente exclusivos e Simulação 
de atributos multivalorados
Banco de Dados Profª. Rossana Junqueira 97
Transformação entre modelos
z Relacionamentos mutuamente 
exclusivos:
z Implementação pelas regras -
colunas CIC e CGC em Venda 
são especificadas como opcionais
PessFis (CIC, Nome)
PessJur (CGC, RazSoc)
Venda (No, data, CIC, CGC)
CIC referencia PessFis
CGC referencia PessJur
z colunas CIC e CGC em Venda 
são especificadas como opcionais
Banco de Dados Profª. Rossana Junqueira 98
Transformação entre modelos
z Relacionamentos mutuamente exclusivos:
z Implementação alternativa - criar uma única coluna na qual aparece o 
CIC ou o CGC do comprador
PessFis (CIC, Nome)
PessJur (CGC, RazSoc)
Venda (No, data, CIC/CGC, TipoCompr)
z Desvantagem:
ƒ Não é possível especificar ao SGBD que o campo CIC/CGC é chave 
estrangeira
ƒ Não referencia uma única tabela
Banco de Dados Profª. Rossana Junqueira 99
Transformação entre modelos
z Tratamento de atributos 
multivalorados:
Cliente (CodCli, Nome)
Telefone (CodCli, Número)
CodCli referencia Cliente
z Condições de contorno:
ƒ Raros clientes possuem mais que dois 
telefones.
ƒ Quando isso ocorrer: é suficiente 
armazenarmos apenas dois números
ƒ Não há consultas ao banco de dados 
usando o número de telefone como 
critério de seleção
ƒ Números de telefone são apenas 
exibidos ou impressos juntos às demais 
informações de cliente
Banco de Dados Profª. Rossana Junqueira 100
Transformação entre modelos
z Tratamento de atributos multivalorados:
z Implementação “desnormalizada”
Cliente (CodCli,Nome,NumTel1,NumTel2)
z Simular uma coluna multi-valorada através da criação de diversas 
colunas NumTel sufixadas por um número
z Permite que os telefones de um cliente sejam obtidos mais 
rapidamente
z Implica em menos espaço ocupado – não é necessária chave primária 
da tabela Telefone
z Inconveniente
z Consulta usando o número de telefone como critério de busca torna-se 
mais complicada
z Manter os telefones "alinhados à esquerda" exige rotina complexa
Banco de Dados Profª. Rossana Junqueira 101
Transformação entre modelos
z Engenharia reversa de modelos relacionais:
z Parte de modelo de implementação
z Obtém modelo de especificação (modelo conceitual)
z Passos:
z Identificação da construção ER correspondente a cada tabela
z Definição de relacionamentos 1:n e 1:1
z Definição de atributos
z Definição de identificadores de entidades e relacionamentos
Banco de Dados Profª. Rossana Junqueira 102
Transformação entre modelos
z Ex:
Disciplina (CodDisc, NomeDisc)
Curso (CodCr, NomeCr)
Curric (CodCr, CodDisc, Obr/Opc)
CodCr referencia Curso
CodDisc referencia Disciplina
Sala (CodPr, CodSl, Capacidade)
CodPr referencia Prédio
Prédio (CodPr, Endereço)
Turma (Anosem, CodDisc, SiglaTur, Capacidade, CodPr, CodSl)
CodDisc referencia Disciplina
(CodPr, CodSl) referencia Sala
Laboratório ( CodPr, CodSl, Equipam)
(CodPr, CodSl) referencia Sala
Banco de Dados 103
Transformação entre modelos
z Identificação da construção ER correspondente a cada 
tabela
z Uma tabela pode corresponder a:
z uma entidade
z um relacionamento n:n
z uma entidade especializada
z Fator determinante
z composição de sua chave primária
Banco de Dados Profª. Rossana Junqueira 104
Transformação entre modelos
z Ex:
Disciplina (CodDisc, NomeDisc) entidade
Curso (CodCr, NomeCr) entidade
Curric (CodCr, CodDisc, Obr/Opc) relacionamento n:n
CodCr referencia Curso
CodDisc referencia Disciplina
Sala (CodPr, CodSl, Capacidade) entidade
CodPr referencia Prédio
Prédio (CodPr, Endereço) entidade
Turma (Anosem, CodDisc, SiglaTur, Capacidade, CodPr, CodSl) entidade
CodDisc referencia Disciplina
(CodPr, CodSl) referencia Sala
Laboratório ( CodPr, CodSl, Equipam) especialização
(CodPr, CodSl) referencia Sala
Banco de Dados Profª. Rossana Junqueira 105
Transformação entre modelos
z Construções identificadas:
Turma
Prédio
Sala
Laboratório
Curso
Disciplina
Currículo
n
n
Banco de Dados Profª. Rossana Junqueira 106
Transformação entre modelos
z Identificação de relacionamentos 1:n ou 1:1
z Chave estrangeira que não se enquadra nas regras acima – representa 
relacionamento 1:n ou relacionamento 1:1
z Esquema não informa se é 1:1 ou 1:n
z Chave estrangeira é parte de uma chave primária trata-se de um 
relacionamento 1:n
z Nos demais casos, para definir a cardinalidade, é necessário verificar os 
possíveis conteúdos do banco de dados
Banco de Dados 107
Transformação entre modelos
z Construções identificadas:
Turma
Prédio
Sala
Laboratório
Curso
Disciplina
CurrículoCurrículo
Currículo
Currículo
n
n
1n
n
1
n
1
108
Transformação entre modelos
z Definição de atributos:
z Cada coluna não chave 
estrangeira é um atributo na 
entidade/relacionamento 
correspondente à tabela
z As colunas chave estrangeira não 
correspondem a atributos 
correspondem a relacionamentos
z Definição de identificadores de 
entidades:
z Coluna da chave primária que 
não é chave estrangeira 
corresponde a um atributo 
identificador da entidade ou 
relacionamento.
z Coluna da chave primária que é
chave estrangeira corresponde a 
um relacionamento identificador 
da entidade
Banco de Dados Profª. Rossana Junqueira 109
Capítulo 6: 
Normalização
Banco de Dados Profª. Rossana Junqueira 110
Normalização
z Sistemas de informação hoje usados não utilizam bancos de 
dados relacionais – Sistemas legados (dados armazenados 
em arquivos de linguagens de 3ª geração).
z Raramente documentados.
z Necessidade de modelo ER:
z Manutenção
z Migração para outro tipo de BD
z Integração com outros BD
Banco de Dados Profª. Rossana Junqueira 111
Normalização
Banco de Dados Profª. Rossana Junqueira 112
Normalização
z Objetivo:
z Reagrupar informações para eliminar redundâncias de dados
z Reagrupar informações para eliminar estruturas inexistentes no 
modelo ER (atributos multivalorados)
z Passos:
113
Normalização
z Documento exemplo:
Código do Projeto: LSC001 Tipo: Novo desenvolvimento
Descrição: Sistema de Estoque
Código do 
Empregado
Nome Categoria 
Funcional
Salário Data início no 
projeto
Tempo 
alocado ao 
projeto
2146 João A1 4 01/11/91 24
3145 Sílvio A2 4 02/10/91 24
6126 José B1 9 03/10/92 18
1214 Carlos A2 4 04/10/92 18
8191 Mário A1 4 01/11/92 12
Código do Projeto: PAG02 Tipo: Manutenção
Descrição: Sistema de RH
Código do 
Empregado
Nome Categoria 
Funcional
Salário Data início no 
projeto
Tempo alocado 
ao projeto
8191 Mário A1 4 01/05/93 12
4112 João A2 4 04/01/91 24
6126 José B1 9 01/11/92 12
Banco de Dados 114
Normalização
z Representação na forma de tabela não normalizada:
z Tabela não-normalizada ou tabela não-primeira-forma-normal
z possui uma ou mais tabelas aninhadas
z tabela aninhada ( ou grupo repetido ou coluna multivalorada ou coluna 
não atômica) - coluna que ao invés de conter valores atômicos, contém 
tabelas aninhadas
z Abreviatura: ÑN
z Exemplo:
Proj (CodProj,Tipo,Descr,
(CodEmp, Nome, Cat, Sal, DataIni, TempAl))
Banco de Dados Profª. Rossana Junqueira 115
Normalização
z Forma Normal:
z Regra que uma tabela deve obedecer para ser considerada “bem 
projetada”
z Há diversas formas normais, cada vez mais rígidas, para verificar 
tabelas relacionais
z Aqui tratadas:
z primeira forma normal (1FN)
z segunda forma normal (2FN)
z terceira forma normal (3FN)
Banco de Dados Profª. Rossana Junqueira 116
Normalização
z Passagem à primeira forma normal (1FN)
z Alternativas:
z Uma única tabela
ƒ Uma tabela na qual os dados das linhas externas à tabela aninhada são 
repetidos para cada linha da tabela aninhada
ƒ Exemplo:
ProjEmp (CodProj, Tipo, Descr, CodEmp, Nome, Cat, Sal, DataIni, 
TempAl)
ƒ Dados do projeto aparecem repetidos para cada empregado do projeto
Banco de Dados Profª. Rossana Junqueira 117
Normalização
z Uma tabela para cada tabela aninhada
ƒ Cria-se uma tabela referente a própria tabela que está sendo normalizada e 
uma tabela para cada tabela aninhada
ƒ Exemplo:
Proj (CodProj, Tipo, Descr)
ProjEmp (CodProj,CodEmp, Nome, Cat, Sal, DataIni, TempAl)
z Primeira alternativa (tabela única) é mais correta
z Decompor uma tabela em várias tabelas (segunda alternativa) –
podem ser perdidas relações entre informações
z Para fins práticos – preferimos a segunda alternativa (decomposição 
de tabelas)
z Quando houver diversas tabelas aninhadas, eventualmente com 
diversos níveis de aninhamento, fica difícil visualizar a tabela na 1FN 
na alternativa de tabela única
Banco de Dados Profª. Rossana Junqueira 118
Normalização
z Passo 1:
z Criar uma tabela na 1FN referente a tabela não normalizada
z A chave primária da tabela na 1FN é idêntica a chave da tabela ÑN
Criar tabela referente a tabela ÑN
Banco de Dados Profª. Rossana Junqueira 119
Normalização
z Passo 2:
z Para cada tabela aninhada criar uma tabela na 1FN composta pelas
seguintes colunas:
ƒ a chave primária de cada uma das tabelas na qual a tabela em questão está
aninhada
ƒ as colunas da própria tabela aninhada
Criar tabela referente a tabela aninhada
Banco de Dados Profª. Rossana Junqueira 120
Normalização
z Passo 3:
z Definir as chaves primárias das tabelas na 1FN que correspondem a 
tabelas aninhadas.
Definição da chave primária
Banco de Dados Profª. Rossana Junqueira 121
Normalização
Normalização
z Exemplo na 1FN:
CodProj Tipo Descr
LSC001 Novo Desenvol. Sistema
PAG02 Manutenção Sistema de RH
CodProj CodEmp Nome Cat Sal DataIni TempAl
LSC001 2146 João A1 4 01/11/91 24
LSC001 3145 Sílvio A2 4 02/10/91 24
LSC001 6126 José B1 9 03/10/92 18
LSC001 1214 Carlos A2 4 04/10/92 18
LSC001 8191 Mário A1 4 01/11/92 12
PAG02 8191 Mário A1 4 01/05/93 12
PAG02 4112 João A2 4 04/01/91 24
PAG02 6126 José B1 9 01/11/92 12
ProjEmp
Proj
Banco de Dados Profª. Rossana Junqueira 123
Normalização
z Dependência Funcional:
z Para entender 2FN e 3FN – é necessário compreender o conceito de 
dependência funcional.
z Em uma tabela relacional, diz-se que – uma coluna C2 depende 
funcionalmente de uma coluna C1 (ou que a coluna C1 determina a 
coluna C2) quando, em todas linhas da tabela, para cada valor de C1 
que aparece na tabela, aparece o mesmo valor de C2.
124
Normalização
z Segunda forma normal 2FN:
z Objetiva eliminar um certo tipo de redundância de dados
z Exemplo:
(CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl)
z Dados referentes a empregados (Nome, Cat e Sal) – Redundantes, 
para os empregados que trabalham em mais de um projeto
CodProj CodEmp Nome Cat Sal DataIni TempAl
LSC001 2146 João A1 4 01/11/91 24
LSC001 3145 Sílvio A2 4 02/10/91 24
LSC001 6126 José B1 9 03/10/92 18
LSC001 1214 Carlos A2 4 04/10/92 18
LSC001 8191 Mário A1 4 01/11/92 12
PAG02 8191 Mário A1 4 01/05/93 12
PAG02 4112 João A2 4 04/01/91 24
PAG02 6126 José B1 9 01/11/92 12
ProjEmp
125
Normalização
z Segunda forma normal 2FN:
Æ Dependências parciais
Æ Dependências não parciais
126
Normalização
z Segunda forma normal 2FN:
z Tabela 1FN e que possui apenas uma coluna como chave primária –
não contém dependências parciais
z É impossível uma coluna depender de uma parte da chave primária, 
quando a chave primária não é composta por partes
z Conclusão – Toda tabela 1FN que possui apenas uma coluna como 
chave primária já está na 2FN
127
Normalização
z Segunda forma normal 2FN:
z Tabela que contenha apenas colunas chave primária
z Impossível atributo não chave depender de parte da chave (tabela 
não tem colunas não chave)
z Tabela sem colunas não chave já está na 2FN
128
Normalização
z Segunda forma normal 2FN:
Banco de Dados Profª. Rossana Junqueira 129
Normalização
z Segunda forma normal 2FN:
130
Normalização
z Terceira forma normal 3FN:
z Trata de um outro tipo de redundância
z Exemplo: Emp (CodEmp, Nome, Cat, Sal)
z Considerar: – salário (coluna Sal) é determinado pela categoria 
funcional (coluna Cat)
z Salário que é pago a uma categoria funcional é armazenado tantas 
vezes quantos empregados possui a categoria funcional
131
Normalização
z Terceira forma normal 3FN:
z Trata de um outro tipo de redundância
z Exemplo: Emp (CodEmp, Nome, Cat, Sal)
z Considerar: – salário (coluna Sal) é determinado pela categoria 
funcional (coluna Cat)
z Salário que é pago a uma categoria funcional é armazenado tantas 
vezes quantos empregados possui a categoria funcional
Banco de Dados Profª. Rossana Junqueira 132
Normalização
z Terceira forma normal 3FN:
Proj (CodProj, Tipo, Descr)
ProjEmp (CodProj, CodEmp, DataIni, TempAl)
Emp (CodEmp, Nome, Cat)
Cat (Cat, Sal)
Banco de Dados Profª. Rossana Junqueira 133
Normalização
z Normalização do exemplo:
z ÑN
Proj (CodProj,Tipo, Descr,
(CodEmp, Nome, Cat, Sal, DataIni, TempAl))
z 1FN
Proj (CodProj, Tipo, Descr)
ProjEmp (CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl)
z 2FN
Proj (CodProj, Tipo, Descr)
ProjEmp (CodProj, CodEmp, DataIni, TempAl)
Emp (CodEmp, Nome, Cat, Sal)
z 3FN
Proj (CodProj, Tipo, Descr)
ProjEmp (CodProj, CodEmp, DataIni, TempAl)
Emp (CodEmp, Nome, Cat)
Cat (Cat, Sal)
Banco de Dados Profª. Rossana Junqueira 134
Normalização
z Tabelas na 3FN:
Normalização
z Problemas de normalização:
z Chaves primárias omitidas ou incorretas
z Arquivos convencionais:
ƒ o conceito de chave primária não é obrigatório
ƒ é possível encontrar arquivos que não possuem chave primária
z Quando um arquivo convencional não possui chave primária ou quando a 
chave primária nele usada difere da usual na organização:
ƒ deve-se proceder como se a chave primária aparecesse no arquivo
ƒ deve-se inseri-la na forma ÑN
z Arquivo com dados sobre empregados de uma organização enviado para 
fins de fiscalização a um órgão governamental
z Identificador de empregado usado na organização é omitido, já que este é
irrelevante para o órgão fiscalizador
z Outra situação: uso de uma chave alternativa, ao invés da chave primária 
usual do arquivo
z No caso mencionado acima: Se o órgão governamental fosse a receita 
federal, arquivo poderia ter como chave primária o CIC do empregado, ao 
invés da chave primária normalmente usada na organização.
Banco de Dados Profª. Rossana Junqueira 136
Normalização
z Problemas de normalização:
z Atributos relevantes implicitamente representados
z Arquivos convencionais podem conter atributos de forma implícita
ƒ ordenação de registros ou de listas
ƒ ponteiros físicos, etc
z Deve-se proceder como se o atributo aparecesse explicitamente 
no documento
z Exemplo:
ƒ arquivo contém registros referentes a cursos em um concurso vestibular
ƒ para cada curso, há um grupo repetido aninhado, com as informações dos 
candidatos ao curso em questão
ƒ informações dos candidatos ordenadas por classificação no concurso
Banco de Dados Profª. Rossana Junqueira 137
Normalização
z Problemas de normalização:
z Atributos irrelevantes, redundantes ou derivados
z Devem ser eliminados já quando da passagem a forma não normalizada
Banco de Dados Profª. Rossana Junqueira 138
Capítulo 7: SQLBanco de Dados Profª. Rossana Junqueira 139
Criação de Banco de Dados
z Conjunto de objetos que armazenam e manipulam dados.
z Como nomear arquivos e objetos:
z Regras para nomeação dos objetos:
z Caracteres A...Z, a...z, 0...9, $ e _
z Nomes devem começar com A...Z ou a...z.
z Nomes limitados a 31 caracteres.
z Nomes dos objetos devem ser únicos.
z CREATE DATABASE ‘C:\Banco de Dados\empresa.fdb’;
Criação de Tabelas
z Restrições a serem especificadas para uma coluna de tabela:
z Regras que governam os relacionamentos e validam entradas de dados.
z Atuam em todas as transações que acessam o banco de dados e são 
automaticamente mantidas pelo sistema.
z Restrição UNIQUE e PRIMARY KEY:
z Asseguram que os valores inseridos em uma ou mais colunas são únicos para 
cada linha da tabela.
z Uma ou mais colunas definidas com essas restrições devem também ser 
definidas com o atributo NOT NULL.
z Restrição FOREIGN KEY:
z Chave estrangeira é uma ou mais colunas em uma tabela que corresponde 
exatamente a uma ou mais colunas definida(s) como chave primária em outra 
tabela.
z Restrição CHECK:
z Estabelece uma condição que deve ser verdadeira durante uma entrada ou 
atualização de dados na tabela.
z Além dessas restrições, uma coluna pode ser definida com o atributo 
NOT NULL. Esse atributo não permite valores nulos na coluna onde é
definida e é obrigatório em colunas com restrições PRIMARY KEY ou 
UNIQUE.
Banco de Dados Profª. Rossana Junqueira 141
Criação de Tabelas
z CREATE TABLE cria uma nova tabela, suas colunas e restrições de 
integridade em um banco de dados.
z Tabela Fabrica
CREATE TABLE FABRICA (
ID_FABRICA INTEGER NOT NULL,
NOME VARCHAR(40) NOT NULL,
ENDERECO VARCHAR(40),
CIDADE VARCHAR(30),
UF CHAR(2),
TELEFONE VARCHAR(20),
CONSTRAINT PK_FABRICA PRIMARY KEY (ID_FABRICA));
Banco de Dados Profª. Rossana Junqueira 142
Criação de Tabelas
z Tabela Produto
CREATE TABLE Produto
(Id_Produto
 
INTEGER NOT NULL,
Referencia
 
VARCHAR(15),
Descricao
 
VARCHAR(40) NOT NULL,
Unidade
 
CHAR(2) DEFAULT 'UN' NOT NULL,
Id_Fabrica
 
INTEGER NOT NULL,
Id_ProdutoC
 
INTEGER NOT NULL,
CONSTRAINT PK_PRODUTO PRIMARY KEY (ID_PRODUTO),
CONSTRAINT FK_PRODUTO_FABRICA FOREIGN KEY (ID_FABRICA) 
REFERENCES Fabrica (Id_Fabrica),
CONSTRAINT FK_PRODUTO_PRODUTO FOREIGN KEY 
(ID_PRODUTOC) REFERENCES Produto (Id_Produto));
Banco de Dados Profª. Rossana Junqueira 143
Alteração de Tabelas
z ALTER TABLE modifica uma tabela adicionando, modificando ou 
eliminando colunas ou restrições.
z Para alterar uma tabela, deve-se observar o seguinte:
z Uma tabela pode ser alterada por seu criador ou qualquer usuário com 
direitos de superusuário do sistema operacional.
z ALTER TABLE provoca erro se os novos dados em uma tabela violam 
as definições de restrição PRIMARY KEY ou UNIQUE.
z Eliminar uma coluna provoca falha se:
z A coluna é parte de uma restrição UNIQUE, PRIMARY KEY ou FOREING 
KEY.
z A coluna é usada em uma restrição CHECK.
z A coluna é utilizada em uma expressão value de uma coluna calculada.
z A coluna é referenciada por outros objetos, tais como uma visão.
Banco de Dados Profª. Rossana Junqueira 144
Alteração de Tabelas
z Exemplos de utilização de ALTER TABLE:
z Incluir nova coluna
z ALTER TABLE Fabrica ADD Email VARCHAR(30);
z ALTER TABLE Fabrica
ADD Contato VARCHAR(30) NOT NULL,
ADD Fax VARCHAR(18);
z Eliminar uma coluna existente
z ALTER TABLE Fabrica DROP Fax;
z Alterar a posição de uma coluna
z ALTER TABLE Produto ALTER Id_ProdutoC POSITION 5;
Banco de Dados Profª. Rossana Junqueira 145
Alteração de Tabelas
z Exemplos de utilização de ALTER TABLE:
z Alterar o tipo de dado de uma coluna
z ALTER TABLE Fabrica ALTER Email TYPE VARCHAR(40);
z Obs: Tamanhos de tipos não podem ser reduzidos e o novo tipo de dado 
deve ser capaz de manter os dados originais.
z Alterar o nome da coluna
z ALTER TABLE Fabrica ALTER Nome TO RazaoSocial;
z Adicionar uma nova restrição
z ALTER TABLE Fabrica ADD CONSTRAINT Un_Mail UNIQUE (Email);
z Eliminar uma restrição existente
z ALTER TABLE Fabrica DROP CONSTRAINT Un_Mail;
Banco de Dados Profª. Rossana Junqueira 146
Exclusão de Tabelas
z A instrução DROP TABLE remove dados de tabela.
z Não se pode eliminar uma tabela que é referenciada em uma coluna 
calculada, uma visão, restrição de chave estrangeira ou 
procedimento armazenado. 
z DROP TABLE [nome da tabela]
Banco de Dados Profª. Rossana Junqueira 147
Povoamento de Tabelas
z INSERT armazena uma ou mais linhas de dados em uma tabela.
z Os valores inseridos devem estar na mesma ordem das colunas da 
tabela.
z Se o número de colunas informadas no comando for menor que o 
número de colunas da tabela, valores padrões ou NULL são 
armazenados nas colunas não informadas.
z Para inserir uma única linha de dados na tabela, deve-se especificar 
uma lista de valores na cláusula VALUES.
z Inserções de dados nas tabelas não podem violar as restrições.
z É importante inserir dados primeiramente nas tabelas referenciadas 
por chaves estrangeiras.
Banco de Dados Profª. Rossana Junqueira 148
Povoamento de Tabelas
z Exemplos:
z INSERT INTO Vendedor VALUES (1, ‘João Dias’);
z A instrução seguinte insere uma linha na mesma tabela, mas informa 
explicitamente as colunas para as quais serão informados:
z INSERT INTO Vendedor (Id_Vendedor, Nome)
VALUES (2, ‘Fábio Almeida’);
z INSERT INTO Cliente VALUES (1, ‘Francisco de Assis’, ‘Av. Principal, 
500’, ‘Santarém’, ‘PA’, ‘3522-0101’, ‘Francisco’);
Povoamento de Tabelas
z INSERT INTO Transportadora VALUES (1, ‘Transpedroso’, ‘Av. Getúlio 
Vargas, 500’, ‘São Paulo’, ‘SP’);
z INSERT INTO Pedido VALUES (1, ’06/15/2005’, 500, 1, 1, 1);
z O campo data é inserido no formato mm/dd/aaaa
z INSERT INTO Fabrica (Id_Fabrica, RazaoSocial, UF)
VALUES (1, ’CAP Computadores Ltda’, ‘SP’);
z INSERT INTO Produto VALUES (1, null, 'Microcomputador', 'UN', null, 
1);
z As colunas Referencia e Id_ProdutoC da tabela Produto permitem valores 
nulos e esta é uma maneira de inserir nulos.
z A outra é a maneira como foi inserida a linha na tabela Fabrica. Omitiram-
se as colunas que receberão valores nulos.
Banco de Dados Profª. Rossana Junqueira 150
Alteração de dados
z A instrução UPDATE modifica os dados em toda ou parte de uma 
linha de uma tabela.
z Em caso de atualizações seletivas, a cláusula opcional WHERE 
pode ser usada para restringir as atualizações a um subconjunto de 
linhas na tabela.
z Se a cláusula WHERE não for utilizada, todas as linhas da tabela 
serão atualizadas.
z O seguinte comando modifica as linhas da tabela. Esse comando 
calcula um novo preço para todos os produtos, reajustando-os em 
5%:
z UPDATE ProdutoCond SET Preco = Preco * 1.05;
Banco de Dados Profª. Rossana Junqueira 151
Alteração de dados
z O comando a seguir modifica apenas uma linha da tabela. Modifica
a descrição do produto que tem chave primária igual a 2:
z UPDATE Produto SET Descricao = ‘Monitor de vídeo 15”’
WHERE Id_Produto = 2;
z Quando for necessário alterar os dados de uma única linha é
aconselhável selecioná-la pela chave primária. Este é a garantia de que 
a atualização ocorrerá em uma única linha, no máximo.
z UPDATE Pedido SET Id_Transportadora = 1, Id_Vendedor = 2 
WHERE Data = ’06/15/2005’;
z O comando acima modifica dados de duas colunas dos pedidos 
efetuados em 15/06/2005. 
Banco de Dados Profª. Rossana Junqueira 152
Exclusão de linhas
z O comando DELETE elimina linhas de uma tabela.
z Especifica uma ou mais linhas a serem eliminadas de uma tabela.
z No caso de deleções seletivas, a cláusula WHERE deve ser 
utilizada para restringir as exclusões a um subconjunto de linhas de 
uma tabela.
z Se a cláusula WHERE não for especificada, todas as linhas da 
tabela são eliminadas.
z O comando a seguir deleta todas as linhas da tabela:
z DELETE FROM ProdutoPedido;
z A exclusão de linhas de uma tabela não pode violar as restrições de 
chave estrangeira.
z Se não, devem ser excluídas inicialmente as linhas da tabela filha (a 
tabelaque tem a chave estrangeira).
z O comando seguinte elimina linhas específicas de uma tabela:
z DELETE FROM ProdutoPedido WHERE Id_Pedido = 1;
Banco de Dados Profª. Rossana Junqueira 153
Consultas a dados de uma tabela
z Uma das funções mais importantes de um SGBD é permitir que os 
dados armazenados em um banco de dados sejam recuperados das 
formas mais diversas que se possa imaginar.
z O comando SELECT é o comando SQL utilizado para recuperar 
informações de bancos de dados.
z Operadores:
z A cláusula WHERE utiliza expressões que limitam as linhas da tabela a
serem recuperadas.
z Dessas expressões fazem parte os operadores que podem ser 
classificados em quatro categorias:
z Aritméticos
z Lógicos
z De comparação
z De concatenação
Banco de Dados Profª. Rossana Junqueira 154
Consultas a dados de uma tabela
z Aritméticos:
+ Adição
-
 
Subtração
* Multiplicação
/ Divisão
z Lógicos:
AND E
OR Ou
NOT Não
z De concatenação:
|| Concatenação de 
strings
z De comparação:
< Menor que
> Maior que
<= Menor ou igual a
>=
 
Maior ou igual a
=
 
Igual
<>
 
Diferente
BETWEEN
 
Entre
IN
 
Em
IS
 
É
LIKE
 
Igual a
Banco de Dados Profª. Rossana Junqueira 155
Consultas a dados de uma tabela
z Consultas simples:
z SELECT * FROM CLIENTE;
z Esse comando recupera todas as linhas e colunas da tabela CLIENTE. 
z O asterisco (*) indica que todas as colunas são mostradas.
z Se for desejado recuperar colunas específicas da tabela, um exemplo 
seria:
z SELECT NOME, CONTATO, TELEFONE FROM CLIENTE;
z É possível também, nas consultas, que os nomes originais das colunas 
sejam modificados.
z SELECT ID_FABRICA AS ID, RAZAOSOCIAL AS "RAZÃO SOCIAL“
FROM FABRICA;
z A cláusula AS permite que as colunas recebam um apelido.
Banco de Dados Profª. Rossana Junqueira 156
Consultas a dados de uma tabela
z A cláusula AS permite que as colunas recebam um apelido.
z Se o apelido possuir espaços deve-se defini-lo entre aspas.
z A cláusula AS é opcional.
z O comando no formato a seguir produz o mesmo resultado:
ƒ SELECT ID_FABRICA ID, RAZAOSOCIAL "RAZÃO SOCIAL“ FROM FABRICA;
z As colunas de consultas podem incluir expressões aritméticas.
z SELECT ID_PRODUTO, ID_CONDICAO, PRECO * 1.05 FROM 
PRODUTOCOND;
z Esta consulta mostra os preços dos produtos com seus valores 
reajustados em 5%.
z No resultado da consulta, essa coluna não estará identificada. Assim, é
fortemente aconselhável utilizar sempre os apelidos.
ƒ SELECT ID_PRODUTO, ID_CONDICAO, PRECO * 1.05 “Novo Preço”
FROM PRODUTOCOND;
Banco de Dados Profª. Rossana Junqueira 157
Consultas a dados de uma tabela
z A consulta seguinte utiliza o operador de concatenação:
z SELECT NOME, ENDERECO, CIDADE || '-' || UF "CIDADE-ESTADO" 
FROM CLIENTE;
z A terceira coluna da consulta é resultante da concatenação de três 
strings: as colunas da tabela, CIDADE e UF, e o literal hífen (-). 
z Foi atribuído um apelido à coluna resultante do cálculo.
z A cláusula DISTINCT é utilizada para suprimir linhas duplicadas do 
resultado de uma coluna.
z SELECT CIDADE FROM CLIENTE;
z O comando acima poderia retornar linhas duplicadas.
z Para eliminar as duplicações utiliza-se DISTINCT:
ƒ SELECT DISTINCT CIDADE FROM CLIENTE;
Banco de Dados Profª. Rossana Junqueira 158
Consultas a dados de uma tabela
z Uso da cláusula WHERE:
z O uso de WHERE juntamente com as expressões envolvendo os 
operadores irá permitir que seja obtido o resultado de uma consulta 
seletiva, onde apenas as linhas que atendem às restrições estabelecidas 
são mostradas.
z Com operadores de Comparação:
z SELECT ID_CLIENTE, NOME FROM CLIENTE
WHERE UF = 'PA';
ƒ Retornam da tabela CLIENTE as linhas que atendem a condição de que a coluna UF 
seja igual a ‘PA’.
z SELECT ID_PEDIDO, VALOR, ID_CLIENTE FROM PEDIDO
WHERE DATA > '06/15/2005';
ƒ Essa consulta mostra os pedidos cuja DATA seja maior que 15/06/2005.
Banco de Dados Profª. Rossana Junqueira 159
Consultas a dados de uma tabela
z SELECT ID_CLIENTE, NOME FROM CLIENTE
WHERE NOME LIKE 'A%';
ƒ O operador LIKE recupera da tabela os clientes que têm o nome iniciando com a letra 
A.
z SELECT * FROM PEDIDO
WHERE VALOR BETWEEN 200 AND 700;
ƒ Essa consulta retorna todos os pedidos, tais que a coluna VALOR esteja no intervalo 
entre 200 e 700 reais.
ƒ Se houver linhas cujos valores sejam iguais a 200 ou 700, elas serão retornadas.
z SELECT ID_FABRICA, RAZAOSOCIAL FROM FABRICA
WHERE UF IN ('PA', 'AM', 'AC', 'AP');
ƒ Essa consulta retorna as linhas onde a coluna UF seja igual a qualquer dos 
elementos relacionados entre parênteses.
Banco de Dados Profª. Rossana Junqueira 160
Consultas a dados de uma tabela
z Com operadores Lógicos:
z SELECT * FROM CLIENTE WHERE NOT UF = 'PA';
ƒ Mostra os clientes que não são do estado do Pará.
z SELECT * FROM PEDIDO WHERE VALOR NOT BETWEEN 200 AND 
700;
ƒ Retorna os pedidos cujos valores não estão entre 200 e 700.
z SELECT * FROM CLIENTE WHERE NOME NOT LIKE 'D%';
ƒ Recupera os clientes cujos nomes não iniciam com a letra D.
z SELECT * FROM PRODUTO WHERE ID_PRODUTOC IS NOT NULL;
ƒ Mostra os produtos que fazem parte da composição de outro produto, ou seja, aqueles 
em que a coluna ID_COMPOSTOC não é nula.
Banco de Dados Profª. Rossana Junqueira 161
Consultas a dados de uma tabela
z SELECT * FROM PEDIDO WHERE VALOR > 200 AND VALOR < 700;
ƒ AND e OR são utilizados para criar condições complexas resultantes de duas ou mais 
condições que usam operadores de comparação.
z Uso da cláusula ORDER BY:
z Como padrão, uma consulta recupera linhas na mesma ordem em que 
ela as encontra na tabela.
z Para especificar uma ordem na qual as linhas devem ser retornadas por 
uma consulta, usa-se a cláusula ORDER BY no fim do comando 
SELECT.
z SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA 
ORDER BY CIDADE;
z SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA 
ORDER BY CIDADE DESC, RAZAOSOCIAL;
Banco de Dados Profª. Rossana Junqueira 162
Consultas a dados de uma tabela
z Uso de funções:
z AVG
z SELECT AVG(VALOR) FROM PEDIDO;
ƒ Calcula a média dos valores numéricos em uma coluna.
z COUNT
z SELECT COUNT(*) FROM CLIENTE;
ƒ Calcula o número de linhas que satisfazem uma condição de seleção de uma 
consulta.
z MAX
z SELECT MAX(VALOR) FROM PEDIDO;
ƒ Recupera o valor máximo de uma coluna.
z MIN
z SELECT MIN(VALOR) FROM PEDIDO;
ƒ Recupera o valor mínimo de uma coluna.
Banco de Dados Profª. Rossana Junqueira 163
Consultas a dados de uma tabela
z Agrupamento de linhas com GROUP BY:
z Habilita uma consulta retornar um resumo sobre grupos de linhas que 
compartilham valores de coluna.
z SELECT ID_CLIENTE, AVG(VALOR) FROM PEDIDO GROUP BY 
ID_CLIENTE;
z O exemplo retorna o valor médio dos pedidos de cada cliente.
z A cláusula GROUP BY garante que o valor médio dos pedidos seja 
calculado e recuperado com base no identificados de cada cliente.
Banco de Dados Profª. Rossana Junqueira 164
Relacionamento entre tabelas
z Devido ao Firebird se tratar de um banco de dados relacional, às
vezes pode ser necessário construir consultas a dados que estão
em tabelas diferentes.
z A recuperação de dados de duas ou mais tabelas usando um único 
comando SELECT é denominada junção (join).
select
 
a.ID_PEDIDO, a.DATA, a.VALOR, b.NOME
from
 
PEDIDO a, CLIENTE b
where
 
a.ID_CLIENTE = b.ID_CLIENTE and
a.DATA >= '06/25/2006';
z Observa-se neste exemplo o uso do alias de uma tabela.
z Um alias, ou apelido, é uma variável temporária que representa o nome 
da tabela.
	Disciplina: Banco de Dados
	Capítulo 1: Conceitos Básicos
	Como Informática é adotada em organizações
	Sistemas isolados – Dados não compartilhados
	Sistemas isolados – Dados não compartilhados
	Banco de Dados
	Sistema de gerência de banco de dados
	Sistema de gerência de banco de dados
	Sistema de gerência de banco de dados
	Sistema de gerência de banco de dados
	Sistema de gerência de banco de dados
	Modelo de Dados
	Esquema de banco de dados
	Modelo Conceitual
	Modelo Lógico
	Modelo Físico
	Modelo conceitual como modelo de organizaçãoModelo conceitual como modelo de organização
	Projeto de banco de dados
	Capítulo 2: Abordagem entidade - relacionamento
	Abordagem entidade-relacionamento
	Entidade
	Entidade
	Relacionamento
	Relacionamento
	Cardinalidade de relacionamentos
	Cardinalidade de relacionamentos
	Cardinalidade de relacionamentos
	Exemplos de entidades e relacionamentos
	Atributo
	Atributo
	Generalização e Especialização
	Generalização e Especialização
	Entidade associativa
	Entidade associativa
	Capítulo 3: Construindo modelos entidade-relacionamento
	Propriedades de modelos ER
	Equivalência entre modelos
	Exemplo de equivalência entre modelos
	Exemplo de equivalência entre modelos
	Atributo versus entidade relacionada
	Atributo versus generalização/especialização
	Verificação do modelo
	Verificação do modelo
	Verificação do modelo
	Verificação do modelo
	Verificação do modelo
	Verificação do modelo
	Verificação do modelo
	Estabelecimento de padrões
	Estratégias de modelagem
	Definição da estratégia de modelagem
	Capítulo 4: Abordagem relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Abordagem Relacional
	Capítulo 5: Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Transformação entre modelos
	Capítulo 6: Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Normalização
	Capítulo 7: SQL
	Criação de Banco de Dados
	Criação de Tabelas
	Criação de Tabelas
	Criação de Tabelas
	Alteração de Tabelas
	Alteração de Tabelas
	Alteração de Tabelas
	Exclusão de Tabelas
	Povoamento de Tabelas
	Povoamento de Tabelas
	Povoamento de Tabelas
	Alteração de dados
	Alteração de dados
	Exclusão de linhas
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Consultas a dados de uma tabela
	Relacionamento entre tabelas

Outros materiais