PROF.

EROS MOURA

LICENCIATURA EM INFORMÁTICA
Bando de Dados

1ª Edição

CACHOEIRO DE ITAPEMIRIM
IFES/CEAD
2011
© Instituto Federal do Espírito Santo
Governo Federal
Ministro de Educação
Fernando Haddad
Instituto Federal do Espírito Santo (Ifes)
Reitor
Dênio Rebello Arantes
Pró-Reitora de Ensino
Cristiane Tenan Schlittler dos Santos
Diretora do CEAD – Centro de Educação a Distância
Yvina Pavan Baldo
Coordenadores da UAB – Universidade Aberta do Brasil
Marize Lyra Silva Passos
José Mario Costa Junior

Curso Licenciatura em Informática

Coordenação de Curso
José Inácio Serafini
Designer Instrucional
Edmundo Rodrigues Junior
Professor Especialista/Autor
Eros Estevão de Moura

Catalogação da fonte: Renata Lorencini Rizzi - CRB 6/685

M929b Moura, Eros Estevão de
Banco de dados / Eros Estevão de Moura. Cachoeiro de Itapemirim:
Ifes, 2011.
124p. : il
ISBN 978-85-62934-13-1
1. Banco de dados. 2. SQL (Linguagem de programação de
computador). I. Instituto Federal de Educação, Ciência e Tecnologia do
Espírito Santo. II. Título.
CDD: 005.74

DIREITOS RESERVADOS
Instituto Federal do Espírito Santo (Ifes)
Avenida Rio Branco, nº 50 Santa Lúcia - CEP. 29056-255 – Vitória – ES - Telefone: 3227-5564
Créditos de autoria da editoração
Capa: Juliana Cristina da Silva
Projeto gráfico: Juliana Cristina e Nelson Torres
Iconografia: Nelson Torres
Editoração eletrônica: Gráfica Editora Fátima
Revisão de texto:
Esther Orlieb Faria de Almeida
COPYRIGHT – É proibida a reprodução, mesmo que parcial, por qualquer meio, sem autorização escrita dos
autores e do detentor dos direitos autorais.
Olá, Aluno(a)!

É um prazer tê-lo(a) conosco.

O Ifes – Instituto Federal do Espírito Santo – oferece a você, em parceria

com as Prefeituras e com o Governo Federal, o Curso Licenciatura em
Informática, na modalidade a distância. Apesar de este curso ser ofertado
a distância, esperamos que haja proximidade entre nós, pois, hoje, graças
aos recursos da tecnologia da informação (e-mails, chat, videoconferên-
cia, etc.) podemos manter uma comunicação efetiva.

É importante que você conheça toda a equipe envolvida neste curso: co-
ordenadores, professores especialistas, tutores a distância e tutores presen-
ciais, porque, quando precisar de algum tipo de ajuda, saberá a quem
recorrer.

Na EaD – Educação a Distância, você é o grande responsável pelo sucesso

da aprendizagem. Por isso, é necessário que se organize para os estudos e
para a realização de todas as atividades, nos prazos estabelecidos, confor-
me orientação dos Professores Especialistas e Tutores.

Fique atento às orientações de estudo que se encontram no Manual do

Aluno!

A EaD, pela sua característica de amplitude e pelo uso de tecnologias mo-

dernas, representa uma nova forma de aprender, respeitando, sempre, o
seu tempo.

Desejamos-lhe sucesso e dedicação!

Equipe do Ifes
ICONOGRAFIA

Veja, abaixo, alguns símbolos utilizados neste material para guiá-lo em seus estudos

Fala do Professor

Conceitos importantes. Fique atento!

Atividades que devem ser elaboradas por você,

após a leitura dos textos.

Indicação de leituras complementares, refe-

rentes ao conteúdo estudado.

Destaque de algo importante, referente ao

conteúdo apresentado. Atenção!

Reflexão/questionamento sobre algo impor-

tante referente ao conteúdo apresentado.

Espaço reservado para as anotações que você

julgar necessárias.
 APRESENTAÇÃO

Olá!

Meu nome é Eros Moura, responsável pela disciplina Banco de Dados.

Atuo como professor do Ifes há 5 anos e já lecionei em outras instituições de
ensino superior (São Camilo e Unes, ambas em Cachoeiro de Itapemirim -
ES). Sou graduado em Processamento de Dados (1989) pela, hoje, Univer
Cidade - Rio de Janeiro, com pós-graduação em Segurança em Banco de
Dados, pela Universidade Estácio de Sá (2004), no Rio de Janeiro, e tenho
Mestrado em Informática, pela Universidade Candido Mendes (2006), Rio
de Janeiro. Hoje, sou doutorando em Produção Vegetal, pela Universidade
Norte Fluminense (UENF). Tenho uma grande experiência de mercado de
trabalho e tive oportunidade de trabalhar em grandes empresas, tais como
a Embratel e a IBM. Minhas áreas de interesse são: Banco de Dados, Data
Mining, Text Mininge Sistemas de Suporte a Decisão. Antes de atuar como
professor, trabalhei durante 12 anos como administrador de banco de
dados (DBA database administrator). Também sou certificado no SGBD
Oracle (OCP), no qual trabalhei a maior parte do tempo.

Nesta disciplina, você conhecerá o papel desempenhado pelos sistemas

gerenciadores de banco de dados relacionais (SGBDR).

A disciplina de Banco de Dados tem como objetivo principal preparar o

profissional para definir, implementar e utilizar um banco de dados. Como
existem vários SGBDR disponíveis no mercado, vamos dar preferência
à utilização de comandos na sua forma padrão. Quando isso não for
possível, será feita indicação para avisar a especificidade do comando.

Nesta disciplina, será utilizado o SGBDR PostGreSQL em nossos trabalhos,

que é um software gratuito (Open Source license).

A fim de que ele seja aproveitado ao máximo por você, seguem algumas
orientações:

- faça a leitura de forma sequencial, evitando saltar partes. Isso,

pois consideramos que, na escrita de cada tópico, o leitor já domina o
tópico anterior;

- faça as atividades propostas assim que terminar de ler cada

tópico ou capítulo, evitando acumular atividades. Essa atitude simples
pode favorecer muito seu desempenho no processo de aprendizagem;

- seja sistemático no seu estudo, evitando ficar muitos dias sem

consultar este material. É importante que você reserve diariamente um
tempo para estudo e para fazer as atividades propostas;
 - procure participar de grupos de estudo, aproximando-se de
pessoas com quem você possa estudar. Lembre-se de que seu acesso à
Internet (seja em casa, no trabalho, na instituição de ensino ou em uma
lan house) dá a essa parceria um alcance muito maior.

Este texto está organizado em seis capítulos: o primeiro está relacionado

à modelagem conceitual; o capítulo seguinte apresenta o modelo lógico e
o modelo físico; o terceiro capítulo trata de uma introdução a Banco de
Dados.

Após ser feita esta introdução a Banco de Dados, nos demais capítulos
serão vistas as linguagem SQL, que podem ser divididas em: DDL,
estudada no quarto capítulo; DML, estudada no quinto capítulo; e, no
sexto, estaremos vendo o comando Select.

Meus votos são de que Deus o abençoe, permitindo que você tenha um
ótimo desempenho acadêmico e que aproveite ao máximo em sua vida
profissional as competências desenvolvidas nesta disciplina.

Assim, desejo-lhe bastante sucesso!!!

Prof. Eros Moura

Bons estudos!
Cap.1 MODELAGEM DE DADOS: CONCEITUAL  11
1.1. Níveis de abstração: Dado x Informação  11
1.2. Conceitos básicos em modelagem conceitual  12
1.2.1. Definição de modelo  12
1.2.2. O papel do objeto observado  13
1.2.3. O processo de modelagem  14
1.2.4. Tipos de modelos  14
1.2.5. Execução da modelagem de dados  15
1.2.6. Os níveis de modelagem de dados  17
1.3. Modelo Conceitual de Dados (MCD)  18
1.3.1. Entidades  20
1.3.2. Relacionamentos  20
1.3.3. Atributo  26
1.3.4. Criando o modelo de dados conceitual  32

Cap.2 MODELO LÓGICO DE DADOS (MLD)  37

2.1. Regras de Derivação  39
2.1.1. Etapa 1: Mapeamento de tipos de entidade regular  39
2.1.2. Etapa 2: Mapeamento de tipos de entidade fraca  40
2.1.3. Etapa 3: Mapeamento dos tipos de relacionamento binários
1:1  40
2.1.4. Etapa 4: Mapeamento de tipos de relacionam binário
1:N  41
2.1.5. Etapa 5: Mapeamento de tipos de relacionamento binário
N:N  41
2.1.6. Etapa 6: Mapeamento de atributos multivalorados  42
2.1.7. Etapa 7: Mapeamento de Autorrelacionamento 1:N  42
2.1.8. Etapa 8: Autorrelacionamento N:N  43
2.1.9. Etapa 9: Mapeamento de tipos de relacionamento n-ário
(qualquer relacionamento maior que o binário).  43
2.1.10. Etapa 10: Mapeamento da especialização /
generalização  45
2.2. Normalização  46
2.2.1. Primeira Forma Normal (1FN)  47
2.2.2. Segunda Forma Normal (2FN)  47
2.2.3. Terceira Forma Normal (3FN)  48
2.2.4. Exemplo de Modelo Lógico  49
2.3. Modelo Físico de Dados (MFD)  50
Cap.3 INTRODUÇÃO A BANCO DE DADOS  53
3.1. Conceitos Básicos de Banco de Dados  53
3.2. Sistema Gerenciador de Banco de Dados  56
3.3. Estrutura geral do SGBD - principais
componentes  57
3.3.1. Definição de dados  57
3.3.2. Manipulação de dados  58
3.3.3. Otimização e execução  58
3.3.4. Segurança e integridade de dados  59
3.3.5. Recuperação de dados e concorrência  59
3.3.6. Dicionário de dados  59
3.3.7. Desempenho  59
3.4. Banco de dados Cliente/Servidor  60
3.5. Vantagens do uso de SGBD  61
3.5.1. Aprimoramento do compartilhamento de dados  61
3.5.2. Aprimoramento da segurança de dados  61
3.5.3. Melhoria na integração dos dados  61
3.5.4. Minimização da inconsistência dos dados  61
3.5.5. Aprimoramento do acesso aos dados  62
3.5.6. Aprimoramento da tomada de decisão  62
3.5.7. Aumento de produtividade do usuário final  62
3.5.8. Outras vantagens  62
3.6. Desvantagens do uso de SGBD  63
3.6.1. Aumento de custos  63
3.6.2. Complexidade de gerenciamento  63
3.6.3. Manutenção do banco de dados atualizado  63
3.6.4. Dependência do fornecedor  63
3.6.5. Ciclos frequentes de atualização/substituição  64
3.7. SGBD gratuitos  64

Cap.4 A LINGUAGEM SQL – DDL E PERMISSÕES  65

4.1. A importância de saber ler um manual  67
4.2. SQL/DDL (Data Definition Language)  69
4.3. CREATE  69
4.4. CREATE TABLE  70
4.4.1. Os tipos de dados mais utilizados  71
4.4.2. Restrições de Integridade  71
4.4.3. Valor default  74
4.5. CREATE INDEX  74
4.6. Domains  75
4.7. ALTER  76
4.7.1. Alter Table  76
4.8. DROP  78
 4.8.1. Drop Table  78
4.8.2. Drop Index  79
4.9. Esquema  79
4.10. Usuários  80
4.11. Grupos  81
4.12. Privilégios  81

Cap.5 A LINGUAGEM SQL - DML  85

5.1. DML (Data Manipulation Language)  85
5.2. INSERÇÃO DE LINHAS NA TABELA  86
5.3. ATUALIZAÇÃO DE LINHAS DA TABELA  87
5.4. OPERADORES ESPECIAIS  89
5.4.1. Operador especial BETWEEN  89
5.4.2. Operador especial IS NULL  89
5.4.3. Operador especial LIKE  90
5.4.4. Operador especial IN  91
5.4.5. Operador especial EXISTS  92
5.5. EXCLUSÃO DE LINHAS DA TABELA  93

Cap.6 A LINGUAGEM SQL – COMANDO SELECT  97

6.1. Listagem de linhas da tabela  97
6.2. Funções de agregação  98
6.2.1. Função de agregação - Count  98
6.2.2. Função de agregação – Sum  99
6.2.3. Função de agregação – AVG  100
6.2.4. Função de agregação – MIN  100
6.2.5. Função de agregação – MAX  101
6.2.6. Agrupamentos  101
6.2.7. Restrições para o Agrupamento  103
6.2.8. Ordenação  103
6.3. Utilização dos principais operadores com o coman-
do Select  104
6.4. Junções na SQL  104
6.4.1. Junção cruzada  109
6.4.2. Junção natural  109
6.4.3. Cláusula de junção USING  110
6.4.4. Cláusula de junção JOIN ON (ou INNER JOIN ON)  111
6.4.5. Junções externas  111
6.5. Visualização Relacional - VIEW  113
6.6. OPERADORES DO CONJUNTO rE-LACIONAL  114
6.6.1. UNION  114
6.6.2. UNION ALL  115
6.6.3. INTERSECT  116
 6.7. ATUALIZAÇÃO AVANÇADA DE LINHAS DA
TABELA  116
6.8. EXCLUSÃO AVANÇADA DE LINHAS DA
TABELA  118

REFERÊNCIAS 123
 MODELAGEM DE DADOS:
CONCEITUAL

Olá, Turma!
Neste capítulo, apresentaremos a modelagem de dados, conteúdo
que é fundamental para o desenvolvimento de sistemas. A ideia
é que você consiga, ao final deste capítulo, desenhar um modelo
que demonstre os aspectos importantes do ambiente onde você vai
desenvolver um sistema.
Os objetivos deste capítulo são:
• conhecer os conceitos básicos em Modelagem conceitual;
• compreender o conceito de informação e dado;
• conhecer os tipos de modelos de dados;
• compreender o modelo conceitual;
• compreender o que é atributo e o seu valor;
• compreender o que é atributo composto, multivalorado e
determinante;
• reconhecer o relacionamento existente entre entidades;
• definir o grau em um relacionamento;
• conhecer relacionamento parcial e total;
• conhecer a entidade associativa ou de agregação;
• conhecer o auto-relacionamento ou exclusivo.

1.1. Níveis de abstração: Dado x

Informação

Podemos definir dado como um fenômeno qualquer desprovido de

um significado. No momento em que o dado é contextualizado em um
determinado nível de abstração, passa a ser identificado como uma
informação. Portanto, podemos definir informação como o resultado
do processamento, manipulação e organização de dados de tal forma
que represente um acréscimo ao conhecimento da pessoa que a recebe.

Para Rob e Coronel (2011), os dados são fatos brutos. A palavra bruto
indica que os fatos ainda não foram processados para revelar seu
12
EROS MOURA

significado, e as informações são o resultado do processamento de dados

brutos para revelar seu significado. Para Elmasri e Navathe (2011), os
dados são fatos que podem ser gravados e que possuem um significado
implícito. Para Date (2003), essa distinção (entre dado e informação) é
claramente importante - tão importante que parece preferível torná-la
explícita, onde for apropriado, em vez de contar com uma diferenciação,
de certa forma arbitrária, entre dois termos basicamente sinônimos.

Em banco de dados, poderíamos exemplificar esta diferença da seguinte

forma: dado é o que está armazenado no banco de dados e informação
se refere ao significado desses dados para um determinado usuário.

Para Elmasri e Navathe (2011), um banco de dados é uma coleção

de dados relacionados.

1.2. Conceitos básicos em modelagem

conceitual

1.2.1. Definição de modelo

Em uma definição mais ampla, modelo pode ser:

MODELO é a representação abstrata e simplificada de um sistema
real, com a qual se pode explicar ou testar o seu comportamento,
em seu todo ou em partes. (Cougo, 1997).

Vamos analisar melhor esta definição: “O modelo é a representação

abstrata e simplificada de um sistema real”, dando um exemplo para que
isso fique mais claro. Imagine que você quer comprar um apartamento.
Você chega à imobiliária e mostram-lhe uma maquete ou uma planta.
Você não está vendo exatamente o apartamento que quer comprar, e,
dependendo da qualidade da maquete ou da planta, muitos detalhes
podem não estar identificados (por exemplo: o local onde você poderia
colocar um abajur), mas você consegue identificar qual a quantidade
de quartos, quantos banheiros, etc, sem a necessidade de visitar a
construção. Portanto, isto é um modelo.

Continuando a análise da definição: “com a qual se pode explicar ou

testar o seu comportamento, em seu todo ou em parte”.. Neste mesmo
exemplo, podemos verificar a posição do quarto, verificar que o quarto
 13
BANCO DE DADOS

não tem janela, ou que o banheiro não tem báscula. Você, através da
maquete ou da planta, será capaz de avaliar se você gosta, ou não, destas
coisas.

Logo, o modelo não é uma estrutura real, mas algo que a representa , com
maior ou menor nível de detalhes. E isso faz com que, pela observação
deste modelo, possamos ter nossas necessidades de informação
satisfeitas.

Vamos ver mais alguns e exemplos de modelos, fora da informática, que

encontramos em nosso dia-a-dia:

• o manequim da vitrine;

• a foto de um conjunto estofado;

• o desenho em perspectiva de sua nova cozinha;

• o molde de uma nova roupa, obtido em uma revista.

Assim como esses, vários outros exemplos poderiam ser dados para
demonstrar o uso de modelos em nosso dia a dia. O que é importante
é perceber que, através de algum meio, seja uma maquete, uma planta,
um desenho, etc., podemos antecipar ou substituir a existência de uma
realidade qualquer. Ou seja, por meio de um elemento semelhante, em
escala ou não, representamos um objeto desejado e, assim, podemos
percebê-lo e entendê-lo.

Procure no seu dia a dia e dê mais exemplos de modelos.

1.2.2. O papel do objeto observado

Em relação aos exemplos que foram dados até agora, sempre tivemos
modelos de algum objeto que, em um determinado momento, serviram
como uma referência para suas criações. Por exemplo: a maquete teve
como referência um apartamento (a maquete era de um apartamento),
o manequim teve como referência um ser humano, a foto do conjunto
estofado teve como referência o estofado.

O termo Objeto é utilizado de modo genérico para caracterizar

qualquer coisa, pessoa, ambiente, conceito, etc.
14
EROS MOURA

Assim, um arquiteto, ao desenhar a planta baixa de um novo apartamento,

estará reproduzindo um objeto imaginário que já existe, pelo menos, em
sua imaginação. Poderíamos dar outro exemplo no qual a planta baixa
seria de um imóvel que acabou de ser vistoriado. Neste caso, o objeto a
ser modelado é concreto e não mais imaginário. Ou seja, a modelagem
necessita, obrigatoriamente, de um objeto a ser modelado, seja ele real
ou imaginário.

Dessa forma, ao criarmos um modelo de dados, estaremos reproduzindo

algo que foi observado: concreto ou imaginário. Então, podemos
perceber que o processo de levantamento de dados é muito importante
para a modelagem de dados. Mas, se não captarmos informações que
nos caracterizem devidamente os objetos, não conseguiremos fazer
uma correta observação desse objeto, assim, nosso modelo não o
contemplará.

Por exemplo: ao fazer o levantamento dos dados, faltou a informação

do número de quartos. Assim, quando eu for desenvolver meu modelo
poderá haver um erro na quantidade de quartos.

1.2.3. O processo de modelagem

Para criar um modelo de dados a partir de um conjunto de objetos

observados é importante levar em conta alguns quesitos. Cada um destes
quesitos será fundamental para que o resultado (o modelo de dados)
gerado seja o esperado. A ordem dos quesitos a serem satisfeitos é:

• abrangência: definir a abrangência ou escopo do trabalho é fundamental.

Este referencial vai definir que objetos teremos que buscar em nosso
processo de observação;

• tempo para a produção do modelo e recursos disponíveis: teremos que

saber o tempo e o tamanho da equipe disponível para fazer o modelo
de dados.

1.2.4. Tipos de modelos

Os principais modelos são:

• Hierárquico;
• Redes;
• Relacional;
• Orientado a Objetos;
 15
BANCO DE DADOS

O modelo de dados relacional é o mais largamente utilizado no mercado,

por esse motivo vamos utilizá-lo em nossa disciplina.

1.2.5. Execução da modelagem de dados

É um processo cíclico de atividades que também terá seus quesitos a

serem atendidos e que envolverá os seguintes passos:

1. a observação dos objetos;

2. o entendimento dos conceitos;
3. a representação dos objetos;
4. a verificação de fidelidade e coerência;
5. a validação do modelo.

Cada um desses passos fornecerá elementos para que o próximo passo

possa ser iniciado, ou, então, que há problemas em sua execução, o que
exigirá a volta aos passos anteriores. Este ciclo será repetido cada vez
que houver a adição de uma extensão ao modelo.

A seguir, iremos descrever cada um desses passos.

Passo 1: A observação dos objetos

Não imagine você que, uma vez definida a abrangência, todos os objetos
que lhe serão apresentados pelos processos de levantamento de dados
pertencerão ao escopo predefinido. Você, conforme sua habilidade em
levantar dados, poderá escolher caminhos que o levem para mais perto
do resultado esperado, mas, certamente, muito “ruído”, ou “lixo” virá
junto à massa de dados obtida, por qualquer que seja o processo.

Através de entrevistas, reuniões, questionários, análise de documentos,

análise de dados já estruturados em outros processos, etc., poderemos
encontrar a quase totalidade de nossos objetos.

Passo 2: O entendimento dos conceitos

O núcleo do processo de modelagem, ou o ponto no qual realmente se

processa a transposição do objeto observado para o objeto reproduzido,
é o instante em que, ao analisar um objeto, conseguimos:

➢ Identificá-lo
➢ Conceituá-lo
➢ Entendê-lo
➢ Assimilá-lo
16
EROS MOURA

Essa sequência de fases faz com que algo, que até certo instante era
desconhecido para nós, passe a fazer parte de nosso conhecimento e
seja incorporado ao conjunto de objetos de nosso domínio.

Passo 3: Representação dos objetos

Após termos identificado os objetos, suas características, seus

relacionamentos com outros objetos e seu comportamento, poderemos
aplicar uma das várias técnicas de representação de objetos que nos são
disponibilizadas. Algumas mais detalhistas; outras, mais simplistas;
algumas mais formais; outras, mais flexíveis. Sem dúvida, o domínio
dessas técnicas ajudará sensivelmente na produção do resultado final.

O domínio de técnicas de modelagem é necessário, mas não é suficiente

para se produzirem bons modelos.

O domínio de técnicas de modelagem é necessário, mas não é

suficiente para se produzirem bons modelos.

Passo 4: Verificação de fidelidade e coerência

Após terem sido representados novos objetos, através de uma técnica

escolhida, devemos verificar se a representação gerada, associada aos
objetos já existentes (ou não) previamente no modelo, continua a
formar um conjunto, em sua totalidade, coerente e fiel aos conceitos
encontrados.

Passo 5: Validação do modelo

Os procedimentos de validação, que sucedem as verificações feitas no

passo anterior, têm papel fundamental no encerramento do processo
de modelagem de dados. Será através da validação que obteremos a
aprovação formal do cliente, ou a indicação de pontos falhos existentes
em nossos modelos. Devemos ter em mente, neste instante, duas grandes
máximas aplicáveis à modelagem de dados:

Não ame seu modelo de dados!

Se você acha que seu modelo está bom, é porque talvez ainda não
o tenha olhado direito!
 17
BANCO DE DADOS

Quais são os tipos de modelos que existem?

Qual desses modelos é mais utilizado no mercado de trabalho?

1.2.6. Os níveis de modelagem de dados

Durante o ciclo de desenvolvimento do modelo de dados passarão por

níveis distintos, cada um com suas características e particularidades.
Na abordagem entidade-relacionamento (E-R) de Peter Chen, defende-
se basicamente a elaboração de um modelo que represente os objetos
e seus relacionamentos, independentemente de preocupações com
implementações lógicas ou físicas. Peter Chen entende que esses
aspectos devem ser agregados em um momento depois do primeiro,
pois são alheios à estrutura inerente de dados observados. Em outras
palavras, Chen defende que devemos, em um primeiro momento,
estar preocupados apenas com objetos que estão sendo observados,
sem levar em conta outras preocupações que deverão ser tratadas em
outro momento.

