Disciplina: Banco de Dados

Ciência da Computação - 4° Período
Profa. Rossana de Paula Junqueira Almeida

Banco de Dados

Profª. Rossana Junqueira

1

Capítulo 1: Conceitos Básicos

Banco de Dados

Profª. Rossana Junqueira

2

Como Informática é adotada em organizações
z z

Informática é implementada gradativamente; Exemplo: uma empresa
z

Implementa gradativamente sistemas para: z Vendas z Produção z Compras Usados em várias funções Pode ocorrer que, para casa uma das funções, seja criado um arquivo separado de produtos.

z

Onde ficam os dados dos produtos?
z z

Banco de Dados

Profª. Rossana Junqueira

3

Sistemas isolados – Dados não compartilhados

z z

Problema: redundância de dados 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

4

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:
ƒ ƒ z

Entrada repetida da mesma informação Inconsistência de dados

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

5

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 z

A estrutura interna dos arquivos para a ser mais complexa Devem atender às necessidades dos diferentes sistemas Usar sistema de gerência de banco de dados
Profª. Rossana Junqueira 6

z

Solução:
z

Banco de Dados

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 Foram identificadas funcionalidades comuns a muitos programas z Exibição dos dados na interface
ƒ z

z

Evolução da programação:
z

Gerenciadores de interface do usuário Gerenciadores de comunicação Sistemas de Gerência de Banco de Dados (SGBD)
Profª. Rossana Junqueira 7

Comunicação com processos remotos
ƒ

z

Manutenção de grandes repositórios compartilhados de dados
ƒ

Banco de Dados

Sistema de gerência de banco de dados
z

z

Software que incorpora as funções de definição, recuperação e alteração de dados em um banco de dados Facilita o desenvolvimento de aplicações de BD
z z

Manutenção de programas torna-se mais simples Produtividade de programadores aumenta

Banco de Dados

Profª. Rossana Junqueira

8

Sistema de gerência de banco de dados
z

Sistema Dados:
z

de

Banco

de

Apenas um sistema computadorizado de manutenção de registros Sistema computadorizado cuja finalidade geral é armazenar informações e permitir que os usuários busquem e atualizem essas informações quando as solicitar.

ou
z

z

Tal sistema envolve quatro componentes principais: Dados, Hardware, Software e Usuários.
9

Banco de Dados

Profª. Rossana Junqueira

Sistema de gerência de banco de dados
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.

Banco de Dados

Profª. Rossana Junqueira

10

Sistema de gerência de banco de dados
z

Sistema de Banco de Dados:
z

Hardware:
ƒ

Volumes de armazenamento, processadores de hardware e memória. 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 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).
Profª. Rossana Junqueira 11

z

Software:
ƒ

ƒ
z

Usuários:
ƒ

ƒ ƒ
Banco de Dados

Modelo de Dados
z

Modelo de (banco) de dados
z

z

Descrição dos tipos de informações que estão armazenadas em um banco de dados Exemplo da indústria: z Modelo de dados informa:
ƒ ƒ z

São armazenadas informações sobre produtos Para cada produto, são armazenados seu código, preço e descrição Quais os produtos que estão armazenados no banco de dados

Modelo de dados não informa:
ƒ

Banco de Dados

Profª. Rossana Junqueira

12

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

Níveis de Abstração:

z

z

Um modelo de dados pode ser apresentado de várias formas (texto, figura, ...) Cada apresentação do modelo recebe a denominação esquema de banco de dados
Banco de Dados Profª. Rossana Junqueira 13

Modelo Conceitual
z z

z

Independente do tipo de SGBD Registra: z Que dados podem aparecer no banco de dados Não registra:
z

Como estes dados estão armazenados a nível de SGBD Abordagem entidade-relacionamento (ER)

z

Técnica mais difundida na modelagem conceitual
z

z

Modelo conceitual é representado através de diagrama entidade-relacionamento (DER)

Banco de Dados

14

Modelo Lógico
z z z

Nível de abstração visto pelo usuário do SGBD Depende do tipo particular de SGBD que está sendo usado Em um SGBD relacional, os dados estão organizados na forma de tabelas

Banco de Dados

Modelo Físico
z z

Contém detalhes de armazenamento interno de informações Detalhes que:
z z

Não têm influencia sobre a programação de aplicações no SGBD 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

16

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 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 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
Profª. Rossana Junqueira 17

z

Exemplo da indústria
z

z

Idéia fundamental do projeto de banco de dados:
z

Banco de Dados

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.
Profª. Rossana Junqueira 18

Banco de Dados

Projeto de banco de dados
z

3 fases:
z

z

z

Modelagem conceitual z Construído um modelo conceitual, na forma de um diagrama entidade-relacionamento. Modelo lógico z Objetiva transformar o modelo conceitual obtido na primeira faze em um modelo lógico. Projeto físico z O modelo é enriquecido com detalhes que influenciam no desempenho do banco de dados, mas não interferem em sua funcionalidade

Banco de Dados

Profª. Rossana Junqueira

19

Capítulo 2: Abordagem entidade relacionamento

Banco de Dados

Profª. Rossana Junqueira

20

Abordagem entidaderelacionamento
z z z z z

Técnica para construir modelos conceituais de bases de dados Técnica de modelagem de dados mais difundida e utilizada Criada em 1976 por Peter Chen Padrão de fato para modelagem conceitual Não é única:
z z

NIAM/ORM (técnica européia da década de 70) UML (Técnica para modelos Orientados a Objetos)

z z

Técnicas de modelagem orientada a objetos (UML) baseiam-se nos conceitos da abordagem ER Modelo de dados é representado através de um
z

