Guia de Estudos Banco de Dados

Banco de dados
Prof. Me. Rodrigo Franklin Frogeri

1ª Edição
Gestão da Educação a Distância
Cidade Universitária - Bloco C
Avenida Alzira Barra Gazzola, 650,
Bairro Aeroporto. Varginha /MG
ead.unis.edu.br
0800 283 5665
Todos os direitos desta edição

ficam reservados ao Unis - MG.
É proibida a duplicação ou re-
produção deste volume (ou
parte do mesmo), sob qualquer
meio, sem autorização expressa
da instituição.
Autoria
Prof. Me.
Rodrigo Franklin Frogeri
Doutorando em Sistemas de Informação e Gestão do Conhecimento pela Universidade FUMEC.

Mestre em Administração. Pós-graduado em Gestão de Tecnologia da Informação. Pós-graduado
em Docência no Ensino Superior. Pós-graduado em Redes de Computadores. Bacharel em Ciência
da Computação. Professor efetivo no Centro Universitário do Sul de Minas - UNIS-MG, atuando
nos cursos de Tecnologia em Análise e Desenvolvimento de Sistemas, Bacharelado em Sistemas
de Informação e Bacharelado em Ciência da Computação. Na pós-graduação do UNIS-MG atuou
nos cursos de Engenharia de Software com Java, Desenvolvimento de Aplicativos para Dispositivos
Móveis, Gerência e Tecnologias de Redes de Computadores e MBA em Gestão de Tecnologia da
Informação. Atualmente, na pós-graduação, ministra aulas no MBA Executivo em Governança de
Tecnologia da Informação (GTI), Gerência e Tecnologias de Redes de Computadores e Cibersegu-
rança e Perícia Forense Computacional.
Currículo Lattes: http://lattes.cnpq.br/0403458828547468

FROGERI, Rodrigo Franklin. Banco de dados. Varginha: GEaD-UNIS/
MG, 2018.
149 p.
1. Banco de dados. 2. Projeto de bancos de dados. 3. Linguagem SQL.

4. Big Data.
Unis EaD
Cidade Universitária – Bloco C
Avenida Alzira Barra Gazzola, 650,
Bairro Aeroporto. Varginha /MG
ead.unis.edu.br
0800 283 5665
5
Prezado (a) aluno (a),
Neste guia serão apresentados e discutidos os principais conceitos do tema Banco de Da-
dos. Desenvolveremos projetos de banco de dados completos, desde a fase de identificação das en-
tidades e atributos até à implementação em um Sistema Gerenciador de Banco de Dados (SGBD).
Na sequência, vamos conhecer a fundo a linguagem de consultas estruturadas, o que nos permitirá
desenvolver códigos avançados em SGBDs. Os últimos capítulos trazem novos conceitos da aplica-
ção de banco de dados, como no SQL, Data Warehouse e Big Data.
Temos muito o que estudar, mas tenho certeza que esse conteúdo irá lhe proporcionar um
grande crescimento intelectual na temática Banco de Dados. ;)
Nossa interação será essencial nesse processo.

Conte sempre comigo!
Abraço,
Prof. Rodrigo Franklin Frogeri.
Ementa
Analisar e projetar modelos de bancos de dados; analisar e manipular dados em siste-
mas gerenciadores de banco de dados; administrar sistemas gerenciadores de banco
de dados; compreender e aplicar princípios de segurança, integridade, concorrên-
cia e recuperação a falhas; compreender os conceitos de datawarehouse, datamarts,
datamining, big data e OLAP.
Orientações
Ver plano de estudos da disciplina, disponível no ambiente virtual.
Palavras-chave
Banco de dados. Modelo relacional. Modelo objeto-relacional. Gerenciadores.
Big Data.
Unidade I - Banco de Dados: Uma Visão Introdutória 12
1.1. Introdução 12
1.2. Arquiteturas de Banco de Dados 14
1.3. Conceitos e a Propriedade ACID 17
1.4. Conceitos em Banco de Dados 20
Unidade II - Linguagens de Banco de Dados 25
2. Introdução 25
2.1. Linguagem de Manipulação de Dados 26
2.2. Linguagem de Definição de Dados 27
2.3. Linguagem de Transação de Dados 30
2.4. Linguagem de Controle de Dados 32
Unidade III - Projeto de Banco de Dados 35
3. Introdução 35
3.1. Modelos de Dados 35
3.2. Projeto de Banco de Dados (Passo a Passo) 37
3.3. Criando o Projeto de Banco de Dados 38
3.3.1. Modelo Relacional 39
3.3.2. Modelo Conceitual 46
3.3.3. Modelo Lógico 54
3.3.4. Modelo Físico 56
Unidade IV - Normalização de Projetos de Banco de Dados 60
4. Introdução 60
4.1. Formas Normais 62
4.1.1. Primeira Forma Normal (1NF) 63
4.1.2. Segunda Forma Normal 65
4.1.3. Terceira Forma Normal 67
Unidade V - Linguagem de Consultas Estruturadas (SQL) 72
5. Introdução 72
5.1. Estruturas Básicas da SQL 72
5.2. Operações de Junções 80
5.3. Operações de Alteração de Dados 83
5.4. Consultas Entre Várias Tabelas 86
5.5. Sub-Consultas Aninhadas 88
Unidade VI - Linguagens de Definição de Dados da SQL 92
6. Introdução 92
6.1. Comandos de Definição de Dados 92
6.1.1. Grupo de Arquivos (FILEGROUPS) 93
6.2. Integridade e Consistência dos Dados 103
Unidade VII - Estruturas Avançadas de Programação em Banco de Dados I 111
7. Introdução 111
7.1. Procedimentos Armazenados (Stored Procedures) 114
Unidade VIII - Estruturas Avançadas de Programação em Banco de Dados II 120
8. Introdução 120
8.1. Gatilhos (triggers) 120
Unidade IX - Introdução à Organização e Análise de Dados 128
9. Introdução 128
9.2. Big Data 133
Unidade X - Tecnologias de Armazenamento e Manipulação de Grandes Quantida-
des de Dados 138
10. Introdução 138
10.1. Data Warehouse 138
10.2. Hadoop 141
10.3. Computação em Memória (In-memory Computing) 145
Referências Bibliográficas 149
I Unidade I - Banco de
Dados: Uma Visão
Introdutória
Objetivos da Unidade
Ao final desta unidade, os alunos irão:
- Compreender os princípios de uma estrutura de banco de da-

dos e seus principais conceitos.
Unidade I - Banco de Dados: Uma Visão Introdutória
1.1. Introdução
Podemos considerar que o surgimento dos bancos de dados, como o conhecemos hoje, sur-
giu na IBM entre as décadas de 1960 e 1970, onde se buscava automatizar processos de escritório
reduzindo a quantidade de pessoas para armazenar e indexar (organizar) arquivos.
O pesquisador da IBM Edgard Frank Codd (Ted Codd como era chamado) publica, em
1970, o primeiro artigo sobre bancos de dados relacionais (veremos a seguir o que é). A ideia de
Codd era que o usuário fosse capaz de acessar dados organizados em uma estrutura computacional
(tabelas) por meio de comandos em inglês.
A IBM monta um grupo de pesquisa chamado System R, com o objetivo de testar e desen-
volver as ideias de Codd. O System R evoluiu para o chamado SQL/DS e que posteriormente foi
nomeado de Structured Query Language (SQL) - Linguagem de Consulta Estruturada. Mais tarde o
padrão ISO (International Organization for Standardization) homologou o padrão SQL se tornando
um padrão internacional.
Os primeiros sistemas de banco de dados que utilizariam a SQL só surgiram no

início da década de 80 com a empresa Oracle. Esses sistemas capazes de arma-
zenar dados em forma de tabelas e utilizar a linguagem SQL são chamados de
Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDR).
Com o aumento da complexidade dos tipos de dados que precisam ser armazenados nesses
sistemas, como aqueles trabalhados nas áreas da medicina, multimídia, física, entre outras, ao final da
década de 80 as pesquisas em banco de dados são direcionadas para o paradigma da orientação a
objetos.
Por meio da orientação a objetos os métodos de acesso aos dados e a forma de represen-
tação são facilitadas, permitindo que linguagens de programação e Sistemas Gerenciadores de Banco
de Dados Objeto Relacionais (SGBDORs) surgissem, o que possibilitou sistemas de informação mais
avançados.
12
ATENÇÃO: O fato do surgimento dos SGBDORs não eliminou os SGBDs
relacionais, pelo contrário, popularizou ainda mais os princípios relacionais
e adicionou mais poder aos sistemas de armazenamento e manipulação de
dados.
Diante das discussões, até o momento, ainda não ficou claro o que seria um SGBD, seja
relacional ou objeto-relacional.
Um Sistema de Gerenciador de Banco de Dados, relacional ou objeto-relacional, é um
software capaz de armazenar, manipular e aplicar princípios relacionais à organização dos dados.
Possibilita ainda integridade, segurança e controle de acesso a esses dados.
Ao contrário do que muitos alunos acham, o conceito de SGBD é bem diferente de Banco
de Dados (BD). O primeiro (SGBD) é um software, enquanto que o segundo (BD) é uma estrutura
lógica para armazenamento de dados, composta por tabelas que se inter-relacionam visando repre-
sentar a ligação dos dados no mundo real.
O software SQL Server, MySQL, PostgreSQL são SGBDs, enquanto que a

criação de um banco de dados dentro desses softwares possibilita que você
armazene dados de um sistema acadêmico de uma instituição de ensino, por
exemplo. Você cria o Banco de Dados chamado BDUNIS e dentro desse
banco de dados as tabelas que representam os dados no mundo real são criadas e relacionadas,
como: Tabela de Alunos, Professores, Disciplinas, Cursos, etc.
Os estudos que faremos em profundidade nessa disciplina está direcionado a essa criação e
relação de tabelas em um SGBD, a forma como fazemos isso? Como podemos criar essas tabelas
sem que ocorram redundâncias (dados duplicados)? Como relacionar as tabelas de forma que dife-
rentes visões (relatórios) dos dados sejam possíveis?
Esses são questionamentos que buscaremos responder ao longo da disciplina, entre outros
que surgirão. Na sequência, vamos compreender as arquiteturas nas quais um banco de dados pode
ser utilizado.
13
1.2. Arquiteturas de Banco de Dados
Uma das primeiras definições que um administrador de banco de dados, em conjunto com o
Engenheiro de Software e programadores precisa fazer, é a definição da arquitetura do sistema, uma
vez que cada arquitetura implica em diferentes situações. A arquitetura de sistemas que utilizam
banco de dados mais simples existente é a chamada duas camadas.
Nesse tipo de ambiente é instalado um software na máquina de cada cliente e

configura-se, manualmente, o acesso ao banco de dados por meio de tecnolo-
gias como ODBC ou JDBC. Esse tipo de arquitetura é também chamado de
cliente servidor.
Figura 1 – Arquitetura em duas camadas/cliente-servidor
Fonte: MACEDO. Disponível em: http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-n-camadas

Nessa arquitetura o software é instalado no cliente, ou seja, a lógica de negócio (código do
programa) que representa a primeira camada fica no cliente e o acesso ao servidor de banco de
dados (camada dois), onde está instalado o SGBD, é acessado via uma comunicação entre software
e SGBD.
Qual seria o problema dessa arquitetura? Ela é a ideal para todo tipo de orga-
nização?
A arquitetura em duas camadas tem como principal problema o fato de que
cada cliente precisa ter a lógica de negócio e a camada de apresentação (layout)
14
instalado localmente, ou seja, se você tem 100 máquinas, todos os clientes precisam da instalação
e da configuração de acesso ao banco de dados. O mesmo processo pode ocorrer em caso de
atualização.
A próxima arquitetura é a em três camadas, nesse tipo de estrutura temos a inclusão de um

servidor de aplicação.
Figura 2 – Arquitetura em três camadas/cliente-servidor
No modelo em três camadas a lógica de negócio e a camada de apresen-

tação é colocada em um servidor de aplicação e retirada do cliente. Deixa-
se no cliente apenas um atalho para o programa executável do software.
A comunicação com o banco de dados é realizada somente entre o servidor
de aplicação e de banco de dados.
Qual seria o problema com essa arquitetura, uma vez que não temos mais no
cliente a lógica de negócio?
O problema está no fato de que uma simples atualização em layout, lógica de
negócio ou nova validação no sistema obriga a indisponibilidade de todos os
clientes, ou seja, a desconexão de todos para que a atualização no servidor de aplicação aconteça.
A arquitetura em quatro camadas busca resolver os problemas anteriores.
15
Figura 3 – Arquitetura em quatro camadas/cliente-servidor
Na arquitetura em quatro camadas adiciona-se um servidor web na estrutura de hardware

com o objetivo de tirar do servidor de aplicação a camada de apresentação (layout) do cliente, ou
seja, o navegador web passa a ser o software para acesso ao sistema, resolvendo o problema de
atualização na interface e consequente indisponibilidade de todos os clientes. A lógica de negócio
continua no servidor de aplicação, em que este se comunica com o banco de dados.
As quatro camadas seriam: camada de apresentação (servidor web com as

interfaces de usuário), camada de lógica de negócios (servidor de aplicação),
camada de banco de dados (servidor de banco de dados) e o cliente (navega-
dor web).
Apesar de ser uma arquitetura que traz muitas vantagens em relação às demais, eleva o nível
de necessidade de segurança da informação aos sistemas.
Pense a respeito: Hoje em dia, que arquitetura vem dominando as grandes

empresas de software? Como elas estão vendendo os seus sistemas ERP?
16
Resposta: Se analisarmos a atual migração dos softwares para as nuvens temos
uma clara arquitetura em quatro camadas, em que o usuário acessa o seu sis-
tema nas nuvens pelo navegador, não sendo instalado mais nada no lado do
cliente.
Pesquise sobre arquitetura em N camadas. Arquitetura em Cloud Computing.
No próximo tópico vamos compreender o conceito que envolve a propriedade ACID, prin-
cipal estrutura dos sistemas de banco de dados modernos.
1.3. Conceitos e a Propriedade ACID
O sigla ACID é um conceito utilizado em ciência da computação para caracterizar uma tran-
sação (Silberschatz, Korth, & Sudarshan, 2012). ACID é a união das iniciais de:
- Atomicidade
- Consistência
- Isolamento
- Durabilidade
Todo SGBD deve aplicar os conceitos de ACID, pois, caso isso não ocorra, ele
não pode ser considerado um SGBD.
Muita gente, inclusive profissionais da área de tecnologia consideram o Micro-

soft Access como um SGBD, porém, não podemos fazer essa afirmativa, uma
vez que ele não apresenta todos os princípios da propriedade ACID, obrigató-
ria a um SGBD. Vejamos então as características de cada item.
17
Atomicidade
O princípio da atomicidade está relacionado a execução em sua totalidade ou não de uma
transação.
Imagine a seguinte situação: Você está realizando uma transferência bancária e

o sistema da agência bancária cai abruptamente, um SGBD que aplica a pro-
priedade ACID terá duas ações, ou garantir que a operação tenha sido conclu-
ída ou desfaça a transação, a atomicidade é isso. Nunca deixar uma transação
pendente mesmo que ela tenha sido interrompida no meio. Sistemas como o Microsoft Access,
por mais que ele tenha recursos de um SGBD, esse tipo de proteção não é tão eficiente quanto
um SGBD como SQL Server, MySQL ou Oracle por exemplo
Em uma transação atômica, ou se faz tudo ou nada, sem meio termo. Ao incluirmos um
novo cliente no banco de dados ou excluirmos um pedido, essa transação deve ser concluída em
sua totalidade ou ser desfeita, independente do que ocorra durante esse processo. Não deve haver
a possibilidade de que a transação fique no “limbo”.
Consistência
A consistência está relacionada à integridade do banco de dados, ou seja, antes e depois de
cada transação deve ser garantido que ele esteja consistente, íntegro (Date, 2004).
Os SGBDs modernos nos permitem criar mecanismos que evitem problemas de integridade
no banco, por exemplo:
Em uma transação em uma conta bancária, onde o cliente possui um saldo

de R$ 100,00 e for feita uma retirada de R$ 150,00, esta transação não pode
ser concluída, pois a consistência do banco de dados não estaria garantida,
deixando a conta com um saldo negativo. Veremos como criar regras de
consistência em banco de dados nos últimos capítulos deste guia.
Há algumas regras de integridade dos dados que devem ser seguidas como: unicidade de
chaves, restrições de integridade lógica, entre outras.
18
Considere um banco de dados que guarde informações de clientes e que use o
CPF como identificador único (não pode se repetir). Então, qualquer inserção
ou alteração no banco não pode duplicar um CPF (unicidade de chaves) ou
colocar um valor de CPF inválido, como o valor 000.000.000-00 (restrição de
integridade lógica).
Isolamento
O isolamento está relacionado à proteção de manipulação dos dados em transações con-
correntes, ou seja, que ocorrem ao mesmo tempo. Perceba que seria catastrófico duas transações
manipularem o mesmo dado ao mesmo tempo.
O Isolamento objetiva garantir que nenhuma transação seja interferida por outra até que
ela seja completada. A única transação que pode ocorrer ao mesmo tempo sobre exatamente os
mesmos dados são as consultas.
Duas transações são iniciadas, ambas estão ligadas diretamente ao mesmo re-
gistro no banco de dados, a primeira atualizando, a segunda consultando, o
isolamento nos garantirá que a transação de consulta somente será executada
após a transação de atualização ser completada. No ato de consultas, podemos
imaginar um sistema de vendas, no qual o mesmo produto pode ser consultado várias vezes ao
mesmo tempo, visando saber o valor deste.
Podemos ver o princípio do isolamento em dados que não estão em um SGBD quando
duas pessoas abrem um arquivo do Excel compartilhado em rede, para garantir o isolamento,
apenas uma pessoa tem a permissão de escrita, enquanto que a outra só pode ler. O mesmo
acontece no Google Docs ou Sheets, apenas uma pessoa pode manipular uma mesma célula ao
mesmo tempo
Durabilidade
O princípio da durabilidade está relacionado à imutabilidade do dado dentro de um SGBD,
ou seja, o dado deve permanecer sem nenhuma modificação até que uma operação de manipulação
(deleção ou atualização) seja solicitada.
19
Em termos mais populares, podemos dizer que este conceito garante que os dados não
sejam corrompidos, ou seja, desapareçam ou se modifiquem sem motivo aparente.
Esse princípio da imutabilidade era e ainda é um grande problema em sistemas

mais antigos que utilizam arquivos DBASE para armazenar os dados. Nesse
tipo de arquivo, a queda de energia, por exemplo, enquanto uma transação
estava ocorrendo, causava o corrompimento do arquivo do BD e inviabilizava
qualquer acesso. Arquivos do Access também sofrem com esse problema, caso alguém esteja
manipulando o arquivo e a máquina desligue repentinamente, há o corrompimento da base. Há
ferramentas para recuperar, mas o que quero deixar claro é que a propriedade não é aplicada
nesse tipo de sistema, por isso não o considero como um SGBD.
Na sequência vamos compreender alguns conceitos importantes que são tratados em banco
de dados.
1.4. Conceitos em Banco de Dados
O primeiro conceito é a abstração de dados. O principal objetivo de um sistema de banco

de dados é prover os usuários com uma visão abstrata dos dados. Ou seja, deve omitir do usuário
detalhes como a forma que os dados são armazenados e manipulados.
O nível de abstração que cada usuário tem do banco de dados deve ser de acordo com o
seu nível de treinamento e conhecimento daquele sistema. Temos três níveis de abstração: físico,
conceitual/lógico e visão/usuário (Date, 2004). Vamos compreender cada um.
- Nível físico: o nível físico é o mais baixo e descreve como os dados estão armazenados fisica-
mente.
Nesse nível é possível visualizarmos o local onde o arquivo de banco de dados
está armazenado (caminho físico dentro do disco). Geralmente um banco de
dados possui mais de um arquivo físico como, por exemplo, o SQL Server que
sempre cria um arquivo de dados e outro de log. Essa é a estrutura física do
Banco de Dados.
20
- Nível conceitual: o nível conceitual é o que considero como nível do Administrador de Banco
de Dados (DBA), é onde você tem acesso à estrutura lógica do banco de dados. Aqui é onde o
DBA se sente à vontade. Visualiza-se a estrutura de tabelas, restrições e as relações.
- Nível de visão ou de usuário: nesse nível são apresentados os dados já formatados para o usu-
ário, o sistema consulta os dados no banco de dados e os apresenta ao usuário final.
Alguns sistemas permitem que usuários mais avançados utilizem um interpre-

tador de consultas SQL (veremos a seguir), o que possibilita que o usuário
final tenha recursos do nível conceitual. Nem sempre temos essa possibilidade,
visto que exige treinamento por parte dos usuários na linguagem SQL.
Figura 4 – Níveis de abstração
Usuários
Finais
Nível
Externo
Visão externa ... Visão externa
Nível
Conceitual
Esquema Conceitual
Nível
Físico
Esquema interno
BDS Armazenados
Fonte: Adaptado de Elmasri e Navathe (2011), p.16 por Design Unis EAD
Outros termos importantes no contexto de Banco de Dados é o de esquema e instância,

vamos entender a seguir.
21
Instâncias e esquemas
Sabemos que os banco de dados estão em constante mudança devido às operações de
gravação e modificação de dados a todo momento. Dizemos que a coleção de dados armazenados
em determinado momento é chamada de instância do banco de dados (Elmasri & Navathe, 2011)
Dizemos que a instância de um BD é como se fosse a fotografia dele naquele