Peter Chen foi quem propôs a técnica de modelagem Entidade-

Relacionamento em 1976, em seu trabalho intitulado “The Entity-
Relationship Model: Toward the unified view of data” no qual
definia uma possível abordagem para o processo de modelagem.

Assim, teremos três tipos distintos de modelos de dados: modelo

conceitual de dados (MCD), modelo lógico de dados (MLD) e modelo
físico de dados (MFD). Cada um desses modelos será visto a seguir.
18
EROS MOURA

{
Análise de
requisitos { Entrevista
Necessidade do negócio

{
Modelo Modelagem de dados
Conceitual Definição: entidade, atributo,
(DER) relacionamentos
As etapas não consideram
ainda nehuma característica

{
específica de um SGBD, apenas
o tipo Modelo Definição do tipo
Lógico SGBD

{
Construção do BD
Modelo Linguagem SQL
Físico Dicionário de dados
Definição do SGBD

Três tipos distintos de modelos de dados: modelo conceitual de

dados (MCD), modelo lógico de dados (MLD) e modelo físico de
dados (MFD).

Você vai começar um trabalho de modelagem de dados. Qual dos

modelos de dados visto até agora deverá ser o primeiro a ser feito?

1.3. Modelo Conceitual de Dados (MCD)

Define-se como modelo conceitual aquele em que os objetos, suas

características e relacionamentos têm a representação fiel do ambiente
observado, independente de limitações quaisquer impostas por
tecnologias, técnicas de implementação ou dispositivos físicos. Nesse
modelo, devemos representar os conceitos e características observados
em um dado ambiente, voltando-nos simplesmente ao aspecto
conceitual.

Esse deve ser o modelo a ser utilizado para o nível de conversação,

entendimento, transmissão, validação de conceitos, mapeamento
do ambiente, etc. Nesse nível, devem ser ignoradas quaisquer
particularidades de implementação, bem como desconsiderada qualquer
preocupação com qual será o modo de implementação futura. Assim,
nosso modelo conceitual de dados (MCD) permanecerá imutável, tanto
 19
BANCO DE DADOS

se vier a ser implementado em um SGBD relacional, como em um SGBD

hierárquico ou, ainda, um SGBD rede.

Na verdade, essa estabilidade é o grande diferencial na utilização de um

modelo conceitual de dados. Devemos derivar diferentes estruturas de
implementação a partir de um mesmo modelo conceituai, e não criá-las
e mantê-las separadamente. Assim, a partir de um MCD poderemos, a
qualquer instante, derivar um modelo para implementação em SGBD
relacional. Se, futuramente, nossa necessidade não for mais de um
modelo relacional, descartaremos o modelo derivado, voltaremos ao
modelo conceitual original, aplicaremos outras regras de derivação e,
então, poderemos ter outro tipo de modelo novamente derivado.

O modelo Entidade-Relacionamento definido por Peter Chen, em 1976,

teve como base a teoria relacional criada por E.F.Cood (1970). Segundo
Chen, a visão de uma dada realidade baseia-se no relacionamento
entre entidades, os quais retratam os fatos que governam esta mesma
realidade. Essas a entidades possuem atributos. O relacionamento
pode ou não possuir atributos (qualificadores desta realidade). Ao
utilizar a Modelagem Conceitual de dados com a técnica de Entidade
e Relacionamentos, obteremos resultados e esquemas puramente
conceituais sobre o negócio para o qual estamos desenvolvendo um
projeto. Os objetos que desejamos conhecer e modelar para um sistema,
Chen classificou-os em dois grupos: Entidades e Relacionamentos. Um
modelo Entidade-Relacionamento (ER) é representado graficamente
por meio de um diagrama entidade-relacionamento (DER), cujos
elementos básicos são chamados de entidades, relacionamentos e
atributos.

Em sala de aula, quando estou falando do modelo conceitual,

sempre digo uma frase que, entendo, resume a visão que tenho, na
prática, desta parte da modelagem: “Seu maior objetivo é entender
seu cliente e, ao mesmo tempo, ser entendido por ele”. Um erro
nesta fase poderá ter um impacto muito grande no futuro.

Matrícula
(0,N) (1,1)
Alunos Lotação Cursos
Nome Código Nome
AnoIngresso

Figura 1: Diagrama entidade-relacionamento (DER)

20
EROS MOURA

1.3.1. Entidades

Uma entidade é algo (uma pessoa, um local, um objeto, um evento)

sobre o qual se deseja que sejam coletados e armazenados dados. Ela
representa um tipo particular de objeto no mundo real. Por isso, as
entidades são “distinguíveis”, ou seja, cada ocorrência de entidade é
única e distinta. Por exemplo: uma entidade CLIENTE teria muitas
ocorrências de clientes distinguíveis, como João, Pedro, José Silva, etc.
As entidades podem ser objetos físicos, como clientes e produtos, mas
também abstrações, como rotas de voo ou apresentações musicais.

PESSOA PROFESSOR ALUNO

MATERIAL MEIO DE
TRANSPORTE

As entidades são representadas por retângulos.

Estratégias para reconhecer entidades:

- procurar as coisas tangíveis do universo modelado: aquilo que pode

ser tocado. Exemplos: carro, cachorro, gato, livro, caderno, mesa, etc;

- procurar as funções do universo modelado: todo o tipo de papel,

atribuição, classificação, ou outra característica qualquer que, para
um dado elemento, especifique não sua existência, mas sua atuação
no ambiente em que está inserido. Exemplos: Departamento de uma
empresa, o autor de um livro, um médico, etc;

procurar os eventos ou ocorrências do universo modelado: são ações ou

fatos que, uma vez ocorrendo, possuem características próprias sobre as
quais podemos fazer alguma referência. Exemplos: um voo comercial,
um acidente de trânsito, uma partida de vôlei, etc.

1.3.2. Relacionamentos

Um relacionamento descreve uma associação entre entidades. Por

exemplo, existe um relacionamento entre clientes e corretores que pode
ser descrito da seguinte maneira: um corretor pode atender muitos
clientes, mas cada cliente pode ser atendido apenas por um corretor.
Os modelos de dados utilizam três tipos de relacionamento: um para
muitos, muitos para muitos e um para um. Os projetistas de bancos
de dados costumam utilizar as notações abreviadas 1:N, N:N ou e 1:1,
respectivamente (Embora a notação N:N seja a identificação-padrão
 21
BANCO DE DADOS

para o relacionamento de muitos para muitos, também é possível utilizar

a abreviação M:N.).

Os exemplos a seguir ilustram as distinções entre os três.

Relacionamento um para muitos (1:N) - Um pintor faz várias pinturas,

mas cada uma é criada por apenas um artista. Assim, o pintor (“uma
ocorrência da entidade pintor”) relaciona-se com as pinturas (“várias
ocorrências da entidade pintura”). Portanto, os projetistas de bancos
de dados identificam o relacionamento “PINTOR pinta PINTURA”
como 1:N. (Observe que os nomes de entidades, em geral, são escritos
no singular por convenção. Em uma empresa, você deve definir um
padrão e usá-lo em todas as entidades ou relacionamentos.) De modo
similar, um cliente (“uma entidade”) pode gerar muitas faturas (“várias
ocorrências de faturas na entidade fatura”), mas cada fatura é gerada
apenas por um cliente. O relacionamento “CLIENTE gera FATURA”
também seria identificado como 1:N.

Relacionamento de muitos para muitos (N:N) - Um funcionário pode

aprender várias habilidades profissionais e cada habilidade profissional
pode ser aprendida por vários funcionários. Os projetistas de bancos
de dados identificam o relacionamento “FUNCIONÁRIO aprende
HABILIDADE” como N:N. De modo similar, um aluno pode frequentar
várias turmas e cada turma pode ser frequentada por vários alunos,
conferindo-se, assim, a identificação N:N ao relacionamento expresso
por “ALUNO frequenta TURMA”.

Relacionamento um para um (1:1) - A estrutura de gerenciamento

de uma empresa de varejo pode exigir que cada uma de suas lojas seja
gerenciada por um único funcionário. Por sua vez, cada gerente de loja, que
é um funcionário, gerencia uma loja apenas. Portanto, o relacionamento
“FUNCIONÁRIO gerencia LOJA” é identificado como 1:1.

A discussão precedente identificou cada relacionamento em duas

direções, ou seja, os relacionamentos são bidirecionais:

➢ um CLIENTE pode gerar várias FATURAs;

➢ cada uma das várias FATURAs é gerada apenas por um CLIENTE.

Estes três tipos de relacionamentos indicam sua cardinalidade máxima.

Há também a cardinalidade mínima. Em um relacionamento binário, a
Cardinalidade Mínima indica se a participação de TODAS as ocorrências
de uma entidade em um determinado relacionamento é obrigatória (1)
ou opcional (0).
22
EROS MOURA

OBS: Em notações nas quais se assinala a cardinalidade mínima e

máxima, a cardinalidade mínima é anotada como primeiro elemento e
a máxima é anotada como segundo elemento.

Um livro obrigatoriamente tem

ao menos um autor (1, )

Livro Autoria Pessoa

(0, )
Uma pessoa pode não ser
autor de um livro

A restrição é uma limitação imposta aos dados. As restrições são

importantes, pois ajudam a assegurar a integridade dos dados. Elas,
normalmente, são expressas na forma de regras. Por exemplo:

➢ o salário de um funcionário possui valores entre 6.000 e 350.000;

➢ a média da nota de um aluno deve estar entre 0,00 e 10,00;

➢ cada turma deve ter um e somente um professor.

Embora a maioria dos relacionamentos ocorra entre duas entidades

(relacionamentos binários), podem ser definidos relacionamentos entre
qualquer número de entidades.

Por exemplo, para representar as seguintes regras de uma empresa de

projetos:

• cada projeto tem uma equipe formada por um ou mais

funcionários que executam diferentes funções no projeto;

• cada funcionário pode executar diferentes funções em vários

projetos, inclusive executar mais de uma função no mesmo projeto.

Vamos ver exemplos de dados para esta regra de negócio:

FUNCIONÁRIO PROJETO FUNÇÃO

Ana SuperRocha Análise de Sistemas
Ana RochaPlus Programação
Carlos RochaPlus Análise de Sistemas
Carlos RochaPlus Programação
 23
BANCO DE DADOS

Observe que Ana trabalha em funções diferentes em projetos diferentes

e Carlos trabalha em funções diferentes em um mesmo projeto. O
projeto RochaPlus tem mais de um funcionário, possui mais de um
programador.

Assim, a cardinalidade para essa situação poderia ser assim:

FUNÇÃO

(0,N )

(0,N ) (0,N )
PROJETO EQUIPE FUNCIONÁRIO

Escolha um lugar do qual você conheça o funcionamento. Faça

um exercício de selecionar “coisas” que você imagina serem
entidades. Tente achar a relação entre estas entidades.

Entidade Associativa

Há situações em que pode haver necessidade de uma entidade se

relacionar com um relacionamento. Isso não é possível, uma vez que este
conceito não é permitido na abordagem E/R, pois uma entidade apenas
se relaciona com outra entidade. Para resolver estas situações, temos
um conceito relacionado aos relacionamentos N:N : é o de Entidade
Associativa, que também recebe o nome Agregação. Uma Entidade
Associativa é uma forma de abstração em que o relacionamento entre
duas ou mais entidades é tratado como se fosse uma entidade. Assim,
esta entidade associativa pode, então, relacionar-se com uma outra
entidade. Vamos ver um exemplo:

N N
Médico Consulta Paciente

Suponha que seja necessário modificar este modelo da seguinte forma:

é necessário saber que medicamentos existem (então, precisamos de
uma entidade Medicamento) e quais medicamentos foram prescritos
em cada consulta.
24
EROS MOURA

Observe que Consulta é um relacionamento, por isto, não poderia

se relacionar com Medicamento. A saída, então, está na Entidade
Associativa.

N N
Médico Consulta Paciente

preescreve

Medicamento

Entidade Fraca

Entidades fracas são entidades que dependem de outras para existirem.

Nesse caso, a entidade de quem ela depende é chamada entidade forte.
Quando temos uma entidade fraca, obrigatoriamente fará parte de seus
atributos identificadores o atributo(s) identificador(es) da entidade
forte.

Pedido possui Itens Pedido

num_item
num_pedido
num_pedido

Nesse exemplo, só irão existir itens de pedido de houver um pedido. A

entidade Itens de Pedido terá como parte de seus atributos identificadores
o atributo identificador de Pedido.

Relacionamento parcial e total

(0,n) (1,1)
FUNCIONÁRIO trabalha como FUNÇÃO
 25
BANCO DE DADOS

O relacionamento “trabalha como” é total em relação a FUNCIONÁRIO

e parcial em relação à FUNÇÃO. Esse conceito é baseado na cardinalidade
mínima do relacionamento. Ele é total em relação a FUNCIONÁRIO,
pois todo funcionário participa do relacionamento pelo menos uma vez
(cardinalidade mínima 1) e parcial em relação à FUNÇÃO, pois pode
existir uma função que não participe do relacionamento nenhuma vez
(mínimo 0).

Autorrelacionamento

O autorrelacionamento (antes do acordo ortográfico era auto-

relacionamento e você deve encontrar assim, na literatura) é um caso
especial de relacionamento em que a entidade se relaciona com ela mesma.

matrícula
FUNCIONÁRIO nome_funcionário
matrícula_gerente
(1,n ) (1,1)

é gerente por é gerente de papel

GERÊNCIA

No autorrelacionamento há uma coisa nova que é o “papel” (o texto

escrito na ligação do relacionamento com a tabela) que tem o objetivo
de facilitar o entendimento do modelo. Neste caso, temos um modelo
que nos mostra que um funcionário pode gerenciar no mínimo 1
funcionário e no máximo vários funcionários. Também está descrito
que 1 funcionário é gerenciado por no mínimo 1 funcionário(gerente) e
no máximo 1 funcionário (gerente).

Generalização / Especialização

Imagine que você está modelando duas entidades e começa a observar

que vários atributos das duas entidades são iguais e uns poucos são
diferentes. A solução pode ser criar uma entidade com todos os atributos
comuns (Cliente) e outras duas (Pessoa Física e Pessoa Jurídica), cada
uma com seus atributos específicos.
26
EROS MOURA

código
CLIENTE
nome

PESSOA PESSOA
FÍSICA JURÍDICA

CPF CNPJ

A especialização pode ser classificada em dois tipos, total ou parcial, de

acordo com a obrigatoriedade ou não de, a cada ocorrência da entidade
genérica, corresponder uma ocorrência da entidade especializada.

Indica que
Indica que nem todo
o cliente é empregado
CLIENTE PF ou PJ EMPREGADO é motorista
ou secretária

t p

PESSOA PESSOA MOTORISTA SECRETÁRIA

FÍSICA JURÍDICA

1.3.3. Atributo

Um atributo é uma característica de uma entidade. Por exemplo: uma

entidade CLIENTE seria descrita por atributos como nome, telefone,
endereço, data nascimento, sexo e limite de crédito de clientes. Os
atributos são equivalentes aos campos nos sistemas de arquivos.

Para cada atributo existe um conjunto de valores permitidos ou válidos,

chamado domínio do atributo. Este domínio, quando for estático (não
muda), deverá ser indicado entre parênteses, por exemplo (S,N). Quando
você cria um relacionamento entre uma entidade A e uma entidade B,
também está informando que haverá um atributo que terá seu domínio
validado por uma entidade, neste caso um domínio dinâmico, uma vez
que será possível incluir ou excluir ocorrências na entidade que estará
validando o domínio desse atributo.
 27
BANCO DE DADOS

Vamos ver um exemplo do domínio dinâmico:

Pedido possui Itens Pedido

num_pedido num_item
num_pedido

O atributo num_pedido da entidade Itens Pedido só deverá aceitar

valores que estejam previamente cadastrados na entidade Pedido
(domínio dinâmico, pois pode-se incluir, alterar ou excluir valores
na entidade Pedido). Ao criar o relacionamento, você também estará
informando que haverá um atributo que ficará encarregado de fazer
esta ligação, o qual pode estar em uma das entidades utilizadas no
relacionamento. Neste caso, o atributo está na entidade Itens Pedido,
porque só faz sentido ter um item de pedido se houver um pedido. Isto
é abordado de uma forma mais detalhada no modelo lógico.

Um atributo deve ser associado a um relacionamento quando não for

possível associá-lo a uma entidade, como no exemplo a seguir.

→ Deseja-se modelar um sistema que irá guardar a posição em

que os pilotos chegaram, em todos os circuitos de uma temporada de
fórmula 1.

Temos duas entidades: Piloto e Circuito

PILOTO CIRCUITO

Temos que guardar a posição em que o piloto chegou, nos vários

circuitos em que correu.

Como exemplo, vamos imaginar as seguintes informações:

a) o piloto Felipe Massa chegou em 1º. Lugar no Brasil;

b) o piloto Felipe Massa chegou em 5º. Lugar na Espanha;
c) o piloto Felipe Massa chegou em 3º. Lugar na Austrália;
d) o piloto Rubens Barrichello chegou em 10º. Lugar no Brasil;
e) o piloto Rubens Barrichello chegou em 2º. Lugar na Espanha;
f) o piloto Rubens Barrichello chegou em 15º. Lugar na Austrália.
28
EROS MOURA

Vamos verificar a possibilidade de colocar este atributo em Piloto.

Nome do Poloto Posição de Chegada

Felipe Massa 1

Como poderei colocar a informação que

ele chegou em 5º na Espanha e em 3º na Austrália?
Se colocar 5 no lugar onde está o número 1, vou
perder a informação que ele chegou em
1º no Brasil.

Vamos verificar a possibilidade de colocar este atributo em Circuito.

Nome do Circuito Posição de Chegada

Brasil 1

Deu certo para o Felipe Massa, mas e

os outros pilotos quecorreram neste circuito.
Por exemplo, o Rubens Barrichello chegou na
10ª posição. Da mesma forma, se colocar o número
10 vou perder a informação do Felipe Massa

Neste caso, chegamos à conclusão que o atributo posição não pode ficar
nem na entidade Piloto e nem na Entidade Circuito. Assim, só resta o
relacionamento.
 29
BANCO DE DADOS

CLASSIFICAÇÃO

Piloto Corrida Circuito

A ocorrência de relacionamento com atributos é pequena, aparecendo

principalmente em relacionamentos N por N.

Todas as entidades devem possuir atributos.

Cardinalidade do atributo

(1,1) nome

(0,n)
FUNCIONÁRIO telefone

(0,1 ) data de nascimento

• (1,1) atributo obrigatório e monovalorado (neste caso, a

cardinalidade pode ser omitida);
• (0,1) atributo opcional e monovalorado;
• (1,N) atributo obrigatório e multivalorado
• (0,N) atributo opcional e multivalorado;

A cardinalidade mínima (o primeiro valor), indica se ele é obrigatório

(1) ou se ele é opcional (0).

A cardinalidade máxima (o segundo valor), indica se ele será

monovalorado (1) ou multivalorado (N).

OBS: Monovalorado: apenas 1 valor;

Multivalorado: vários valores.

Atributos Identificadores ou Determinantes

Um identificador é um atributo, ou menor grupo de atributos, que

determina univocamente uma ocorrência em uma entidade ou
relacionamento.
30
EROS MOURA

Você tem que definir em qual atributo ou em qual o menor conjunto

de atributos é possível identificar um elemento dentro do conjunto
(entidade) no qual ele está inserido. Imagine que você tem um saco
cheio de bolas numeradas (conjunto/entidade) de vários tamanhos,
vários pesos, várias cores e com vários números. Cada bola possui estas
informações (atributos): tamanho, peso, cor e número. Você sabe que há
várias bolas com o mesmo tamanho, que há várias bolas com o mesmo
peso, que há várias bolas com a mesma cor, porém cada bola possui um
número único, que não se repete. Lembre-se de que você deve escolher
um atributo ou o menor conjunto de atributos que possibilite identificar
um único elemento. Neste exemplo, se você escolhesse o atributo cor,
não daria certo, pois há mais de uma bola da mesma cor (basta haver
mais de uma para não servir). O mesmo ocorreria com os atributos
tamanho e peso. O atributo correto seria o número, pois cada bola
possui um número que não se repete em outra bola. Será, então, que se
poderia utilizar cor e número ou número e cor? Não. Lembre-se de que
tem que ser conjunto de menor tamanho possível. Neste caso, o menor
conjunto é o conjunto que possui apenas o atributo número.

Toda entidade deve possuir um e apenas um identificador, podendo este

ser simples ou composto, além de interno ou externo.

Identificador Simples

É formado de apenas 1 atributo.

matrícula

FUNCIONÁRIO
nome

Identificador Composto

É formado de mais de 1 atributo.

Os atributos identificadores são assinalados com

número da linha

número da coluna
MATRIZ
valor
 31
BANCO DE DADOS

Identificador Interno

Quando todos os atributos que formam o identificador da entidade

forem dela mesmo, temos o identificado interno.

Identificador Externo

Quando uma entidade não possui atributos suficientes para sua

identificação é necessário a utilização de atributos identificadores de
outras entidades relacionadas com esta para compor seu identificador.

Identificador de Relacionamento

Pode-se dizer que uma ocorrência de um relacionamento é implicitamente

identificada pelas ocorrências das entidades associadas por este. Assim,
o relacionamento Corrida é identificado implicitamente pelo piloto
e pelo circuito, como, por exemplo:<Felipe Massa, GP Brasil>, o que
significa afirmar que esta associação pode ocorrer uma única vez.

Entretanto, algumas vezes é necessário permitir a repetição das

ocorrências de um relacionamento. Nestes casos, deve ser escolhido um
atributo do próprio relacionamento para, juntamente com as ocorrências
das entidades, compor o identificador do relacionamento.

Por exemplo: se no relacionamento Corrida fosse necessário representar

dados históricos dos vários campeonatos de fórmula 1, poderíamos
optar por utilizar o ano da Corrida como parte do identificador do
relacionamento.

ano classificação

(0, n) (0, n)
Piloto Corrida CircuitoO
CIRCUIT

Desta forma, seriam possíveis ocorrências como:

<Felipe Massa, GP Brasil,2010> e

<Felipe Massa, GP Brasil,2011>.

Pegue as entidades que você escolheu na atividade 4 coloque

alguns atributos em cada uma das entidades.
32
EROS MOURA

1.3.4. Criando o modelo de dados conceitual

Como já foi visto, o início de um modelo conceitual começa com

entrevistas e análise do problema do cliente para levantamento dos
requisitos. Aqui, vamos simular o resultado desse levantamento,
descrevendo os requisitos.

“Deseja-se desenvolver um sistema para controlar os resultados de um

campeonato de futebol. O sistema deverá manter informações sobre
as equipes que participam do campeonato. De cada equipe, deseja-se
saber: código e nome. Além disso, é necessário controlar os jogadores
que pertencem a cada equipe. De cada jogador, deseja-se saber: código,
nome, data de nascimento, altura e peso. Ao longo do campeonato, um
jogador só pode pertencer a uma equipe. Uma equipe, por outro lado,
poderá ter vários jogadores, podendo não ter nenhum, em um dado
momento. É necessário ter um controle dos países dos jogadores, dos
quais se deseja armazenar as seguintes informações: uma sigla, o nome
do país e o nome do hino nacional. Um jogador sempre representa um
país, enquanto que um país pode ter vários jogadores participando do
campeonato, ou até mesmo nenhum. Uma equipe também representa
um país, enquanto que um país pode ter várias equipes participando do
campeonato, ou mesmo nenhuma. Para que cada jogo seja realizado, é
necessário saber a data em que ocorreu, o nome do estádio, a duração
total em minutos, a relação dos jogadores que participaram do jogo e a
posição que cada um obteve no campeonato. Para caracterizar um jogo
é necessário que haja pelo menos 1 jogador habilitado a participar.”

O primeiro passo para a construção de um modelo é identificar os

elementos no contexto para os quais temos o interesse de manter
informações a respeito, ou seja, identificar as possíveis entidades. Em
uma situação de levantamento de requisitos, provavelmente, a relação
de entidades poderá aumentar conforme sejam feitos os levantamentos.
Aqui, em que estamos simulando o resultado desse levantamento,
talvez seja necessário ler o texto mais de uma vez, até ter certeza de
que conseguiu identificar todas as entidades. Nesse exemplo, você
deverá relacionar as seguintes entidades: equipe, jogador, país e jogo. É
importante lembrar que só faz sentido definir alguma coisa como uma
entidade se ela possuir atributos próprios, caso contrário, provavelmente
se trata de um atributo.
 33