modelo entidade-relacionamento (modelo ER) diagrama entidade-relacionamento (DER)
Profª. Rossana Junqueira 21

z

Modelo ER é representado graficamente
z

Banco de Dados

Entidade
z

z

Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de dados Exemplos:
z

z

Sistema de informações industrial: z Produtos z Tipos de produtos z Vendas z Compras Sistemas de contas correntes: z Clientes z Conta correntes z Cheques z Agências
Profª. Rossana Junqueira 22

Banco de Dados

Entidade
z z

Representada através de um retângulo Retângulo contem o nome da entidade
Pessoa
Departamento

z z

z

z

Entidade = conjunto de objetos Para se referir a um objeto em particular fala-se em instância ou ocorrência da entidade 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 Propriedades são especificadas na forma de: relacionamentos, atributos e generalizações/especializações
Profª. Rossana Junqueira 23

Banco de Dados

Relacionamento
z

Conjunto de associações entre entidades sobre as quais deseja-se manter informações na base de dados

z

z

z

Relacionamento é um conjunto de associações entre instâncias de entidades Uma instância (ocorrência) é uma associação específica entre determinadas instâncias de entidade Exemplo (relacionamento LOTAÇÃO)
z

ocorrência = par específico formado por uma ocorrência de PESSOA e uma ocorrência de DEPARTAMENTO
Profª. Rossana Junqueira 24

Banco de Dados

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

25

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

z

Chamada de cardinalidade relacionamento Cardinalidade máxima:

de

uma

entidade

em

um

Banco de Dados

Profª. Rossana Junqueira

26

Cardinalidade de relacionamentos
z

Relacionamento de 1:1

z

Relacionamento de 1:n

z

Relacionamento de n:n

27

Cardinalidade de relacionamentos
z

Cardinalidade mínima:
z

z

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 Para fins de projeto de BD, consideram-se apenas duas cardinalidades mínimas z cardinalidade mínima 0 z cardinalidade mínima 1 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

28

Exemplos de entidades e relacionamentos

Banco de Dados

Profª. Rossana Junqueira

29

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

30

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

Banco de Dados

Profª. Rossana Junqueira

31

Generalização e Especialização
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
z z

Além de suas próprias propriedades Também as propriedades da ocorrência da entidade genérica Profª. Rossana Junqueira 32 correspondente

Generalização e Especialização
z

Especialização total ou parcial

Banco de Dados

Entidade associativa

É 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.
z

Banco de Dados

34

Entidade associativa

Banco de Dados

Profª. Rossana Junqueira

35

Capítulo 3: Construindo modelos entidaderelacionamento

Banco de Dados

Profª. Rossana Junqueira

36

Propriedades de modelos ER
z

É um modelo formal, preciso, não ambíguo.
z

z z

z

Isto significa que diferentes leitores de um mesmo modelo ER devem sempre entender exatamente o mesmo. DER pode ser usado como entrada a uma ferramenta CASE. Fundamental: todos os envolvidos devem estar treinados na sua perfeita compreensão. Risco: sub-utilização Modelo ER apresenta apenas algumas propriedades de um banco de dados Foi concebido para o projeto da estrutura de um BD relacional Pouco poderoso para expressar restrições de integridade (regras de negócio)
Profª. Rossana Junqueira 37

z

Modelos ER têm poder de expressão limitado
z

z z

Banco de Dados

Equivalência entre modelos
z z

Dois modelos diferentes podem se equivalentes Modelos equivalentes:
z z

expressam o mesmo modelam a mesma realidade

z

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 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

38

Exemplo de equivalência entre modelos
z

CONSULTA como relacionamento n:n

z

CONSULTA como entidade

Banco de Dados

Profª. Rossana Junqueira

39

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 z

não pode ser feita através da observação do objeto isoladamente é necessário conhecer o contexto (modelo dentro do qual o objeto aparece)

z z z z

Decisão por uma construção para a modelagem de um objeto está sujeita a alteração durante a modelagem Não despender um tempo excessivo em longas discussões sobre como modelar um objeto O próprio desenvolvimento do modelo e o aprendizado sobre a realidade irão refinando e aperfeiçoando o modelo Existem critérios alguns critérios para escolha de construções de modelagem
Profª. Rossana Junqueira 40

Banco de Dados

Atributo versus entidade relacionada
z

Alguns critérios para esta decisão são:
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
z

Banco de Dados

Profª. Rossana Junqueira

41

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

Banco de Dados

Profª. Rossana Junqueira

42

Verificação do modelo
z z

z

z

Uma vez construído, um modelo ER dever ser validado e verificado. A verificação é o controle de qualidade que procura garantir que o modelo usado para a construção do banco de dados gerará um bom produto. Um modelo para ser considerado bom, deve preencher uma série de requisitos, como ser completo, ser correto e não conter redundância. 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

43

Verificação do modelo
z

Modelo COMPLETO
z z z

z

Deve fixar todas as propriedades desejáveis do banco de dados. Somente pode ser verificado por alguém que conhece profundamente o sistema a ser implementado. 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? Este requisito é aparentemente conflitante com a falta de poder de expressão de modelos ER.

Banco de Dados

Profª. Rossana Junqueira

44

Verificação do modelo
z

Modelo deve ser livre de REDUNDÂNCIAS
z z

Modelo deve ser mínimo, isto é não deve conter conceitos redundantes 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

45

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

46

Verificação do modelo
z

Modelo deve refletir o aspecto temporal
z

z

Dados temporais z Dados que mudam ao longo do tempo e para as quais o BD mantém histórico Tipos de dados temporais: z Atributos cujos valores modificam ao longo do tempo z Relacionamentos que modificam ao longo do tempo

Banco de Dados

Profª. Rossana Junqueira