exato momento.
Já o conceito de esquema está relacionado ao projeto geral de um banco de dados, ou seja,

são as relações entre as tabelas, seus campos e tipos. Podemos dizer que o esquema de um BD não
muda com frequência porque se mudasse você teria um grande retrabalho.
O esquema de um banco de dados pode ser relacionado ao coração de um

sistema de informação. É a forma como tudo será armazenado e relacionado.
Nessa disciplina focaremos muito na criação de um esquema de BD perfeito,
sem erros ou anomalias.
22
Na nossa próxima unidade do guia de estudos vamos conhecer os
tipos de linguagens de banco de dados existentes.
Esse primeiro capítulo teve como objetivo fornecer uma visão geral
do que é um SGBD, um banco de dados e as principais propriedades de que
se aplicam a esses ambientes.

Ao trabalharmos com SGBDs relacionais, devemos atentar para o fato de que tabelas serão
utilizadas para relacionar os dados por meio de campos chave. Essa estrutura é a base do arma-
zenamento de informações nas organizações, apesar de que mudanças já vêm ocorrendo, como
veremos nas últimas unidades desse guia.
Vimos que a propriedade ACID é que caracteriza um software de armazenamento de
dados como um SGBD ou não. A garantia da propriedade ACID assegura o armazenamento dos
dados consistentemente. Ao observarmos os dados em vários níveis de visão, percebemos que
vamos trabalhar, principalmente, nos níveis conceituais e interno, por sermos usuários avançados
de SGBDs.
Vale relembrar alguns termos que farão parte dos nossos estudos, como esquema e instância.
Um projeto de banco de dados pode ser traduzido em linguagem de banco de dados como um
esquema e uma instância, como uma “fotografia” do banco de dados em determinado momento.
Chamo atenção para os nossos estudos sobre as camadas de um sistema computacional,
uma vez que a determinação da arquitetura de um sistema implica diretamente onde estará a
lógica de negócio. Esse tipo de informação, a princípio, parece não ser tão importante porque o
BD continua no mesmo local, mas quando estudarmos recursos avançados de banco de dados
(Unidade 6 e 7) vocês terão a noção do que muda.
Essa foi uma unidade aperitivo, para que vocês se interessem pelo assunto e se dediquem
aos estudos.
23
II Unidade II -
Linguagens de
Banco de Dados
Ao final desta unidade, os alunos aprenderão:
- Compreender e analisar a aplicação dos diferentes tipos de lin-

guagens de banco de dados.
Unidade II - Linguagens de Banco de Dados
2. Introdução
Todos os sistemas gerenciados de banco de dados fornecem dois tipos de linguagens básicas
para as operações de manipulação e definição do banco de dados.
A primeira é conhecida como Linguagem de Definição de Dados (Data Definition Language
– DDL). A segunda é a Linguagem de Manipulação de Dados (Data Manipulation Language – DML).
Atenção, a DDL e a DML NÃO são linguagens separadas, elas são utilizadas em
conjunto por meio da Linguagem de Consultas Estruturadas (Structured Query
Language – SQL). Há ainda a Linguagem de Controle de Dados (Data Control
Language - DCL), que destacarei a seguir.
Todos esses tipos de linguagens são subdivisões de uma linguagem de banco de dados rela-
cionais mãe, chamada SQL (Comentei sobre a SQL no início do nosso guia).
O que diferencia uma linguagem da outra?

RESPOSTA: Somente os tipos de comandos que são aplicados. Vamos enten-
der isso na sequência.
Uma sigla bastante comum dos profissionais de banco de dados e desenvolvedores é a cha-
mada CRUD (acrônimo de Create, Read, Update e Delete em língua Inglesa). Essas são as quatro
operações básicas de manipulação de dados em um Banco de Dados.
Perceba o termo “manipulação”, ele remete a linguagem DML. Ou seja, quando tivermos
qualquer uma dessas quatro operações, estaremos usando a linguagem DML, linguagem de Manipu-
lação de dados. A abreviação CRUD mapeada para o padrão ISO/SQL:
25
- Create - INSERT
- Read (Retrieve) - SELECT
- Update - UPDATE
- Delete (Destroy) - DELETE
2.1. Linguagem de Manipulação de Dados
A linguagem de manipulação de dados (Data Manipulation Language, DML) é a linguagem

que nos permite manipular os dados por meio das quatro operações básicas. Existem dois tipos:
- DMLs procedurais requerem do usuário a especificação de qual dado é necessário e de como

obtê-lo.
Um procedimento armazenado ou Stored Procedure, como chamaremos

mais à frente no guia, é uma DML procedural, porque simula um proce-
dimento de uma linguagem de programação. Sistemas ERPs utilizam larga-
mente esse recurso para automatizar tarefas e aumentar a capacidade de
manipulação de dados em SGBDs.
Figura 5 – Níveis de abstração
Fonte: Elaborado pelo próprio autor
O procedimento armazenado (Stored Procedures – SPs) anterior, pode ser executado den-
tro do SGBD ou chamado pelo programa do usuário de forma a buscar os endereços de uma
26
cidade. No caso, a cidade de Varginha. Mas, pode ser uma variável. As SPs dão esse “poder” ao
Administrador de Banco de Dados, possibilitando que lógicas de negócio sejam criadas dentro do
SGBD. Trataremos desse assunto mais à frente no guia.
- DMLs não-procedurais requerem do usuário a especificação de qual dado é necessário, sem

especificar como obtê-lo.
Exemplo: SELECT * FROM PESSOAS.

DMLs não-procedurais são usualmente mais fáceis de aprender e usar do que
DMLs procedurais. Por isso aprenderemos primeiro as não-procedurais para
que ao final do guia possamos trabalhar com as procedurais.
Lembrando: os comandos que fazem parte da DML são SELECT, UPDATE, DELETE e
INSERT.
A próxima linguagem que vamos estudar é a DDL, ou Linguagem de Definição de Dados.
2.2. Linguagem de Definição de Dados
O termo “definição” remete a criação, estruturação, por isso a DDL está relacionada ao
projeto de banco de dados ou, como nós vimos anteriormente, ao esquema de banco de dados.
O resultado da execução de comandos de uma DDL é um conjunto tabelas que são ar-
mazenadas em um arquivo especial chamado dicionário de dados. Um dicionário de dados é um
arquivo que contém metadados, ou seja, “dados sobre dados”. Este arquivo é consultado antes que
os dados sejam lidos ou modificados no sistema de banco de dados.
Vamos entender o quer dizer tudo isso. Quando criamos um banco de dados e suas tabelas
o SGBD armazena dados de quem criou, em que horário, o que foi criado, quais tipos de dados
foram criados em cada tabela, etc. Isso é chamado de metadados.
Para que você entenda o que sejam metadados, basta você clicar com o botão direito sobre
um arquivo no Windows Explorer e ir na aba propriedades, lá você encontrará dados como o dono
27
do arquivo, permissões, quando foi criado, quando foi modificado, etc. Isso são METADADOS. São
informações sobre uma estrutura de dados, o mesmo acontece com um SGBD, só que os meta-
dados de um SGBD são armazenados no que chamamos de dicionário de dados ou diretório de
dados, como algumas literaturas apresentam.
Assim, a DDL é a responsável por criar, deletar e alterar partes do esquema

de banco de dados, ou seja, na DDL não há manipulação dos dados, mas do
esquema.
Erro comum de muitos alunos que estudam banco de dados: não saber diferenciar os co-
mandos DROP de DELETE.
Explicação: O comando delete é da DML, logo ele só deleta registros, linhas de uma ou mais
tabelas. O delete não apaga uma tabela chamada ALUNOS, por exemplo. Quem apaga uma tabela,
ou seja, uma parte do esquema do banco de dados é o comando da DDL, no caso o DROP (DROP
TABLE ALUNO – apaga a tabela), enquanto que (DELETE FROM ALUNOS – apaga os registros da
tabela alunos, mas mantém a tabela, no caso vazia).
Podemos dizer que a DDL é uma parte da SQL bastante poderosa, porque trabalha no
esquema do banco de dados, permitindo que restrições possam ser impostas.
Lembre-se da propriedade ACID: As principais restrições que podem ser configuradas em
um banco de dados estão relacionadas à integridade dos dados, o I da propriedade ACID.
Restrições de Integridade:
- Restrições de domínio: O termo domínio está relacionado aos possíveis valores que um
campo de uma tabela pode ter.
Quando você configura uma célula no Excel para ser do tipo Moeda, você está configurando
o seu domínio. Os possíveis valores que aquela célula vai ter. O mesmo vale para um campo de
uma tabela no BD. Quando você diz que o campo Idade da tabela ALUNOS será do int (inteiro),
28
você configura o domínio desse campo. Isso é a restrição de domínio! Você pode, por exemplo,
configurar um campo para receber apenas os valores entre 1 e 10, ou V ou F. Você está restringindo
o seu domínio. Veremos mais à frente, no guia, como fazer isso na prática.
- Integridade Referencial: Existem casos em que desejamos garantir que um valor que apare-
ce em uma tabela, para um determinado conjunto de atributos, também apareça para em um certo
conjunto de atributos, em outra tabela.
Essa é uma das restrições mais importantes de um banco de dados relacional, a Integridade
de Referência. O que quer dizer isso? Quando você cria duas tabelas, ALUNOS e CURSO e quer
saber qual aluno está vinculado a qual curso, você cria uma referência entre essas tabelas. O que
aparece em uma tabela também deve aparecer em outra. A integridade de referência é realizada
por meio de chaves (primárias e estrangeiras).
A chave primária (Primary-Key) é uma restrição que diz que, naquela coluna da tabela, só
haverá números diferentes, ou seja, nenhum número se repete naquela coluna. A chave estrangeira
(Foreign Key - FK) é a chave primária na outra tabela.
Vamos ver as duas tabelas, ALUNOS e CURSO, criadas com essas chaves.
Tabela 1 – Tabela de Alunos
MATRICULA (PK) NOME DATANASCIMENTO

0001 Rodrigo Franklin Frogeri 04/04/79
0002 João Marcos Aveia 06/07/1987
0003 Maria Gertrudde 10/07/1999
0004 Joaquim das Neves 25/09/2000
Fonte: Adaptado do autor por Design Unis EAD
29
Tabela 2 – Tabela Curso
ID_CURSO (PK) NOME_CURSO MATRICULA (FK)
1 Ciência da Computação 0001
2 Sistemas de Informação 0002
Análise e Desenvolvimento de
3 0003
Sistemas
5 Análise e Desenvolvimento de
0001
Sistemas
Percebam que as colunas com PK indicam uma chave primária e a coluna com FK indica uma
chave estrangeira. Para que seja possível eu saber qual aluno está em qual curso, eu coloco na tabela
de cursos a chave primária de Alunos (MATRÍCULA). Assim, eu sei que o aluno 0001 faz os cursos
Ciência da Computação e Análise e Desenvolvimento de Sistemas, devido ao vínculo com as chaves.
Perceba a última linha que há a matrícula 0005, mas ela não existe na tabela de ALUNOS, isso é a
INTEGRIDADE DE REFERÊNCIA.
Um banco de dados que implementa essa restrição, NÃO permite que seja inserida uma
chave estrangeira (matricula) que não exista onde ela é chave primária (alunos). Ou seja, a última
linha em vermelho não seria possível existir.
- Assertivas: Assertiva está relacionada a uma validação que podemos colocar no banco de
dados.
Podemos criar uma assertiva que verifique o saldo de um cliente, quando ele for fazer um
saque, se o saque é maior do que o saldo que ele possui em conta o SGBD bloqueará a transação.
Esse tipo de lógica pode ser feito na camada de apresentação do usuário também, mas sendo reali-
zada no SGBD garante uma proteção maior aos dados. Você tem duas vias de proteção.
2.3. Linguagem de Transação de Dados
30
A linguagem de transação de dados (Data Language Transaction – DTL) está relacionada
a manipulação das transações, ou seja, a capacidade de confirmar, desfazer ou delimitar transações
com comandos SQL. Os principais comandos são:
- BEGIN WORK (ou START TRANSACTION, dependendo do SGBD), pode ser usado para
marcar o começo de uma transação de banco de dados, que pode ser completada ou não.
- COMMIT envia todos os dados das mudanças permanentemente.
- ROLLBACK faz com que as mudanças nos dados existentes sejam descartadas.
- COMMIT e ROLLBACK permitem terminar qualquer transação aberta e liberar qualquer blo-
queio ligado a dados.
O uso de commit e rollback é bastante utilizado em DML procedurais para garantir que uma
transação seja efetuada ou que ela seja desfeita, caso algum problema ocorra, princípio da ATOMI-
CIDADE. O commit força uma transação a ser efetivada no banco de dados.
Vou explicar porque isso é necessário:
Quando um comando SQL de inserção é efetuado em um banco de dados, ele não é
efetivamente alterado nos dados que estão fisicamente armazenados, ele é alterado em memória
principal (RAM), para depois ser colocado em memória principal. Quando eu uso o commit eu
“forço” que esses dados sejam diretamente colocados em disco e alterados permanentemente (isso
é chamado de savepoint). Por isso um rollback não vai funcionar depois de um commit. O rollback
desfaz a transação, mas até que os dados estejam em memória principal.
Figura 6 – Commit e Rollback

31
O código apresenta o uso desses recursos. São feitas duas atualizações (UPDATE) e depois
os testes lógicos. Se a operação chegou no SGBD commit, senão rollback. Assim eu consigo garantir
a propriedade da atomicidade.
2.4. Linguagem de Controle de Dados
Outro grupo de linguagem da SQL é a DCL (Data Control Language - Linguagem de Con-
trole de Dados). DCL controla os aspectos de autorização de dados e licenças de usuários, para
controlar quem tem acesso para ver ou manipular dados dentro do banco de dados. Utiliza basica-
mente dois comandos, GRANT e REVOKE.
- GRANT: autoriza ao usuário executar ou realizar operações.

GRANT SELECT, UPDATE ON My_table TO some_user, another_user;
- REVOKE: remove ou restringe a capacidade de um usuário de executar
operações.
REVOKE SELECT, UPDATE ON My_table TO some_user, another_user;
As operações GRANT e REVOKE habilitam ou desabilitam permissões de execução de

comandos DML dos usuários em determinadas tabelas. É bastante utilizado pelo DBA. Para resumir
tudo isso, apresento uma estrutura que junta todas as linguagens.
Figura 7 – Hierarquia SQL
SQL
DDL DML DCL TC
Create, alter,
Insert, update, Grant e
truncate e Save point
delete e select Revoke
drop
32
Nessa unidade trabalhamos as diferentes subdivisões que a linguagem
SQL possui. A linguagem de definição de dados estará sempre relacionada ao
esquema de banco de dados, ou seja, ao seu projeto. Enquanto que a lingua-
gem de manipulação de dados foca na manipulação dos dados, por meio dos
comandos CRUD.
A linguagem de transação será utilizada, principalmente, nas Unidades 6 e 7 deste guia,
quando estudarmos stored procedures e triggers. A linguagem de controle de dados está relacio-
nada a operações do cotidiano de um DBA.
Apesar da SQL ter essas subdivisões, nós trabalharemos com elas em conjunto, como se
fossem uma única linguagem, que na verdade é.
Assunto importante desta unidade é a integridade referencial, recurso este que permite
que os dados estejam relacionados e se mantenham íntegros. Quanto à integridade da referência,
caso não existisse, teríamos sérios problemas para relacionar os dados e garantir que nenhum
dado esteja “perdido” na base de dados.
Essa unidade é bastante conceitual, mas recomendo uma atenção especial, porque vamos
utilizar todos esses conceitos ao longo do guia, da disciplina e do curso.
Fique atento!
33
III Unidade III -
Projeto de Banco
de Dados
Ao final desta unidade, os alunos estudarão:
- Analisar e criar projetos de banco de dados.

Unidade III - Projeto de Banco de Dados
3. Introdução
Um projeto de banco de dados está relacionado ao desenvolvimento do esquema de arma-

zenamento dos dados de um sistema computacional. É por meio do projeto que vamos pensar na
estrutura lógica que será criada dentro SGBD.
Para que seja possível criarmos um projeto de banco de dados, temos que conhecer os
modelos de dados que permitirão esse desenvolvimento.
3.1. Modelos de Dados
Um modelo de dados pode ser definido como uma coleção de tabelas, atributos, domínios
e relações. Um modelo de dados oferece uma maneira de descrever o projeto de um banco de
dados no nível físico, lógico e de view (visualização – usuário) (Silberschatz et al., 2012)
Os modelos de dados podem ser classificados como:
Figura 8 – Diagrama Entidade-Relacionamento - Modelo Relacional: O modelo rela-

cional usa uma coleção de tabelas para
representar os dados e as relações en-
tre elas.
- Modelo Entidade/Relacionamento: O
modelo de entidade/relacionamento
(MER) é baseado em uma percepção
de um mundo real que consiste em
uma coleção de objetos básicos, cha-
mados entidades e as relações entre
Fonte: Arquivo pessoal do autor

esses objetos.
35
Podemos dizer que o MER possui um nível de abstração do projeto de banco de dados mais
alto, ou seja, não são detalhados aspectos técnicos, como no modelo relacional.
Figura 9 – Modelo
Matrícula
(0,N) (1,1)
Alunos Alunos
Lotação Cursos
Nome
AnoIngresso Código
OBSERVAÇÃO: Esse é o modelo que vamos trabalhar com maior intensidade porque, por meio
dele, seremos capazes de criar os demais modelos.
- Modelo de dados orientado a objetos: Ele pode ser visto como uma extensão ao modelo E-R com
noções de encapsulamento, métodos (funções) e identidade de objeto.
Um diagrama de classe da UML é um modelo de dados orientado a objetos. Você perceberá
que o diagrama entidade/relacionamento é muito parecido ao diagrama de classe, a diferença está
no paradigma (princípio) utilizado. O diagrama de classe é especialmente utilizado quando se deseja
realizar o mapeamento objeto-relacional, ou seja, quando eu crio primeiro as classes, para depois
criar as entidades/tabelas.
São dois caminhos que podemos seguir: (1) criar o projeto de banco de dados no modelo
entidade-relacionamento; ou (2) criar o diagrama de classe e, depois, realizar o mapeamento obje-
to-relacional.
Qual a vantagem de um ou de outro?

Tanto um quanto o outro podem levar ao mesmo resultado, podemos tanto criar o MER
e gerar o diagrama de classe, quanto poderemos criar o diagrama de classe e gerar o entidade-re-
lacionamento de um SGBD. Como o diagrama de classe é abordado em outras disciplinas, vamos
36
abordar aqui o MER. O que quero deixar claro é que o profissional precisa conhecer ambas as
abordagens.
3.2. Projeto de Banco de Dados (Passo a Passo)
O projeto de um banco de dados deve seguir alguns passos para ser criado, vamos a eles.
1° Fase: A primeira fase está relacionada ao levantamento de requisitos, você precisa saber o que
deve ser ARMAZENADO, que tipos de dados, quais dados, quantidade de caracteres, etc. Quanto
mais detalhes melhor.
Geralmente, nessa fase, utilizamos relatórios e documentos existentes para conhecer os
dados que serão imputados no sistema.
2° Fase: Na sequência, o projetista ou administrador de banco de dados (DBA), escolhe um modelo

de dados (expliquei os modelos anteriormente).
Aplicando os conceitos do modelo de dados escolhido, traduz essas necessidades em um
esquema conceitual do banco de dados. O esquema desenvolvido nessa fase de projeto conceitual
fornece uma visão geral detalhada da empresa.
Criaremos aqui o modelo conceitual do banco de dados.
3° Fase: O DBA revisa o esquema para confirmar se todas as necessidades de dados estão realmen-
te satisfeitas e se não estão em conflito entre si.
O projetista também pode examinar o projeto para remover quaisquer recursos redundan-
tes. O foco, nesse momento, é descrever os dados e suas relações e não especificar detalhes do
armazenamento físico.
Nesta fase, devemos nos certificar de que todas as tabelas que farão parte do esquema estão
identificadas.
37
4° Fase: O processo de projeto conceitual envolve decisões de quais atributos (colunas/campos)
queremos capturar do banco de dados e de como agrupar esses atributos para formar as várias
tabelas.
Nesta fase utilizamos recursos como a normalização, técnica para evitar a redundância de
dados e anomalias nas relações.
5° Fase: Um esquema conceitual totalmente desenvolvido, também indicará as necessidades funcio-

nais. Os usuários descrevem os tipos de operações (ou transações) que serão realizadas nos dados.
Nessa fase do projeto o projetista pode revisar o esquema, para se certificar de que ele atende as
necessidades funcionais.
O DBA deve ter certeza que, de acordo com o que foi projetado, será possível gerar todos
os relatórios e relações de dados pedidos pelo cliente.
6° Fase: O processo de mudar de um modelo de dados abstrato, para a implementação do banco