BANCO DE DADOS

Como resultado, teríamos o seguinte modelo conceitual:

data_jogo
JOGO nome_estadio
duração

código participa
nome
(1,n)
(1,1) (0,n) código
EQUIPE pertence nome
JOGADOR data_nasc

(0, n) altura
peso
(0, n)

é de é de

(1,1) (1,1)
PAÍS

nome_hino nacional

nome

sigla

Procure observar o modelo conceitual acima e responda a

perguntas como:

a) um jogador é de, no mínimo, __ e, no máximo, __ de quantos

países?
b) um jogador possui, no mínimo, __ e, no máximo, __ jogadores?
c)Qual o atributo identificador da entidade Jogo?_____________
d)Responda a estas perguntas para cada um dos relacionamentos
e atributos identificadores.

Baseado no texto abaixo, faça o modelo conceitual.
34
EROS MOURA

Você trabalha em uma empresa que faz serviços de manutenção em

informática. Foi solicitado a você a modelagem para um sistema
de controle dessas manutenções, desde o momento da abertura
do pedido (Ordem de Serviço) até o final do serviço. Foi feito um
levantamento e pediram a você o desenvolvimento do modelo
conceitual, incluindo a cardinalidade (mínima e máxima), além de
todos os outros elementos do modelo conceitual. O levantamento
contém as seguintes informações:
1. há um cadastro que contém todas as unidades federativas
do Brasil. Este cadastro contém a sigla da UF, que é como são
identificadas, e seu nome;
2. existe um cadastro de atendente, o qual contém todos os
atendentes na empresa. Ela possui a informação da matrícula do
atendente e o nome do mesmo. Neste cadastro há atendentes que
nunca abriram uma ordem de serviço;
3. há um cadastro de serviços que podem ser executados em uma
OS. Este cadastro contém as seguintes informações: código do
serviço, nome do serviço, estimativa de tempo que o serviço leva
para ser executado, valor de tabela do serviço (este valor pode ser
negociado com o cliente);
4. também existe um cadastro com os técnicos que podem
trabalhar em uma OS. Este cadastro contém as informações do
código do técnico, nome do técnico e a informação se ele é terceiro
(S) ou não (N) (neste cadastro há técnicos da empresa e técnicos
terceiros);
5. foi montado também um cadastro de algumas cidades, inclusive
aquelas em que não há nenhum cliente da empresa, mas não de
todas as cidades. Este cadastro possui as seguintes informações:
código da cidade, nome da cidade e a sigla da UF na qual a cidade
está situada;
6. do estoque, são guardadas as seguintes informações: código do
item do estoque, descrição do item do estoque, valor de compra
do item de estoque e a quantidade existente do item do estoque;
7. do cliente, são armazenadas as seguintes informações: código
do cliente, nome do cliente, rua, número, bairro, cidade, cep,
telefones do cliente, sexo do cliente;
8.para as Ordens de Serviços, as chamadas OS, são guardadas as
seguintes informações: número da OS, data de abertura da OS,
hora de abertura da OS, cliente da OS, atendente que abriu a OS,
descrição do problema da OS, descrição do fechamento da OS,
posição da OS que pode ser (A-aberta, F-Fechada e P-Pendente)
e valor total da OS.
 35
BANCO DE DADOS

9. para cada OS são armazenados os serviços executados. Para

cada serviço executado são armazenadas as seguintes informações:
número da OS, serviço executado, técnico responsável pelo
serviço, data inicial do serviço, hora inicial do serviço, data final
do serviço, hora final do serviço, valor cobrado pelo serviço (que
pode ser diferente do valor de tabela).
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
36
EROS MOURA
 MODELO LÓGICO DE DADOS
(MLD)

Olá, Turma!
Neste capítulo, daremos prosseguimento ao nosso trabalho de
modelar o negócio para o qual estaremos desenvolvendo um sistema.
Quando vamos trabalhar com o modelo lógico, já deveremos ter o
modelo conceitual finalizado. Estaremos, então, aplicando certas
restrições técnicas ao modelo conceitual para que seja possível
implementar este modelo em um tipo de SGBD escolhido. No final,
veremos o modelo físico e, nessa parte, iremos inserir características
de um específico SGBD.
Os objetivos deste capítulo são:
• entender o que é um projeto lógico;
• saber utilizar as regras de integridade;
• conhecer a primeira, segunda e terceira forma normal e
saber colocar o modelo na terceira forma normal;
• conhecer o modelo físico.

Muitos autores e profissionais da área, em suas abordagens sobre o

tema modelagem de dados, têm direcionado o processo de modelagem
diretamente para o nível lógico. Partem, desde o início de seu processo,
para a construção de um modelo fortemente dependente do ambiente
onde será implementado. Isso tem levado à obtenção de modelos
eficientes, mas bastante dependentes da tecnologia que os orientou
(relacional, redes, orientado a objetos).

Dentro da proposta apresentada nos itens anteriores, vimos que a

geração de um modelo lógico deveria ser antecedida pela obtenção de
um modelo conceitual. Esse modelo conceitual deveria ser independente
da tecnologia disponível, procurando aproximar-se o máximo possível
do mapeamento fiel do ambiente observado. No modelo conceitual,
você pode e deve representar o negócio sem limitações técnicas.

Existem várias notações para o modelo lógico. Em nossa disciplina,

vamos utilizar a notação de James Martin (Engenharia de Informações)
que foi criada em 1980 e é uma das mais utilizadas no mercado de
trabalho.
38
EROS MOURA

(0,n) (1,1)
Empregado Trabalha Departamento

EMPREGADO DEPARTAMENTO

= muitos
= um
= a ocorrência do relacionamento é opcional
= a ocorrência do relacionamento é obrigatória

Os relacionamentos já não são mais nomeados. Só será necessário

nomear um relacionamento quando houver mais de um relacionamento
entre duas tabelas.

Lógicos ou de implementação (nível intermediário) entre o Modelo

Conceitual e o Modelo Físico.

A grande vantagem dessa proposta é que, a partir do modelo conceitual

gerado, poderemos aplicar regras predefinidas em função da tecnologia
a ser empregada e, assim, obter os modelos necessários. Isso fará com
que, a partir de um mesmo modelo conceitual, possamos gerar modelos
lógicos para bancos de dados baseados na abordagem “relacional” ou
até mesmo em novas abordagens, tais como bancos de dados orientados
a objetos.

Assim, podemos definir que o processo de obtenção de um modelo

lógico a partir de um modelo conceitual segue os seguintes passos,
segundo Cougo (1997):

1. obter o modelo conceitual;

2 definir o tipo de implementação (relacional, O-O);
3. aplicar as regras de derivação específicas;
4. adaptar o modelo às necessidades.
 39
BANCO DE DADOS

Perceba que, dentre os passos a serem seguidos, existe, em último

lugar, uma atividade extremamente importante para a geração de
um modelo lógico aplicável efetivamente à solução de problemas
práticos do dia a dia.

Estaremos utilizando o programa DBDesigner para criar nossos

modelos lógicos. Há uma versão dele que pode ser encontrada aqui:
http://sourceforge.net/projects/dbdesigner-fork/files/dbdesigner-
fork/r1.5/DBDesignerFork-1.5-bin-i386-win32-beta5.zip/
download

2.1. Regras de Derivação

Como citamos anteriormente, a obtenção de um modelo lógico deveria

ser feita a partir de um modelo conceituai previamente gerado. Para
tanto, deveríamos dispor de uma série de regras de derivação que fossem
aplicadas sobre o modelo conceitual e que o transformassem em função
da topologia (tipo) de BD usada, em um modelo relacional, rede ou até
hierárquico.

Veremos, a partir deste instante, portanto, essas regras. Como nosso

objetivo, neste material, é explorar a derivação de modelos relacionais,
estaremos trabalhando com as regras para o modelo relacional segundo
Elmasri e Navathe (2011).

2.1.1. Etapa 1: Mapeamento de tipos de entidade regular

Para cada tipo de entidade regular (forte) “E” no modelo conceitual,

crie uma tabela “T” que inclua todos os atributos simples de “E”. Inclua
apenas os atributos de componente simples de um atributo composto.
Escolha um dos atributos-chave de “E” como chave primária para “T”.
Se a chave escolhida de “E” for composta, então o conjunto de atributos
simples que a compõem juntos formarão a chave primária de “T”.

Se várias chaves fossem identificadas para “E” durante o projeto

conceitual, a informação que descreve os atributos que formam cada
chave adicional é mantida a fim de especificar chaves secundárias
(únicas) da tabela “T”. O conhecimento sobre as chaves também é
mantido para fins de indexação e outros tipos de análises.

Em nosso exemplo, criamos as tabelas JOGO, EQUIPE, JOGADOR e

PAÍS. Os atributos de chave estrangeira e relacionamento se houver,
ainda não estão incluídos; eles serão acrescentados durante as etapas
40
EROS MOURA

seguintes. Em nosso exemplo, escolhemos data_jogo e nome_estadio

como chaves primárias para a tabela JOGO,; código, para chave primária
de EQUIPE; código, para chave primária de JOGADOR; sigla, para
chave primária de PAÍS.

2.1.2. Etapa 2: Mapeamento de tipos de entidade fraca

Para cada tipo de entidade fraca “F” no modelo conceitual: com tipo
de entidade proprietária forte “E”, crie uma tabela “T” e inclua todos os
atributos simples (ou componentes simples dos atributos compostos)
de “F” como atributos de “T”. Além disso, inclua como atributos
chave estrangeira de “T” os atributos de chave primária da tabela que
correspondem aos de entidade proprietária “E”. Isso consegue mapear
o tipo de relacionamento de identificação de “F”. A chave primária de
“T” é a combinação das chaves primárias do proprietário “E” e a chave
parcial do tipo de entidade fraca “F”, se houver.

Se houver um tipo de entidade fraca E2, cujo proprietário também

é um tipo de entidade, então Ej deve ser mapeado antes de E2
para determinar primeiro sua chave primária. Em outras palavras,
se houver uma entidade fraca (E2), ligada a outra entidade fraca
(E1), E1 deve ser criada antes de E2.

2.1.3. Etapa 3: Mapeamento dos tipos de relacionamento

binários 1:1

Para cada tipo de relacionamento binário 1:1 “R” no modelo conceitual,

identifique as tabelas “A” e “B” que correspondem aos tipos de entidades
participantes em “R”. Escolha entre as tabelas “A” e “B” e inclua a
chave estrangeira referenciando a outra. Por exemplo: coloco a chave
estrangeira em “A” referenciando “B”.

Complementando:

➢ já criamos duas tabelas (“A” e “B”), uma para cada conjunto de

entidades que participa do relacionamento;
➢ delas, incluir como chave estrangeira a chave primária da
outra;
➢ se o relacionamento for total em um dos dois conjuntos de
entidades, então é melhor incluir a chave estrangeira no “lado total”.
 41
BANCO DE DADOS

2.1.4. Etapa 4: Mapeamento de tipos de relacionam

binário 1:N

Para cada tipo de relacionamento “R” binário regular 1:N, identifique

a tabela “T” que representa o tipo de entidade participante no lado N
do tipo de relacionamento. Inclua como chave estrangeira em “T” a
chave primária da tabela “P” que representa o outro tipo de entidade
participante em “R”; fazemos isso porque cada instância de entidade
no lado N (tabela “T”) está relacionada, no máximo, a uma instância
de entidade do lado 1 (tabela “P”) do tipo de relacionamento. Inclua
quaisquer atributos simples (ou componentes simples dos atributos
compostos) do tipo de relacionamento 1:N como atributos de “P”.

Complementando:

➢ já temos duas tabelas (“T”,“P”), uma para cada conjunto de

entidades que participa do relacionamento;
➢ incluir como chave estrangeira, na tabela do “lado muitos” (o
“lado N”), a chave primária da tabela do “lado um”.

2.1.5. Etapa 5: Mapeamento de tipos de relacionamento

binário N:N

Para cada tipo de relacionamento “R” binário N:N, crie uma nova tabela
“S” para representar “R”. Inclua como atributos de chave estrangeira em
“S” as chaves primárias das tabelas que representam os tipos de entidade
participantes; sua combinação formará a chave primária de “S”. Inclua,
também, quaisquer atributos simples do tipo de relacionamento N:N
(ou componentes simples dos atributos compostos) como atributos de
“S”. Observe que não podemos representar um tipo de relacionamento
N:N por um único atributo de chave estrangeira em uma das tabelas
participantes (como fizemos para os tipos de relacionamento 1:1 ou
1:N) devido à razão de cardinalidade, por isso temos de criar uma tabela
de relacionamento “S” separada.

Complementando:

➢ já temos duas tabelas, uma para cada conjunto de entidades

que participa do relacionamento;
➢ criar uma nova tabela contendo, como chaves estrangeiras, as
chaves primárias dessas duas tabelas;
➢ a combinação dessas chaves estrangeiras forma a chave
primária da nova tabela;
➢ incluir também, se houver, colunas com os atributos do
relacionamento.
42
EROS MOURA

2.1.6. Etapa 6: Mapeamento de atributos multivalorados

Para cada atributo multivalorado “A” na tabela “S”, crie uma tabela “T”.
Essa tabela “T“ incluirá um atributo correspondente a “A”, mais o atributo
da chave primária da tabela “S”. A chave primária de “T” é a combinação
do atributo da chave primária da tabela “S” (esse atributo também será
chave estrangeira) e o atributo “A”. Se o atributo multivalorado for
composto, incluímos seus componentes simples.

Complementando:

Para cada atributo multivalorado, criar uma tabela contendo:

➢ como chave estrangeira, a chave primária da tabela que possuía

o atributo multivalorado mais o próprio atributo que era multivalorado;

➢ a nova chave primária também será uma chave estrangeira

para a tabela que possuía o atributo;

➢ a chave primária da nova tabela é a combinação da chave

estrangeira e do valor do atributo;

➢ se o atributo multivalorado for composto, incluímos seus

componentes simples.

2.1.7. Etapa 7: Mapeamento de

Autorrelacionamento 1:N

Para os autorrelacionamentos 1:N, como existe um relacionamento

entre a mesma entidade, deve-se criar a chave estrangeira na própria
tabela, no atributo que tem o relacionamento. Nesse caso, o atributo que
terá a chave estrangeira não terá o mesmo nome da chave primária, pois
não é possível repetir o nome do atributo.

matrícula
FUNCIONÁRIO nome_funcionário
matrícula_gerente
(1,n) (1,1)

é gerenciado por é gerente de

GERÊNCIA
 43
BANCO DE DADOS

Ao final, teremos a tabela assim:

FUNCIONARIO (matricula, nome_funcionario, matricula_gerente)

sendo que o atributo matricula_gerente terá uma chave estrangeira para
FUNCIONÁRIO.

2.1.8. Etapa 8: Autorrelacionamento N:N

Para os autorrelacionamentos N:N, faremos da mesma forma que um

relacionamento N:N tradicional, ou seja, criamos uma nova tabela para
o relacionamento. Esta nova tabela terá, ao menos, duas colunas as quais
serão, ao mesmo tempo, chave primária e chaves estrangeiras. Neste
caso, as duas chaves estrangeiras estarão se referenciando à mesma
tabela base.

cod_disciplina
DISCIPLINA nome_disciplina
carga_horária
(0,n) (0,n)

são pré-requisito para

DISCIPLINA (cod_disciplina, nome_disciplina, carga_horaria)

PRE_REQUISITO (cod_disciplina, cod_disciplina_pre)

cod_disciplina terá uma chave estrangeira apontando para

DISCIPLINA.
cod_disciplina_pre terá uma chave estrangeira apontando para
DISCIPLINA.

2.1.9. Etapa 9: Mapeamento de tipos de relacionamento

n-ário (qualquer relacionamento maior que o binário).

Para cada tipo de relacionamento n-ário R, onde n > 2, crie uma tabela T
para representar R. Inclua como atributos de chave estrangeira em T as
chaves primárias das tabelas que representam as entidade participantes.
44
EROS MOURA

Inclua, também, quaisquer atributos simples do tipo de relacionamento

n-ário (ou componentes simples de atributos compostos) como atributos
de T. A chave primária de T normalmente é uma combinação de todas
as chaves estrangeiras que referenciam as tabelas representando as
entidades participantes. Porém, se as restrições de cardinalidade sobre
qualquer um dos tipos de entidade E participantes em R for 1, então a
chave primária de T não deve incluir o atributo de chave estrangeira que
referencia a relação E’ correspondente a E.

Complementando:

➢ criar uma nova tabela contendo, como chaves estrangeiras, as

chaves primárias das tabelas que representam os conjuntos de entidades
participantes;

➢ normalmente, a combinação dessas chaves estrangeiras forma

a chave primária da nova tabela, mas se a cardinalidade máxima de
uma das entidades participantes for 1, então a chave estrangeira que
referencia essa entidade não fará parte da chave primária da nova tabela.

A tabela abaixo resume as correspondências entre as construções e

restrições do modelo conceitual para o modelo lógico.

MODELO CONCEITUAL MODELO LÓGICO

Tipo de entidade Tabela
Tipo de relacionamento 1:1 ou 1:N Chave estrangeira (ou tabela)
Tipo de relacionamento N:N Nova tabelae duaschaves estrangeiras
Tipo de relacionamento n-ário Nova tabela
Atributo simples Atributo
Atributo composto Conjunto de atributos componentes simples
Atributo multivalorado Tabela e chave estrangeira
Conjunto de valores Domínio
Atributo-chave Chave primária
 45
BANCO DE DADOS

2.1.10. Etapa 10: Mapeamento da especialização /

generalização

Tomemos como base este modelo conceitual.

código
CLIENTE
nome

PESSOA PESSOA
FÍSICA JURÍDICA

CPF CNPJ

Para os casos em que há generalização / especialização, há três opções

de projeto que podem ser adotadas:

• Opção 1: criar uma tabela para cada entidade (CLIENTE, FÍSICA,

JURÍDICA). Nesse caso, a chave primária das tabelas especializadas
(FÍSICA e JURÍDICA) é a mesma da entidade generalista (CLIENTE) e
também devem ser chaves estrangeiras para a tabela CLIENTE.

Ao final, teremos três tabelas, assim:

CLIENTE (cod_cliente, nome_cliente)

FISICA (cod_cliente, cpf, sexo)
JURIDICA(cod_cliente, cnpj, nome_fantasia)

OBS: aqui, a chave primária está sublinhada.

Lembre-se de que:
A coluna cod_cliente na tabela FISICA deverá ter chave estrangeira
para CLIENTE.
A coluna cod_cliente na tabela JURIDICA deverá ter chave
estrangeira para CLIENTE.

• Opção 2: criar uma tabela para cada entidade da especialização, como

FÍSICA e JURIDICA. Nesse caso, os atributos da entidade genérica (em
nosso exemplo CLIENTE) devem ser incluídos em ambas as tabelas
criadas.
46
EROS MOURA

Ao final, teremos duas tabelas, assim:

FISICA (cod_cliente, nome_cliente, cpf, sexo)

JURIDICA (cod_cliente, nome_cliente, CNPJ,nome_fantasia)

• Opção 3: criar uma única tabela, incluindo os atributos das 3 entidades.

Nesse caso, os campos que eram das entidades especializadas deverão
ser opcionais, ou seja, deverão aceitar valores nulos. Ao final, teremos a
única tabela, assim:

CLIENTE (cod_cliente, nome_cliente, cpf, sexo, cnpj, nome_fantasia)

Qual opção escolher?

Cada uma das opções apresentadas traz vantagens e desvantagens. A

terceira opção tem como vantagem a redução do número de junções
(veremos isso mais adiante) entre tabelas e como desvantagem possuir
atributos que só terão valores preenchidos quando for o caso dos dados
especializados. Por exemplo: quando for o caso de cadastrar uma pessoa
física, os campos CNPJ e nome fantasia não serão preenchidos. O mesmo
ocorrerá quando for o caso do cadastro da pessoa Jurídica; neste caso, os
atributos CPF e sexo não serão preenchidos. É por esse motivo que os
atributos que vieram das entidades especializadas devem aceitar nulo,
pois assim passam a ser opcionais. Para a segunda opção, temos como
desvantagem a repetição dos atributos que eram da entidade generalista.
Agora, estes atributos deverão existir nas duas tabelas. Na primeira
opção há uma organização maior, pois são preservadas as estruturas que
existiam no modelo conceitual. O problema dessa solução é a quantidade
de junções que aumentará em relação às outras duas soluções, o que pode
ser traduzido em problemas de performance. Deve-se, então, verificar se
esta tabela terá muito acesso, e se o acesso a este dado, um pouco mais
lento, poderá trazer problemas para a aplicação.

2.2. Normalização

Finalizado o esquema relacional, passa-se ao processo de normalização.

Este processo baseia-se no conceito de forma normal. Uma forma
normal é uma regra que deve ser obedecida por uma tabela para que esta
seja considerada “bem projetada”. Há diversas formas normais, isto é,
diversas regras, cada vez mais rígidas, para verificar tabelas relacionais.
Em nossa disciplina, vamos considerar três formas normais. As formas
normais são denominadas simplesmente primeira, segunda e terceira
forma normal, abreviadamente 1FN, 2FN e 3FN.
 47
BANCO DE DADOS

Embora a normalização seja um ingrediente muito importante do

projeto de bancos de dados, não se deve assumir que seu nível mais
alto seja sempre o mais desejável. Em geral, quanto mais alta a forma
normal, mais operações de junção são necessárias para produzir a saída
especificada e mais recursos são exigidos pelo sistema de banco de
dados para responder a consultas do usuário final. Um projeto bem-
sucedido deve considerar a demanda desse usuário por empenho rápido.
Portanto, em algumas ocasiões, será preciso desnormalizar certas partes
de um projeto do banco de dados, de modo a atender às exigências
de desempenho. A desnormalização produz uma forma normal mais
baixa; ou seja, por meio dela, 3NF pode ser convertido para 2NF. No
entanto, o preço a pagar pela melhora de desempenho decorrente da
desnormalização é a maior redundância de dados.

2.2.1. Primeira Forma Normal (1FN)

O primeiro passo da normalização consta da transformação do esquema

de tabela não normalizada em um esquema relacional na primeira forma
normal (1FN). Segundo Rob e Coronel (2011), uma tabela encontra-se
na 1FN quando:

➢ todos os atributos de chave estão definidos;

➢ não há grupos de repetição na tabela. Em outras palavras, cada

intersecção de linha/coluna contém um e somente um valor, não um
conjunto de valores;

➢ todos os atributos são dependentes da chave primária.

V
CÓDIGO NOME GERENTE DEP. LOCALIZAÇÕES DO DEPARTAMENTO

5 Pesquisa 1 Cachoeiro, Castelo, Muqui

4 Adm 2 Marataízes, Guarapari

eja um exemplo de quando uma tabela não está na 1FN:
1 Sede 3 Iconha

2.2.2. Segunda Forma Normal (2FN)

Segundo Rob e Coronel (2011), uma tabela encontra-se na 2FN quando:

➢ está em 1NF. e

➢ não inclui dependências parciais; ou seja, nenhum atributo é

dependente apenas de uma parte da chave primária.
48
EROS MOURA

Se a 2FN trata das dependências parciais de uma chave primária,

se a chave primária for simples (formada apenas por um atributo)
ela já estará na 2FN.

Observe que ainda é possível uma tabela em 2NF apresentar

dependência transitiva, ou seja, um ou mais atributos podem
ser funcionalmente dependentes de atributos não relacionados à
chave.

Veja um exemplo de quando uma tabela não está na 2FN:

*A *B C D

Ddepende só de A e não da chave inteira (A,B)

2.2.3. Terceira Forma Normal (3FN)

Segundo (Rob e Coronel, 2011), uma tabela encontra-se na 3FN quando:

➢ está em 2NF. e

➢ não contém dependências transitivas.

*A B C

C depende de B que não é chave

Coloque as estruturas abaixo na 3FN.

a) Contrato( num_contrato, cod_cliente, dta_inicio_contrato,
dta_termino_contrato, num_prestacao, val_prestacao, dta_venc_
prestacao )
b) PecaEstocada(cod_peca, cod_armazem, qtd_estocada,
tel_armazem)
 49
BANCO DE DADOS