47

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 Quando informações antigas são necessárias apenas para tomada de decisões Pode ser conveniente manter no banco de dados informações 48 compiladas e eliminar as informações usadas na compilação

z

Planejar informações estatísticas
ƒ ƒ

Verificação do modelo
z

Entidade isolada e entidade sem atributos
z z z

z

Caso raro, mas não incorreto Entidade que muitas vezes aparece isolada Caso típico: z Entidade que modela a organização na qual o sistema implementado pelo BD está embutida 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
Profª. Rossana Junqueira 49

Banco de Dados

Estabelecimento de padrões
z

Modelos de dados são usados para comunicação com:
z z

Pessoas da organização (usuários, analistas, programadores, ...) Programas (ferramentas CASE, geradores de código, ...)

z z

z

É necessário estabelecer padrões de confecção de modelos 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 Variantes de abordagem ER
z z z z

Peter Chen (acadêmica) Engenharia de informações UML Merise (notação Européia)
50

Banco de Dados

Estratégias de modelagem
z

z

Uma seqüência de passos (uma “receita de bolo”) de transformação de modelos desde o modelo inicial de modelagem até o final Diferentes estratégias:
z z

z

Bottom-up Æ Parti de conceitos mais detalhados e abstrai gradativamente. Inicia com a identificação de atributos 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 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

51

Definição da estratégia de modelagem
z

Na prática
z

Nenhuma das estratégias propostas na literatura é universalmente aceita Combinação das diversas estratégias de modelagem Processo de modelagem é um processo de aprendizagem

z

Normal
z

z

Compreensível
z

Banco de Dados

Profª. Rossana Junqueira

52

Capítulo 4: Abordagem relacional

Banco de Dados

Profª. Rossana Junqueira

53

Abordagem Relacional
z

z

Abordagem de modelagem de dados usada nos sistemas de gerência de banco de dados do tipo relacional; 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 Profissional
Tabela Linha Coluna Valor de campo

z

Terminologias:
Acadêmica
Relação Tupla Atributo Valor de atributo
54

Banco de Dados

Profª. Rossana Junqueira

Abordagem Relacional

Banco de Dados

Profª. Rossana Junqueira

55

Abordagem Relacional
z

Características das tabelas:
z z

As linhas de ma tabela não têm ordenação Valores de campo:
z z

Atômicos Æ o campo não pode ser composto de outros Monovalorados Æ o campo possui um único valor

z

Acesso por quaisquer critérios envolvendo os campos de uma ou mais linhas
z

z

Programadores escrevem consultas sem considerar a existência de caminhos de acesso 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
Profª. Rossana Junqueira 56

Banco de Dados

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 z z

Chave Primária Chave Alternativa 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

57

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

Banco de Dados

Profª. Rossana Junqueira

58

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

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 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 chave primária que está sendo alterada
Ex: Caso um departamento possua empregados, seu código não pode ser modificado

Abordagem Relacional
z z z

A palavra “estrangeira” pode levar a crer que a chave estrangeira sempre referencia uma chave primária de outra tabela. Esta restrição não existe. Um chave primária pode referenciar a chave primária da própria tabela.

Banco de Dados

Profª. Rossana Junqueira

60

Abordagem Relacional
z

Chave Alternativa Æ Mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais
z

z

Uma das colunas (ou combinação de colunas) é escolhida como chave primária As demais colunas ou combinações são denominadas chaves alternativas

61

Abordagem Relacional
z

z

Domínio de coluna Æ conjunto de valores que podem aparecer em uma coluna (atributo) Valor vazio:
z

z

z

z

Um valor de campo pode assumir o valor especial vazio (“null” em inglês) Colunas nas quais não são admitidos valores vazios são chamadas de colunas obrigatórias Colunas nas quais podem aparecer campos vazios são chamadas de colunas opcionais Abordagem relacional:
z
z

todas colunas que compõem a chave primária devem ser obrigatórias
demais chaves podem conter colunas opcionais

Banco de Dados

Profª. Rossana Junqueira

62

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

z

z

Para garantir a integridade de um banco de dados, SGBD oferecem o mecanismo de restrições de integridade Uma restrição de integridade é uma regra de consistência de dados que é garantida pelo próprio SGBD São classificadas nas seguintes categorias:
z

z

Integridade de domínio Æ o valor de um campo deve obedecer a definição de valores admitidos para a coluna Integridade de vazio Æ é especificado se os campos de uma coluna podem ou não ser vazios.

Banco de Dados

Profª. Rossana Junqueira

63

Abordagem Relacional
z z

Integridade de chave Æ define que os valores da chave primária e alternativa devem ser únicos Integridade referencial Æ define que os valores que aparecem em uma chave estrangeira devem aparecer na chave primária da tabela referenciada

z z

Restrições acima são garantidas automaticamente por um SGBD relacional Não é exigido que o programador escreva procedimentos para garanti-las explicitamente Restrições de integridade que não se encaixam nas categorias básicas Exemplos de restrições semânticas:
z

z

Restrições de integridade semânticas:
z 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.
Profª. Rossana Junqueira 64

Banco de Dados

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 z z

Tabelas que formam o banco de dados Colunas que as tabelas possuem Restrições de integridade

Banco de Dados

Profª. Rossana Junqueira

65

Abordagem Relacional
z

Esquema textual de BD relacional

Banco de Dados

Profª. Rossana Junqueira

66

Abordagem Relacional
z

Esquema diagramático de BD relacional

Banco de Dados

Profª. Rossana Junqueira

67

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

68

Capítulo 5: Transformação entre modelos

Banco de Dados

Profª. Rossana Junqueira

69

Transformação entre modelos
z

Dois processos de transformação de modelos:

z