de dados, é realizado em duas fases de projeto finais. O esquema conceitual definido é mapeado
para o modelo de dados de implementação do sistema de banco de dados. Logo após, os recursos
físicos do sistema de banco de dados são especificados. Esses recursos é que incluem a forma de
organização de arquivo e as estruturas de armazenamento internas.
De posse do nosso modelo conceitual, vamos gerar o modelo lógico e o modelo físico do
banco de dados, na sequência o modelo físico é executado dentro do SGBD utilizado. Utilizaremos
o software brModelo para criar esses modelos.
No próximo tópico vamos conhecer esses modelos e como criar o projeto do nosso banco
de dados.
3.3. Criando o Projeto de Banco de Dados
Para desenvolvermos o nosso projeto de banco de dados, utilizarei como referência ao livro
de Carlos Alberto Heuser, “Projeto de Banco de Dados” da editora Bookman (Heuser, 2017).
38
O autor utiliza uma notação diferenciada para representar o modelo conceitual, mas que ao
mesmo tempo se assemelha bastante ao diagrama de classe, o que nos permite ter maior facilidade
na compreensão do esquema de banco de dados.
3.3.1. Modelo Relacional
Para compreendermos a criação de um modelo conceitual, precisamos antes compreender

alguns recursos chave, como relações/relacionamentos e mapeamento ou cardinalidade, como al-
guns autores chamam.
Os relacionamentos serão simbolizados sempre por um losango que liga duas entidades/
tabelas. Usamos a expressão entidade sempre em banco de dados relacionais, a partir desse mo-
mento, farei referência a uma tabela somente por meio do termo entidade.
Observe na Figura 10 que o losango “lotação” representa a relação entre as entidades “de-
partamento” e “pessoa”.
Figura 10 – Relacionamento Departamento/Pessoa
No caso de termos duas
entidades se relacionando (é o
Alunos
Departamento Alunos
Lotação Pessoa
mais comum), dizemos que é um
relacionamento binário.
Fonte: Adaptado de Heuser (2017) por Design Unis EAD
Veja agora a Figura 11, em que é apresen- Figura 11 – Relacionamento Unário

tada a relação entre a entidade “Pessoa” com ela
mesma. O objetivo é demonstrar que uma pessoa
PESSOA
pode ser marido e outra pode ser a esposa. Nesse Marido Esposa
caso, temos um auto relacionamento ou unário.
Muitos alunos têm dificuldade em entender
Casamento
esse tipo de relacionamento. Por isso, eu explico
por meio de dados armazenados em uma entidade Fonte: Adaptado de Heuser (2017) por Design
Unis EAD
PESSOA.
39
Tabela 3 – Entidade Pessoa
IdPessoa (PK) NomePessoa DataNascimentoPessoa IdPessoa (FK)
0001 Rodrigo Frogeri 10/05/1985 0004

0002 Joaquim das Couves 05/06/1999 0003
0003 Maria Joana 03/05/2005 0002
0004 Liz Áurea 05/03/1991 0001
Observe que, o fato de ter colocado o auto relacionamento na minha modelagem, diz como
os dados serão relacionados por meio das chaves primárias (PK) e chaves estrangeiras (FK) na minha
tabela.
Como eu sei quem está casando com quem? Basta observar os IdPessoa como
PK e FK. Essa é uma forma correta de identificar esse tipo de relacionamento
em um banco de dados.
ATENÇÃO: Entenda sempre que, quando houver um LOSANGO, você terá
que, obrigatoriamente, utilizar uma chave estrangeira nas entidades envolvidas.
A pergunta é, quando eu tenho duas entidades relacionadas, em qual delas a

chave estrangeira vai ficar? Vamos responder isso na sequência.
Temos que estudar agora um importante conceito de Banco de dados, as res-
trições de mapeamento.
Temos sempre que representar com fidelidade a realidade na forma como os dados serão
armazenados. Uma restrição importante, são as cardinalidades (ou multiplicidade) do mapeamento,
que expressam o número de entidades às quais outra entidade pode estar associada, via um conjun-
to de relacionamentos.
Vamos entender isso!
40
Restrições de mapeamento:
Existem quatro tipos de restrições de mapeamento, um-para-um (a), um-para-muitos (b),
muitos-para-um (c) e muitos-para-muitos (d) (ver Figura 8). O que diferencia cada um, é o local
onde a chave estrangeira será colocada, ou seja, em qual entidade envolvida na relação.
Figura 12 – Restrições de mapeamento
Fonte: Korth e Sudarshan (2011), p. 23

Imagine as seguintes lógicas de negócios de um sistema acadêmico de uma instituição de
ensino.
Lógica 1: Um aluno pode se matricular em, no máximo, um curso e, obrigatoriamente, em um curso.
Isso é uma relação de um para um entre ALUNO e CURSO.
Figura 13 – Lógica 1
(1,1) (1,1)
Alunos
ALUNO Alunos
matrícula CURSO
Quando criamos as cardinalidades no modelo conceitual, temos que dizer a cardinalidade
mínima (direita) e a máxima (esquerda).
41
SEMPRE que eu dizer que, OBRIGATORIAMENTE, algo deve acontecer, a cardinalidade
mínima deve ser um (um do lado direito). Quando eu disser que, opcionalmente, algo pode ocorrer,
a cardinalidade mínima deve ser zero.
Vou mudar a frase que fiz no início: Um aluno pode se matricular em, no máximo, um curso
ou em nenhum.
(1,1) (0,1)
Alunos
ALUNO Alunos
matrícula CURSO

Perceba que a relação Aluno → Curso ficou com a cardinalidade mínima (0, 1) e máxima 1.
No modelo, ainda estou dizendo que um curso deve ter, no máximo, um aluno e, obriga-
toriamente, um (Curso → Aluno | 1,1), o que não é uma realidade para um sistema acadêmico.
Cardinalidade um para um.

Lógica 2: Um aluno pode se matricular em mais de um curso, inclusive em nenhum, e um
curso pode não ter nenhum aluno matriculado, mas no máximo um.
(1,1) (0,n)
Alunos
ALUNO Alunos
matrícula CURSO
Fonte: adaptado do autor por Design Unis EAD
Observe que agora eu tenho o (0, n) do lado de curso, indicando que um aluno pode se
matricular em nenhum curso ou em vários.
A explicação de curso para aluno (0,1) está em dizer que um curso pode ter, no máximo,
um aluno matriculado e, no mínimo, nenhum (0 - mínimo,1 - máximo). Cardinalidade 1 para muitos.
Percebemos que todas as modelagens apresentadas até agora, não satisfazem a realidade de
uma instituição de ensino porque, na maioria dos sistemas, teremos a possibilidade de que um aluno
se matricule em, no máximo, um curso e não seja obrigado a se matricular, podendo ficar no cadas-
42
tro de alunos sem relação com nenhum curso (esse caso acontece quando o aluno faz o vestibular,
mas não se matricula). Outra questão é que um curso sempre deve ter mais de um aluno ou pode
não ter nenhum.
Como ficaria essa modelagem?
(0,n) (0,1)
Alunos
ALUNO Alunos
matrícula CURSO
Nessa modelagem, temos um aluno podendo se matricular a, no máximo, um curso ou
nenhum (0 - nenhum,1 – máximo) e um curso podendo não ter aluno algum matriculado ou vários
(0 – nenhum, n – vários). Cardinalidade muitos para um.
Por fim, podemos ter a possibilidade de que a instituição permita que um aluno se matricule
em vários cursos ou em nenhum e que um curso tenha vários cursos ou nenhum.
(0,n) (0,n)
Alunos
ALUNO Alunos
matrícula CURSO
idMatriculados
Agora chegamos no modelo mais complexo, porque temos uma cardinalidade “muitos
para muitos”, em que SEMPRE será criada uma tabela intermediária entre as entidades, ou seja, o
LOSANGO que representa o relacionamento se transforma em uma tabela em relações “muitos
para muitos”.
Por que isso acontece Prof. Rodrigo?
Para explicar esse fenômeno, vou pegar as tabelas que apresentei anteriormente de ALU-
NO e CURSO.
43
Perceba que, anteriormente, nas tabelas originais, havia uma repetição de
cada curso que o aluno fazia.
Tabela 4 – Tabela de Alunos

Tabela 5 – Tabela Curso
ID_CURSO (PK) NOME_CURSO MATRICULA (FK)
Análise e Desenvolvimento de
3 0003
Sistemas
5 Análise e Desenvolvimento de
0001
Sistemas
Após eu criar o relacionamento “muitos para muitos”, essa redundância acaba. Veja as tabelas
normalizadas.
Tabela 6 – Tabela alunos (normalizada)
44
Tabela 7 – Tabela Cursos (normalizada)
ID_CURSO (PK) NOME_CURSO

1 Ciência da Computação
2 Sistemas de Informação
3 Análise e Desenvolvimento de Sistemas
Tabela 8 – Tabela de Matrículas
idMatriculados (PK) Matricula (FK) ID_Curso (FK)

1 0001 1
2 0001 2
3 0002 3
4 0003 2
5 0004 3
6 0003 1
Perceba o seguinte, SEMPRE a chave estrangeira vai para o lado que estiver o n (muitos). No
caso de um relacionamento “muitos para muitos”, as chaves primárias de Alunos e Cursos irão para
o relacionamento Matrículas, criando assim uma nova tabela. Isso só acontece em relações “muitos
para muitos”, nas demais, a chave estrangeira vai para o lado do muitos (n).
A seguir, apresento o modelo conceitual das tabelas anteriores.
Figura 18 – Modelo conceitual
dataNascimentoAluno
nomeCurso
nomeAluno
ALUNO matrícula CURSO
idMatriculados
matrículaAluno idCurso
45
Aí você me pergunta, onde está a tabela de matrícula professor, com as chaves
estrangeiras?
Eu lhe respondo que, no modelo conceitual tabelas, que são criadas como
origem relacionamentos “muitos para muitos”, NÃO APARECEM. Elas serão
criadas, AUTOMATICAMENTE, no modelo LÓGICO pelo software brModelo.
Bom! Após compreendermos como funciona os relacionamentos e as cardinalidades, já po-

demos partir para a criação dos modelos conceituais lógicos e físico.
3.3.2. Modelo Conceitual
Para estudarmos modelo conceitual, precisamos compreender todos os recursos que o

envolvem. Primeiro, vamos entender os tipos de atributos que podem ser modelados no Modelo
Conceitual. São, basicamente, sete tipos:
- Compostos: Os atributos compostos podem ser divididos em partes menores, ou subpartes, as

quais representariam atributos básicos mais simples com significados independentes.
Um atributo “endereço” pode ser subdividido em rua, cidade, estado e CEP. Poderíamos,
também, dividir o atributo rua em número, nome-rua e número-apartamento. Atributos deste
tipo formam uma hierarquia. Usar atributos compostos em um projeto de banco de dados pode
ser útil quando o usuário desejar se referir a um atributo inteiro em algumas ocasiões e apenas a
parte dele em outras.
- Simples: São chamados, também, por atributos atômicos. Eles não são divisíveis.
- Monovalorados: São atributos que possuem apenas um valor para uma entidade em particular.
A idade é um atributo monovalorado para uma entidade pessoa.
46
- Multivalorado: São atributos que possuem um ou mais valores para o mesmo.
O atributo “idioma” de uma entidade “aluno”, pode conter os valores inglês e francês. Para
um outro aluno poderia conter apenas um valor - espanhol. Para um terceiro aluno, poderíamos
ter 3 valores para este atributo. Um livro que possui várias edições, neste caso, “edições” seria
um atributo multivalorado de “livros”.
- Armazenado: Em geral todos os atributos são armazenados. Valores calculados NÃO devem
ser armazenados em um atributo.
- Derivado: Alguns atributos podem ter uma relação entre si. Por exemplo, idade e data-nasci-
mento de uma pessoa.
Para uma pessoa em particular, podemos determinar o valor atual de idade através do atri-
buto data-nascimento. Então idade é chamado de um atributo derivado e é derivado do atributo
data-nascimento. Alguns atributos podem ser derivados de entidades relacionadas. Por exemplo,
um atributo número-empregados de uma entidade departamento pode ser derivado através da
contagem de número de empregados que trabalham para um departamento. O valor de um
atributo derivado não é armazenado, mas é calculado quando necessário.
- Nulo: Em alguns casos, uma entidade pode não necessitar de um valor aplicável a um de seus
atributos.
Por exemplo, no atributo número-apartamento composto, visto acima, apenas definiremos
valores para este campo quando a entidade pessoa em particular morar em um prédio. Outro
exemplo é o multivalorado idioma de um aluno: caso este aluno em particular não tenha fluência em
nenhuma língua, então não necessitamos preencher o valor deste atributo. A representação de um
atributo sem valor é colocarmos um valor especial null. Null também pode ser utilizado quando não
conhecemos o valor de um atributo, por exemplo, quando se é desconhecida a data de nascimento
de uma pessoa.
Um atributo pode possuir cardinalidade, como é o caso de atributos multivalorados.
47
Um atributo pode possuir cardinalidade de maneira análoga a uma entidade em um relacio-
namento.
A cardinalidade de um atributo define quantos valores deste atributo podem estar associa-
dos a uma ocorrência da entidade/relacionamento a qual ele pertence.
Figura 19 – Cardinalidade
No caso de a cardinalidade ser (1,1), ela
pode ser omitida do diagrama. Assim, o exem-
plo expressa que nome e código são atributos CLIENTE
obrigatórios (cardinalidade mínima “1” – cada
entidade possui no mínimo um valor associado)
e monovalorados (cardinalidade máxima “1” – Telefone(0,n)
cada entidade possui no máximo um valor asso-
código
ciado). Já o atributo telefone, é um atributo op-
cional (cardinalidade mínima 0) e multivalorada nome
(cardinalidade máxima n). Fonte: Adaptado do autor por Design Unis EAD
Atributos em relacionamentos
Um exemplo de um atributo em relacionamento é mostrado na figura abaixo. Este diagra-
ma modela vendas em uma organização comercial. Algumas vendas são à vista, outras são a prazo.
Vendas a prazo são relacionadas a uma financeira, através do relacionamento FINANCIAMENTO.
Os atributos n° parcelas e taxa de juros são atributos do relacionamento.
Figura 20 – Atributo em Relacionamento
Num_parcelas
(0,1) (0,n)
FINANCEIRA FINANCIAMENTO VENDA
Taxa_de_juros
Fonte: Adaptado de Heuser (2017) Design Unis EAD
Estes dois atributos poderiam ter sido incluídos na entidade VENDA. Neste caso, seriam
atributos opcionais, já que nem toda venda é a prazo e possui estes atributos. Assim preferiu-se o
modelo apresentado, exatamente para explicar o fato de os atributos n° parcelas e taxa de juros
48
pertencerem somente a vendas a prazo.
Atente para o fato de que NÃO existirá a entidade FINANCIAMENTO, visto

que a relação entre as entidades é de um para muitos, assim, no modelo ló-
gico, os atributos Num_parcelas e Taxa_de_Juros serão alocados na entidade
Financeira, mas modelagem pode ser feita conforme apresentado.
Relacionamento identificador
Temos casos em que o identificador de uma entidade é composto não somente por atribu-
tos da própria entidade, mas também por relacionamentos dos quais a entidade participa (relacio-
namento identificador).
Um exemplo deste caso é mostrado abaixo. Este modelo envolve empregados de uma or-
ganização, relacionados com os seus dependentes, para fins de imposto de renda. Cada dependente
está relacionado a exatamente um empregado. Um dependente é identificado pelo empregado ao
qual ele está relacionado e por um número de sequência que distingue os diferentes dependentes
de um mesmo empregado. No modelo, o relacionamento usado como identificador é indicado por
uma linha mais densa, conforme mostra a figura abaixo.
Figura 21 – Relacionamento identificador
(1,1) (0,n)
EMPREGADO DEPENDENTE
código nome Numero_seq nome

Fonte: Adaptado de Heuser (2017) Design Unis EAD
No exemplo a seguir é apresentada a divisão de grupos de empresas em empresas e de
empresas em filiais de empresas. Para identificar um grupo de empresas é usado um código. Já uma
empresa é identificada pelo grupo ao qual está relacionada e por um número da empresa dentro do
grupo. Finalmente, uma filial é identificada pela empresa a qual está vinculada e por um número de
filial dentro da empresa. Pela definição acima, tanto EMPRESA quanto FILIAL são entidades fracas.
49
Figura 22 – Divisão de Grupos de Empresas Uma entidade fraca é aquela que depende de
outra para existir. As entidades fracas podem ser re-
GRUPO código
presentadas por linhas sólidas no relacionamento. No
(1,1) exemplo a entidade EMPRESA só existe, se antes existir
GRUPO e FILIAL só existe, se antes existir EMPRESA.
(1,n)
EMPREGADO Número_empresa Generalização/Especialização

Além de relacionamentos e atributos, proprie-
(1,1)
dades podem ser atribuídas a entidades através do con-
(0,n) ceito de generalização/especialização. Através desse
Número_filial
conceito, é possível atribuir propriedades a um subcon-
EMPREGADO
FILIAL
junto das ocorrências (especializadas) de uma entidade
genérica. No modelo conceitual, para representar uma
generalização/especialização é usado um triângulo isósceles.
Figura 23 – Divisão de Grupos de Empresas Ao lado está sendo modelado que a enti-
dade CLIENTE está subdividida em dois subcon-
(0,n) (0,n) juntos, PESSOA FÍSICA e PESSOA JURÍDICA.
Alunos
ALUNO CLIENTE
Associada ao conceito de generalização/especia-
lização está a ideia de herança de propriedades.
PESSOA PESSOA
FÍSICA JURÍDICA
Exemplo: A entidade PESSOA FISICA possui,
CIC Sexo CGC Tipo de
além de seus atributos, CIC e SEXO, possui tam-

organização
bém NOME e CÓDIGO da entidade CLIENTE.

Entidade Associativa
No modelo entidade-relacionamento não foi prevista a possibilidade de associar dois rela-
cionamentos. Observe o modelo a seguir:
50
Figura 24 – Entidade associativa (modelos muitos para muitos)
n n
MÉDICO CONSULTA PACIENTE
Fonte: Adaptado de Heuser (2017) por Design Unis EAD
Analise a situação a seguir:
Suponha que tenhamos que modificar esse modelo para saber os medicamentos que são
prescritos em cada consulta. Ok! Para isso, podemos criar uma nova entidade medicamen-
to, mas a questão é, com que entidade ela vai se relacionar?
Caso se relacionasse com MÉDICO, eu saberia apenas qual médico prescreveu qual me-
dicamento, mas não saberia para qual paciente e em qual consulta, se eu fizer a relação
com PACIENTE, eu só saberei qual paciente teve prescrito determinado medicamento. O
ideal é relacionar o medicamento a uma consulta. Nesse caso, lançamos mão do recurso
de Entidade Associativa, ou seja, ela possibilita que uma relação/relacionamento seja vista
como uma entidade e possa se relacionar a outra entidade.
Adaptado de Heuser (2017)

Nesse caso teríamos a seguinte modelagem.
Figura 25 – Entidade associativa
n
n
MÉDICO CONSULTA PACIENTE
PRESCRIÇÃO
MEDICAMENTO
Fonte: Adaptado de Heuser (2017), p. 60. por Design Unis EAD
51
Poderia também fazer a mesma modelagem, modificando a relação consulta por uma enti-
dade, da seguinte forma:
Figura 26 – Entidade associativa modificada
MÉDICO PACIENTE
(1,1) (1,1)
n n
CONSULTA
PRESCRIÇÃO
MEDICAMENTO

Bom! Conhecidos todos os recursos possíveis de um Modelo Conceitual, vamos criar um
modelo nosso.
Conforme mencionado, o modelo conceitual tem uma abstração dos dados bem alta, ou
seja, a modelagem omite muitos detalhes que só serão exibidos no modelo lógico.
O motivo para isso é que o modelo conceitual pode ser mostrado ao usuário final ou
stakeholder para avaliar se os dados estão corretamente relacionados. Porém, nem sempre é viável
mostrar esse modelo, a não ser que o usuário tenha um nível de compreensão da relação dos dados
maior.
Para criarmos o nosso modelo lógico, faremos uso do software brModelo, já discutido ante-
riormente (sugiro assistir a aula prática sobre brModelo).
52
Estudo de Caso
Deseja-se modelar parte de um sistema acadêmico de uma instituição chamada

ALUNOMAISVOCÊ.
As regras de negócio são apresentadas a seguir:
Cada disciplina possui exatamente um departamento responsável e um departamento é
responsável por muitas disciplinas, inclusive por nenhuma.
Note-se que: Apesar de sabermos que os departamentos em uma universidade existem para serem res-
ponsáveis por disciplinas, especificamos a cardinalidade mínima de DEPARTAMENTO em RESPONSÁVEL
como sendo “0”. Com isto admitimos a possibilidade de existirem departamentos vazios. Esta cardinalidade
foi especificada considerando o estado do banco de dados imediatamente após a criação de um novo de-
partamento. Da forma como a restrição foi especificada, é possível incluir o departamento em uma transação
para, depois, em transações subsequentes vinculá-lo às disciplinas sob sua responsabilidade. Se tivesse sido
especificada a cardinalidade mínima “1”, ao menos uma disciplina teria que ser vinculada ao departamento já
na própria transação de inclusão do departamento.
Como observa-se da discussão acima, para especificar as cardinalidades mínimas, é necessário possuir
conhecimento sobre a ordem de execução das transações de inclusão e exclusão de entidades.
- Uma disciplina pode possuir diversos pré-requisitos, inclusive nenhum. Uma disciplina pode ser pré-re-
quisito de muitas outras disciplinas, inclusive de nenhuma.
- Uma disciplina pode aparecer no currículo de muitos cursos (inclusive de nenhum) e um curso pode
possuir muitas disciplinas em seu currículo (inclusive nenhuma).
- Um aluno está inscrito em exatamente um curso e um curso pode ser nele inscritos muitos alunos (in-
clusive nenhum).
Adaptado de Heuser (2017)
O modelo conceitual do estudo de caso é apresentado a seguir. Perceba os significados dos
relacionamentos. Todos eles devem representar exatamente a lógica de negócio descrita anterior-
mente.
Figura 27 – Modelo Conceitual
Pré-Requisito
Liberadora (0,n)
(0,n) Liberada
(0,n) (0,n)
DEPARTAMENTO Responsável DISCIPLINA
(0,n)
Disc-Curso
(0,n)
(0,n) (1,1)
ALUNO Responsável CURSO