c) Horario_Voo(sigla_cia, num_voo, hor_voo, sigla_aeroporto,

nom_aeroporto, cidade_aeroporto, status_voo).
OBS: a chave primária está em negrito e sublinhado.

2.2.4. Exemplo de Modelo Lógico

Veja aqui exemplo de um modelo lógico de uma transportadora.

TIPO CLIENTE
cod_tipo_cliente: INTEGER
descricao_tipo_cliente: VARCHAR(20)
UF CIDADE
sigla_uf: CHAR(2) sigla_uf: CHAR(2)
nome_uf: VARCHAR(25) nome_cidade: VARCHAR(40)
sigla_uf: CHAR(2) (FK)

CLIENTE
CTRC
cod_cliente: INTEGER
ITENS_MANIFESTO num_ctrc: CHAR (6)
nome_cliente: VARCHAR(40)
num_manifesto: CHAR (6) (FK) cliente_remetente: INTEGER (FK)
Remetente rua_cliente: VARCHAR(40)
num_ctrc: CHAR(6) (FK) cliente_destinatario: INTEGER (FK)
bairro_cliente: VARCHAR(40)
posicao_ctrc: INTEGER bairro_cliente: VARCHAR(40)
cidade_cliente: INTEGER (FK)
data_emissão: CHAR (10) Destinatário
cep_cliente: VARCHAR(8)
peso_ctrc: NUMERIC (8,2)
documento_cliente: VARCHAR (20)
frete_ctrc: NUMERIC (10,2)
cod_tipo_cliente: INTEGER (FK)

MANIFESTO CTRC_NF CLIENTE_TELEFONE

num_manifesto: CHAR (6) num_ctrc: CHAR(6) (FK) cod_cliente: INTEGER (FK)
filial_origem_manifesto: CHAR(3) (FK) num_nf: CHAR(6) telefone_cliente: CHAR(10)
filial_destino_manifesto: CHAR (3) (FK)
placa_veiculo_manifesto: CHAR (7) (FK) MANIFESTO_MOTORISTA MOTORISTA
data_emissao_manifesto: CHAR (10) num_manifesto: CHAR (7) cod_motorista: INTEGER
data_chegada_manifesto: CHAR (10) cod_motorista: INTEGER (FK) nome_motorista: VARCHAR(40)
cod_ajudante: INTEGER (FK) sexo_motorista: CHAR(1)

VEICULO
Origem Destino
placa_veiculo: CHAR (7)
descricao_veiculo: VARCHAR (FK)

UF AJUDANTE
sigla_uf: CHAR(2) cod_ajudante: INTEGER (7)
nome_uf: VARCHAR(25) nome_ajudante: VARCHAR (35)

Baseado no modelo lógico acima, responda às seguintes perguntas.

a) um manifesto pode ter, no mínimo, ___ itens de manifesto e,
no máximo, ___ itens de manifesto;
b) um item de manifesto pode ter, no mínimo, ___ manifesto(s) e,
no máximo, ___ manifesto(s).
c) um manifesto pode ter, no mínimo, ___ ajudante(s) e, no
máximo, ___ ajudante(s).
50
EROS MOURA

d) qual é a chave primária da tabela itens __ manifesto?

________________
e) responda a estas perguntas para todos os relacionamentos e
chaves primárias do modelo.

2.3. Modelo Físico de Dados (MFD)

Define-se como modelo físico de dados (também chamado de modelo

interno) aquele em que a representação dos objetos é feita sob o foco
do nível físico de implementação das entidades e seus relacionamentos.
O conhecimento do modo físico de implementação das estruturas de
dados é ponto básico para o domínio desse tipo de modelo.

Cada diferente SGBD poderá definir um diferente modo de

implementação física das características e recursos necessários para o
armazenamento e manipulação das estruturas de dados. Utilizar estas
características de modo correto pode significar uma ótima performance,
enquanto a não utilização das mesmas pode significar um grande
problema.

Na prática, para se desenvolver um bom modelo físico é necessário um

bom conhecimento do SGBD com que você vai trabalhar (aqui, estou
me referindo a um específico SGBD, por exemplo, PostGreSQL). Neste
momento, você não tem conhecimento necessário para decidir se no
SGBD Oracle é melhor trabalhar com a tabela Cliente particionada em
vários discos rígidos diferentes ou não. Ou, se para o campo sexo da
tabela Cliente, que receberá consultas, seria melhor criar um índice
BTree ou Bitmap.

Cougo (1997) diz que, em alguns casos, um mesmo SGBD em diferentes

ambientes de sistema operacional poderá ter diferentes métodos de
armazenamento e manuseio de suas estruturas de dados. Isso é fácil de ser
constatado quando analisamos um SGBD que tenha sua implementação,
por exemplo, em ambiente Windows(DOS), Linux(UNIX) e VMS.
Em cada um desses ambientes, existirão diferentes estruturas de
armazenamento, endereçamento, acesso e alocação física. Isso significa
que, em alguns casos, um mesmo modelo lógico poderá estar mapeado
de diferentes modos em cada um dos sistemas operacionais.
 51
BANCO DE DADOS

Baseado no modelo conceitual abaixo, crie o modelo lógico.

cod_cidade
(0, n) (1,1) sigla_uf
nome_cidade CIDADE Está localizada UF nome_uf
sigla_uf
(1,1)

Mora

(1,n)
cod_cliente
bairro
nome_cliente cod_cidade cod_técnico
rua CLIENTE cep TÉCNICO nome_técnico
telefones )(0,n
numero sexo (M,F
) terceitos) (S,N

(1,1) (1,1)

pede faz

(1,n) (1,n)
número_oe número_os
data_os cod_serviço
hora_os cod_técnico
cod_cliente Ordem data_inicial_serviço
(1,1) (1,n)
matrícula_atendente de Possui Serviço Executado hora_inicial_serviço
descrição_problema Serviço data_final_serviço
descrição_fechamento hora_final_serviço
posição_os (A,F, P) valor_cobrado_serviço
valor_total_os
(0,n) (0,n) (0,n)

Cadastra data_uso
usa é feito
hora_uso

quantidade_uso

(1,1)
cod_serviço
matrícula_atendente
ATENDENTE ESTOQUE SERVIÇO
nome_serviço
nome_atendente estimativa_tempo
valor_serviço
(1,1)
quantidade_estoque
valor_compra
desc_estoque
cod_estoque
52
EROS MOURA
 INTRODUÇÃO A BANCO DE
DADOS

Vamos lá!
Agora vamos conhecer a teoria sobre banco de dados, assim
podermos usá-lo de uma forma melhor.
Os objetivos deste capítulo são:
• conhecer os conceitos básicos de banco de dados;
• conhecer um SGBD;
• conhecer os principais componentes de um SGBD;
• saber definir as principais vantagens e desvantagens do
SGBD;
• compreender a tecnologia Cliente/Servidor aplicada a
Banco de Dados.

3.1. Conceitos Básicos de Banco de

Dados

Para Elmasri e Navathe (2011), bancos de dados e sistemas de banco de

dados são componentes essenciais da vida na sociedade moderna, e a
maioria de nós encontra diariamente diversas atividades que envolvem
alguma interação com um banco de dados. Por exemplo: quando vamos
ao banco para depositar ou retirar fundos, fazemos uma reserva de
hotel ou de voo, acessamos o catálogo de uma biblioteca virtual para
procurar uma referência bibliográfica, ou compramos algo on-line
(como um livro, um brinquedo ou um computador), provavelmente
essas atividades envolverão alguém ou algum programa de computador
que acessa um banco de dados. Até mesmo a compra de produtos em
um supermercado atualiza automaticamente o banco de dados que
mantém o controle de estoque dos itens.

Essas interações são exemplos do que podemos chamar de aplicações

de banco de dados tradicionais, em que a maior parte da informação
armazenada e acessada é textual ou numérica. Nos últimos anos, os
avanços na tecnologia levaram a interessantes novas aplicações dos
sistemas de banco de dados. A nova tecnologia de mídia tornou possível
armazenar imagens, clipes de áudio e streams de vídeo digitalmente.
54
EROS MOURA

Esses tipos de arquivo estão se tornando um componente importante dos

bancos de dados de multimídia. Os sistemas de informações geográficas
(GIS — Geographic Information Systems) podem armazenar e analisar
mapas, dados sobre o clima e imagens de satélite. Sistemas de data
warehousing e de processamento analítico on-line (OLAP — On-Line
Analytical Processing) são usados em muitas empresas para extrair
e analisar informações comerciais úteis de bancos de dados muito
grandes, para ajudar na tomada de decisão. A tecnologia de tempo real
e o banco de dados ativo são usados para controlar processos industriais
e de manufatura. Além disso, técnicas de pesquisa de banco de dados
estão sendo aplicadas à World Wide Web para melhorar a busca por
informações necessárias feita pelos usuários que utilizam a Internet.

Os bancos de dados e sua tecnologia têm um impacto importante sobre

o uso crescente dos computadores. E correto afirmar que os bancos de
dados desempenham um papel crítico em quase todas as áreas em que
os computadores são usados, incluindo negócios, comércio eletrônico,
engenharia, medicina, genética, direito, educação e biblioteconomia.
O termo banco de dados (do original database) é tão utilizado que
precisamos começar por sua definição. Um banco de dados é uma
coleção de dados relacionados. Com dados, queremos dizer fatos
conhecidos que podem ser registrados e possuem significado implícito.
Por exemplo, considere os nomes, números de telefone e endereços das
pessoas que você conhece. Você pode ter registrado esses dados em uma
agenda ou, talvez, os tenha armazenado em um disco rígido, usando
um computador pessoal e um software como BROffice Calc(planilha
eletrônica). Essa coleção de dados relacionados, com um significado
implícito, é um banco de dados.

Essa definição de banco de dados é bastante genérica; por exemplo,

a coleção de palavras que compõem esta página de texto pode ser
considerada dados relacionados e, portanto, constitui um banco de
dados. Porém, o uso comum do termo banco de dados normalmente é
mais restrito e tem as seguintes propriedades implícitas:

• um banco de dados representa algum aspecto do mundo real, às

vezes chamado de minimundo ou de universo de discurso (UoD —
Universe of Discourse). As mudanças no minimundo são refletidas
no banco de dados;
• um banco de dados é uma coleção logicamente coerente de dados
com algum significado inerente. Uma variedade aleatória de dados
não pode ser corretamente chamada de banco de dados;
• um banco de dados é projetado, construído e populado com dados
para uma finalidade específica. Ele possui um grupo definido de
 55
BANCO DE DADOS

usuários e algumas aplicações previamente concebidas nas quais

esses usuários estão interessados.

Em outras palavras, um banco de dados tem alguma fonte da qual o dado

é derivado, algum grau de interação com eventos no mundo real e um
público que está ativamente interessado em seu conteúdo. Os usuários
finais de um banco de dados podem realizar transações comerciais (por
exemplo, um cliente compra uma câmera) ou eventos podem acontecer
(por exemplo, uma funcionária tem um filho), fazendo com que a
informação no banco de dados mude.

Para que um banco de dados seja preciso e confiável o tempo todo,

ele precisa ser um reflexo verdadeiro do minimundo que representa;
portanto, as mudanças precisam ser refletidas no banco de dados o mais
breve possível.

Um banco de dados pode ter qualquer tamanho e complexidade. Por

exemplo, a lista de nomes e endereços referenciados anteriormente
pode consistir em apenas algumas centenas de registros, cada um com
uma estrutura simples. Por sua vez, o catálogo computadorizado de uma
grande biblioteca pode conter meio milhão de entradas organizadas
sob diferentes categorias (por sobrenome do autor principal, por
assunto, por título do livro), com cada uma das categorias organizada
alfabeticamente. Um banco de dados de tamanho e complexidade ainda
maior é mantido pela Receita Federal para monitorar formulários de
imposto de renda preenchidos pelos contribuintes. Se a Receita Federal
mantém o registro dos três últimos anos de cada contribuinte, além do
ano atual, teríamos um banco de dados de mais ou menos 800 gigabytes.
Essa imensa quantidade de informações precisa ser organizada e
gerenciada de modo que os usuários possam consultar, recuperar e
atualizar os dados quando necessário.

Um exemplo de um grande banco de dados comercial é a Amazon.com.

Ela contém dados de mais de 20 milhões de livros, CDs, vídeos, DVDs,
jogos, eletrônicos, roupas e outros itens. O banco de dados ocupa
mais de dois terabytes (um terabyte é 1012 bytes de armazenamento)
e está armazenado em 200 computadores diferentes (denominados
servidores). Cerca de 15 milhões de visitantes acessam a Amazon.com
todos os dias e utilizam o banco de dados para fazer compras. O banco
de dados é continuamente atualizado à medida que novos livros e outros
itens são acrescentados ao estoque e as quantidades em estoque são
atualizadas à medida que as compras são feitas. Cerca de cem pessoas
são responsáveis por manter o banco de dados da Amazon atualizado.
56
EROS MOURA

Um banco de dados pode ser gerado e mantido manualmente, ou pode

ser computadorizado. Por exemplo, um catálogo de cartão de biblioteca
é um banco de dados que pode ser criado e mantido manualmente. Um
banco de dados computadorizado pode ser criado e mantido por um
grupo de programas de aplicação escritos especificamente para essa
tarefa ou por um sistema gerenciador de banco de dados. Vamos tratar
apenas dos bancos de dados computadorizados nesta disciplina.

3.2. Sistema Gerenciador de Banco de

Dados

Segundo Elmasri e Navathe (2011) “Um sistema gerenciador de banco

de dados (SGBD — Database Management System) é uma coleção de
programas que permite aos usuários criar e manter um banco de dados”.
O SGBD é um sistema de software de uso geral que facilita o processo
de definição, construção, manipulação e compartilhamento de bancos
de dados entre diversos usuários e aplicações. Definir um banco de
dados envolve especificar os tipos, estruturas e restrições dos dados a
serem armazenados. A definição ou informação descritiva do banco de
dados também é armazenada pelo SGBD na forma de um catálogo ou
dicionário, chamado de metadados.

A construção do banco de dados é o processo de armazenar os dados

em algum meio controlado pelo SGBD. A manipulação de um banco
de dados inclui funções como consulta ao banco de dados para
recuperar dados específicos, atualização do banco de dados para refletir
mudanças no minimundo e geração de relatórios com base nos dados.
O compartilhamento de um banco de dados permite que diversos
usuários e programas acessem-no simultaneamente. Um programa de
aplicação acessa o banco de dados ao enviar consultas ou solicitações de
dados ao SGBD. Uma consulta normalmente resulta na recuperação de
alguns dados; uma transação pode fazer que alguns dados sejam lidos e,
outros, gravados no banco de dados.
 57
BANCO DE DADOS

3.3. Estrutura geral do SGBD -

principais componentes

Vamos examinar agora as funções do SGBD. Segundo Date (2003), as

funções incluirão o suporte a todos os itens a seguir:

Solicitações de Solicitações de
Fonte de esquemas DML não-planejadas
e mapeamento DML planejadas
(ocasionais)

Processadores
Processadores Processadores
da linguagem
de DDL de DDL
de consulta

Solicitações
compiladas

Fonte e objeto
de esquemas Otimizador
e mapeamento

Solicitações
otimizadas

Gerenciador
em tempo Metadados
de execução

Banco
de dados

Dados

Metadados
(dicionários de dados)

Figura 2 Funções do SGBD

Fonte:Date, 2003

3.3.1. Definição de dados

O SGBD deve ser capaz de aceitar definições de dados (esquemas externos,

o esquema conceitual, o esquema interno e todos os mapeamentos
associados) em formato fonte e convertê-los para o formato objeto
58
EROS MOURA

apropriado. Em outras palavras, o SGBD deve incluir componentes

de processador de DDL(DDL - Data Definition Languages). O SGBD
também deverá “entender” as definições da DDL, no sentido de que,
por exemplo, ele “entende” que os registros externos EMPREGADO
incluem um campo SALÁRIO; ele deve, então, ser capaz de usar esse
conhecimento para analisar e responder a pedidos de manipulação de
dados (por exemplo, “obtenha todos os empregados com salário < R$
1.000,00”).

3.3.2. Manipulação de dados

O SGBD deve ser capaz de lidar com requisições do usuário para

buscar, atualizar ou excluir dados existentes no banco de dados, ou
para acrescentar novos dados ao banco de dados. Em outras palavras, o
SGBD deve incluir um componente processador de DML ou compilador
de DML para lidar com a linguagem de manipulação de dados (DML -
Data Manipulation Language).

Em geral, as requisições de DML podem ser “planejadas” ou

“não-planejadas”:

• a) uma requisição planejada é aquela para a qual a necessidade foi

prevista com bastante antecedência em relação ao momento em
que a requisição é executada. O DBA provavelmente terá ajustado
o projeto de banco de dados físico de modo a garantir um bom
desempenho para requisições planejadas. As requisições planejadas
em geral serão emitidas a partir de programas de aplicação;

• b) ao contrário, uma requisição não planejada é uma consulta “ad

hoc”, isto é, uma requisição cuja necessidade não foi prevista com
antecedência mas, em vez disso, surgiu na última hora. O projeto
físico do banco de dados pode estar ou não adaptado de forma ideal
para a requisição específica sendo considerada. Emitidas de modo
interativo por meio de algum processador de linguagem de consulta.

3.3.3. Otimização e execução

As requisições de DML, planejadas ou não planejadas, devem ser

processadas pelo componente otimizador, cuja finalidade é determinar
um modo eficiente de implementar a requisição. As requisições
otimizadas são, então, executadas sob o controle do gerenciador em
tempo de execução (run time). Nota: na prática, o gerenciador em
tempo de execução provavelmente invocará algum tipo de gerenciador
de arquivos para obter acesso aos dados armazenados.
 59
BANCO DE DADOS

3.3.4. Segurança e integridade de dados

O SGBD, ou algum subsistema chamado pelo SGBD, deve monitorar

requisições de usuários e rejeitar toda tentativa de violar as restrições
de segurança e integridade definidas pelo DBA. Essas tarefas podem
ser executadas em tempo de compilação ou em tempo de execução, ou,
ainda, em alguma combinação dos dois.

3.3.5. Recuperação de dados e concorrência

O SGBD - ou, mais provavelmente, algum outro componente de

software relacionado, em geral chamado gerenciador de transações ou
monitor de TP (transaction processing) - deve impor certos controles
de recuperação e concorrência. O gerenciador de transações não é
mostrado na Figura 2 porque, em geral, ele não faz parte do SGBD
propriamente dito. Ele é responsável por disponibilizar meios para que
seja possível fazer backup, e também deve fornecer meios para gerenciar
situações de conflitos entre transações.

3.3.6. Dicionário de dados

O SGBD deve fornecer uma função de dicionário de dados. O dicionário

de dados pode ser considerado um banco de dados isolado (mas um
banco de dados do sistema, não um banco de dados do usuário); ele
contém “dados sobre os dados” (também chamados metadados ou
descritores), ou seja, definições de outros objetos do sistema, em vez
de somente “dados crus”. Em particular, todos os vários esquemas e
mapeamentos (externos, conceituais, etc.) e todas as diversas restrições
de segurança e integridade estarão armazenados, tanto na forma de
fonte quanto de objeto, no dicionário. Um dicionário completo também
incluirá muitas informações adicionais mostrando, por exemplo, os
programas que utilizam determinadas partes do banco de dados, os
usuários que exigem certos relatórios, e assim por diante. O dicionário
poderia até estar (na verdade, provavelmente deve estar) integrado ao
banco de dados que ele define e, portanto, incluir sua própria definição.
Por certo, deve ser possível consultar o dicionário como em qualquer
outro banco de dados, para que, por exemplo, seja possível saber que
programas e/ou usuários terão maior probabilidade de serem afetados
por alguma alteração proposta no sistema.

3.3.7. Desempenho

É desnecessário dizer que o SGBD deve realizar todas as funções

identificadas anteriormente de forma tão eficiente quanto possível.
60
EROS MOURA

3.4. Banco de dados Cliente/Servidor

O objetivo geral desses sistemas é fornecer suporte ao desenvolvimento

e à execução de aplicações de bancos de dados. Portanto, sob um ponto
de vista de mais alto nível, um sistema desse tipo pode ser considerado
como tendo uma estrutura muito simples em duas partes, consistindo
em um servidor, também chamado back end, e um conjunto de clientes,
também chamados front ends (consulte a Figura 3). Explicação:

Usuários finais

APLICAÇÕES Clientes

SGBD Servidor

Banco de dados

Figura 3 Cliente / Servidor

Fonte: Date, 2003

O servidor é o próprio SGBD. Ele admite todas as funções básicas de

SGBDs discutidas na Seção3.3 (definição de dados, manipulação de
dados, segurança e integridade de dados, e assim por diante). Em outras
palavras, o termo “servidor” neste contexto é apenas um outro nome
para o SGBD.

Os clientes são as diversas aplicações executadas em cima do SGBD

- tanto aplicações escritas por usuários quanto aplicações internas
(built-in, ou seja, aplicações fornecidas pelo fabricante do SGBD ou por
terceiros).

É importante destacar que neste tipo de sistema (para alguns autores,

plataforma), a comunicação se dá através de solicitação e reposta. Por
exemplo, uma aplicação (cliente) solicita todos os clientes cadastrados,
o SGBD (servidor) responde com todos os clientes.
 61
BANCO DE DADOS

Uma outra coisa que deve ficar claro: o servidor e cliente apresentado
a Figura 3 não é necessariamente física, ou seja, não obrigatoriamente
está se falando em um computador servidor e outro computador cliente
(embora em empresas médias e grandes seja assim mesmo). Em alguns
casos (aplicativos menores) estes dois, cliente e servidor, podem estar na
mesma máquina. Mesmo neste caso, tudo o que foi falado está valendo.

3.5. Vantagens do uso de SGBD

Rob e Coronel (2011) descrevem as seguintes vantagens do SGBD:

3.5.1. Aprimoramento do compartilhamento de dados

O SGBD ajuda a criar um ambiente em que os usuários finais tenham

melhor acesso a dados em maior quantidade e mais bem gerenciados.
Esse acesso possibilita que os usuários finais respondam rapidamente a
mudanças em seu meio.

3.5.2. Aprimoramento da segurança de dados

Quanto mais usuários acessam os dados, maiores são os riscos de falhas

de segurança. As empresas investem consideráveis quantidades de
tempo, esforços e dinheiro para garantir que seus dados sejam utilizados
adequadamente, e o SGBD fornece um modelo para melhor aplicar as
políticas de privacidade e segurança de dados.

3.5.3. Melhoria na integração dos dados

O acesso mais amplo a dados bem gerenciados promove uma perspectiva

integrada das operações da organização e uma visualização mais clara
do panorama geral, o que facilita muito a visualização de como as ações
de um segmento da empresa afetam outros segmentos.

3.5.4. Minimização da inconsistência dos dados

A inconsistência dos dados ocorre quando diferentes versões dos

mesmos dados aparecem em locais diferentes. Por exemplo, quando
o departamento de vendas de uma empresa armazena o nome de
uma representante de vendas como “Cris Silva” e o departamento de
recursos humanos armazena o nome da mesma pessoa como “Cristina
G. da Silva”. Ou, no caso do escritório regional de vendas divulgar um
produto com preço de R$ 45,95 e o escritório nacional apresentar o
mesmo produto por R$ 43,95. Esse problema é reduzido por meio de
um adequado projeto de banco de dados.
62
EROS MOURA

3.5.5. Aprimoramento do acesso aos dados

O SGBD torna possível obter respostas rápidas a consultas “ad hoc”.

Da perspectiva do banco de dados, uma consulta é uma solicitação
específica de manipulação de dados, emitida ao SGBD - por exemplo,
ler ou atualizar os dados. Colocando de modo simples, uma consulta é
uma pergunta, e uma consulta ad hoc é uma consulta eventual. O SGBD
retorna uma resposta (chamada conjunto de resultados de consulta)
à aplicação. Por exemplo, os usuários finais, ao lidarem com grandes
quantidades de dados de vendas, podem querer respostas rápidas a
perguntas (consultas ad hoc) como:

➢ Qual é o volume em valor de vendas por produto durante os

últimos seis meses?

➢ Qual é o número de bônus de vendas de cada um de nossos

vendedores durante os últimos três meses?

➢ Quantos de nossos clientes têm saldo de crédito maior ou igual

a R$ 3.000,00?