Visão geral do projeto lógico:

Banco de Dados

70

Transformação entre modelos
z

Transformação ER para relacional:
z

Objetivos básicos:
z z z z

Boa performance; Simplificar o desenvolvimento; Ocupar pouco espaço em disco; 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
Profª. Rossana Junqueira 71

Banco de Dados

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

72

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 z z

Tradução inicial de entidades e respectivos atributos Tradução de relacionamentos e respectivos atributos Tradução de generalizações/especializações

Banco de Dados

Profª. Rossana Junqueira

73

Transformação entre modelos
z

Implementação inicial de entidades
z z z

z

z

Cada entidade é traduzida para uma tabela. Cada atributo da entidade define uma coluna desta tabela. Atributos identificadores da entidade correspondem a chave primária da tabela. Tradução inicial – Regras que seguem, as tabelas definidas nessa etapa ainda poderão ser fundidas. Ex:
Data admissão Data nascimento

Pessoa

código nome endereço

Pessoa (CodPess, Nome, Endereço, Data Nasc, DataAdm)
Banco de Dados Profª. Rossana Junqueira 74

Transformação entre modelos
z

Nome de atributos e Nomes de Colunas:
z z z z z z

z z z

z
Banco de Dados

Referenciados freqüentemente em programas e outras formas de texto em computador Para diminuir o trabalho de programadores – manter os nomes de colunas curtos. SGBD relacional – nome de uma coluna não pode conter brancos Não transcrever os nomes de atributos para nomes de colunas Nomes de atributos compostos de diversas palavras devem ser abreviados 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 SQL já exige muitas vezes formar - Pessoa.Nome Chave primária – pode aparecer em outras tabelas na forma de chave estrangeira 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 Exemplo: CodigoPess
Profª. Rossana Junqueira 75

Transformação entre modelos
z

Implementação de relacionamento
z

Alternativas:
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

z

Tabela própria
n

Engenheiro
nome código

Atuação
função

n

Projeto
título código

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

76

Transformação entre modelos
z

Adição de colunas
1

Departamento
nome código
z

Lotação
data lotação

n

Empregado
nome código

Departamento (CodDept, Nome) Empregado (CodEmp, Nome, CodDept, DataLota) CodDept referencia Departamento

Fusão de tabelas
1
Organização

Conferência
nome código

1

Comissão
ender

Conferência (CodConf, Nome, DataInstComOrg, EnderComOrg)

Data instalação

Banco de Dados

Profª. Rossana Junqueira

77

Transformação entre modelos
z

Implementação de relacionamentos Æ 1:1

Banco de Dados

Profª. Rossana Junqueira

78

Transformação entre modelos
z

1:1 – Ambas entidades opcionais
Homem
nome

(0,1)

Casamento
regime data

(0,1)

Mulher
título

identidade

identidade

Adição de colunas: Tabela própria: Mulher (IdentM, Nome, IdentH, Data, Regime)Mulher (IdentM, Nome) IdentH referencia Homem Homem (IdentH, Nome) Homem (IdentH, Nome) Casamento (IdentM, IdentH, Data, Regime) IdentM referencia Mulher IdentH referencia Homem Fusão de Tabelas: (NÃO USAR) Casamento (IdentM, IdentH, NomeM, NomeH, Data, Regime)
Banco de Dados Profª. Rossana Junqueira 79

Transformação entre modelos
z

1:1 – Ambas entidades opcionais
z z

Solução por fusão de tabelas é inviável – Chave primária artificial Solução por adição de colunas: melhor opção
z

Menor número de junções

z z

Menor número de chaves

Solução por tabela própria: opção aceitável

Banco de Dados

Profª. Rossana Junqueira

80

Transformação entre modelos
z

1:1 – Uma entidade opcional outra obrigatória
(1,1) (0,1)

Correntista
nome código

Cartão Magnético
Data expedição código

Tabela própria: (NÃO USAR) Correntista (CodCorrent, Nome) Cartão (CodCartão, DataExp) CartãoCorrentista (CodCartão, CodCorrent) CodCorrent referencia Correntista Fusão de Tabelas: Correntista (CodCorrent, Nome, CodCartão, DataExp) CodCartão referencia Cartão
Banco de Dados Profª. Rossana Junqueira 81

Adição de colunas: Correntista (CodCorrent, Nome) Cartão (CodCartão, DataExp, CodCorrent) CodCorrent referencia Correntista

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 z z

Maior número de índices Nenhuma têm problema de campos opcionais
Fusão de tabelas é melhor em termos de número de junções e número de chaves Adição de colunas em melhor em termos de campos opcionais Fusão de tabelas é considerada a melhor opção e adição de colunas é

Adição de colunas versus fusão de tabelas
z

z z

aceitável

Banco de Dados

Profª. Rossana Junqueira

82

Transformação entre modelos
z

1:1 – Ambas entidades tem participação obrigatória
(1,1)
Organização

Conferência
nome código

(1,1)

Comissão
ender

Data instalação

Fusão de Tabelas: Conferência (CodConf, Nome, DataInstComOrg, EnderComOrg)
z

Nenhuma das demais alternativas atende plenamente
z

z

z z
Banco de Dados

Entidades que participam do relacionamento seriam representadas através de duas tabelas distintas Estas tabelas teriam a mesma chave primária e relação um-para-um entre suas linhas Maior número de junções Maior número de chaves primárias
Profª. Rossana Junqueira 83

Transformação entre modelos
z

Implementação de relacionamentos Æ 1: n

Banco de Dados

Profª. Rossana Junqueira

84

Transformação entre modelos
z

1:n – A entidade que tem cardinalidade máxima 1 é obrigatória
Departamento
nome código data lotação código