Gerado o modelo conceitual, vamos criar o modelo lógico correspondente, mas antes te-
mos que estudar sobre atributos e seus domínios.
3.3.3. Modelo Lógico
Os atributos podem ser relacionados a colunas em uma tabela, como estamos no mundo
relacional, um atributo é parte de uma entidade.
Cada atributo tem um domínio correspondente, ou seja, cada coluna terá uma
faixa de valores possíveis. ATENÇÃO: Os atributos que você deve especificar
estão relacionados ao SGBD que você irá utilizar. O que isso significa? Que, se
você for utilizar o SGBD SQL Server, você tem que conhecer os domínios que
podem ser colocados nos atributos. O mesmo vale para o MySQL, PostgreSQL e outros. Isso é
necessário para que o seu modelo físico seja gerado com sucesso.
54
Perceba que no nosso modelo conceitual anterior que não temos sequer um atributo, o que
inviabiliza a geração do modelo lógico.
Lembre-se que os atributos deverão ser identificados de acordo com o levantamento de
requisitos com o usuário e não vir da sua cabeça.
Para o nosso exemplo vou colocar atributos básicos nas entidades e considerar os domínios
2
de atributos disponíveis no SQL Server 2016 .
Figura 28 – Modelo Conceitual com atributos
PREREQUISITOS
nomeDepartamento
Liberada (0,n) idPreRequisito
idDepartamento
(0,n) Liberada
(0,n) (0,n) idDisciplina

Departamento Responsável Disciplina nomeDisciplina
idResponsável
Disc-Curso
(0,n)
idCurso
(0,n) (1,1) CURSO nomeCurso
ALUNO matrícula
idAluno
nomeAluno

Pontos importantes a serem considerados no modelo apresentado:
- As bolinhas azuis indicam campos que são chave primária e estão configurados com o tipo
smallint do SQL Server.
- Os nomes estão configurados com os tipos varchar (50);
- Sempre coloque uma chave primária em um relacionamento muitos para muitos, visto que ele
se transformará em uma tabela no modelo lógico.
Vamos observar agora o modelo lógico criado pelo software brModelo com base no mode-
lo conceitual apresentado na Figura 29.
2 Tipos de dados (Transact-SQL): Disponível em: <https://docs.microsoft.com/pt-br/sql/t-sql/data-types/data-types-tran-

sact-sql?view=sql-server-2017>. Acesso em: 6. maio. 2018. 55
Figura 29 – Modelo lógico do estudo de caso
Percebam que o modelo lógico é mais detalhado em termos técnicos do que

o modelo conceitual, essa é justamente a ideia. O modelo lógico está no nível
de visão de um DBA, enquanto que o conceitual no nível de visão do usuário,
apesar do usuário não criar um modelo conceitual.
O passo seguinte é a geração do modelo físico, também realizado automaticamente pelo

software brModelo.
3.3.4. Modelo Físico
O modelo físico é a utilização de comandos da DDL para a criação do esquema de banco
56
de dados, ou seja, o brModelo utiliza a modelagem gráfica apresentada e converte para comandos
DDL do padrão ISO/SQL.
Figura 30 - Linha de código 1: Modelo físico do estudo de caso

57
Não se preocupe nesse momento em entender todos os comandos que foram gerados,
gostaria apenas que você observasse que, a partir da criação do modelo conceitual, nós consegui-
mos gerar o modelo lógico e com ele o modelo físico, faltando apenas executar esses comandos
dentro do SGBD Sql Server.
Por isso, vamos focar os nossos estudos no desenvolvimento de um modelo conceitual per-
feito, a próxima unidade nos ajudará nessa tarefa, fornecendo as formas normais (normalização) de
uma estrutura de banco de dados.
Essa é a unidade que considero mais importante da nossa disciplina,

por isso ela é bem mais longa do que as demais. Tudo que estudaremos daqui
para a frente dependerá do conhecimento que você adquiriu nessa unidade.
Por isso, recomendo que, se ficou alguma dúvida, releia o conteúdo e entre
em contato com o professor.
Construir um projeto de banco de dados é uma arte, não é algo tão simples quanto pa-
rece e nem muito difícil, mas exige atenção e conhecimento do que se está fazendo.
Podemos perceber que, se você conseguir modelar um projeto conceitual de banco de
dados bem feito, os demais passos se tornarão extremamente simples de serem executados. Por
isso, foco no modelo conceitual!
Vimos também que, a modelagem de um banco de dados é realizada por meio de vários
detalhes do mundo real. Assim, sugiro que você, ao modelar um banco de dados, entenda em
profundidade o ambiente ao qual se está trabalhando. Ficará muito mais fácil a modelagem!
A próxima unidade de nosso guia fornecerá conceitos importantíssimos para que possa-
mos construir bancos de dados consistentes, íntegros e livres de anomalias.
Vamos lá!
58
IV
Unidade IV -
Normalização de
projetos de
banco de dados
- Analisar projetos de banco de dados e aplicar os princípios de

normalização de entidades.
Unidade IV - Normalização de Projetos de Banco de Dados
4. Introdução
Antes de estudarmos as formas normais, vamos compreender alguns conceitos básicos. O

primeiro deles se chama dependência funcional e é a base da normalização de dados.
Dependência funcional
O Modelo Relacional pegou emprestado da teoria de funções da matemática o conceito de

dependência funcional.
Observe na figura ao lado que existe uma Figura 31 – Dependência CPF x Nome
dependência entre os valores dos conjuntos, que
CPF Nome
pode ser expressa pela relação CPF -> nome. Ou
seja, se eu tenho o CPF eu consigo saber o nome.
Essa é a ideia de dependência funcional, a partir 1 José
do momento que os meus dados estão relacionados 2 João

por meio de chaves primárias e estrangeiras eu 3 Rui
consigo acessar os dados usando a dependência 4 Manuel
funcional (pela chave eu chego aos demais atributos).
Vamos observar a “Planilha de Pedidos”
Fonte: Adaptado do Autor por Design Unis EaD
apresentada a seguir, para compreendermos o que é
a dependência funcional em uma estrutura de banco de dados não normalizada.
60
Figura 32 – Planilha de pedidos
CONTROLEDEPEDIDOS
idProduto nomeProduto idPedido dataPedido qtdePedido valorUnitarioProduto valorTotalPedido numeroNotaFiscal idCliente nomeCliente idVendedor nomeVendedor
1 Arroz 1 10-Oct 5 R$6,30 R$31,50 01256988 1 José Maria 1 Rodrigo
2 Feijão 1 10-Oct 2 R$4,20 R$8,40 01256988 1 José Maria 1 Rodrigo
3 Macarrão 2 5-Jun 9 R$3,90 R$35,10 05479526 2 Amâncio Junior 2 Jones Clay
4 Pipoca 2 5-Jun 4 R$2,80 R$11,20 05479526 2 Amâncio Junior 2 Jones Clay
1 Arroz 2 5-Jun 8 R$6,30 R$50,40 05479526 2 Amâncio Junior 2 Jones Clay
2 Feijão 3 9-Sep 6 R$4,20 R$25,20 0326547 3 Ted Bill 1 Geizer Gilson
3 Macarrão 4 15-Jan 8 R$3,90 R$31,20 01478963 3 Ted Bill 3 Joclesley
4 Pipoca 4 15-Jan 2 R$2,80 R$5,60 01478963 3 Ted Bill 3 Joclesley
2 Feijão 4 15-Jan 5 R$4,20 R$21,00 01478963 4 Maria Claudete 3 Joclesley
3 Macarrão 5 28-Dec 12 R$3,90 R$46,80 025874110 4 Maria Claudete 3 Joclesley
4 Pipoca 5 28-Dec 1 R$2,80 R$2,80 025874110 4 Maria Claudete 3 Joclesley
Observe na planilha que eu tenho dados referentes ao Pedido (idpedido, qtdePedido, valor-
TotalPedido, numeroNotaFIscal), dados do Produto (idProduto, nomeProduto, valorUnitarioProdu-
to), dados de quem fez a Venda e do Vendedor (idVendedor, nomeVendedor).
De acordo com a teoria da dependência funcional, por meio de um campo

chave eu consigo acesso a todos os outros campos relacionados. Porém, na
forma como os dados estão organizados, se eu pegar o idProduto igual a 1,
terei como retorno pelo menos duas linhas da planilha, o que não é a regra da
dependência funcional. Quando eu seleciono um atributo que outros dependem dele o retorno
deve ser uma única linha, caso contrário há anomalias nos meus dados. O mesmo ocorrerá se
eu pegar o código de um vendedor ou o código de um pedido.
Nesse momento que surge o recurso de normalização de dados ou formas normais, o ob-
jetivo é retirar essas anomalias permitindo que haja dependência funcional entres os dados.
61
4.1. Formas Normais
A normalização de dados foi proposta por E. F. Codd em 1972. Inicialmente foram criadas
três formas normais, chamando-as de:
- Primeira forma normal (1NF);
- Segunda forma normal (2NF);
- Terceira forma normal (3NF).
A ideia do processo de normalização é substituir um conjunto de

entidades (tabelas) e relacionamento anômalos (com anomalias de atualiza-
ção, inclusão, alteração e exclusão) por outros “purificados” ou normalizados
como vamos chamar.
Os principais problemas ocasionados por dados não normalizados são:
- Grupos repetitivos (atributos multivalorados) de dados;

- Variação temporal de certos atributos, dependências funcionais totais ou parciais em relação a
uma chave concatenada;
- Redundâncias de dados desnecessários;
- Perdas acidentais de informação;
- Dificuldade na representação de fatos da realidade observada;
- Dependências transitivas entre atributos.

Calma! Vou explicar cada um deles. Observe novamente a nossa planilha do Excel.
62
CONTROLEDEPEDIDOS
idProduto nomeProduto idPedido dataPedido qtdePedido valorUnitarioProduto valorTotalPedido numeroNotaFiscal idCliente nomeCliente idVendedor nomeVendedor
1 Arroz 1 10-Oct 5 R$6,30 R$31,50 01256988 1 José Maria 1 Rodrigo
2 Feijão 1 10-Oct 2 R$4,20 R$8,40 01256988 1 José Maria 1 Rodrigo
3 Macarrão 2 5-Jun 9 R$3,90 R$35,10 05479526 2 Amâncio Junior 2 Jones Clay
4 Pipoca 2 5-Jun 4 R$2,80 R$11,20 05479526 2 Amâncio Junior 2 Jones Clay
1 Arroz 2 5-Jun 8 R$6,30 R$50,40 05479526 2 Amâncio Junior 2 Jones Clay
2 Feijão 3 9-Sep 6 R$4,20 R$25,20 0326547 3 Ted Bill 1 Geizer Gilson
3 Macarrão 4 15-Jan 8 R$3,90 R$31,20 01478963 3 Ted Bill 3 Joclesley
4 Pipoca 4 15-Jan 2 R$2,80 R$5,60 01478963 3 Ted Bill 3 Joclesley
2 Feijão 4 15-Jan 5 R$4,20 R$21,00 01478963 4 Maria Claudete 3 Joclesley
4 Pipoca 5 28-Dec 1 R$2,80 R$2,80 025874110 4 Maria Claudete 3 Joclesley
- Anomalia de inclusão: para que seja possível incluir um cliente novo, obrigatoriamente eu teria
que vinculá-lo a um pedido, a um produto no mínimo e a um vendedor. Não faz sentido!
- Anomalia de exclusão: se eu precisar excluir uma linha e ela for a única em que aparece um
produto, esse produto simplesmente deixa de existir no cadastro.
- Anomalia de alteração: caso eu necessite alterar o nome de um cliente, teria que percorrer toda
a planilha procurando por aquele nome, alterando um a um.
Entendido os problemas com dados anômalos, vamos compreender o processo de norma-

lização. Atente para as seguintes observações:
- Normalização de relações é uma técnica que permite depurar um projeto de

banco de dados, por meio da identificação de inconsistências (informações em
duplicidade, dependências funcionais mal resolvidas, etc.).
- À medida que um conjunto de relações passa para uma forma normal, vamos
construindo um banco de dados mais confiável.
- O objetivo da normalização não é eliminar todos as inconsistências, e sim controlá-las.
4.1.1. Primeira Forma Normal (1NF)

63
“Uma relação está na primeira forma normal, se todos os seus atributos são monovalorados
e atômicos”.
O que é um atributo atômico?

Aquele que não pode ser dividido em partes menores, ou seja, um
endereço completo em um campo é não-atômico porque pode ser dividido
em estado, bairro, rua, número, etc.
O que é um atributo monovalorado?

É aquele atributo que comporta ou armazena apenas um valor relacio-
nado a aquele assunto.
Exemplo: O campo Idioma em um cadastro, se for permitido que o
sujeito coloque que ele fala português, inglês e espanhol no mesmo campo, ele se torna MUL-
TIVALORADO, vários valores do mesmo assunto no mesmo campo.
O que devo fazer quando encontrar um atributo multivalorado?
Quando encontrarmos um atributo multivalorado, deve-se criar um novo atributo que in-
dividualize a informação que esta multivalorada. Exemplo, considere a entidade Boletim com os
atributos matricula-aluno, disciplina e notas.
BOLETIM = {matriculaAluno, disciplinaBoletim, notasBoletim}
Você concorda comigo, que uma mesma disciplina pode ter várias notas relacionadas? Ok!
Então é campo multivalorado.
64
No caso, cada nota seria individualizada, identificando a prova a qual aquela nota se refere.
BOLETIM = {matriculaAluno, disciplinaBoletim, numeroProvaBoletim, notaBoletim}
Quando encontrarmos um atributo não atômico, deve-se dividi-lo em outros atributos que
sejam atômicos (não podem ser subdivididos). Observe a entidade Pessoa com os atributos CPF e
nome completo.

PESSOA = {cpfPessoa, nomeCompletoPessoa}
Vamos supor que, para a aplicação que utilizará esta relação, o atributo nome completo não
é atômico, a solução então será:
PESSOA = {cpfPessoa, primeiroNomePessoa, segundoNomePessoa}
Eu faço a divisão do atributo não-atômico em partes até que ele se

torne atômico.
4.1.2. Segunda Forma Normal
Uma relação está na segunda forma normal quando duas condições são satisfeitas:
- A relação estiver na primeira forma normal;
- Todos os atributos primos dependerem funcionalmente de toda a chave primária.
Vamos entender a 2NF, observe a entidade Boletim a seguir:
BOLETIM = {matriculaAluno, codigoDisciplina, numeroProva, notaProva, dataProva, nomeAluno,

endereçoAluno, nomeDisciplina}
Agora que já sabemos o que é dependência funcional (DF), chegou a hora de aplicarmos.
65
Para fazermos a dependência funcional, pegue um campo que é código ou uma possível cha-
ve primária (valor que não se repete) e coloque à esquerda, observe que outros campos dependem
dele.
Ou seja, por meio daquele campo chave você chega nos demais. É bem simples, separe os
campos por assuntos que são relacionados, o próprio nome dos campos já nos ajuda.
Observe as dependências funcionais para a entidade Boletim.
(1) matriculaAluno, codigoDisciplina, numeroProva -> notaProva

(2) codigoDisciplina, numeroProva -> dataProva
(3) matriculaAluno -> nomeAluno, endereçoAluno
(4) codigoDisciplina -> nomeDisciplina
Perceba que na dependência funcional (1), para que eu saiba uma ÚNICA nota (tenha como
retorno uma única linha) eu preciso de três campos, saber qual é o aluno, qual a disciplina e qual é
prova, caso contrário, terei o retorno de várias notas.
Na DF (2) com a disciplina e o número da prova eu chego na data de uma determinada pro-
va. Na (3) e (4), basta que eu saiba, respectivamente, a matricula do aluno e o código da disciplina.
Ao finalizar a 2NF devemos criar as entidades correspondentes às DFs, veja a seguir:
- BOLETIM = {matriculaAluno, codigoDisciplina, numeroProva, notaProva}

- PROVA = {codigoDisciplina, numeroProva, dataProva}
- ALUNO = {matriculaAluno, nomeAluno, endereçoAluno}
- DISCIPLINA = {codigoDisciplina, nome-Disciplina}
O nome das novas entidades deve ser escolhido de acordo com a chave e os campos subli-
nhados são chaves primárias.
66
Figura 33 – Planilha de pedidos
matriculaAluno codigoDisciplina numeroProva Nota Válido?

0001 1 1 8 SIM
0001 1 1 9 NÃO
0001 3 3 10 SIM
0002 1 1 6 SIM
0003 1 1 6 SIM
0003 2 1 7 SIM
Observe que a linha inválida pertence a um registro que repetiu a matricula do aluno, o
código da disciplina e o número da prova. No caso de chaves primárias compostas a violação só
acontece quando os três campos são afetados em conjunto.
4.1.3. Terceira Forma Normal
Podemos dizer que uma entidade está na terceira forma normal quando duas condições
forem satisfeitas:
1. A relação estiver na segunda forma normal;

2. E todos os atributos primos dependerem não transitivamente de toda a chave primária.
Vamos entender isso! ;)
Observe a entidade Pedido a seguir:
PEDIDO = {numeroPedido, codigoCliente, dataPedido, nomeCliente,codigoCidadeCliente, nome-

CidadeCliente}
Fazendo a análise da dependência funcional de cada atributo primo (aqueles atributos que
não são chave primária), chegamos às seguintes dependências funcionais:
67
- numeroPedido -> codigoCliente
- numeroPedido -> dataPedido
- codigoCliente -> nomeCliente
- codigoCliente -> codigoCidadeCliente
- codigoCidadeCliente -> nomeCidadeCliente
Observe que, se com o número de pedido eu chego no código do cliente, logo com o có-
digo do cliente eu chego no código da cidade do cliente e na sequência na cidade.

Observe:
- numeroPedido -> codigoCliente -> nomeCliente
- numeroPedido -> codigoCliente -> codigoCidadeCliente
- numeroPedido -> codigoCliente -> codigoCidadeCliente -> nomeCidadeCliente
Isso é dependência transitiva, ou seja, eu tenha chaves dependendo de

chaves, ou em outras palavras e considerando o exemplo, o campo número
do pedido que seria a chave primaria da entidade Pedido tem todos os demais
campos, que não são chaves dependendo dele.
RESUMO: Na 3NF eu NÃO POSSO TER campos que não são chave depen-
dendo um do outro.
Devemos resolver, inicialmente, as dependências mais simples, criando uma nova relação
onde codigoCliente é a chave. O codigoCliente continuará na relação PEDIDO como atributo pri-
68
mo, porém, os atributos que dependem dele, devem ser transferidos para uma nova entidade.
- PEDIDO = {numeroPedido, codigoCliente, dataPedido}

- CLIENTE = {codigoCliente, nomeCliente, codigoCidadeCliente, nomeCidadeCliente}
As dependências transitivas da relação PEDIDO foram eliminadas, porém ainda devemos
analisar a nova relação CLIENTE.
codigoCliente -> codigoCidadeCliente -> nomeCidadeCliente
Observe que o nome-cidade-cliente continua com uma dependência transitiva (depende do

campo chave codigoCidadeCliente), vamos resolvê-la da mesma maneira:
- PEDIDO = {numeroPedido, codigoCliente, dataPedido}

- CLIENTE = {codigoCliente, nomeCliente, codigoCidadeCliente}
- CIDADE = {codigoCidadeCliente, nomeCidadeCliente}
As entidades acima são a finalização da aplicação da 3NF. O nome das novas relações deve
ser escolhido de acordo com a chave.
69
Esta unidade teve como foco, a principal norma aplicável a projetos de
banco de dados, ou seja, a normalização. Todo profissional desenvolvedor de
sistemas de informação deve dominar em sua totalidade a aplicação de pelo
menos as três formas normais que apresentei.
Algumas literaturas apresentam até a quinta forma normal, mas posso lhes garantir que se
aplicar de forma consistente as três primeiras, dificilmente precisará das demais.
No primeiro contato que temos com essas normas, elas parecem difíceis e impossíveis de
serem compreendidas, mas posso lhes garantir que é só no começo, à medida que as atividades
forem sendo realizadas ficará tudo mais simples. ;)
Não deixe estudar e rever essas normas, visto que elas lhes acompanharão pelo resto da
vida.
Na próxima unidade saímos do projeto de banco de dados e vamos para a manipulação
desse projeto, ou seja, conhecer a linguagem que nos permite criar as estruturas e manipular os
dados.
70
V
Unidade V -
Linguagem
de consultas
estruturadas (SQL)
- Compreender, analisar e criar consultas em sistemas gerencia-