3.5.6. Aprimoramento da tomada de decisão

Dados mais bem gerenciados e com acesso aprimorado tornam possível

gerar informações de melhor qualidade sobre as quais se podem basear
melhores decisões.

3.5.7. Aumento de produtividade do usuário final

As disponibilidades de dados combinadas com as ferramentas que

os transformam em informações úteis capacitam os usuários finais a
tomarem decisões mais rápidas e confiáveis que podem fazer a diferença
entre o sucesso e o fracasso na economia global.

3.5.8. Outras vantagens

As vantagens da utilização de um SGBD não se limitam aos poucos

itens aqui listados. Na verdade, você descobrirá muito mais vantagens
ao conhecer os detalhes técnicos dos bancos de dados e seu projeto
adequado.
 63
BANCO DE DADOS

3.6. Desvantagens do uso de SGBD

Segundo Rob e Coronel (2011), embora o sistema de banco de

dados apresente vantagens consideráveis em relação a abordagens de
gerenciamento anteriores, também trazem desvantagens significativas.
Por exemplo:

3.6.1. Aumento de custos

Os sistemas de banco de dados exigem hardware/software sofisticados e

pessoal altamente treinado. O custo de manutenção do hardware, software
e pessoal necessário para operar e gerenciar um sistema de banco de
dados pode ser substancial. Os custos de treinamento, licenciamento e
atendimento às regulamentações costumam ser negligenciados quando
da implementação desses sistemas.

3.6.2. Complexidade de gerenciamento

Os sistemas de banco de dados apresentam interfaces com muitas

tecnologias diferentes e têm um impacto significativo sobre os recursos
e a cultura de uma empresa. As alterações introduzidas pela adoção do
sistema de banco de dados devem ser adequadamente gerenciadas para
garantir que ajudem no progresso dos objetivos da empresa. Levando
em conta o fato de que os bancos de dados mantêm dados fundamentais
da empresa que são acessados a partir de várias fontes, as questões de
segurança devem ser uma constante preocupação.

3.6.3. Manutenção do banco de dados atualizado

Para maximizar a eficiência do sistema de banco de dados, deve-se

manter o sistema atualizado. Portanto, é necessário fazer atualizações
frequentes e aplicar os últimos pacotes e medidas de segurança a todos
os componentes. Como a tecnologia dos bancos de dados avança
rapidamente, os custos com treinamento de pessoal tendem a ser
significativos.

3.6.4. Dependência do fornecedor

Em virtude do alto investimento em tecnologia e treinamento de pessoal,

as empresas podem hesitar em trocar os fornecedores de bancos de
dados. Por essa razão, é menos provável que estes ofereçam vantagens de
preço aos clientes existentes, que ficarão restritos quanto a suas escolhas
de componentes de sistemas de banco de dados.
64
EROS MOURA

3.6.5. Ciclos frequentes de atualização/substituição

Os fornecedores de SGBDs atualizam seus produtos adicionando

novas funcionalidades. Em geral, esses recursos são integrados a novas
versões de atualização do software. Algumas dessas versões exigem
atualizações de hardware. Mas não são apenas as atualizações que geram
custo, também o treinamento dos usuários e administradores para que
utilizem e gerenciem adequadamente os novos recursos.

3.7. SGBD gratuitos

Em geral, os SGBD gratuitos são uma boa opção para projetos pequenos
e médios. Algumas das desvantagens comentadas no item anterior não
fariam sentido para SGBD gratuitos, mas outras deveriam ser levadas
em conta como, por exemplo, o suporte, a possibilidade de continuidade
do projeto, a possibilidade do projeto passar a ser pago, etc.

Respondas às perguntas abaixo:

1. Dê exemplos de onde você pode observar, no seu dia a dia,
bancos de dados.
2. Posso ter um SGBD de um BD ou um BD sem um SGBD?
Explique.
3. Cite 3 vantagens no uso de SGBD.
4. Cite 3 desvantagens no uso do SGBD.
5. Defina banco de dados.
6. Defina Sistema Gerenciador de Banco de Dados.
7. Pesquise alguns SGBD que existem no mercado.
 A LINGUAGEM SQL – DDL E
PERMISSÕES

Oi, pessoal!
Neste capítulo, começaremos a conhecer a linguagem que vai
possibilitar o uso do banco de dados. Será através dela faremos tudo
com o banco de dados.
Os objetivos deste capítulo são:
• conhecer o que é SQL;
• compreender o que é DDL;
• conhecer os principais comandos DDL;
• compreender quais são os tipos de dados mais utilizados;
• entender a utilização das restrições de integridade;
• compreender o que é índice e quando utilizá-lo;
• entender como se cria usuários;
• saber utilizar os comandos Grant e Remove.

Para Elmasri e Navathe (2011), a linguagem SQL pode ser considerada

um dos principais motivos para o sucesso dos bancos de dados
relacionais comerciais. Isso aconteceu porque, mesmo que os usuários
estivessem insatisfeitos com o produto de SGBD relacional em particular
que estavam usando, conversão para outro produto de SGBD relacional
não seria tão cara ou demorada, pois os dois sistemas seguiam os
mesmos padrões de linguagem. Na prática é óbvio, pois existem muitas
diferenças entre diversos de SGBD relacionais comerciais. Porém, se
o usuário for cuidadoso em usar apenas dos recursos que fazem parte
do padrão, e se os dois sistemas relacionais admitirem fielmente o
padrão, então, a conversão de ambos deverá ser bastante simplificada.
Outra vantagem de ter esse padrão é que os usuários podem escrever
comandos em um programa de aplicação de banco de dados que pode
acessar dados armazenados em dois ou mais SGBDs relacionais sem ter
de mudar a sublinguagem de banco de dados (SQL). Embora isto seja
verdade, haverá uma questão a ser resolvida: se o analista quiser ter um
sistema que possa funcionar em mais de um SGBD, ele estará limitado
ao padrão e isto pode ser bastante custoso, pois você estaria abrindo
mão de extensões específicas de um SGBD em particular, que facilitam,
e muito, a vida destes analistas, para que seu sistema possa funcionar
com outros SGBD. Na prática do mercado não é isto que é visto. Há
66
EROS MOURA

sistema que funciona com o SGBD X , ou há uma versão do sistema para

o SGBD X e outra versão para o SGBD Y. Em nossa disciplina, estarei
usando, sempre que possível, este padrão. Haverá situações em que terei
que ser específico, e neste ponto estarei utilizando o SGBD PostgreSQL.

O nome SQL hoje é expandido como Structured Query Language

(Linguagem de Consulta Estruturada). Originalmente, SQL era
chamada de SEQUEL (Structured English QUEry Language) e foi criada
e implementada na IBM Research como a interface para um sistema de
banco de dados relacional experimental, chamado SYSTEM R. A SQL
agora é a linguagem padrão para SGBDs relacionais comerciais. Um
esforço conjunto entre o American National Standards Institute (ANSI)
e a International Standards Organization (ISO) em 1986 levou a uma
versão-padrão da SQL (ANSI, 1986), chamada SQL-86 ou SQL1. Um
padrão revisado e bastante expandido, denominado SQL-92 (também
conhecido como SQL2) foi desenvolvido mais tarde, em 1992. O
próximo padrão reconhecido foi SQL:1999, que começou como SQL3.
Duas atualizações posteriores ao padrão são SQL:2003 e SQL:2006,
que acrescentaram recursos de XML entre outras atualizações para a
linguagem. Outra atualização em 2008 incorporou mais recursos de
banco de dados de objeto na SQL. O núcleo deve ser implementado por
todos os fornecedores de SGBDR que sejam compatíveis com SQL. As
extensões podem ser implementadas como módulos opcionais a serem
adquiridos independentemente para aplicações de banco de dados
específicas, como mineração de dados, dados espaciais, dados temporais,
data ware-housing, processamento analítico on-line (OLAP), dados de
multimídia, e assim por diante.

SQL é uma linguagem de banco de dados abrangente, a qual possui as

seguintes funcionalidades principais:

➢ definição (DDL) e manipulação (DML) de dados;

➢ definição de visões e autorizações de acesso;
➢ definição de restrições de integridade;
➢ definição de transações;
➢ comandos para embutir em Linguagens de Programação.

Estaremos conhecendo esta linguagem a seguir.

A palavra query está relacionada a um comando ou um conjunto
de comandos da linguagem SQL. Estão, podemos nos referir a um
comando SQL como uma query.
 67
BANCO DE DADOS

4.1. A importância de saber ler um

manual

Nesta disciplina, estaremos utilizando o SGBD PostgreSQL versão 9.0.4

(a versão mais recente em 25/04/2011) que pode ser baixada em http://
www.postgresql.org/ . O PostgreSQL é um SGBD gratuito.

Como tentarei ser o mais padrão possível, não estarei abordando as

funcionalidades extras do PostgreSQL, assim como você poderá utilizar
um outro SGBD, como Oracle, Sybase, SQLServer, Interbase, Mysql etc.

Por este motivo, vou dedicar um tempo em nossa disciplina para falar
sobre uma coisa básica para profissionais de informática: saber ler um
manual.

Entender como deve ser lido o manual ajuda, e muito, no entendimento

do mesmo. Sempre no início do manual deverá haver uma parte que
explica os símbolos utilizados. No manual do PostgreSQL em português,
isso fica na parte de “Convenções”.

Vou pegar um comando SQL qualquer do PostgreSQL como exemplo.

CREATE [ GLOBAL | LOCAL ] TABLE table_name ( [

{ column_namedata_type [ DEFAULT default_expr ] [
column_constraint [ ... ] ]
| table_constraint
| LIKE parent_table[ { INCLUDING | EXCLUDING }
DEFAULTS ] }
[, ... ]
] )
[ INHERITS ( parent_table [, ... ] ) ]
[ WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }
]
[ TABLESPACE tablespace ];

O objetivo aqui não é ensinar o comando CREATE TABLE, e sim como

se deve ler este tópico no manual.

Símbolo Descrição
Indica que começa aqui uma parte que é opcional. Então,
[ sabemos que o que vem à frente, até que seja encontrado
o símbolo ] correspondente a este, será tudo opcional.
68
EROS MOURA

Este símbolo indica que deve ser escolhida uma das

|
alternativas.
Indica que acabou a parte opcional. Lembre-se de que
]
este símbolo fecha colchete deve ter um correspondente.
Indica que começa aqui uma parte a qual sinaliza que
{ deve ser escolhida uma das alternativas. Isto é assim, até
se encontrar o símbolo }
... Indica que o elemento anterior pode ser repetido.

Então, vamos fazer uma “tradução” para ver se ficou bem entendido.

Um trecho do comando “CREATE [ GLOBAL | LOCAL ] TABLE

table_name”

O comando é CREATE, depois há uma parte opcional; se quiser usar a

parte opcional, vou escolher entre GLOBAL ou LOCAL, um ou outro.
Depois continua o comando com a palavra TABLEtable_name (nome
da tabela)

Outro trecho do comando:

( [
{ column_namedata_type [ DEFAULT default_expr ] [
column_constraint [ ... ] ]
| table_constraint
| LIKE parent_table[ { INCLUDING | EXCLUDING }
DEFAULTS ] }
[, ... ]
] )

Primeiro temos um ( , depois começa uma parte opcional. Repare que

esta parte opcional me dá 3 opções (column_name ou table_constraint
ou LIKE parent_table ); mas, se eu quiser usar a primeira opção,
terei que colocar column_name (nome da coluna), data_type (tipo da
coluna), depois vem alguma coisa opcional, na qual posso usar ou não o
DEFAULTdefault_expr (observe que é opcional até default_expr pois
após há um ], depois disto, outra coisa opcional column_constraint
(constraint de coluna) e que podemos ter mais de uma constraint de
coluna). Mas se quis utilizar a primeira opção, vou para a segunda
opção, que é table_constraint, ou posso querer utilizar a terceira opção,
que é LIKE parent_table[ { INCLUDING | EXCLUDING } DEFAULTS
] }, que significa que preciso colocar a palavra reservada LIKE, depois
parent_table (tabela da qual você quer copiar), depois uma parte opcional
em que você deve escolher entre INCLUDING ou EXCLUDING. Feita
 69
BANCO DE DADOS

a escolha, depois você tem que colocar DEFAULTS, depois o símbolo ]

indica o fim do opcional que começou depois da palavra parent_table .
Por fim, o símbolo } que indica o final do que pode ser repetido.

Depois há um [, ... ] indicando que há coisas opcionais; se eu o utilizar,

vou começar com a “,” depois repetir com a mesma sintaxe do anterior,
ou seja, que começa em { column_name e termina em DEFAULTS ] }

Por fim, temos ] ) indicando que há o final do opcional que começou

com ( [ , e depois que tenho que colocar )

Você reparou como é difícil explicar isto em português? Por isto é

necessário você aprender a utilizar o manual.

Faça, como exercício, uma “tradução” do final desse comando.

Mais uma coisa importante em relação aos manuais: os mais

recentes estão em inglês. Por isso, se você tem algum problema
com a língua inglesa, resolva este problema e comece a, ao menos,
ler materiais de informática em inglês. Isso é fundamental em
nossa área.

4.2. SQL/DDL (Data Definition Language)

A DDL (Data Definition Language), ou Linguagem de Definição de Dados,

é um grupo de comandos da linguagem SQL responsável pela definição
dos dados, ou seja, pela criação de bancos, esquemas, tabelas, campos,
tipos de dados, constraints, etc, e que permite ao usuário definir tabelas e
elementos associados. A SQL/DDL se caracteriza por poucos comandos
básicos, embora implementações comerciais tenham várias extensões.

4.3. CREATE

Comando CREATE cria um objeto (uma tabela, por exemplo) dentro

da base de dados.

Exemplos:
70
EROS MOURA

CREATE TABLE
CREATE INDEX
CREATE VIEW

Veremos estes comandos a seguir.

4.4. CREATE TABLE

Define a estrutura da tabela, suas restrições de integridade e cria uma

tabela vazia.

Sintaxe:

CREATE TABLE nome_tabela (

nome_atributo_1 tipo_1 [[NOT]NULL][UNIQUE]
[, ...]
[, CONSTRAINT <nome_constraint>
PRIMARY KEY (nome_atributo,...)]
[, CONSTRAINT <nome_constraint>
FOREIGN KEY (nome_atributo_local,...)‫‏‬
REFERENCESnome_tabela_remota(nome_atributo_
remoto,...)]
[, CONSTRAINT ...]
)‫;‏‬

Exemplo:

CREATE TABLE empregado(

matricula INTEGER NOT NULL,
nome VARCHAR(40) NOT NULL,
cpf CHAR(11) NULL
);

Todo comando SQL deve sempre terminar com “;”, o que é um

indicativo do término do comando.

OBSERVAÇÕES:

Este comando ainda está incompleto. Estaremos vendo, a seguir, mais

detalhes sobre o CREATE TABLE.
 71
BANCO DE DADOS

4.4.1. Os tipos de dados mais utilizados

Os tipos de dados mais utilizados são:

• char(n) ou character(n) - Cadeia de caracteres de tamanho fixo n

• varchar(n) ou character varying(n) - Cadeia de caracteres com
tamanho máximo n
• text - Cadeia de caracteres sem tamanho definido
• int ou integer - Números inteiros (4 bytes)
• numeric(precisão, escala) - Números reais sem limite de tamanho
• date e time - Data e hora
• datetime - Data + hora no mesmo campo
• boolean - Valores booleanos

Alguns desses tipos podem não existir em um determinado SGBD, mas

sempre haverá um tipo que seja sinônimo de algum desses.

Ainda há outro tipo que é importante, mas neste caso não existe
um padrão entre os SGBD. Este tipo possibilita que a coluna seja
incrementada automaticamente a cada nova linha. O valor está com 1
depois vai para 2, e assim por diante. No caso do PostgreSQL, que é o
SGBD que estaremos utilizando, o tipo é o SERIAL. Ao informar serial,
o PostgreSQL já sabe que ele será também NOT NULL.

4.4.2. Restrições de Integridade

Devemos sempre dar nomes às restrições para que seja mais fácil
identificar a razão pela qual a inserção de dados falha. Isso também
irá facilitar a exclusão, caso seja for necessário apagar a restrição. As
principais restrições são:

➢ CHECK

A restrição (constraint) do tipo CHECK é utilizada para validar uma

expressão lógica.

Exemplo:

CONSTRAINT salario_positivo
CHECK (salario > 550)

OBS: neste exemplo, o nome da constraint é salario_positivo (isso é

definido aqui com a palavra reservada CONSTRAINT).

Neste exemplo, não será possível incluir ou alterar o valor da coluna

salário com valor menor que 550.
72
EROS MOURA

CONSTRAINT valida_sexo
CHECK (sexo = ‘M’ OR sexo = ‘F’)

Neste exemplo, só será possível incluir ou alterar o valor do sexo com

M ou F. É com esta constraint que você implementa o domínio estático
mencionado no modelo conceitual.

➢ NOT-NULL

Para garantir que uma coluna não vai possuir valores nulos, podemos
usar uma restrição do tipo NOT NULL.

Exemplo:

salario NUMERIC(9,2) NOT NULL

(NOT NULL) é a única restrição (constraint) para a qual não é

dado um nome.

➢ UNIQUE

Chaves candidatas alternativas podem ser definidas usando restrições

do tipo UNIQUE. Estas restrições são equivalentes às restrições de chave
primária, mas não obrigam as colunas a serem não nulos (NOT NULL).

Exemplo:

CONSTRAINT un_empregado_cpf
UNIQUE (cpf)

➢ CHAVE PRIMÁRIA

Podemos definir uma, e só uma, chave primária para a tabela. Uma

chave primária não pode conter valores nulos nem pode ter valores
repetidos. Uma chave primária pode ser composta por mais de uma
coluna (campo).

Exemplo:

CREATE TABLE empregado(

matricula INTEGER NOT NULL,
nome VARCHAR(40) NOT NULL,
CONSTRAINT pk_empregado
PRIMARY KEY (matricula)
);
 73
BANCO DE DADOS

Um exemplo com a chave primária composta (mais de uma coluna):

CREATE TABLE empregado(

setor CHAR(3) NOT NULL,
matricula INTEGER NOT NULL,
nome VARCHAR(40) NOT NULL,
CONSTRAINT pk_empregado
PRIMARY KEY (setor, matricula)
);

➢ CHAVE ESTRANGEIRA

Uma restrição do tipo FOREIGN KEY permite declarar chaves

estrangeiras. Uma chave estrangeira deve sempre referenciar uma chave
primária ou única.

Exemplo:

CREATE TABLE empregado(

matricula INTEGER NOT NULL,
nome VARCHAR(40) NOT NULL,
cod_dep INTEGER NOT NULL,
CONSTRAINT pk_empregado
PRIMARY KEY (matricula),
CONSTRAINT fk_empregado_departamento
FOREIGN KEY (cod_dep)
REFERENCES departamento(cod_depto)
);
Podemos definir o que acontece, de forma automática, quando uma
chave estrangeira é violada durante uma operação de remoção ou
alteração. Isso será feito incluindo a cláusula ON DELETE (para fazer
de forma automática na remoção) e ON UPDATE (para fazer de forma
automática na alteração).

As alternativas para os valores de ON DELETE e ON UPDATE são:

➢ RESTRICT - Não deixa efetuar a operação;

➢ CASCADE - Apaga os registros associados (DELETE) ou
altera a chave estrangeira (UODATE);
➢ SET NULL - A chave estrangeira passa a NULL;
➢ SET DEFAULT - A chave estrangeira passa a ter o valor padrão;

Se não for definido o funcionamento default é a restrição do tipo

RESTRICT.
74
EROS MOURA

Exemplo:

CREATE TABLE empregado(

matricula INTEGER NOT NULL,
nome VARCHAR(40) NOT NULL,
cod_depto INTEGER NOT NULL,
CONSTRAINT pk_empregado
PRIMARY KEY (matricula),
CONSTRAINT fk_empregado_departamento
FOREIGN KEY (cod_depto)
REFERENCES departamento(cod_depto)
ON DELETE CASCADE
);
No exemplo, quando for apagado um departamento e caso exista(m)
empregado(s) associado(s) ao departamento que está sendo apagado,
todos estes empregados também serão apagados.

Tome muito cuidado com estas opções que fazem as operações de forma
automática, pois usá-las pode não ser a melhor saída.

4.4.3. Valor default

Você pode definir um valor padrão que será colocado sempre quando
houver uma inclusão na tabela e o valor da coluna não for especificado.

Exemplo:

CREATE TABLE departamento2(

cod_depto INTEGER NOT NULL,
nome_depto VARCHAR(40) DEFAULT ‘Departamento
Novo’ NOT NULL,
CONSTRAINT pk_departamento
PRIMARY KEY (cod_depto)
);

4.5. CREATE INDEX

Os índices são utilizados, principalmente, para melhorar o desempenho

do banco de dados (embora a utilização não apropriada possa resultar
em uma degradação de desempenho). e são definidos sobre atributos
para acelerar o acesso físico a dados. São definidos automaticamente
índices para atributos chave (PRIMARY KEY, UNIQUE).

Para criar um índice:

 75
BANCO DE DADOS

CREATE [UNIQUE] INDEX nome_índice

ON nome_tabela (nome_atributo_1[{, nome_
atributo_n }]);

Para apagar um índice:

DROP INDEX nome_índice;

Exemplo:
CREATE INDEX ind_medico_1
ON medico (nome_medico);

4.6. Domains

Os domains são tipos de dados definidos pelo utilizador de forma

a padronizar e evitar repetições. Um domain pode conter um valor
default, restrições do tipo not null e check.

Criando o domain:

CREATE DOMAIN do_salario NUMERIC(9,2) NOT NULL DE-

FAULT 1
CONSTRAINT ck_salario_maior_zero CHECK (value >
0);

Usando o domain:

CREATE TABLE empregado (

matricula INTEGER NOT NULL,
salario do_salario
);

Estará associado à coluna salário que ela é NUMERIC(9,2), que não

aceita valores null (restrição NOT NULL) e tem um valor padrão 1
(DEFAULT). Isso ocorreu quando se definiu o tipo da coluna salário
sendo do_salario.

Para apagar um DOMAIN:

DROP DOMAIN do_salario;

76
EROS MOURA

Observação: só será possível apagá-lo quando não houver mais

nenhuma tabela utilizando este DOMAIN.

4.7. ALTER

Comando ALTER altera um objeto (um índice, por exemplo) dentro da

base de dados.

Exemplos:

ALTER TABLE
ALTER INDEX
ALTER VIEW

4.7.1. Alter Table

Depois de criada, uma tabela pode ser modificada. Vejamos alguns

exemplos:

➢ Adicionando uma nova coluna (telefone) à tabela medico;

ALTER TABLE medico

ADD COLUMN telefone CHAR(10) NULL;

Observação: se a tabela já possuir linhas, você só pode incluir uma nova

coluna aceitando NULL, isto porque o SGBD colocará em cada linha
o valor NULL nesta coluna. Caso você deseje a coluna NOT NULL,
primeiro inclua como NULL, altere o valor dessa coluna em todas as
linhas e depois transforme para NOT NULL.

➢ Retirando uma coluna (telefone) da tabela medico;

ALTER TABLE medico

DROP COLUMN telefone;

➢ Incluindo uma nova restrição (CONSTRAINT) do tipo

CHECK à tabela medico;

ALTER TABLE medico

ADD CONSTRAINT ck_medico_idade
CHECK (idade_medico > 0);
 77
BANCO DE DADOS

➢ Incluindo uma nova restrição (CONSTRAINT) do tipo

UNIQUE à tabela medico;

ALTER TABLE medico

ADD CONSTRAINT un_medico_cpf
UNIQUE (cpf);

➢ Incluindo uma nova restrição (CONSTRAINT) do tipo

FOREIGN KEY à tabela medico;

ALTER TABLE medico

ADD CONSTRAINT fk_medico_ambulatorio
FOREIGN KEY (cod_ambulatorio)
REFERENCES ambulatorio(cod_ambulatorio);

➢ Incluindo uma nova restrição (CONSTRAINT) do tipo NOT

NULL à tabela medico;

ALTER TABLE medico

ALTER COLUMN especialidade SET NOT NULL;

➢ Retirando uma restrição (CONSTRAINT) com o nome un_

medico_cpf (restrição do tipo UNIQUE);

ALTER TABLE medico

DROP CONSTRAINT un_medico_cpf;

➢ Retirando uma restrição (CONSTRAINT) do tipo NOT

NULL, isto é, passando a coluna para aceitar NULL;

ALTER TABLE medico

ALTER COLUMN especialidade DROP NOT NULL;

➢ Definindo um valor DEFAULT para a coluna rg_medido;

ALTER TABLE medico

ALTER COLUMN rg_medico SET DEFAULT ‘SEM RG’;

➢ Retirando um valor DEFAULT para a coluna rg_medido;

ALTER TABLE medico

ALTER COLUMN rg_medico DROP DEFAULT;
78
EROS MOURA

➢ Renomeando a coluna CPF para CPF_medico na tabela

medico;

ALTER TABLE medico

RENAME COLUMN cpf TO cpf_medico;

➢ Renomeando a tabela medico para medicos;

ALTER TABLE medico

RENAME TO medicos;

4.8. DROP

Comando DROP apaga um objeto (uma view, por exemplo) dentro da

base de dados.

Exemplos:

DROP TABLE
DROP INDEX
DROP VIEW

4.8.1. Drop Table

Remove uma tabela com todos os seus registros, mas não remove tabelas
referenciadas por outras tabelas.

Sintaxe:

drop table <nome_tabela>;

Exemplo:

drop table empregado;

É importante chamar atenção para o seguinte: o SGBD não irá

permitir que você remova uma tabela que é referenciada por outra
tabela. Caso você realmente deseje fazer isso, você terá que apagar
primeiro as tabelas que fazem referência para, depois, apagar a
tabela que é referenciada. Uma outra possibilidade é apagar as
constraints foreign key, eliminando a dependência entre as tabelas.
 79
BANCO DE DADOS

4.8.2. Drop Index

Remove um índice do banco de dados.

Sintaxe:
drop index <nome_índice>;

Exemplo:
drop index i_empregado_nome;

4.9. Esquema

Um esquema do banco de dados é uma coleção de objetos de um banco

de dados que estão reunidos para um determinado grupo ou usuário. A
finalidade do esquema é possibilitar que, em um mesmo banco de dados,
possam existir tabelas de vários sistemas convivendo sem problemas de
nomes e permissões.

Um esquema é essencialmente um espaço de nomes: contém objetos

com nome (tabelas, tipos de dados, funções e operadores), cujos nomes
podem ser iguais aos de outros objetos existentes em outros esquemas.

Você pode criar o esquema, incluindo os objetos no momento da criação

ou apenas criar o esquema e, ao criar um novo objeto, informar a qual
esquema ele pertence.

Sintaxe:

CREATE SCHEMA nome_do_esquema

[ AUTHORIZATION nome_do_usuário ]
[ elemento_do_esquema [ ... ] ] ;

➢ nome_do_esquema

É o nome do esquema a ser criado. Se for omitido, será usado o nome

do usuário como nome do esquema. O nome não pode começar por pg,
porque estes nomes são reservados para os esquemas do sistema.

➢ nome_do_usuário

É o nome do usuário que será o dono do esquema. Se for omitido, tem

como padrão o usuário que está executando o comando. Somente os
superusuários podem criar esquemas pertencentes a outros usuários.
80
EROS MOURA

➢ elemento_do_esquema

É um comando SQL definindo um objeto a ser criado no esquema.

Atualmente, somente CREATE TABLE, CREATE VIEW, CREATE
INDEX, CREATE SEQUENCE, CREATE TRIGGER e GRANT são
aceitos como cláusula no comando CREATE SCHEMA no PostgreSQL.
Os objetos de outros tipos podem ser criados por comandos em
separado, após o esquema ter sido criado.

Exemplo:

Criar um esquema:
CREATE SCHEMA meu_esquema;

Criar um esquema para o usuário eros; o esquema também se chamará eros:

CREATE SCHEMA eros AUTHORIZATION eros;

Criar um esquema e, ao mesmo tempo, criar uma tabela neste esquema:

CREATE SCHEMA meu_esquema

CREATE TABLE filmes (
titulo VARCHAR(40),
lancamento DATE ,
premios VARCHAR(50)
)
;

4.10. Usuários

É possível criar usuários em seu banco de dados.

Sintaxe:
CREATE USER <nome_do_usuário>;

Exemplo:
CREATE USER eros;

No PostgreSQL, para criar um usuário com uma senha:

CREATE USER eros WITH PASSWORD ‘jw8s0F4’;
 81
BANCO DE DADOS

Para apagar um usuário, utilize este comando:

Sintaxe:
DROP USER <nome_do_usuário>;

4.11. Grupos

É possível criar um grupo para os usuários.

Sintaxe:
CREATE GROUP <nomedogrupo>;

Exemplo:
CREATE GROUP adm;

Para apagar um grupo, use:

DROP GROUP <nomedogrupo>;

OBSERVAÇÃO: isso remove somente o grupo, não remove os usuários.

Exemplo:
DROP GROUP adm;

Incluindo usuários no grupo:

ALTER GROUP adm

ADD USER user1, user2,user3 ;

Excluindo usuários do grupo:

ALTER GROUP adm

DROP USER user1, user2

4.12. Privilégios

Um privilégio é ter permissão para fazer alguma coisa em algum lugar.

O privilégio pode ser dado para o grupo, assim todos os usuários
daquele grupo receberão aquele privilégio. Pode, também, ser dado a
um usuário ou a mais de um usuário ao mesmo tempo.
82
EROS MOURA

Os privilégios de uso de tabelas e views são: SELECT,UPDATE,INSERT

e DELETE

Os privilégios de objetos são: DROP, CREATE e ALTER

O privilégio ALL (todos) é uma cláusula que pode ser utilizada quando
se deseja dar todos os privilégios.

O comando para conceder privilégios é o GRANT.

O comando de remover é o REVOKE.

Exemplos:

Dando privilégios de alterar dados a um usuário eros na tabela cidade:

GRANT UPDATE ON cidade TO eros;

Dando privilégios de leitura a um grupo analista na tabela cliente:

GRANT SELECT ON cliente TO analista;

Removendo todos os privilégios de todos os usuários da tabela cliente

(PostgreSQL):
REVOKE ALL ON cliente FROM PUBLIC;

Removendo todos os privilégios do usuário eros na tabela cliente:

REVOKE ALL ON cliente FROM eros;

Removendo os privilégios de alterar, excluir, inserir e selecionar (ler) da

tabela cidade do usuário eros:
REVOKE UPDATE,DELETE,INSERT,SELECT
ON cidade FROM eros;

Dando privilégios de selecionar (ler), alterar, inserir e apagar a o usuário

eros na tabela cidade:
GRANT SELECT,UPDATE,INSERT,DELETE
ON cidade TO eros;
 83
BANCO DE DADOS

Os privilégios DROP, GRANT, REVOKE, etc., pertencem ao dono

do objeto, não podendo ser concedidos ou revogados. O máximo
que um dono pode fazer é abdicar de seus privilégios e, com isso,
ninguém mais teria os privilégios dos mesmos e o objeto seria
somente leitura para todos.

Baseado no modelo abaixo, responda às seguintes questões:

1) Faça os comandos DDL necessários para implementar este
modelo no SGBD PostgreSQL.
2) Altere o nome da coluna descricao_problema na tabela Ordem_
Servico para desc_problema.
3) Altere o nome da tabela Telefone para Telefone_Cliente.
4) Inclua uma nova coluna na tabela Ordem_Servico com o nome
multa, do tipo numeric com o tamanho 6 sendo 2 com casas
decimais.
5) Suponha a seguinte situação: estão sendo reformulados os
acessos ao banco de dados em uma empresa. O diretor desta
empresa está preocupado com como será o acesso às informações
do banco de dados, em especial na tabela pedido. A empresa
possui 3 departamentos, sendo: operacional, financeiro e
comercial. Ele deseja que o acesso à tabela seja da seguinte forma:
o departamento operacional poderá ler, alterar, incluir e excluir; o
financeiro poderá ler e alterar; o comercial, apenas ler. Cada um
desses departamentos possui 2 funcionários, sendo: F1 e F2, do
operacional; F3 e F4, do financeiro; F5 e F6, do comercial, mas há
planos desta empresa para aumentar o número de empregados.
Como você resolveria esta necessidade, levando em conta a
previsão de crescimento da empresa?
6) Observação: os funcionários e os grupos ainda não existem e
devem ser criados no banco de dados. Os usuários não devem
ter permissão de criar usuários e também não devem poder criar
banco de dados. Cada usuário deverá ter com senha o mesmo que
o nome do usuário. Depois de ter terminado, o diretor solicitou
para você retirar os acessos que foram dados até uma segunda
ordem.
84
TELEFONE
cod_cliente: INTEGER (FK)
numero_telefone: CHAR(12)
ATENDENTE
matricula_atendente: CHAR(6)
nome_atendente: VARCHAR(30)
Ordem_Servico
numero_os: CHAR(6)
data_os: DATE
hora_os: TIME
cod_cliente: INTEGER (FK)
matricula_atendente: CHAR(6) (FK)
descricao_problema: VARCHAR(200)
descricao_fechamento: VARCHAR(200)
posicao_os: CHAR(1)
valor_total_os: NUMERIC(9,2)
ESTOQUE
cod_estoque: INTEGER
desc_estoque: VARCHAR(30)
valor_compra: NUMERIC(9,2)
quantidade_estoque: NUMERIC(8,2)
EROS MOURA
Cidade
cod_cidade: INTERGER UF
nome:cidade: VARCHAR(30) sigla_uf: CHAIR(2)
sigla_uf: CHAR(2) (FK) nome_uf: VARCHAR(30)
Cliente
cod_cliente: INTERGER Tecnico
nome_cliente: VARCHAR(40) cod_servico: INTEGER
rua: VARCHAR(35) nome_tecnico: VARCHAR(35)
numero: CHAR(6) terceiro: CHAIR(1)
bairro: VARCHAR(25)
cod_cidade: INTERGER(FK)
cep: CHAR(8)
sexo: CHAR(1)
Servico_Executado
numero_os: CHAR(6) (FK) Servico
cod_servico: INTERGER (FK) cod_servico: INTEGER
cod_tecnico: INTERGER (FK) nome_servico: VARCHAR(30)
data_inicial_servico: DATE estimativa_tempo: INTERGER
hora_inicial_servico: TIME valor_servico: NUMERIC(9,2)
data_final_servico: DATE
hora_final_servico: TIME
valor_cobrado_servico: NUMERIC(9,2)
Servico_Executad_Estoque
numero_os: CHAR(6) (FK)
cod_servico: INTERGER (FK)
cod_estoque: INTERGER (FK)
data_uso: DATE
hora_uso: TIME
quantidade_uso: NUMERIC(8,2)
 A LINGUAGEM SQL - DML