(1,1)

Lotação

(0,n)

Empregado
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

85

Transformação entre modelos
z

1:n – A entidade que tem cardinalidade máxima 1 é obrigatória
z

Fusão de tabelas
z z

Não se aplica Implicaria em:
ƒ ƒ

redundância de dados de departamento, ou tabela aninhada Menor número de chaves Menor número de junções Não há o problema de campos opcionais

z

Adição de colunas é melhor que tabela própria:
ƒ ƒ ƒ

Banco de Dados

Profª. Rossana Junqueira

86

Transformação entre modelos
z

1:n – A entidade que tem cardinalidade máxima 1 é opcional
Financeira
nome código

(0,1)

Financiam

(0,n)

Venda
data id

nº de parcelas taxa de juros

Adição de Colunas: z 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 Banco de Dados

Implementação por tabela própria também é aceitável:
z

z

É melhor em relação a campos opcionais Perde em relação a junções e número de chaves
87

Transformação entre modelos
z

Implementação de relacionamentos Æ n : n

Banco de Dados

Profª. Rossana Junqueira

88

Transformação entre modelos
z

n:n
Engenheiro
nome código

(0,n)

Atuação
função

(0,n)

Projeto
título

código

Tabela própria: Engenheiro (CodEng, Nome) Projeto (CodProj, Título) Atuação (CodEng, CodProj, Função) CodEng referencia Engenheiro CodProj referencia Projeto

Banco de Dados

89

Transformação entre modelos
z

Relacionamentos de grau maior que dois
z z

Não são definidas regras específicas O relacionamento é transformado em uma entidade

Produto (CodProd, Nome) Cidade (CodCid, Nome) Distribuidor (CodDistr, Nome) Distribuição (CodProd, CodDistr, DataInicio) CodProd referencia Produto CodDistr referencia Distribuidor CodCid referencia Cidade

CodCid,

Banco de Dados

90

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

91

Transformação entre modelos
z

Implementação de generalização / especialização
z

Uma tabela por hierarquia:
z

z

Todas as tabelas referentes às especializações são fundidas em uma única tabela Tabela contém:
ƒ ƒ ƒ ƒ

ƒ ƒ

Banco de Dados

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)

92

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

93

Transformação entre modelos
z

Implementação de generalização/especializaç ão
z

Uma tabela por entidade especializada:
z

z

Criar uma tabela para cada entidade que compõe a hierarquia Incluir a chave primária da tabela correspondente à entidade genérica, em cada tabela correspondente a uma entidade especializada

Banco de Dados

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) 94 CódigoEmp referencia Engenheiro CódigoProj referencia Projeto

Transformação entre modelos
z

Implementação de generalização / especialização
z

Vantagens da implementação com tabela única:
z

z z

Dados referentes à entidade genérica + dados referentes às especializações – em uma única linha Minimiza junções 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

95

Transformação entre modelos
z

Refinamento do modelo relacional
z

z

z

z

z

z

Projeto (engenharia) em geral – compromisso entre o ideal e o realizável dentro das restrições de recursos impostas pelas prática Projeto de banco de dados – compromisso entre o ideal (regras de implementação) e o alcançável frente a limitações de performance Algumas vezes – esquema de BD criado através do uso das regras acima não atende requisitos de performance impostos ao sistema Necessário buscar alternativa que resulte em melhor performance do sistema Alternativas somente devem ser tentadas em último caso - do ponto de vista da programação são sempre piores Exemplos: Relacionamentos mutuamente exclusivos e Simulação de atributos multivalorados
Profª. Rossana Junqueira 96

Banco de Dados

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
Profª. Rossana Junqueira 97

Banco de Dados

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

98

Transformação entre modelos
z

Tratamento multivalorados:

de

atributos

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
Profª. Rossana Junqueira 99

Banco de Dados

Transformação entre modelos
z

Tratamento de atributos multivalorados:
z

Implementação “desnormalizada”

Cliente (CodCli,Nome,NumTel1,NumTel2)
z

z

z

z

Simular uma coluna multi-valorada através da criação de diversas colunas NumTel sufixadas por um número Permite que os telefones de um cliente sejam obtidos mais rapidamente Implica em menos espaço ocupado – não é necessária chave primária da tabela Telefone Inconveniente
z

Banco de Dados

z

Consulta usando o número de telefone como critério de busca torna-se mais complicada Manter os telefones "alinhados à esquerda" exige rotina complexa
Profª. Rossana Junqueira 100

Transformação entre modelos
z

Engenharia reversa de modelos relacionais:
z z z

Parte de modelo de implementação Obtém modelo de especificação (modelo conceitual) Passos:
z z z z

Identificação da construção ER correspondente a cada tabela Definição de relacionamentos 1:n e 1:1 Definição de atributos Definição de identificadores de entidades e relacionamentos

Banco de Dados

Profª. Rossana Junqueira

101

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

Profª. Rossana Junqueira

102

Transformação entre modelos
z

Identificação da construção ER correspondente a cada tabela
z

Uma tabela pode corresponder a:
z z z

uma entidade um relacionamento n:n uma entidade especializada composição de sua chave primária

z

Fator determinante
z

Banco de Dados

103

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

104

Transformação entre modelos
z

Construções identificadas: Turma Disciplina
n

Sala

Currículo
n

Curso Laboratório Prédio
Banco de Dados Profª. Rossana Junqueira 105

Transformação entre modelos
z

Identificação de relacionamentos 1:n ou 1:1
z

z z

z

Chave estrangeira que não se enquadra nas regras acima – representa relacionamento 1:n ou relacionamento 1:1 Esquema não informa se é 1:1 ou 1:n Chave estrangeira é parte de uma chave primária trata-se de um relacionamento 1:n Nos demais casos, para definir a cardinalidade, é necessário verificar os possíveis conteúdos do banco de dados