dores de banco de dados.
Unidade V - Linguagem de Consultas Estruturadas (SQL)
5. Introdução
A linguagem de consultas estruturadas (SQL) surgiu junto com o modelo relacional de Boyce
Codd na década de 70. A ideia era possibilitar que a busca pelos dados pudesse ser feita por meio
de uma escrita natural na língua inglesa.
Desde então a linguagem SQL é o padrão de comunicação entre DBAs e usuários avança-
dos de SGBDs para manipular dados armazenados em sistemas de banco de dados. Cada empresa
desenvolvedora de SGBDs cria o seu próprio conjunto de comandos SQL, sendo que há um padrão
mundial (ANSI) que todos seguem, o que permite que a maioria dos comandos funcionem em qual-
quer SGBD do mercado.
O SQL Server da Microsoft utiliza a linguagem chamada T-SQL, enquanto que o Oracle
utiliza a PL-SQL, mas a pergunta é: o que diferencia um do outro?
A resposta está nos comandos avançados e recursos que cada SGBD possui, como nem
todos possuem as mesmas funcionalidades, obviamente não terão os mesmos comandos.
Felizmente, os comandos de manipulação e consulta de dados são iguais para qualquer
SGBD (INSERT, UPDATE, DELETE e SELECT).
Vamos entender isso na sequência do guia. ;)
5.1. Estruturas Básicas da SQL
Vamos começar pela instrução mais simples da SQL, a consulta (SELECT). Uma expressão
básica em SQL consiste em três cláusulas: SELECT, FROM e WHERE.
Quando utilizamos uma consulta (SELECT) em uma base de dados desejamos que seja re-
tornado determinados atributos e uma sequência de linhas (também chamada de tuplas), podemos
ainda colocar condições no retorno de dados que desejamos.
Nas próximas consultas vou utilizar a tabela “Customers – Clientes” da base de dados Nor-
thwind disponibilizado pela Microsoft. Todas as consultas são executadas no SQL Server.
72
SELECT [CustomerID],[CompanyName], [ContactName] ,[ContactTitle]
,[Address],[City],[Region],[PostalCode],[Country],[Phone],[Fax]
FROM [Customers]
Observação: A utilização dos colchetes é opcional.

No caso a tabela Customers possui 11 atributos, sendo que a chave prim´ria é o atri-
buto CustomerID.
O retorno da consulta é apresentado a seguir. Apresento apenas parte da consulta porque

a tabela possui 91 registros.
Figura 34 – Parte da consulta
Fonte: Arquivo Pessoal do Autor
Muitas vezes a nossa consulta SQL retorna valores repetidos, de acordo com os parâmetros
que utilizamos, caso você deseje omitir as tuplas repetidas, basta usar o comando DISTINCT.
Para exemplificar o distinct fiz a consulta “SELECT City FROM Customers”, ou seja, listei
apenas as cidades dos clientes.
73
SELECT DISTINCT City
SELECT City FROM Customers
FROM Customers
- 91 linhas de retorno
- 69 linhas de retorno
74
Perceba que as repetições foram removidas da saída da consulta. “Buenos Aires”, por exem-
plo, que aparecia três vezes foi removida.
Outro caráter importante em um comando SQL de consulta é asterisco “*”, uma vez que
ele permite a omissão de todos os atributos de uma tabela, bastando que eu coloque *.
SELECT * FROM Customers
O uso dos * permite que a gente omita todos os campos de uma

tabela.
Comando bastante utilizado em conjunto com o SELECT é o AS, que permite darmos
um “apelido” para um atributo. Muitas vezes os nomes dos atributos que estão armazenados
no SGBD não são muito intuitivos, o que nos leva a renomeá-los.
SELECT City AS Cidade

FROM Customers
Perceba que o cabeçalho da coluna, ao in-

vés de apresentar City apresenta Cidade.
75
A cláusula WHERE corresponde a uma condição. Pode conter
expressões aritméticas envolvendo os operadores de comparação <, <=,
>, >=, = e <>, e operandos constantes ou atributos das tuplas.
Em SQL, nessa cláusula podem-se usar os conectores lógicos AND, OR
e NOT. SQL possui o operador de comparação BETWEEN AND para simplificar a cláusula
where que especifica que um valor pode ser menor ou igual a algum valor e maior ou igual a
algum outro valor.
W HERE OR AN D
SELECT* SELECT * SELECT*
FROM [Customers] FROM [Customers] FROM [Customers]
WHEREcity = 'Sao Paulo' WHEREcity = 'Sao Paulo' WHERE city = 'Sao Paulo' AND
OR Country = 'Brazil'
city = 'Campinas'
76
Temos a possibilidade também de trabalharmos com compara-
ções de strings, LIKE e NOT LIKE. Permitindo que possamos recuperar
linhas com base em apenas alguns caracteres da string.
LIKE NOT LIKE MÁSCARA (%)

SELECT * SELECT * SELECT *
WHEREcountry LIKE'Brazil' WHEREcountry NOT LIKE'Brazil' WHEREcountry LIKE'B%'
Consulta semelhante a “< > ”
Consultasemelhante a “= ” igual. diferente. Todos os países que começam com a letra
B.
MÁSCARA (%) MÁSCARA (_) MÁSCARA (_)
SELECT * SELECT * SELECT *
WHERE country LIKE'%Z%' WHERE country LIKE'_R%' WHERE country LIKE'_R%_L'
Todos os países com a letra Z no meio Todos os países com a segunda letra Todos os países com a segunda letra do
do nome. do nome sendo “R”. nome sendo “R” e a última letra sendo “L”.
Retorno da última consulta:
Para que possamos ordenar os resultados, utilizamos os coman-

dos: ascendente ou decrescente, ASC e DESC. Para usarmos esses co-
mandos precisamos do ORDER BY.
77
ORDER BY
DESC ASC
SELECT * O padrão de saída para oscomandos SQL
FROM [Customers] é em ordem ascendente, caso não seja
ORDERBY countryDESC especificadaa ordenação.
Perceba a ordenação do país Venezuela

para a letra A que seria o menor valor.
78
Por fim, mas não menos importante temos os comandos de valo-
res nulos, IS NULL e IS NOT NULL.
IS N ULL IS N OT N ULL
SELECT *
FROM [Customers]
WHEREcountry ISN OT NULLAND region ISNULL
ORDERBY country ASC
O comando acima apresenta os países que não possuem campos NULL e asregiõesque
estão com o campo NULL.
- Observe o campo “region” com o valor NULL.
- Esse é um valor que pode ser configurado por padrão quando você configura um
atributo, dizendo que se nenhum dado for colocado, o SGBD preenche com NULL.
A utilização do comando SELECT nos permite também realizar junções de dados, recurso
semelhante às tabelas dinâmicas do Excel1. Vamos ver a seguir como trabalhar com esse recurso tão
poderoso.
1 Fonte: https://support.office.com/pt-br/article/Criar-uma-Tabela-Din%C3%A2mica-para-ana-
lisar-dados-da-planilha-a9a84538-bfe9-40a9-a8e9-f99134456576
79
5.2. Operações de Junções
As operações de junções na linguagem SQL são também chamadas de funções agregadas.

Funções que tomam uma coleção, (um conjunto ou subconjunto), de valores como entrada, retor-
nando um único valor.
Funções de agregação da SQL:

- SUM: soma/total;
- AVG: média;
- COUNT: contagem;
- MIN: mínimo;
- MAX: máximo;
Essas funções agrupam em uma mesma linha um conjunto de valores iguais, ou seja, permite
que os dados sejam sumarizados, ou resumidos. É semelhante a pedirmos um relatório de todas as
vendas de um mês ao invés de ser por dia, o agrupamento é por mês e não por dia.
Vamos supor que eu deseje saber quantos países eu tenho cadas-

trado na tabela Customers. Bastaria eu usar o comando COUNT.
SELECT COUNT(*) AS'Total Paises'

FROM [Customers]
80

Eu poderia querer saber também quantas cidades eu tenho por

países cadastrados na tabela “Customers”.
SELECT country, city, count(*) AS 'Total

Paises'
FROM [Customers]
GROUPBY country, city
ORDERBY country
*Observe que eu fiz o agrupamento

(GROUP BY) pelos atributos que eu gostaria
de contar.
Uma outra consulta seria eu multiplicar o valor unitário de um

produto pela respectiva quantidade que há desse produto em estoque.
Para essa consulta vou utilizar a tabela “Products”.
SELECT ProductName, SUM (UnitPrice *UnitsInStock) as 'Total de Mercadorias

em dolar'
FROM [Products]
GROUPBY ProductName
81
1) Sempre que você for utilizar uma função de agregação você terá que usar o
GROUP BY, com a única EXCEÇÃO do COUNT se você for contar a tabela
inteira (mostre essa situação no início).
2) Perceba que o atributo que aparece no GROUP BY sempre vai aparecer no SELECT. Sem-
pre, sempre, sempre.
Podemos utilizar também no comando SQL com agregação uma

estrutura condicional, semelhante ao WHERE. No caso das funções de
agregação usamos o HAVING.
SELECT ProductName, SUM (UnitPrice

*UnitsInStock) as 'Total de Mercadoriasem
dolar'
FROM [Products]
GROUPBY ProductName
HAVING SUM (UnitPrice *UnitsInStock) >
0
- Perceba que na saída não há mais

somatórios com o valor zero.
ATENÇÃO: Há uma diferença essencial entre WHERE e HAVING. O WHERE aplica con-
dições em linhas/tuplas, enquanto que o HAVING aplica a condição no agrupamento, no grupo de
dados que foi agrupado.
82
SELECT ProductName, sum (UnitPrice
*UnitsInStock) as 'Total de Mercadoriasem dolar'
FROM [Products]
W HEREProductName LIKE'C%'
GROUPBY ProductName
HAVING sum (UnitPrice *UnitsInStock) > 0
- Atente para o fato que SEMPRE o WHERE virá
antes do GROUP BY, porque primeiro é feito o
filtro daslinhas para depoisagrupar.
- NUNCA o HAVING virá antes do GROUP BY

ou sem o GROUPBY.
Vamos agora compreender os operadores de alteração de dados da linguagem SQL.
5.3. Operações de Alteração de Dados
Os comandos para modificação dos dados são os seguintes: INSERT, UPDATE e DELETE.
O comando INSERT tem a seguinte sintaxe:
INSERT INTO tabela (nomeDoAtributo1, nomedoAtributo2, ...)

VALUES (valorAtributo1, valorAtributo1, ...)
INSERT INTO alunos (matriculaAluno, nomeAluno)

VALUES (0001, “Rodrigo Franklin”)
83
Atente para o fato de que a quantidade de atributos deve ser igual
à quantidade de valores a serem inseridos, caso contrário você terá um
erro.
Outra possiblidade de comando seria, sem passar a lista de atributos. Nesse caso você deve
passar valores para TODOS os atributos da tabela envolvida.
INSERT INTO alunos

VALUES (0001, “Rodrigo Franklin”, “10/10/2000”, 040505, “Rua A-Vila
B”)
Na inserção anterior, eu não especifiquei os atributos, mas tive que apresentar valor para
todos os campos de uma suposta tabela de alunos.
O próximo comando é o DELETE, bastante conhecido pelo seu poder de destruição, mas
que poucos sabem manipulá-lo corretamente. A sintaxe é a seguinte:
DELETE FROM tabela

WHERE condição
84
DELETE FROM alunos
WHERE matricula = 0001
Esse comando deleta apenas a linha/registro do aluno de matricula
0001. Ao contrário do comando: “DELET FROM alunos” que deletaria
todos os registros da tabela, assim TOME CUIDADO com o DELETE.
Muitas vezes necessitamos ATUALIZAR os dados de um banco de dados, nessa situação

faremos uso do UPDATE. Sintaxe:

UPDATE tabela
SET atributo1 = valorNovo
WHERE condição
UPDATE alunos
SET nomeAluno = “Rodrigo Franklin Frogeri”
WHERE matriculaAluno = 001
O comando anterior atualiza o nome do aluno com a matrícula 0001 na tabela alunos. Aten-
te para o fato de que o comando UPDATE também é bastante perigoso
UPDATE alunos
SET nomeAluno = “Rodrigo Franklin Frogeri”

85
Esse comando atualiza a tabela inteira de alunos com o nome “Rodrigo Franklin Frogeri”.
Na sequência, vamos entender como realizar consultas entre mais de uma tabela, visto que
até o momento só trabalhamos com uma única tabela para consulta.
5.4. Consultas Entre Várias Tabelas
Na grande maioria das vezes que trabalhamos com banco de dados, precisamos trazer
dados de diferentes tabelas, até porque os dados estão todos separados devido às operações de
normalização.
O comando que mais utilizaremos para as operações de junções entre tabelas é o INNER
JOIN. Observe a sintaxe:
SELECT *
FROM tabela1 INNER JOIN tabela2
ON tabela1.chavePrimaria = tabela2.chaveEstrangeira
OBSERVAÇÃO: Sempre que formos fazer consultas entre tabelas, deve-

remos utilizar a CHAVE PRIMARIA de uma e a tabela onde ela é CHAVE
ESTRANGEIRA.
Considere o modelo lógico a seguir:
86
Figura 35 – Modelo Lógico
Fonte: Arquivo Pessoal do Autor
Caso seja necessário montar uma consulta que apresente todos os atributos da tabela ALU-
NO e todos os atributos da tabela CURSO. Como devemos proceder?
87
SELECT *
FROM aluno INNER JOIN curso ON curso.idCurso = aluno.idCurso
*Perceba que a junção é realizada pelas chaves primárias e chaves estrangeiras de

CURSO, não de ALUNO, porque aluno não tem chave estrangeira na relação.
Vamos fazer agora uma consulta mais avançada com várias tabelas. Eu desejo saber o nome
do curso, o nome das disciplinas de cada curso e o departamento que estão vinculados.
SELECT curso.nomeCurso, disciplina.nomeDisciplina, departamento.nomeDepartamento

FROM curso INNER JOIN disc-curso ON curso.idCurso = disc-curso.idCurso
IN NERJOIN disciplina ON disc-curso.idDisciplina= disciplina.idDisciplina
IN NERJOIN responsável ON disciplina.idDisciplina= responsável.idDisciplina
IN NERJOIN departamento ON responsável.idDepartamento =
departamento.idDepartamento
Esse tipo de consulta mostra, claramente, a importância da normalização e da dependência

funcional, se tudo estiver correto eu consigo fazer consultas dos mais variados tipos.
Temos outros tipos de JOIN, como por exemplo RIGHT JOIN, LEFT
JOIN e CROSS JOIN. Pesquise sobre esses tipos e observe a diferença para
o INNER JOIN.
Vamos agora realizar consultas aninhadas, ou também chamada de sub consultas, uma con-
sulta dentro da outra.
5.5. Sub-Consultas Aninhadas
Muitas vezes, precisamos verificar se um valor existe ou não em um outro local, esse recurso
pode ser utilizado por meio dos comandos EXISTS e NOT EXISTS.
88
SELECT *
FROM aluno
WHERE EXISTS (SELECT * FROM curso
WHERE nomeCurso = “Sistemas de Informação”)
Explicação: Primeiro será realizada a consulta mais interna, ou seja,

a sub consulta (curso igual a Sistemas de Informação), se essa consulta
retornar algum registro ela sinaliza para a consulta externa um Ok (ver-
dadeiro) então a consulta externa é realizada, ou seja, apresenta todos os
atributos da tabela aluno.
ATENÇÃO: A sub consulta apenas sinaliza e não exibe nenhum tipo de dado. O NOT
EXISTS tem a mesma aplicação do EXISTS.
Uma outra consulta possível por meio de sub consultas seria para apresentarmos os nomes
dos alunos que estão com notas abaixo de seis. Considere que as tabelas ALUNO e de NOTAS
estão relacionadas por meio da chave matricula.
SELECT aluno.nomeAluno
FROM aluno
WHERE aluno.matricula IN (SELECT matricula FROM notas
WHERE nota < 6)
Perceba que nessa situação a consulta mais interna retornará uma
lista de matriculas, que serão verificadas pela consulta mais externa para mostrar somente
aqueles alunos com notas menores que seis.
89
A aplicação das sub consultas é bem vasta e, em muitas situações, só elas podem resolver a
necessidade de buscas por determinados dados.
Conforme já mencionei, a SQL é a linguagem padrão dos SGBDs

do mercado, sendo um item essencial para o profissional de computação.
Busquei nessa unidade trazer os comandos mais utilizados no dia a dia de um
desenvolvedor ou DBA.
Chamo a atenção para os comandos de agregação e suas funções, esses são sem dúvida
o grande “calcanhar de Aquiles”, de quem está estudando banco de dados. Atente para as regras
de ouro que coloco no guia, como a necessidade de que todo atributo que aprece no group by,
também deve aparecer no select, entre outras que são apresentadas.
As operações com JOINs são outro assunto de grande importância, porque não temos
como fazer consultas mais avançadas com apenas uma tabela envolvida. Devemos nos atentar
para a utilização das chaves primárias e chaves estrangeiras dentro das operações de junções
(JOIN).
Por fim estudamos as operações com sub consultas, recurso esse que considero mais
avançado e que poucos profissionais dominam, mas que não é tão complicado como parece,
basta atentarmos para a lógica que se aplica nessas consultas.
90
VI
Unidade VI -
Linguagens de
definição
de dados da SQL
- Compreender, analisar e criar estruturas de banco de dados

por meio da linguagem de consulta estruturada (SQL).
Unidade VI - Linguagens de Definição de Dados da SQL
6. Introdução
Para a execução dos códigos apresentados a seguir vamos utilizar o SGBD SQL Server Ex-
pressa da Microsoft. A linguagem de definição de dados (DDL) da SQL foca na criação do esquema
de banco de dados, assim, trabalharemos com os comandos CREATE, ALTER e DROP basicamente,
além de outros que fazem parte do SGBD estudado.
6.1. Comandos de Definição de Dados
Cada SGBD estrutura as suas bases de dados (BD) de uma forma, no caso do SQL Server a
criação de uma BD implica na geração de arquivos extras, como:
1. Arquivos primários (Primary);
2. Arquivos secundários (Secondary);
3. Arquivos do transaction log.
Figura 36 – Tipos de arquivos de um banco de dados SQL Server
Tipo de Arquivo Descrição

Todos os bancos de dados têm um Primary Data File. A
PRIMARY DATA FILE extensão de arquivo recomendada para o Primary Data
File é .mdf.
Contém todos os dados que não estão Primary Data File.
Alguns databases podem não ter nenhum Secondary Data
SECONDARY DATA FILE File, enquanto outros tem vários. A extensão de arquivo
recomendadapara o Secondary Data File é .ndf.
Arquivos de logscontém todas asinformaçõesusadaspara
recuperar um database. Deve existir pelo menos um
ARQUIVOSDE LOG arquivo de log para cada database, embora possa ter mais
de um. A extensão recomendada para arquivos de logs é
.ldf.

92
Essas extensões não são obrigatórias, mas devem ser utilizadas por ser um padrão do SQL
Server.
Figura 37 – Extensão
Extensão Significado O que contém Filegroup