Oi, pessoal!
Neste capítulo, continuaremos a ver a linguagem SQL, e a parte
que aprenderemos agora faz a manipulação dos dados. No último
capítulo, vimos como criar a estrutura do banco de dados, por
exemplo, criando uma tabela. Agora, vamos inserir, alterar e tirar
dados dessa tabela. Quase todos os sistemas que existem fazem estas
operações internamente, e você irá aprender os comandos que mais
tarde irá inserir em seus programas.
Os objetivos deste capítulo são:
• compreender o que é DML;
• conhecer os comandos DML;
• conhecer a utilização dos principais operadores.

5.1. DML (Data Manipulation Language)

A DML, ou Linguagem de Manipulação de Dados, em português, é

a parte da SQL que manipula dados. Devo dizer que há autores que
inserem na DML as inserções, alterações, exclusões e pesquisas
(incluindo comandos para controle dessas operações). Há outros que
separam um pouco mais, deixando o DML apenas com inserções,
alterações e exclusões.

Ao fazermos uma pesquisa com um motor de busca qualquer (por

exemplo, Google), veremos que a Wikipédia, descrevendo SQL, faz as
seguintes divisões:

• DML - Linguagem de Manipulação de Dados

• DDL - Linguagem de Definição de Dados
• DCL - Linguagem de Controle de Dados
• DTL - Linguagem de Transação de Dados
• DQL - Linguagem de Consulta de Dados

Neste material, estamos utilizando a definição mais formal, que é a da

maioria dos autores e que inclui toda a parte de manipulação de dados
na parte DML.
86
EROS MOURA

5.2. INSERÇÃO DE LINHAS NA TABELA

A SQL exige a utilização do comando INSERT para inserir dados em

uma tabela. A sintaxe básica do comando possui o seguinte aspecto:

INSERT INTO <nome da tabela> (coluna1,

coluna2,...,colunaN)
VALUES (valorl, valor2, ..., valorN);

Onde:

<nome da tabela> nome da tabela em que se deseja incluir o dado

coluna1 a primeira coluna da tabela que terá sua
informação preenchida
coluna2 a segunda coluna da tabela que terá sua
informação preenchida
valor1 o valor correspondente à coluna1, ou seja, é o
valor que será colocado na coluna1
valor2 o valor correspondente à coluna2, ou seja, é o
valor que será colocado na coluna2

ColunaN e valorN significa que poderão existir várias colunas em uma

tabela. Se você informar 10 colunas, você deve informar 10 valores.

Você pode fazer o comando INSERT sem informar as colunas.

Embora isso seja verdade, há problemas que podem surgir
com esta opção, como por exemplo: se você fizer um comando
INSERT sem informar as colunas, seu comando ficará correto
enquanto perdurar a estrutura da tabela; caso haja a inclusão de
uma nova coluna, seu comando não funcionara mais. Assim, em
nosso curso, e espero que fora dele também, você irá usar a sintaxe
apresentada, utilizando os nomes das colunas.

Caso a tabela em que você quer incluir um dado tenha uma chave
estrangeira (FOREIGN KEY) com outra tabela, lembre-se de que
o valor informado em seu INSERT deverá existir antes na tabela
referenciada em sua chave estrangeira.
 87
BANCO DE DADOS

Exemplo:

INSERT INTO empregado (matricula,nome, CPF)

VALUES (1,’Eros Moura’,’12345678901’);

A indentação que é recuo (neologismo derivado da palavra em

inglês indentation – também encontram-se as formas identação e
endentação) é um termo aplicado ao código fonte de um programa
para indicar que os elementos hierarquicamente dispostos têm
o mesmo avanço relativamente a uma posição. A indentação ou
identação torna o código de qualquer linguagem muito mais fácil
de entender. Também na SQL isso é importante.

Observações:

• a entrada de dados depende do formato de data esperado pelo

SGBD. Por exemplo, 5 de abril de 2011 pode ser apresentado como
05/04/2011 ou 04/05/2011 ou, ainda, 2011/04/05. Isso é configurado
no SGBD;

• os valores de caracteres (string) e datas devem ser inseridos

entre apóstrofos ‘ ‘;
• as entradas numéricas não são cercadas por apóstrofos;
• as entradas de campos e valores são separadas por vírgulas;
• é necessário um valor para cada coluna da tabela informado;
• para informar um valor nulo (quando a coluna permitir), deve-
se usar a palavra reservada NULL no valor correspondente à coluna.

INSERT INTO empregado (matricula,nome, CPF)

VALUES (1,’Eros Moura’,NULL);

Supondo que a coluna CPF aceite valores NULL.

5.3. ATUALIZAÇÃO DE LINHAS DA TABELA

Utilize o comando UPDATE para modificar dados de uma tabela. A

sintaxe desse comando é:
88
EROS MOURA

UPDATE <nome da tabela>

SET coluna1 = valor1 [, ..., colunaN = valorN]
[WHERE lista de condições ];
Onde:

<nome da tabela> nome da tabela em que se deseja alterar dado

coluna1 a primeira coluna da tabela que terá sua
informação alterada
valor1 o valor correspondente à coluna1, ou seja, é o
valor que será alterado na coluna1
colunaN podem ser feitas alterações em várias colunas ao
mesmo tempo, para isso basta incluir uma vírgula
“,” e indicar mais uma coluna, o símbolo “=” e o
valor correspondente
valor1 o valorN correspondente à colunaN, ou seja, é o
valor que será colocado na colunaN
lista de condições é opcional, mas, se indicada, deverá ser uma
expressão lógica que retorne verdade ou falso

Na lista de condições podem ser utilizados operadores lógicos

AND e OR, como também é possível o uso de parênteses “( )”
para estruturar sua lógica. Podemos utilizar também o operador
lógico NOT para negar o resultado de uma expressão.

UPDATE aluno
SET nome_aluno = ‘MARIA’
WHERE matricula_aluno = 1;

Neste comando, estamos alterando o nome para MARIA, mas apenas

para o aluno que tem a matrícula com o número 1.

UPDATE aluno
SET media = 100;

Neste comando, estamos colocando a média 100 para todos os alunos.

UPDATE aluno
SET turma = ‘INF2’
WHERE nome_aluno LIKE ‘A%’ AND
matricula_aluno < 1000;
 89
BANCO DE DADOS

Neste comando, estamos alterando a turma para INF2, mas apenas

para os alunos cujos nomes começarem com A e cujas matrículas sejam
menores que 1000.

5.4. OPERADORES ESPECIAIS

A SQL do padrão ANSI permite a utilização de operadores especiais

com a cláusula WHERE. Esses operadores incluem:

➢ BETWEEN - Utilizado para verificar se o valor de um atributo

está dentro de uma faixa.
➢ IS NULL - Utilizado para verificar se o valor de um atributo é
nulo.
➢ LIKE - Utilizado para verificar se o valor de um atributo
coincide com um determinado padrão de caractere.
➢ IN - Utilizado para verificar se o valor de um atributo coincide
com qualquer valor de uma lista.
➢ EXISTS - Utilizado para verificar se uma subconsulta retorna
alguma linha.

5.4.1. Operador especial BETWEEN

O operador BETWEEN pode ser utilizado para verificar se um valor de

atributo está dentro de uma faixa de valores. Por exemplo: caso queira
alterar o valor de todos os produtos cujos preços estejam entre R$2,00 e
R$50,00, deve-se utilizar o comando a seguir:

UPDATE produto
SET valor_produto = 100
WHERE valor_produto BETWEEN 2.00 AND 50.00;

Para padronizar nossos códigos, além da indentação, utilizaremos:

caixa alta (upper-case), para as palavras que fazem parte da
linguagem; caixa baixa (lower-case), para as palavras que não
fazem parte da linguagem.

5.4.2. Operador especial IS NULL

O operador IS NULL é utilizado para verificar valores de atributos nulos.

Suponha, por exemplo, que se queira alterar todos os alunos que não
informaram o CPF (foi colocado valor NULL na coluna CPF), passando
para 00000000000. Podemos fazer isso com este comando:
90
EROS MOURA

UPDATE aluno
SET cpf = ‘00000000000’
WHERE cpf IS NULL;

Observe que a SQL utiliza um operador especial para testar os

nulos. Por quê? Não seria possível simplesmente inserir uma
condição como “CPF = NULL”? Não. Tecnicamente, NULL não
é um “valor” como o número 0 (zero), um espaço em branco ou
uma string vazia(‘’). Em vez disso, trata-se de uma propriedade
especial de um atributo que representa precisamente a ausência
de qualquer valor. Você pode pensar em NULL também como
um valor desconhecido, então pode ser 1 ou ‘A’ ou qualquer outra
coisa. Por isso é necessário existir um operador específico para
trabalhar com NULL.

5.4.3. Operador especial LIKE

O operador especial LIKE é utilizado com coringas para encontrar

padrões em atributos de strings. A SQL padrão permite a utilização dos
caracteres coringas do sinal de porcentagem (%) e do traço inferior (_)
para obter correspondências quando a string inteira é desconhecida.

• % significa que todos e quaisquer caracteres seguintes ou

precedentes podem ser escolhidos. Por exemplo:
➢ ‘J%’ inclui Joaquim, João, Jamile, Joana;
➢ ‘Jo%’ inclui Joaquim e Joana;
➢ ‘%e’ inclui Jamile.
• _ significa que um único caractere qualquer pode ser substituído
pelo traço. Por exemplo:
➢ ‘ _23-456-789’ inclui ‘123-456-789’, ‘223-456-789’ e
‘323-456-789’;
➢ ‘_a_ile’ inclui Jamile.

Quero alterar a média de todos os alunos cujos nomes comecem com

a letra E.

UPDATE aluno
SET media = 0
WHERE nome_aluno LIKE ‘E%’;
 91
BANCO DE DADOS

Quero alterar a média de todos os alunos cujos nomes comecem com

as letras MA.

UPDATE aluno
SET media = 0
WHERE nome_aluno LIKE ‘MA%’;
Quero alterar a média de todos os alunos cujos nomes terminem com
a letra E.

UPDATE aluno
SET media = 0
WHERE nome_aluno LIKE ‘%E’;
Quero alterar a média de todos os alunos cujos nomes contenham CH
em qualquer parte.

UPDATE aluno
SET media = 0
WHERE nome_aluno LIKE ‘%CH%’;

Pode haver problemas de performance com a utilização do

operador LIKE quando não for usado da primeira forma, por
exemplo, nome LIKE ‘E%’. Isso pode ocorrer se o SGBD não
conseguir utilizar um índice que eventualmente exista na coluna,
neste exemplo, nome.

5.4.4. Operador especial IN

O operador IN é uma implementação do operador lógico OR. Imagine

que você queira alterar a média do aluno, caso o nome dele seja
‘João’,’Maria’,’José’.

Isto poderia ser feito assim:

UPDATE aluno
SET media = 0
WHERE nome_aluno = ‘João’ OR
nome_aluno = ‘Maria’ OR
nome_aluno = ‘José’;
Mas com o uso do operador IN, este mesmo comando ficaria assim:

UPDATE aluno
SET media = 0
WHERE nome_aluno IN (‘João’, ‘Maria’, ‘José’);
92
EROS MOURA

Observe que o operador IN utiliza uma lista de valores. Todos os valores

da lista (que forma um conjunto) devem ter o mesmo tipo de dados.
Cada um dos valores da lista é comparado ao atributo - neste caso,
nome_aluno. Se o valor de nome_aluno corresponder a qualquer valor
da lista, a linha é selecionada. Neste exemplo, se já existisse um aluno
chamado João e outra Maria e não existisse o José cadastrado, apenas
João e Maria seriam selecionados. Se o atributo utilizado for de tipo de
dados de caracteres ou data, os valores da lista devem ficar entre aspas,
simples e se for do tipo numérico sem aspas simples.

O operador IN é especialmente útil quando utilizado com subconsultas.

Por exemplo: suponha que se queira alterar o tipo do fornecedor (tipo_
fornecedor), mas apenas daqueles que estão fornecendo produtos.
Nesse caso, pode-se utilizar uma subconsulta (uma pesquisa feita dentro
de outro comando. Veremos detalhes sobre consulta no próximo
capítulo) no operador IN para gerar automaticamente a lista de valores
(conjunto). A consulta seria:

UPDATE fornecedor
SET tipo_fornecedor = ‘Ativo’
WHERE codigo_fornecedor IN (SELECT codigo_forne-
cedor FROM produto);

A consulta precedente será executada em duas etapas:

1. A consulta interior ou subconsulta gerará uma lista de valores de

codigo_fornecedor da tabela Produto. Esses valores representam os
fornecedores que estão fornecendo os produtos.

2. O Operador IN comparará os valores gerados pela subconsulta

com os valores de codigo_fornecedor na tabela Fornecedor e
selecionará apenas as linhas com valores correspondentes, ou seja, os
fornecedores que estão fornecendo produtos. Assim, só será alterada
a coluna tipo_fornecedor com o valor Ativo, para os fornecedores
que estão fornecendo produtos.

5.4.5. Operador especial EXISTS

O operador especial EXISTS pode ser utilizado sempre que for

necessário executar um comando com base no resultado de uma
consulta. Ou seja, se uma subconsulta retornar quaisquer linhas, deve-
se executar o comando principal; do contrário, não. Por exemplo: o
seguinte comando vai alterar o tipo_fornecedor para o valor ‘Compra’,
mas apenas se houver produtos em seu estoque (coluna estoque) que
estejam abaixo do mínimo (coluna estoque_minimo):
 93
BANCO DE DADOS

UPDATE fornecedor
SET tipo_fornecedor = ‘Compra’
WHERE EXISTS (SELECT * FROM produto WHERE estoque
<= estoque_minimo);

5.5. EXCLUSÃO DE LINHAS DA TABELA

Excluir uma linha ou várias linhas de uma tabela se faz com a utilização
do comando DELETE. A sintaxe desse comando é:

DELETE FROM <nome da tabela>

[WHERE lista de condições];

Por exemplo: caso queira excluir da tabela aluno o aluno com a matricula
21, deve ser usado:

DELETE FROM aluno

WHERE matricula_aluno = 21;

Se quero apagar todos os alunos, deve ser usado:

DELETE FROM aluno;

Temos que tomar muito cuidado com este comando, pois

ele irá funcionar sem a cláusula WHERE, porém com outro
funcionamento, no caso, apagando todas as linhas da tabela.
Apagar os alunos que o nome começa com a letra E

DELETE FROM aluno

WHERE nome_aluno LIKE ‘E%’;

Todos os operadores especiais que vimos podem ser utilizados no

comando DELETE.

Baseado nos comandos DDL abaixo, responda às questões abaixo.

94
EROS MOURA

CREATE TABLE produto (

cod_produto INTEGER NOT NULL,
desc_produto VARCHAR(30) NOT NULL,
valor_produto NUMERIC(8,2) NOT NULL,
estoque_produto NUMERIC(9,2) NOT NULL,
valor_compra_produto NUMERIC(8,2) NOT NULL,
CONSTRAINT pk_produto
PRIMARY KEY(cod_produto)
);

CREATE TABLE rota (

cod_rota INTEGER NOT NULL,
desc_rota VARCHAR(40) NOT NULL,
CONSTRAINT pk_rota
PRIMARY KEY(cod_rota)
);
CREATE TABLE itens_rota (
cod_rota INTEGER NOT NULL,
cod_item_rota INTEGER NOT NULL,
desc_item_rota VARCHAR(30) NOT NULL,
tempo_item_rota INTEGER NOT NULL,
CONSTRAINT pk_itens_rota
PRIMARY KEY(cod_rota, cod_item_rota),
CONSTRAINT fk_itens_rota_rota
FOREIGN KEY(cod_rota)
REFERENCES rota(cod_rota)
);
CREATE TABLE pedido (
numero_pedido INTEGER NOT NULL,
data_pedido DATE NOT NULL,
hora_pedido TIME NOT NULL,
data_prev_entrega DATE NOT NULL,
cod_cliente INTEGER NOT NULL,
CONSTRAINT pk_pedido
PRIMARY KEY(numero_pedido),
CONSTRAINT fk_pedido_cliente
FOREIGN KEY(cod_cliente)
REFERENCES cliente(cod_cliente)
);
CREATE TABLE cliente (
cod_cliente INTEGER NOT NULL,
nome_cliente VARCHAR(35) NOT NULL,
rua_cliente VARCHAR(40) NOT NULL,
bairro_cliente VARCHAR(30) NOT NULL,
cep_cliente CHAR(8) NOT NULL,
 95
BANCO DE DADOS

telefone_cliente CHAR(10) NOT NULL,

cod_rota INTEGER NOT NULL,
cod_item_rota INTEGER NOT NULL,
CONSTRAINT pk_cliente
PRIMARY KEY(cod_cliente),
CONSTRAINT fk_cliente_itens_rota
FOREIGN KEY(cod_rota, cod_item_rota)
REFERENCES itens_rota(cod_rota, cod_item_rota)
);

1) Para fazer alguns testes no banco de dados, você deseja incluir

pelo menos um registro em cada uma das tabelas acima, de uma
forma que não haja erro nestas inclusões. OBS: utilize qualquer
valor válido. Como ficaria o DML para resolver esta questão?

2) Foi solicitado a você que retirasse da tabela cliente o(s) cliente(s)

que tiverem a descrição de suas rotas começando com a letra R.
Qual(is) o(s) comando(s) DML para executar esta tarefa, sem
haver eventuais erros no processo?

3) Aconteceu um problema e você foi chamado às 2:30 da manhã

para resolver! No relatório de entregas, foi observado que o sistema
gerou pedidos com valor unitário do produto e valor total do item
errados, ou seja, o valor do item não está igual ao valor de tabela
do produto. Mas isso aconteceu apenas para os pedidos que estão
associados aos itens de rota com o tempo previsto do item maior
que 60 e para todas as rotas que começam com a letra A. Qual(is)
o(s) comando(s) DML para resolver este problemas?
OBS:
valor_total_item=valor unitário correto do produto *
quantidade_produto

O valor unitário correto do produto está na tabela Produto e

chama-se valor_produto.

4)A empresa está pensando, sinceramente, em comprar ou

desenvolver outro sistema, pois o mesmo apresentou outro
problema. Desta vez, foi solicitado a você que apagasse os itens de
pedidos do dia 06/04/2011, os quais foram feitos com a quantidade
de produto maior do que a quantidade que há em estoque. Qual(is)
o(s) comando(s) DML para resolver este problemas?
96
EROS MOURA

5)Houve uma alteração nas rotas da empresa, e se deseja alterar

as rotas dos clientes que estão associados a itens de rota com os
tempos 60, 90, 120, 150. A nova informação que deve ser colocada
para estes clientes é a rota para 3 e o item de rota para 1.

OBS: utilize o operador IN

 A LINGUAGEM SQL – COMANDO
SELECT

Olá, pessoal! Estamos quase no final!

Neste capítulo, conheceremos a última parte da linguagem SQL que
será vista em nosso curso. Esta parte está no final, mas considero
a mais importante de todas. Certamente é a parte da SQL que é
mais utilizada e que pode ajudar ou atrapalhar a qualidade e, em
especial, a performance de um sistema. Já conheci vários analistas
que não tinham o conhecimento necessário para trabalhar bem com
a SQL, principalmente nesta parte de leitura que será abordada
agora. Espero que seja um grande diferencial para você conhecer,
como vamos fazê-lo, a parte de leitura da SQL.
Os objetivos deste capítulo são:
• conhecer o comando Select;
• conhecer como utilizar os principais operadores com o
comando Select;
• compreender como são feitas junções na SQL;
• conhecer como fazer junções utilizando o novo formato;
• conhecer como é realizada uma exclusão com a utilização
de junções;
• conhecer como é realizada uma atualização com a
utilização de junções.

6.1. Listagem de linhas da tabela

O comando SELECT é utilizado para listar o conteúdo de uma tabela. A

sintaxe desse comando é a seguinte:

SELECT lista de colunas

FROM nome da tabela[,...nome_tabelaN]
[WHERE condição]
A lista de colunas representa uma ou mais colunas separadas por
vírgulas. Pode-se utilizar * (asterisco) como caractere coringa para listar
todas as colunas. Por exemplo: para listar todas as colunas e todas as
linhas da tabela aluno, utilize:
98
EROS MOURA

0SELECT *
FROM aluno;

O resultado de um comando SELECT é um conjunto. Saber disso é

importante para entender, por exemplo, porque podemos utilizar
um SELECT dentro de outro (subquery) ou entender o resultado
de algumas funções de agregação, as quais veremos a seguir.

6.2. Funções de agregação

Há situações em que você precisará totalizar informações. Sem

o SGBD, você teria que ler os dados do banco de dados e fazer um
programa que fizesse esta totalização. Felizmente, com o uso do SGBD,
há a possibilidade do uso das funções de agregação, as quais fazem a
totalização e retornam uma informação.

A informação que recebemos de uma função de agregação é

sintética, pois está resumindo um conjunto de informações
analíticas que estão no banco de dados.

6.2.1. Função de agregação - Count

Retorna a quantidade de linhas (registros) existentes em uma tabela ou,

mais precisamente, a quantidade de linhas (registros) existentes em um
conjunto resposta de um comando SELECT.

Sintaxe:
COUNT(campo ou *)

Onde:

Campo: campo por onde se deseja contar. Não será feita a contagem da
linha que tiver o campo indicado com o valor NULL.

* : Um coringa que significa todos os campos, inclusive a chave primária,

que, como sabemos, não pode aceitar valor NULL, portanto, sempre
trará o total de linhas da tabela.

Exemplos:

Vai retornar a quantidade de linhas de produtos, mas sem levar em

conta os produtos que têm o favor de cod_fornecedor como NULL.
 99
BANCO DE DADOS

SELECT COUNT(cod_fornecedor)
FROM produto;

Vai retornar a quantidade total de linhas de produtos, isso porque está

usando cod_produto que é a chave primária da tabela produto, portanto,
não pode aceitar NULL.

SELECT COUNT(cod_produto)
FROM produto;

Vai retornar a quantidade total de linhas de produtos, isso porque está

usando * que inclui colunas NOT NULL (que não aceitam NULL),
inclusive a coluna cod_produto que é a chave primária da tabela produto,
portanto, não pode aceitar NULL.

SELECT COUNT(*)
FROM produto;

Uma dica: se seu objetivo for apenas contar a quantidade de

linhas e a tabela tiver um tamanho um pouco maior, você pode
experimentar usar COUNT(1). É possível que a performance seja
melhor. Em uma tabela pequena, você não vai sentir diferença.

SELECT COUNT(1)
FROM produto;

6.2.2. Função de agregação – Sum

Retorna a soma de uma coluna indicada dos dados existentes em uma

tabela.

Sintaxe:

SUM(coluna)
Onde:

Coluna: uma coluna da tabela que possa ser somada (numérica).

Exemplo:

Vai retornar a soma de todos os valores de venda dos produtos

cadastrados na tabela produto.
100
EROS MOURA

SELECT SUM(p.valor_venda)
FROM produto p;

Por favor, observe a diferença entre contar e somar. Imagine que

você tenha duas linhas em uma tabela, e que esta s linhas tenham
uma coluna chamada valor_venda.
Linha 1: valor venda 3.00
Linha 2: valor venda 6.00
A contagem com a função COUNT vai retornar 2, mas a soma
com a função SUM, por este campo, vai retornar 9.00

6.2.3. Função de agregação – AVG

Retorna a média aritmética de uma coluna indicada dos dados existentes

em uma tabela.

Sintaxe:

AVG(coluna)
Onde:

Coluna: uma coluna da tabela em que possa ser tirada a média

(numérica).

Exemplo:

Vai retornar a média de todos os valores de venda dos produtos

cadastrados na tabela produto.

SELECT AVG(p.valor_venda)
FROM produto p;

6.2.4. Função de agregação – MIN

Retorna o menor valor de uma coluna indicada dos dados existentes em

uma tabela.

Sintaxe:

MIN(coluna)
Onde:
 101
BANCO DE DADOS

Coluna: uma coluna da tabela.

Exemplo:

Vai retornar o menor valor de venda dos produtos cadastrados na tabela

produto.

SELECT MIN(p.valor_venda)
FROM produto p;

6.2.5. Função de agregação – MAX

Retorna o maior valor de uma coluna indicada dos dados existentes em

uma tabela.

Sintaxe:

MAX(coluna)
Onde:

Coluna: uma coluna da tabela.

Exemplo:

Vai retornar o maior valor de venda dos produtos cadastrados na tabela

produto.

SELECT MAX(p.valor_venda)
FROM produto p;

6.2.6. Agrupamentos

Até aqui, todos os nossos resultados foram feitos para toda a tabela,
por exemplo, a média aritmética do valor de venda do produto. Vamos
imaginar que nos foi pedido a média aritmética do valor de venda do
produto, mas não de todos, e sim destes em relação a cada fornecedor.
Em outras palavras, deseja-se saber qual é o valor médio de venda de
cada fornecedor.

Para se possível isto, precisamos entender que teremos que pegar todos os
registros da tabela e dividi-los (quebrá-los) em grupos de fornecedores.
Assim, eu teria um grupo de produtos de cada fornecedor. Na SQL, isso
é feito com o GROUP BY.
102
EROS MOURA

Por exemplo: quantos produtos eu tenho de cada fornecedor.

SELECT p.cod_fornecedor,

COUNT(*)
FROM produto p
GROUP BY p.cod_fornecedor;

Sairá um resultado parecido com este:

Fornecedor Quantidade

1 1000
2 1500
3 2000
4 1100

Você deve ter observado que dividimos os dados da tabela por cada
fornecedor com o GROUP BY.

Apenas para confirmar: se não utilizasse a divisão (quebra), o resultado

seria:

SELECT COUNT(*)
FROM produto p;

Quantidade

5600

Observe que as funções de agregação retornam uma informação sintética

e a informação do fornecedor é analítica (refere-se a cada fornecedor e
não um total, uma soma, uma média, etc.). A única forma na SQL de
juntar informações analíticas com informações sintéticas é utilizando o
GROUP BY.

Informação CódigoNome1Empresa
12Empresa
Analítica
23Empresa 3...
SELECT p.cod_fornecedor,
COUNT(*)
FROM produto p
GROUP BY p.cod_fornecedor; Informação
Sintética.
Total: 1.100,00

Se é possível juntar ‘
(analítico com sintético) com
o uso do GROUP BY
 103
BANCO DE DADOS

6.2.7. Restrições para o Agrupamento

Da mesma forma que as informações analíticas podem ser restringidas

através da cláusula WHERE, também podemos fazer restrições às
informações sintéticas com a cláusula HAVING.

A listagem só sairá quando eu tiver mais de 20 produtos em meu

cadastro de produtos.

SELECT COUNT(*)
FROM produto p
HAVING COUNT(*) > 20;

A listagem só sairá quando um fornecedor tiver mais que 10 produtos

em meu cadastro de produtos.

SELECT p.cod_fornecedor,
COUNT(*)
FROM produto p,
fornecedor f
GROUP BY p.cod_fornecedor
HAVING COUNT(*) > 10;

6.2.8. Ordenação

É possível escolher em que ordem você quer ver o resultado de sua

query. Isso é feito com a cláusula ORDER BY. Veja o exemplo:

SELECT p.cod_produto,
p.nome_produto
FROM produto p
ORDER BY p.nome_produto;

Você ainda pode escolher que saia do maior para o menor com a opção
DESC. Veja o exemplo:

SELECT p.cod_produto,
p.nome_produto
FROM produto p
ORDER BY p.nome_produto DESC;

É possível também ordenar por mais de uma coluna. Veja o exemplo:

SELECT p.tipo_produto,
p.nome_produto
FROM produto p
ORDER BY p.tipo_produto,
p.nome_produto;
104
EROS MOURA

6.3. Utilização dos principais

operadores com o comando Select

É possível utilizar todos os operadores que vimos até aqui com o

comando SELECT, inclusive aqueles vistos no item 5.4.

Por exemplo: quero listar todas as colunas de todos os alunos, cujos

nomes comecem com a letra A.

SELECT *
FROM aluno
WHERE nome_aluno LIKE ‘A%’;

Quero listar apenas o nome e o sexo dos alunos, cujas datas de nascimento
estejam entre 01/01/1980 a 31/12/1990.

SELECT nome_aluno,
sexo
FROM aluno
WHERE data_nascimento BETWEEN ‘01/01/1980’ AND
‘31/12/1900’;

Quero listar a matrícula dos alunos que nasceram nas UF RJ e ES.

SELECT matricula
FROM aluno
WHERE naturalidade IN (‘RJ’,’ES’);

Assim como nesses exemplos, qualquer um dos operadores já estudados

pode ser utilizado no comando SELECT.

6.4. Junções na SQL

A capacidade de combinar tabelas em atributos comuns talvez seja a

distinção mais importante entre o banco de dados relacional e os outros
bancos. Executa-se uma junção quando os dados são recuperados de
mais de uma tabela ao mesmo tempo. Para juntar tabelas, basta listá-
las na cláusula FROM do comando SELECT ou UPDATE ou, ainda,
no USING. O SGBD criará o produto cartesiano de todas as tabelas
dessa cláusula. No entanto, para obter o resultado correto devem ser
selecionadas apenas as linhas em que os valores de atributos comuns
coincidam.

Para fazer isso, utilize a cláusula WHERE para indicar os atributos

comuns utilizados para ligar as tabelas.
 105
BANCO DE DADOS

A condição de junção costuma ser composta por uma comparação

de igualdade entre a chave estrangeira e a chave primária das tabelas
relacionadas. Por exemplo: suponha que se deseje juntar duas tabelas:
Fornecedor e Produto. Na tabela Produto existe uma coluna chamada
cod_fornecedor, que é a chave estrangeira de Produto e, também, a
chave primária de Fornecedor. Estão disponíveis as junções internas,
externas e cruzadas. Assim, podemos estabelecer uma junção utilizando
este atributo.

Produto Fornecedor
cod_produto (PK) cod_fornecedor (PK)
nome_produto nome_fornecedor
cod_fornecedor (FK) ...
....

Antes de implementarmos isso na SQL, precisamos saber que, se tiver

uma situação na qual duas ou mais tabelas estão fazendo junção (join)
e há um mesmo nome de coluna repetido em mais de uma tabela, temos
que utilizar um mecanismo para que o SGBD entenda de qual tabela
quero a coluna escolhida.

Neste exemplo, temos a coluna cod_fornecedor na tabela Produto e na

Tabela Fornecedor. Se não fizer nenhuma indicação de qual tabela quero
ler a coluna cod_fornecedor, o SGBD não saberá o que fazer, assim você
receberá uma mensagem de erro, algo como “coluna ambígua”. Para
resolver esta situação, há duas formas: indicar o nome da tabela antes da
coluna (por exemplo: fornecedor.cod_fornecedor) ou usar um apelido
(alias) para as tabelas e usá-lo ao invés do nome da tabela, por exemplo:
f.cod_fornecedor. Na prática se usa a segunda opção, e é por isso que
passarei a utilizá-la.

Vamos ver como ficaria este comando:

Sei que o
cod_fornecedor
é da tabela
fornecedor
porque o
apelido (alias)
é f

ELECT p.cod_produto,
p.nome_produto,
f.cod_fornecedor, O apelido
f.nome_fornecedor (alias)
FROM produto p, criado p e Aqui foi
fornecedor f
feito a
WHERE p.cod_fornecedor = f.cod_fornecedor; junção
106
EROS MOURA

Passo utilizar os termos Join e Alias para me referenciar a junções

e apelido, respectivamente, pois são mais comumente utilizados
na área de banco de dados.

Também podemos criar um apelido (alias) para a coluna,

utilizando a cláusula AS. Um exemplo:
SELECT p.cod_produto as “Código”,
p.nome_produto as “Nome Prod”
FROM produto p;

Feito o join entre as tabelas produto e fornecedor, passa a estar disponível

um conjunto com todas as colunas de produto e de fornecedor. Assim,
você pode selecionar as colunas que quiser nestas duas tabelas.

Embora a utilização do alias apenas seja obrigatória nos casos em

que há ambiguidade de colunas, nós o utilizaremos em todas as
colunas com a finalidade de facilitar a leitura do código por você
ou por outro profissional da área.

Ao juntar três ou mais tabelas, é necessário especificar uma condição de

junção para cada par de tabelas. O número de condições é sempre N - 1,
em que N representa o número de tabelas listadas na cláusula FROM.
Por exemplo: se houver três tabelas, devem existir duas condições de
junção; se forem cinco tabelas, são necessárias quatro condições, etc.

Lembre-se: a condição de junção corresponderá à chave estrangeira de

uma tabela com a chave primária da tabela relacionada. Por exemplo:
utilizando a Figura 1, caso deseje a lista das sessões, com a data da
sessão, hora da sessão, titulo do filme, nome do cinema, ficaria assim:

sessão
cod_cinema: CHAR(14) (FK) cinema
cod_filme: INTEGER(5) (FK) cnpj_cinema:CHAR(14
data_sessao: DATE nome_cinema: VARCHAR(35)
hora_sessao: TIME lotacao_cinema: INTEGER(3)
quantidade_pessoas: INTERGER(3)

filme
cod_servico: INTERGER(5)
genero
cod_genero: INTERGER(2) (FK)
titulo_filme: VARCHAR(40) cod_genero: INTEGER(2)
duracao_filme: INTEGER(3) descricao_genero: VARCHAR(30)
censura_filme: INTEGER(2)
 107
BANCO DE DADOS

SELECT s.data_sessao,
s.hora_sessao,
f.titulo_filme,
c.nome_cinema
FROM sessao s,
filme f,
cinema c
WHERE s.cod_file = f.cod_filme AND
s.cod_cinema = c.cnpj_cinema;
Será que posso, neste mesmo comando, inserir a informação da
descrição do gênero?

Quando fiz o join entre sessão e filme, como já vimos, passei a ter acesso
a todas as colunas da tabela filme. Se tenho este acesso, posso utilizar
a coluna cod_genero. Se posso utilizar a coluna cod_genero da tabela
filme, posso fazer o join entre as tabelas filme e gênero.

Veja como ficaria:

SELECT s.data_sessao,
s.hora_sessao,
f.titulo_filme,
c.nome_cinema,
g.descricao_genero
FROM sessao s,
filme f,
cinema c,
genero g
WHERE s.cod_file = f.cod_filme AND
s.cod_cinema = c.cnpj_cinema AND
f.cod_genero = g.cod_genero;

Espero que tenha dado para perceber que, havendo uma ligação
entre as tabelas, é possível “navegar” no modelo escolhendo as
colunas que forem necessárias. Isso é um SGBD Relacional!

Vamos ver mais um exemplo:

108
EROS MOURA

Ordem_Servico
numero_os: CHAR(6)
data_os: DATE
hora_os: TIME
descricao_problema: VARCHAR(200)
descricao_fechamento: VARCHAR(200)
posicao_os: CHAR(1)
valor_total_os: NUMERIC(9,2)
Servico_Executado
numero_os: CHAR(6) (FK)
cod_servico: INTERGER (FK)
data_inicial_servico: DATE
hora_inicial_servico: TIME
data_final_servico: DATE
hora_final_servico: TIME
valor_cobrado_servico: NUMERIC(9,2)
Estoque
cod_servico: INTEGER
nome_servico: VARCHAR(30)
estimativa_tempo: INTERGER
valor_servico: NUMERIC(9,2)

Estoque
cod_servico: INTEGER
desc_estoque: VARCHAR(30)
valor_compra: NUMERIC(9,2)
quantidade_estoque: NUMERIC(8,2)
Servico_Executado_Estoque
numero_os: CHAR(6) (FK)
cod_servico: INTERGER (FK)
cod_estoque: INTERGER (FK)
data_uso: DATE
hora_uso: TIME
quantidade_uso: NUMERIC(8,2)

É possível fazer uma listagem contendo: descricao_problema, nome_

servico? Vejamos como ficaria:

SELECT os.descricao_problema,
s.nome_servico
FROM ordem_servico os,
servico_executado se,
servico s
WHERE os.numero_os = se.numero_os AND
se.cod_servico = s.cod_servico;

Nesse exemplo, temos uma coisa nova. Precisamos incluir a tabela

servico_executado, mesmo sem colocar na listagem nenhuma
informação dessa tabela. Por quê?

Porque saindo da tabela ordem_servico para chegar à tabela servico foi

necessário passar por servico_executado.

Por fim, tenha cuidado para não criar condições de junções circulares.
Por exemplo: se a Tabela A for relacionada com a Tabela B, a Tabela B
com a Tabela C e a Tabela C com a Tabela A, crie apenas duas condições
de junção: una A com B e B com C. Não una C com A!

Até aqui, utilizamos o estilo mais antigo de fazer os joins. Este estilo é
muito bom para as junções internas (as que vimos até agora) e cruzadas
(que retornam o produto cartesiano entre as duas tabelas, e equivale
a indicar as tabelas no FROM e não colocar a regra do join na clásula
WHERE). Mas, para as junções externas, este estilo não possui um
padrão em todos os SGBD. Para resolver este problema, vamos conhecer
um outro estilo de fazer nossos joins.
 109
BANCO DE DADOS

6.4.1. Junção cruzada

A junção cruzada executa um produto relacional (também conhecido

como produto cartesiano) de duas tabelas. A sintaxe da junção cruzada
é:

SELECT lista de colunas

FROM tabela1 CROSS JOIN tabela2;

Por exemplo,

SELECT *
FROM fatura CROSS JOIN linha;

Executa a junção cruzada das tabelas fatura e linha. A consulta CROSS

JOIN. Supondo-se que há 8 linhas de fatura e 18 de linha, esta consulta
vai gerar 144 linhas (8 x 18 = 144 linhas.)

Também é possível executar uma junção cruzada que produza apenas os

atributos especificados. Por exemplo, pode-se especificar:

SELECT f.numero_fatura,
f.cod_cliente,
f.data_fatura,
l.cod_linha
FROM fatura f CROSS JOIN linha l;

Os resultados gerados por esse comando de SQL também podem ser

gerados utilizando a seguinte sintaxe:

SELECT f.numero_fatura,
f.cod_cliente,
f.data_fatura,
l.cod_linha
FROM fatura f,
linha l;

6.4.2. Junção natural

Uma junção natural retorna todas as linhas com valores correspondentes

nas colunas correspondentes e elimina colunas duplicadas. Esse estilo
de consulta é utilizado quando as tabelas compartilham um ou mais
atributos comuns com nomes comuns. A sintaxe da junção natural é:
110
EROS MOURA

SELECT lista de colunas

FROM tabela1 NATURAL JOIN tabela2;

A junção natural executará as seguintes tarefas:

➢ Determinar os atributos comuns, buscando atributos com

nomes idênticos e tipos de dados compatíveis.
➢ Selecionar apenas as linhas com valores comuns nos atributos
comuns.

SELECT p.cod_produto,
p.nome_produto,
f.cod_fornecedor,
f.nome_fornecedor
FROM produto p NATURAL JOIN fornecedor f;

Tem que haver colunas com o mesmo nome nas 2 tabelas!

O resultado é o mesmo que o da forma tradicional de fazer o

join.

6.4.3. Cláusula de junção USING

Um segundo modo de expressar uma junção (o CROSS JOIN é um

produto cartesiano e não uma junção) é por meio da palavrachave USING.
Essa consulta retorna apenas as linhas com valores correspondentes na
coluna indicada nessa cláusula (essa coluna deve ocorrer em ambas
tabelas). A sintaxe é:

SELECT lista de colunas

FROM tabela1 JOIN tabela2 USING (coluna comum)

Veja o exemplo:

SELECT p.cod_produto,
p.nome_produto,
f.cod_fornecedor,
f.nome_fornecedor
FROM produto p JOIN fornecedor f USING
(cod_fornecedor);
 111
BANCO DE DADOS

6.4.4. Cláusula de junção JOIN ON (ou INNER JOIN ON)

Os dois estilos de junção anteriores utilizavam nomes de atributos

comuns nas tabelas a serem unidas. Outro modo de expressar uma
junção, quando as tabelas não têm nomes de atributos em comum, é
utilizar o operando JOIN ON (na verdade, você pode utilizar este estilo
também no caso de haver atributos comuns nas tabelas). Essa consulta
retornará apenas as linhas que atendam à condição de junção indicada.
Essa condição normalmente incluirá uma expressão de comparação de
igualdade de duas colunas. (As colunas podem ou não compartilhar
o mesmo nome, mas, obviamente, devem apresentar tipos de dados
comparáveis.) A sintaxe é:

SELECT lista de colunas

FROM tabela1 JOIN tabela2 ON condição de junção;

A cláusula INNER é opcional no PostgreSQL.

Exemplo:

SELECT p.cod_produto,
p.nome_produto,
f.cod_fornecedor,
f.nome_fornecedor
FROM produto p JOIN fornecedor f
ON p.cod_fornecedor = f. cod_fornecedor;

Lembre-se de que a sintaxe de JOIN ON permite executar a junção,

mesmo que as tabelas não compartilhem um nome de atributo.

6.4.5. Junções externas

Até aqui, todos os tipos de joins vistos poderiam ser feitos do modo
tradicional, sem nenhum problema. Há uma situação em que é necessário
retornar não apenas as linhas que atendam à condição de junção (ou
seja, aquelas com valores correspondentes nas colunas comuns), mas
também as linhas sem valores correspondentes, e, neste caso, você irá
utilizar a junção externa. O padrão ANSI define três tipos de junções
externas: à esquerda, à direita e completa.
112
EROS MOURA

As designações à esquerda e à direita referem-se à ordem em que as

tabelas são processadas pelo SGBD. Lembre-se de que as operações de
junção se dão em duas tabelas por vez. A primeira tabela indicada na
cláusula FROM será o lado esquerdo; a segunda, o direito.

Se três ou mais tabelas estiverem sendo juntadas, o resultado da junção

das duas primeiras torna-se o lado esquerdo e a terceira tabela, o direito.

A junção externa à esquerda retorna não apenas as linhas que atendam

à condição de junção (ou seja, aquelas com valores correspondentes na
coluna comum), mas também as linhas da tabela do lado esquerdo sem
valores correspondentes na tabela do lado direito. A sintaxe é:

SELECTlista de colunas
FROM tabela1 LEFT OUTER JOIN tabela2 ON condição
de junção;

Por exemplo: a seguinte consulta lista o código de produto, nome do

produto, código do fornecedor e o nome de fornecedor de todos os
produtos, e inclui os produtos sem os fornecedores correspondentes:

SELECT p.cod_produto,
p.nome_produto,
f.cod_fornecedor,
f.nome_fornecedor
FROM produto p LEFT OUTER JOIN fornecedor f
ON p.cod_fornecedor = f. cod_fornecedor;

A junção externa à direita retorna não apenas as linhas que atendam à

condição de junção (ou seja, aquelas com valores correspondentes na
coluna comum), mas também as linhas da tabela do lado direito sem
valores correspondentes na tabela do lado esquerdo. A sintaxe é:

SELECT lista de colunas

FROM tabela1 RIGHT OUTER JOIN tabela2 ON condição
de junção

Por exemplo: a seguinte consulta lista o código do fornecedor, nome

de fornecedor, código de produtoe o nome do produto de todos os
fornecedores, e inclui os fornecedores sem os produtos correspondentes:

SELECT f.cod_fornecedor,
f.nome_fornecedor,
p.cod_produto,
p.nome_produto
FROM produto p RIGHT OUTER JOIN fornecedor f
ON p.cod_fornecedor = f. cod_fornecedor;
 113
BANCO DE DADOS

A junção externa completa retorna não apenas as linhas que atendam

à condição de junção (ou seja, aquelas com valores correspondentes
nas colunas comuns), mas também todas as colunas sem valores
correspondentes nas tabelas de ambos os lados. A sintaxe é:

SELECT lista de colunas

FROM tabela1 FULL OUTER JOIN tabela2 ON condição
de junção

Por exemplo, a seguinte consulta lista o código de produto, nome do

produto, código do fornecedor e o nome de fornecedor de todos os
produtos, incluindo os produtos sem os fornecedores correspondentes
e os fornecedores sem os produtos correspondentes:

SELECT p.cod_produto,
p.nome_produto,
f.cod_fornecedor,
f.nome_fornecedor
FROM produto p FULL OUTER JOIN fornecedor f
ON p.cod_fornecedor = f. cod_fornecedor;

6.5. Visualização Relacional - VIEW

Como você aprendeu anteriormente, o resultado de um operador

relacional como SELECT é um conjunto (outra relação ou tabela).
Suponha que, no fim de cada dia, deseje-se obter uma lista de todos
os produtos que devem ser encomendados, ou seja, produtos cuja
quantidade disponível é menor ou igual a uma quantidade mínima.

Em vez de digitar a mesma consulta no fim de cada dia, não seria melhor
salvar essa consulta de forma permanente no banco de dados? Essa é a
função de uma visualização relacional.

Uma visualização é uma tabela virtual baseada em uma consulta

SELECT. A consulta pode conter colunas, colunas computadas, alias e
funções agregadas de uma ou mais tabelas.

É possível criar uma visualização utilizando o comando CREATE VIEW:

Sintaxe: CREATE VIEW <nome da view> AS

SELECT consulta;
114
EROS MOURA

Exemplo:

CREATE VIEW v_trabalho_executado AS

SELECT os.descricao_problema,
s.nome_servico
FROM ordem_servico os,
servico_executado se,
servico s
WHERE os.numero_os = se.numero_os AND
se.cod_servico = s.cod_servico;

Você pode utilizar a view para queries mais complicadas, para relatórios
ou, por questões de segurança, liberado apenas as informações a que um
determinado usuário possa ter acesso.

O uso da view é o mesmo de uma tabela. A única diferença é que alguns

SGBD só permitem a leitura da view (SELECT). A gravação (INSERT,
UPDATE e DELETE) não é permitida.

6.6. OPERADORES DO CONJUNTO

rE-LACIONAL

6.6.1. UNION

Suponha que a Empresa1 tenha comprado outra empresa. A gerência

da Empresa1 deseja ter certeza de que a lista de clientes da empresa
adquirida seja fundida adequadamente com sua própria lista de clientes.
Como é muito provável que alguns clientes tenham comprado artigos
de ambas as empresas, as duas listas podem conter nomes comuns. A
gerência da Empresa1 quer certificar-se de que os registros de clientes
não sejam duplicados quando da fusão das duas listas. A consulta
UNION é a ferramenta perfeita para gerar uma listagem combinada de
clientes que exclua registros duplicados.

Esse comando combina linhas de duas ou mais consultas sem incluir

linhas duplicadas. A sintaxe do comando UNION é:

Consulta
UNION
consulta
 115
BANCO DE DADOS

Em outras palavras, o comando UNION combina o resultado de duas

consultas SELECT. (Lembre-se de que o comando SELECT deve ser
compatível para união, ou seja, deve retornar os mesmos nomes de
atributos e tipos de dados similares.).

Por exemplo:

SELECT nome_cliente,
cpf_cliente
FROM cliente
UNION
SELECT nome_cliente,
cpf_cliente
FROM cliente2;

O comando UNION pode ser utilizado para unir mais do que apenas
duas consultas. Por exemplo: assuma que se tenham quatro consultas
compatíveis para união chamadas T1, T2, T3 e T4. Com o comando
UNION, é possível combinar a saída das quatro em um único conjunto
de resultados. O comando de SQL será similar ao seguinte:

SELECT lista de colunas

FROM Tl
UNION
SELECT lista de colunas
FROM T2
UNION
SELECT lista de colunas
FROM T3
UNION
SELECT lista de colunas
FROM T4;

6.6.2. UNION ALL

Se a gerência da Empresa1 quiser saber quantos clientes há em ambas

as listas CLIENTE1(da Empresa1) e CLIENTE2 (da Empresa2), você
pode utilizar o operador UNION ALL para produzir um conjunto que
conserve as linhas duplicadas. Portanto, a seguinte consulta manterá
todas as linhas de ambas as tabelas (inclusive as duplicadas):

SELECT nome_cliente,
cpf_cliente
FROM cliente
UNION ALL
116
EROS MOURA

SELECT nome_cliente,
cpf_cliente
FROM cliente2;

Como UNION, o comando UNION ALL também pode ser utilizado

para unir mais do que apenas duas consultas.

6.6.3. INTERSECT

Se a gerência da Empresa1 quiser saber quais registros de clientes estão

duplicados nas tabelas Cliente1 e Cliente2, o comando INTERSECT
pode ser utilizado para combinar linhas de duas consultas, retornando
apenas as que aparecem em ambos os conjuntos. A sintaxe do comando
INTERSECT é:

consulta
INTERSECT
consulta

Para gerar a lista de registros de clientes duplicados, pode-se utilizar:

SELECT nome_cliente,
cpf_cliente
FROM cliente
INTERSECT
SELECT nome_cliente,
cpf_cliente
FROM cliente2;

6.7. ATUALIZAÇÃO AVANÇADA DE LINHAS DA

TABELA

No item 5.3, vimos como é feita a atualização de uma linha em uma

tabela; porém, há situações em que, para atualizar uma tabela A, eu vou
precisar de dados da tabela B. Isso é possível? Sim, e você já sabe como
fazer esta ligação (join) entre as tabelas, só precisamos saber como é
feito na atualização. Vamos dar uma olhada:

Vejam este modelo:

 117
BANCO DE DADOS

UF CIDADE
sigla_uf: CHAR(2) cod_cidade; INTEGER(4)
nome_uf: VARCHAR(25) nome_cidade: VARCHAR(35)
sigla_uf: CHAR(2) (FK)

ITENS_MANIFESTO
num_manifesto: CHAR (6) (FK)
num_ctrc: CHAR(6) (FK)
posicao_ctrc: INTEGER(2)
CTRC
num_ctrc: CHAR (6)
cliente_remetente: INTEGER(8) (FK)
cliente_destinatario: INTEGER(8) (FK)
data_emissão: DATE
peso_ctrc: NUMERIC (6,2)
frete_ctrc: NUMERIC (8,2)
CLIENTE
cod_cliente: INTEGER(8)
nome_cliente: VARCHAR(40)
Remetente tipo_cliente: CHAR(1)
cpf_cliente: CHAR(11)
cnpj_cliente: CHAR (14)
Destinatário
rua_cliente: VARCHAR(30)
bairro_cliente: VARCHAR (15)
cidade_cliente: INTEGER(4) (FK)
cep_cliente: CHAR(8)

MANIFESTO
num_manifesto: CHAR (6)
cod_motorista: INTEGER(4) (FK)
filial_origem_manifesto: CHAR(3) (FK)
final_destino_manifesto: CHAR(3) (FK)
placa_veiculo_manifesto: CHAR(7) (FK)
data_emissao_manifesto: DATE
data_chegada_manifesto: DATE
Origem Destino
CTRC_NF
CLIENTE_TELEFONE
num_ctrc: CHAR(6) (FK)
num_nf: CHAR(6) cod_cliente: INTEGER (FK)
telefone_cliente: CHAR(12)
VEICULO
MODELO VEICULO
placa_veiculo: CHAR (7)
cod_modelo_veiculo: INTEGER(2)
descricao_veiculo: VARCHAR (40)
desc_modelo_veiculo: VARCHAR(30)
cod_modelo_veiculo: INTEGER(2) (FK)

UF MOTORISTA
sigla_filial: CHAR(3) cod_motorista: INTEGER (4)
nome_filial: VARCHAR(30) nome_motorista: VARCHAR (45)
categoria_motorista: CHAR(1)

Foi solicitado a você uma atualização na tabela CTRC, aumentando em

15% o valor do frete (frete_ctrc), mas apenas para os destinos que forem
para unidade federativa que tenha o nome “São Paulo”. Repare que você
quer alterar um valor na tabela CTRC com uma informação que está na
tabela UF.

UPDATE ctrc c
SET frete_ctrc = c.frete_ctrc * 1.15
FROM cliente cl,
cidade ci,
uf u
WHERE c.cliente_destinatario = cl.cod_cliente AND
cl.cod_cidade = ci.cod_cidade AND
ci.sigla_uf = u.sigla_uf AND
u.nome_uf = ‘São Paulo’;

Você estava natabela ctrc, foi para a tabela cliente (c.cliente_destinatario

= cl.cod_cliente) da tabela cliente foi para a tabela cidade (cl.cod_cidade
= ci.cod_cidade) de cidade foi para a tabela uf (ci.sigla_uf = u.sigla_
uf) e já tendo chegado na tabela uf pode utilizar a coluna nome da UF
(u.nome_uf).
118
EROS MOURA

Não se pode utilizar alias de tabela na cláusula SET do comando

UPDATE pois, obrigatoriamente, as colunas alteradas são da
tabela indicada no início do comando. Então fazer:
SET c.frete_ctrc = c.frete_ctrc * 1.15
Estaria errado, inclusive recebendo um erro de sintaxe do SGBD.

6.8. EXCLUSÃO AVANÇADA DE LINHAS DA

TABELA

No item 5.5 vimos como é feita a exclusão de uma linha em uma tabela;
porém, há situações em que, para excluir de uma tabela A, eu vou
precisar de dados da tabela B. Isso é possível? Sim, e você já sabe como
fazer esta ligação (join) entre as tabelas, só precisamos saber como é
feito na exclusão. Vamos dar uma olhada:

Baseado no modelo acima, temos que excluir os CTRC que foram

emitidos com destino ao Rio de Janeiro.

DELETE FROM ctrc c

USING cliente cl,
cidade ci,
uf u
WHERE c.cliente_destinatario = cl.cod_cliente AND
cl.cod_cidade = ci.cod_cidade AND
ci.sigla_uf = u.sigla_uf AND
u.nome_uf = ‘Rio de Janeiro’;

A ideia é igual à da alteração, a diferença é a palavra reservada USING

no lugar do FROM no UPDATE. O comando DELETE usa USING pois
já faz o uso de FROM no início do comando, mas o resto é igual.

Baseando-se nos comandos DDL abaixo, responda às seguintes

perguntas:
CREATE TABLE uf (
sigla_uf CHAR(2) NOT NULL,
nome_uf VARCHAR(30) NOT NULL,
CONSTRAINT pk_uf
PRIMARY KEY(sigla_uf)
);
 119
BANCO DE DADOS

CREATE TABLE tipo_pagamento (

cod_tipo_pagamento SERIAL,
desc_tipo_pagamento VARCHAR(20) NOT NULL,
CONSTRAINT pk_tipo_pagamento
PRIMARY KEY(cod_tipo_pagamento)
);

CREATE TABLE categoria (

cod_categoria SERIAL,
nome_categoria VARCHAR(30) NOT NULL,
estocavel CHAR(1) NOT NULL,
CONSTRAINT pk_categoria
PRIMARY KEY(cod_categoria)
);
CREATE TABLE mesa (
cod_mesa SERIAL,
qtd_lugares INTEGER NOT NULL,
status_mesa CHAR(1) NOT NULL,
descricao TEXT NOT NULL,
CONSTRAINT pk_mesa
PRIMARY KEY(cod_mesa)
);
CREATE TABLE cargo (
cod_cargo SERIAL,
nome_cargo VARCHAR(40) NOT NULL,
descricao TEXT NOT NULL,
CONSTRAINT pk_cargo
PRIMARY KEY(cod_cargo)
);
CREATE TABLE produto (
cod_produto SERIAL,
nome_produto VARCHAR(30) NOT NULL,
qtd_estoque INTEGER NOT NULL,
valor NUMERIC(6,2) NOT NULL,
cod_categoria INTEGER NOT NULL,
CONSTRAINT pk_produto
PRIMARY KEY(cod_produto),
CONSTRAINT fk_produto_categoria
FOREIGN KEY(cod_categoria)
REFERENCES categoria(cod_categoria)
);
CREATE TABLE funcionario (
cod_funcionario SERIAL,
nome_funcionario VARCHAR(40) NOT NULL,
120
EROS MOURA

cod_cargo INTEGER NOT NULL,

salario NUMERIC(6,2) NOT NULL,
CONSTRAINT pk_funcionario
PRIMARY KEY(cod_funcionario),
CONSTRAINT fk_funcionario_cargo
FOREIGN KEY(cod_cargo)
REFERENCES cargo(cod_cargo)
);
CREATE TABLE cliente (
cod_cliente SERIAL,
nome_cliente VARCHAR(30) NOT NULL,
rua VARCHAR(30) NOT NULL,
complemento VARCHAR(10) NOT NULL,
cod_bairro INTEGER NOT NULL,
cep CHAR(8) NULL,
CONSTRAINT pk_cliente
PRIMARY KEY(cod_cliente),
CONSTRAINT fk_cliente_bairro
FOREIGN KEY(cod_bairro)
REFERENCES bairro(cod_bairro)
);
CREATE TABLE cidade (
cod_cidade SERIAL,
nome_cidade VARCHAR(40) NOT NULL,
sigla_uf CHAR(2) NOT NULL,
CONSTRAINT pk_cidade
PRIMARY KEY(cod_cidade),
CONSTRAINT fk_cidade_uf
FOREIGN KEY(sigla_uf)
REFERENCES uf(sigla_uf)
);

CREATE TABLE bairro (

cod_bairro SERIAL,
nome_bairro VARCHAR(30) NOT NULL,
cod_cidade INTEGER NOT NULL,
CONSTRAINT pk_bairro
PRIMARY KEY(cod_bairro),
CONSTRAINT fk_bairro_cidade
FOREIGN KEY(cod_cidade)
REFERENCES cidade(cod_cidade)
);
CREATE TABLE conta (
cod_conta SERIAL,
cod_cliente INTEGER NULL,
 121
BANCO DE DADOS

cod_mesa INTEGER NOT NULL,

data_criacao DATE NOT NULL,
desconto NUMERIC(6,2) NOT NULL,
acrescimo NUMERIC(6,2) NOT NULL,
status_conta CHAR(1) NOT NULL,
valor_total_consumo NUMERIC(6,2) NOT NULL,
comissao_paga CHAR(1) NOT NULL,
cod_tipo_pagamento INTEGER NOT NULL,
valor_recebido NUMERIC(9,2) NOT NULL,
CONSTRAINT pk_conta
PRIMARY KEY(cod_conta),
CONSTRAINT fk_conta_cliente
FOREIGN KEY(cod_cliente)
REFERENCES cliente(cod_cliente),
CONSTRAINT fk_conta_mesa
FOREIGN KEY(cod_mesa)
REFERENCES mesa(cod_mesa),
CONSTRAINT fk_conta_tipo_pagamento
FOREIGN KEY(cod_tipo_pagamento)
REFERENCES tipo_pagamento(cod_tipo_pagamento)
);
CREATE TABLE comanda (
cod_comanda SERIAL,
cod_conta INTEGER NOT NULL,
cod_funcionario INTEGER NOT NULL,
data_pedido DATE NOT NULL,
hora_pedido TIME NOT NULL,
CONSTRAINT pk_comanda
PRIMARY KEY(cod_comanda),
CONSTRAINT fk_comanda_funcionario
FOREIGN KEY(cod_funcionario)
REFERENCES funcionario(cod_funcionario),
CONSTRAINT fk_comanda_conta
FOREIGN KEY(cod_conta)
REFERENCES conta(cod_conta)
);
CREATE TABLE itens_comanda (
cod_comanda INTEGER NOT NULL,
cod_produto INTEGER NOT NULL,
quantidade INTEGER NOT NULL,
CONSTRAINT pk_itens_de_comanda
PRIMARY KEY(cod_comanda, cod_produto),
CONSTRAINT fk_itens_de_comanda_comanda
FOREIGN KEY(cod_comanda)
REFERENCES comanda(cod_comanda),
122
EROS MOURA

CONSTRAINT fk_itens_de_comanda_produto
FOREIGN KEY(cod_produto)
REFERENCES produto(cod_produto)
);

1) O dono de um restaurante deseja verificar a produtividade

dos produtos de seu restaurante. Para isso, solicitou a você uma listagem
que tivesse: nome do produto, a quantidade de pedidos feitos, a maior
quantidade vendida em uma só comanda, a menor quantidade vendida
em uma só comanda e a média pedida nas comandas. Ele só deseja que
saia nesta listagem os produtos cuja média da quantidade seja maior que
10 e a categoria do produto seja LIQUIDO. Esta listagem deve sair em
ordem decrescente pela média da quantidade.

2) O dono desse restaurante deseja saber se vale a pena continuar

com a quantidade de mesas que o restaurante tem atualmente. Para isso,
solicitou a você uma listagem que contenha: a descrição da mesa e a
soma total de cada produto vendido em cada mesa(usar o nome SOMA)
(não utilizar o total da comanda). Nesta listagem devem aparecer apenas
as mesas com o código 1,2,3 e 4 (utilizar a cláusula IN) e só devem
ser computadas as vendas que foram pagas com o tipo de pagamento
DINHEIRO. Ele ainda solicitou que só saíssem na listagem os produtos
que foram vendidos mais de 10 itens de comanda e que a listagem saísse
em ordem da soma.

3) O dono desse restaurante agora deseja verificar se deve ficar

com a quantidade de garçons que ele possui hoje. Esta verificação será
feita pela quantidade de comandas (e não de itens de comanda) que
cada garçom atende. Para isso, ele solicitou uma listagem contendo o
nome do garçom e a quantidade de comandas atendidas por ele (deve
sair quantidade_comandas). Nessa listagem só devem sair os garçons
e, para isso, deve-se utilizar o nome do cargo com todos os cargos que
começam com a letra G. A listagem deve sair ordenada pela quantidade
de comandas do maior para o menor. Fazer do jeito “novo” e, se for o
caso, em mais de uma forma.
Cougo, P. Modelagem de Dados Conceitual e Projetos de Banco de Dados. 16. ed. Rio de
Janeiro: Elsevier Editora, 1997.

Date, C. J. Introdução a Sistemas de Banco de Dados. 7. ed. Rio de Janeiro: Elsevier, 2003.

Elmasri, R.; Navathe, S. B. Sistemas de Banco de Dados. 6. ed. São Paulo: Person Addison
Wesley, 2011.

Rob, P.; Coronel, C. Sistemas de Banco de Dados-Projeto, Implementação e

Administração. 8. ed. São Paulo: Cengage Leaning, 2011.