Banco de Dados

Profª. Rossana Junqueira

106

Transformação entre modelos
z

Construções identificadas: Turma
n

n

Currículo

1

Disciplina
n

Currículo
1

Currículo
n

Sala
n

Curso

Currículo
1
Banco de Dados

Prédio

Laboratório
107

Transformação entre modelos
z

Definição de atributos:
z

z

Cada coluna não chave estrangeira é um atributo na entidade/relacionamento correspondente à tabela As colunas chave estrangeira não correspondem a atributos correspondem a relacionamentos

z

Definição de identificadores de entidades:
z

z

Coluna da chave primária que não é chave estrangeira corresponde a um atributo identificador da entidade ou relacionamento. Coluna da chave primária que é chave estrangeira corresponde a um relacionamento identificador da entidade
108

Capítulo 6: Normalização

Banco de Dados

Profª. Rossana Junqueira

109

Normalização
z

z 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). Raramente documentados. Necessidade de modelo ER:
z z z

Manutenção Migração para outro tipo de BD Integração com outros BD

Banco de Dados

Profª. Rossana Junqueira

110

Normalização

Banco de Dados

Profª. Rossana Junqueira

111

Normalização
z

Objetivo:
z z

Reagrupar informações para eliminar redundâncias de dados Reagrupar informações para eliminar estruturas inexistentes no modelo ER (atributos multivalorados)

z

Passos:

Banco de Dados

Profª. Rossana Junqueira

112

Normalização
z

Documento exemplo:
Tipo: Novo desenvolvimento Categoria Funcional A1 A2 B1 A2 A1 4 4 9 4 4 Tipo: Manutenção Categoria Funcional A1 A2 B1 Salário 4 4 9 Data início no projeto 01/05/93 04/01/91 01/11/92 Tempo alocado ao projeto 12 24 12
113

Código do Projeto: LSC001 Descrição: Sistema de Estoque Código do Empregado 2146 3145 6126 1214 8191 Nome

Salário

Data início no projeto 01/11/91 02/10/91 03/10/92 04/10/92 01/11/92

Tempo alocado ao projeto 24 24 18 18 12

João Sílvio José Carlos Mário

Código do Projeto: PAG02 Descrição: Sistema de RH Código do Empregado 8191 4112 6126 Nome Mário João José

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 z

z z

possui uma ou mais tabelas aninhadas 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 Abreviatura: ÑN Exemplo:

Banco de Dados

Proj (CodProj,Tipo, Descr, (CodEmp, Nome, Cat, Sal, DataIni, TempAl))

114

Normalização
z

Forma Normal:
z

z

z

Regra que uma tabela deve obedecer para ser considerada “bem projetada” Há diversas formas normais, cada vez mais rígidas, para verificar tabelas relacionais Aqui tratadas:
z z z

primeira forma normal (1FN) segunda forma normal (2FN) terceira forma normal (3FN)

Banco de Dados

Profª. Rossana Junqueira

115

Normalização
z

Passagem à primeira forma normal (1FN)

z

Alternativas:
z

Uma única tabela
ƒ ƒ

Banco de Dados

ƒ

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
Profª. Rossana Junqueira 116

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 z

z

z

Primeira alternativa (tabela única) é mais correta Decompor uma tabela em várias tabelas (segunda alternativa) – podem ser perdidas relações entre informações Para fins práticos – preferimos a segunda alternativa (decomposição de tabelas) 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
Profª. Rossana Junqueira 117

Banco de Dados

Normalização
z

Passo 1:
z z

Criar uma tabela na 1FN referente a tabela não normalizada 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

118

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

119

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

120

Normalização

Banco de Dados

Profª. Rossana Junqueira

121

Normalização
z

Exemplo na 1FN:
Tipo Novo Desenvol. Manutenção Descr Sistema Sistema de RH

Proj CodProj LSC001 PAG02 ProjEmp CodProj LSC001 LSC001 LSC001 LSC001 LSC001 PAG02 PAG02 PAG02 CodEmp 2146 3145 6126 1214 8191 8191 4112 6126 Nome João Sílvio José Carlos Mário Mário João José Cat A1 A2 B1 A2 A1 A1 A2 B1 4 4 9 4 4 4 4 9 Sal DataIni 01/11/91 02/10/91 03/10/92 04/10/92 01/11/92 01/05/93 04/01/91 01/11/92 24 24 18 18 12 12 24 12 TempAl

Normalização
z

Dependência Funcional:
z

z

Para entender 2FN e 3FN – é necessário compreender o conceito de dependência funcional. 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.

Banco de Dados

Profª. Rossana Junqueira

123

Normalização
z

Segunda forma normal 2FN:
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
z

ProjEmp

CodProj LSC001 LSC001 LSC001 LSC001 LSC001 PAG02 PAG02 PAG02

CodEmp 2146 3145 6126 1214 8191 8191 4112 6126

Nome João Sílvio José Carlos Mário Mário João José

Cat A1 A2 B1 A2 A1 A1 A2 B1 4 4 9 4 4 4 4 9

Sal

DataIni 01/11/91 02/10/91 03/10/92 04/10/92 01/11/92 01/05/93 04/01/91 01/11/92

TempAl 24 24 18 18 12 12 24 12
124

Normalização
z

Segunda forma normal 2FN:

Æ Dependências parciais

Æ Dependências não parciais

125

Normalização
z

Segunda forma normal 2FN:
z

z

z

Tabela 1FN e que possui apenas uma coluna como chave primária – não contém dependências parciais É impossível uma coluna depender de uma parte da chave primária, quando a chave primária não é composta por partes Conclusão – Toda tabela 1FN que possui apenas uma coluna como chave primária já está na 2FN