É o primeiro arquivo de dados e sempre
vai conter o Catálogo do Database.
Mdf Primary Data File Primary
Poderá também conter tabelas e dados
dos usuários.
É o arquivo de dados secundário, isto é,
que foi criado depois do primário. A critério do
Ndf Secondary Data File
Poderá existir outros arquivos usuário
secundários.
É o arquivo que vai conter as transações
Ldf Log Data File Não há.
realizadas no sistema.
- Nome Lógico = É o nome conhecido pelo SQL Server para se referir ao arquivo em todos os
comandos Transact – SQL. O nome lógico de arquivo deve seguir as regras dos identificadores
do SQL Server e deve ser único para o servidor.
- Nome Físico = É o nome do arquivo físico é conhecido pelo sistema operacional. Ele deve se-
guir as regras de nomes de arquivos do sistema operacional sobre o qual foi instalado.
Observações:
- Os dados e logs nunca são misturados num mesmo arquivo.
- Um arquivo poderá conter apenas UM database.
- Quando um database é excluído, seus arquivos também o são.
6.1.1. Grupo de Arquivos (FILEGROUPS)
Os arquivos (files) podem ser organizados em grupos de arquivos (filegroups) com a finalida-
de de melhor gerenciar e administrar os mesmos. Se a configuração do hardware contém múltiplos
discos, podem colocar objetos e arquivos específicos em discos individuais, agrupando seus arquivos
de databases em diversos grupos de arquivos.
93
Podemos melhorar a performance de alguns sistemas, controlando a
localização de arquivos de dados e de índices em discos específicos. O dba
pode criar grupos de arquivos, atribuindo tabelas e índices para um filegroup
específico.
Dicas bacanas:
- Nenhum arquivo pode ser membro de mais de um filegroup.
- Arquivos de log não fazem parte de um filegroup. O arquivo de log
é gerenciado separadamente dos arquivos de dados.
- O SQL Server contém um filegroup como default, e podemos criar filegroups adicionais
quando necessário.
- Com filegroups, podemos colocar objetos específicos em arquivos específicos.
- Os administradores do sistema também podem fazer backup de arquivos individuais ou
grupos de arquivos em vez de fazer backup do database inteiro.
- O SQL Server cria um database, usando um conjunto de arquivos do sistema operacional.
Todos os dados e objetos do database, como tabelas, stored procedures, triggers e views
(veremos o que é isso mais a frente) são armazenados dentro destes arquivos do sistema
operacional.
Há dois tipos de filegroup:
- Filegroup default = contém o Primary Data File e quaisquer outros arquivos que não estiverem
em outro filegroup. Todas as tabelas do sistema são alocadas no filegroup default. Todas as tabe-
las e índices que não tem um filegroup especificado quando eles são criados, também, tem suas
paginas alocadas no filegroup default.
94
- Filegroups definidos por usuário = são quaisquer grupos de arquivos especificados, usando a
palavra chave “Filegroup” no comando CREATE DATABASE ou ALTER DATABASE.
Conhecida estrutura de uma base de dados no SQL Server e que muitos SGBDs de grande
porte também seguem esses conceitos, vamos criar nossa base de dados por meio da DDL.
Criação de um Database especificando os arquivos de dados e de log
CREATEDATABASEALUNO
ON
(
NAME= ‘Aluno_dados’,
FILENAME= ‘C:\Bancos\Aluno_Dados.mdf’,
SIZE= 10MB,
MAXSIZE= 50MB,
FILEGROWTH = 5MB
)
LOG ON
(
NAME= ‘Aluno_log’,
FILENAME= ‘C:\Bancos\Aluno_Log.ldf’,
SIZE= 5MB,
MAXSIZE= 25MB,
FILEGROWTH = 5MB
)
95
Criação de um database especificando múltiplos arquivos para os dados
e o log
CREATEDATABASEBIBLIOTECA
ON PRIMARY
(
NAME= ‘Biblioteca_dados_1’,
FILENAME= ‘C:\Bancos\Biblioteca_dados_1.mdf’,
SIZE= 100MB,
MAXSIZE= 200MB,
FILEGROWTH = 20MB
),
(
FILENAME= ‘C:\Bancos\Biblioteca_dados_2.ndf’,
SIZE= 100MB,
MAXSIZE= 200MB,
FILEGROWTH = 20MB
),
(
FILENAME= ‘C:\Bancos\Biblioteca_dados_3.ndf’,
SIZE= 100MB,
MAXSIZE= 200MB,
FILEGROWTH = 20MB
)
LOG ON
(
NAME= ‘Biblioteca_log_1’,
FILENAME= ‘C:\Bancos\Biblioteca_log_1.ldf’,
SIZE= 1MB,
MAXSIZE= 20MB,
FILEGROWTH = 1MB
),
(
NAME= ‘Biblioteca_log_2’,
FILENAME= ‘C:\Bancos\Biblioteca_log_2.ldf’,
SIZE= 1MB,
MAXSIZE= 20MB,
FILEGROWTH = 1MB
)
96
Criação de uma simples database sem especificar o arquivo de log
CREATEDATABASEPRODUTOS
ON
(
NAME= ‘Produtos_dados’,
FILENAME= ‘C:\Bancos\Produtos_dados.mdf’,
SIZE= 4,
MAXSIZE= 10,
FILEGROWTH = 1
)
Criação de um Database Sem Especificar os Arquivos
CREATEDATABASETESTE
Este exemplo cria uma database chamada Teste e um primary file e um log file corres-
pondente. O primary file do database terá o tamanho do primary file do model database. O
tamanho do arquivo de log será o tamanho arquivo de log do model database. Se o MAXSIZE
não for especificado, o arquivo poderá crescer ate preencher todo o espaço disponível no
disco.
Observe que em todas as situações serão criados dois arquivos obrigatoriamente, um MDF
(primário) e outro LDF (log), mesmo que eu não especifique no comando (último caso) o arquivo
de log, ele será criado, porque não existe uma base de dados sem um arquivo de log.
97
Qual a importância do arquivo de log?
É nele que ficam armazenadas todas as transações que estão sendo re-
alizadas no banco de dados, por meio dele que é possível realizar os comandos
de COMMIT e ROLLBACK, por exemplo.
Criação de um Database Com Filegroup - este exemplo cria um data-

base chamado Produção com três filegroups
CREATE D ATABASE PRODUCAO

ON PRIMARY
(
NAME = ‘Producao_dados1’,
FILENAME = ‘C:\Bancos\Producao_dados1.mdf’,
SIZE = 10MB,
MAXSIZE = 50MB,
FILEGROW TH = 1MB
),
(
FILENAME = ‘C:\Bancos\Producao_dados2.ndf’,
SIZE = 10MB,
MAXSIZE = 50MB,
FILEGROW TH = 1MB
),
FILEGRO UPGrupoProducao1
(
SIZE = 10,
MAXSIZE = 50,
FILEGROW TH = 5
),
(
98 FILENAME = ‘C:\Bancos\Producao_dados4.ndf’,
SIZE = 10,
(
SIZE = 10,
MAXSIZE = 50,
FILEGROW TH = 5
),
(
SIZE = 10,
MAXSIZE = 50,
FILEGROW TH = 5
),
(
SIZE = 10MB,
MAXSIZE = 50MB,
FILEGROW TH = 5MB
),
(
SIZE = 10MB,
MAXSIZE = 50MB,
FILEGROW TH = 5MB
)
LO G O N
(
NAME = ‘Producao_log’,
FILENAME = ‘C:\Bancos\Producao_log_.ldf’,
SIZE = 5MB,
MAXSIZE = 25MB,
FILEGROW TH = 5MB
)
No próximo comando vamos criar tabelas dentro de um filegroup específico. Para criar uma
tabela em um filegroup específico, basta apontar o grupo de arquivo desejando no comando CRE-
ATE TABLE.
99
Use PRODUCAO
CREATETABLEProduto
(
Cod_Prod int,
Nome_Prod char (20)
)
ON GrupoProducao1
Quando criamos uma tabela e não especificamos o filegroup sobre o

qual ela deve ser criada, o SQL Server a criará no filegroup default. Por de-
fault, o filegroup padrão é o PRIMARY, mas podemos especificar um outro
grupo de arquivos do database em questão para ser o filegroup default.
ALTER DATABASEProdução
MODIFY FILEGROUP GrupoProducao1 DEFAULT
*Nesse caso colocamos o filegroup GrupoProducao1 como sendo o default da base de dados Producao.
Antes de executarmos comandos da DDL voltadas para tabelas, precisamos compreender

os tipos de dados que o SGBD trabalha.
Tipos de dados de atributos no SQL Server
Tipos numéricos:
- TINYINT: Armazena valores numéricos inteiros, variando de 0 a 256.
- SMALLINT: Armazena valores numéricos inteiros, variando de -32.768 a 32.767
100
- INT: Armazena valores numéricos inteiros, variando de -2.147.483.648 a 2.147.483.647.
- BIGINT: Armazena valores numéricos inteiros, variando de -9.223.372.036.854.775.808 a

-9.223.372.036.854.775.807
- MONEY: Valores numéricos decimais variando de -922,337,203,685,477.5808 a

+922,337,203,685,477.5807.
- NUMERIC (18,0): Armazena valores numéricos com casas decimais, utilizando precisão. O pri-
meiro número entre os parênteses, representa a quantidade de inteiros a serem armazenados, o
segundo número, indica a quantidade de casas decimais do número.
- DECIMAL(18,0): Tem as mesmas funcionalidades do tipo NUMERIC, a diferença é que o DE-

CIMAL faz parte do padrão ANSI e NUMERIC é mantido por compatibilidade.
- FLOAT: Armazena valores numéricos aproximados com precisão de ponto flutuante, variando
de -1.79E + 308 a 1.79E + 308.
- REAL: Armazena valores numéricos aproximados com precisão de ponto flutuante, variando de
-3.40E + 38 a 3.40E + 38
Tipo BIT:
- BIT: Armazena bits, ou seja, somente poderá conter os valores lógicos 0 ou 1.
Tipo data:
- SMALLDATETIME: Armazena data e hora, com precisão de minutos.
101
- DATETIME: Armazena data e hora, com precisão de centésimos de segundos.
- DATETIME2: É uma combinação dos tipos de dados DATE e TIME. A diferença para o tipo
DATETIME é a precisão ao armazenar as horas.
- DATETIMEOFFSET: Armazena valores data e hora com a combinação da hora do dia com o
fuso horário. O intervalo de deslocamento do fuso horário é de -14:00 a +14:00
Tipos caracteres:
- CHAR(N): Armazena N caracteres fixos (até 8.000) no formato não Unicode. Independente da
quantidade de caracteres utilizados, irá sempre armazenar o tamanho de caracteres do campo,
sendo preenchido o restante com espaços em branco.
- VARCHAR(N): Armazena N caracteres (até 8.000) no formato não Unicode.
- VARCHAR(MAX): Armazena caracteres no formato não Unicode. MAX indica que o máximo
a ser armazenado pode chegar a 2^31-1 bytes.
- TEXT: Armazena caracteres no formato não Unicode. Esse tipo de dado suporte até
2.147.483.647 caracteres e existem funções específicas para trabalhar com esse tipo de dado.
- NCHAR(N): Armazena N caracteres fixos (até 4.000) no formato Unicode. Independente da

quantidade de caracteres utilizados, irá sempre armazenar o tamanho de caracteres do campo,
sendo preenchido o restante com espaços em branco.
- NVARCHAR(N): Armazena N caracteres (até 4.000) no formato Unicode.
102
- NVARCHAR(MAX): Armazena caracteres no formato Unicode. MAX indica que o máximo a ser
armazenado pode chegar a 2^31-1 bytes.
- NTEXT: Armazena caracteres no formato Unicode. Esse tipo de dado suporte até 1.073.741.823
caracteres e existem funções específicas para trabalhar com esse tipo de dado
Há outros tipos de dados para armazenamento de tipos de informações mais específicas no

SQL Server, mas vamos trabalhar com os mais simples e aplicados.
6.2. Integridade e Consistência dos Dados
As colunas definidas como NOT NULL deverão receber um valor quando uma linha for
inserida; e as colunas definidas com NULL poderão não receber valor algum.
CREATETABLECLIENTE
(
Cod_Cli int NOT NULL,
Nome_Cli char(20) NOT NULL,
Renda_Cli decimal (10,2) NULL
)
Constraints – Restrições
Quando criamos chaves primárias e estabelecemos o relacionamento entre as tabelas atra-

vés de chaves estrangeiras, estamos estabelecendo vários tipos de integridade para os dados.
- As chaves Primárias estabelecem a integridade de Entidade.

- As chaves Estrangeiras estabelecem a integridade Referencial.
103
Consistir os dados de uma coluna de uma tabela significa limitar os valores que ela poderá
receber.
Na tabela de Filhos podemos ter um atributo SexoFilho, onde provavelmente podemos

permitir que sejam inseridas apenas as letras F (Feminino) ou M (Masculino).
Para impor este tipo consistência, deve ser implementado a integridade de Domínio, limitan-
do as possibilidades de valores inseridos.
No SQL Server, existem algumas formas de manter a integridade e consistência dos dados.
As constraints são objetos do SQL Server criados para manter a integridade e consistência dos seus
dados.
As constraints são divididas em cinco:
A) PRIMARY KEY
B) FOREING KEY / REFERENCES
C) UNIQUE
D) CHECK
E) DEFAULT
PRIMARY KEY
São as constraints que vão garantir a integridade de Entidade, ou seja, são elas que vão per-
mitir a identificação de uma linha como única numa tabela. É com as constraints PRIMARY KEY que
adicionamos chaves primárias numa tabela. A seguir uma constraint PRIMARY KEY.
104
CREATETABLEPAI
(
Cod_Pai int NOT NULL,
Nom_Pai char (30) NOT NULL,
Idade_Pai Tinyint NOT NULL,
Salário_Pai Decimal (10,2) NOT NULL,
CONSTRAINT PK_PAI PRIMARY KEY (Cod_Pai)
)
Constraint FOREIGN KEY:
CREATETABLEFILHO
(
Cod_Filho int NOT NULL,
Nom_Filho char(30) NOT NULL,
Idade_Filho tinyint NOT NULL,
Sexo_Filho char(01) NOT NULL,
CONSTRAINT PK_FILHO PRIMARY KEY (Cod_Filho),
CONSTRAINT FK_Filho FOREIGN KEY (Cod_Pai) REFERENCESPai (Cod_Pai)
)
Podemos configurar certas regras de deleção e atualização em nosso banco de dados, ou

seja, quando eu deletar um registro que possui chave estrangeira em outra tabela, o que deve acon-
tecer? Deve ser bloqueado? Deve ser atualizado? Deve ser deletado? Nesse momento fazemos uso
do ON DELETE CASCADE – ON UPDATE CASCADE.
105
ON DELETE CASCADE
CREATETABLEFILHO
(
Nom_Filho char(30) NOT NULL,
Idade_Filho tinyint NOT NULL,
Sexo_Filho char(01) NOT NULL CONSTRAINT DF_FILHO DEFAULT ‘M’,

CONSTRAINT CH_FILHO CHECK (Sexo_Filho IN (‘F’,’M’)),
CONSTRAINT DF_FILHO FOREIGN KEY (Cod_Filho) REFERENCESPai (Cod_Pai)
ON DELETECASCADE
)
- Nesse caso estamos configurando a deleção em cascata, ou seja, se eu delete uma chave
primária, todosos registrosque se relacionam com essa chave também serão deletados.
Constraint UNIQUE
Vamos supor que, além da coluna chave primária da tabela, hou-

vesse uma outra coluna que nós quiséssemos que seu valor nunca se re-
petisse na tabela inteira. Por exemplo, se na tabela PAI houvesse uma coluna chamada RG_Pai
e quiséssemos garantir que não haveria nesta tabela dois pais com o mesmo RG. Estaríamos,
então, criando uma chave primária secundária, implementada no SQL Server com as cons-
traints UNIQUE.
106
CREATETABLEPAI
(
Nom_Pai char (30) NOT NULL,
RG_Pai char (12) NOT NULL,
Idade_Pai Tinyint NOT NULL,
Salário_Pai Decimal (10,2) NOT NULL,
CONSTRAINT PK_PAI PRIMARY KEY (Cod_Pai),
CONSTRAINT U_PAI UNIQUE(RG_Pai),
))
Constraint CHECK
Vamos supor que quiséssemos garantir que seu usuário final, não
consiga inserir nenhuma outra letra na coluna Sexo_Filho da tabela Filho
e não ser as letras F ou M. Para tanto, poderíamos usar as constraints Check, utilizadas para
implementar a integridade de domínio.
CREATETABLEFILHO
(
Cod_Pai int NOT NULL REFERENCESPAI (Cod_Pai),
Nom_Filho char (30) NOT NULL,
Idade_Filho Tinyint NOT NULL,
Sexo_Filho char(10) NOT NULL,
CONSTRAINT CH_FILHO CHECK (Sexo_Filho IN (‘F’, ‘M’))
)
107
Constraint DEFAULT
Vamos supor que a maioria dos filhos cadastrados na tabela Filho

seja homem (Sexo Masculino), poderíamos facilitar a vida do seu usuário,
permitindo que ele não digite nada quando quiser que a coluna sexo_filho seja preenchida
com a letra M. Para isso, podemos utilizar um valor padrão implementado com as constraints
DEFAULT.
CREATETABLEFILHO
(
Cod_Pai int NOT NULL REFERENCESPAI (Cod_Pai),
Nom_Filho char (30) NOT NULL,
Idade_Filho Tinyint NOT NULL,
Sexo_Filho char(10) N OT NULL CONSTRAINT DF_FILHO DEFAULT ‘M’,
CONSTRAINT CH_FILHO CHECK (Sexo_Filho IN (‘F’, ‘M’))
)
108
Na unidade seis entramos literalmente no mundo dos administradores
de banco de dados. Tivemos a oportunidade de compreender o armazena-
mento e configuração avançados de uma estrutura física de banco de dados.
O uso de filegroups é utilizado apenas por DBAs com anos de experiência,
mas que é um recurso bastante importante quando pensamos em desempenho e organização
física dos dados.
A aplicação de constraints no nosso modelo físico de banco de dados permite que
sejam criadas estruturas muito mais consistentes e livres de anomalias por inserção de valores
incorretos ou pela inadequação da relação entre os dados. Temos restrições de várias nature-
zas, mas que juntas nos dão um poder de organização dos dados impressionante.
Vocês devem se lembrar que no início do guia de estudos apresentei um modelo físico
construído com base em um modelo conceitual que fizemos, e disse para vocês não se preo-
cuparem com aqueles comandos porque iríamos aprender. Aprendemos bem mais do que foi
apresentado no modelo físico, o que os habilita a construir os seus próprios modelos sem a
necessidade de um software. ;)
109
Unidade VII -
VII Estruturas Avançadas

de Programação em
Banco de Dados I
- Analisar e criar estruturas avançadas de programação em banco

de dados.
Unidade VII - Estruturas Avançadas de Programação em Banco de Dados I
7. Introdução
Nesta unidade vamos aprender como criar variáveis, como usar o comando IF e o comando
While, enfim, vamos começar a ver que a linguagem SQL é também uma linguagem de programa-
ção.
VARIÁVEIS DE USUÁRIO
Os usuários avançados de BD poderão criar variáveis LOCAIS usando o comando DECLA-

RE. As variáveis criadas pelos usuários devem ser precedidas por @.
DECLARE @VAR1 INT,

@VAR2 CHAR(10), @VAR3 TINYINT
Podemos notar que, para cada variável criada, deverá ser atribuído um datatype – tipo de
dados.
Atribuindo um valor a uma variável
Para atribuir um valor a uma variável, podemos usar o comando SET ou o comando SELECT.
Observemos o comando abaixo com o SET, da mesma forma que o comando SELECT, atribuímos
um conteúdo para uma variável.
111
DECLARE @VAR1 INT,
@VAR2 CHAR(50)
SET @VAR1 = 100
SELECT @VAR2 = COLUNA 2 FROM TABELA
Linguagens de controle de fluxo
Os elementos de controle de fluxo usados na linguagem SQL do SQL Server são:

- BEGIN / END
- IF ... ELSE
- WHILE
Com estes elementos de linguagem, mais os comandos SQL, podemos construir lógicas
muito úteis e interessantes para o sistema.
BEGIN / END
Estes elementos iniciam e terminam um bloco de comandos. São utilizados após um co-
mando IF ou após um comando WHILE caso for executado um bloco de comandos logo após a
realização de um teste de condição.
IF ... ELSE
Qualquer linguagem de programação deve fornecer uma forma de testarmos uma determi-
nada condição e executarmos ou não uma ou mais tarefas logo após este teste. Assim como outras
linguagens, o SQL Server também possui o comando IF com esta finalidade.
112
IF <CONDICAO>
BEGIN
COMANDO 1
COMANDO 2
COMANDO 3
END
USE BDAULA
GO
IF (SELECT COUNT(*) FROM PRODUTOS) < 30
BEGIN
PRINT “Esta tabela tem muitas linhas”
PRINT “São produtos do catálogo produtos”
END
ELSE
PRINT “Esta tabela tem poucas linhas”
- No código acima eu uso o banco de dados chamado aula que tem a tabela produtos.
Conto quantaslinhastem e faço o teste lógico apresentando uma ou outra mensagem.
CASE / WHEN / THEN / END
Para evitar a construção de comandos com IF aninhados, podemos usar o comando CASE.
O comando CASE é utilizado junto com o comando SELECT.
SELECT
CASECOLUNA
WHEN VALOR1 THEN NOVO_VALOR1
ELSENOVO_VALOR4
END
FROM <NOMETABELA>
113
WHILE
Com o comando WHILE, podemos criar um loop.
WHILE<CONDICAO = V>
BEGIN
COMANDO1
COMANDO2
COMANDO3
END
Vamos ver um exemplo funcional.
DECLARE@CONT TINYINT
SELECT @CONT = 1
WHILE@CONT < 10
BEGIN
SELECT @CONT
SET @CONT = @CONT + 1
END
- Nesse código eu declaro uma variável CONT e a implemento

como um contador dentro de um loop.
7.1. Procedimentos Armazenados (Stored Procedures)
Uma Stored Procedure é uma coleção de comandos SQL, que pode ser criada para uso per-
manente ou para uso temporário dentro de uma sessão de usuário (Procedure Temporária Local)
ou por todos os usuários (Procedure Temporária Global).
Stored Procedure também são criadas para rodarem automaticamente em um determinado
horário, em determinados períodos ou quando o SQL Server é ligado. AS SP´s como chamamos as
Stored Procedures são largamente utilizadas em grandes sistemas, principalmente ERP’s, que neces-
sitam de muitas lógicas automatizadas.
114
CREATEPROCEDUREP_INCPAIFILHO
AS
BEGIN TRANSACTION
INSERT PAI VALUES(1,’JOSE’,35, 1500)
IF @@ERROR <> 0
BEGIN
RAISERROR(50002,16,1)
RETURN
END
INSERT FILHO VALUES(1,1,’ANDRE’,5,’M’)
IF @@ERROR <> 0
BEGIN
ROLLBACK TRANSACTION
RETURN
END
COMMIT TRANSACTION
- Nesta SP é inserido quatro valores em uma tabela chamada PAI e na sequência é

verificado se algum erro acontece (@@ERROS<> 0 – é um comando do próprio SQL
Server para verificar erro). Na sequencia um novo comando de INSERT é realizado e
caso apresente um erro um ROOLBACK irá ocorrer. Caso tudo dê certo é dado um
COMMIT.
PARÂMETROS
As Stored Procedures do SQL Server são similares as procedures de outras linguagens de

programação e elas podem:
- Aceitar parâmetros de entrada;
- Retornar vários parâmetros como saída.
As Stored Procedures retornam um valor status para a aplicação (procedure ou batch) que a
chamou para indicar sucesso ou falha e a razão da falha. Podemos usar o comando EXECUTE para
rodar uma S.P. Vamos observar um exemplo.
115
CREATEPROCEDUREP_INCPAIFILHO
@COD_PAI INT,
@COD_FILHO INT,
@NOM_PAI VARCHAR(30),
@NOM_FILHO VARCHAR(30),
@IDA_PAI INT,
@SAL_PAI DEC(10,2) = 465,
@IDA_FILHO INT,
@SEXO_FILHO CHAR(1) = ‘M’
AS
BEGIN TRANSACTION
INSERT PAI VALUES(1,’JOSE’,35, 1500)
IF@@ERROR<> 0
BEGIN
RETURN
END
INSERT FILHO VALUES(1,1,’ANDRE’,5,’M’)
IF@@ERROR<> 0
BEGIN
ROLLBACKTRANSACTION
RETURN
END
COMMIT TRANSACTION
- Nesta SP são declaradasvariáveisou parâmetros, indicando que quando essa