126

Normalização
z

Segunda forma normal 2FN:
z z

z

Tabela que contenha apenas colunas chave primária Impossível atributo não chave depender de parte da chave (tabela não tem colunas não chave) Tabela sem colunas não chave já está na 2FN

127

Normalização
z

Segunda forma normal 2FN:

128

Normalização
z

Segunda forma normal 2FN:

Banco de Dados

Profª. Rossana Junqueira

129

Normalização
z

Terceira forma normal 3FN:
z z z

z

Trata de um outro tipo de redundância Exemplo: Emp (CodEmp, Nome, Cat, Sal) Considerar: – salário (coluna Sal) é determinado pela categoria funcional (coluna Cat) Salário que é pago a uma categoria funcional é armazenado tantas vezes quantos empregados possui a categoria funcional

130

Normalização
z

Terceira forma normal 3FN:
z z z

z

Trata de um outro tipo de redundância Exemplo: Emp (CodEmp, Nome, Cat, Sal) Considerar: – salário (coluna Sal) é determinado pela categoria funcional (coluna Cat) 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:

Proj (CodProj, Tipo, Descr) ProjEmp (CodProj, CodEmp, DataIni, TempAl) Emp (CodEmp, Nome, Cat) Cat (Cat, Sal)

Banco de Dados

Profª. Rossana Junqueira

132

Normalização
z

Normalização do exemplo:
Ñ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)
z

Banco de Dados

Profª. Rossana Junqueira

133

Normalização
z

Tabelas na 3FN:

Banco de Dados

Profª. Rossana Junqueira

134

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

z

z

z

Arquivo com dados sobre empregados de uma organização enviado para fins de fiscalização a um órgão governamental Identificador de empregado usado na organização é omitido, já que este é irrelevante para o órgão fiscalizador Outra situação: uso de uma chave alternativa, ao invés da chave primária usual do arquivo 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.

Normalização
z

Problemas de normalização:
z

Atributos relevantes implicitamente representados z Arquivos convencionais podem conter atributos de forma implícita
ƒ ƒ
z

ordenação de registros ou de listas ponteiros físicos, etc

z

Deve-se proceder como se o atributo aparecesse explicitamente no documento 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

136

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

137

Capítulo 7: SQL

Banco de Dados

Profª. Rossana Junqueira

138

Criação de Banco de Dados
z z

Conjunto de objetos que armazenam e manipulam dados. Como nomear arquivos e objetos: z Regras para nomeação dos objetos:
z z z z

Caracteres A...Z, a...z, 0...9, $ e _ Nomes devem começar com A...Z ou a...z. Nomes limitados a 31 caracteres. Nomes dos objetos devem ser únicos.

z

CREATE DATABASE ‘C:\Banco de Dados\empresa.fdb’;

Banco de Dados

Profª. Rossana Junqueira

139

Criação de Tabelas
z

Restrições a serem especificadas para uma coluna de tabela:
z z z

Regras que governam os relacionamentos e validam entradas de dados. Atuam em todas as transações que acessam o banco de dados e são automaticamente mantidas pelo sistema. Restrição UNIQUE e PRIMARY KEY:
z z

Asseguram que os valores inseridos em uma ou mais colunas são únicos para cada linha da tabela. Uma ou mais colunas definidas com essas restrições devem também ser definidas com o atributo NOT NULL. 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. Estabelece uma condição que deve ser verdadeira durante uma entrada ou atualização de dados na tabela.

z

Restrição FOREIGN KEY:
z

z

Restrição CHECK:
z

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.

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

141

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

142

Alteração de Tabelas
z

z

ALTER TABLE modifica uma tabela adicionando, modificando ou eliminando colunas ou restrições. Para alterar uma tabela, deve-se observar o seguinte:
z

z

z

Uma tabela pode ser alterada por seu criador ou qualquer usuário com direitos de superusuário do sistema operacional. ALTER TABLE provoca erro se os novos dados em uma tabela violam as definições de restrição PRIMARY KEY ou UNIQUE. Eliminar uma coluna provoca falha se:
z

z z z
Banco de Dados

A coluna é parte de uma restrição UNIQUE, PRIMARY KEY ou FOREING KEY. A coluna é usada em uma restrição CHECK. A coluna é utilizada em uma expressão value de uma coluna calculada. A coluna é referenciada por outros objetos, tais como uma visão.
Profª. Rossana Junqueira 143

Alteração de Tabelas
z

Exemplos de utilização de ALTER TABLE:
z

Incluir nova coluna
z

ALTER TABLE Fabrica ADD Email VARCHAR(30); ALTER TABLE Fabrica
ADD Contato VARCHAR(30) NOT NULL, ADD Fax VARCHAR(18);

z

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;
Profª. Rossana Junqueira 144

Banco de Dados

Alteração de Tabelas
z

Exemplos de utilização de ALTER TABLE:
z

Alterar o tipo de dado de uma coluna
z z

ALTER TABLE Fabrica ALTER Email TYPE VARCHAR(40); 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

Banco de Dados

ALTER TABLE Fabrica DROP CONSTRAINT Un_Mail;
Profª. Rossana Junqueira

145

Exclusão de Tabelas
z z

z

A instrução DROP TABLE remove dados de tabela. Não se pode eliminar uma tabela que é referenciada em uma coluna calculada, uma visão, restrição de chave estrangeira ou procedimento armazenado. DROP TABLE [nome da tabela]

Banco de Dados

Profª. Rossana Junqueira

146

Povoamento de Tabelas
z z

z

z

z z

INSERT armazena uma ou mais linhas de dados em uma tabela. Os valores inseridos devem estar na mesma ordem das colunas da tabela. 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. Para inserir uma única linha de dados na tabela, deve-se especificar uma lista de valores na cláusula VALUES. Inserções de dados nas tabelas não podem violar as restrições. É importante inserir dados primeiramente nas tabelas referenciadas por chaves estrangeiras.

Banco de Dados

Profª. Rossana Junqueira

147

Povoamento de Tabelas
z

Exemplos:
z

INSERT INTO Vendedor VALUES (1, ‘João Dias’); A instrução seguinte insere uma linha na mesma tabela, mas informa explicitamente as colunas para as quais serão informados:
z

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’);

Banco de Dados

Profª. Rossana Junqueira

148

Povoamento de Tabelas
z

INSERT INTO Transportadora VALUES (1, ‘Transpedroso’, ‘Av. Getúlio Vargas, 500’, ‘São Paulo’, ‘SP’); INSERT INTO Pedido VALUES (1, ’06/15/2005’, 500, 1, 1, 1);
z

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

z

As colunas Referencia e Id_ProdutoC da tabela Produto permitem valores nulos e esta é uma maneira de inserir nulos. A outra é a maneira como foi inserida a linha na tabela Fabrica. Omitiramse as colunas que receberão valores nulos.

Alteração de dados
z

z

z

z

A instrução UPDATE modifica os dados em toda ou parte de uma linha de uma tabela. 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. Se a cláusula WHERE não for utilizada, todas as linhas da tabela serão atualizadas. 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

150

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

151

Exclusão de linhas
z z z

z z z z z

O comando DELETE elimina linhas de uma tabela. Especifica uma ou mais linhas a serem eliminadas de uma tabela. 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. Se a cláusula WHERE não for especificada, todas as linhas da tabela são eliminadas. O comando a seguir deleta todas as linhas da tabela:
z

DELETE FROM ProdutoPedido;

A exclusão de linhas de uma tabela não pode violar as restrições de chave estrangeira. Se não, devem ser excluídas inicialmente as linhas da tabela filha (a tabela que tem a chave estrangeira). O comando seguinte elimina linhas específicas de uma tabela:
z

DELETE FROM ProdutoPedido WHERE Id_Pedido = 1;
Profª. Rossana Junqueira 152

Banco de Dados

Consultas a dados de uma tabela
z

z

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. O comando SELECT é o comando SQL utilizado para recuperar informações de bancos de dados. Operadores:
z

z

A cláusula WHERE utiliza expressões que limitam as linhas da tabela a serem recuperadas. 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

153

Consultas a dados de uma tabela
z

Aritméticos:
+ * / Adição Subtração Multiplicação Divisão

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

z

Lógicos:
AND OR NOT E Ou Não

z

De concatenação:
|| Concatenação de strings
Profª. Rossana Junqueira 154

Banco de Dados

Consultas a dados de uma tabela
z

Consultas simples:
z

SELECT * FROM CLIENTE;
z z

Esse comando recupera todas as linhas e colunas da tabela CLIENTE. 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

z
Banco de Dados

SELECT ID_FABRICA AS ID, RAZAOSOCIAL AS "RAZÃO SOCIAL“ FROM FABRICA; A cláusula AS permite que as colunas recebam um apelido.
Profª. Rossana Junqueira 155

Consultas a dados de uma tabela
z z z z

A cláusula AS permite que as colunas recebam um apelido. Se o apelido possuir espaços deve-se defini-lo entre aspas. A cláusula AS é opcional. 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

z

z

SELECT ID_PRODUTO, ID_CONDICAO, PRECO * 1.05 FROM PRODUTOCOND; Esta consulta mostra os preços dos produtos com seus valores reajustados em 5%. No resultado da consulta, essa coluna não estará identificada. Assim, é fortemente aconselhável utilizar sempre os apelidos.
ƒ

Banco de Dados

SELECT ID_PRODUTO, ID_CONDICAO, PRECO * 1.05 “Novo Preço” FROM PRODUTOCOND;
Profª. Rossana Junqueira

156

Consultas a dados de uma tabela
z

A consulta seguinte utiliza o operador de concatenação:
z

z

z

SELECT NOME, ENDERECO, CIDADE || '-' || UF "CIDADE-ESTADO" FROM CLIENTE; 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 (-). 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 z z

SELECT CIDADE FROM CLIENTE; O comando acima poderia retornar linhas duplicadas. Para eliminar as duplicações utiliza-se DISTINCT:
ƒ

SELECT DISTINCT CIDADE FROM CLIENTE;
Profª. Rossana Junqueira 157

Banco de Dados

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. Com operadores de Comparação:
z

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.
Profª. Rossana Junqueira 158

Banco de Dados

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.
Profª. Rossana Junqueira 159

Banco de Dados

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

160

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

z

Como padrão, uma consulta recupera linhas na mesma ordem em que ela as encontra na tabela. 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

z

SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA ORDER BY CIDADE; SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA ORDER BY CIDADE DESC, RAZAOSOCIAL;
Profª. Rossana Junqueira 161

Banco de Dados

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.
Profª. Rossana Junqueira 162

Banco de Dados

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. SELECT ID_CLIENTE, AVG(VALOR) FROM PEDIDO GROUP BY ID_CLIENTE;
z z

z

O exemplo retorna o valor médio dos pedidos de cada cliente. 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

163

Relacionamento entre tabelas
z

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. 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 z

Observa-se neste exemplo o uso do alias de uma tabela. Um alias, ou apelido, é uma variável temporária que representa o nome da tabela.
Profª. Rossana Junqueira 164

Banco de Dados

Sign up to vote on this title
UsefulNot useful