SP for chamada eu tenho que passar esses parâmetros de entrada, com
exceção daquelesvalores que possuem um valor default, como sexo_filho.
Vamos analisar agora um exemplo práico do uso de SPs em um banco de dados. Utilizarei
o banco de dados Northwind disponibilizado gratuitamente pela Microsoft.
116
Consulta para buscar aniversariantes:
use NORTHWIND
SELECT COUNT(NOME) FROM dbo.Funcionários
WHEREEXISTS (SELECT dbo.Funcionários.NOMEfrom dbo.Funcionárioswhere
DAY(dbo.Funcionários.DataDeNascimento) = DAY(GETDATE()) AND
MONTH(dbo.Funcionários.DataDeNascimento) = MONTH(GETDATE()))
Criando a Stored Procedure:
CREATEPROCEDURE[dbo].[SP_ANIVERSARIANTES]
AS
DECLARE@qtdeaniversariantesINT
BEGIN
SET @qtdeaniversariantes= (SELECT COUNT(*) as 'Qtde Aniversariantes'
FROM dbo.Funcionários
WHEREDAY(dbo.Funcionários.DataDeNascimento) = DAY(GETDATE()) AND
MONTH(dbo.Funcionários.DataDeNascimento) = MONTH(GETDATE()))
IF @qtdeaniversariantes> 0
BEGIN
SELECT dbo.Funcionários.NOME+ ' ' + dbo.Funcionários.Sobrenome as
'Aniversariantes'
FROM dbo.Funcionários
WHEREDAY(dbo.Funcionários.DataDeNascimento) = DAY(GETDATE())
AND MONTH(dbo.Funcionários.DataDeNascimento) =
MONTH(GETDATE())
END
ELSE
PRINT 'NAO HA ANIVERSARIANTES'
END
117
No início faço a consulta que retorna aniversariantes, mas eu preciso automatizar esse pro-
cesso criando uma SP que vai “rodar” todos os dias em meu BD e verificar se eu tenho pessoas
fazendo aniversário, caso haja, posso enviar um e-mail, por exemplo. No nosso caso estou dando
apenas uma mensagem no próprio SGBD.
Observação: Caso o seu banco de dados Northwind esteja em inglês, traduza o nome dos
campos e tabelas.
A unidade sete deve ter sido um choque para muitos de vocês, por-
que trouxe para um mundo dos banco de dados recursos de linguagens de
programação. Muita gente sequer imagina que isso seja possível, mas é :).
A criação de procedimentos armazenados (stored procedures) em
SGBDs é um dos recursos mais avançados de banco de dados e também de sistemas de in-
formação em geral. Hoje é muito comum que a lógica seja retirada do programa e colocada
no SGBD. Esse tipo de abordagem permite que o sistema de informação tenha somente as
regras de negócio que devem ser aplicadas no cliente enquanto que no SGBD ficam as regras
de manipulação dos dados, permitindo, inclusive uma maior agilidade na execução e transação
de dados.
Comentei em unidades anteriores que as stored procedures são amplamente utilizadas
em ERPs, e como podemos perceber em um simples exemplo da configuração de checagem
de aniversariantes, as SPs permitem que inúmeras funcionalidades possam ser automatizadas
e executadas pelo próprio SGBD, sem a necessidade de um formulário ou botão para alguém
clicar.
Aprender SPs éter um passo a frente dos profissionais de mercado, visto que poucos
dominam esse recurso. Esteja a frente!
118
Unidade VIII -
VIII Estruturas Avançadas
de Programação em
Banco de Dados II
- Analisar e criar estruturas automáticas de programação em

banco de dados.
Unidade VIII - Estruturas Avançadas de Programação em Banco de Dados II
8. Introdução
Um trigger é um tipo especial de stored procedure que é executado sempre que houver
determinada modificação nos dados de uma tabela. Os triggers estão associados a uma ação sobre
uma tabela.
Poderemos criar triggers para serem acionados quando houver sobre determinada tabela os
seguintes comandos:
- INSERT
- DELETE
- UPDATE
- INSERT/UPDATE
- INSERT/DELETE
- UPDATE/DELETE
- DELETE/UPDATE
- INSERT/DELETE/UPDATE
Os triggers são acionados automaticamente, eles não podem ser acionados diretamente
como as stored procedures. Os triggers não devolvem e nem recebem parâmetros.
8.1. Gatilhos (triggers)
O trigger e o comando que acionou são tratados como uma única transação, que pode ser
desfeita de qualquer lugar dentro do trigger. Ou seja, se fizemos um rollback transaction de dentro
do trigger, este rollback desfaz tudo o que o trigger fez e o que foi acionado pelo comando também.
Considere as tabelas a seguir.
120
Funcionário:
Cod_Func N om_Func Ida_Func Sal_Func
1 Carlos 35 2.500,00
2 Renato 36 2.000,00
3 João 34 3.000,00
4 Joana 18 1.000,00
5 Carmen 27 700,00
6 Raquel 25 3.500,00
Histórico de modificação do Salário (HistoricoSalario):
Cod_Func Sal_Func Dat_Sal

1 2.500,00 25/02/99
2 2.000,00 30/03/99
3 3.000,00 24/04/99
4 1.000,00 25/06/99
5 700,00 27/07/99
6 3.500,00 28/07/99
O trigger abaixo grava dados alterados da tabela Funcionário na tabela Histórico.
CREATETRIGGER T_IncHistorico
ON Funcionario
FOR INSERT //Esse comando diz que a trigger será disparada quando houver um
INSERT na tabela //Funcionario.
AS
INSERT Historico
SELECT Cod_Func,
Sal_Func,
Getdate() //Pega a data atual do sistema.
FROM Inserted //Essa é uma tabela temporária que o SGBD cria para os dados
em transações.
Podemos notar que este trigger não está inserindo nenhum dado na tabela Funcionário. É
121
a inclusão feita na tabela Funcionário, gerada fora do trigger, que o aciona. Dê o comando a seguir
para realizar o teste.
INSERT Funcionario VALUES (1, ‘Carlos’, 35, 6000,00)
Assim sendo, o INSERT acima aciona o trigger que executara seu código interno (neste
exemplo, é uma inclusão na tabela Histórico). Um trigger de inclusão, ou seja, que é acionado quan-
do ocorre uma inclusão numa tabela, poderá executar internamente qualquer comando INSERT,
SELECT, UPDATE e DELETE.
Qualquer trigger poderá executar qualquer comando, com exceção de:
- CREATE (todos)
- DROP (todos)
- ALTER TABLE
- ALTER DATABASE
- TRUNCATE TABLE
- GRANT
- REVOKE
- UPDATE STATISTCS
- RECONFIGURE
- LOAD
- RESTORE DATABASE
- RESTORE LOG
- DISK (todos)
- SELECT INTO (Porque cria uma tabela)
122
- As alterações em cascata que devem ser feitas no seu sistema podem ser
implementadas com triggers.
- Apesar dos triggers não retornarem parâmetros, eles podem gerar erros
com o comando RAISERROR ().
Trigger de seleção
Para mostrar um trigger de deleção e sua tabelinha Deleted, vamos novamente usar como
exemplo a tabela Funcionário e Histórico.
Um usuário executa o comando abaixo:
DELETEFROM Funcionario WHERECod_Func = 4 or Cod_Func = 5
O comando DELETE acima, executado pelo usuário, registra a operação no Transaction Log
e aciona a execução do trigger, criando na memória a tabela Deleted.
O trigger de deleção será acionada é esta:
CREATETRIGGER T_DelHistorico
ON Funcionario
FOR INSERT
AS
DELETEHistorico
FROM Historico INNER JOIN deleted
ON Historico.Cod_Func = deleted. Cod_Func
123
Tabela Funcionário:
Cod_Func N om_Func Ida_Func Sal_Func

1 Carlos 35 2.500,00
2 Renato 36 2.000,00
3 João 34 3.000,00
4 Joana 18 1.000,00
5 Carmen 27 700,00
6 Raquel 25 3.500,00
7 Maria 28 2.000,00
Tabela Deleted (essas duas linhas são deletadas):
Cod_Func Nom_Func Ida_Func Sal_Func

4 Joana 18 1.000,00
5 Carmen 27 700,00
O código interno do trigger é executado. Neste nosso exemplo, o código interno do trigger
insere os dados da tabela Deleted na tabela Histórico.
Tabela Deleted na memória do servidor de banco de dados:

4 Joana 18 1.000,00
5 Carmen 27 700,00
Tabela HISTÓRICO DO SALÁRIO:

1 2.500,00 25/02/99
2 2.000,00 30/03/99
3 3.000,00 24/04/99
4 1.000,00 25/06/99
5 700,00 27/07/99
6 3.500,00 28/07/99
7 2.000,00 11/08/99
(Estas duas linhas são deletadas)

RESULTADO FINAL:
Funcionário
124
1 Carlos 35 2.500,00
2 Renato 36 2.000,00
3 João 34 3.000,00
6 Raquel 25 3.500,00
7 Maria 28 2.000,00
Tabela Histórico do Salário após a deleção na tabela Funcionário e execução do trigger.

1 2.500,00 25/02/99
2 2.000,00 30/03/99
3 3.000,00 24/04/99
6 3.500,00 28/07/99
7 2.000,00 11/08/99
O mesmo exemplo poderia ser realizado para o comando UPDATE, mas,

atente para o fato que não existirá a tabela temporária UPDATED, usamos as
tabelas DELETED ou INSERTED.
CREATE TRIGGER T_AltHistorico

ON Funcionario
FOR UPDATE
AS
INSERT Historico
SELECT Cod_Func,
Sal_Func,
Getdate()
FROM Inserted
A seguir, apresento um exemplo prático de como podemos fazer o controle de estoque

automaticamente por meio de trigger. Mai suma vez estou considerando as tabelas e estrutura do
banco de dados Northwind.
125
CREATE TRIGGER T_ESTOQUE
ON [Detalhes do Pedido]
FOR INSERT
AS
UPDATE PRODUTOS
SET
Produtos.UnidadesEmEstoque = Produtos.UnidadesEmEstoque - [Detalhes do Pedido].Quantidade
FROM
Produtos INNER JOIN Inserted i ON Produtos.CódigoDoProduto = i.CódigoDoProdutoINNER JOIN
[Detalhes do Pedido] ON [Detalhes do Pedido].CódigoDoProduto = Produtos.CódigoDoProduto
Perceba que eu utilizo a tabela temporária INSERTED para pegar a quantidade que foi
vendida no PEDIDO (Tabela Detalhes do Pedido). Assim, basta decrementar o valor do campo
quantidade da tabela Produtos.
As triggers, ao contrário das SPs são lógicas disparadas automatica-

mente diante de uma operação de inserção, deleção ou atualização em um
determinado objeto do banco de dados.
Também amplamente utilizadas, permite-nos a desenvolver regras de
negócio automáticas no banco de dados, como é o exemplo do controle de estoque apresen-
tado. Não é necessário nenhum tipo programação ou iteração para o usuário, quem fica a cargo
de tudo é o próprio SGBD.
Vale ressaltar que todo programador deve analisar a aplicação ou não de uma trigger,
uma vez que a programação de triggers vincula a sua lógica a aquele SGBD, não sendo emigrá-
vel para outro. Essa falta de portabilidade entre SGBDs se deve ao fato de que cada empresa
desenvolve a sua própria linguagem SQL para comandos avançados como é o caso de SP e
triggers.
Sempre avalie essa situação!
126
IX
Unidade IX -
Introdução à
Organização e
Análise de Dados
- Conceituar e compreender os recursos de banco de dados

para organização e análise de grandes depósitos de dados.
Unidade IX - Introdução à Organização e Análise de Dados
9. Introdução
As primeiras estruturas de banco de dados e que, até hoje existem em alguns estabelecimen-
tos, principalmente em consultórios médicos mais antigos, são aqueles armários de aço indexados
pelas letras do alfabeto que armazenam as fichas dos pacientes. A armazenagem de dados nesse
tipo de estrutura demanda um enorme espaço físico além de uma busca pelo dado bastante lenta e
manual.
Na busca por uma armazenagem cada vez maior de dados e a manipulação cada vez mais
rápida surgiram formas para que os dados fossem armazenados em formato digital, tínhamos uma
espécie de digitalização das fichas dos pacientes, como se fossem vários arquivos .doc, um para cada
paciente. Esse tipo de estrutura ainda não atendia às demandas organizacionais e principalmente de
sistemas bancários, necessitando que os dados estivessem relacionados.
Na década de 70, Edgard Frank Codd apresenta à comunidade científica o modelo relacional,
uma nova forma de armazenagem de dados baseada na relação entre tabelas compostas por colunas
e linhas, e relacionadas por uma coluna chave. A Figura abaixo apresenta uma estrutura de banco de
dados relacional para um sistema acadêmico.
Figura 38 – Exemplo de uma estrutura de banco de dados relacional
128
Fonte: Elmasri e Navathe (2011), p. 5.
No exemplo, a relação se dá por meio de colunas chaves, no caso da tabela Aluno a cha-
ve é o campo “Numero_aluno” que está relacionado a tabela Historico_escolar pelo campo de
mesmo nome. A turma a qual o aluno pertence é identificada também na tabela Historico_Escolar
pelo campo identificação_turma, assim todos os dados de todas tabelas podem ser restaurados de
forma rápida e simples, utilizando-se para tal operação, a Linguagem de Consultas Estruturadas (SQL
– Structured Query Language) (ELMASRI; NAVATHE, 2011; SILBERSCHATZ; KORTH; SUDAR-
SHAN, 2012).
A mudança do paradigma de armazenagem de dados levou à criação de sistemas que arma-
zenassem e realizassem tarefas administrativas e de recuperação desses dados, sendo criados os Sis-
temas Gerenciadores de Banco de Dados (SGBDs). Apesar da literatura tratar em alguns momentos
como SGBDRs (Sistemas Gerenciadores de Banco de Dados Relacionais) ou SGBDORs (Sistemas
Gerenciadores de Banco de Dados Objeto/Relacionais) a estrutura base na forma como os dados
são armazenados se mantiveram como proposto por Codd na década de 70.
129
O mercado apresenta hoje uma gama de SGBDs, variando entre a
capacidade de manipulação de dados, recursos agregados (outros sistemas
que realizam tarefas adicionais a de um SGBD) e integração com determi-
nadas tecnologias, sendo os mais utilizados os seguintes:
- Oracle: SGBD proprietário da Oracle Corporation; por possuir total integração com o mais
utilizado ERP do mercado, o SAP, é bastante utilizado por grandes corporações, apesar da
própria Oracle possuir o seu ERP.
- SQL Server: SGBD proprietário da Microsoft Corporation, pode ser utilizado com o siste-
ma ERP da SAP, mas possui maior integração com outros ERPs como Protheus da TOTVS,
apesar da Microsoft possuir o seu próprio sistema de ERP (Dynamics ERP).
- MySQL: O MySQL, adquirido pela Oracle, tem uma grande popularidade em desenvolve-
dores que utilizam softwares livres, principalmente programadores web nque fazem uso da
linguagem PHP.
- PostgreSQL: projeto open source coordenado pelo PostgreSQL Global Development
Group é considerado um dos SGBDs de código aberto mais avançados. Alguns ERPs de
código fonte aberto utilizam esse SGBD.
O que podemos observar é que os SGBDs são os sistemas centrais de armazenagem de

dados organizacionais, os sistemas MIS, DSS, ESS e etc. apresentam a interface de entrada e saída
de dados, enquanto que os SGBDs fornecem a estrutura para armazenagem. Toda a transformação
dos dados em informações se dará dentro dos SGBDs por meio das suas ferramentas de análise e
linguagem para consulta de dado.
No tópico seguinte vamos conhecer um novo paradigma nessa transformação de dados em
informações.
130
9.1. Um Novo Paradigma
Por mais de 30 anos o modelo relacional proposto por E. F. Codd reinou absoluto entre as
tecnologias para armazenamento e manipulação de dados, mas com a necessidade de um armaze-
namento cada vez maior, diferentes tipos de dados e serviços web com grandes volumes de dados a
serem manipulados (Ex: Facebook, Twitter, Instagram, etc.), o modelo relacional acabou se tornando
inviável para essas aplicações, surgindo um conceito inverso, o NoSQL (Not only SQL) fazendo uma
alusão à inexistência da linguagem de consultas SQL do modelo relacional. O surgimento do NoSQL
não significou a extinção dos sistemas relacionais, que continuam existindo, mas permitiu que novas
formas de dados pudessem ser armazenadas e analisadas em conjunto com a estrutura de tabelas,
colunas, linhas e relacionamentos.
Os sistemas NoSQL são projetados para manipular grandes con-

juntos de dados distribuídos em diferentes computadores, permitindo que
se reduza ou aumente facilmente a quantidade de máquinas e o volume de
dados a ser utilizado (LAUDON; LAUDON, 2015). Assim como existem
diferentes SGBDs relacionais o mesmo ocorre com os sistemas NoSQL, segue alguns exemplos
do mercado:
- Oracle NoSQL: sistema não relacional da Oracle Corporation.

- SimpleDB: sistema não relacional da Amazon. Diferentemente do padrão relacional, no
SimpleDB você não precisa definir uma estrutura prévia de armazenamento de dados ou
alterar caso haja novos tipos de dados.
- MongoDB: sistema não relacional de código fonte aberto, um dos mais utilizados em todo
o mundo.
131
Figura 39 – Sistemas noSQL
Fonte: InformationWeek. Disponível em: <https://www.informationweek.com/big-data/big-da-

ta-analytics/16-nosql-newsqldatabases-to-watch/d/d-id/1269559>. Acesso em: 5. Maio. 2018.
A empresa MetLife, gigante no ramo de seguros de vida, utiliza o NoSQL MongoDB para
reunir em uma só estrutura mais de 70 bancos de dados de diferentes sistemas, incluindo sistemas
administrativos, sistemas de reclamações e outras fontes de dados, abrangendo dados estruturados,
não estruturados, imagens de registros de saúde e atestados de óbitos.
O NoSQL tem como grande diferencial em relação ao SGBD relacional essa capacidade de
se adequar ao tipo de dados a ser armazenado muito mais rapidamente do que o processo moroso
e delicado que seria realizado em um modelo relacional.
Tabela 9 – Sistemas SGBDR versus NoSQL
SGBDR NoSQL
Rígido Flexível
Representação dos dados em partes Representação unificada
Relacional Orientado a objetos
Estruturado Semiestruturado
Maduro (longo tempo de desenvolvimento) Emergente (poucos estudos)
Estável Escalável
Consistente Eventualmente consistente
Fonte: Desenvolvido pelo autor.
132
Diante dos argumentos expostos sobre os SGBDRs e NoSQL você conside-
raria eliminar da sua organização os SGBDs relacionais e migrar os sistemas
existentes para a estrutura NoSQL? Pense a respeito! Reflita e pesquise sobre
o assunto.
9.2. Big Data
Quando falamos em quantidade de dados armazenados em formato digital pensamos em

gigabytes ou terabytes, mas ao tratarmos de Big Data estamos falando de dados na casa dos petaby-
tes ou exabytes e medidas superiores, ou seja, tratamos com trilhões de registros de dados. Apenas
para termos noção do que é um Big Data, vamos observar alguns exemplos:
Um motor a jato pode gerar 10 terabytes de dados em apenas 30

minutos; O Facebook tem mais de 250 bilhões de fotos e a cada dia mais
350 milhões são adicionadas; O Twitter gera mais de 8 terabytes de dados
por dia (LAUDON; LAUDON, 2015, p. 193).
Essas são algumas informações das maiores empresas de tecnologia do mundo, mas o
que se observa é que em todas as organizações a quantidade de dados digitais sendo gerados
a todo dia cresceu exponencialmente, sejam dados de processos internos ou que têm origem
nos diversos canais de relacionamento com o cliente.
A empresa Shutterstock armazena 24 milhões de imagens e a cada dia mais 10 mil, sen-
do que o objetivo desses dados é analisar onde os visitantes do site posicionam o seu cursor e
quanto tempo eles o mantêm sobre determinada imagem antes de fazer uma compra. Assim,
a Shutterstock espera otimizar a experiência do usuário em sua loja virtual.
133
Percebemos que o caso da empresa Shuttershock utiliza dados dos seus sistemas internos,
mas busca em fontes de dados inimagináveis estabelecer um padrão que possa levar a um diferencial
competitivo.
O conceito de Big Data está relacionado a essa capacidade de analisar dados não tradicionais
em conjunto com os dados corporativos tradicionais, mas para tanto são necessárias ferramentas
específicas para esse tipo de análise (LAUDON; LAUDON, 2015). Analisando a literatura sobre o
conceito de Big Data temos mais algumas definições:
Tabela 10 – Conceitos de Big Data
Conceito Fonte
Big Data é o termo que descreve o imenso volu- SAS.
me de dados – estruturados e não estruturados Disponível em: <https://www.sas.com/pt_br/
– que impactam os negócios no dia a dia.
insights/big-data/what-is-big-data.html>. Acesso
em: 04. Jan. 2018.
Big Data = volume + variedade + velocidade + IBM. Disponível em: <https://www.ibm.com/de-
veracidade + valor. veloperworks/community/blogs/ctaurion/entry/
voce_realmente_sabe_o_que_e_big_data?lan-
g=em>. Acesso em: 04. Jan. 2018.
Big Data é um termo amplamente utilizado na Wikipedia.
atualidade para nomear conjuntos de dados Disponível em: <https://pt.wikipedia.org/wiki/
muito grandes ou complexos, que os aplicativos
de processamento de dados tradicionais ainda Big_data>. Acesso em: 04. Jan. 2018.
não conseguem lidar.
Fonte: Desenvolvido pelo autor.
A definição da IBM trata o conceito de Big Data baseado em cinco “Vês”: volume, variedade,
velocidade, veracidade e valor. Vamos analisar como essas palavras compõem a definição de Big
Data.
134
O volume diz respeito a quantidade de dados que são gerados diariamente
em formato digital. Variedade diz respeito aos tipos de dados gerados, po-
dendo ser estruturados (passíveis de serem armazenados em forma de tabe-
las) e os não estruturados (gerados por e-mails, mídias sociais, documentos
eletrônicos, apresentações em powerpoint, mensagens instantâneas, sensores, etiquetas RFID,
câmeras de vídeo, etc.). A velocidade trata a necessidade de que esses dados sejam analisados
em tempo real, caso contrário perdem o seu valor. Veracidade, os dados precisam ter a garantia
de que são autênticos, são consistentes e fazem sentido. O valor está diretamente associado ao
que estamos discutindo nesse guia, a transformação de dados em informações que possam au-
xiliar em processos decisórios que agreguem valor aos negócios, caso contrário a análise dessa
enorme quantidade de dados não teria sentido.
Ressalto que a utilização de sistemas de Big Data está na necessidade de armazenagem e tra-
tamento de dados do tipo ESTRUTURADO e NÃO ESTRUTURADO. A figura a seguir representa
a diferença entre dados estruturados e não estruturados.
Figura 40 – Dados estruturados versus não estruturados
Fonte: : Visão geral sobre a gestão de conteúdo. Disponível em: < http://www.grupotreinar.com.br/blog/2016/4/9/
vis%C3%A3o-geral-sobre-a-gest%C3%A3o-de-conte%C3%BAdo-n%C3%A3o-estruturado-e-ecm.aspx>. Acesso em:
5. Maio. 2018. Adaptado por Design Unis EAD
135
Os dados estruturados estão relacionados a dados armazenados em SGBDs relacionais tra-
dicionais, em que os dados estão relacionados por meio de chaves e estruturados em tabelas.
Enquanto que os dados não estruturados são armazenados em sistemas noSQL e indexados em
estruturas de Big Data.
Sugiro os seguintes vídeos como material extra de estudo:
Vídeo 1: OlharDigital. Disponível em: <https://www.youtube.com/watch?-

v=OMBGEQ3pjMw>. Acesso em: 5. Maio. 2018.
Vídeo 2: Nerdologia. Disponível em: <https://www.youtube.com/watch?v=hEFFCKxYbKM>.
Acesso em: 5. maio. 2018.
Essa unidade nove introduziu o conceito de noSQL, um outro paradigma de

banco de dados que vem se consolidando a alguns anos, e o de Big Data;
assunto este que faz parte do cotidiano de grandes empresas e tende a fazer
parte de negócios menores.
Devemos observar que o fato de uma nova tecnologia estar surgindo e aparentemente
trazer grandes vantagens às tecnologias “antigas”, não deixaremos de utilizar, de um dia para o
outro, os SGBDs relacionais; pelo contrário, eles se fortaleceram e tendem a incorporar recur-
sos de noSQL as suas estruturas.
A aplicação de Big Data em ambientes organizacionais parece um sonho longínquo, mas
que eu vejo como bastante próximo, até porque muitas das gigantes de tecnologia estão vol-
tando os olhos para os pequenos e médios negócios. Isso abrirá muitas portas para a utilização
dessa tecnologia, mas que exigirá profissionais capacitados para entender a demanda e verificar
a viabilidade.
Isso é com vocês!
136
X
Unidade X - Tecnologias
de Armazenamento e
Manipulação de Grandes
Quantidades de Dados
- Apresentar e discutir as principais tecnologias de armazena-

mento de grandes quantidades de dados.
Unidade X - Tecnologias de Armazenamento e Manipulação de Grandes Quantida-
des de Dados
10. Introdução
A partir de agora vamos compreender o processo de transformação dos dados em informa-

ções úteis aos negócios, ou como a literatura preconiza, em inteligência empresarial.
Discutimos anteriormente que os Big Datas lidam com uma grande gama de informações de
todos os tipos e formatos, mas para que seja possível transformar esses dados em uma informação
aplicável aos negócios precisaremos de ferramentas específicas, então vamos compreender cada
uma delas.
10.1. Data Warehouse
Os data warehouses (DW) ou depósitos de dados são considerados elementos centrais de

armazenamento de bancos de dados integrados de múltiplas fontes (ERP, CRM, setor de Finanças,
arquivos dispersos) que por meio de uma camada de integração (ETL) e técnicas analíticas (OLAP
e Data mining) são geradas informações relevantes aos DSS´s (Sistemas de Tomada de Decisão).
Os bancos de dados relacionais são limitados a trabalharem com poucas quantidades de
registros relacionados, enquanto que os DWs são projetados para dar suporte à extração, proces-
samento/transformação e carregamento/organização para fins analíticos de uma grande quantidade
de dados (ELMASRI; NAVATHE, 2011; ELEUTERIO, 2015). A Figura 40 representa essa estrutura
de um DW.
138
Figura 41 - Ambiente de um data warehouse
Dados espalhados Ambiente de data warehouse Camada de

pela empresa apresentação
ERP
Repositório DW
CRM
Transformação
Carregamento
Extração
Data mining
Dados Dados
FIN Brutos Sumarizados
Metadados
Camada de integração (ETL)

Arquivos
Fonte: Eleuterio (2015), p. 161. Adaptado por Design Unis EAD.
DWs são considerados não voláteis pelo fato de que os dados armazenados neles mudam
com pouca frequência, há um processo de atualização que normalmente é realizado pelo método
incremental, ou seja, apenas dados modificados ou novos dados são inseridos no depósito. Para El-
masri e Navathe (2011, p. 721) um DW é “uma coleção de tecnologias de apoio a decisão, visando
habilitar o trabalhador do conhecimento (executivo, gerente, analista) a tomar decisões melhores e
mais rápidas.
A Figura 41 apresenta a estrutura completa de um data warehouse, destacando-se que os
sistemas de processamento on-line (OLAP – visão dos dados sob múltiplos ângulos), sistemas de
apoio a decisão (DSS), sistema de informação executivo (EIS) e o sistema de mineração de dados
(data mining) busca no data warehouse as informações para processamento e análise.
139
Figura 42 - Data Warehouse
Fonte: Elmasri e Navathe (2011), p. 722. Adaptado por Design Unis EAD.
O processo de transformação de dados (depósito do data warehouse) em informação se

dará por meio dos sistemas que leem os dados do DW.
Há no mercado uma série de ferramentas de mineração de dados (data mining), as quais se
destacam (Eleuterio, 2015).
(i) Oracle Data Mining;

(ii) SAP Netweaver Business Warehouse (BW);
(iii) SQL Server Analysis Services,
(iv) Statistica;
(v) Teradata Database;
(vi) IBM SPSS Modeler e;
(vii) RapidMiner, entre outras.
140
A lenda da fralda e da cerveja: Assim que a tecnologia de data warehouse
foi difundida na comunidade científica começaram a surgir casos que de-
monstravam a sua capacidade de análise. O exemplo que foi amplamente
utilizado nas universidades foi o da fralda e da cerveja. Diz a lenda que o
Walmart, por meio do seu data warehouse e da mineração desses dados identificou um pa-
drão nas vendas às sextas-feiras à noite de fraldas e cervejas. Teoricamente as esposas pediam
aos seus maridos que comprassem fraldas no supermercado e o marido ao comprar a fralda
também comprava cerveja para o seu fim de semana. O Walmart então decidiu colocar as
gôndolas de fraldas e cervejas próximas, observando-se um aumento geométrico nas vendas
desses produtos.
O exemplo ilustra a capacidade analítica que um sistema de mineração de dados em um data

warehouse pode ter. Relações de dados que nunca poderiam ser feitas por meio de ferramentas
tradicionais de análise são realizadas em segundos por essas tecnologias.
10.2. Hadoop
As tecnologias de data warehouse e de mineração de dados utilizam SGBDs relacionais para

executarem, muito bem, o seu papel em dados estruturados, ou seja, aqueles tipos de dados que
podem ser colocados na forma de linhas e colunas, porém, a quantidade de dados não estruturados
ou semiestruturados, estão superando os estruturados, de forma que novas tecnologias precisam ser
aplicadas para atender essa demanda.
A solução que vem sendo aplicada pelas gigantes da área de tecnologia como Amazon,
Google, HP, Yahoo e outras é o Hadoop.
141
“Hadoop é uma plataforma de software em Java de computação distribuída voltada para clusters e
processamento de grandes volumes de dados, com atenção a tolerância a falhas. Foi inspirada no
MapReduce e no GoogleFS (GFS) ”.
Figura 43 - Modelo gráfico do MapReduce
Fonte: Adaptado por Design Unis EAD.
142
Figura 44 - Representação gráfica do GoogleFS
Fonte: Adaptado por Design Unis EAD.
Para mais informações sobre MapReduce sugiro a leitura do conteúdo dispo-

nível em: <https://www.devmedia.com.br/hadoop-mapreduce-introducao-a-
big-data/30034>. Acesso em: 5. maio. 2018.
Para mais informações sobre o Google File System (GoogleFS), sugiro a leitura do trabalho
Google File System (GFS). Disponível em: <http://www.lisha.ufsc.br/teaching/os/ine5412-2008-
2/work/gfs.pdf>. Acesso em: 5. maio. 2018.
143
Para Laudon e Laudon (2015, p. 194) o “Hadoop é uma estrutura de software
de código aberto, gerenciado pela Apache Software Foundation que permite
o processamento paralelo distribuído de grandes quantidades de dados por
meio de computadores de baixo custo”.
A ideia por trás do Hadoop é a fragmentação de um big data em subproblemas que são dis-
tribuídos em vários nós de processamento computacional, sendo o resultado de cada nó combinado
em um conjunto de dados menor e mais fácil de analisar O Hadoop é executado em um cluster
barato de processadores que podem ser adicionados ou removidos de acordo com a demanda
computacional (Laudon & Laudon, 2015).
O Hadoop utiliza o sistema de arquivos distribuídos HDFS (Hadoop Distributed File System)
para o armazenamento dos dados nos nós do cluster, e o MapReduce, tecnologia desenvolvida pelo
Google, para processamento de alto desempenho de dados em paralelo. Uma das imagens que
melhor resume o funcionamento do Hadoop é apresentada a seguir.
Figura 45 - Estrutura do hadoop
Fonte: Sri Prakash (2012). Disponível em: <http://ecomcanada.org/blog/tag/hadoop/>. Acesso em 4. maio. 2018. Adaptado por
144 Design Unis EAD.
A figura destaca no início do processo os dados não estruturados que ali-
mentam o Big Data (Engine Hadoop), são dados de todos os tipos arma-
zenados em um único local. Na sequência um nó master do HDFS lê esses
dados e os distribui entre nós slaves para a execução das sub tarefas de
análise e processamento dos dados, realizadas por meio do MapReduce. A busca de dados
é feita por um cliente Hadoop que submete uma consulta ao nó master que por sua vez
consulta os nós slaves que podem consultar outros nós, o resultado é enviado ao nó master
que agrupa os resultados por meio do processo de “redução” e envia ao cliente o resultado.
Apesar de parecer complexo, todo esse processo é realizado em segundos. Quando você
faz uma busca por passagens aéreas na internet ou quando busca instruções para chegar a um res-
taurante, são engines Hadoops trabalhando para que se lhe forneça a melhor informação.
10.3. Computação em Memória (In-memory Computing)
Vislumbramos na última década um aumento inimaginável no poder de processamento e

armazenamento de dados dos hardwares. Tal evolução aconteceu também nas memórias voláteis,
ou memórias de acesso aleatório (RAM – Random Access Memory). Acredito que você já deve ter
percebido que um computador notebook tem um desempenho superior quando possui 8 GigaBy-
tes ou 16 GigaBytes de memória RAM em relação àquele que trabalha apenas com 4 GigaBytes.
O motivo para essa diferença é bem simples, tudo que precisa ser executado em um com-
putador é retirado do disco mecânico (Hard Disk) ou do SSD (Solid State Disk) e é então alocado
na memória principal (RAM) do computador para execução, esse processo de retirada dos dados
do disco e alocação em memória acarreta em um atraso no processamento, comprometendo o
desempenho principalmente quando se tem pouca memória RAM.
A ideia da computação em memória é utilizar a capacidade de memória RAM disponível
nos grandes data centers e realizar o processamento de uma quantidade de dados semelhante a um
data mart ou um pequeno data warehouse totalmente em memória principal, sem o uso de discos,
145
eliminando-se a camada mais lenta do processamento.
Os principais produtos para computação em memória no mercado são:
- HANA (High Performance Analytic Appliance) da SAP;

- Oracle Exalytics;
IBM e Microsoft veem desenvolvendo soluções para computação em memória vinculadas às

suas soluções de SGBDs relacionais.
O SAP HANA é um sistema de gerenciamento de banco de dados relacional, orientado a
colunas e em memória, desenvolvido e comercializado pela SAP. Sua função principal como servi-
dor de banco de dados é armazenar e recuperar dados conforme solicitado pelos aplicativos. Além
disso, ele executa análises avançadas (análise preditiva, processamento de dados espaciais, análise
de texto, pesquisa de texto, análise de fluxo contínuo, processamento de dados gráficos) e inclui
recursos de ETL (extract, transform, load), bem como um servidor de aplicativos (Tradução nossa
de Wikipedia - https://en.wikipedia.org/wiki/SAP_HANA).
O conceito de ETL é visto na teoria sobre Datawarehouse, sendo considerado o processo
de “organização” dos dados para alocação nos data marts, veja figura a seguir.
Figura 46 - Diagrama ETL
Fonte: Wikipedia. Disponível em: < https://en.wikipedia.org/wiki/Extract,_transform,_load#/media/File:Conventional_ETL_Diagram.

146 jpg>. Acesso em: 5. maio. 2018.Adaptado por Design Unis EAD.
Mas qual seriam os reais benefícios e aplicabilidades da computação em
memória?
A princípio podemos observar a questão do desempenho como principal
benefício, sem dúvida que os dados armazenados em memória principal terão uma velocidade
de execução muito superior aos dados armazenados em um SGBD relacional tradicional.
Então o nosso questionamento principal ficaria na aplicabilidade, em que situação é mais viável
a utilização da computação em memória?
A aplicabilidade está relacionada a necessidade de desempenho e respostas em tempo real da

análise dos dados. Observe o caso da Mclaren que utiliza o sistema HANA da SAP para receber
os dados analisados dos seus carros de fórmula 1 em um décimo de segundo após eles serem
gerados, podendo-se realizar ajustes enquanto a corrida acontece, fato este que era impossível
devido a quantidade de dados que precisavam ser analisados em um modelo relacional padrão.
Veja detalhes do SAP HANA em: <https://www.sap.com/brazil/developer/

topics/sap-hana.html>. Acesso em: 5. maio. 2018.
147
Ao contrário da unidade nove, a unidade dez focou em tecnologias
específicas para viabilizar recursos que armazenam grandes quantidades de
dados. Tecnologias como MapReduce, GoogleFS e Hadoop são grandes alia-
das do paradigma noSQL e do conceito de Big Data.
Trata-se de uma estrutura de diferentes recursos que quando utilizados em conjunto
permite essa enorme manipulação e armazenamento de dados em escala inimaginável, e ainda
mais, com um poder de recuperação e apresentação de dados analisados enorme. Quando
digo dados analisados estou me referindo a dados que já passaram por algum tipo de proces-
samento, seja por um algoritmo de inteligência artificial ou por rum mecanismos de indexação.
O profissional do futuro, independente de trabalhar com banco de dados ou não terá
eu observar essas evoluções, afinal de contas a informação é o bem mais precioso da atual
economia.
Não pare de estudar, não pare de se atualizar, continue a observar as mudanças. ;)
148
Referências Bibliográficas
DATE, C. J. (2004). Introdução a Sistemas de Bancos de Dados (1st ed.). Rio de Janeiro: Elsevier.
ELEUTERIO, M. A. M. (2015). Sistemas de informações gerenciais na atualidade (1st ed.). Curitiba:

InterSaberes.
ELMASRI, R., & NAVATHE, S. B. (2011). Sistemas de banco de dados (6th ed.). São Paulo: Pearson
Addison Wesley.
HEUSER, C. A. (2017). Projeto de Banco de Dados (6th ed.). Porto Alegre: Bookman.
LAUDON, K. C., & LAUDON, J. P. (2015). Sistema de informação gerenciais (11th ed.). São Pau-
lo: Pearson Education do Brasil. Retrieved from http://unis.bv3.digitalpages.com.br/users/publica-
tions/9788543005850/pages/-18
SILBERSCHATZ, A., KORTH, H. F., & SUDARSHAN, S. (2012). Sistema de Banco de Dados. Rio
de Janeiro: Campus.

Guia de Estudos Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guia de Estudos Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Banco de dados

Prof. Me. Rodrigo Franklin Frogeri

Todos os direitos desta edição

Doutorando em Sistemas de Informação e Gestão do Conhecimento pela Universidade FUMEC.

Currículo Lattes: http://lattes.cnpq.br/0403458828547468

1. Banco de dados. 2. Projeto de bancos de dados. 3. Linguagem SQL.

Nossa interação será essencial nesse processo.

- Compreender os princípios de uma estrutura de banco de da-

Os primeiros sistemas de banco de dados que utilizariam a SQL só surgiram no

O software SQL Server, MySQL, PostgreSQL são SGBDs, enquanto que a

Nesse tipo de ambiente é instalado um software na máquina de cada cliente e

Figura 1 – Arquitetura em duas camadas/cliente-servidor

Fonte: MACEDO. Disponível em: http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-n-camadas

A próxima arquitetura é a em três camadas, nesse tipo de estrutura temos a inclusão de um

Fonte: MACEDO. Disponível em: http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-n-camadas

No modelo em três camadas a lógica de negócio e a camada de apresen-

A arquitetura em quatro camadas busca resolver os problemas anteriores.

Fonte: MACEDO. Disponível em: http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-n-camadas

Na arquitetura em quatro camadas adiciona-se um servidor web na estrutura de hardware

As quatro camadas seriam: camada de apresentação (servidor web com as

Pense a respeito: Hoje em dia, que arquitetura vem dominando as grandes

1.3. Conceitos e a Propriedade ACID

Muita gente, inclusive profissionais da área de tecnologia consideram o Micro-

Imagine a seguinte situação: Você está realizando uma transferência bancária e

Em uma transação em uma conta bancária, onde o cliente possui um saldo

Esse princípio da imutabilidade era e ainda é um grande problema em sistemas

1.4. Conceitos em Banco de Dados

O primeiro conceito é a abstração de dados. O principal objetivo de um sistema de banco

Alguns sistemas permitem que usuários mais avançados utilizem um interpre-

Figura 4 – Níveis de abstração

Outros termos importantes no contexto de Banco de Dados é o de esquema e instância,

Dizemos que a instância de um BD é como se fosse a fotografia dele naquele

Já o conceito de esquema está relacionado ao projeto geral de um banco de dados, ou seja,

O esquema de um banco de dados pode ser relacionado ao coração de um

se aplicam a esses ambientes.

- Compreender e analisar a aplicação dos diferentes tipos de lin-

O que diferencia uma linguagem da outra?

2.1. Linguagem de Manipulação de Dados

A linguagem de manipulação de dados (Data Manipulation Language, DML) é a linguagem

- DMLs procedurais requerem do usuário a especificação de qual dado é necessário e de como

Um procedimento armazenado ou Stored Procedure, como chamaremos

Fonte: Elaborado pelo próprio autor

- DMLs não-procedurais requerem do usuário a especificação de qual dado é necessário, sem

Exemplo: SELECT * FROM PESSOAS.

2.2. Linguagem de Definição de Dados

Assim, a DDL é a responsável por criar, deletar e alterar partes do esquema

Tabela 1 – Tabela de Alunos

MATRICULA (PK) NOME DATANASCIMENTO

2.3. Linguagem de Transação de Dados

Fonte: Elaborado pelo próprio autor

2.4. Linguagem de Controle de Dados

- GRANT: autoriza ao usuário executar ou realizar operações.

As operações GRANT e REVOKE habilitam ou desabilitam permissões de execução de

DDL DML DCL TC

- Analisar e criar projetos de banco de dados.

Um projeto de banco de dados está relacionado ao desenvolvimento do esquema de arma-

3.1. Modelos de Dados

Figura 8 – Diagrama Entidade-Relacionamento - Modelo Relacional: O modelo rela-

Fonte: Arquivo pessoal do autor

Qual a vantagem de um ou de outro?

3.2. Projeto de Banco de Dados (Passo a Passo)

2° Fase: Na sequência, o projetista ou administrador de banco de dados (DBA), escolhe um modelo

5° Fase: Um esquema conceitual totalmente desenvolvido, também indicará as necessidades funcio-