Principio Banco de Dados

Princípios de Banco
de Dados
Prof. Décio Lehmkuhl

Prof. Djayson Roberto Eger
2013
Copyright © UNIASSELVI 2013
Elaboração:
Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.
005.75
L523p Lehmkuhl, Décio
Princípios de banco de dados / Décio Lehmkuhl; Djayson Roberto.
Indaial : Uniasselvi, 2013.
189 p. : il
ISBN 978-85-7830- 684-7
1. Banco de dados.
I. Centro Universitário Leonardo da Vinci.
Impresso por:
Apresentação
Atualmente existem vários bancos de dados no mundo. Você já parou
para pensar qual é a sua relação com os mesmos ou qual é a importância
deles para a sociedade? Vamos relacionar alguns fatos para evidenciar uma
possível resposta a este questionamento.
A sociedade vive em torno de dados. Sua conta de energia elétrica,

água, telefone e várias outras possuem dados relacionados que formam o
valor a ser pago na fatura. Cada fornecedor desses serviços tem em sua base
de dados o seu cadastro e o consumo que foi utilizado. Logo, pode-se concluir
que o seu cadastro possivelmente existe em inúmeros bancos de dados.
Pense em um documento pessoal, por exemplo, o seu CPF. Ele deve

constar na base de dados da Receita Federal. Se você comprou algum produto
em estabelecimento comercial, o seu CPF provavelmente existe na base de
dados dele. Como foi mencionado acima, existe uma grande “ligação” entre
você e vários bancos de dados.
Isso pode tornar o conteúdo desta disciplina muito interessante.

Serão abordados vários assuntos que vão desde as primeiras formas de
armazenamento de dados até o estado atual de evolução da tecnologia. Você
aprenderá quais são os conceitos de bancos de dados e até poderá programar
a sua própria base de dados.
Sendo assim, temos muito para aprender! Bons estudos!

III
UNI
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades
em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o

material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato
mais prático, que cabe na bolsa e facilita a leitura.
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação
no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir
a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade
de estudá-lo com versatilidade nas telas do celular, tablet ou computador.

Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto
em questão.
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

Desempenho de Estudantes – ENADE.

Bons estudos!
IV
V
VI
Sumário
UNIDADE 1 – FUNDAMENTOS DE BANCO DE DADOS ........................................................... 1
TÓPICO 1 – INTRODUÇÃO A BANCO DE DADOS ..................................................................... 3

1 INTRODUÇÃO ..................................................................................................................................... 3
2 CONCEITOS DE BANCO DE DADOS ........................................................................................... 4
2.1 DADO E INFORMAÇÃO . ............................................................................................................. 4
2.2 BANCOS DE DADOS ..................................................................................................................... 6
3 HISTÓRICO DO GERENCIAMENTO DOS DADOS .................................................................. 8
4 SISTEMA GERENCIADOR DE BANCO DE DADOS ................................................................. 11
4.1 DEFINIÇÕES DE UM SGBD .......................................................................................................... 11
4.2 FUNÇÕES DE UM SGBD ............................................................................................................... 13
4.3 ESTRUTURA DE UM SGBD .......................................................................................................... 14
4.4 TIPOS DE USUÁRIOS DO SGBD . ................................................................................................ 16
5 PRINCIPAIS BANCOS DE DADOS DISPONÍVEIS NO MERCADO ..................................... 16
5.1 MYSQL .............................................................................................................................................. 16
5.2 ORACLE . .......................................................................................................................................... 17
5.3 POSTGRESQL .................................................................................................................................. 18
5.4 SQL SERVER . ................................................................................................................................... 20
LEITURA COMPLEMENTAR ............................................................................................................... 22
RESUMO DO TÓPICO 1 ....................................................................................................................... 24
AUTOATIVIDADE ................................................................................................................................. 25
TÓPICO 2 – EVOLUÇÃO DOS BANCOS DE DADOS .................................................................. 27

1 INTRODUÇÃO ..................................................................................................................................... 27
2 HISTÓRICO DA EVOLUÇÃO DOS BANCOS DE DADOS ...................................................... 28
2.1 PRIMEIRA GERAÇÃO ................................................................................................................... 28
2.2 SEGUNDA GERAÇÃO . ................................................................................................................. 30
2.3 TERCEIRA GERAÇÃO ................................................................................................................... 32
3 ARQUITETURA DE BANCO DE DADOS ...................................................................................... 35
3.1 ARQUITETURA CENTRALIZADA ............................................................................................. 35
3.2 ARQUITETURA CLIENTE-SERVIDOR ....................................................................................... 36
3.3 ARQUITETURA PARALELA ........................................................................................................ 37
3.4 ARQUITETURA DISTRIBUÍDA . .................................................................................................. 38
RESUMO DO TÓPICO 2 ....................................................................................................................... 43
AUTOATIVIDADE ................................................................................................................................. 44
TÓPICO 3 – TENDÊNCIAS E PERSPECTIVAS ................................................................................ 45

1 INTRODUÇÃO ..................................................................................................................................... 45
2 CLASSIFICAÇÃO DOS BANCOS DE DADOS ........................................................................... 46
2.1 BANCOS DE DADOS DE INFORMAÇÕES GEOGRÁFICAS ................................................. 46
2.2 BANCOS DE DADOS MULTIMÍDIA . ......................................................................................... 49
2.3 BANCO DE DADOS TEMPORAL ................................................................................................ 50
2.4 BANCOS DE DADOS BIOLÓGICOS ........................................................................................... 51
VII
2.5 BANCO DE DADOS XML ............................................................................................................. 53
3 TIPOS DE GERENCIAMENTO DE DADOS ................................................................................. 54
3.1 DATA MINING ................................................................................................................................. 55
3.2 DATA WAREHOUSE ....................................................................................................................... 58
3.3 DATA MART . ................................................................................................................................... 60
3.4 DATA MARKETING ........................................................................................................................ 60
4 NOVOS CONCEITOS ......................................................................................................................... 61
4.1 BIG DATA .......................................................................................................................................... 62
4.2 NOSQL .............................................................................................................................................. 64
RESUMO DO TÓPICO 3 ....................................................................................................................... 68
AUTOATIVIDADE ................................................................................................................................. 69
UNIDADE 2 – MODELAGEM DE DADOS ....................................................................................... 71
TÓPICO 1 – MODELOS DE DADOS .................................................................................................. 73

1 INTRODUÇÃO ..................................................................................................................................... 73
2 MODELO CONCEITUAL ................................................................................................................... 74
3 MODELO LÓGICO .............................................................................................................................. 75
4 MODELO FÍSICO ................................................................................................................................. 75
RESUMO DO TÓPICO 1 ....................................................................................................................... 80
AUTOATIVIDADE ................................................................................................................................. 81
TÓPICO 2 – MODELO ENTIDADE-RELACIONAMENTO .......................................................... 83

1 INTRODUÇÃO ..................................................................................................................................... 83
2 MODELO ENTIDADE-RELACIONAMENTO .............................................................................. 83
2.1 ENTIDADE ....................................................................................................................................... 85
2.2 ATRIBUTOS ...................................................................................................................................... 86
2.3 RELACIONAMENTO . ................................................................................................................... 87
3 CONSTRUINDO UM MODELO ENTIDADE-RELACIONAMENTO ..................................... 88
RESUMO DO TÓPICO 2 ....................................................................................................................... 91
AUTOATIVIDADE ................................................................................................................................. 92
TÓPICO 3 – TIPOS DE RELACIONAMENTOS ............................................................................... 93

1 INTRODUÇÃO ..................................................................................................................................... 93
2 CONDICIONALIDADE DO RELACIONAMENTO .................................................................... 93
3 GRAU DO RELACIONAMENTO ..................................................................................................... 95
3.1 RELACIONAMENTO UM PARA UM ......................................................................................... 95
3.2 GRAU UM PARA MUITOS ........................................................................................................... 96
3.3 GRAU MUITOS PARA MUITOS .................................................................................................. 96
4 AUTORRELACIONAMENTO ........................................................................................................... 97
RESUMO DO TÓPICO 3 ....................................................................................................................... 99
AUTOATIVIDADE ................................................................................................................................. 100
TÓPICO 4 – MODELO RELACIONAL ............................................................................................... 101

1 INTRODUÇÃO ..................................................................................................................................... 101
2 BANCO DE DADOS RELACIONAL ............................................................................................... 101
3 TABELA .................................................................................................................................................. 101
4 CHAVE .................................................................................................................................................... 102
4.1 CHAVE PRIMÁRIA . ....................................................................................................................... 102
4.2 CHAVE ESTRANGEIRA ................................................................................................................ 103
VIII
4.3 CHAVE ALTERNATIVA . ............................................................................................................... 105
RESUMO DO TÓPICO 4 ....................................................................................................................... 108
AUTOATIVIDADE ................................................................................................................................. 109
TÓPICO 5 – NORMALIZAÇÃO DE DADOS ................................................................................... 111

1 INTRODUÇÃO ..................................................................................................................................... 111
2 ANOMALIAS DE ATUALIZAÇÃO .................................................................................................. 113
3 APLICAÇÃO DAS FORMAS NORMALIZAÇÃO ........................................................................ 115
4 FERRAMENTAS PARA MODELAGEM DE DADOS .................................................................. 117
4.1 DBDESIGNER .................................................................................................................................. 117
4.2 ERWIN . ............................................................................................................................................. 118
4.3 POWERDESIGNER ......................................................................................................................... 119
RESUMO DO TÓPICO 5 ....................................................................................................................... 121
AUTOATIVIDADE ................................................................................................................................. 122
UNIDADE 3 – SQL .................................................................................................................................. 123
TÓPICO 1 – INTRODUÇÃO À LINGUAGEM SQL ........................................................................ 125

1 INTRODUÇÃO ..................................................................................................................................... 125
2 O QUE É SQL ......................................................................................................................................... 126
3 MODELO DE DADOS DESTA UNIDADE .................................................................................... 126
4 CRIANDO O BANCO DE DADOS .................................................................................................. 127
4.1 CONEXÃO AO BANCO DE DADOS . ......................................................................................... 128
4.2 CRIAÇÃO DE TABELAS ................................................................................................................ 129
5 RESTRIÇÕES ......................................................................................................................................... 136
5.1 CHAVE PRIMÁRIA E RESTRIÇÃO NOT NULL ....................................................................... 136
5.2 CHAVE ESTRANGEIRA ................................................................................................................ 138
5.3 CHAVE ÚNICA ............................................................................................................................... 139
5.4 CHECAGEM DE DADOS .............................................................................................................. 140
RESUMO DO TÓPICO 1 ....................................................................................................................... 144
AUTOATIVIDADE ................................................................................................................................. 145
TÓPICO 2 – MANUTENÇÃO DOS DADOS .................................................................................... 147

1 INTRODUÇÃO ..................................................................................................................................... 147
2 INSERINDO, SELECIONANDO, ATUALIZANDO E DELETANDO DADOS ...................... 147
2.1 VALIDANDO AS RESTRIÇÕES DA TABELA ............................................................................ 147
2.2 TRANSAÇÕES ................................................................................................................................. 152
2.3 CONVERSÃO DE DADOS . ........................................................................................................... 152
2.4 COMANDOS UPDATE E DELETE . ............................................................................................. 154
3 SELEÇÃO DE DADOS ........................................................................................................................ 156
RESUMO DO TÓPICO 2 ....................................................................................................................... 166
AUTOATIVIDADE ................................................................................................................................. 167
TÓPICO 3 – OUTRAS ESTRUTURAS DE DADOS ......................................................................... 169

1 INTRODUÇÃO ..................................................................................................................................... 169
2 OBJETOS DE BANCOS DE DADOS ............................................................................................... 170
2.1 ÍNDICES . .......................................................................................................................................... 170
2.2 SEQUENCES .................................................................................................................................... 172
2.3 VIEWS ............................................................................................................................................... 175
IX
3 PL/SQL .................................................................................................................................................... 177
3.1 PROCEDURES ................................................................................................................................. 178
3.2 FUNCTION ....................................................................................................................................... 179
3.3 PACKAGES ....................................................................................................................................... 180
3.4 TRIGGERS . ....................................................................................................................................... 181
RESUMO DO TÓPICO 3 ....................................................................................................................... 185
AUTOATIVIDADE ................................................................................................................................. 186
REFERÊNCIAS ......................................................................................................................................... 187
X
UNIDADE 1
FUNDAMENTOS DE BANCO
DE DADOS
OBJETIVOS DE APRENDIZAGEM
Esta unidade tem por objetivos:
• apresentar o que é um banco de dados;
• demonstrar como foi a evolução dos bancos de dados;
• apresentar perspectivas e tendências desta tecnologia.
PLANO DE ESTUDOS
Esta unidade está dividida em três tópicos e, em cada um deles, você
encontrará atividades que proporcionarão a compreensão dos conteúdos
apresentados.
TÓPICO 1 – INTRODUÇÃO A BANCO DE DADOS
TÓPICO 2 – EVOLUÇÃO DOS BANCOS DE DADOS
TÓPICO 3 – TENDÊNCIAS E PERSPECTIVAS
1
2
UNIDADE 1
TÓPICO 1
INTRODUÇÃO A BANCO DE DADOS
1 INTRODUÇÃO
“O período de maior ganho de conhecimento e experiência é o período
de maior dificuldade na vida de cada um”. (Dalai Lama)
Esse tópico tem como objetivo apresentar ao(a) acadêmico(a) conceitos de

bancos de dados. Você aprenderá que existe uma grande diferença entre dado e
informação e que a partir deles é possível gerar conhecimento. Compreender isso
é requisito básico para o bom aproveitamento da disciplina.
FIGURA 1 – DADO, INFORMAÇÃO E CONHECIMENTO
FONTE: Os autores
Também será abordado um histórico do gerenciamento dos dados. O

objetivo é que se perceba que vários ciclos de aperfeiçoamento aconteceram para
se chegar ao nível tecnológico que temos hoje.
Para fins conclusivos, veremos quais são os principais bancos de dados

relacionais existentes no mundo. Você perceberá que cada um deles possui focos
diferenciados com características e particularidades que necessitam de uma análise
aprofundada para sua melhor compreensão.
3
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
2 CONCEITOS DE BANCO DE DADOS
2.1 DADO E INFORMAÇÃO

Para entendermos melhor o que é um banco de dados, precisamos antes
compreender a diferença que existe entre dado e informação. Dado é um conteúdo
que ainda não foi processado para gerar um significado. Pode-se dizer que dado é
a menor unidade de conteúdo que tem significado no mundo real. Por exemplo, ao
realizar uma pesquisa para mapear a qualidade de uma biblioteca, normalmente
são feitas entrevistas com seus respectivos usuários. A figura a seguir mostra o
formulário WEB onde os dados da pesquisa podem ser coletados.
FIGURA 2 – FORMULÁRIO DE COLETA DE DADOS PARA A PESQUISA
FONTE: Os autores
4
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
Assim que os usuários responderem à pesquisa, os dados vão sendo

armazenados em um depósito de dados. A figura a seguir representa este
depósito de dados.
FIGURA 3 – DEPÓSITO DE DADOS DA PESQUISA
FONTE: Os autores
Mesmo já possuindo os dados, eles não têm uma utilidade bem definida.
É possível ler linhas e linhas de pesquisa, porém não se tem um real significado
do que ela traz como resultado. A partir desse momento surgem questões como,
por exemplo, qual é o grau de escolaridade dos usuários da biblioteca e como eles
avaliam o atendimento?
Para responder a estas perguntas, precisamos fazer uma análise de todas

as respostas e formatá-las de uma forma mais resumida e de fácil entendimento.
Quando executamos esse processo estamos gerando informação, que é o
processamento de dados para responder a algumas perguntas ou traduzir de
uma forma mais sumarizada o significado dos mesmos. A informação sempre é
gerada com base nos dados. A figura a seguir mostra algumas informações dos
dados da pesquisa.
FIGURA 4 – INFORMAÇÕES DE PARTE DO RESULTADO DA PESQUISA
FONTE: Os autores
5
A informação gera conhecimento. Rob e Coronel (2011, p. 11) nos dizem

que “o conhecimento implica familiaridade, consciência e compreensão das
informações conforme se apliquem a um ambiente”. Quando conseguimos
compreender informações e relacioná-las ao seu contexto, estamos obtendo
conhecimento.
DICAS
As informações podem ser utilizadas para tomada de decisão. No exemplo da

pesquisa da biblioteca, pode ser feita uma análise para descobrir como está a qualidade do
atendimento, e com base nisso, tomar decisões para melhorar os pontos fracos.
2.2 BANCOS DE DADOS

Agora que já sabemos o que são dados, informações, conhecimento e qual
é a diferença entre ambos, precisamos nos concentrar no local onde os dados ficam
armazenados. Anteriormente nos referimos a esse local como depósito de dados,
porém, o mais correto seria chamar de banco de dados. Para definir banco de
dados, buscamos uma explanação mais genérica e abrangente escrita por Elmasri
e Navathe (2011, p. 3):
Um banco de dados é uma coleção de dados relacionados. Com dados,

queremos dizer fatos conhecidos que podem ser registrados e possuem
significado implícito. Por exemplo, considere os nomes, números
de telefone e endereço das pessoas que você conhece. Você pode ter
registrado esses dados em uma agenda ou, talvez, os tenha armazenado
em um disco rígido, usando um computador pessoal e um software
como Microsoft Access ou Excel. Essa coleção de dados relacionados,
com um significado implícito, é um banco de dados.
Um banco de dados também pode ser chamado de base de dados. Os dados

são armazenados de uma maneira que tem como objetivo facilitar a inclusão,
remoção, consulta e alteração. Eles representam aspectos ou fatos do mundo
real, que muitas vezes é denominado de minimundo ou universo de discurso. Só
devemos armazenar no banco de dados o que faz parte do seu minimundo.
Para exemplificar melhor, pense em um sistema de vendas de ingressos

online para cinemas. Nesse minimundo existem características que são importantes
e necessárias para a venda de ingressos, como por exemplo, o nome do filme,
horário em que ele será reproduzido, o local, se é dublado ou legendado etc. Essas
características precisam estar armazenadas para possíveis consultas e alterações.
Já características como a cor das paredes ou o tipo de piso da sala do cinema não
são fatos necessários para posterior consulta em um sistema e não precisam ser
armazenados no banco de dados.
6
Para simplificar a definição, podemos dizer que o minimundo é tudo o que

existe no mundo real que é pertinente para a resolução do problema. A figura a
seguir demostra de forma visual este conceito.
FIGURA 5 – CONCEITO DE MINIMUNDO
FONTE: Os autores
Bancos de dados existem normalmente para serem utilizados por aplicações.

Elas é que realizam consultas e fazem alterações nos dados. Para tornar esse
processo mais simples, existe o Sistema Gerenciador de Banco de Dados (SGDB)
que é um software responsável por manter os bancos de dados que estão sob sua
responsabilidade. Nele existem funções pré-definidas para inserção, remoção,
atualização e consulta dos dados armazenados. A figura a seguir nos dá uma visão
geral da relação entre o SGDB e o seu universo.
FIGURA 6 – SGDB E SEU UNIVERSO
FONTE: Disponível em: <http://www.devmedia.com.br/conceitos-fundamentais-

de-banco-de-dados/1649>. Acesso em: 18 nov. 2012.
7
Detalhes do funcionamento e filosofias do SGDB serão vistos em tópicos

posteriores. Por hora, somente memorize que SGDB é um software responsável
pelo gerenciamento de bases de dados.
3 HISTÓRICO DO GERENCIAMENTO DOS DADOS

Conseguimos de forma introdutória definir alguns conceitos básicos
relacionados a banco de dados. Vimos que existe um Sistema Gerenciador de Banco
de Dados que é responsável pelo gerenciamento dos dados. Para a tecnologia
chegar a esse patamar, passou por diversos processos evolutivos que tiveram
como resultado a organização que temos hoje.
Voltando no tempo, quando a informática estava dando seus primeiros

passos, os sistemas eram desenvolvidos para atender a demandas isoladas, com
foco na resolução de problemas dentro de determinadas áreas.
Para evidenciar de forma mais clara essa ideia, considere a seguinte

situação: um gerente da área de vendas de uma determinada empresa precisa ter
informações mais detalhadas dos vendedores que ele gerencia e das vendas que
são efetuadas. Todos os dados estão armazenados fisicamente em pastas que se
encontram dentro de gavetas de arquivos.
Com muito trabalho, ele consegue examinar todas as suas pastas e extrair
as informações de que necessitava. Acontece que de uma hora para outra suas
vendas aumentaram muito, fazendo com que fosse necessária a contratação de
novos profissionais. Nesse novo cenário, o gerente não consegue mais obter as
informações necessárias dos vendedores e suas vendas, pois o volume cresceu de
tal forma que tornou inviável a análise manual dos dados.
Esse acontecimento faz com que seja necessário um sistema de computador.

Sendo assim, é feita a conversão do sistema de arquivos manual para um sistema de
informação. Esse novo sistema ainda não utilizava um SGBD (o conceito de SGBD será
visto mais à frente). Todos os dados eram gravados em arquivos e cada programa que
era construído poderia ter um formato diferente de organização para a gravação. Rob
e Coronel (2011, p. 12) fazem um relato do que aconteceu naquela época.

A conversão de um sistema de arquivos manual para um sistema de
arquivos computadorizado correspondente pode ser tecnicamente
complexa (como as pessoas estão habituadas as interfaces relativamente
amigáveis dos computadores de hoje, se esqueceram de quão hostis
eram essas máquinas!). Isso gerou um novo tipo de profissional,
conhecido como especialista em processamento de dados (PD), que
devia ser contratado ou “desenvolvido” a partir da equipe atual. O
especialista em PD criava as estruturas de arquivos computacionais
necessárias, escrevendo o software que gerenciava os dados dentro
dessas estruturas e projetava aplicativos que produziam relatórios
com base nos dados dos arquivos. Assim, surgiram vários sistemas
computadorizados “domésticos”.
8
De uma forma resumida, podemos dizer que existiam programas de

computadores gravando dados em arquivos e eles eram responsáveis por toda a
estrutura e complexidade de gravação. A figura a seguir ilustra essa abordagem.
FIGURA 7 – GERENCIAMENTO DE DADOS EM SISTEMA DE ARQUIVOS
FONTE: Os autores
Seguindo essa linha, podemos concluir que se a estrutura de dados de

um arquivo fosse alterada, todos os programas que utilizassem esse arquivo
precisariam ser atualizados, pois deixariam de funcionar. Para fins de exemplo,
imagine que existe um arquivo com os dados de clientes. Foi solicitado que seja
inclusa uma observação para cada cliente. Tomando como base a figura anterior, é
feita uma alteração no programa que está rodando no computador 1 e logicamente
no arquivo cliente. A partir desse momento o programa que está no computador
2 para de funcionar, pois ele ainda trabalha com a estrutura de dados antiga. Em
casos mais complexos, ele poderia “corromper” o arquivo cliente, porque não tem
conhecimento da nova estrutura de armazenamento.
Esse problema é conhecido pelo nome de dependência estrutural, em que

independente do tipo de alteração que seja feita no arquivo, todos os programas
precisarão ser alterados. Isso abre margem para erros, tornando todo o processo
mais caro e difícil de ser executado. O desejado seria a independência estrutural,
em que qualquer alteração de estrutura não influenciaria no acesso aos dados.
Como foi mencionado anteriormente, na época, quando o armazenamento

de dados era feito em simples arquivos, os sistemas eram desenvolvidos de forma
isolada, com focos bem distintos. Isso significa que o gerente da área de vendas
tinha o seu sistema, o de recursos humanos tinha outro e o financeiro poderia
ter outro específico para a sua necessidade. Conhecendo este cenário, podemos
imaginar que o gerente de vendas possui dados dos seus vendedores e que o de
recursos humanos também. Como ambos trabalham em sistemas distintos, cada
um tem a sua versão dos dados, ou seja, o nome do vendedor está armazenado no
sistema de vendas e no de recursos humanos.
9
Redundância de dados é o termo utilizado quando temos o mesmo dado

armazenado em mais de um local. Rob e Coronel (2011, p.18) fazem um alerta para
possíveis problemas que a redundância de dados pode gerar.
A estrutura do sistema de arquivos dificulta a combinação de dados

a partir de várias fontes e sua falta de segurança torna o sistema de
arquivos vulnerável a falhas. A estrutura organizacional realiza o
armazenamento dos mesmos dados em locais diferentes. Os profissionais
de bancos de dados utilizam o termo ilhas de informação para se referir
a essa localização dispersa dos dados. Como é improvável que os dados
armazenados em locais diferentes sejam sempre atualizados de modo
consistente, as ilhas de informação, em geral, contém versões diferentes
dos mesmos dados [...].
Pode acontecer, por exemplo, que um vendedor tenha uma alteração no seu
nome. Essa alteração pode ter sido feita apenas no sistema de vendas, enquanto
que no de recursos humanos o nome continua desatualizado. A figura a seguir
documenta essa estrutura.
FIGURA 8 – REDUNDÂNCIA DE DADOS
FONTE: Os autores
A complexidade do gerenciamento de dados é alta no exemplo apresentado

acima. Seria mais correto o dado estar armazenado em um único local para que
todas as aplicações o consumissem.
10
Outro ponto a ser observado quanto ao armazenamento de dados em

arquivos se refere à concorrência de acesso, ou seja, mais de um usuário tentando
acessar o mesmo dado em um mesmo momento. Um exemplo clássico dessa
situação é a manutenção de saldo de uma conta bancária.
Imagine uma conta bancária que tem um saldo de R$ 1.500,00. Se dois

clientes retirarem dinheiro dessa conta ao mesmo tempo, teremos um problema
de inconsistência dos dados. Vamos ver na prática como isso acontece: o cliente 1
e o cliente 2 fazem uma busca no saldo da conta e ambos têm como resultado R$
1.150,00. O primeiro retira R$ 300,00 da conta e o segundo R$ 150,00. Dependendo
de qual cliente finalize a operação por último o saldo da conta poderá ser R$ 850,00
(R$ 1.500,00 – R$ 300,00) ou R$ 1.000,00 (R$ 1.150,00 – R$ 150,00).
O correto seria que quando está sendo feita a manutenção do saldo pelo
cliente 1, o cliente 2 ficasse aguardando a manutenção terminar para daí sim
iniciar o seu procedimento. Em um sistema de arquivos isso é muito complicado
de gerenciar.
Até agora vimos como era o armazenamento de dados em arquivos

juntamente com algumas características negativas desse modelo. Percebemos
que a dependência estrutural dos dados, a redundância e o acesso concorrente
são fatores dificultadores que podem causar vários erros nos sistemas. Visando
diminuir a complexidade no gerenciamento de dados surge o SGBD ou Sistema
Gerenciador de Banco de Dados. Esse será o nosso próximo assunto. Por enquanto,
entenda que compreender o funcionamento de sistemas que gravam dados em
arquivos é muito útil para evitarmos os mesmos problemas quando iniciarmos o
trabalho com SGBD.
4 SISTEMA GERENCIADOR DE BANCO DE DADOS
4.1 DEFINIÇÕES DE UM SGBD

Um Sistema Gerenciador de Banco de Dados é um software responsável pelo
gerenciamento de base de dados. Uma das principais características dele é retirar
da aplicação à estruturação dos dados, deixando de forma transparente o acesso
aos mesmos. A figura a seguir mostra graficamente onde o SGBD está inserido.
11
FIGURA 9 – SGBD
FONTE: Os autores
O SGBD elimina boa parte da complexidade do gerenciamento de dados,

fazendo com que o programador tenha um foco maior na lógica da sua aplicação
do que no armazenamento dos dados.
Ao falarmos de SGBD precisamos entender como funciona a forma básica

de armazenamento nesse novo tipo de organização. Ao invés de gravarmos dados
em arquivos, gravamos em tabelas. Uma tabela possui colunas e registros. Vamos
resumir a organização de armazenamento de dados de um SGBD:
• Um banco de dados é formando por uma ou mais tabelas.

• Tabelas são locais onde os dados ficam logicamente armazenados.
• Colunas são campos que armazenam um determinado tipo de dado.
• Registros são linhas, que de uma forma mais resumida, pode-se dizer que são
conjuntos de campos preenchidos.
A figura a seguir esclarece esse conceito.
FIGURA 10 – FORMA BÁSICA DE ARMAZENAMENTO DE DADOS
FONTE: Os autores
12
4.2 FUNÇÕES DE UM SGBD

A seguir listamos algumas funções do SGBD:
• Manutenção do dicionário de dados – toda aplicação que desejar trabalhar com

o banco de dados fará isso por intermédio do SGBD. Ele mantém definições
de estruturas de dados e como eles estão relacionados. Qualquer alteração de
estrutura é automaticamente atualizada no dicionário de dados. Isso retira
a responsabilidade dos programas que necessitam dos dados de manter a
estrutura de organização dos mesmos. Essa é a função do SGBD que tem toda
a estrutura dos dados em seu dicionário de dados. A figura a seguir traz um
exemplo do dicionário de dados de um banco Mysql.
FIGURA 11 – DICIONÁRIO DE UM BANCO DE DADOS MYSQL
FONTE: Os autores
• Segurança – O SGBD é responsável por garantir regras de segurança no que

diz respeito ao acesso a dados e a objetos do banco. Cada usuário deve utilizar
algum meio para se autenticar no SGBD, seja por login e senha ou através de
leitura biométrica. Ao se autenticar, existem regras que definem os acessos, ou
seja, quais bases estão visíveis, quais tabelas ou qualquer outra característica que
estará disponível. Também existem controles em nível de objeto. O usuário pode
ter acesso somente à leitura em um determinado objeto e gravação/leitura em
vários outros.
13
• Apresentação dos dados em vários formatos – Um exemplo clássico deste

conceito se refere ao trabalho com datas. Para clarificar, vamos pensar em uma
data: 21 de dezembro de 2012. Essa data aqui no Brasil pode ser digitada por
um usuário como 21/12/2012, enquanto que nos Estados Unidos a mesma seria
12/21/2012. O SGBD consegue manipular ambas as datas de forma transparente,
desde que configurado corretamente.
• Controle de acesso simultâneo ao mesmo dado – garante a integridade e

consistência dos dados armazenados no banco quando acessados de forma
concorrente. Isso resolve o problema apresentado no título “3 HISTÓRICO DO
GERENCIAMENTO DOS DADOS”, que descrevia o acesso de dois usuários na
manutenção do saldo de uma conta bancária em um sistema de arquivos.
• Gerenciamento de backups – o SGBD fornece ferramentas para que o administrador

do banco de dados possa configurar e efetuar backups. Se for feito o backup, outra
funcionalidade existente é a de retornar os dados que o mesmo salvou. Isso pode
ser necessário por vários motivos como, por exemplo, falhas de hardware ou
manipulação da base de dados de forma incorreta.
• Linguagem de acesso e manipulação dos dados – é fornecida pelo SGBD uma

linguagem estruturada para consulta e alteração dos dados. Através dela, é possível
que o utilizador tenha acesso aos dados de uma forma mais simplificada. O SQL
(Structured Query Language) é uma espécie de linguagem padrão para este fim.
Alguns SGBDs fornecem outra linguagem de programação para possibilitar
a implementação de rotinas que executem no servidor do banco. Isso pode
viabilizar a criação de aplicações mais performáticas, pois ao invés de consumir
processamento e recursos de rede da máquina do usuário, boa parte do programa
roda no servidor.
4.3 ESTRUTURA DE UM SGBD

Os sistemas gerenciadores de bancos de dados são compostos, de uma
forma geral, por módulos com funcionalidades bem definidas. Cada módulo
tem sua responsabilidade no processo de gerenciamento dos dados. Usuários e
programadores interagem com esses módulos a fim de obter seus resultados. A
figura a seguir detalha essa estrutura.
14
FIGURA 12 – ESTRUTURA DE UM SGBD
FONTE: Disponível em: <http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula5.html>.

Acesso em: 18 nov. 2012.
Vamos detalhar os módulos apresentados na figura anterior.
• Programas aplicativos/consultas – Um usuário comum normalmente utiliza

um sistema e é através desse sistema que o acesso ao banco de dados é feito.
Já um programador tem ferramentas que são específicas para trabalhar com
a tecnologia que o SGBD disponibiliza. Essas ferramentas tem um foco mais
centrado na visualização de dados e manutenção de suas estruturas.
• Processador/otimizador de consultas – Interpreta todos os acessos que são feitos

na base de dados com um foco maior em otimização. Em outras palavras, ele é
responsável por processar e definir “caminhos” para que o usuário tenha uma
resposta a sua solicitação com performance.
• Software para acessar os dados – Esse módulo é o responsável por recuperar

os dados do local onde eles estão armazenados. Esses dados são divididos em
dois grupos: os dados armazenados e a definição dos dados armazenados. O
primeiro grupo se refere aos dados que um usuário comum manipula, como
por exemplo, nomes de pessoas, cidades, endereços, telefones etc. Já o segundo
define a forma de organização dos dados do primeiro grupo. É composto por
tabelas, índices, relacionamentos etc.
15
4.4 TIPOS DE USUÁRIOS DO SGBD

Existem vários tipos de usuários que acessam bancos de dados. Alguns têm
um foco mais gerencial, enquanto outros apenas se concentram na manipulação
de dados da base. A seguir detalhamos alguns tipos de usuários e suas
responsabilidades ou necessidades.
• Administrador do banco de dados (DBA – Database Administrator) – Essa figura

é responsável por toda a administração do banco de dados. Atividades como
instalação, configuração e melhorias em performance fazem parte do seu dia
a dia. Também possui tarefas relacionadas ao gerenciamento de acesso de
usuários na base e um constante monitoramento visando garantir uma alta
disponibilidade do sistema.
• Projetista ou analista de dados – É o profissional que tem como tarefa fazer o

mapeamento dos dados que deverão ser armazenados no banco. Em seguida,
vem à definição da estrutura onde os mesmos serão “organizados”. Isso envolve
a criação/manutenção de tabelas e demais objetos de acordo com a tecnologia
do SGBD. Este usuário tem um grande foco em performance, pois quando vai
definir a estrutura de organização dos dados é crucial que ela seja performática.
• Programador – É a figura que constrói o sistema que irá acessar o banco de

dados. É imprescindível que o sistema desenvolvido manipule os dados de
forma correta, para evitar a perda ou falta de confiança neles.
• Usuário comum – Utiliza o sistema que foi desenvolvido pelo programador para
acessar o banco de dados. Normalmente desconhece as estruturas onde os dados
estão armazenados. Consegue manipular somente o que o sistema permite. Ele é
a sua fronteira com o SGBD.
5 PRINCIPAIS BANCOS DE DADOS DISPONÍVEIS NO

MERCADO
Atualmente existem vários fornecedores de bancos de dados. Isso
significa que é necessária uma boa análise antes de decidir qual banco utilizar.
Cada um tem as suas características e peculiaridades. Alguns são apropriados
para projetos menores, outros não. O custo para implantação também deve ser
levado em conta. A seguir, vamos ver uma breve descrição dos principais SGBDs
disponíveis no mercado.
5.1 MYSQL
É um dos SGBDs mais populares do mundo. Inicialmente foi desenvolvido
para aplicações de pequeno porte, porém já superou há muito tempo essa barreira.
16
O MySQL teve origem quando os desenvolvedores David Axmark,

Allan Larsson e Michael “Monty” Widenius, na década de 90,
precisaram de uma interface SQL compatível com as rotinas ISAM que
utilizavam em suas aplicações e tabelas. Em um primeiro momento,
tentaram utilizar a API mSQL, contudo a API não era tão rápida quanto
eles precisavam, pois utilizavam rotinas de baixo nível (mais rápidas
que rotinas normais). Utilizando a API do mSQL, escreveram em C e
C++ uma nova API que deu origem ao MySQL.
Com o ótimo resultado gerado por essa nova API, o MySQL começou a
ser difundido e seus criadores fundaram a empresa responsável por sua
manutenção, que é a MySQL AB. (MILANI, 2007, p. 23).
Como foi citado acima, a empresa que mantinha inicialmente o Mysql era
a Mysql AB. Ela foi comprada pela Sun em janeiro de 2008. Em abril de 2009, a
Oracle, que é uma das gigantes do mundo de bancos de dados comprou a Sun,
sendo hoje responsável pela manutenção do MySql.
Atualmente, o Mysql se encontra na versão 5.6 e é muito utilizado em

aplicações WEB. Roda em várias plataformas como Linux e Windows. É livre para
uso não comercial. O site oficial é <http://www.mysql.com>.
5.2 ORACLE
Hoje, é um dos bancos de dados mais robustos e confiáveis do mundo
corporativo. Nasceu da ideia de um homem que percebeu que o mercado
precisava desse tipo de tecnologia.
Há quase trinta anos, Larry Ellison vislumbrou uma oportunidade que

outras companhias não haviam percebido, quando encontrou uma descrição
de um protótipo funcional de um banco de dados relacional e descobriu que
nenhuma empresa tinha se empenhado em comercializar essa tecnologia.
Ellison e os cofundadores da Oracle, Bob Miner e Ed Oates, perceberam que
havia um tremendo potencial de negócios no modelo de banco de dados
relacional, mas não se deram conta de que mudariam a face da computação
empresarial para sempre. Hoje a Oracle (Nasdaq: ORCL) continua à frente de
seu tempo. A tecnologia Oracle pode ser encontrada em quase todos os setores
do mundo inteiro e nos escritórios de 98 das empresas citadas na lista “Fortune
100”. A Oracle é a primeira empresa de software a desenvolver e empregar
software empresarial totalmente habilitado para Internet em toda a sua linha
de produtos: banco de dados, aplicativos empresariais e ferramentas para
desenvolvimento de aplicativos e suporte a decisões. A Oracle é o principal
fornecedor de software para gerenciamento de informações e a segunda maior
empresa de software independente do mundo.
FONTE: Disponível em: <http://www.oracle.com/br/corporate/press/story-346137-ptb.html>.
Acesso em: 16 jan. 2013.
17
O Oracle possui uma vasta lista de recursos. Tem a linguagem PL/SQL para
desenvolvimento de funcionalidades internas. Integra-se com outras linguagens
de programação como JAVA, C, C++ etc. Roda em várias plataformas. O site oficial
é <http://www.oracle.com>.
5.3 POSTGRESQL
É conhecido pela sua robustez e confiabilidade e tem uma característica
bem interessante: é um SGBD de código fonte aberto. O texto a seguir descreve
esse banco de dados com uma maior riqueza de detalhes.
UNI
Leia a seguir um texto retirado do site da comunidade brasileira de

PostgreSql.
O QUE É O POSTGRESQL?
Para alguns pode parecer um assunto batido, mas esse é um artigo

introdutório, voltado principalmente àqueles que conhecem pouco ou nada
sobre o PostgreSQL. O PostgreSQL é um SGBD (Sistema Gerenciador de
Banco de Dados) objeto-relacional de código aberto, com mais de 15 anos
de desenvolvimento. É extremamente robusto e confiável, além de ser
extremamente flexível e rico em recursos. Ele é considerado objeto-relacional
por implementar, além das características de um SGBD relacional, algumas
características de orientação a objetos, como herança e tipos personalizados.
A equipe de desenvolvimento do PostgreSQL sempre teve uma grande
preocupação em manter a compatibilidade com os padrões SQL92/SQL99.
HISTÓRICO DO POSTGRESQL
O PostgreSQL (conhecido anteriormente como Postgres95) derivou

do projeto POSTGRES da universidade de Berkley, cuja última versão foi
a 4.2. O POSTGRES foi originalmente patrocinado pelo DARPA (Agência
de Projetos de Pesquisa Avançada para Defesa), ARO (Departamento
de Pesquisa Militar), NSF (Fundação Cinetífica Nacional) e ESL Inc. A
implementação do projeto POSTGRES iniciou em 1986, já em 87 tornou-se
18
operacional. A primeira versão lançada para o público externo foi em 1989.

Devido a uma crítica feita ao seu sistema de regras, o POSTGRES teve essa
parte reimplementada e lançada em uma segunda versão em 1990. Em 1991
foi lançada a versão 3, com melhorias no executor de consultas e algumas
partes do código foram reescritas. As versões subsequentes, até o Postgres95,
foram focadas em confiabilidade e portabilidade. O POSTGRES foi utilizado
para diversos sistemas de pesquisa e de produção, uma aplicação de
análise financeira, um banco com rotas de asteroides, e diversos sistemas
de informações geográficas. O código do POSTGRES foi aproveitado
em um produto comercializado pela Illustra Information Technologies
(posteriormente incorporada à Informix, que agora pertence à IBM).
A versão seguinte, o Postgres95, teve mudanças radicais em relação ao

projeto original. O seu código foi totalmente revisado, o tamanho das fontes foi
reduzido em 25%, e a linguagem SQL foi implementada como interface padrão.
A performance foi consideravelmente melhorada e vários recursos foram
adicionados. Em 1996. o nome Postgres95 tornou-se inadequado, o projeto foi
rebatizado “PostgreSQL”, para enfatizar a relação do POSTGRES original com
a linguagem SQL. A numeração da versão voltou a seguir o padrão anterior
ao Postgres95 (considerada a 5.0), e a primeira versão do PostgreSQL foi a 6.0.
Enquanto a ênfase do Postgres95 tinha sido a correção de falhas e otimização do
código, o desenvolvimento das primeiras versões do PostgreSQL foi orientada
à melhoria de recursos e implementação de novos recursos, sempre seguindo
os padrões de SQL anteriormente estabelecidos.
O POSTGRESQL HOJE
A equipe do projeto cresceu e se espalhou pelo mundo. O Grupo Global de

Desenvolvimento do PostgreSQL tem membros nos Estados Unidos, Canadá,
Japão, Rússia, vários países da Europa e alguns outros. Esse grupo é formado
essencialmente por empresas especializadas em PostgreSQL, empresas usuárias
do sistema, além dos pesquisadores acadêmicos e programadores independentes.
Além da programação, essa comunidade é responsável pela documentação,
tradução, criação de ferramentas de modelagem e gerenciamento, e elaboração
de extensões e acessórios.
Pela riqueza de recursos e conformidade com os padrões, ele é um

SGBD muito adequado para o estudo universitário do modelo relacional,
além de ser uma ótima opção para empresas implementarem soluções de alta
confiabilidade sem altos custos de licenciamento. É um programa distribuído
sob a licença BSD, o que torna o seu código fonte disponível e o seu uso
livre para aplicações comerciais ou não. O PostgreSQL foi implementado em
diversos ambientes de produção no mundo, entre eles, um bom exemplo do
seu potencial é o banco de dados que armazena os registros de domínio .org,
mantido pela empresa Afilias.
19
Alguns recursos presentes na versão mais recente:

Subconsultas.
Controle de concorrência multiversão (MVCC).
Integridade Referencial.
Funções armazenadas (Stored Procedures), que podem ser escritas em
várias linguagens de programação (PL/PgSQL, Perl, Python, Ruby, e outras).
Gatilhos (Triggers).
Tipos definidos pelo usuário.
Esquemas (Schemas).
Conexões SSL.
Áreas de armazenamento (Tablespaces).
Pontos de salvamento (Savepoints).
Commit em duas fases.
Arquivamento e restauração do banco a partir de logs de transação.
Diversas ferramentas de replicação.
Extensões para dados geoespaciais, indexação de textos, xml e várias outras.
COMO COMEÇAR?
No site nacional do projeto podem ser encontrados tutoriais de instalação

nas plataformas Linux e Windows, além do manual de referência traduzido.
No site oficial, você encontra toda a documentação. Para baixar o código fonte
do PostgreSQL, você pode utilizar o mirror brasileiro. Depois de seguir as
instruções de instalação do tutorial, você pode escolher uma boa ferramenta
gráfica de gerenciamento.
Alguns links úteis:

Site Oficial (<http://www.postgresql.org>)
Site de marketing (<http://advocacy.postgresql.org/?lang=br>)
Site nacional (<http://www.postgresql.org.br>)
Lista de discussão nacional (<http://br.groups.yahoo.com/group/
postgresql-br>)
FONTE: Disponível em: <http://wiki.postgresql.org.br/Introdu%C3%A7%C3%A3o_e_hist%C3%B3rico>.

Acesso em: 16 jan. 2013.
5.4 SQL SERVER

É o banco de dados da empresa Microsoft. É considerado um dos principais
concorrentes da Oracle. O texto a seguir descreve o SQL Server.
20
TODA A HISTÓRIA DO SISTEMA SQL DA MICROSOFT
Você sabe o que é o SQL Server? Se você tem um blog ou um site que utiliza
banco de dados já deve ter, pelo menos, ouvido falar nele. O MS SQL Server
é um sistema de gerenciamento de banco de dados relacional desenvolvido
pela Microsoft. A partir da versão 2008 a plataforma de dados com alta
confiabilidade e que permite a redução de custos com eficiência e robustez.
Tudo começou em março de 1987 quando a Microsoft comprou os direitos

do DataServer da Sysbase para o sistema operacional OS/2. O objetivo era
provocar o interesse e chamar a atenção da comunidade do dBase. Por isso a
Microsoft traçou um acordo com a Ashton-Tate como forma de endossar esse
novo processo. Assim, a primeira versão do SQL Server se chamava Ashton-
Tate/Microsoft SQL Server e chegou ao mercado na metade final de 1988. Em
maio do ano seguinte a versão 1.0 para OS/2 era lançada com parca participação
da Microsoft (limitando-se apenas a poucas ferramentas, testes e o projeto
visando tornar o aplicativo mais simples de ser instalado). Na segunda metade
de 1990 a união da Microsoft com a Ashton-Tate se encerrou e a versão 1.1
do SQL Server passou a oferecer suporte para o Windows 3.0 (que era uma
novidade na época). Apesar disso, a base do SQL era produzida pela Sysbase
e a Microsoft sequer tinha acesso ao código-fonte. Qualquer defeito tinha que
ser relatado para a Sysbase e corrigido apenas por ela. Só em 1991 a Microsoft
passou a poder acessar a fonte do SQL apenas para leitura.
Com o lançamento da versão 4.2 para OS/2 no fim de 1991 a Microsoft

já desenvolvia o banco de dados em conjunto com a Sysbase, o que só mudou
em agosto de 1993 quando a Microsoft finalmente conseguiu a totalidade da
criação do SQL Server e lançou a versão para o Windows NT 3.1. Essa nova
versão já era em 32-bit. Assim, pouco tempo depois, a parceria entre as duas
empresas acabava.
Podemos declarar como principais vantagens do SQL Server o

fornecimento de uma plataforma de grande confiabilidade e robustez capaz de
suportar aplicações de missão crítica de grande exigência. A possibilidade de
encriptação dos dados contidos em todo o banco de dados ou nos arquivos de
log. Isso protege os dados das solicitações não autorizadas sem a necessidade
de aplicativos complementares. Além disso, ele permite o espelhamento do
banco de dados a recuperação automática da página de dados e a compressão
do fluxo de logs. Um aumento na produtividade com a rapidez e simplicidade
de instalação, manutenção e uso. Também possui uma enorme versatilidade
na aceitação de informações e no oferecimento de respostas previsíveis as
demandas dos usuários.
21
As aplicações vão desde criar aplicações que se utilizem de um banco

de dados de forma rápida e simples até aplicações de alta complexidade com
a mesma facilidade. Da mesma forma o SQL Server garante que seus dados
podem ser acessados de qualquer lugar mesmo estando baseados a distância e
serem acessados por uma enorme variedade de aplicativos diferentes o que o
torna muito prático e de fácil uso para hospedagem de sites na internet.
FONTE: Disponível em: <http://www.artigonal.com/advertising-artigos/toda-a-historia-do-sistema-
sql-da-microsoft-1845126.html>. Acesso em: 16 jan. 2013.
UNI
Caro(a) acadêmico(a)! A Leitura Complementar a seguir traz uma visão clara

de questões relacionadas à utilização de um sistema de banco de dados. A seguir serão
apresentados alguns fatores que devem ser analisados quando trabalhamos com esse tipo de
tecnologia.
LEITURA COMPLEMENTAR
GERENCIAMENTO DO SISTEMA DE BANCO DE DADOS: UMA

MUDANÇA DE FOCO
A introdução de um sistema de banco de dados em um ambiente de sistema

de arquivos fornece um modelo no qual podem ser aplicados procedimentos e
padrões rígidos. Como consequência, o papel do componente humano muda da
ênfase em programação (no sistema de arquivos) para focar nos aspectos mais
amplos de gerenciamento dos recursos de dados da organização e na administração
do próprio software do banco de dados complexo.
O sistema de banco de dados torna possível atingir usos muito mais

sofisticados dos recursos de dados contanto que seja projetado para aproveitar
esse poder disponível. Os tipos de estruturas de dados criados no banco de dados
e a extensão dos relacionamentos entre elas desempenham um papel poderoso na
determinação da eficiência do sistema.
Embora o sistema de banco de dados apresente vantagens consideráveis em

relação à abordagem de gerenciamento anteriores, também trazem desvantagens
significativas. Por exemplo:
22
Aumento de custos: os sistemas de banco de dados exigem hardware e

software sofisticado e pessoal altamente treinado. O custo de manutenção do
hardware, software e pessoal necessários para operar e gerenciar um sistema de
banco de dados pode ser substancial. Os custos de treinamento, licenciamento
e atendimento as regulamentações costumam ser negligenciados quando da
implementação desses sistemas.
Complexidade do gerenciamento: os sistemas de banco de dados apresentam

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

do sistema de banco de dados, deve-se manter o sistema atualizado. Portanto, é
necessário fazer atualizações frequentes e aplicar os últimos pacotes e medidas de
segurança a todos os componentes. Como a tecnologia do banco de dados avança
rapidamente, os custos com treinamento de pessoal tendem a ser significativos.
Dependência do fornecedor: Em virtude do alto investimento em tecnologia

e treinamento de pessoal, as empresas podem hesitar em trocar os fornecedores de
banco de dados. Por essa razão, é menos provável que estes ofereçam vantagens
de preço aos clientes existentes, que ficarão restritos quanto a suas escolhas de
componentes de sistema de banco de dados.
Ciclos frequentes de atualização/substituição: os fornecedores de SGBDs

atualizam seus produtos adicionando novas funcionalidades. Em geral, esses
recursos são integrados a novas versões de atualização de software. Algumas
dessas versões exigem atualizações de hardware. Não são apenas as atualizações
que geram custo, mas também o treinamento dos usuários e administradores para
que utilizem e gerenciam adequadamente os novos recursos.
FONTE: Rob e Coronel (2011, p. 18)
23
RESUMO DO TÓPICO 1
Neste tópico, você viu que:
• Existe uma grande diferença entre dado, informação e conhecimento.
• Bancos de dados relacionais predominam no mundo do desenvolvimento de

software.
• SGBD ou Sistema Gerenciador de Bancos de Dados foi uma evolução do

paradigma de armazenamento em arquivos.
• Algumas dicas são importantes para ter sucesso na escolha do banco de dados
a ser utilizado.
24
AUTOATIVIDADE
1 De acordo com o conteúdo estudado, defina o conceito de dado, informação

e conhecimento.
2 O que é um SGBD ou Sistema Gerenciador de Bancos de Dados e qual é a sua

melhoria em relação ao armazenamento de dados em arquivos?
3 Dê quatro exemplos de bancos de dados relacionais disponíveis no mercado.
4 Cite as principais funções de um SGBD.
5 O que faz uma pessoa que tem o cargo de Administrador do Banco de Dados
(DBA – Database Administrator)?
25
26
UNIDADE 1
TÓPICO 2
EVOLUÇÃO DOS BANCOS DE DADOS
1 INTRODUÇÃO
“O descontentamento é o primeiro passo na evolução de um homem
ou de uma nação”. (Oscar Wilde)
Relembrando um pouco do Tópico 1, vimos que inicialmente os bancos de

dados eram simples sistemas de arquivos. Tudo o que era desenvolvido tinha uma
finalidade específica, não existindo muita integração entre sistemas distintos. Isso
gerou vários problemas, como redundância de dados e concorrência de acessos.
Outro ponto negativo nesse tipo de estrutura é que toda a organização dos dados
ficava armazenada no programa que fazia a sua utilização. Questões relacionadas
à alteração dessa estrutura ficavam relacionadas a inconsistências e trabalho árduo.
Também foi apresentado o conceito de SGBD, que é a evolução do modelo

de sistemas de arquivos. Os principais SGBDs da atualidade fizeram parte desta
apresentação e todos são considerados SGBDs relacionais ou objeto relacional.
Esse tipo de tecnologia é o que predomina hoje no mercado quando tratamos de
aplicações tradicionais.
Para entendermos o futuro é interessante conhecermos o passado. Por isso

esse tópico trata da evolução dos bancos de dados, dividindo-se em três grupos:
histórico da evolução, arquitetura e níveis de abstração dos bancos de dados.
O primeiro trata as gerações dos bancos de dados (três gerações), o segundo
as arquiteturas (centralizadas, distribuídas, cliente-servidor etc.) e o terceiro a
abstração (três níveis).
Bons estudos!
27
2 HISTÓRICO DA EVOLUÇÃO DOS BANCOS DE DADOS

A evolução ou o histórico da evolução dos bancos de dados estão divididos
em três gerações: a primeira trata dos bancos hierárquicos e em rede, a segunda
dos relacionais e a terceira dos bancos orientados a objetos e objeto relacional.
Vamos estudar cada geração para entender melhor todo o processo de evolução.
2.1 PRIMEIRA GERAÇÃO

Foi na década de 60 que “nasceram” os primeiros bancos de dados. Existiam
basicamente duas formas de organização: o modelo hierárquico e o em rede. Ambos
trabalhavam com o conceito de registro, que segundo Korth e Silberschatz (1995),
é uma coleção de campos (atributos) os quais contêm apenas um valor de dado.
Também existe a ideia de ligação entre registros. Korth e Silberschatz (1995)

definem que uma ligação é uma associação entre exatamente dois registros.
Um banco de dados hierárquico consiste basicamente em um conjunto de

registros conectados por meio de ligações. Toda a estrutura está organizada em um
modelo de árvore ou também conhecido como modelo hierárquico. Cada registro
filho pode ter apenas um registro pai. Um registro pai pode ter vários registros
filho. Exemplificamos isso na figura a seguir.
FIGURA 13 – RELAÇÃO ENTRE REGISTRO PAI E REGISTROS FILHOS
PAI
FILHO FILHO FILHO
FONTE: Os autores
Para simplificar o conceito de um banco de dados hierárquico observe a

figura a seguir. Nela apresentamos uma estrutura típica de clientes de um banco
com suas contas e saldo. Esse exemplo é muito utilizado em livros que tratam
desse assunto.
28
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
FIGURA 14 – ESTRUTURA DE UM BANCO DE DADOS HIERÁRQUICO
RAIZ
Marcos Silva 469.206.617-21 João Trindade 227.428.671-04
70948 R$ 700,00 12496 R$ 150,00
FONTE: Os autores
A figura a seguir demostra a estrutura dos dados que estão na figura

anterior.
FIGURA 15 – ESTRUTURA DE DADOS DA FIGURA 14
RAIZ
NOME CPF NOME CPF
Nº CONTA SALDO Nº CONTA SALDO
FONTE: Os autores
Os dados da conta e saldo podem ser acessados somente a partir do nó

raiz (registro falso), seguindo os registros da esquerda para a direita. É necessário
navegar por toda a estrutura para chegar a esses valores. Um dos problemas se
refere à duplicidade de dados. Por exemplo, se uma conta pertencesse a mais de
um cliente, os dados da conta provavelmente precisariam ser duplicados. Isso,
segundo Korth e Silberschatz (1995) gera dois inconvenientes: a inconsistência dos
dados quando acontecerem atualizações e a perda de espaço em disco.
Marcando presença ainda na primeira geração estão os bancos de dados

que seguem o modelo em rede. São considerados como sendo uma evolução do
modelo hierárquico. Embora o nome sugira ligação com redes de computadores
(um computador “ligado” ao outro), o conceito não tem relação com isso.
Esse modelo surgiu com o benefício de que o registro possa fazer parte de
várias associações, o que não era possível no hierárquico (a não ser que o registro
fosse duplicado). Também eliminou a hierarquia quando ao acesso dos dados. A
figura a seguir mostra uma estrutura de dados no modelo rede.
29
FIGURA 16 – ESTRUTURA DE DADOS NO MODELO REDE
Marcos Silva 469.206.617-21 70948 R$ 700,00
João Trindade 227.428.671-04 12496 R$ 150,00
FONTE: Os autores
Na parte esquerda da figura 16 temos o nome do cliente e seu CPF. No

lado direito a conta e o saldo. Note que agora é possível associar uma conta a dois
clientes sem ter que duplicá-la (a conta 70948 pertence ao Marcos e ao João). Não
temos a presença de um registro falso (raiz), sendo que agora se podem acessar os
dados de qualquer parte do grafo.
Apesar de uma aparente melhoria em relação aos bancos de dados

hierárquicos, o modelo em redes apresenta alguns problemas. É complicado para
o programador trabalhar com esse modelo, pois ele tem que pensar em ligações de
registros e como percorrê-las para buscar os dados que necessita.
Sendo assim, podemos concluir que a primeira geração de bancos de dados

deixou pontos a serem melhorados. Entretanto, na época, existiam sistemas que
eram referência para os modelos hierárquicos e de redes. Como exemplo, Kort
e Silberschatz (1995) citam o IMS – sistema de gerenciamento de informações da
IBM (hierárquico) e o IDMS (rede).
2.2 SEGUNDA GERAÇÃO

No início da década de 70, surge um novo conceito em banco de dados: o
modelo de dados relacional. Esse modelo é largamente utilizado até os dias de hoje por
aplicações de processamento de dados comerciais mais padronizadas (ERPs, CMDs
etc.). Date (2003) nos diz que a introdução do modelo relacional em 1969-1970 foi sem
dúvida o evento mais importante em toda a história da área de bancos de dados.
Rob e Coronel (2011) fazem um breve relato sobre este modelo.
O modelo relacional foi apresentado em 1970 por E. F. Codd (da IBM)

em seu famoso artigo “A Relational Model Data for Large Shared
Databanks” (Um modelo relacional de dados para grandes bancos de
dados compartilhados) (Comunicações da ACM, junho de 1970, p. 377-
387). O modelo relacional representava uma importante ruptura tanto
para usuários como para projetistas. Para utilizar uma analogia, esse
modelo produziu um banco de dados de “câmbio automático” para
substituir os de “câmbio manual” que o precederam. Sua simplicidade
conceitual preparou o terreno para a verdadeira revolução dos bancos
de dados. (ROB; CORONEL, 2011, p. 40).
30
O modelo relacional trabalha na sua forma mais básica com tabelas. Podem
existir relações entre as mesmas para buscas de registros. A definição das tabelas
pode envolver restrições para garantir dados confiáveis. Este modelo elimina a
complexidade de navegação ou busca de dados presentes nos hierárquicos e nos
de rede. A figura a seguir traz um exemplo de dados organizados sob o modelo
relacional. Neste exemplo são listados os clientes de um banco com seus respectivos
gerentes de conta.
FIGURA 17 – ORGANIZAÇÃO DE DADOS NO MODELO RELACIONAL
FONTE: Os autores
Note que na figura anterior existe um relacionamento entre as tabelas cliente

e gerente. Para tal, é utilizada a coluna CD_GERENTE. Neste caso, significa que
um cliente pode ter somente um gerente e que um gerente pode ter vários clientes.
Podem ser adicionadas restrições em ambas as tabelas para que, por exemplo, não
se permita o cadastro de mais de um gerente ou cliente com o mesmo CPF.
Quando trabalhamos com um modelo relacional é comum a utilização de

um diagrama relacional ou MER – Modelo Entidade Relacionamento. A figura a
seguir traz o MER da estrutura apresentada na figura anterior.
31
FIGURA 18 – MODELO ENTIDADE RELACIONAMENTO FIGURA 17
FONTE: Os autores
A presença de uma chave ao lado das colunas CD_CLIENTE E CD_

GERENTE indica que os campos são identificadores únicos de registros, ou seja,
o dado que está nessas colunas não poderá se repetir na tabela. Diz-se que esses
campos são chaves primárias.
Boas partes dos conceitos apresentados aqui serão revistos e aprofundados

na Unidade 2, que vai tratar exclusivamente do modelo de dados relacional.
2.3 TERCEIRA GERAÇÃO

A terceira geração é datada em meados do ano de 1980 e vai até os dias
atuais. Como em todas as outras, essa geração também têm o seu destaque
tecnológico. O nome deste novo conceito é banco de dados orientado a objetos.
Para detalhar melhor qual foi a origem deste tipo de banco de dados,
Silberschatz, Korth e Sudarshan (2006) nos apresentam um breve relato.
As aplicações tradicionais de bancos de dados consistem em tarefas de

processamento de dados, como transações bancárias e gerenciamento de
folha de pagamento, com tipos de dados relativamente simples, que são
adequados ao modelo de dados relacional. Uma vez que os sistemas de
bancos de dados foram aplicados a uma faixa mais ampla de aplicações,
como projeto auxiliado por computador e sistemas de informações
geográficas, as limitações compostas pelo modelo relacional se
apresentaram como um obstáculo. A solução era a introdução dos bancos
de dados baseados em objeto, que permitem lidar com tipos de dados
complexos. (SILBERSCHATZ; KORTH; SUDARSHAN, 2006 p. 241).
Esse novo tipo de estruturação permite uma adaptação menos dolorosa,

porque vários programadores já estão familiarizados em linguagens orientadas a
objeto, o que em termos de conceito são iguais a este tipo de banco. Tudo “gira”
em torno de objetos, que possuem atributos e propriedades com mais uma gama
de recursos para atingir seus objetivos.
32
Existe também uma variação do modelo orientado a objetos “puro”. Ele

se chama modelo de dados objeto-relacional, que é um meio termo entre bancos
relacionais e bancos orientados a objetos. Elmasri e Navathe (2011) explicam
essa nova ideia.
Vendedores de SGBD relacional (SGBDR) também reconheceram a

necessidade de incorporar recursos que foram propostos para bancos
de dados de objeto, e versões mais novas de sistemas relacionais
incorporaram muitos desses recursos. Isso levou a sistemas de bancos
de dados que são caracterizados como objeto relacional ou SGBDORs.
A versão mais recente do padrão SQL (2008) para SGBDRs inclui muitos
desses recursos, que eram conhecidos originalmente como SQL/Object e
agora têm sido incorporados na especificação SQL principal, conhecida
como SQL/Foundation. (ELMASRI; NAVATHE, 2011, p. 236).
Entretanto, os bancos de dados orientados a objetos ainda não têm um

uso massivo em virtude da grande popularidade de sistemas relacionais e objeto
relacional. Fernando Amaral faz algumas análises evidenciando essa situação.
E
IMPORTANT
Leia a seguir um texto que faz uma análise sobre o motivo pelo qual bancos de
dados orientados a objetos não são utilizados em larga escala.
POR QUE NÃO ESTAMOS UTILIZANDO BANCO DE DADOS

ORIENTADOS A OBJETOS?
A orientação a objetos, mesmo que não da forma purista encontrada

no mundo acadêmico, é uma realidade irreversível no mundo do
desenvolvimento de software. Mesmo o próprio Visual Basic, uma das
linguagens mais utilizadas do mundo e que sempre foi rotulada como
linguagem “para fracos”, sem tipagem e sem qualquer recurso de OO,
ganhou, com o lançamento da plataforma. NET, uma versão totalmente
reformulada e OO, onde restou pouca semelhança com o VB clássico.
Agora, e quanto ao universo dos Bancos de Dados? A esmagadora maioria

dos gerenciadores de banco de dados existentes hoje no mercado são relacionais,
e não há qualquer evidência de uma tendência em contrário, ou seja, parece
que no futuro vamos continuar utilizando banco de dados relacionais. Porque o
mercado de banco de dados continua predominantemente relacional, enquanto
utilizamos cada vez mais linguagens de programação OO?
33
O QUE ACONTECEU?
Diante desta indagação, resolvi investigar os motivos, e descobri que

são muitos. Inicialmente um bom OODBMS é muito, muito mais caro que um
produto relacional “Top” de linha, além disso:
- O modelo relacional é mais simples

- O modelo OO não tem a escabilidade de um banco de dados relacional
- O modelo OO possui dependência de linguagem: um banco de dados OO
deve ser acessado através de uma API específica, normalmente através de uma
linguagem específica. Por outro lado, nos OODBMS a linguagem e o banco de
dados utilizam os mesmo tipos de dados.
- Consultar um banco de dados relacional, devido a sua natureza, é mais simples.
Em um banco de dados OO não é possível fazer joins ou consultas “Ad-Hoc”.
Outro fato que não deve ser esquecido é que o modelo relacional é mais
antigo, possui uma padronização maior e um maior número de ferramentas. Os
bancos de dados OO se mostraram superiores em aplicações específicas, como,
por exemplo, CAD, multimídia etc.
CONSEQUÊNCIAS: IMPEDANCE MISMATCH
Então tudo indica que os bancos de dados relacionais vão continuar

predominantes por muito tempo, e que, cada vez as linguagens de programação
serão OO (repetindo: mesmo que não da forma purista encontrada no mundo
acadêmico). Mas como trabalhar corretamente com uma linguagem OO e um banco
de dados relacional? Na OO temos objetos, que representam entidades do mundo
real e atributos, que são suas características. No modelo relacional temos Entidades
(ou tabelas), com atributos (campos). Na OO, o relacionamento entre objetos é
através de referências, no relacional, através de chaves primárias e estrangeiras.
A implementação de uma classe terá que contornar todos os problemas

desta diferença entre universos tão heterogêneos. Para uma simples classe
poderá parecer fácil, mas para um sistema complexo com dezenas ou centenas
de classes e relacionamentos, pode virar um pesadelo.
Este conflito objeto X relacional é conhecido com “The Object-Relational

Impedance Mismatch”, ou simplesmente Impedance Mismatch, algo como
um problema de adaptação, numa tradução livre. Estudos afirmam que a
Impedance Mismatch podem consumir até 25 % do tempo de desenvolvimento
de um software e ainda prejudicar consideravelmente seu desempenho.
34
O obra Agile Database Techniques: Effective Strategies for the Agile

Software Developer, (Scott W. Ambler, ISBN:0471202835), dedica o capítulo 7
de título The Object-Relational Impedance Mismatch a debater esse assunto, e é
uma leitura altamente recomendada.
FONTE: Disponível em: <http://www.fernandoamaral.com.br/Default.aspx?Artigo=17>. Acesso
em: 22 jan. 2013.
Com o passar do tempo é possível que esta situação mude. Existem grandes
iniciativas para que isso aconteça. O cache da empresa Intersystems é um exemplo
disto. Outra tendência é que o uso desta tecnologia se limite apenas a situações
onde existem dados complexos, como informações geográficas, aplicações que
trabalham com imagens, entre outras.
3 ARQUITETURA DE BANCO DE DADOS

A arquitetura de um banco de dados está diretamente ligada a questões
de hardware e sistema computacional existentes na estrutura em questão. O
poder de processamento, a estrutura de rede, a memória e diversos outros
componentes, são características que fazem parte da análise de toda arquitetura
para bancos de dados.
Sendo assim, vamos nos concentrar em quatro tipos de arquitetura:

centralizada, cliente-servidor, paralela e distribuída. Cada um destes tipos teve
grande importância na história da evolução dos bancos de dados.
3.1 ARQUITETURA CENTRALIZADA

Os primeiros bancos de dados estavam implementados nesse tipo de
arquitetura. Na década de 1970, eles tinha a implementação centralizada,
normalmente em mainframes. Para os usuários acessarem os dados utilizavam
terminais sem capacidade de processamento. Esses computadores se conectavam
em mainframes (onde era feito todo o processamento) e ali obtinham os dados
que necessitavam.
Na arquitetura centralizada, existem duas formas de utilização de sistemas:

a multiusuário e a monousuário. A estrutura exposta no parágrafo anterior é um
exemplo de sistema multiusuário. Silberschatz, Korth e Sudarshan (2006, p. 527)
exemplificam com mais detalhes essas duas formas.
35
Distinguimos duas maneiras como os computadores são usados:

como sistemas monousuário e como sistemas multiusuários. Os
computadores pessoais e as estações de trabalho caem na primeira
categoria. Um sistema monousuário típico é uma unidade de desktop
usada por uma única pessoa, normalmente com apenas uma CPU em
um ou dois discos rígidos e normalmente somente uma pessoa usando
a máquina de cada vez. Um sistema multiusuário típico, por outro lado
tem mais discos e mais memória, pode até ter várias CPUs e possui um
sistema operacional multiusuário. Ele atende a uma grande quantidade
de usuários que estão conectados ao sistema por meio de terminais.
TURO S
ESTUDOS FU
Veremos nos próximos tópicos a evolução das arquiteturas centralizadas.
3.2 ARQUITETURA CLIENTE-SERVIDOR
Conforme os computadores pessoais foram evoluindo e o seu custo se

tornou menor, a arquitetura centralizada, como era conhecida, teve o seu uso
diminuído. Os computadores pessoais substituíram os terminais de acesso e
começaram a desempenhar novos papéis. O gerenciamento da interface que antes
era responsabilidade do servidor, agora passou a ser gerenciado por clientes.
Em resumo, os sistemas centralizados atualmente respondem requisições

que são feitas pelos sistemas clientes. Esse é o conceito de cliente-servidor. A figura
a seguir representa graficamente esse conceito.
FIGURA 19 – ARQUITETURA CLIENTE-SERVIDOR
FONTE: Os autores
36
A funcionalidade oferecida pelos servidores de bancos de dados cliente-

servidor pode ser dividida em duas partes: o front-end e o back-end. O back-end
basicamente controla as estruturas de acesso ao dado, enquanto o front-end faz a
interface com o usuário final. A figura a seguir expõe esse cenário.
FIGURA 20 – FUNCIONALIDADE DE FRONT-END E BACK-END
FONTE: Silberschatz, Kort e Sudarshan (2006, p. 529)
TURO S
ESTUDOS FU
Novamente, se você observar a Figura 20, estamos nos referindo a SQL (Structured
Query Language). Por hora entenda que SQL é uma linguagem para acesso/manipulação dos
dados. A Unidade 3 deste Caderno de Estudos tratará de esclarecer este assunto.
3.3 ARQUITETURA PARALELA

É uma arquitetura que tem como objetivo o compartilhamento de recursos
para processamento de dados. O texto sobre sistemas paralelos de Silberschatz,
Korth e Sudarshan (2006) detalha este conceito.
37
SISTEMAS PARALELOS
Sistemas paralelos melhoram as velocidades de processamento e E/S

usando várias CPUs e discos em paralelo. As máquinas paralelas estão se
tornando cada vez mais comuns, tornando o estudo de sistemas de banco
de dados paralelos cada vez mais importantes. A força motriz por trás dos
sistemas de banco de dados paralelos é a demanda de aplicações que precisam
consultar bancos de dados extremamente grandes (da ordem de terabytes – ou
seja, 10 (12) bytes) ou que tenham de processar um número extremamente
grande de transações por segundo (da ordem de milhares de transações por
segundo). Os sistemas de bancos de dados centralizados e cliente-servidor
não são poderosos o suficiente para lidar com tais aplicações.
No processamento paralelo, muitas operações são realizadas

simultaneamente, ao contrário do processamento serial, em que as etapas
computacionais são realizadas sequencialmente. Uma máquina paralela com
granularidade grossa consiste em um pequeno número de processadores
poderosos; uma máquina maciçamente paralela ou paralela com granularidade
fina utiliza milhares de processadores menores. A maior parte das máquinas de
alto nível hoje em dia oferece algum grau de paralelismo com granularidade
grossa; máquinas com dois ou quatro processadores são comuns. Computadores
maciçamente paralelos podem ser distinguidos de máquinas paralelas com
granularidade grossa pelo grau muito maior de paralelismo que eles admitem.
Computadores paralelos, com centenas de CPus e discos, estão disponível
comercialmente.
Existem duas medidas principais de desempenho de um sistema de

banco de dados: 1) throughput, o número de tarefas que pode ser completado
em determinado intervalo de tempo, e 2) tempo de resposta, a quantidade
de tempo necessária para completar uma única tarefa desde o momento
em que ela foi submetida. Um sistema que processa um grande número
de transações pequenas pode melhorar o troughput processando muitas
transações em paralelo. Um sistema que processa grandes transações pode
melhorar o tempo de resposta e também o troughput realizando subtarefas
de cada transação em paralelo.
FONTE: Silberschatz, Korth e Sudarshan (2006, p. 532)
3.4 ARQUITETURA DISTRIBUÍDA

A definição mais básica de sistemas distribuídos é que máquinas diferentes
podem estar conectadas entre si através de uma rede de comunicações. O sistema
distribuído difere do sistema paralelo na seguinte questão: no paralelo a tendência
é que as máquinas fiquem mais próximas, enquanto que no distribuído elas podem
estar geograficamente distantes.
38
Date (2003) nos diz que a internet é um exemplo mais óbvio de sistema
distribuído, de tal modo que uma única tarefa de processamento de dados possa
se estender a várias máquinas da rede.
A figura a seguir mostra um exemplo de arquitetura de bancos de dados

distribuída.
FIGURA 21 – ARQUITETURA DE BANCO DE DADOS DISTRIBUÍDA
Rob e Coronel (2011) nos dizem que bancos de dados distribuídos, por sua
vez, armazenam o banco relacionado logicamente por dois ou mais locais físicos
independentes.
NOTA
Veja o quadro a seguir, que mostra as vantagens e desvantagens desse modelo

de arquitetura.
39
QUADRO 1 – VANTAGENS E DESVANTAGENS DE BANCOS DE DADOS DISTRIBUÍDOS
Vantagens Desvantagens
Os dados ficam localizados próximo do local de Complexidade de gerenciamento e controle. As

maior demanda. Os dados em um sistema de aplicações devem reconhecer a localização dos
banco de dados distribuído são dispersos para dados e ter a capacidade de integrá-los a partir de
atender às necessidades comerciais. vários locais. É necessário que os administradores
tenham capacidade de coordenar as atividades
Maior rapidez de acesso aos dados. Os do banco de dados, evitando sua degradação em
usuários finais costumam trabalhar apenas função de anomalias.
com um subconjunto dos dados da empresa,
armazenado localmente. Dificuldade tecnológica. É necessário tratar
e solucionar a integridade dos dados,
Maior rapidez de processamento de dados. Um o gerenciamento de transações, o controle
sistema de gerenciamento de banco de dados de concorrência, o backup, a recuperação, a
distribuídos divide a carga de trabalho do otimização de consultas, a seleção do caminho
sistema, processando dados em vários locais. de acesso etc.
Facilidade de ampliação. É possível adicionar Segurança. A probabilidade de falhas de

novos locais à rede sem afetar as operações de segurança aumenta quando os dados são
outros locais. armazenados em vários locais. A responsabilidade
do gerenciamento dos dados será compartilhada
Aprimoramento das comunicações. Como os por diferentes pessoas em diversos locais.
sites locais são menores e mais próximos dos
clientes, promovem melhor comunicação entre Falta de padrões. Não há protocolos de
os departamentos e entre os clientes e a equipe comunicação padronizados no nível de banco
da empresa. de dados. (Embora o TCP/IP seja, na prática, um
padrão no nível de rede, não há padronização
Custos operacionais reduzidos. Do ponto de no nível de aplicação.) Por exemplo, diferentes
vista dos custos, é mais eficiente adicionar fornecedores de banco de dados empregam
estações de trabalho a uma rede do que técnicas diferentes e geralmente incompatíveis
atualizar um sistema de mainframe. O trabalho de gerenciamento da distribuição de dados e
de desenvolvimento é feito de modo mais processamento no ambiente de SGBDD.
rápido e barato em PCs de baixo custo do que
em mainframes. Ampliação das necessidades de armazenamento
e infraestrutura. São necessárias várias cópias
Interface amigável. Os PCs e as estações de de dados em diferentes locais, exigindo, assim,
trabalho costumam ser equipados com interface espaço adicional de armazenamento em disco.
gráfica de usuário (GUI) fácil de usar. A GUI
simplifica o treinamento e utilização dos usuários Aumento de custos com treinamento. Os custos
finais. com treinamento costumam ser mais elevados em
modelos distribuídos do que em centralizados,
Menor risco de falha em ponto único. Quando às vezes a ponto de compensar as economias
um componente dos computadores falha, o operacionais e de hardware.
trabalho é mantido por outras estações. Os
dados também são distribuídos em vários Custos. Os bancos de dados distribuídos exigem
locais. infraestrutura duplicada para operar (localização
física, ambiente, pessoal, software, licenciamento
Independência do processador. O usuário final etc.).
é capaz de acessar todas as cópias disponíveis
dos dados e suas solicitações são processadas
por qualquer processador no local dos dados.
40
GRIDS COMPUTACIONAIS COMO TENDÊNCIA NO PROCESSAMENTO

DE BANCOS DE DADOS
Methanias Colaço Júnior
A computação distribuída é uma realidade evidente no contexto dos

Sistemas Gerenciadores de Banco de Dados. Neste artigo, apresentaremos o
conceito de uma tecnologia distribuída emergente: os Grids Computacionais.

Atualmente, o custo para se ter um banco de dados com capacidade de
terabytes (1024 gigabytes) já não é, relativamente, tão alto. Com a evolução
da capacidade de armazenamento, cientistas estão planejando experimentos
físicos e simulações que geram arquivos de resultados enormes na ordem de
petabytes (1024 terabytes). Essa grande quantidade de dados demanda mais
recursos computacionais para ser analisada e ter esses recursos em um único
lugar é impraticável.
Esses avanços que a tecnologia tem experimentado, principalmente nas

áreas de bancos de dados e de redes de computadores, levaram à ideia de utilizar
computadores, independentes e geograficamente dispersos, conectados em uma
plataforma para execução de aplicações paralelas. Esta plataforma, chamada
comumente de Grid Computacional, apresenta características diferentes das outras
plataformas existentes, principalmente devido a sua heterogeneidade (diversidade
de computadores), compartilhamento com outros usuários e complexidade.
O termo Grid Computacional vem exatamente da analogia feita à rede

elétrica (Electric Power Grid) baseado nas malhas de interligação dos sistemas de
distribuição de energia elétrica, nos quais um usuário utiliza a eletricidade sem
ao menos saber onde ela foi gerada. Esta representa a infraestrutura que permitirá
avanços na computação, de um modo geral, como ocorreu com a rede elétrica. Essa
infraestrutura necessita de software específico para monitorar e controlar o ambiente.
Segundo Ian Baird, Grid é uma infraestrutura emergente que faz o processamento
e o acesso a dados serem possíveis de qualquer lugar e a qualquer horário, sem
que alguém seja obrigatoriamente notificado. Em outras palavras, Computação em
Grid é uma coleção de recursos heterogêneos e distribuídos, possibilitando que os
mesmos sejam utilizados em grupo para executar aplicações de larga escala.

41
Neste momento, vocês podem estar se perguntado: “Mas qual a diferença

dos Grids para a computação distribuída tradicional?” A diferença se dá pelo fato de
que a computação distribuída é um conceito que vem dos anos 80 e 90, consistindo
na possibilidade de resolver um determinado problema computacional através
da utilização de diferentes recursos distribuídos geograficamente. A computação
distribuída passa a ser uma “Computação em Grade” no momento em que existe
uma infraestrutura física e uma infraestrutura lógica (software) que permita coordenar
os trabalhos que vão ser processados e garantir a sua qualidade de serviço. Os Grids
são uma evolução da computação distribuída, uma vez que eles são orientados
essencialmente para aplicações que precisam de uma grande capacidade de cálculos
e/ou enormes quantidades de dados transmitidos de um lado para o outro.

Não podemos imaginar que a tecnologia em Grid é uma panaceia (resolução
de todos os problemas neste contexto), pois se imaginarmos uma aplicação sendo
executada paralelemente em diversos pontos, é fácil visualizar a necessidade de
divisão da mesma em partes coordenadas e interdependentes que necessitarão
de alteração de código. Além disso, é necessário consolidar soluções de níveis de
prioridade para acesso aos recursos da rede. Contudo, as pesquisas sobre Grids
permitirão que empresas acessem e compartilhem bases de dados de forma
remota, o que é essencialmente benéfico para as ciências da saúde ou comunidades
de pesquisa, cujos volumes grandiosos de dados são gerados e analisados durante
todo o dia. Já imaginaram o fato de uma empresa que possui filiais em países
com fusos diferentes poder usar, durante o dia, o poder de processamento dos
computadores da filial no Japão, ociosos neste horário por ser noite? Este é o futuro
com a evolução da computação distribuída. SGBDs como o Oracle já começam a
apresentar características de processamento baseadas em Grids Computacionais.
Em um próximo artigo, descreveremos as novas características do Oracle 10g
baseadas nesta tecnologia.
FONTE: Disponível em: <http://www.devmedia.com.br/grids-computacionais-como-tendencia-

no-processamento-de-bancos-de-dados/1382>. Acesso em: 24 jan. 2013.
42
RESUMO DO TÓPICO 2
• O histórico da evolução dos bancos de dados foi dividido em três gerações.
• Existem vários tipos de arquiteturas de bancos de dados e cada um possui

particularidades que devem ser estudados durante o processo de escolha.
• A arquitetura cliente-servidor é amplamente utilizada inclusive nos dias de hoje.
43
AUTOATIVIDADE
1 Diferencie a primeira geração da segunda no histórico da evolução dos

bancos de dados.
2 Explique como foi a terceira geração de bancos de dados.
3 Segundo o que foi estudado neste Caderno de Estudos, quando se fala em

arquitetura de bancos de dados, quais são os fatores ou itens que devem ser
analisados?
4 Descreva o que vem a ser uma arquitetura de banco de dados centralizada.
5 Cite a principal diferença entre as arquiteturas paralelas e distribuídas.
44
UNIDADE 1
TÓPICO 3
TENDÊNCIAS E PERSPECTIVAS
1 INTRODUÇÃO
“Nossas dúvidas são traidoras e nos fazem perder o que, com
frequência, poderíamos ganhar, por simples medo de arriscar.”
(William Shakespeare)
Agora que você já tem uma boa fundamentação sobre bancos de dados,
suas origens, sua evolução e suas arquiteturas, chegou a hora de estudarmos
as possíveis tecnologias que são apontadas como tendência para o futuro. Será
percebido que algumas delas já fazem parte do cotidiano em algumas áreas, porém
ainda precisam evoluir.
FIGURA 22 – NOVAS TECNOLOGIAS EM BANCOS DE DADOS
FONTE: Disponível em: <http://www.devmedia.com.br/introducao-aos-bancos-de-dados-

nosql/26044>. Acesso em: 23 dez. 2012.
Vamos estudar, inicialmente, os tipos de bancos de dados que servem para

trabalhar com dados complexos em cenários como georeferenciamento, biologia,
entre outros. Também veremos conceitos de gerenciamento e mineração de dados
para geração de informações. Por último, dois novos conceitos no mundo de
bancos de dados: NoSQL e Big Data. Bons estudos!
45
2 CLASSIFICAÇÃO DOS BANCOS DE DADOS

Até o presente momento estudamos bancos de dados sob uma ótica do
modelo relacional. Este é largamente utilizado e muito difundido em vários
sistemas considerados “tradicionais” como ERPs, CRMs, E-commerce etc.
Porém, existem sistemas com uma abrangência mais específica que norteiam
áreas mais delimitadas. É o caso do armazenamento e manipulação de informações
geográficas ou também de arquivos que necessitam de uma organização em nível
de bancos de dados.
Esse é o foco do nosso estudo nesta seção. Está dividido em sete áreas:
bancos de dados de informações geográficas, multimídia, temporal, biológico e
XML. Cada uma dessas áreas será estudada e exemplificada.
2.1 BANCOS DE DADOS DE INFORMAÇÕES GEOGRÁFICAS

Este tipo de banco de dados tem como objetivo armazenar e manipular
dados geométricos que sejam pertinentes a representações de partes do planeta.
Também é conhecido como Sistema Gerenciador de Bancos de Dados Geográficos
ou simplesmente SGBDG. Em resumo, armazena dados geográficos como mapas,
imagens de satélite etc.
FIGURA 23 – OBJETO QUE PODE SER REPRESENTADO POR UM SGBDG
FONTE: Disponível em: <http://www.mobypicture.com/user/patrickitj/

view/9762284>. Acesso em: 15 dez. 2012.
Alguns bancos que são de natureza relacional permitem que sejam

instalados pacotes para que tipos de dados geográficos sejam suportados. Um
exemplo disto é uma extensão que pode ser adicionada no banco PostgreSQL para
habilitar suporte a dados espaciais. O nome dela é PostGIS e sua ideia é ilustrada
na figura a seguir.
46
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
FIGURA 24 – EXTENSÃO ESPACIAL DO POSTGRESQL
FONTE: Disponível em: <http://www.infoescola.com/informatica/banco-de-

dados-geograficos/>. Acesso em: 15 dez. 2012.
UNI
O texto a seguir trata sobre representação geral de informações geográficas.

Nele, procura-se detalhar com maior riqueza de detalhes, o paradigma de bancos de dados
geográficos.
DESCRIÇÃO GERAL DE SISTEMAS DE INFORMAÇÃO GEOGRÁFICA
O termo sistemas de informação geográfica (SIG) é aplicado para sistemas

que realizam o tratamento computacional de dados geográficos. A principal
diferença de um SIG para um sistema de informação convencional é sua
capacidade de armazenar tanto os atributos descritivos como as geometrias
dos diferentes tipos de dados geográficos. Assim, para cada lote num cadastro
urbano, um SIG guarda, além de informação descritiva como proprietário e valor
do IPTU, a informação geométrica com as coordenadas dos limites do lote. A
partir destes conceitos, é possível indicar as principais características de SIGs:
• Inserir e integrar, numa única base de dados, informações espaciais

provenientes de meio físico-biótico, de dados censitários, de cadastros
urbano e rural, e outras fontes de dados como imagens de satélite, e GPS.
• Oferecer mecanismos para combinar as várias informações, através de

algoritmos de manipulação e análise, bem como para consultar, recuperar e
visualizar o conteúdo da base de dados geográficos.
47
Os componentes de um SIG estão mostrados na Figura 1.1. No nível

mais próximo ao usuário, a interface homem-máquina define como o sistema
é operado e controlado. Esta interface pode ser tanto baseada na metáfora
da “mesa de trabalho” (Kuhn e Frank, 1991) (Richards e Egenhofer, 1995)
(Câmara, 1999), como adaptada ao ambiente de navegação da Internet (Kraak
e Brown, 2001), quanto baseada em linguagens de comando como Spatial SQL
(Egenhofer, 1994) e LEGAL (Câmara, 1995). No nível intermediário, um SIG
deve ter mecanismos de processamento de dados espaciais. A entrada de dados
inclui os mecanismos de conversão de dados (Hohl, 1998). Os algoritmos de
consulta e análise espacial incluem as operações topológicas (Egenhofer e
Franzosa, 1991), álgebra de mapas (Tomlin, 1990), estatística espacial (Druck
et al., 2004), modelagem numérica de terreno (Li et al., 2004) e processamento
de imagens (Mather, 2004). Os mecanismos de visualização e plotagem devem
oferecer suporte adequado para a apreensão cognitiva dos aspectos relevantes
dos dados pesquisado (MacEachren, 2004) (Tufte, 1983) (Monmonier, 1993).
No nível mais interno do sistema, um sistema de gerência de bancos de dados
geográficos oferece armazenamento e recuperação dos dados espaciais e seus
atributos. Cada sistema, em função de seus objetivos e necessidades, implementa
estes componentes de forma distinta, mas todos os subsistemas citados devem
estar presentes num SIG.
Do ponto de vista da aplicação, o uso de sistemas de informação

geográfica (SIG) implica escolher as representações computacionais mais
adequadas para capturar a semântica de seu domínio de aplicação. Do ponto
de vista da tecnologia, desenvolver um SIG significa oferecer o conjunto mais
amplo possível de estruturas de dados e algoritmos capazes de representar a
grande diversidade de concepções do espaço.
FONTE: Disponível em: <http://www.dpi.inpe.br/livros/bdados/cap1.pdf>. Acesso em: 11 set. 2012.
48
2.2 BANCOS DE DADOS MULTIMÍDIA

Dados multimídia são cada vez mais populares. Com o advento da internet
a troca de dados multimídia expandiu-se. Entretanto, imagens, vídeo e audio
estão hoje, na maioria das vezes, armazenados em sistemas de arquivos. Esse
fato não vem a ser um problema quando se trabalha com um volume reduzido
de dados, considerando que um banco não iria trazer grandes benefícios. Porém,
com muitos arquivos uma forma de armazenamento em banco facilitaria o
gerenciamento dos mesmos.
Boa parte dos principais bancos de dados implementam um tipo de

dado binário para armazenar dados multimídia. Isso faz com que essa forma de
armazenamento se resuma apenas em salvar arquivos no banco, não trazendo
muitas vantagens comparadas com o armazenamento em sistemas em arquivos.
Um banco de dados multimídia precisa ter algumas características como

suporte a objetos gigantes (muito mais que alguns gigabytes), fornecimento dos
dados em um ritmo constante (um vídeo precisa ser fornecido sem lacunas durante
sua exibição) e recuperação baseada na semelhança.
UNI
O texto a seguir detalha a necessidade e a motivação para a recuperação baseada

em semelhança.
RECUPERAÇÃO BASEADA EM SEMELHANÇA
Dados de imagem. Duas figuras ou imagens que são ligeiramente

diferentes, conforme representadas no banco de dados, podem ser consideradas
iguais por um usuário. Por exemplo, um banco de dados pode armazenar um
projeto de marca comercial. Quando uma marca comercial deve ser registrada,
o sistema pode precisar primeiro identificar todas as marcas comerciais
semelhantes que foram registradas anteriormente.
Dados de áudio. Interfaces de usuário baseadas em fala estão sendo

desenvolvidas para permitir que o usuário dê um comando ou identifique um
item de dados pela fala. A entrada do usuário precisa então ser testada por
semelhança com aqueles comandos ou itens de dados armazenados no sistema.
Dados escritos à mão. A entrada escrita à mão pode ser usada para
identificar um item de dados ou comando escrito à mão, armazenado no banco
de dados. Aqui, novamente, o teste de semelhança é exigido.
49
A noção de semelhança normalmente é subjetiva e específica do

usuário. Porém, o teste de semelhança normalmente é mais bem-sucedido
do que o reconhecimento de voz ou escrita manual, pois a entrada pode
ser comparada com dados já no sistema e, assim, o conjunto de opções
disponíveis ao sistema é limitado.
Existem vários algoritmos para encontrar as melhores combinações de

determinada entrada pelo teste de semelhança. Alguns sistemas, incluindo a
discagem por nome, sistema de telefone ativado por voz, foram implantados
comercialmente.
FONTE: Silberschatz, Korth e Sudarshan (2006, p. 620)
Para resumir e exemplificar uma das principais características que um banco

de dados multimídia precisa ter. Vamos pensar em um arquivo cujo conteúdo
é uma imagem. Quando trabalhamos com imagens, o sistema deve conseguir
identificar algumas particularidades delas. Por exemplo, listar todas as imagens
de um pôr de sol ou talvez todas as que contenham barcos cuja cor é branca. Para
isso ser possível é necessário identificar a semântica da imagem, ou seja, o que
significa e qual o seu conteúdo. Este conceito também é válido para áudio e vídeo.
2.3 BANCO DE DADOS TEMPORAL

Em um conceito resumido, podemos dizer que um banco de dados
temporal armazena o estado de um determinado objeto, procurando obter toda
a sua evolução. Fazendo uma junção deste conceito com os bancos de dados
relacionais, pode-se entender que o objeto pode ser uma tabela.
As aplicações rotineiras se preocupam normalmente em registrar quando

determinado fato ocorreu. Um banco de dados temporal se preocupa com todo o
histórico de todos os fatos. Isso pode ser confeccionado com base em intervalos de
datas ou intervalo de validade das informações.
Cabe ao projetista de banco de dados definir o formato de gerenciamento

dos dados de forma temporal. Alguns tipos de sistemas que podem consumir
um banco de dados temporal são: BI (Sistema de suporte a decisões ou Bussiness
Intelligence), SIGs (Sistemas de Informações Gerenciais) etc.
Alguns SGBDs fornecem meios para o desenvolvimento de bancos

temporais. Entre eles, existe um grande destaque por parte da Oracle, com o Time
Series Cartridge.
50
2.4 BANCOS DE DADOS BIOLÓGICOS

Tendo em vista que existem vários estudos desenvolvidos no campo da
biologia, existe a necessidade de documentá-los e armazená-los em locais seguros.
Esse é o conceito de bancos de dados biológico. Alguns são públicos, outros
privados. Podem oferecer também integração com outros bancos de dados.
UNI
O site <http://pt.scribd.com/doc/58841709/Banco-de-Dados-biologico> traz

alguns exemplos de bancos de dados biológicos.
Projeto GMOD
“O Generic Model Organism Database Project é um projeto open source,

cujo objetivo é desenvolver um conjunto completo de softwares para a criação
e administração de um banco de dados biológico”. GMOD (2004). Financiado
pelo NIH (National Instituteof Health) e pelo USDA Agricultural Research Service.
Citrina
O Citrina consiste em uma ferramenta de gerência que permite automatizar

o espelhamento e processamento de bancos de dados que estão distribuídos
através de diversos servidores FTP. A mesma foi desenvolvida através da
tecnologia Java Ant, o que a torna mais flexível e portável.
Um exemplo de uso para o Citrina seria a transferência de Chado SQL

entre vários sites de organismos e a população automática dos diversos bancos
de dados PostgreSQL através dos recursos de SQL fornecidos pela tecnologia
Java Ant.
BioMart
Sistema de Integração de dados orientado a consultas, baseado na ideia

de Data Warehouse.
Sistema de Consultas desenvolvido especificamente para uso de grandes

bancos de dados. Simplifica a tarefa de integração entre diferentes bancos de
dados distribuídos pela rede.
51
Chado
Segundo Chado (2004), consiste em um “... conjunto de módulos de um

esquema destinados à construção de um esquema de banco de dados biológico
relacional....”
O Chado foi desenvolvido com o intuito de ser aplicado, especificamente,

a um banco de dados open source, como é o caso do PostGreSQL (PostgreSQL,
2004) e do MySQL (MySQL, 2004). Além disso, outro pré-requisito para o
funcionamento eficiente do Chado é a configuração de diversos pacotes BioPerl
(BioPerl, 2004).
O Chado está sendo utilizado atualmente pelo FlyBase (FlyBase, 2004) e

pelo Berkeley Drosophila Genome Project (BDGP, 2004).
O Chado, o qual constitui um dos subprojetos do GMOD, apresenta-se

como um esquema mais simples e genérico para a representação de dados
biológicos. Este esquema ainda se encontra em desenvolvimento, o que pode ser
verificado na grande simplicidade nos módulos responsáveis pela representação
de mapas genéticos, interações genéticas e expressão gênica.
Todos os dados resultantes das análises de um projeto genoma são

armazenados nos chamados bancos de dados biológicos. Inicialmente, cada
laboratório desenvolveu o seu próprio banco de dados, contemplando somente
as necessidades do projeto genoma por ele sendo executado.
Um banco de dados genômico para os biólogos geralmente é um web site

que apresenta informações que muitas vezes estão armazenadas em arquivos
texto.
Outras vezes, os dados podem até estar em SGBDs, mas isto só começou
a se tornar realidade há poucos anos. Por exemplo, o www.plasmodb.org, um
“banco de dados genômico” do Plasmodium (causador da malária) usa dados
armazenados tanto em arquivos texto quanto em Oracle. A migração vem se
dando há pouco tempo.
O banco de dados biológico mais famoso é o GenBank.

FONTE: Disponível em: <http://pt.scribd.com/doc/58841709/Banco-de-Dados-biologico>.
Acesso em: 24 dez. 2012.
52
2.5 BANCO DE DADOS XML

O XML (Extensible Markup Language) é uma linguagem de marcação
extensível criada em 1996. Pode ser utilizada para troca, compartilhamento e
armazenamento de dados.
Rob e Coronel (2011, p.615) fazem um relato do cenário onde a XML pode
estar envolvida.
A internet fez surgir novas tecnologias que facilitam a troca de dados

de negócios entre parceiros comerciais e clientes. As empresas têm
utilizado a internet para criar novos tipos de sistemas que integrem seus
dados de modo a aumentar a eficiência e reduzir custos. O comércio
eletrônico (e-commerce) permite que todos os tipos de organizações
vendam produtos e serviços em um mercado global de milhões de
usuários. As transações de comércio eletrônico – venda de produtos ou
serviços – podem ser executados entre empresas (business-to-business ou
B2B) ou entre uma empresa e um cliente (business-to-consumer ou B2C).
A maioria dessas transações ocorre entre empresas. Como o comércio
eletrônico B2B integra processos de negócios entre empresas, ele exige
a transferência de informações comerciais entre as diferentes entidades.
Mas o modo como os dados são representados, identificados e utilizados
tende a diferir significativamente de empresa para empresa [...].
De uma forma bem resumida, pode-se dizer que XML consiste em descrever
o conteúdo dos campos em um formato de marcação. É amplamente utilizado na
internet para integração entre sistemas.
A figura a seguir mostra um exemplo de XML.
FIGURA 25 – EXEMPLO XML
FONTE: Disponível em: <http://blog.kirupa.com/?p=227>. Acesso em: 27

jan. 2013.
53
3 TIPOS DE GERENCIAMENTO DE DADOS

No cenário em que vivemos hoje, as empresas precisam estar preparadas e
“munidas” de informações que possam gerar valor competitivo para o seu negócio.
Para que isso aconteça, precisamos de uma forma de analisar os dados disponíveis
nos seus sistemas a fim de gerar informação e conhecimento. Vale a pena lembrar-
se do que foi apresentado no início desta unidade: a partir dos dados são geradas
informações e a interpretação dessas informações gera conhecimento.
FIGURA 26 – DADOS SÃO UTILIZADOS PARA GERAR INFORMAÇÃO
FONTE: Disponível em: <http://gestorsistemas.info/content/?secao=data_

mining>. Acesso em: 27 jan. 2013.
Rob e Coronel (2011, p. 535) fazem um relato sobre a necessidade de análise

e gerenciamento de dados analisados.
54
As organizações tendem a crescer e prosperar quando obtêm melhor

compreensão de seu ambiente. A maioria dos gerentes deseja rastrear
as transações diárias para avaliar o fluxo dos trabalhos. Recorrendo ao
banco de dados operacional, a gerência pode desenvolver estratégias
que atendam as metas organizacionais. Além disso, a análise dos
dados pode fornecer informações sobre estratégias e avaliações táticas
de curto prazo como as seguintes: nossas promoções de vendas estão
funcionando? Que porcentagem do mercado controlamos? Estamos
atraindo novos clientes? As decisões táticas e estratégicas também são
moldadas por uma pressão constante de forças externas e internas,
incluindo a globalização, o ambiente legal, cultural e (talvez o mais
importante) a tecnologia.
Esta seção trata de formas de analisar e gerar informações e conhecimento

acerca de um determinado negócio. Esse processo também pode ser denominado
de estudo de atividades para gerar informações de apoio à decisão. Envolve os
seguintes itens que serão posteriormente estudados: Data Mining, Data Warehouse,
Data Mart e Data Marketing.
3.1 DATA MINING

Data Mining ou mineração de dados é um dos primeiros processos que são
executados a fim de construir uma nova base de dados que gere conhecimento e
informações de apoio à decisão.
FIGURA 27 – PROCESSOS DE DATA MINING
FONTE: Disponível em: <http://imasters.com.br/artigo/10229/tecnologia/mineracao-de-

dados-e-web-semantica/>. Acesso em: 27 jan. 2013.
55
Rob e Coronel (2011) nos dizem que o banco de dados de suporte a decisões
é criado, em grande parte, pela extração de dados do banco operacional e pela
importação de dados adicionais de fontes externas. Isso significa que as empresas
já possuem seus sistemas de gerenciamento e extraem os dados dos mesmos para
buscar padrões que sejam valiosos para o ramo do negócio.
UNI
O texto disponível em: <http://www.intelliwise.com/reports/i2002.htm> elucida

de forma mais pormenorizada o que vem a ser um Data Mining. Ele também traz alguns
termos que serão vistos em seguida, como Data Warehouse e Data Mart.
Data Mining é uma das novidades da Ciência da Computação que veio

para ficar. Com a geração de um volume cada vez maior de informação, é
essencial tentar aproveitar o máximo possível desse investimento. Talvez a
forma mais nobre de se utilizar esses vastos repositórios seja tentar descobrir
se há algum conhecimento escondido neles. Um banco de dados de transações
comerciais pode, por exemplo, conter diversos registros indicando produtos
que são comprados em conjunto. Quando se descobre isso, pode-se estabelecer
estratégias para otimizar os resultados financeiros da empresa. Essa já é uma
vantagem suficientemente importante para justificar todo o processo. Contudo,
embora essa ideia básica seja facilmente compreensível, fica sempre uma dúvida
sobre como um sistema é capaz de obter esse tipo de relação. No restante deste
artigo vamos observar alguns conceitos que podem esclarecer essas dúvidas.
O que é Data Mining?
Talvez a definição mais importante de Data Mining tenha sido elaborada

por Usama Fayyad (Fayyad et al. 1996):
“[...] o processo não trivial de identificar, em dados, padrões válidos,
novos, potencialmente úteis e ultimamente compreensíveis”.
Esse processo vale-se de diversos algoritmos (muitos deles desenvolvidos

recentemente) que processam os dados e encontram esses “padrões válidos,
novos e valiosos”. É preciso ressaltar um detalhe que costuma passar
despercebido na literatura: embora os algoritmos atuais sejam capazes de
descobrir padrões “válidos e novos”, ainda não temos uma solução eficaz para
determinar padrões valiosos. Por essa razão, Data Mining ainda requer uma
interação muito forte com analistas humanos, que são, em última instância, os
principais responsáveis pela determinação do valor dos padrões encontrados.
56
Além disso, a condução (direcionamento) da exploração de dados é também

tarefa fundamentalmente confiada a analistas humanos, um aspecto que não
pode ser desprezado em nenhum projeto que queira ser bem sucedido.
Os passos do Data Mining
A literatura sobre o assunto trata com mais detalhes todos os passos

necessários ao Data Mining. Veja, por exemplo, Groth (1998) e Han, Chen & Yu
(1996). Para o escopo do que pretendemos neste artigo é suficiente apresentar
os passos fundamentais de uma mineração bem sucedida. A partir de fontes
de dados (bancos de dados, relatórios, logs de acesso, transações, etc.) efetua-se
uma limpeza (consistência, preenchimento de informações, remoção de ruído e
redundâncias etc.). Disto nascem os repositórios organizados (Data Marts e Data
Warehouses), que já são úteis de diversas maneiras.
Mas é a partir deles que se pode selecionar algumas colunas para

atravessarem o processo de mineração. Tipicamente, este processo não é o final
da história: de forma interativa e frequentemente usando visualização gráfica,
um analista refina e conduz o processo até que valiosos padrões apareçam.
Observe que todo esse processo parece indicar uma hierarquia, algo que
começa em instâncias elementares (embora volumosas) e terminam em um
ponto relativamente concentrado, mas muito valioso.
57
Este é um dos conceitos importantes para nós neste artigo: encontrar

padrões requer que os dados brutos sejam sistematicamente "simplificados" de
forma a desconsiderar aquilo que é específico e privilegiar aquilo que é genérico.
Faz-se isso porque não parece haver muito conhecimento a extrair de eventos
isolados. Uma loja de sua rede que tenha vendido a um cliente em particular
uma quantidade impressionante de um determinado produto em uma única
data pode apenas significar que esse cliente em particular procurava grande
quantidade desse produto naquele exato momento. Mas isso provavelmente
não indica nenhuma tendência de mercado.
Em outras palavras, não há como explorar essa informação em particular

para que no futuro a empresa lucre mais. Apenas com conhecimento genérico é
que isto pode ser obtido. Por essa razão devemos, em Data Mining, controlar
nossa vontade de "não perder dados". Para que o processo dê certo, é necessário
sim desprezar os eventos particulares para só manter aquilo que é genérico.
FONTE: Disponível em: <http://www.intelliwise.com/reports/i2002.htm>. Acesso em:

24 dez. 2012.
3.2 DATA WAREHOUSE

Resumidamente, podemos dizer que um Data WareHouse é um banco de
dados que possui todos os dados da organização que são pertinentes para uma
futura análise. Rob e Coronel (2011) explicam que Data WareHouse normalmente é
um banco de dados apenas de leitura, otimizado para processamento de análises
e consultas. Geralmente, os dados são extraídos de várias fontes e, em seguida,
transformados e integrados.
É conhecido também como armazém de dados por reunir dados de vários

sistemas distintos. Nas organizações é comum existirem sistemas específicos para
algumas áreas, como por exemplo, folha de pagamento, faturamento, vendas etc.
Quando chega o momento de responder a algumas perguntas, é muito complicado
ir a cada sistema e pesquisar os dados relacionados. Por isso, através de um
processo de Data Mining é gerado um Data WareHouse com os dados da empresa.
UNI
Tudo é feito para melhorar a tomada de decisão das empresas. O texto a seguir
mostra como isso é possível.
58
COMO UM DATA WAREHOUSE PODE MELHORAR A TOMADA DE

DECISÃO NAS EMPRESAS?
A principal proposta do data warehouse é colocar nas mãos dos analistas

de negócios dados estratégicos para as tomadas de decisões baseadas em
fatos reais e não por intuição. A produtividade oferecida pelo data warehouse é
traduzida em ganho de tempo e dinheiro. Na construção de um banco de
dados para suporte a um data warehouse são filtrados e normalizados os dados
de vários bancos de dados dos sistemas estruturados, formando uma base de
dados com todos os dados relevantes da empresa ou de uma área específica.
Com o cruzamento desses dados extraem-se informações que os sistemas de
informações estruturados não conseguem identificar. O banco Itaú enviava
cerca de um milhão de malas diretas para seus correntistas e obtinha apenas 2%
de retorno, após a implantação do data warehouse o retorno passou para 30% e a
conta do correio diminuiu para um quinto.
Em muitas empresas quando um executivo faz uma pergunta sobre

o perfil dos seus negócios fora de um padrão definido pelos analistas de
sistemas o tempo e o esforço para respondê-la é muito grande. Várias bases
de dados devem ser consultadas, programas de pesquisas são construídos,
download de arquivos para microcomputadores para manipulação dos dados
e gerar relatórios gráficos. Se uma decisão deve ser tomada acompanhando a
velocidade do mercado, o executivo acaba tomando a decisão por intuição não
podendo esperar o resultado da área de sistemas.
Quando o assunto é simulação de cenários de negócios o processo é

ainda mais traumático. Os sistemas estruturados atuais não são suficientemente
flexíveis para traçar cenários complexos usando cruzamento de vários
componentes. Os bancos de dados tradicionais possuem visão bidimensional,
por exemplo, enxergam uma tabela de produto por região. As ferramentas
de data warehouse possuem a visão de uma tabela multidimensional, por
exemplo, geram uma tabela de produto x região x período de tempo.
Os data warehouses já colecionam muitas estórias de sucesso. A clássica foi o

resultado obtido pela rede americana de supermercados Wal-Mart quanto o seu
data warehouse identificou uma relação entre o consumo de fraldas descartáveis
e o consumo de cerveja. Analisando a informação do data warehouse verificou-
se que quando os maridos iam ao supermercado à noite para comprar fraldas
aproveitavam e compravam algumas cervejas. Constatado o fato, elaborou-se
uma estratégia de vendas onde as fraldas ficam próximas as cervejas, induzindo
os maridos a comprarem as cervejas. O resultado foi o aumento de vendas das
cervejas. Outro exemplo é o caso da empresa de telecomunicações americana Sprint
que com o seu data warehouse consegue identificar com 60 dias de antecedência os
usuários que trocaram seus serviços por outra operadora. Através de um marketing
agressivo ela conseguiu evitar a deserção de 120.000 clientes e uma perda de 35
milhões de dólares em faturamento.
59
A introdução de um data warehouse em uma empresa exige uma mudança

de comportamento dos executivos e sua relação entre os computadores e as
informações. Os data warehouse mantêm um quadro único e coerente das
informações ao longo da empresa, uma única versão da verdade, trazendo
produtividade e ganho de dinheiro.
FONTE: Disponível em: <http://www.efagundes.com/artigos/Como%20um%20data%20
warehouse%20pode%20melhorar%20as%20tomadas%20de%20decisoes%20nas%20empresas.
htm>. Acesso em: 24 dez. 2012.
3.3 DATA MART

Com o passar dos anos, foi percebido que os usuários responsáveis por
extrair informações dos Data WareHouses usavam uma pequena parte dele para
realizar o seu trabalho. Neste mesmo conjunto era preciso criar novas visões e
executar os mesmos procedimentos de forma repetitiva a cada atualização recebida.
É nesse cenário que surge a definição de Data mart.
Para Date (2003), Data Mart é um depósito de dados especializado,

orientado por assunto, integrado, volátil e variável no tempo, que fornece apoio a
um subconjunto específico de decisões da gerência. É um agrupamento de dados e
informações dentro do Data WareHouse com um objetivo específico e bem definido.
3.4 DATA MARKETING

Em uma definição bem simplista, pode-se dizer que é um banco de dados
utilizado para relacionamento com clientes. É nele que estão os dados utilizados
para atingir objetivos de venda, público alvo para promoções etc.
UNI
O texto disponibilizado no site <http://www.benic.com.br/marketing-digital/blog/

o-que-e-database-marketing> deixa claro quais são os benefícios da utilização deste conceito.
60
O QUE É DATABASE MARKETING
Caso a sua empresa queira adotar estratégias de retenção de

clientes, fundamentadas no Marketing de Relacionamento, é imprescindível que
possua tecnologia que possibilite desenvolver com eficácia essas estratégias.
A base do Marketing de Relacionamento é a personalização do

relacionamento com os clientes, mas como realizar esta personalização se
sua empresa possuiu milhares e até milhões de clientes em um único ano? É
impossível imaginar alguma estratégia de Marketing de Relacionamento sem
contemplar a área de Tecnologia da Informação.
Somente com o uso da Tecnologia é possível armazenar, recuperar,

processar, comunicar e analisar os dados dos seus clientes. Ter um banco de dados
com as informações dos clientes é condição primordial para o desenvolvimento
de uma estratégia de Marketing de Relacionamento.
Este banco de dados, criado para armazenar as informações sobre os

seus consumidores, é chamado de Database Marketing (DBM).
O Database Marketing é uma ferramenta para utilização das informações

internas e externas para filtrar o mercado alvo, desenvolver o planejamento de
vendas inteligentes e mensagens de promoções e de marketing que sejam relevantes.
FONTE: Disponível em: <http://www.benic.com.br/marketing-digital/blog/o-que-e-database-
marketing>. Acesso em: 24 dez. 2012.
4 NOVOS CONCEITOS
Esta última seção da Unidade 1 tem como objetivo apenas introduzir
alguns novos conceitos existentes no mercado. Entenda que estamos tratando
de novas tecnologias e que muitas delas ainda não chegaram ao seu ápice de
desenvolvimento e utilização. Isso pode significar que poderão sofrer alterações
quando a sua definição e aplicação durante este período de amadurecimento.
Trataremos apenas de dois novos conceitos: Big Data e NoSQL. Vamos focar
apenas no paradigma das tecnologias, passando de forma superficial por questões
técnicas de implementação.
61
4.1 BIG DATA

Muito tem se falado sobre essa nova tecnologia. Ela visa atender basicamente
ao gerenciamento de grandes volumes de dados. Imagine a quantidade de dados
gerados por tweets no mundo inteiro. Agora pense no seguinte: esses dados
podem revelar muitas coisas a respeito de um determinado cenário. Através
da análise deles é possível, de certa forma, medir o nível de felicidade de uma
determinada população, a satisfação das pessoas em relação a determinado
produto comercializado por alguma empresa, entre várias outras situações.
Várias empresas já utilizam o conceito de Big Data em seus negócios. A

figura a seguir dá uma visão geral do conceito.
FIGURA 28 – CENÁRIO ATUAL DO BIG DATA
FONTE: Disponível em: <http://oglobo.globo.com/infograficos/bigdata/>. Acesso em: 27 jan.

2013.
62
UNI
Um texto publicado na Info Abril: <http://info.abril.com.br/noticias/computacao-

inteligente/aplicativo-de-big-data-e-tendencia-nas-corporacoes-diz-especialista-07012013-20.
shl>, destaca a tendência de utilização do Big Data nas empresas.
APLICATIVO DE BIG DATA É TENDÊNCIA NAS CORPORAÇÕES, DIZ

ESPECIALISTA
São Paulo – Uma pesquisa da IBM mostra que 90% de todos os dados
divulgados na internet surgiram nos últimos dois anos. Além disso, as corporações
de diferentes áreas digitalizam e compartilham documentos na web diariamente.
Segundo Ederson Riechelmann, diretor de outsourcing da Unione, é

necessário usar aplicativos de Big Data (BDA) para organizar e usar todos estes
dados. Ainda de acordo com o especialista, o uso destes apps é certamente uma
tendência nas corporações.
As áreas que possuem urgência em usar estes apps são a comercial e de

marketing. É possível, por exemplo, usar esta tecnologia para cruzar os dados
e descobrir a rotina e os gastos mensais de um cliente e personalizar anúncios
direcionados a ele.
Riechelmann explica que a área de segurança também é influenciada

positivamente pelo avanço no mercado de aplicativos de Big Data.
Seria inviável comercializar estes apps sem uma forte barreira contra
crackers e hackers. O especialista afirma que os todos esses resultados em usar
estas aplicações (BDA) serão notados em curto prazo.
FONTE: Disponível em: <http://info.abril.com.br/noticias/computacao-inteligente/aplicativo-de-
big-data-e-tendencia-nas-corporacoes-diz-especialista-07012013-20.shl>. Acesso em: 27 jan.
2013.
Como acontece com qualquer nova tecnologia, o mercado de trabalho carece

de profissionais para trabalhar com Big Data. Existe bastante material informativo
na internet, porém boa parte está disponível em inglês. O site <BigDataUniversity.
com> oferece cursos online e gratuitos sobre Big Data e pode ser uma boa opção
para quem domina a língua.
63
4.2 NOSQL
NoSQL é uma classe de bancos de dados que tem como principal destaque
o rompimento com o paradigma relacional, predominante durante vários anos no
mercado de TI. Ele representa vários bancos de dados que não são relacionais e
utilizam outras formas de organização, visando armazenamento e processamento
de dados complexos.
UNI
O texto disponível no site <http://imasters.com.br/artigo/17043/banco-de-dados/

nosql-voce-realmente-sabe-do-que-estamos-falando/> esclarece de forma mais aprofundada
o que é NoSQL.
O termo NoSQL foi usado pela primeira vez em 1998, como o nome de um
banco de dados relacional de código aberto que não possuía um interface SQL.
Seu autor, Carlo Strozzi, alega que o movimento NoSQL “é completamente
distinto do modelo relacional e, portanto, deveria ser mais apropriadamente
chamado ‘NoREL’ ou algo que produzisse o mesmo efeito”. Porém, o
termo só voltou a ser assunto em 2009, por um funcionário do Rackspace, Eric
Evans, quando Johan Oskarsson, da Last.fm, queria organizar um evento para
discutir bancos de dados open source distribuídos.
NoSQL são diferentes sistemas de armazenamento que vieram para

suprir necessidades em demandas onde os bancos de dados tradicionais
(relacionais) são ineficazes. Muitas dessas bases apresentam características
muito interessantes como alta performance, escalabilidade, replicação,
suporte a dados estruturados e subcolunas.
O NoSQL surgiu da necessidade de uma performance superior e de uma

alta escalabilidade. Os atuais bancos de dados relacionais são muito restritos a
isso, sendo necessária a distribuição vertical de servidores, ou seja, quanto mais
dados, mais memória e mais disco um servidor precisa. O NoSQL tem uma grande
facilidade na distribuição horizontal, ou seja, mais dados, mais servidores, não
necessariamente de alta performance. Um grande utilizador desse conceito é o
Google, que usa computadores de pequeno e médio porte para a distribuição dos
dados; essa forma de utilização é muito mais eficiente e econômica. Além disso, os
bancos de dados NoSQL são muito tolerantes a erros.
64
No caso dos bancos NoSQL, toda a informação necessária estará agrupada no

mesmo registro, ou seja, em vez de você ter o relacionamento entre várias tabelas
para formar uma informação, ela estará em sua totalidade no mesmo registro.
FONTE: Disponível em: <http://imasters.com.br/artigo/17043/banco-de-dados/nosql-voce-
realmente-sabe-do-que-estamos-falando/>. Acesso em: 27 jan. 2013.
De certa forma, pode-se dizer que bancos de dados que pertencem ao

paradigma NoSQL trabalham com o conceito de Big Data visto anteriormente.
Exemplos de bancos NoSQL: Berkeley DB, MemcacheDB, Cassandra (Apache),
MongoDB, InfoGrid e Vertica.
DATA WAREHOUSE OU DATA MART? PROJETANDO BI
Tiago Curcio
As organizações que almejam alta competitividade no mercado não

questionam a importância do Business Intelligence. A grande questão que se coloca
é por onde e como começar. Os analistas de mercado têm uma resposta que pode
parecer simplista, mas verdadeira: o tamanho do sapato deve ser o do tamanho
do pé. Em outros termos, empresas pequenas ou com pouca cultura tecnológica
podem começar usando algumas ferramentas de análise mais simples, como o EIS –
Executive Information Systems, que são amigáveis e fornecem informações gerenciais
de forma rápida e eficiente. Outra opção são as DSS – Decision Support Systems,
sistemas de apoio à decisão que surgiram a partir dos sistemas transacionais e
utilizam modelos para solucionar problemas não estruturados. São ferramentas
que podem auxiliar as empresas a se familiarizar com os conceitos e tecnologias
relativas ao BI, e evoluir nesse sentido aos poucos.
O fundamental é entender que os dados precisam ser estruturados de forma

diferente do que ocorre nos sistemas transacionais. Por isso, os especialistas no
assunto ressaltam que um dos principais pilares do BI é o Data Warehouse (DW).
Como bem define William (Bill) Inmon, considerado o pai do DW, esse repositório
nada mais é do que um banco de dados orientado por assuntos, não volátil (os dados
não podem sofrer modificações) e integrado. No DW há apenas a carga dos dados e
a consulta. Não há atualizações. Variável com o tempo é outra característica inerente
ao DW. Isso significa que sempre será retratada uma situação num determinado
ponto do tempo. É como se pegássemos uma foto de uma pessoa com um ano de
idade e outra foto, dessa mesma pessoa, aos 10 anos de idade, para então fazer
uma comparação e verificar as modificações ocorridas. No DW os assuntos são
guardados em determinados pontos no tempo, o que permite uma análise histórica
e comparativa dos fatos. Os dados podem ser retirados de múltiplos sistemas de
computação utilizados internamente na empresa, ou também podem vir de fontes
65
externas. Em resumo, um DW pode ser definido como um conjunto de técnicas e de

bancos de dados integrados, projetados para suportar as funções dos Sistemas de
Apoio à Decisão, onde cada unidade de dados está relacionada a um determinado
assunto ou fato. Sua meta é fornecer subsídios e informações aos gerentes e diretores,
para que assim possam analisar tendências históricas de seus clientes e, com isso,
melhorarem os processos e agilizarem as tomadas de ações.
O maior problema do Data Warehouse é a sua grande complexidade. Sua

criação requer pessoas altamente especializadas, uma metodologia consistente,
computadores, banco de dados, ferramentas de front-end (sistemas transacionais
– para captura dos dados), ferramentas para extração e limpeza dos dados, e
treinamento dos usuários. É um processo complicado e demorado, que requer altos
investimentos e que se não for corretamente planejado e executado, pode trazer
prejuízos enormes e se tornar um grande elefante branco dentro da organização.
Uma forma de minimizar os riscos seria começar com o desenvolvimento

de Data Marts departamentais e, numa fase posterior, integrá-los transformando-
os num Data Warehouse.
Em termos conceituais, pode-se afirmar que um Data Mart é um mini Data

Warehouse que fornece suporte à decisão para um pequeno grupo de pessoas –
como aos profissionais da área de marketing, ou de vendas, por exemplo. O tempo
de desenvolvimento e implementação, assim como os investimentos necessários,
também são bem menores, em comparação ao DW. Segundo estimativas, enquanto
um Data Mart custa em torno de US$ 100 mil a US$ 1 milhão e leva cerca de 20 dias
para ficar pronto, um DW integral começa a partir de US$ 2 milhões e demora
no mínimo um ano para estar consolidado. Mas são valores apenas estimados,
uma vez que não existe um projeto padrão que serve para todas as empresas
indistintamente. O montante aplicado depende de cada caso.
De acordo com alguns especialistas no assunto, as diferenças existentes

entre um Data Mart e um Data Warehouse são apenas com relação ao tamanho
do projeto e ao escopo da empresa. Portanto, as definições dos problemas e os
requisitos dos dados são essencialmente os mesmos para ambos. No entanto,
um Data Mart trata das questões departamentais ou locais (de um departamento
específico), enquanto um DW envolve as necessidades de toda a companhia de
forma que o suporte à decisão atue em todos os níveis da organização.
Ralph Kimball, consultor norte-americano e considerado um dos mais

influentes gurus do Business Intelligence, discorda dessa definição e argumenta que
os Data Marts não devem ser departamentais, mas, sim, orientados aos dados ou a
fontes de dados. Ele exemplifica o caso de uma instituição bancária que dispõe de
uma fonte de dados de contas correntes e poupança. Nesse caso deveria ser criado
um Data Mart de Contas, que não será um Data Mart proprietário da área financeira,
e nem da área de marketing, mas sim um repositório de dados que terá como público
todos os usuários de todos os departamentos que lidam com aquele assunto.
66
Ralph Kimball é um defensor da teoria de que o DW deve ser dividido para

depois ser conquistado, ou seja, que o mais viável para as empresas é desenvolver
vários Data Marts para posteriormente integrá-los e, assim, chegar-se ao DW. Na
sua avaliação, as empresas devem construir Data Marts orientados por assuntos.
Ao final, teriam uma série de pontos de conexão entre eles, que seriam as tabelas
Fato e Dimensão em conformidade. Dessa forma, informações entre os diferentes
Data Marts poderiam ser geradas de maneira íntegra e segura. Kimball batizou
esse conceito de Data Warehouse Bus Architeture.
Bill Inmon rebate essa teoria e propõe justamente o contrário. Na

sua avaliação deve-se construir primeiro um Data Warehouse, modelando-se toda a
empresa para se chegar a um único modelo corporativo, partindo-se posteriormente
para os Data Marts construídos por assuntos ou departamentais. Inmon defende a
ideia de que o ponto de partida seriam os CIF – Corporate Information Factory – uma
infraestrutura ideal para ambientar os dados da empresa. O CIF seria alimentado
pelos sistemas transacionais. A construção de um ODS (Operational Data Store) seria
facultativa, mas essa iniciativa ajudaria a reduzir a complexidade da construção de
um DW, uma vez que todo o esforço de integração entre os sistemas transacionais
da empresa seria depositado nele.
Uma vez que todos os dados estivessem integrados no DW, se partiria para
os Data Marts que iriam atender aos diversos departamentos da empresa, gerando
dados íntegros e corporativos. Inmon condena o processo inverso porque, na sua
concepção, a construção de Data Marts atendendo a requisitos departamentais seria
delineada a partir de regras específicas de negócios e de procedimentos de Extração,
Transformação e Carga (ETL) dos dados oriundos dos sistemas transacionais. A
visão corporativa da empresa seria relegada a segundo plano e as necessidades
imediatas dos departamentos prevaleceriam. Além disso, essa iniciativa poderia
gerar outros problemas, como a redundância de dados em diversos sistemas, o
consumo exagerado de recursos de produção, e a formação de um verdadeiro caos
informacional, na medida em que os dados dispostos nos diferentes Data Marts
não poderiam ser integrados.
Qual deles está certo: Inmon ou Kimball? Ambos ou nenhum? Cabe a cada
empresa analisar qual das duas abordagens mais se aplica às suas necessidades
reais e ao seu bolso. No que ambos os gurus concordam é que uma empresa sem
autoconhecimento e sem ter uma visão corporativa de seu negócio, nunca terá um
sistema eficiente para auxiliá-la na tomada de decisão.
FONTE: Disponível em: <http://www.tiagocurcio.com/data-warehouse-ou-data-mart-2/>. Acesso

em: 27 jan. 2013.
67
RESUMO DO TÓPICO 3
• Existem vários tipos de bancos de dados. Alguns exemplos são: bancos de dados
de informações geográficas, multimídia, temporal, biológicos e XML.
• Data Mining é um processo de mineração de dados que visa construir um Data

Warehouse. Data Warehouse é uma espécie de centralização dos dados da empresa
com foco em apoio à tomada de decisão.
• Data Mart é um tipo de organização de dados com um fim bem específico e

definido. Também visa dar apoio a tomada de decisão e normalmente se encontra
dentro de uma organização de Data WareHouse.
• Big Data e NoSQL são novas tecnologias que visam à armazenamento e

manipulação de grande quantidade de dados.
68
AUTOATIVIDADE
1 De acordo com o conteúdo estudado no neste tópico, defina por que é

importante a busca por semelhança em bancos de dados multimídia.
2 Quais são os objetos que um banco de dados de informações geográficas

pode armazenar?
3 Com base no conteúdo apresentado no Caderno de Estudos defina o que é

um processo de Data Mining.
4 Qual é a diferença entre Data Warehouse e Data Mart?
5 Defina o que é o novo paradigma de bancos de dados denominado Big Data?
69
70
UNIDADE 2
MODELAGEM DE DADOS
A partir desta unidade, você será capaz de:
• conhecer o processo de modelagem de dados;
• identificar uma entidade e seus atributos;
• compreender a aplicação das formas normais.
PLANO DE ESTUDOS
Esta unidade está dividida em cinco tópicos e em cada um deles, você
encontrará atividades que proporcionarão a compreensão dos conteúdos
apresentados.
TÓPICO 1 – MODELOS DE DADOS
TÓPICO 2 – MODELO ENTIDADE-RELACIONAMENTO
TÓPICO 3 – TIPOS DE RELACIONAMENTOS
TÓPICO 4 – MODELO RELACIONAL
TÓPICO 5 – NORMALIZAÇÃO DE DADOS
71
72
UNIDADE 2
TÓPICO 1
MODELOS DE DADOS
1 INTRODUÇÃO
O conhecimento da modelagem de dados é muito importante para
qualquer desenvolvedor que, em algum momento, construir alguma aplicação
que irá interagir com um banco de dados. Independente do tamanho da aplicação
a ser desenvolvido, o sucesso estará diretamente relacionado a uma modelagem
bem feita, de modo a garantir dados consistentes, armazenados de forma eficiente,
proporcionando bom desempenho e também a integridade dos dados.
O objetivo da modelagem de dados é garantir que todos os objetos de

dados existentes em determinado contexto e requeridos pela aplicação estejam
representados com precisão dentro do Banco de Dados.
Podemos definir modelagem de dados como sendo um conjunto de conceitos

que devem ser usados para descrever a estrutura de uma base de dados. Quanto
mais fiel a modelagem for ao ambiente em análise, maior é a chance de o projeto ter
um bom resultado, permitindo assim a criação de um banco de dados mais aderente
à realidade, possibilitando de forma mais eficiente o desenvolvimento da aplicação.
Uma modelagem mal feita, por sua vez, pode comprometer o sucesso do
projeto, tendo como consequência diversos problemas, como por exemplo, a aplicação
não funcionar adequadamente, os dados não confiáveis devido à falta de integridade,
baixo desempenho etc.
O objetivo da modelagem é criar uma abstração da realidade que seja capaz

de registrar os acontecimentos, de forma que seja possível programar um sistema
que atenda às devidas necessidades e informações esperadas pelo usuário. A
modelagem de dados utiliza notações em idioma natural, podendo ser facilmente
compreendidos, por conta disso, é recomendado que o modelo de dados, depois de
elaborado, sejam revisados e verificados pelos usuários finais.
A representação dos dados pode estar submetida a diferentes níveis de

abstração. Estes níveis podem ser classificados como: modelos conceituais, modelos
lógicos e modelos físicos. Veremos mais detalhes durante esta unidade.
O objetivo desta unidade é dar um embasamento para que você tenha as

condições e conhecimentos mínimos para projetar um banco de dados relacional
dentro da metodologia e segurança necessária para o sucesso de uma aplicação.
73
UNIDADE 2 | MODELAGEM DE DADOS
2 MODELO CONCEITUAL
Segundo Machado (2009), a princípio toda realidade é sempre bastante
nebulosa e informal. Ao observarmos esta realidade, podemos identificar fatos
que nos levam a conhecê-la de uma forma mais organizada. Os fatos observados
e modelados dizem algo a respeito do funcionamento de um negócio que estamos
tentando compreender e manter.
O Modelo Conceitual é uma descrição mais abstrata da realidade, onde

os fatos do mundo real são descritos de uma forma mais natural, bem como suas
propriedades e relacionamentos. Esse modelo é utilizado para entendimento,
transmissão, validação de conceitos e mapeamento do ambiente, possibilitando
um melhor diálogo entre desenvolvedores e usuários.
Conforme relato de Machado (2004), o Modelo Conceitual deve ser sempre

a primeira etapa de um projeto de um Banco de Dados (DB), onde o objetivo deste
modelo é descrever de forma simples e facilmente compreensível pelos usuários
finais as informações em um contexto de negócio, para posteriormente serem
armazenadas em um banco de dados. É uma definição de alto nível que retrata
toda a realidade de uma organização, processo de negócio, setor, repartição,
departamento etc.
Durante o processo de criação do modelo conceitual, o analista deverá

observar fatos e também buscar documentações, registros, regras etc. que
possam lhe proporcionar um melhor entendimento do processo que se propõe a
automatizar. Porém, é importante que o processo se atenha aos fatos relevantes
que serão utilizados para a geração de informações e registro no sistema proposto.
É importante destacar que o Modelo Conceitual não está relacionado

com o modelo de banco de dados, forma de acesso ou armazenamento dos
dados. Ele está focado em uma representação gráfica da uma realidade
existente em um contexto de negócio, conforme está ilustrado na figura a
seguir. Essa modelagem é feita utilizando o modelo entidade-relacionamento.
Nos próximos tópicos veremos mais detalhes.
FIGURA 29 – MODELO CONCEITUAL
FONTE: Os autores
74
TÓPICO 1 | MODELOS DE DADOS
3 MODELO LÓGICO
O Modelo Lógico tem por objetivo representar as estruturas que irão

armazenar os dados dentro de um Banco de Dados, a partir deste momento é que
são definidas com maior propriedade as entidades e os seus atributos.
O Modelo Lógico é iniciado somente a partir da estruturação do Modelo

Conceitual. Nesta etapa é que será levada em consideração qual abordagem será
utilizada referente ao Banco de Dados: Relacional, Hierárquico ou de Rede. Assim,
o modelo lógico é diretamente dependente da abordagem, que determinará o tipo
de SGDB que será utilizado.
O Modelo Lógico representa os dados em uma estrutura de armazenamento

de dados. Nesse momento é definido a estrutura de registro do Banco de Dados,
seus registros e números de campos com seus respectivos tamanhos, conforme a
figura a seguir.
FIGURA 30 – MODELO LÓGICO
FONTE: Os autores
4 MODELO FÍSICO
O Modelo Físico é construído com base em um modelo lógico definido,
com intuito de ser aplicado sobre um SGDB. Neste momento entram as questões
relacionadas ao tipo e tamanho do campo, relacionamento, indexação, restrições
etc. Ele descreve as estruturas físicas de armazenamento, tais como tabelas, índices,
gatilhos, funções, visões, nomenclaturas etc.
O modelo físico, conforme Machado (2004) é a etapa final do projeto de banco

de dados, onde será utilizada a linguagem de definição de dados do SGDB (DDL)
para a construção do banco de dados com base no script SQL gerado. A figura a seguir
representa um Modelo Físico que foi concebido a partir da ferramenta DBDesigner.
75
FIGURA 31 – MODELO FÍSICO
FONTE: Os autores
Normalmente, as ferramentas de modelagem têm funções para criação de

scripts que serão responsáveis pela implementação do projeto físico em diversos
SGBDs. Tomando como exemplo o projeto acima, temos como resultado o
seguinte script SQL:
CREATE TABLE FILME (

Codigo Filme INTEGER(6) NOT NULL,
Titulo VARCHAR(100),
GeneroVARCHAR(50),
Ano INTEGER(4),
Duracao TIME,
Diretor VARCHAR(150),
FaixaEtariaINTEGER(2) UNSIGNED,
PRIMARY KEY(Codigo Filme)
);
CREATE TABLE CINEMA (

Codigo do Cinema (CNPJ) INTEGER NOT NULL,
Nome Fantasia VARCHAR(100),
Rua VARCHAR(100),
Bairro VARCHAR(100),
Cidade INTEGER(6),
Estado INTEGER(6),
LotacaoINTEGER(3),
PRIMARY KEY(Codigo do Cinema (CNPJ))
)
76
CREATE TABLE EXIBICAO (

Data Início DATE NOT NULL,
Data Fim DATE NOT NULL,
FILME_Codigo Filme INTEGER(6) NOT NULL,
CINEMA_Codigo do Cinema (CNPJ) INTEGER NOT NULL,
PRIMARY KEY(Data Inicio, FILME_Codigo Filme, CINEMA_Codigo do Cinema
(CNPJ)),
INDEX FK2_EXIBICAO_FILME(FILME_Codigo Filme),
INDEX FK1_EXIBICAO_CINEMA(CINEMA_Codigo do Cinema (CNPJ)),
FOREIGN KEY(FILME_CodigoFilme)
REFERENCES FILME(Codigo Filme)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
FOREIGN KEY(CINEMA_Codigo do Cinema (CNPJ))
REFERENCES CINEMA(Codigo do Cinema (CNPJ))
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
UNI
Caso você não tenha entendido o script gerado, não se preocupe, pois
abordaremos mais detalhes sobre este assunto na Unidade 3.
DIFERENTES VISÕES PARA OS MESMOS DADOS
Sandra de Albuquerque Siebra
Todos esses modelos, na verdade, são visões diferentes, com nível de

profundidade diferente para os mesmos dados. E é importante saber que, a
partir de um modelo, o modelo seguinte pode ser derivado. Para lhe dar uma
ideia de como as coisas acontecem, vamos explicar o processo descrito na figura
a seguir. O analista de banco de dados observa a realidade (e também conversar
com as pessoas que se fizerem necessárias) e, a partir do problema a ser resolvido
(aplicação a ser desenvolvida), ele organiza suas ideias e cria um minimundo (que
é um subconjunto da realidade contendo os dados necessários para a resolução do
problema sendo tratado). O minimundo tem dados que vão ajudar a descrever o
modelo conceitual (mais alto nível de abstração), o modelo lógico é especificado
a partir do modelo conceitual e é implementado pelo modelo físico (que é que
realmente é usado para criar o banco de dados (BD)).
77
Vamos descrever mais formalmente esse processo de criação do BD (que

equivale ao processo de projeto do banco de dados)? Bem, podemos dizer que esse
processo é composto por quatro fases conforme figura a seguir.
Na primeira fase, é feito o Levantamento e Análise dos Requisitos. Nessa

fase são realizadas entrevistas com os potenciais utilizadores do BD, são levantados
documentos importantes, pode-se olhar um sistema legado (já existente) para ver
como ele funciona, com o objetivo de compreender e documentar os requisitos
necessários para a construção do banco de dados (requisitos de BD).
A segunda fase é o projeto conceitual (ou modelagem) cujo objetivo é definir

um modelo de dados conceitual que inclua a descrição das entidades do BD, dos
atributos das entidades, dos relacionamentos entre entidades, além das possíveis
restrições, evitando, no entanto, detalhes de próprios da fase de implementação.
Essa fase dá origem ao esquema conceitual representado pelo modelo entidade-
relacionamento (que estudaremos em detalhes na próxima seção).
A terceira fase é o projeto lógico (ou implementação) que objetiva mapear o

modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem
ao esquema lógico representado pelo modelo relacional que já é um modelo que
depende do SGBD que será usado para implementar o banco de dados.
A quarta e última fase é o projeto físico que objetiva mapear o modelo

dedados relacional para o modelo de dados físico que tratará das estruturas em
memória e organização dos arquivos do BD (arquivos de índices). Essa fase dá
origem ao esquema físico que será o que realmente será implementado no BD.
78
FONTE: Disponível em: <http://www.fernandoans.site50.net/curso/curso06/UFPE-

BancoDeDados.pdf>. Acesso em: 26 fev. 2013.
79
RESUMO DO TÓPICO 1
• A modelagem de dados é o conjunto de conceitos que devem ser usados para

descrever a estrutura de uma base de dados.
• O objetivo da modelagem é criar uma abstração da realidade que seja capaz de

registrar os acontecimentos.
• A modelagem de dados utiliza notações em idioma natural.
• O Modelo Conceitual é uma descrição mais abstrata da realidade, onde os

fatos do mundo real são descritos de uma forma mais natural, bem como suas
propriedades e relacionamentos.
• O Modelo Conceitual deve ser sempre a primeira etapa de um projeto de um

Banco de Dados (DB).
• O Modelo Conceitual não está relacionado com o modelo de banco de dados,

forma de acesso ou armazenamento dos dados.
• O Modelo Lógico tem por objetivo representar as estruturas que irão armazenar
os dados dentro de um Banco de Dados. A partir deste momento é que são
definidas com maior propriedade as entidades e os seus atributos.
• O Modelo Lógico é iniciado somente a partir da estruturação do Modelo

Conceitual.
• O Modelo Físico é construído com base em um modelo lógico definido, com

intuito de ser aplicado sobre um SGDB.
• Na construção do Modelo Físico entram as questões relacionadas ao tipo e

tamanho do campo, relacionamento, indexação, restrições etc.
• O Modelo Físico descreve as estruturas físicas de armazenamento, tais como

tabelas, índices, gatilhos, funções, visões, nomenclaturas etc.
• O Modelo Conceitual, o Modelo Lógico e o Modelo Físico, na verdade, são

visões diferentes, com nível de profundidade diferente para os mesmos
dados. E é importante saber que, a partir de um modelo, o modelo seguinte
pode ser derivado.
80
AUTOATIVIDADE
1 O Modelo de Dados pode ser representado em diferentes níveis de abstração.

Quais são estes tipos de modelos?
2 O Modelo Conceitual é a primeira fase de um projeto de Banco de Dados.

Para que ele é utilizado e o que ele possibilita?
3 O que o Modelo Lógico tem por objetivo representar?
4 Qual é o tipo de modelo que descreve as estruturas físicas de armazenamento,

tais como tabelas, índices, gatilhos, funções, visões, nomenclaturas etc?
( ) Modelos conceituais.
( ) Modelos lógicos.
( ) Modelos físicos.
81
82
UNIDADE 2 TÓPICO 2
MODELO ENTIDADE-RELACIONAMENTO
1 INTRODUÇÃO
Caro(a) Acadêmico(a)! A seguir será possível conhecer o Modelo Entidade-
Relacionamento e sua estrutura conceitual e lógica geral de um banco de dados.
2 MODELO ENTIDADE-RELACIONAMENTO
O Modelo Entidade-Relacionamento (MER) é uma representação gráfica
dos objetos do mundo real, chamados de entidades, bem como a forma como
que eles estão relacionados, denominada relacionamento. Este modelo tem por
objetivo retratar uma porção da realidade para que seja implementada sobre uma
estrutura de Banco de Dados.
Aliado ao fato do Modelo Entidade-Relacionamento (MER) ser uma

ferramenta gráfica para representação de um banco de dados, ele ainda possui
um alto grau de interpretação, simplificando o processo de comunicação entre
usuários e analistas que estão à frente do projeto.
O MER descreve a estrutura conceitual e lógica geral de um banco de

dados, conforme ilustrado na figura a seguir.
83
FIGURA 32 - ENTIDADERELACIONAMENTO E ATRIBUTO
FONTE: Os autores
Segundo Machado (2004), o MER foi originalmente definido por Peter Chen
em 1976, baseado na teoria relacional criada em 1970 por Codd. Durante os anos
80, o MER sofreu algumas alterações com o objetivo de melhor atender às questões
relacionadas ao mundo real, tornando-se hoje o modelo de dados conceitual mais
conhecido e utilizado no mercado.
O processo de modelagem consiste em cinco aspectos importantes, segundo

Machado (2004), que são os seguintes:
• Observação: Composta por entrevistas, reuniões, questionários, análise de

documentos aliados ao conhecimento e experiência prévia da área de negócio.
• Entendimento dos conceitos: É considerado o núcleo do processo de modelagem.

Fase destinada a identificar, entender e assimilar o objeto observado.
• Representação dos objetos: É aplicado à técnica de modelagem de dados

Entidade-Relacionamento.
• Verificação de fidelidade e carências: Momento para identificar falhas e

anomalias, ponto de vista errado ou má aplicação da técnica.
• Validação: Fase de aprovação final do modelo junto ao usuário final e outros

profissionais da área técnica.

84
TÓPICO 2 | MODELO ENTIDADE-RELACIONAMENTO
Antes de iniciar com a elaboração de um Modelo Entidade Relacionamento,

é preciso compreender seus principais componentes:
2.1 ENTIDADE
A entidade é a representação dentro do MER de um objeto físico ou abstrato
do mundo real e relacionado ao negócio em análise. A entidade tem existência
própria, e dentro do MER é sobre ela que são guardadas algumas informações.
Machado (2004, p. 71), define entidade como sendo “... aquele objeto que
existe no mundo real com uma identificação distinta e com um significado próprio”.
Cada entidade deve possuir identificação própria e atributos. Dentro do

MER, as entidades são representadas por um retângulo. Exemplos: casa, carro,
matrícula, pessoa (física ou jurídica), viagem etc.
FIGURA 33 – ENTIDADES
FONTE: Os autores
UNI
Entidade X Instância de Entidade

“Para se referir a uma entidade particular fala-se em instância ou ocorrência de entidade. Uma
instância é um objeto de uma entidade com suas respectivas propriedades preenchidas com
valores, distinguindo-a assim de qualquer outra instância. Vamos exemplificar: a entidade
empregada, descrita há pouco, possui os atributos, nome, cargo que ocupa, idade e estado civil.
Uma instância dessa entidade poderia ser: “Maria, secretária, 31 anos, solteira”. Ou seja, a
instância é como se fosse um exemplo de empregado, com os atributos preenchidos com
valores. Entendeu?” (SIEBRA 2010, p. 13).
85
2.2 ATRIBUTOS
Os atributos são as características ou propriedades das entidades e guardam
informações específicas delas.
Segundo Machado (2009, p. 61), “Todo objeto, para ser uma entidade, possui
propriedades que são descritas por atributos. Esses atributos e seus conteúdos
(valores), juntos, descrevem as instâncias de uma entidade [...]”.
Exemplo: em uma entidade “Veículo”, teremos os atributos modelo, marca,

ano, tipo, combustível etc.
Existem basicamente dois tipos de atributos:
• Identificadores: Dão identificação única a cada ocorrência dentro da entidade.

Também são conhecidos por chaves. Por exemplo, em uma entidade “Pessoa”, o
CPF poderia ser um atributo identificador, pois cada pessoa tem um CPF único.
• Descritores: Descrevem características da entidade. Tomando o exemplo

anterior da entidade “Pessoa”, os atributos descritores poderiam ser nome,
telefone, data de nascimento etc.
Os atributos relacionados à entidade podem ser representados dentro da

mesma, ou na forma geométrica de círculos, também associados à entidade à qual
pertencem, conforme demonstram as imagens:
FIGURA 34 – ATRIBUTOS DA ENTIDADE
FONTE: Os autores
86
UNI
Para que a entidade seja relevante ao projeto MER, ela deverá ter pelo menos um
ou mais atributos.
2.3 RELACIONAMENTO
O relacionamento é a forma pela qual são feitas associações entre as
entidades existentes no mundo real. Os relacionamentos são relativamente mais
complexos que os outros componentes do MER, porém, eles são extremamente
importantes por se tratarem de uma questão essencial deste tipo de modelo.
Para Machado (2009, p. 73) “Entender efetivamente relacionamentos e ser

capaz de enxergar esses objetos como participantes do mundo real são fatores
primordiais para efetuar trabalhos de modelagem de dados”.
No mundo real, assim como no MER, é justamente o relacionamento que é

o responsável por dar sentidos aos objetos ou entidades.
Dentro do MER, os relacionamentos são representados por losangos,

e normalmente seus nomes são verbos que identificam uma ação entre as duas
entidades, conforme podemos ver na imagem a seguir.
FIGURA 35 – RELACIONAMENTO ENTRE ENTIDADES
FONTE: Os autores
Para melhor compreendermos os relacionamentos, é preciso entender os

elementos que o caracterizam:
• Semântica: A forma verbal utilizada para representar o conceito, lido da

esquerda para a direita, e de cima para baixo.
• Cardinalidade: É o número de ocorrências de uma entidade para outra. Podem

ser de três tipos:
87
• 1:1= um para um.

• 1:N = um para muitos.
• N:M = muitos para muitos.
• Condições para as entidades participarem em determinado relacionamento.
• Número de entidades envolvidas em um relacionamento, determinando se ele é

binário (entre duas entidades) ou n-ário (entre mais de duas entidades).
3 CONSTRUINDO UM MODELO ENTIDADE-RELACIONAMENTO
Inicialmente é necessário que tenhamos em vista um problema a ser

resolvido, e com base nesse problema devemos delimitar o minimundo ou escopo
a ser especificado.
Deste modo, durante a fase inicial, chamada análise de requisitos, costuma

ser elaborado o Modelo Descritivo, que corresponde a uma documentação
descritiva, que busca relatar através de linguagem natural à situação, o ambiente e
o problema a ser resolvido, delimitando assim o escopo do projeto.
O Modelo Descritivo irá fornecer as informações para a construção do

modelo MER.
Segue um exemplo prático e resumido de um Modelo Descritivo.
Uma universidade mantém um cadastro de seus acadêmicos. De cada um

são registrados: nome, endereço, telefone e data de nascimento.
As disciplinas, que são oferecidas à universidade, mantêm o código, nome,

carga horária e ementa.
O histórico de um aluno faz associação com as disciplinas que ele cursou

em cada etapa, contendo a nota e frequência e situação de aprovado ou reprovado.
A universidade também mantém um cadastro dos seus professores: são

registrados nome, endereço, telefone, e data de nascimento.
Cada uma das disciplinas nos cursos da universidade terá somente um

professor ministrando as aulas.
Este documento pode ser construído a partir de vários recursos que

o analista poderá fazer, como observações, reuniões, questionário, análise de
documentos, troca de experiências etc.
88
Depois da elaboração deste documento, é muito importante revisá-lo

juntamente com os usuários ou envolvidos no projeto, para validar as informações
relacionadas.
Mesmo durante a construção do modelo descrito, é possível identificar

nele quais serão as entidades, parte dos atributos das mesma e boa parte dos
relacionamentos. As entidades, conforme foi citado anteriormente, são abstrações
do mundo real dentro do MER.
Uma maneira prática de identificar mais facilmente as entidades é relacionar

todos os substantivos descritos no modelo descrito. Depois de relacionados, é
preciso verificar dentro desta lista de substantivos, quais realmente são entidades
e quais têm aderência a serem atributos destas entidades.
Os relacionamentos por sua vez podem ser identificados através dos

verbos utilizados no modelo descritivo. Obviamente, nem todos os verbos serão
utilizados (pois fazem parte dos recursos da linguagem para descrição do cenário).
Porém, os verbos que identificam ações entre duas entidades, é um sério candidato
a um relacionamento. Por conta disso, é essencial identificar todas as entidades do
modelo descritivo primeiro e para depois identificar os relacionamentos.
QUADRO 2 – TABELA DEMONSTRATIVA
OBJETO ENTIDADE ATRIBUTO RELACIONAMENTO

Universidade X
Aluno X
Nome X
Data de nascimento X
Cursar X
Disciplinas X
Notas X
Professor X
Ministrar X
.....
FONTE: Os autores
89
Edgar Frank Codd
Edgar Frank Codd (Dorset, 23 de agosto de 1923 – 18 de abril de 2003) foi

um matemático britânico. Ele desenvolveu o modelo de banco de dados relacional,
quando era pesquisador no laboratório da IBM em San José.
Em junho de 1970, ele publicou um artigo chamado “RelationalModelof

Data for LargeShared Data Banks” (“Modelo de dados relacional para
grandes bancos de dados compartilhados”) que foi publicado na Revista ACM
(“Association for ComputingMachinery”) Vol. 13, No. 6, pp. 377–387. Este artigo,
um desenvolvimento de um artigo interno da IBM publicado no ano anterior,
demonstrou os fundamentos da teoria dos bancos de dados relacionais, usando
tabelas (“linhas” e “colunas”) e operações matemáticas para recuperá-las destas
tabelas (UNION, SELECT, SUM etc…).
Devido ao interesse da IBM em preservar o faturamento trazido por produtos

pré-relacionais, tais como o IMS/DB, ela não quis, inicialmente, implementar as
ideias de Codd. Este então buscou grandes clientes da IBM para mostrar-lhes as
novas potencialidades de uma eventual implementação do modelo relacional.
Mesmo com a pressão dos clientes IBM, ela não incluiu Codd nos novos projetos
sendo implementados. Devido a isso, desgostoso pela rejeição de suas ideias, Codd
uniu-se a seu colega Christopher J. Date da IBM para deixar a mesma, fundando
uma consultoria chamada Codd & Date. Logo após adoeceu e teve de encerrar sua
carreira, vindo a falecer no começo do III milênio. Porém, Date continuou a obra de
Codd, tornando-se autor de vários livros importantes da área de BD.

90
RESUMO DO TÓPICO 2
• O Modelo Entidade-Relacionamento (MER) é uma representação gráfica dos

objetos do mundo real, chamados de entidades, bem como a forma como que
eles estão relacionados, chamada de relacionamento.
• O MER foi originalmente definido por Peter Chen em 1976, baseado na teoria
relacional criada em 1970 por Codd.
• A entidade é a representação dentro do MER de um objeto físico ou abstrato

do mundo real e relacionado ao negócio em análise. A entidade tem existência
própria, e dentro do MER é sobre ela que são guardadas algumas informações.
• Os atributos são as características ou propriedades das entidades, e guardam

informações específicas sobre as mesmas.
• Os atributos Identificadores identificam cada ocorrência dentro da entidade,

também conhecidos por chaves.
• O atributo descritor descreve as características da entidade.
• O relacionamento é a forma pela qual são feitas associações entre as entidades

existentes no mundo real.
91
AUTOATIVIDADE
1 A representação gráfica do Modelo Entidade-Relacionamento representa o

quê?
2 Por quem foi originalmente definido o Modelo Entidade-Relacionamento? E

com base em qual teoria?
3 O que uma entidade representa dentro do Modelo Entidade-Relacionamento?
4 Basicamente existem dois tipos de atributos, quais são eles e para que servem?
5 Qual é a função do relacionamento dentro do MER?
92
UNIDADE 2
TÓPICO 3
TIPOS DE RELACIONAMENTOS
1 INTRODUÇÃO
Conforme foi dito anteriormente, os relacionamentos definem como são
feitas as associações entre duas ou mais entidades. Eles existem por características
intrínsecas dos objetos, e através do seu mapeamento é possível demonstrar como
uma entidade se comporta em relação às demais.
Conforme Cougo (1997), cada objeto poderá se relacionar com diversos

outros objetos independentemente do seu tipo. Porém, o que define se uma
associação é válida ou não será o grau de fidelidade e completeza atingido durante
o processo de modelagem.
Nesta unidade estaremos vendo quais são os tipos de relacionamento, a

partir do grau de associação entre as entidades.
2 CONDICIONALIDADE DO RELACIONAMENTO
Os relacionamentos podem ser denotados de opcionalidade quanto à
participação de elementos em sua associação. O critério para condicionalidade é
verificar o número de ocorrência de instâncias dentro do relacionamento. Desta
forma, vão existir relacionamentos opcionais, que não exigem a obrigatoriedade
de acontecerem instâncias e os que indicarão obrigatoriedade da participação.
Para que o conceito fique mais claro, vamos observar alguns exemplos
práticos. Observe a figura:
FIGURA 36 – RELACIONAMENTO OBRIGATÓRIO
FONTE: Os autores
93
Nesta relação, observamos que a entidade PAI precisa possuir pelo

menos um FILHO para que seja caracterizado um relacionamento. Lendo o
relacionamento, temos:
• Um PAI deverá ter um ou mais FILHOS.

• Cada filho deverá ter um e somente um PAI.
O relacionamento entre duas ou mais entidades pode admitir opcionalidade,

que é quando não é obrigatória a ocorrência de uma instância. Para ficar mais claro
o entendimento, observe a figura a seguir:
FIGURA 37 – RELACIONAMENTO OPCIONAL
FONTE: Os autores
Neste relacionamento percebemos que não é obrigatório que a entidade

PESSOA venha a possuir CARRO. Então, lendo o relacionamento, temos:
• Uma PESSOA poderá ter nenhum, um ou vários CARROS.

• Um CARRO sempre pertencerá a uma única pessoa.
Ainda é possível determinar o número máximo de associações que as

entidades podem fazer em um relacionamento, de modo a atender características
de limitações sobre abstrações do mundo real. Por exemplo, vamos observar a
figura a seguir:
FIGURA 38 – LIMITE DE ASSOCIAÇÃO
FONTE: Os autores
É possível observar que existe uma limitação no número máximo de

associações entre as entidades, nos dois sentidos do relacionamento. Fazendo a
leitura, temos:
• Em um CAMPEONATO, terá que ter no mínimo1 e no máximo 24TIMES.
94
TÓPICO 3 | TIPOS DE RELACIONAMENTOS
Um TIME deverá participar em pelo menos um CAMPEONATO, podendo

participar de no máximo até dois CAMPEONATOS.
3 GRAU DO RELACIONAMENTO
O grau de relacionamento ou cardinalidade do relacionamento é
responsável por determinar o número de ocorrências entre duas entidades que
estão associadas por um relacionamento.
Com base no grau de relacionamento ou cardinalidade, temos a

possibilidade de classificar os relacionamentos entre as entidades com três tipos
de graus distintos, conforme estudaremos a seguir:
3.1 RELACIONAMENTO UM PARA UM

No relacionamento Um para Um (1:1), cada elemento de uma entidade se
relaciona a apenas um único elemento de outra entidade. Veja o exemplo na figura
a seguir, onde cada elemento da entidade “PESSOA” está associado apenas a um
único elemento de “PASSAPORTE”.
FIGURA 39 – RELACIONAMENTO UM PARA UM
FONTE: Os autores
Sempre que for feito o relacionamento entre duas entidades, devemos

fazer a leitura nos dois sentidos do negócio, isso poderá evitar o erro na criação
do grau do relacionamento entre as entidades. Para o exemplo apresentado, cada
uma das entidades tem características próprias. O seu relacionamento é de 1:1
em ambos os sentidos:
• Uma PESSOA poderá ter somente um PASSAPORTE.

• Cada PASSAPORTE pertencerá somente a uma única PESSOA.
95
3.2 GRAU UM PARA MUITOS

No relacionamento Um para Muitos (1:N), temos a associação de um
elemento da entidade associado a vários elementos de outra entidade. Veja o
exemplo a seguir, em que a entidade “PESSOA” associado a muitos elementos da
entidade “CARRO”, e somente um elemento de “CARRO” associado à entidade
“PESSOA”. Este grau de relacionamento na prática é o mais comum no mundo
real, observe a figura a seguir.
FIGURA 40 – RELACIONAMENTO UM PARA MUITOS
FONTE: Os autores
Observando a figura anterior, podemos ter a seguinte interpretação:
• Cada PESSOA pode ser proprietária de um ou vários CARROS.

• Cada CARRO por sua vez, pertence a uma única PESSOA.
Podemos observar que é importante fazermos sempre a leitura nos dois

sentidos do negócio, pois caso a leitura fosse feita apenas no sentido de “CARRO”
para “PESSOA”, o grau fica Um para Um, não chegaríamos a um grau de
relacionamento que reflete a realidade em questão.
3.3 GRAU MUITOS PARA MUITOS

O relacionamento Muitos para Muitos (M:N) ocorre quando a ocorrência
de uma entidade se relaciona com vários de outra e vice-versa. Para um melhor
entendimento, observe a figura a seguir.
FIGURA 41 - RELACIONAMENTO MUITOS PARA MUITOS
FONTE: Os autores
Conforme ilustra a figura anterior, podemos observar que uma ocorrência

da entidade “LIVRO” pode estar associa a várias ocorrências na entidade “AUTOR”,
e uma ocorrência da entidade “AUTOR” pode estar associa a várias ocorrências na
entidade “LIVRO”. Na prática, poderias ler:
96
TÓPICO 3 | TIPOS DE RELACIONAMENTOS
• Um LIVRO pode ser escrito por um ou vários AUTORES.

• Um AUTOR pode escrever um ou vários LIVROS.
Uma forma de identificar a cardinalidade Muitos para Muitos pode ser feita
através da leitura do grau, onde o resultado vai ser Um para Muitos por ambos os
lados da leitura.
Segundo Machado (2009, p. 84), “Esse tipo de relacionamento tem um

aspecto extremamente peculiar, ele possui atributos. Isso quer dizer que esse
relacionamento possui dados que são inerentes ao fato e não às entidades”.
4 AUTORRELACIONAMENTO
O autorrelacionamento, assim como o seu próprio nome sugere é
responsável por identificar o relacionamento de uma ocorrência de uma entidade
com ela mesma. Este tipo de relacionamento normalmente seve para representar
uma estrutura hierárquica. Por exemplo, vamos considerar uma entidade pessoa,
onde uma ocorrência (Pessoa) pode ter um pai, este pai pode ter pai e assim
sucessivamente. Para ilustrar observe a figura a seguir:
FIGURA 42 – AUTORRELACIONAMENTO
FONTE: Os autores
A figura que acabamos de observar represente uma entidade pessoa com

autorrelacionamento, onde podemos fazer a seguinte leitura, que uma pessoa tem
um único pai e um pai pode ter associado muitas pessoas (filhos). Neste caso,
o relacionamento é um para muitos, conforme vimos anteriormente, a única
diferença é que a entidade que será relacionada neste momento é a própria
entidade de origem.
Vejamos a seguir como fica a representação deste autorrelacionamento

dentro de uma única tabela, veja na figura a seguir.
97
FIGURA 43 – AUTORRELACIONAMENTO
ID-PESSOA NOME ID-PAI

1 Edson Neto Null
2 Roberto Carlos Null
3 Agatha Christie 1
4 Renato Russo 2
5 Anderson Silva 4
FONTE: Os autores
Com base na figura que acabamos de observar, podemos identificar que as

ocorrências que possuem o atributo ID-PAI com valor informado, representam a
ocorrência de um filho do pai em questão.
Para facilitar o entendimento, vamos fazer a leitura da entidade que

acabamos de analisar. Edson Neto é pai de Agatha Christie, Roberto Carlos é pai
de Renato Russo e avô de Anderson Silva.
98
RESUMO DO TÓPICO 3
• Os relacionamentos definem como são feitas as associações entre duas ou mais

entidades.
• Existem relacionamentos opcionais, que não exigem a obrigatoriedade de

acontecerem instância e os que indicarão obrigatoriedade da existência.
• O grau de relacionamento ou cardinalidade do relacionamento é responsável por

determinar o número de ocorrências entre duas entidades que estão associadas
por um relacionamento.
• No relacionamento Um para Um (1:1), cada elemento de uma entidade se

relaciona apenas com um único elemento de outra entidade.
• No relacionamento Um para Muitos (1:N), temos a associação de um elemento

da entidade associado a vários elementos de outra entidade.
• O relacionamento Muitos para Muitos (M:N) ocorre quando a ocorrência de

uma entidade se relaciona com vários de outra e vice-versa.
• O autorrelacionamento, como seu próprio nome sugere, é responsável por

identificar o relacionamento de uma ocorrência de uma entidade com ela mesma.
99
AUTOATIVIDADE
1 O que define o relacionamento?
2 O que representa o grau de relacionamento ou cardinalidade do

relacionamento?
3 Crie uma representação gráfica do relacionamento Um para Um (1:1) entre

duas entidades.
4 Crie uma representação gráfica do relacionamento Um para Um (1:N) entre

duas entidades.
5 Crie uma representação gráfica do relacionamento Um para Um (M:N) entre

duas entidades.
6 Crie uma representação gráfica de um autorrelacionamento.
100
UNIDADE 2
TÓPICO 4
MODELO RELACIONAL
1 INTRODUÇÃO
Neste tópico será apresentada uma breve introdução ao modelo de
dados que é utilizado nos sistemas de gerenciamento de banco de dados do tipo
relacional. O objetivo é dar condições para que você compreenda um projeto de
um DB relacional, e não uma abordagem completa.
2 BANCO DE DADOS RELACIONAL

O banco de dados relacional é composto por estruturas que permitem o
armazenamento e resgate de informações, de modo estruturado, respeitando uma
série de regras de funcionamento.
É preciso ter em mente que, o modelo lógico criado até aqui sofrerá uma
adaptação para que possua aderência sobre estas estruturas de armazenamento
que um banco de dados relacional dispõe.
Normalmente, um modelo lógico se transformará em um conjunto de

tabelas e relações. As tabelas em um banco de dados relacionais têm sua origem
no modelo entidade-relacionamento, onde elas eram chamadas de entidades. Os
atributos de cada entidade irão compor campos em uma tabela.
Os relacionamentos têm a mesma origem quando é criado o modelo

entidade-relacionamento além de criar as entidades e seus atributos, também é
criado o relacionamento entre elas.
3 TABELA
A tabela é um objeto de grande importância para um banco de dados,
pois é nela que serão armazenados os dados e futuramente disponibilizados aos
usuários do sistema.
Segundo Heuser (2001, p. 78), uma tabela é um conjunto não ordenado de

linhas (tupla), cada linha é composta por uma série de campos (atributo). Cada
campo é identificado por um nome de campo (nome do atributo), o conjunto de
campos homônimos de todas as linhas de uma tabela forma uma coluna. Observe
a figura a seguir:
101
FIGURA 44 – TABELA
CÓDIGO NOME DATA DE NASCIMENTO ENDEREÇO
120958 Edson Vargas Farias 15/02/1985 Rua Chapecó
120959 Cintia Ferreira 27/08/1984 Rua Maranhão
120960 Robson da Silva 28/01/1983 Rua Ingá
120961 Agnaldo Ribeiro 02/05/1979 Rua Rondônia
120962 Júlio Bastos 25/10/1984 Rua Enry
FONTE: Os autores
Ao fazermos uma comparação da tabela com o modelo lógico, percebemos

que as tabelas correspondem às entidades. É muito provável que cada entidade do
modelo lógico seja convertida em uma tabela ou mais tabelas.
Os campos da tabela (colunas) são facilmente relacionados aos atributos de

cada entidade.
As linhas por sua vez, representam cada instancia da entidade. Cada vez
que houver uma ocorrência de registro de uma entidade, respectivamente na tabela
será adicionada uma linha com os valores dos seus atributos.
4 CHAVE
As chaves, em relação ao modelo lógico, correspondem aos atributos
identificadores. Eles permitem dar uma identificação a cada ocorrência de instância
em uma tabela, e garantir que elas sejam únicas.
Porém, dentro do banco de dados propriamente dito, as chaves contam

ainda com outras funcionalidades, sendo que, além de ter a função de identificar
uma linha de uma tabela, elas ajudam a estabelecer o relacionamento entre as
tabela de um banco de dados relacional.
Basicamente existem três tipos de chaves em um banco de dados relacional:

chave primária, chave alternativa, chave estrangeira. Em seguida veremos mais
detalhes referentes aos tipos de chaves e suas respectivas características.
4.1 CHAVE PRIMÁRIA

A chave primária ou primary key (PK) é uma coluna ou conjunto de colunas
que identificam unicamente um registro dentro de uma tabela, ela pode ser simples
ou composta. Os campos que pertencem à chave primária são obrigatórios, não
admitindo valor vazio ou NULL.
102
TÓPICO 4 | MODELO RELACIONAL
Na abordagem relacional, segundo Heuser (2001), ao definir uma chave

primária não se está definindo nenhum caminho de acesso, está-se definindo
apenas uma restrição de integridade.
A chave primária simples é formada por apenas um campo da tabela. Neste

caso podemos dizer que o valor da coluna chave não se repete.
FIGURA 45 – TABELA COM CHAVE PRIMÁRIA SIMPLES

PESSOA
CPF_PESSOA NOME
88381248175 André Ricardo
87702347368 Murilo Santos
66986242255 Magda Silva
FONTE: Os autores
A chave primária composta é formada por mais de um campo da tabela,

quando temos esta situação, o valor do conjunto de colunas envolvidas na chave
não se repete. Isso significa que os valores de parte das colunas podem se repetir.
FIGURA 46 – TABELA COM CHAVE PRIMÁRIA COMPOSTA

PESSOA_MATRÍCULA
CPF_PESSOA CD_MATRÍCULA SITUACAO
88381248175 223344 Ativo
87702347368 556644 Ativo
66986242255 552244 Formado
FONTE: Os autores
4.2 CHAVE ESTRANGEIRA

A chave estrangeira ou foreign key (FK), é uma coluna ou conjunto de
colunas que se referem necessariamente a uma chave primária de outra tabela ou
dela mesma no caso de recursividade, estabelecendo um relacionamento entre as
tabelas. Este relacionamento garante a integridade dos dados relacionados, pois
apenas serão permitidos valores que atendam ao relacionamento.
A existência de uma chave estrangeira, segundo Heuser (2001), impõe

restrições que devem ser garantidas ao executar operações de alterações do DB.
103
• Na inclusão de uma linha: Deve garantir que o valor da chave estrangeira

apareça na coluna da chave primária referenciada.
• Na alteração do valor da chave estrangeira: Deve garantir que o novo valor da

chave estrangeira apareça na coluna da chave primária referenciada.
• Na exclusão de uma linha da tabela que contém a chave primária referenciada

pela chave estrangeira: Deve garantir que na coluna chave estrangeira não
apareça o valor da chave primária que está sendo excluída.
• Na alteração do valor da chave primária referenciada pela chave estrangeira:

Deve garantir que na coluna chave estrangeira não apareça o antigo valor da
chave primária que está sendo alterada.
Observe a figura a seguir, onde a tabela FUNCIONÁRIO possui uma

coluna ID_DEPARTAMENTO que é chave primária da tabela DEPARTAMENTO.
FIGURA 47 – TABELA COM CHAVE ESTRANGEIRA
FUNCIONÁRIO
ID_PESSOA PK NOME_FUNCIONÁRIO ID_DEPARTAMENTO FK
123041 Maria da Silva 1022

123042 João Neto 1023
123043 Roberto Augusto 1023
123044 Jonas Manuel Ribeiro 1021
123045 Augusto Franco 1023
DEPARTAMENTO
ID_DEPARTAMENTO PK NOME_DEPARTAMENTO
1021 Financeiro
1022 Recursos Humanos
1023 Operacional
1024 Direção
FONTE: Os autores
As duas tabelas anteriores representam informações distintas: a primeira

traz uma relação de funcionários de uma empresa fictícia, e a outra relaciona os
departamentos desta empresa.
104
Existe um relacionamento entre as tabelas, onde dentro da tabela de

funcionário é feito referência ao departamento a que o funcionário pertence,
a partir do número de sua identificação. Por exemplo, a funcionária “Maria da
Silva”, cujo código é 123041, possui no campo ID_DEPARTAMENTO o valor 1022,
que corresponde ao departamento “Financeiro” da tabela departamento.
Logo, este campo ID_DEPARTAMENTO na tabela funcionários é uma

chave estrangeira (foreing key) que faz referência à chave primária da tabela
DEPARTAMENTOS.
4.3 CHAVE ALTERNATIVA

Em alguns casos mais de uma coluna ou grupo de colunas da tabela
servem para identificar unicamente um registro. Neste caso, uma das chaves
é criada como chave primária e a outra, como alternativa (também conhecida
como Chave única “UK”).
FIGURA 48 – TABELA COM CHAVE ALTERNATIVA

VEÍCULO
CD_RENAVAM (PK) PLACA (UK) NOME
998833229 MTU8956 KOMBI
334432455 UTI0669 FUSCA
442634523 MIK9887 GOL
FONTE: Os autores
No exemplo visto anteriormente, tanto a chave primária CD_RENAVAM

quanto a alternativa PLACA servem para identificar um veículo. Neste caso foi
optado por definir o campo CD_RENAVAM como sendo primária, pois esta
informação existe antes mesmo de um veículo possuir placa, é importante lembrar
que a chave primária não aceita valor NULL, já a chave alternativa sim.
UNI
Em alguns SGDB, é possível criar uma chave estrangeira referenciando uma chave
alternativa.
105
As 12 Regras de Codd
Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que determinam

o quanto um banco de dados é relacional. Em algumas vezes, as regras se tornam
uma barreira e nem todos os SGBDs relacionais fornecem suporte a elas. De qualquer
forma, a título de conhecimento, vamos apresentá-las a seguir. Lembramos que
nem todas as regras serão completamente compreendidas nesse momento, mas o
serão até o final da disciplina.
Regra 1: Regra das informações em tabelas: As informações a serem armazenadas

no banco de dados devem ser apresentadas como relações (tabelas formadas por
linhas e colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por
meio de valores de campos comuns (chaves estrangeiras).
Regra 2: Regra de acesso garantido: Todo e qualquer valor atômico em um BD

relacional possui a garantia de ser logicamente acessado pela combinação do nome
da tabela, do valor da chave primária e do nome do campo/coluna que deseja
acessar. Isso porque, com o nome da tabela, se localiza a tabela desejada. Com o
valor da chave primária a tupla desejada dentro da tabela é localizada. E com o
nome do campo/coluna se acessa a parte desejada da tupla.
Regra 3: Regra de tratamento sistemático de valores nulos: Valores nulos devem ser
suportados de forma sistemática e independente do tipo de dado para representar
informações inexistentes e informações inaplicáveis. Deve-se sempre lembrar que
valores nulos devem ter um tratamento diferente de “valores em branco”.
Regra 4: Regra do catálogo relacional ativo: Toda a estrutura do banco de

dados (domínios, campos, tabelas, regras de integridade, índices etc.) deve estar
disponível em tabelas (também referenciadas como catálogo). Sua manipulação
é possível por meio de linguagens específicas (por exemplo, SQL). Essas tabelas
são, geralmente, manipuladas pelo próprio sistema no momento em que o usuário
efetua alterações na estrutura do banco de dados (por exemplo, a inclusão de um
novo atributo em uma tabela).
Regra 5: Regras de atualização de alto nível: Essa regra diz que o usuário deve
ter capacidade de manipular as informações do banco de dados em grupos
de registros, ou seja, ser capaz de inserir, alterar e excluir vários registros ao
mesmo tempo.
Regra 6: Regra de sublinguagem de dados abrangente: Pelo menos uma linguagem,

com sintaxe bem definida, deve ser suportada, para que o usuário possa manipular
a estrutura do banco de dados (como criação e alteração de tabelas), assim como
extrair, inserir, atualizar ou excluir dados, definir restrições de integridade e de
acesso e controle de transações (commit e rollback, por exemplo). Deve ser possível
ainda a manipulação dos dados por meio de programas aplicativos.
106
Regra 7: Regra de independência física: Quando for necessária alguma modificação

na forma como os dados estão armazenados fisicamente, nenhuma alteração deve ser
necessária nas aplicações que fazem uso do banco de dados (isolamento), assim como
devem permanecer inalterados os mecanismos de consulta e manipulação de dados
utilizados pelos usuários finais.
Regra 8: Regra de independência lógica: Qualquer alteração efetuada na estrutura

do banco de dados como inclusão ou exclusão de campos de uma tabela ou
alteração no relacionamento entre tabelas não deve afetar o aplicativo utilizado ou
ter um baixo impacto sobre o mesmo. Da mesma forma, o aplicativo somente deve
manipular visões dessas tabelas.
Regra 9: Regra de atualização de visões: Uma vez que as visões dos dados de uma
ou mais tabelas são, teoricamente, suscetíveis a atualizações, então um aplicativo
que faz uso desses dados deve ser capaz de efetuar alterações, exclusões e inclusões
neles. Essas atualizações, no entanto, devem ser repassadas automaticamente às
tabelas originais. Ou seja, a atualização em uma visão deve refletir na atualização
das tabelas representadas por essa visão.
Regra 10: Regra de independência de integridade: As várias formas de integridade

de banco de dados (integridade de entidade, integridade referencial e restrições
de integridade complementares) precisam ser estabelecidas dentro do catálogo
do sistema ou dicionário de dados e serem totalmente independentes da lógica
dos aplicativos. Assim, os aplicativos não devem ser afetados quando ocorrerem
mudanças nas regras de restrições de integridade.
Regra 11: Regra de independência de distribuição: Alguns SGBDs, notadamente

os que seguem o padrão SQL, podem ser distribuídos em diversas plataformas/
equipamentos que se encontrem interligados em rede. Essa capacidade de
distribuição não pode afetar a funcionalidade do sistema e dos aplicativos que fazem
uso do banco de dados. Em resumo, as aplicações não são logicamente afetadas
quando ocorrem mudanças geográficas dos dados (caso dos BDs distribuídos).
Regra 12: Regra não subversiva: O sistema deve ser capaz de impedir qualquer
usuário ou programador de transgredir os mecanismos de segurança, regras de
integridade do banco de dados e restrições, utilizando algum recurso de linguagem
de baixo nível que eventualmente possam ser oferecidos pelo próprio sistema.

107
RESUMO DO TÓPICO 4
• O banco de dados relacional é composto por estruturas que permitem o

armazenamento e resgate de informações, de modo estruturado, respeitando
uma série de regras de funcionamento.
• As tabelas em um banco de dados relacionais têm sua origem no modelo

entidade-relacionamento, onde elas eram chamadas de entidades. Os atributos
de cada entidade irão compor campos em uma tabela.
• Os relacionamentos têm a mesma origem quando é criado o modelo entidade-

relacionamento além de criar as entidades e seus atributos, também é criado o
relacionamento entre elas.
• A tabela é um objeto de grande importância para um banco de dados, pois é nela

que serão armazenados os dados e futuramente disponibilizados aos usuários
do sistema.
• A chave permite dar uma identificação a cada ocorrência de instância em uma

tabela, e garantir que elas sejam únicas.
• Basicamente existem três tipos de chaves em um banco de dados relacional:

chave primária, chave alternativa, chave estrangeira.
• A chave primária ou primary key (PK) é uma coluna ou conjunto de colunas que
identificam unicamente um registro dentro de uma tabela, ela pode ser simples
ou composta. Os campos que pertencem à chave primária são obrigatórios, não
admitindo valor vazio ou NULL.
• A chave estrangeira ou foreign key (FK) é uma coluna ou conjunto de colunas

que se referem necessariamente a uma chave primária de outra tabela ou
dela mesma no caso de recursividade, estabelecendo um relacionamento
entre as tabelas.
• A chave alternativa é criada quando mais de uma coluna ou grupo de coluna da

tabela servem para identificar unicamente um registro.
108
AUTOATIVIDADE
1 Sabemos que uma tabela é um dos objetos mais importantes de um banco

relacional. De que ela é composta?
2 A chave primária é formada por um ou vários campos de uma tabela, qual

é o seu objetivo e o que ela garante?
3 A correta criação e aplicação da chave estrangeira é primordial para um

bom funcionamento de um banco de dados relacional. Descreva o que você
entendeu sobre a composição e funcionamento da chave estrangeira.
4 Quando se aplica a criação de uma chave alternativa?
109
110
UNIDADE 2
TÓPICO 5
NORMALIZAÇÃO DE DADOS
1 INTRODUÇÃO
Para que a construção de um projeto de banco de dados tenha sucesso é
preciso que proporcione a integridade e consistência dos dados que irá armazenar.
Para isso foi criado uma metodologia chamada normalização, que tem por objetivo
possibilitar o desenvolvimento de um modelo de armazenamento consistente,
além de um acesso eficiente e íntegro aos dados.
O processo de normalização é composto por um conjunto de regras

aplicadas sobre as tabelas (entidades) e seus relacionamentos, buscando evitar
falhas no projeto de banco de dados, como redundâncias, dissociação de assuntos
e informações relevantes ou pertinentes dentro de um domínio etc. Estas e outras
falhas desta natureza são conhecidas por anomalias.
Segundo Machado (2009), com o processo de normalização, pode-se

gradativamente substituir um conjunto de entidade e relacionamento por outro,
que se apresenta “purificado” em relação às anomalias de atualização (inclusão,
alteração e exclusão).
Estas anomalias se não tratadas podem causar certos problemas, tais

como grupos repetitivos de dados, dependências parciais em relação a uma
chave concatenada, redundância de dados desnecessária, perdas acidentais de
informações, dificuldade na representação de fatos da realidade observada e
dependências transitivas entre atributos.
O que é normalização?
Em 1970, o Professor Dr. Edgar F. Codd, analista da IBM, desenvolveu

uma série de estudos sobre como tratar os dados, a fim de eliminar as anomalias
de atualização e as suas consequências desagradáveis para as organizações.
Deste esforço surgiram duas inovações que revolucionaram a maneira de
tratar os dados. A primeira destas inovações foi o Modelo Relacional, no qual
se basearam os Sistemas Gerenciadores de Base de Dados (SGBD) da metade
da década de 1980 e início de 1990. A segunda inovação foi o processo de
Normalização, sendo que ambas estão intimamente relacionadas.
111
O processo de normalização como foi proposto por Codd sujeita um

esquema de relação a uma série de testes para certificar-se de que ele satisfaça
certa forma normal. Na verdade, a normalização de dados pode ser vista como
o processo de análise de determinados esquemas de relações com base em suas
dependências funcionais e chaves primárias para alcançar as propriedades
desejáveis de: (1) minimização de redundâncias e (2) minimização de
anomalias de inserção, exclusão e alteração. Nesse processo, os esquemas de
relações insatisfatórios, que não alcançam certas condições (no caso, os testes
de forma normal) são decompostos em esquemas de relações menores que
passam nos testes e, consequentemente, possuem as propriedades desejadas.
Em outras palavras, quando uma tabela não atende ao critério de uma forma
normal, sua estrutura é redesenhada através da projeção (jogar para fora)
de alguns atributos, levando a construção de novas tabelas contendo algum
atributo que possa refazer o conteúdo da tabela original através da junção
(reunir) das tabelas resultantes.
O processo de normalização tem as seguintes funções:
• Analisar tabelas e organizá-las de forma que a sua estrutura seja simples,

relacional e estável, para que o gerenciamento delas possa ser também
simples, eficiente e seguro.
• Evitar a perda e a repetição da informação.
• Conseguir uma forma de representação adequada para o que se deseja
armazenar.
• Oferecer mecanismos para analisar o projeto do BD (identificação de erros e
possibilidades de melhorias) e oferecer métodos para corrigir problemas que,
por ventura, sejam encontrados.
E, com essas funções, pretende-se alcançar os seguintes objetivos:
• Garantir a integridade dos dados, evitando que informações sem sentido

sejam inseridas no banco de dados.
• Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo
a redundância e permitindo a evolução do banco de dados com o mínimo de
efeito colateral.
Inicialmente Codd propôs três formas normais que ele chamou de

primeira (1FN), segunda (2FN) e terceira (3FN) forma normal. Uma definição
mais forte da 3FN (chamada forma normal BOYCE-CODD - FNBC ou BCNF)
foi depois proposta por Boyce e Codd. Todas essas formas normais são baseadas
nas dependências funcionais entre os atributos de uma relação. Posteriormente,
uma quarta (4FN) e quinta (5FN) forma normal foram propostas.
112
TÓPICO 5 | NORMALIZAÇÃO DE DADOS
As formas normais são aplicadas para evitar redundância de dados,

inconsistências e anomalias de atualização. Isso porque, redundância de dados
é um fato gerador de inconsistências. Já as anomalias de atualização criam
dificuldades operacionais para manutenção do banco de dados, quebrando a
confiabilidade no dado ou ferindo a integridade dos dados.
Uma forma normal engloba todas as outras anteriores, ou seja, a hierarquia

entre as formas normais indica que uma tabela só pode estar numa forma mais
avançada se, além de atender as condições necessárias, já estiver na forma
normal imediatamente anterior.
Por exemplo, para que uma tabela esteja na 2FN, ela obrigatoriamente
deve estar na 1FN e assim por diante.
Na prática, o mais comum é normalizar relações apenas até a 3FN. Isso

porque as três primeiras formas normais (1FN, 2FN e 3FN) atendem à maioria
dos casos denormalização e já são suficientes para organizar as tabelas de um BD.
FONTE: Siebra (2010)
2 ANOMALIAS DE ATUALIZAÇÃO
A entidade que não for devidamente normalizada com base nas formas
normais brevemente vista anteriormente, corre o risco de sofrerem com algumas
anomalias, é justamente esta a situação que estaremos vendo a seguir.
Segundo Siebra (2010), a mistura de atributos de várias entidades pode

gerar problemas conhecidos momo anomalias de atualização, tais anomalias
podem causar uma série de ocorrências tais como:
• Grupos repetitivos de dados.

• Dependências parciais de chave.
• Redundâncias desnecessárias de dados.
• Perdas acidentais de informações.
• Dificuldade de representação de fatos da realidade (modelos).
• Dependências transitivas entre atributos.
• As anomalias de atualização podem ser de três tipos:
• Anomalias de inserção – Causam a repetição desnecessária de dados

(redundância).
• Anomalias de alteração – Levam as inconsistências e aumentam o esforço
para a atualização dos dados.
• Anomalias de exclusão – Causam a perda de informações associadas a um
dado registro.
113
Para exemplificar, Siebra (2010) usa uma suposição onde é criada uma
relação de empregados de uma empresa.
FIGURA 49 – RELAÇÃO EMPREGADO
FONTE: Siebra (2010)
Ao criarmos a relação desta forma, é possível observar as seguintes

anomalias de atualização:
• Anomalia de Inserção: Ocorre quando vamos inserir uma nova ocorrência

(Registro) na relação de empregado, será necessário incluir também os valores
para os atributos de departamento em que o empregado trabalha, ou deixar null
os campos referentes ao departamento. Além disso, deve-se tomar cuidado ao
inserir dados de um departamento que já exista na tabela, pois a possibilidade
de registrar um mesmo código de departamento com um nome diferente, desta
forma criando uma inconsistência na base. Outra questão é a dificuldade para
inserir um novo departamento que ainda não tivesse empregados registrados,
neste caso a única maneira é colocar valores null nos atributos referente aos
empregados. Essa alternativa gera um problema, pois o CPF do empregado faz
parte da chave primária da nossa relação de empregados, onde cada registro
deve representar um empregado e não um departamento.
• Anomalia de Alteração: No caso de necessidade de alterar os atributos de um

departamento qualquer, esse valor deve ser alterado em todas as ocorrências
referente aos empregados que trabalhassem no departamento em questão. Caso
contrário, novamente será gerada uma inconsistência na nossa.
• Anomalia de Remoção: No caso de remoção de uma ocorrência de empregado, se

esta for a última ocorrência de um departamento, a informação do departamento
será perdida.
Para evitar tais anomalias, podemos utilizar as técnicas de normalização

(formas normais) criadas por Codd.
114
3 APLICAÇÃO DAS FORMAS NORMALIZAÇÃO

O objetivo da disciplina não é se aprofundar em cada uma das formas
normais, porém vamos ver como é o processo de aplicação conforme proposto por
Machado (2009).
• Entidade ou documento não normalizado, apresentando grupos repetitivos e

certas anomalias de atualização.
→ Aplicação da 1FN
→ Decompor a entidade em uma ou mais entidades, sem grupos repetitivos.

→ Destacar um ou mais atributos como chave primária da(s) nova(s)
entidades(s), e ele será concatenado com a chave primária da entidade
original.
→ Estabelecer o relacionamento e a cardinalidade entre a(s) entidade(s)
gerada(s) e a entidade geradora.
→ Verificar a questão da variação temporal de certos atributos e criar
relacionamento 1:N entre a entidade original e a entidade criada por
questões de histórico.
• Entidades na 1FN
→ Para entidades que contenham chaves primárias concatenadas, destacar

os atributos que tenham dependência parcial em relação à chave primária
concatenada.
→ Criar uma entidade que conterá esses atributos, e que terá como chave
primária o(s) atributo(s) do(s) qual (quais) se tenha dependência parcial.
→ Serão criadas tantas entidades quantos forem os atributos da chave
primária concatenada, que gerem dependência parcial.
→ Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s)
entidades(s) gerada(s) e a entidade geradora.
→ Verificar se existem atributos que sejam dependentes transitivos de outros

que não pertencem à chave primária, sendo ela concatenada ou não, bem
como atributos que sejam dependentes de cálculo realizado a partir de
outros atributos.
115
→ Destacar os atributos com dependência transitiva, gerando uma nova

entidade com esse atributo e cuja chave primária é o atributo que originou
a dependência.
→ Eliminar os atributos obtidos através de cálculos realizados a partir de
outros atributos.
→ Aplicação da FNBC
→ Só aplicável em entidades que possuam chaves primárias e candidatas

concatenadas.
→ Verificar se alguma chave candidata concatenada é um determinante, e em
caso afirmativo, criar uma entidade com os que dependam funcionalmente
desse determinante e cuja chave primária é o próprio determinante.
• Entidades na FNBC
→ Aplicação do 4FN
→ Para se normalizar em 4FN, a entidade (obrigatoriamente) deve estar na

3FN.
→ Verificar se a entidade possui atributos que não sejam participantes da
chave primária e que sejam multivalorados e independentes em relação a
um mesmo valor da chave primária.
→ Retirar esses atributos não chaves e multivalorados, criando entidades
individuais para cada um deles, herdando a chave primária da entidade
desmembrada.
• Entidade na 4FN
→ Aplicada em elementos que estejam na 4FN.

→ A ocorrência desse tipo de forma normal está vinculada aos relacionamentos
múltiplos (ternários etc.) ou entidades que possuam chave primária
concatenada com três ou mais atributos.
→ Verificar se é possível reconstruir o conteúdo do elemento original a partir
de elementos decompostos desta.
→ Se não for possível, o elemento observado não está na 5FN, caso contrário,
os elementos decompostos representam um elemento na 5FN.
116
• Entidades na Forma Normal Final
O processo de normalização leva ao refinamento das entidades, retirando

delas grande parte das redundâncias e inconsistências. Naturalmente, para que
haja uma associação entre entidades é preciso que ocorram redundâncias mínimas
de atributos que evidenciam esses relacionamentos. Sem as redundâncias não
haveria relacionamento entre entidades.
4 FERRAMENTAS PARA MODELAGEM DE DADOS

Para desenhar o DER e até dar apoio a fases posteriores do projeto de banco
de dados, como a conversão do MER. Para o modelo relacional existem diversas
ferramentas de modelagem de dados.
Na sequência será feito uma breve apresentação de três ferramentas de

modelagem de dados (DBDesigner, CA Erwin, PowerDesigner).
4.1 DBDESIGNER
O DBDesigner é uma ferramenta gratuita para projeto de banco de
dados que integra a modelagem, projeto, implementação e manutenção em um
mesmo ambiente.
Ela é desenvolvida pela empresa Fabulous Force Database Tools, atualmente,

encontra-se na versão 4 e está disponível para download em: <http://fabforce.net/
dbdesigner4/>.
117
FIGURA 50 - INTERFACE DB DESIGNER 4
FONTE: Disponível em: <http://fabforce.net/dbdesigner4/screenshot_image.

php?screenshot=dbd4_ss_simplemodel.png>. Acesso em: 26 fev. 2013.
Este programa é útil para, ao invés de criarmos uma base de dados

através de códigos, criarmos uma base de dados visualmente, com a definição
de tabelas, tipos de dados e relações entre tabelas. A partir do resultado final do
desenho de uma base de dados, termos acesso ao código que podemos utilizar
para a criação da nossa base de dados. O DBDesigner é direcionado para o
desenvolvimento de banco de dados com o SGBD MySQL, mas também oferece
suporte para o Ms-SQL e o Oracle.
4.2 ERWIN
Esta é uma das ferramentas mais utilizada no mercado, conforme informado
no site do fabricante (http://erwin.com/). Através desta ferramenta, o desenvolvedor
de um sistema de informação pode especificar os dados envolvidos, as suas
relações e os requisitos de análise.
118
A ferramenta permite desde a criação e manutenção das bases de dados, até

o uso de mecanismos de sincronização de dados necessários. Além disso, oferece
recursos para realizar o processo inverso (Engenharia reversa4). O ERwin gera
modelos para todos os principais bancos de dados atuais e pode ser integrado para
ajudar no gerenciamento dos mesmos (para atualização das bases de dados).
A notação utilizada pelo ERwin não descende da notação original de Peter

Chen, ela implementa diagramas parecidos com os utilizados na Engenharia de
Software. A interface da ferramenta pode ser visualizada a seguir.
FIGURA 51 - ERWIN
FONTE: Os autores
4.3 POWERDESIGNER
É considerada juntamente com o ERwin, uma das ferramentas mais
utilizadas e completas do mercado. Gera modelo conceitual, converte para modelo
lógico (automaticamente, sem intervenção do usuário) e trabalha com todos os
principais bancos de dados disponíveis empregando inclusive, técnicas de
engenharia reversa e de integridade referencial.
119
Apesar de ser uma ferramenta paga, ela tem uma versão demo disponível
para avaliação por 15 dias no site: <http://www.sybase.com.br/products/
modelingdevelopment/powerdesignerou>, <http://www.sybase.com>. A interface
da ferramenta pode ser visualizada a seguir:
FIGURA 52 - POWERDESIGNER
FONTE: Disponível em: <http://pt.softpicks.net/software/Produtividade/Gerenciamento-de-

Projeto/Sybase-PowerDesigner_pt-220884.htm>. Acesso em: 26 fev. 2013.
120
RESUMO DO TÓPICO 5
• O processo de normalização é composto por um conjunto de regras aplicadas

sobre as tabelas (entidades) e seus relacionamentos, buscando evitar falhas
no projeto de banco de dados, como redundâncias, dissociação de assuntos e
informações relevantes ou pertinentes dentro de um domínio etc.
• O processo de normalização pode-se, gradativamente, substituir um conjunto de

entidade e relacionamento por outro, que se apresenta “purificado” em relação
às anomalias de atualização (inclusão, alteração e exclusão).
• A entidade que não for devidamente normalizada com base nas formas normais
corre o risco de sofrer algumas anomalias.
121
AUTOATIVIDADE
1 O que você entendeu sobre o processo de normalização de dados?
122
UNIDADE 3
SQL
Esta unidade tem por objetivos:
• fixar de forma prática os conteúdos apresentados nas unidades anteriores;
• introduzir a linguagem SQL para criação de bancos de dados;
• apresentar perspectivas sobre o uso desta tecnologia.
PLANO DE ESTUDOS
Esta unidade está dividida em três tópicos e em cada um deles, você en-
contrará atividades que proporcionarão a compreensão dos conteúdos
apresentados.
TÓPICO 1 – INTRODUÇÃO À LINGUAGEM SQL
TÓPICO 2 – MANUTENÇÃO DOS DADOS
TÓPICO 3 – OUTRAS ESTRUTURAS DE DADOS
123
124
UNIDADE 3
TÓPICO 1
INTRODUÇÃO À LINGUAGEM SQL

“Transportai um punhado de terra todos os dias e fareis uma montanha”.
(Confúcio)
1 INTRODUÇÃO
Já estamos na Unidade 3, a última unidade deste Caderno de
Estudos. Muita coisa aconteceu até aqui fazendo com que adquiríssemos
mais conhecimento. Apenas para fins de revisão e clareza, vamos relembrar
rapidamente o que foi visto.
Na Unidade 1 tivemos uma introdução do que é e como funciona o mundo

dos bancos de dados. Conceitos e teorias que vão desde as primeiras formas de
armazenamento até o estado atual da tecnologia, com SGBDs modernos e eficazes.
Vimos que existem vários paradigmas de gerenciamento e adotamos para este
livro o banco de dados relacional. No final da unidade mostramos os principais
bancos relacionais existentes no mercado.
Ao estudarmos a Unidade 2, evoluímos nossa forma de pensar sobre

o modelo de dados relacional. Juntamente com o conhecimento adquirido na
unidade anterior, conseguimos compreender como nascem as entidades (tabelas)
e como elas podem se relacionar. Em resumo, pode-se dizer que tivemos uma boa
base para projetar um banco de dados.
Agora estamos na Unidade 3. Chegou a hora de criarmos um banco de

verdade. Vamos ver na prática como “nascem” as tabelas e como elas são populadas
com dados. Como complemento, vamos explorar algumas estruturas que fazem
parte do cotidiano desta área, como procedures, functions entre outras.
Será utilizado nos exemplos o banco de dados ORACLE, um dos principais

bancos da atualidade. Bons estudos!
125
UNIDADE 3 | SQL
2 O QUE É SQL
A Structured Query Language ou simplesmente SQL é uma linguagem
utilizada para construirmos e manipularmos bancos de dados relacionais. É através
dela que modelos de entidade-relacionamento viram realidade. Ela fornece uma
série de comandos para criarmos estruturas e posteriormente recuperarmos dados.
Seguindo o caminho do aprendizado, vamos procurar entender como a SQL

surgiu. Silberschatz, Korth e Sudarshan (2006) fazem um relato sobre a sua criação.
A IBM desenvolveu a versão original da SQL, originalmente chamada

Sequel, como parte do projeto R no início da década de 1970. A linguagem
Sequel evoluiu desde então, e seu nome mudou para SQL (Structured
Query Language). Muitos produtos agora aceitam a linguagem SQL. A
SQL se estabeleceu claramente como a linguagem padrão de banco de
dados relacional.
Em 1986, o American National Standards Institute (ANSI) e a International
Organization for Standardization (ISO) publicaram um padrão SQL,
chamado SQL-86. Em 1989, o ANSI publicou um padrão estendido
para a linguagem: a SQL-89. A próxima versão do padrão foi a
SQL-92, seguida da SQL-1999; a versão mais recente é a SQL-2003.
(SILBERSCHATZ, KORTH E SUDARSHAN, 2006, p. 3).
Como pôde ser visto na citação acima, vários padrões da linguagem SQL
foram criados desde que ela nasceu. Isso fez com que fabricantes de bancos de
dados relacionais escolhessem qual padrão gostariam de seguir. Sendo assim,
a sintaxe, comandos e outras particularidades podem variar de um banco para
o outro. Isso vem a ser um desafio para programadores que desejam fazer seus
sistemas rodarem em bancos de fabricantes diferentes. Inclusive, alguns bancos de
dados tem o seu próprio padrão de SQL que normalmente é derivado dos padrões
definidos pela ANSI e ISO.
Pode parecer complicado em um primeiro momento assimilar algumas

das informações passadas acima. No momento não se preocupe com isso, porque
posteriormente vários assuntos ficarão mais claros. Por hora, entenda que SQL
é a linguagem utilizada para trabalhar com bancos de dados relacionais e que
cada banco pode seguir um padrão SQL específico. O que torna esse aspecto
um pouco menos custoso é o fato que ambos os padrões derivam de um padrão
definido por um órgão competente.
3 MODELO DE DADOS DESTA UNIDADE

Para iniciar a parte prática deste Caderno de Estudos é essencial que seja
definido um modelo de dados ou modelo entidade-relacionamento (MER). Na
Unidade 2, você aprendeu regras, formas normais e uma série de boas práticas
para modelar um banco de dados com qualidade. Não iremos revisar esses tópicos,
apenas vamos tomar como base o modelo de dados definido aqui.
126
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
O nosso minimundo ou universo do discurso é um consultório médico,

onde atuam quatro médicos. Cada um tem as suas especialidades e basicamente
atendem a pacientes que agendam horário para as consultas. Levando em
consideração que o foco desta unidade é o aprendizado de SQL, o modelo de
dados será extremamente simples, tratando apenas o agendamento de consultas
e deixando de lado outras questões, como por exemplo, pagamento de consultas,
fluxo de caixa etc.
Segue figura com o modelo de dados que será utilizado nesta unidade.
FIGURA 53 – MODELO ENTIDADE-RELACIONAMENTO QUE SERÁ UTILIZADO NESTE CADERNO

DE ESTUDOS
FONTE: Os autores
4 CRIANDO O BANCO DE DADOS

Enfim chegou o grande momento. Finalmente vamos criar nosso banco
de dados seguindo o modelo que foi definido anteriormente. Vale a pena
lembrar que os comandos apresentados neste Caderno de Estudos foram
testados em uma base de dados Oracle 11g Express Edition. Esta versão é gratuita
e pode ser baixada no endereço <http://www.oracle.com/technology/products/
database/xe>. É necessário apenas que se faça um cadastro no site e em seguida
o download será liberado.
É interessante que você efetue o download e instale o banco de dados Oracle

na sua máquina. Isso facilitará muito a sua aprendizagem, podendo testar todos
os comandos apresentados. Não é nosso objetivo tratar questões relacionadas à
instalação, porém o processo é simples, necessitando apenas que se deixem as opções
default selecionadas e avance até o fim. Durante a instalação será solicitado para
definir uma senha para o usuário system. Defina-a e memorize-a para uso posterior.
127
UNIDADE 3 | SQL
ATENCAO
Por se tratar de um sistema robusto, a instalação do Oracle pode deixar o seu

computador com uma performance um pouco inferior. Caso tenha alguma dúvida procure a
ajuda de um profissional.
4.1 CONEXÃO AO BANCO DE DADOS

Para realizarmos qualquer trabalho com um banco de dados é preciso fazer
uma conexão ao mesmo. Para tal, é necessário um programa cliente que irá tratar
todos os comandos recebidos, enviar ao banco e obter sua resposta. A própria
Oracle fornece o SQL Plus que é instalado na máquina no momento da instalação
do banco de dados.
Primeiramente, abra o SQL Plus. A localização deste programa pode variar

de um sistema operacional para o outro. Procure pelo item “Oracle Database 11g
Express Edition” -> “Executar Linha de Comandos SQL”. A figura a seguir mostra
a localização do atalho utilizando o sistema operacional Windows XP.
FIGURA 54 – LOCALIZAÇÃO DO ATALHO DO SQL PLUS NO WINDOWS XP
FONTE: Os autores
128
Dando sequência no procedimento, digite o comando conn. Será solicitado

que se informe um usuário e uma senha. O usuário poderá ser o system e a senha
será a que você definiu durante a instalação.
A figura a seguir ilustra esse processo.
FIGURA 55 – CONEXÃO COM O BANCO DE DADOS ORACLE
FONTE: Os autores
O Oracle e a maioria dos bancos de dados fornece uma forma de organização

para usuários e uma definição do que eles podem acessar. Não é nosso objetivo
explorar a mesma, por isso vamos continuar utilizando o usuário system.
4.2 CRIAÇÃO DE TABELAS

Para criarmos as tabelas, é necessário primeiramente entender sobre os
tipos de dados que os campos dela podem ter. O quadro alista os principais tipos
de dados de um banco Oracle.
129
UNIDADE 3 | SQL
QUADRO 3 – TIPOS DE DADOS PARA CAMPOS DE TABELAS DO ORACLE
Tipo Descrição
Cadeia de caracteres de tamanho fixo n. O default é 1 e
char (n)
o máximo, 255.
Cadeia de caracteres de tamanho variável com o
máximo de n e pode ter o valor de até 4.000. Para que
varchar2(n) duas variáveis desse tipo sejam consideradas iguais,
elas devem possuir, além do mesmo conteúdo, o mesmo
tamanho.
Cadeia de caracteres de tamanho variável com o
long máximo de 2 gigabytes. Só pode existir um campo desse
tipo por tabela.
Equivalente ao varchar2 e long, respectivamente, mas
utilizado para armazenar dados binários que não são
interpretados pelo Oracle, como, por exemplo, sons,
imagens etc. Para agilizar o acesso, costuma-se quebrar
raw e long raw uma tabela em duas quando houver um campo desse
tipo: a primeira teria os campos originais e a segunda, a
chave e o campo “grande”. As duas seriam relacionadas
em 1:1.
Limite para o tipo raw: 2.000 bytes.
Valores numéricos em que p indica a precisão (máximo
de 38) e indica a escala (número de casas decimais) que
number(p, e)
varia de -84 a + 127. Por exemplo, number(5,2) especifica
um número na faixa entre -999,99 e +999,99.
Armazena data e hora, incluindo século, ano, mês, dia,
date
hora, minuto e segundo. Ocupam 7 bytes.
FONTE: Morelli (2000 p. 12)
A seguir, vamos criar as tabelas do nosso banco de dados de acordo com

o modelo proposto para esta unidade. Inicialmente criaremos apenas as tabelas e
sua chave primária, deixando os relacionamentos para um segundo momento.
O comando para criação de tabelas é o create table. Sua sintaxe encontra-

se a seguir. O padrão adotado neste Caderno de Estudos define que os itens dentro
de colchetes ([ ]) são opcionais e sua utilização depende da necessidade do usuário.
create table nome_da_tabela (

coluna1 tipo_de_dado,
...
ColunaN tipo_de_dado,
primary key (nome_coluna))
Vamos criar a tabela paciente seguindo a sintaxe apresentada acima.
130
create table paciente (

nr_sequencia number(6),
nm_paciente varchar2(100),
cpf_paciente varchar2(11),
fone_paciente varchar2(15),
primary key(nr_sequencia))

Uma forma de trabalhar com o SQL Plus para inserir comandos é através
da utilização de um editor de textos. Para utilizar um, digite o comando ed que o
bloco de notas ou o seu editor padrão se abrirá. Caso seja apresentada a mensagem
“Nada para salvar”, digite qualquer comando com um ponto e vírgula no final.
Depois de receber outro erro, digite novamente ed. A figura a seguir demonstra o
funcionamento do processo.
FIGURA 56 – UTILIZANDO SEU EDITOR DE TEXTOS PARA COMANDOS SQL
FONTE: Os autores
Agora substitua o conteúdo do editor de textos pelo comando create da

tabela paciente, deixando apenas a barra (“/”) no final do arquivo. Salve o conteúdo
e feche o editor. Tecle barra (“/”) + enter que o comando será executado. Veja na
figura a seguir, o resultado desses passos.
131
UNIDADE 3 | SQL
FIGURA 57 – COMANDO DO EDITOR SENDO EXECUTADO
FONTE: Os autores
A partir deste momento, a tabela paciente existe no nosso banco de dados.
E
IMPORTANT
Poderíamos ter trabalhado diretamente na tela do SQL Plus sem utilizar o Notepad.
É só digitar todo o comando SQL e no final colocar um ponto e vírgula (“;”).
Para verificar se tudo ocorreu conforme o planejado, um comando muito

útil é o desc. Com ele podemos ver a estrutura dos objetos do banco. Sua sintaxe é:
desc nome_do_objeto;
Vamos testá-lo para verificar a estrutura da tabela paciente.
desc paciente;
O resultado pode ser visto na figura a seguir.
132
FIGURA 58 – RESULTADO DO COMANDO DESC
FONTE: Os autores
Note que um detalhamento dos campos da tabela é apresentado conforme

definimos com o comando create table. Por enquanto não se preocupe com a
coluna Nulo?. Ela será vista mais à frente.
Já que aprendemos a criar uma tabela, vamos ver agora o que temos que
fazer para excluí-la. O comando é extremamente simples e muito poderoso. É o
drop table.
drop table nome_da_tabela;
Veja na figura a seguir o que acontece quando executamos um drop

table da tabela paciente e em seguida tentamos visualizar a sua estrutura com
um comando desc.
FIGURA 59 – UTILIZANDO O COMANDO DROP TABLE
FONTE: Os autores
133
UNIDADE 3 | SQL
Como pôde ser visto, a tabela paciente não existe mais na nossa base de
dados.
ATENCAO
O comando drop table elimina completamente a tabela e os dados existentes

nela. Depois da execução não é mais possível desfazer a ação que ele executou.
Já que excluímos a tabela paciente vamos recriá-la só que desta vez sem
o uso do editor de textos. Digite o comando create table da tabela paciente e para
executá-lo coloque um ponto e vírgula (“;”) no final. Em seguida, procure ver a
estrutura da tabela criada com o comando desc. A figura seguinte ilustra esse
processo.
FIGURA 60 – CREATE TABLE DA TABELA PACIENTE SEM EDITOR DE TEXTO
FONTE: Os autores
Perfeito, agora temos a tabela paciente novamente criada! A seguir temos

todos os comandos para criação das outras tabelas que compõem o nosso modelo
de dados.
134
E
IMPORTANT
A partir deste momento vamos evitar o uso de imagens para demonstrar o

funcionamento dos scripts. Assuma que tudo o que deve ser executado será através do SQL
Plus aplicando o que foi ensinado sobre ele até o momento. Fique atento para o seguinte
detalhe: Se você estiver utilizando um editor de texto, não coloque o ponto e vírgula no final
do comando.
create table consulta (

nr_seq_paciente number(6),
nr_seq_medico number(4),
dt_hora_inicio date,
dt_hora_fim date,
ds_observacao varchar2(1000),
primary key (nr_sequencia);
create table medico (

nm_medico varchar2(100),
crm_medico varchar2(10),
cpf_medico varchar2(11),
fone_medico varchar2(15),
primary key (nr_sequencia));
Se você deseja adicionar algum campo em alguma das tabelas segue um

comando que cria o campo dt_nascimento na tabela paciente.
alter table paciente add (dt_nascimento date);
Para apagar a mesma coluna, use o seguinte comando.
alter table paciente drop column dt_nascimento;
Depois de efetuar alterações nas estruturas das tabelas, verifique se elas

foram aplicadas conforme o esperado através da utilização do comando desc.
135
UNIDADE 3 | SQL
5 RESTRIÇÕES
Conforme você estudou na Unidade 2, o modelo relacional exige que sejam
criadas várias integridades para garantir total confiança nos dados armazenados.
Essa criação de integridade ou restrição é suportada pelo padrão SQL e por vários
bancos de dados. Um sinônimo para restrição é a palavra constraint que inclusive
chega a ser utilizada no SQL para criação de algumas restrições.
Morelli (2000, p. 12) nos dá uma definição para restrição ou o termo

popularmente conhecido como constraint.
Um constraint ou restrição apresenta um mecanismo capaz de

implementar controles que garantam a consistência dos dados
(integridade de dados e referencial). Pode ser definido tanto em nível de
coluna (afeta apenas um campo) como em nível de tabela (afeta todos
os campos).
De uma forma resumida, podemos dizer que restrição é tudo o que faz
alguma validação ou checagem em um conjunto de dados.
5.1 CHAVE PRIMÁRIA E RESTRIÇÃO NOT NULL

Quando criamos as tabelas do nosso modelo de dados, a única restrição
que programamos foi a de chave primária (primary key). Sinalizamos ao Oracle os
campos que fazem parte da chave primária e ele entende que os valores desses
campos não podem se repetir (pois identificam os registros da tabela), e também
não podem ser nulos. Por isso, se você usar o comando desc nas tabelas verá que
algumas linhas na coluna Nulo? aparecem com o valor NOT NULL.
Quando colocamos uma coluna para fazer parte da chave primária,

automaticamente ela deverá ser NOT NULL, ou seja, não é permitido que ela não
tenha valor. Veja a seguir o resultado do comando desc na tabela consulta.
Nome Nulo? Tipo

-------------------------------- -------- ----------
NR_SEQUENCIA NOT NULL NUMBER(10)
NR_SEQ_PACIENTE NUMBER(6)
NR_SEQ_MEDICO NUMBER(4)
DT_HORA_INICIO DATE
DT_HORA_FIM DATE
DS_OBSERVACAO VARCHAR2(1000)

O campo nr_sequencia faz parte da chave primária, por isso,
automaticamente quando criamos a restrição primary key (nr_sequencia),
o Oracle colocou ele como NOT NULL.
136
Na tabela consulta só existe um campo que pode ser NULL: o DS_

OBSERVACAO. Todos os demais deverão ser NOT NULL. Para incluirmos essa
restrição precisamos utilizar o comando alter table. Inicialmente vamos
aplicar a restrição apenas à coluna NR_SEQ_PACIENTE.
alter table consulta modify (nr_seq_paciente NOT NULL);
Novamente vamos ver a estrutura da tabela consulta com o comando desc:
Nome Nulo? Tipo

------------------------------- -------- -------------
NR_SEQ_PACIENTE NOT NULL NUMBER(6)
NR_SEQ_MEDICO NUMBER(4)
DT_HORA_INICIO DATE
DT_HORA_FIM DATE
DS_OBSERVACAO VARCHAR2(1000)
Agora o campo NR_SEQ_PACIENTE não aceita mais valores nulos. Vale

a pena lembrar que também é possível incluir esta restrição ao criar a tabela, no
comando create table. Segue o exemplo para a tabela consulta.
create table consulta (

nr_sequencia number(10) NOT NULL,
nr_seq_paciente number(6) NOT NULL,
nr_seq_medico number(4) NOT NULL,
dt_hora_inicio date NOT NULL,
dt_hora_fim date NOT NULL,
ds_observacao varchar2(1000),
primary key (nr_sequencia);
Como nossas tabelas já estão criadas, vamos utilizar o alter table para
programar as restrições NOT NULL. Seguem os comandos para todas as tabelas.
alter table consulta modify (

nr_seq_medico NOT NULL,
dt_hora_inicio NOT NULL,
dt_hora_fim NOT NULL);
alter table paciente modify (

nm_paciente NOT NULL,
cpf_paciente NOT NULL);
alter table medico modify (

nm_medico NOT NULL,
crm_medico NOT NULL,
cpf_medico NOT NULL);
137
UNIDADE 3 | SQL
Agora temos todas as restrições NOT NULL programadas na nossa base.

Lembrando que para fazer um campo NOT NULL aceitar valores nulos é simples.
Basta fazer o alter table com uma restrição NULL conforme exemplo que
segue:
alter table medico modify (

nm_medico NULL);
ATENCAO
Se você colocou o campo nm_medico da tabela médico para aceitar valores

nulos (conforme descrito no último exemplo), modifique novamente para ele não aceitar nulos.
5.2 CHAVE ESTRANGEIRA

A próxima restrição que vamos abordar é a de integridade referencial
também conhecida como chave estrangeira ou foreign key. Você já estudou sobre
esse tipo de restrição na Unidade 2, por isso vamos para a parte prática através do
comando alter table. Veja no exemplo a seguir a criação da chave estrangeira
entre as tabelas consulta e paciente.
alter table consulta add constraint consulta_paciente_fk

foreign key (nr_seq_paciente)
references paciente(nr_sequencia);
O comando acima criou uma restrição de chave estrangeira com o nome

consulta_paciente_fk que tem como regra que o campo nr_seq_paciente da tabela
consulta só pode conter valores que estão no campo da chave primária da tabela
paciente (nr_sequencia).
Para excluir uma integridade referencial também usamos o comando

alter table só que desta vez com o drop constraint. Segue um exemplo:
alter table consulta drop constraint consulta_paciente_

fk;
A seguir está o script para a criação de todas as chaves estrangeiras

do nosso banco de dados (inclusive a constraint consulta_paciente_fk que
acabamos de apagar).
138
alter table consulta add constraint consulta_paciente_fk

foreign key (nr_seq_paciente)
references paciente(nr_sequencia)
alter table consulta add constraint

consulta_medico_fk
foreign key (nr_seq_medico)
references medico(nr_sequencia)
5.3 CHAVE ÚNICA

Em seções anteriores vimos como funciona a criação de uma chave primária.
Percebemos também que os campos que a compõe não podem ter repetição de
valores e também não podem ser nulos. A chave única ou Unique Key tem os
mesmos princípios, porém com uma única diferença: os campos que a compõem
podem ser nulos.
Para resumir, os campos que fazem parte de uma Unique Key não podem
ter valores repetidos no seu conteúdo, mas aceitam valores nulos. São úteis em
vários casos. No nosso banco de dados seria interessante uma restrição desse
tipo na tabela paciente no campo cpf_paciente, para evitar que um paciente seja
cadastrado mais de uma vez. Segue o comando da criação desta integridade.
alter table paciente add constraint

paciente_cpf_uk
unique (cpf_paciente);
Se caso desejássemos excluir esta integridade, poderíamos fazer com o

seguinte comando:
alter table paciente

drop constraint paciente_cpf_uk;
Precisamos criar mais duas integridades deste tipo na tabela médico. Uma
no campo cpf_medico para impedir a duplicação do cadastro de um médico e
outra no crm_medico para impedir que existam dois CRMs iguais cadastrados
nesta tabela. Abaixo segue os comandos com todas as Unique Keys da nossa base
de dados (inclusive da tabela paciente, que foi excluída no exemplo acima).
alter table paciente add constraint

paciente_cpf_uk
unique (cpf_paciente);
alter table medico add constraint

medico_cpf_uk
unique (cpf_medico);
139
UNIDADE 3 | SQL
alter table medico add constraint

medico_crm_uk
unique (crm_medico);
5.4 CHECAGEM DE DADOS

É muito comum, quando se trabalha com banco de dados, querer que
determinadas tabelas tenham os seus valores consistidos com alguma regra fixa.
Para isso podemos usar uma constraint de checagem dos dados. Rob e Coronel
(2011, p. 254) definem o que vem a ser uma restrição de checagem de dados ou
simplesmente restrição check.
CHECK é utilizado para validar dados quando é inserido um valor de

atributo. A restrição check não é exatamente o que o seu nome sugere:
ela verifica se uma condição específica ocorre. Alguns exemplos desta
restrição são: o valor mínimo de pedidos deve ser 10 ou a data deve ser
posterior a 15 de abril de 2008.
Como foi citado acima, uma restrição check serve para validar dados de
acordo com determinadas situações. No nosso banco de dados ela se encaixaria
na tabela consulta. Temos os campos dt_hora_inicio e dt_hora_fim que registram
o início da consulta e quando ela terminou. Jamais uma consulta pode terminar
antes de começar, ou seja, o campo dt_hora_inicio deve ser sempre menor que o
campo dt_hora_fim. Para isso vamos criar uma constraint check. O comando está
logo abaixo.
alter table consulta add constraint

dt_hora_consulta_ck
check (dt_hora_inicio < dt_hora_fim)
O comando acima fará com que a tabela consulta nunca tenha consultas
terminando antes mesmo de começar. Se você desejar excluir uma check constraint
é só seguir os mesmos princípios de exclusão de uma unique key.
UNI
Caro(a) acadêmico(a)! A Leitura Complementar a seguir traz uma visão clara de

questões relacionadas à origem do SQL e sua evolução até o momento.
A seguir serão apresentados alguns fatores que devem ser analisados quando trabalhamos
com esse tipo de tecnologia.
140
O QUE É SQL
O que é e para que serve o SQL?
As aplicações em rede são cada dia mais numerosas e versáteis. Em

muitos casos, o esquema básico de operação é uma série de scripts que dirigem o
comportamento de uma base de dados.
Devido à diversidade de linguagens e de base de dados existentes, a maneira

de comunicar entre umas e outras seria realmente complicado de providenciar, a
não ser pela existência de padrões que nos permite realizar as operações básicas
de uma forma universal.
É justamente disso que se trata o Structured Query Language que não é

mais do que uma linguagem padrão de comunicação com base de dados. Falamos,
portanto, de uma linguagem normalizada que nos permite trabalhar com qualquer
tipo de linguagem (ASP ou PHP) em combinação com qualquer tipo de base de
dados (MS Access, SQL Server, MySQL...).
O fato de ser padrão não quer dizer que seja idêntico para cada base de
dados. Na prática, determinadas bases de dados implementam funções específicas
que não têm necessariamente que funcionar em outras.
À parte desta universalidade, o SQL possui outras duas características

muito apreciadas. Por uma parte, apresenta potência e versatilidade notáveis que
contrasta, por outra, com sua acessibilidade de aprendizagem.
História do SQL
A história do SQL começa em 1970 com a publicação por E. F. Codd, no

ACM Journal, de um artigo intitulado “A Relational Model of Data for Large
Shared Data Banks”.
O modelo proposto por Codd é hoje considerado a base de trabalho para

qualquer Sistema de Gestão de Base de Dados Relacional (SGBDR).
A primeira implementação da linguagem SEQUEL foi realizada pela

IBM e tinha por objetivo a implementação do modelo de Codd. A evolução desta
linguagem veio a dar origem ao SQL.
A primeira implementação comercial de SQL foi realizada pela Relational

Software, Inc., hoje conhecida por Oracle Corporation.
141
UNIDADE 3 | SQL
Nos dias de hoje, a linguagem SQL é considerada um standard dos Sistemas

de Gestão de Base de Dados Relacionais (SGBDR); por isso, todos os fabricantes a
integram nos seu produtos.
A linguagem SQL pertence à 4ª Geração das Linguagens de Programação,

da qual é a única sobrevivente. Não é, no entanto, uma evolução das linguagens de
3ª Geração (Pascal, BASIC, C, COBOL, FORTRAN), já que estas têm características
bem diferentes:
- Existência de Variáveis, vectores etc.

- Existência de instruções condicionais (if, switch, case etc.).
- Existência de ciclos (for, while, do... while, repeat... until).
- Possibilidade de escrita de funções e procedimentos.
Nenhuma destas características existe no SQL, havendo maior ligação entre

a 3ª e 5ª gerações de linguagens de programação do que com a 4ª.
A linguagem SQL destina-se, por isso e pela sua simplicidade, não só a

informáticos, como também a gestores, utilizadores, administradores de bases de
dados etc..
No entanto, a sua principal diferença em relação às linguagens de 3ª

geração é a ausência nestas de um objetivo pré-definido, coisa que no SQL está
bem determinado: proporcionar a interface entre o SGBDR e o utilizador, através
da manipulação de dados.
A linguagem SQL implementa os conceitos definidos no modelo relacional,

reduzindo assim as incompatibilidades entre os sistemas e evitando a opção por
arquiteturas proprietárias que implicam maiores custos de desenvolvimento e
maior esforço financeiro e humano por parte dos intervenientes.
Com a linguagem SQL é possível:

Criar, alterar e remover todas as componentes de uma base de dados, como
tabelas, índices, views etc.
Inserir, alterar e apagar dados.
Interrogar a base de dados.
Controlar o acesso dos utilizadores à base de dados, e às operações a que
cada um deles tem acesso.
Obter a garantia da consistência e integridade dos dados.
A linguagem SQL é composta por vários conjuntos de comandos:
DDL (Data Definition Language): comandos para definir ou modificar a

composição das tabelas, apagar tabelas, criar índices, definir “views”, especificar
direitos de acesso a tabelas e views.
142
DML (interactive Data Manipulation Language): inclui uma linguagem de

consulta baseada em álgebra relacional e em cálculo relacional sobre registos; inclui
também comandos para inserir, apagar e modificar registos na base de dados.
As novas versões de SQL incluem capacidades de verificação de integridade

dos dados, bem como comandos para especificação do princípio e fim de transações;
algumas implementações permitem o impedimento explícito de acesso aos dados,
para controle de acesso concorrencial.
FONTE: Disponível em: <http://www.xtibia.com/forum/topic/42593-o-que-e-sql-historia-do-sql/ >.

Acesso em: 3 fev. 2013.
143
RESUMO DO TÓPICO 1
• SQL é uma linguagem para acesso e manipulação de dados em um banco

relacional.
• O modelo de dados ou modelagem entidade relacionamento vira realidade

através da aplicação de comandos SQL.
• A criação de tabelas pode ser feita de várias formas, com algumas variações de
comandos que têm o mesmo resultado.
• Restrições em tabelas servem para dar maior confiabilidade nos dados

armazenados e procuram mantê-los íntegros.
144
AUTOATIVIDADE
1 De acordo com o conteúdo estudado, defina o que é SQL.
2 Escreva o comando que pode ser utilizado para apagar uma constraint de
integridade referencial (chave estrangeira), cujo nome é aluno_matricula_fk?
3 Qual é o comando que pode ser utilizado para apagar uma tabela?
4 Com base no que foi aprendido até o momento, escreva um comando

que crie um campo na tabela paciente para armazenar o documento de
identidade do mesmo.
5 Crie um comando para excluir o campo que você criou na pergunta anterior.
145
146
UNIDADE 3
TÓPICO 2
MANUTENÇÃO DOS DADOS

“A persistência é o menor caminho do êxito.”
(Charles Chaplin).
1 INTRODUÇÃO
Dando sequência à parte prática do nosso Caderno de Estudos, vamos
relembrar o que fizemos até aqui. Basicamente, este caderno está dividido em três
momentos, ou melhor, três unidades com focos bem distintos.
Na primeira unidade tivemos vários conceitos relacionados a entender o

que é um banco de dados e qual é a sua utilidade hoje no mundo da tecnologia da
informação. Podemos perceber que houve um grande processo evolutivo desde
as primeiras formas de armazenamento. Já na segunda unidade, começamos a
entender como se projeta um banco de dados, quais são as melhores práticas e
boas recomendações sobre como alcançar os objetivos pretendidos.
Agora que chegamos a terceira e última unidade, estamos mergulhando

neste mundo de forma prática, conhecendo com dinamismo tudo o que nos foi
apresentado nas unidades anteriores. No primeiro tópico aprendemos a criar
tabelas em suas devidas restrições e checagens. Agora, vamos colocar dados
nessas tabelas e verificar se a estrutura que criamos realmente atende o que foi
proposto inicialmente.
Bons estudos!
2 INSERINDO, SELECIONANDO, ATUALIZANDO E

DELETANDO DADOS
2.1 VALIDANDO AS RESTRIÇÕES DA TABELA

Agora que já temos todas as tabelas criadas, vamos preenchê-las com
dados e verificar se tudo o que programamos está funcionando. Essa verificação
consiste basicamente em validar a chave primária, a obrigatoriedade de dados em
campos NOT NULL, as integridades referenciais (chaves estrangeiras), as chaves
de unicidade e checagem de dados (campos dt_hora_inicio e dt_hora_fim da tabela
consulta). Aqui vamos aprender comandos relacionados à inserção, atualização e
deleção dos dados nas tabelas.
147
UNIDADE 3 | SQL
Para isso ser possível, vamos começar utilizando um comando para inserir
dados. É o comando insert, que tem sua sintaxe básica apresentada a seguir.
insert into nome_tabela (campo1, campo2, campoN)

values (valor_campo1, valor_campo2, valor_campo3);
É um comando extremamente simples. Segue um código fonte da inserção

de um paciente na tabela paciente.
insert into paciente (nr_sequencia, nm_paciente, cpf_

paciente, fone_paciente)
values (1, 'Marcio Junior Silva', '16834865101',
'(47)89899999');
Perceba que todos os campos do tipo varchar2 estão entre aspas simples.
Isso é essencial para o correto funcionamento do comando. Para ver o que foi
inserido no banco de dados, usamos o comando select.
select * from paciente;
O resultado é:
NR_SEQUENCIA NM_PACIENTE CPF_PACIENTE FONE_PACIENTE

------------ ---------- ------------ ------------
1 MARCIO JUNIOR 16834865101 (47)89899999
SILVA
DICAS
Para que você tenha um visão mais organizada dos dados selecionados via SQL
Plus utilize os seguintes comandos:
set linesize 1000;
set pagesize 2000;
alter session set NLS_DATE_FORMAT = 'DD/MM/YYYY HH24:mi:ss'
Vamos agora validar algumas restrições que criamos na tabela paciente. A

primeira é a de chave primária, ou seja, jamais poderemos conseguir incluir outro
paciente com o campo nr_sequencia igual a 1. Vamos tentar?
148
TÓPICO 2 | MANUTENÇÃO DOS DADOS

values (1, 'Alberto Moreira', '66440726820',
'(51)99578156');
ERRO na linha 1: ORA-00001: restrição exclusiva (SYSTEM.SYS_C007104)

violada
Nossa restrição de chave primária está funcionando. O Oracle retornou em

erro ORA-00001 informando que já existe outro registro com esse código.
Nossa próxima validação se refere a campos que não aceitam valores nulos.
Vamos relembrar quais são os campos através de um comando desc na tabela paciente.
Nome Nulo? Tipo

--------------------------- -------- ----------------
NM_PACIENTE NOT NULL VARCHAR2(100)
CPF_PACIENTE NOT NULL VARCHAR2(11)
FONE_PACIENTE VARCHAR2(15)
O único campo que deve aceitar valores nulos é o fone paciente. Vamos
tentar fazer um insert deixando o cfp_paciente com valor null.

values (2, 'Juliano Rosa', null, '(47)89899999');
ERRO na linha 2: ORA-01400: não é possível inserir NULL em

("SYSTEM"."PACIENTE"."CPF_PACIENTE")
Como pode ser visto acima, o Oracle não permite que o campo seja nulo,
confirmando que a validação programada funciona corretamente.
Para ser possível realizar teste de validação da integridade referencial,

precisamos antes inserir algum registro na tabela médico para posteriormente
tentarmos inserir consultas. Note que, segundo nosso modelo de dados, a tabela
consulta é filha das tabelas paciente e médico, por isso se faz necessário inserir
dados de pacientes e médicos antes de alguma consulta.
Segue o comando para a inserção de um médico na tabela medico.
149
UNIDADE 3 | SQL
insert into medico (nr_sequencia, nm_medico, crm_medico,

cpf_medico, fone_medico)
values (1, 'Jader Fonseca', '1002365', '94269268018',
'(99) 12438080');
Se você desejar, pode fazer o comando select * from medico para

visualizar os dados do médico cadastrado.
Finalmente, vamos inserir um registro na tabela consulta. Será uma

consulta com o médico Dr. Jader Fonseca (nr_sequencia = 1) com data de início
em 04/02/2013 15:00 e término as 04/02/2013 16:00. O paciente será o Marcio Junior
Silva (nr_sequencia = 1). Segue o comando
insert into consulta (nr_sequencia, nr_seq_paciente,

nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (1, 1, 1, to_date('04/02/2013 15:00:00', 'DD/

MM/YYYY HH24:MI:SS'), to_date('04/02/2013 16:00:00', 'DD/MM/
YYYY HH24:MI:SS'));
Note que usamos uma função to_date. Futuramente entraremos em mais

detalhes sobre ela (seção 2.3 Conversão de dados). Apenas entenda que ela faz a
conversão do tipo string para data. Veja o resultado do comando select * from
consulta.
NR_SEQUENCIA NR_SEQ_PACIENTE NR_SEQ_MEDICO DT_HORA_

INICIO DT_HORA_FIM DS_OBSERVACAO
1 1 1
04/02/2013 15:00:00 04/02/2013 16:00:00
A consulta foi inserida com sucesso. Agora vamos tentar cadastrar outra
consulta para um paciente de código 10 (nr_sequencia da tabela paciente). Se nossa
restrição de integridade estiver correta, esse comando não deverá funcionar. Veja
o resultado.

values (1, 10, 1, to_date('04/02/2013 15:00:00', 'DD/
YYYY HH24:MI:SS'))
ERRO na linha 1:
ORA-00001: restrição exclusiva (SYSTEM.SYS_C007105) violada
Como era esperado, o comando não funcionou. Não é possível incluir uma
consulta para um paciente que não está cadastrado na tabela paciente.
150
Já que voltamos a falar desta tabela, vamos verificar o que acontece quando
tentamos incluir novamente um CPF já cadastrado. Você lembra que criamos uma
restrição de unicidade (chave única ou unique key) para o campo cpf_paciente?
Criamos sim! Segue o comando com a inserção de outro paciente com o CPF do
Márcio Júnior Silva (que já está cadastrado na tabela).

values (5, 'Mauricio Alves', '16834865101',
'(99)89899999')
ERRO na linha 1: ORA-00001: restrição exclusiva (SYSTEM.PACIENTE_

CPF_UK) violada
Novamente nossa restrição funcionou. Não é possível inserir o mesmo CPF

mais de uma vez na tabela paciente.
DICAS
Temos o mesmo tipo de restrição de unicidade na tabela médico para os

campos de CPF e CRM. Com os conhecimentos obtidos até aqui você pode testar se tudo está
funcionado. Sinta-se à vontade para realizar os devidos testes de funcionamento.
Para finalizar nossos testes de restrição de integridade, falta testar a check

constraint ou checagem de dados que fizemos na tabela consulta. Ela impede a
criação de um registro quando a data de início da consulta é maior que a data
final, ou seja, se uma consulta começou antes de terminar. Segue um insert com
essa situação.

values (5, 1, 1, to_date('04/02/2013 16:00:00', 'DD/
YYYY HH24:MI:SS'))
ERRO na linha 1: ORA-02290: restrição de verificação (SYSTEM.TD_

HORA_CONSULTA_CK) violada
Não é possível fazer uma inserção de consulta nesta situação. Terminamos

aqui nossa validação de todos os tipos de restrições que criamos no nosso banco
de dados. Fique à vontade para realizar novos testes, criar novos cenários. Com
certeza isso irá lhe ajudar a compreender o funcionamento de um banco de dados.
151
UNIDADE 3 | SQL
2.2 TRANSAÇÕES
Na seção anterior, trabalhamos basicamente com os comandos insert e select
para fazer a validação das restrições na nossa base de dados. Nossa metodologia
para desempenhar tal tarefa foi inserir dados em tabelas e selecionar os mesmos
para averiguação. Porém chegou a hora de uma grande revelação: os dados que
você usou para fazer seus inserts ainda não estão gravados em definitivo nas
tabelas. Inclusive se você fechar o SQL Plus e abri-lo novamente perceberá que os
dados não vão estar mais disponíveis.
Para gravar os dados em definitivo é necessário executar o comando

commit. Isso fará com que todas as inserções que foram feitas sejam gravadas em
definitivo e disponibilizadas para todos os outros usuários do banco. Antes de
um commit ser executado, os dados das tabelas que alteramos ficam disponíveis
apenas para nós.
Esse é o funcionamento básico de uma transação. Morelli (2000) nos diz

que uma transação é um conjunto de operações, comandos SQL, delimitada por
um início e um fim. O fim pode ser um comando commit, que grava os dados em
definitivo, ou um rollback, que desfaz todas as alterações que efetuamos na base até
encontrar o último commit.
O funcionamento é bem simples. Para confirmar a gravação dos dados no

banco, execute um commit. Se quiser desfazer a alteração, efetue um rollback. Não é
possível desfazer as alterações com um rollback após ter dado um commit.
DICAS
Faça testes. Inclua registros nas tabelas e execute um commit. Inclua outros e
efetue um rollback. Tente executar um rollback depois de executar um commit.
2.3 CONVERSÃO DE DADOS

Anteriormente, quando trabalhamos com insert de data e hora utilizamos
uma função to_date para fazer a conversão de string para o tipo date. Basicamente
essa é a ideia chave das funções de conversão de dados. O Oracle trabalha com
quatro funções distintas: to_char, to_number, to_date e nvl. O quadro
a seguir mostra essas funções e detalha a sua aplicação.
152
QUADRO 4 – FUNÇÕES DE CONVERSÃO DE DADOS DO ORACLE
Função Descrição
Converte um campo numérico ou data em uma
to_char(número ou data,
cadeia de caracteres do tipo varchar2, com o
‘formato’)
formato definido pela variável formato.
Converte uma cadeia de caracteres numérica em
to_number(char)
número inteiro
Converte uma cadeia de caracteres, especificando
uma data, no tipo date, de acordo com a variável
to_date(char, ‘formato’)
formato (se omitida, é assumido ‘DD-MMM-
AA’).
Converte um null que encontre na coluna, em um
nvl(coluna, valor)
valor especificado.
FONTE: Morelli (2000 p. 37)
As funções to_char e to_date quando trabalham com datas possuem

letras para definir o formato. O quadro a seguir mostra os principais formatos de
conversão de data.
QUADRO 5 – FUNÇÕES DE CONVERSÃO DE DADOS DO ORACLE
Formato Descrição
YYYY Ano com 4 dígitos
MM Mês (01 – 12)
MON Nome abreviado do mês
WW Semana do ano (1 – 53)
W Semana do mês (1 – 5)
D Dia da semana (1 – 7)
DAY Nome do dia
DD Dia do mês (1 – 31)
DDD Dia do ano (1 – 366)
HH Hora do dia (1 – 12)
HH12 Hora do dia (1-12)
HH24 Hora do dia (0-23)
MI Minutos (0-59)
SS Segundos (0-59)
FONTE: Disponível em: <http://fazendoti.wordpress.com/2011/05/19/usando-

a-funcao-to_date-em-oracle/>. Acesso em: 3 fev. 2013.
153
UNIDADE 3 | SQL
Para exemplificar o uso de uma função que trabalhe com datas vamos ao
seguinte comando.
select to_char(sysdate, ‘DD/MM/YYYY HH24:MI:SS’) from

dual;
Se você executar esse comando, o resultado dele será a data do sistema

juntamente com hora, minuto e segundo. É dessa forma que o Oracle trabalha com
conversão de datas. Neste caso, o sysdate é um comando que retorna a data e hora
atual do sistema e a tabela dual é uma espécie de tabela genérica do Oracle que
existe para ser utilizada nessas situações.
Existem também várias outras funções que o Oracle disponibiliza para trabalhar
com números, caracteres ou datas. Alguns exemplos podem ser vistos em <http://
www.linknacional.com.br/criar-site/2011/11/funcoes-de-manipulacao-no-oracle/>.
2.4 COMANDOS UPDATE E DELETE

Agora que você já conhece e utiliza os comandos insert e select ficará
fácil de entender o update e delete. Eles servem respectivamente para atualizar
ou apagar os dados em tabelas. Vamos começar explorando o comando update.
Sua sintaxe está a seguir.
update nome_da_tabela set nome_campo1 = valor_campo1,

nome_campo2 = valor_campo2,
nome_campoN = valor_campoN
where campo_restricao = valor_campo_restricao;
Para exercitar, vamos executar um update para o nosso paciente Márcio

Júnior Silva (cujo campo nr_sequencia tem o valor 1), para modificar o seu telefone.
Antes vamos fazer um select e verificar qual é o número do telefone que está
cadastrado na base.
select nr_sequencia, nm_paciente, fone_paciente from

paciente;
NR_SEQUENCIA NM_PACIENTE FONE_PACIENTE

------------ ------------- ----------------------
1 Marcio Junior Silva (47)89899999
O novo telefone dele deverá ser (47) 56897412. Segue o comando update.
154
update paciente set fone_paciente = '(47) 56897412'

where nr_sequencia = 1;
commit;
É muito importante o uso da cláusula where, pois sem ela, todos os registros
da tabela paciente ficariam com o mesmo telefone. Normalmente o campo que
faz parte do where é o que identifica o registro que deve ser alterado, ou seja,
a chave primária da tabela. Notem também a presença do commit, para gravar
definitivamente a alteração na tabela. Vamos novamente executar um select
para verificar o que aconteceu.
select nr_sequencia, nm_paciente, fone_paciente from

paciente;
NR_SEQUENCIA NM_PACIENTE FONE_PACIENT

------------ ------------------- ----------------------
1 Marcio Junior Silva (47) 56897412
Conforme pode ser visto, o telefone foi alterado.

Dando continuidade, vamos ver como funciona o comando delete. Ele
tem a finalidade de eliminar registros de tabelas. Também necessita de um commit
no final do processo para confirmar as alterações. Sua sintaxe básica é a seguinte:
delete from nome_tabela

where campo_restricao = valor_campo_restricao;
Para testá-lo vamos novamente utilizar nosso paciente Márcio Júnior Silva
(cujo campo nr_sequencia tem o valor 1). Vamos tentar apagá-lo da tabela paciente.
Segue o comando.
delete from paciente where nr_sequencia = 1
ERRO na linha 1: ORA-02292: restrição de integridade (SYSTEM.

CONSULTA_PACIENTE_FK) violada - registro filho localizado
Desta vez o comando não funcionou. Você se lembra da integridade

referencial que existe entre a tabela consulta e paciente? É uma chave estrangeira
na tabela consulta para o código do paciente. Anteriormente cadastramos uma
consulta para ele e por isso não podemos excluir esse paciente. Uma consulta não
pode ficar sem um paciente e caso o banco permitisse isso, teríamos um erro de
integridade e dados não íntegros.
155
UNIDADE 3 | SQL
Para conseguir apagar esse paciente, precisamos executar dois comandos

delete. O primeiro para apagar todas as consultas que o paciente tem e o segundo
para eliminar o seu cadastro da tabela paciente. Veja a seguir:
delete from consulta where nr_seq_paciente = 1;

delete from paciente where nr_sequencia = 1;
commit;
Aparentemente os registros foram excluídos. Note que no delete da

tabela consulta não foi utilizado o campo nr_sequencia no where, mas sim o
campo nr_seq_paciente que contém o código do paciente. Como a ideia era excluir
todas as consultas do paciente de código = 1, a condição where buscou todas as
consultas do paciente 1. Vamos selecionar os dados da tabela paciente para ver o
que encontramos.
select * from paciente
não há linhas selecionadas
Na tabela paciente que estou utilizando não existem mais registros porque
o Márcio Júnior Silva era o único que estava cadastrado. Caso você tenha mais
pacientes e executar o comando select acima, todos os pacientes devem aparecer,
menos o Márcio Júnior Silva.
DICAS
Se algum dia você desejar eliminar todos os registros de determinada tabela em

uma única vez, não o faça por meio do comando delete. É mais performático
utilizar o comando truncate table nome_da_tabela e logo em seguida um commit.
3 SELEÇÃO DE DADOS
Neste ponto, já sabemos como inserir, alterar e excluir dados de tabelas
do banco. Tivemos uma pequena noção de seleção de dados, que foi necessária
para validar as alterações que foram feitas com os comandos insert, update
e delete. Agora chegou o momento de aprofundarmos um pouco nossos
conhecimentos sobre o comando select.
156
Para isso ser possível, primeiro precisamos cadastrar mais dados em

nossas tabelas. Seguem os comandos para inserção dos dados. Se desejar, você
pode ignorar esses comandos e inserir seus próprios registros.

values (1, ‘Marcio Silva’, ‘16834865101’, ‘(47)89899999’);

values (2, ‘Juca Pedro’, ‘76820503903’, ‘(47)89748596’);

values (3, ‘Maria Quadros’, ‘62052125442’,
‘(47)12256897’);

values (4, ‘Pedro Almeida’, ‘84828752137’,
‘(47)89452541’);

values (5, ‘Josiane Silva’, ‘38145048524’,
‘(49)58574859’);

values (6, ‘Marcos Rocha’, ‘30305222619’, ‘(51)37865247’);

values (7, ‘Tiago Prado’, ‘18131028640’, ‘(39)85697454’);

values (8, ‘Augusto Pereira’, ‘03660633321’,
‘(41)45859687’);

values (9, ‘Priscila Chaves’, ‘67742258706’,
‘(45)25417896’);
157
UNIDADE 3 | SQL

values (10, ‘Marta Campos’, ‘43407732805’,
‘(49)65897485’);

values (1, ‘Jader Fonseca’, ‘1002365’, ‘94269268018’,
‘(99) 12438080’);

values (50, ‘Fernando Ferreira’, ‘105263’, ‘56624682736’,
‘(45) 58996452’);

values (51, ‘Marleide Benta’, ‘1089745’, ‘21764632184’,
‘(48) 49564586’);

values (52, ‘Cabral Rodrigues’, ‘2035698’, ‘13167468106’,
‘(44) 89745214’);

values (100, 1, 1, to_date(‘04/02/2013 20:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘04/02/2013 21:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));

values (101, 10, 50, to_date(‘05/02/2013 15:00:00’, ‘DD/

values (102, 9, 51, to_date(‘10/02/2013 15:00:00’, ‘DD/
158

values (103, 8, 52, to_date(‘04/02/2013 11:00:00’, ‘DD/

values (104, 7, 1, to_date(‘20/02/2012 15:00:00’, ‘DD/

values (105, 6, 50, to_date(‘11/04/2013 16:00:00’, ‘DD/

values (106, 4, 51, to_date(‘13/06/2013 17:00:00’, ‘DD/

values (107, 5, 52, to_date(‘14/09/2012 14:00:00’, ‘DD/

values (108, 2, 1, to_date(‘24/01/2011 13:00:00’, ‘DD/

values (109, 1, 50, to_date(‘07/04/2013 15:30:00’, ‘DD/

values (110, 3, 1, to_date(‘08/11/2010 13:30:00’, ‘DD/
159
UNIDADE 3 | SQL

values (111, 3, 50, to_date(‘02/12/2012 19:00:00’, ‘DD/

values (112, 2, 1, to_date(‘05/03/2013 15:00:00’, ‘DD/

values (113, 1, 52, to_date(‘19/07/2012 15:30:00’, ‘DD/

values (114, 5, 1, to_date(‘11/01/2013 14:00:00’, ‘DD/

values (115, 1, 51, to_date(‘28/04/2013 13:40:00’, ‘DD/

values (116, 1, 1, to_date(‘10/08/2013 15:00:00’, ‘DD/

values (117, 1, 50, to_date(‘09/02/2013 15:00:00’, ‘DD/

values (118, 1, 1, to_date(‘27/11/2013 15:00:00’, ‘DD/
160

values (119, 1, 52, to_date(‘09/05/2013 15:00:00’, ‘DD/

values (120, 1, 1, to_date(‘14/05/2013 15:00:00’, ‘DD/
Depois de colocarmos dados nas tabelas, vamos adiante. Um comando

select tem várias particularidades e detalhes. Segue uma sintaxe básica:
select [distinct] coluna1, coluna2, colunaN

from tabela1, tabela2, tabelaN
where condições
[group by colunas]
[having [condição]
[order by colunas]
Vamos apresentar alguns exemplos de comandos select com tudo o que está
apresentado nesta sintaxe. Porém, vamos iniciar pelo básico. Segue um select que
tem como objetivo listar o nome de todos os médicos que tem telefone informado.
select nm_medico
from medico
where fone_medico is not null;
Segue o resultado do comando.
NM_MEDICO
------------------------------------------------------
Jader Fonseca
Fernando Ferreira
Marleide Benta
Cabral Rodrigues
Neste select, a cláusula where é responsável por filtrar se todos os telefones

tem valor informado (se são não nulos). Em outros momentos ela pode servir
também para fazer joins entre tabelas, ou seja, quando eu necessito acessar mais
de uma tabela para recuperar os dados, é feito a junção através dos campos que
compõem o relacionamento.
161
UNIDADE 3 | SQL
Veja no exemplo a seguir, um select que mostra todas as consultas realizadas

no período de 01/01/2012 até 31/01/2013. Os dados que serão buscados são o nome
do médico, a data da consulta e o nome do paciente.
select b.nm_medico, a.dt_hora_inicio, c.nm_paciente

from consulta a, medico b, paciente c
where a.dt_hora_inicio between to_date(‘01/01/2012
00:00:00’, ‘DD/MM/YYYY HH24:MI:SS’)
and to_date(‘31/01/2013 23:59:59’, ‘DD/MM/YYYY
HH24:MI:SS’)
and b.nr_sequencia = a.nr_seq_medico
and c.nr_sequencia = a.nr_seq_paciente
order by a.dt_hora_inicio;

O comando between serve para informar o Oracle para buscar dados
dentro de um intervalo definido, que no caso acima é um período de datas. Esse
comando é um filtro dentro do select. Já as duas linhas em destaque são joins das
tabelas médico e paciente com a tabela consulta. Note que o acesso é feito pelos
campos que compõem a chave estrangeira. Foi utilizado a cláusula order by que
serve apenas para ordenar os dados. Segue o resultado:
NM_MEDICO DT_HORA_INICIO NM_PACIENTE

----------------------- ------------------- ----------
Jader Fonseca 20/02/2012 15:00:00 Tiago Prado
Cabral Rodrigues 19/07/2012 15:30:00 Marcio Junior Silva
Cabral Rodrigues 14/09/2012 14:00:00 Josiane Silva
Fernando Ferreira 02/12/2012 19:00:00 Maria Quadros
Jader Fonseca 11/01/2013 14:00:00 Josiane Silva
Ao invés de listar as datas e nome dos pacientes, poderíamos apenas

contar por médico quantas consultas eles atenderam no mesmo intervalo de datas.
Usaríamos uma função de agrupamento de dados para obter esse resultado. O
comando pode ser visto a seguir:
select b.nm_medico, count (a.nr_sequencia)

from consulta a, medico b
HH24:MI:SS’)
group by b.nm_medico;
As partes em destaque no comando fazem parte do agrupamento de dados.

A função count conta o número de consultas. Sempre que trabalhamos com esse
tipo de função precisamos usar o group by e informar todos os campos que não
estão sendo contados. Existem outras funções para agrupamento de valores como
o max e o min que buscam o valor maior e o valor menor respectivamente.
162
Segue o resultado do comando:
NM_MEDICO COUNT(A.NR_SEQUENCIA)
------------------------ --------------------
Cabral Rodrigues 2
Jader Fonseca 2
Fernando Ferreira 1
Para finalizarmos nosso tópico, vamos falar sobre o having. Este comando
tem a finalidade de aplicar um filtro nos dados depois de eles serem agrupados.
Para exemplificar, vamos fazer com que no select acima sejam retornados somente
os médicos com duas consultas. Segue o comando e o resultado:
select b.nm_medico, count (a.nr_sequencia)

from consulta a, medico b
HH24:MI:SS’)
group by b.nm_medico
having count (a.nr_sequencia) = 2;
NM_MEDICO COUNT(A.NR_SEQUENCIA)
------------------------ --------------------
Cabral Rodrigues 2
Jader Fonseca 2
Retornaram somente os médicos com duas consultas.
Existe uma infinidade de recursos e funcionalidades avançadas que são

possíveis de aplicar ao comando select. O que foi passado neste Caderno de
Estudos é apenas uma forma introdutória de seleção de dados. Você pode consultar
a bibliografia da disciplina se deseja aprofundar ainda mais os seus estudos.
163
UNIDADE 3 | SQL
UNI
Caro(a) acadêmico(a)! A Leitura Complementar a seguir fala sobre um tema

que é muito comentado principalmente no mundo WEB: a injeção de dados maliciosos em
comandos SQL. Visando obter vantagens de acesso ou até mesmo a invasão de um sistema,
pessoas mal intencionadas fazem uso desta vulnerabilidade.
SITE PROTEGIDO CONTRA SQL INJECTION E CONCEITUAÇÃO
A Injeção de SQL, mais conhecida através do termo americano SQL

Injection, é um tipo de ameaça de segurança que se aproveita de falhas em sistemas
que interagem com bases de dados via SQL. A injeção de SQL ocorre quando o
atacante consegue inserir uma série de instruções SQL dentro de uma consulta
(query) através da manipulação das entradas de dados de uma aplicação.
Funcionamento
Para exemplificar o funcionamento da injeção de SQL, vamos considerar

uma instrução SQL comum:
SELECT id, nome, sobrenome FROM autores;
Essa instrução, que representa uma consulta na base de dados, retorna

todos os registros das colunas “id”, “nome” e “sobrenome” da tabela “autores”. A
partir desta mesma instrução, os registros a serem retornados podem ser restritos
através da inclusão da cláusula WHERE, como é visto no exemplo abaixo:
SELECT id, nome, sobrenome FROM autores WHERE nome =

‘josé’ AND sobrenome = ‘silva’;
Com base nesta instrução, é fácil supor que “josé” e “silva” são strings,
cujo conteúdo será preenchido pela entrada feita por algum usuário que estiver
fazendo uso da aplicação.
Portanto, supondo que a aplicação não faça o tratamento apropriado do

conteúdo inserido pelo usuário, o mesmo pode fazer o uso acidental do caractere
de aspas simples. Gerando a entrada: nome = jo’sé e sobrenome = silva, fazendo
com que a aplicação gere o código:
164

‘jo’sé’ AND sobrenome = ‘silva’;
De acordo com a especificação da linguagem SQL, existe um erro

de sintaxe nessa instrução, uma vez que a string passada para o campo nome é a
apenas palavra “jo”, pois a adição das aspas simples quebrou a delimitação das
aspas simples originais da consulta. O interpretador do SQL espera que o restante
da instrução seja outros comandos SQL válidos que complementem a instrução
principal. No entanto, como “sé” não é um identificador válido, essa instrução não
será executada e retornará um erro.
Com base neste problema, um possível atacante pode manipular os dados

de entrada a fim de gerar um comportamento não esperado na base de dados.
Para exemplificar este conceito, consideremos na mesma consulta

apresentada, a entrada dos seguintes dados pela aplicação: nome = jo’; DROP
TABLE autores ; -- sobrenome = silva, fazendo com que a aplicação gere o código:

‘jo’; DROP TABLE autores ; --’ AND sobrenome = ‘silva’;
Neste caso, a instrução será executada normalmente, pois não há um erro

de sintaxe, no entanto, com a adição do caractere ponto-e-vírgula, a instrução foi
dada como finalizada de modo prematuro dando espaço para uma nova instrução.
Essa nova instrução, que poderia ser qualquer uma escolhida pelo atacante, pode
ser a responsável por retornar dados confidenciais armazenados na base de dados
ou de executar instruções que comprometam o sistema, como a remoção de dados
e/ou tabelas, como pode ser visto no exemplo apresentado.
Aparentemente um método para prevenir esse problema seria a remoção

de aspas simples dos campos de inserção da aplicação, ou simplesmente não
executando a query nestas situações. Isso é verdade, mas existem várias dificuldades
com esse método tanto quanto soluções. Primeiro, nem todos os usuários inserem
dados em forma de strings. Se o usuário puder selecionar um autor pelo ‘id’
(presumivelmente um número), por exemplo, nossa query aparecerá como abaixo:
SELECT id, forename, surname FROM authors WHERE id=1234
Nesta situação, o atacante pode simplesmente adicionar uma instrução SQL

no fim do ‘input’ numérico. Verificando os dialetos de SQL, vários delimitadores
podem ser usados no Microsoft Jet DBMS engine, por exemplo, datas podem
ser delimitadas com o caracter sustenido. Portanto, escapando da execução da
adição de aspas simples, não necessariamente uma solução como demonstrado
anteriormente.
FONTE: Disponível em: <http://www.2bweb.com.br/Artigos-software-Web/site-protegido-contra-

sql-injection-e-conceituacao.cfm>. Acesso em: 3 fev. 2013.
165
RESUMO DO TÓPICO 2
• O comando insert serve para inserir dados em tabelas.
• O comando update atualiza dados em tabelas.
• O comando delete apaga dados em tabelas.
• Existem vários modos de fazer a validação das restrições em tabelas.
• O comando select seleciona os dados de um banco de dados.
166
AUTOATIVIDADE
1 Faça um comando select que liste todos os nomes de pacientes em ordem

alfabética.
2 Tente apagar algum médico que possua uma consulta. É possível fazer isso?
Se não for, explique o motivo.
3 Escolha uma das consultas cadastradas na tabela consulta e tente colocar o

valor 599 para o campo nr_seq_paciente. Relate o que aconteceu.
4 Para fins de otimização de performance, que comando deve ser utilizado

para apagar todos os registros de determinada tabela?
5 Que comando pode ser utilizado para contar registros em um select que
utiliza uma função de agrupamento de dados?
167
168
UNIDADE 3
TÓPICO 3
OUTRAS ESTRUTURAS DE DADOS

“Não são as ervas más que afogam a boa semente,
e sim a negligência do lavrador”. (Confúcio)
1 INTRODUÇÃO
Chegamos ao último tópico deste Caderno de Estudos. Com muito esforço
e determinação estamos concluindo a disciplina de princípios de bancos de dados.
O conteúdo que será apresentado nesta última parte é composto de algumas
estruturas de bancos de dados que ainda não vimos.
FIGURA 61 – CHEGAMOS À RETA FINAL
FONTE: Disponível em: <http://run-x.blogspot.com.br/2010_03_01_

archive.html>. Acesso em: 4 fev. 2013.
Elas servem basicamente para complementar tudo o que já foi visto, em

alguns casos até automatizando comandos que antes fazíamos “no braço”. Está
dividida em dois momentos: o primeiro trata de alguns objetos de bancos de dados
e o segundo lista alguns recursos da linguagem PL/SQL.
Novamente desejo a você bons estudos!
169
UNIDADE 3 | SQL
2 OBJETOS DE BANCOS DE DADOS

Esta seção tem como objetivo apresentar estruturas de dados de um banco.
As mesmas visam dar suporte a uma gama de recursos que complementam o
trabalho de armazenar e recuperar dados.
De uma forma geral, vamos discutir sobre três itens: índices, sequences e
views. Daremos exemplos de um uso cotidiano apresentando a necessidade de
uma forma detalhada.
2.1 ÍNDICES
É um tipo de estrutura que tem como objetivo facilitar o acesso dos
dados pelo banco de dados. Está diretamente ligado a questões de desempenho
e diminuição do uso de recursos do servidor no qual o banco está disponível (se
você instalou o Oracle na sua máquina, ela é o servidor).
Morelli (2000, p. 69) nos dá uma definição do que é um índice.
Índices (index) são estruturas especiais inseridas no banco de dados

com o objetivo de melhorar o desempenho de acesso às tabelas. Sua
função é reduzir o I/O em disco utilizando uma estrutura de árvore
binária (B*Tree) para localizar rapidamente os dados. Ao varrer a
árvore binária, ele identifica a chave e recupera o seu rowid, ponteiro
para acesso ao dado, localizando o registro rapidamente. O Oracle cria
automaticamente um índice do tipo unique ao criar uma chave primária,
o qual recebeu o mesmo nome da constraint.
Entenda que rowid é um indentificador único de registros gravados em

tabelas. Ele tem certa relação com índices. Segue a sintaxe de criação de um índice.
create index nome_do_indice on tabela (nome_campo);
A sintaxe é extremamente simples. Índices na sua forma mais básica são

criados em campos que fazem parte de relacionamentos. Seguindo esta linha,
precisamos criar dois índices no nosso modelo de dados e ambos na tabela consulta.
Seguem os comandos:
create index nr_seq_paciente_fk_i on consulta (nr_seq_

paciente);
create index nr_seq_medico_fk_i on consulta (nr_seq_
medico);
170
TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS
UNI
O texto a seguir trata sobre algumas dicas para a criação de índices no que se
refere a situações quando devem ser criados.
DICAS PARA CRIAÇÃO DE ÍNDICE
Deparei com um material bem interessante que traz algumas “premissas”

para a criação de índices.
Segue a lista de sugestões:
Crie índices quando:
Uma coluna contiver uma grande faixa de valores.

Uma coluna contiver muitos valores nulos.
Quando uma ou mais colunas forem usadas frequentemente em clausulas
WHERE ou em JOINS.
Se a tabela for muito grande e as consultas realizadas recuperarem menos
de 5% dos registros.
NÃO crie índices quando:
As colunas não são usadas frequentemente como condição nas consultas.

A tabela for pequena ou se os resultados das consultas forem maiores que
5-10% dos registros.
A tabela for atualizada com frequência.
As colunas fizerem parte de uma expressão
* Nesse item entende-se por expressão algo na cláusula where tipo:
SELECT TABLE_NAME
FROM ALL_TABLES
WHERE TABLE_NAME||OWNER = ‘DUALSYS’
Observe que na cláusula de comparação as colunas TABLE_NAME e
OWNER fazem uma expressão de comparação e por consequência um índice
não ajudaria em nada.
171
UNIDADE 3 | SQL
Outras coisas importantes de lembrar:
ÍNDICES NÃO SÃO ALTERÁVEIS! (Para alterar um índice você deve

removê-lo e recriá-lo.)
ÍNDICES ONERAM A PERFORMANCE DE INSERT / UPDATE (Não
dá para fazer milagres, se sua tabela tiver muitos índices as performances de
alterações podem ser comprometidas).
FONTE: Disponível em: <http://www.dartanghan.com.br/oracledb/oracle-index-dicas-para-
criacao-de-indice/>. Acesso em: 4 fev. 2013.
2.2 SEQUENCES
Este tipo de estrutura visa gerar sequências de números, que na maioria das
vezes são utilizadas em chaves primárias de tabelas. É basicamente um objeto que
gera valores numéricos toda vez que for solicitado, porém sempre em sequência,
incrementando os valores para que eles não se repitam.
Pense no nosso modelo de dados. Para as tabelas médico, consulta e paciente

poderia existir uma sequence para cada uma delas. Ao invés de fazermos o insert
com números fixos, poderíamos chamar uma sequence para gerenciar a inserção
dos campos nr_sequencia. De uma forma geral, esta é a função de uma sequence.
Segue a sintaxe do comando para criação de uma sequence segundo Morelli

(2000).
create sequence sequencia

[increment by n]
[start with n]
[maxvalue n | nomaxvalue]
[cycle | nocycle]
[cache n | nocache];
QUADRO 6 – DETALHE DOS ITENS DA SINTAXE
Opção Descrição
Nome da sequência que não pode ser o nome de uma
sequencia
tabela ou view.
Especifica de quanto será o incremento ou decremento
increment by n
da sequência. O default é 1.
start with n Especifica o primeiro número a ser gerado. O default é 1.
Especifica o valor máximo que a sequência pode
maxvalue n
assumir. O default é nomaxvalue, indo até 1027.
172
Especifica o valor mínimo para sequências que estejam

minvalue n sendo decrementadas. É mutuamente exclusiva à
anterior.
Indica que, quando atingir o valor máximo, a
cycle | nocycle numeração continuará a partir do valor inicial. O
default é nocycle.
Especifica quantos valores o Oracle pré-aloca e mantém
cache n | nocache
em memória. O default é 20.
FONTE: Morelli (2000, p. 73)
Visando um pouco de prática, vamos criar uma sequence para a tabela

paciente.
create sequence nr_sequencia_paciente_sequ maxvalue 999999;
Note que o número máximo da sequence será 999999 porque na definição do

campo nr_sequencia da tabela paciente temos um numérico de seis posições. Vale
a pena ressaltar que uma sequence não tem vínculo nenhum com tabela ou campo,
entretanto pode não ser correto declarar uma sequence com tamanho incompatível
com o do campo onde ela será utilizada.
Para buscar o próximo número da sequence criada acima, podemos usar nr_
sequencia_paciente_seq.nextval. Já para retornar o valor corrente usamos
o nr_sequencia_paciente_seq.currval. Para fins de testes é possível fazer
o select seguinte para retornar valores das sequences.
select nr_sequencia_paciente_sequ.nextval from dual
NEXTVAL
----------
1
select nr_sequencia_paciente_sequ.currval from dual
CURRVAL
----------
1
173
UNIDADE 3 | SQL
DICAS
Para fins de lembrança, como foi abordada anteriormente a tabela dual é uma
espécie de tabela coringa no Oracle e serve para utilizar nesses casos em que precisamos
retornar valores.
Segue o exemplo de um comando insert utilizando a sequence criada.

paciente)
values (nr_sequencia_paciente_sequ.nextval, 'Alberto
Antunes', '21724524593');
Se acaso for utilizado o comando nextval na sequence ela incrementará o

seu valor atual. Quando for feito um nextval e o valor não for utilizado, o mesmo
será “perdido”, pois sempre que a sequence é requisitada com nextval ela muda
o seu valor.
UNI
O texto a seguir compara o comportamento de uma sequence no Oracle com os

recursos que outros bancos de dados disponibilizam.
SEQUÊNCIAS ORACLE
Se você utiliza MS Access, deve conhecer o tipo de dados AutoNumber,

que pode ser utilizado para definir uma coluna de tabela preenchida
automaticamente com valores numéricos exclusivos. Com efeito, quando se
cria uma tabela em MS Access e se esquece de definir uma chave primária, o
aplicativo oferecerá a criação de uma coluna de PK. Se aceita, observe que o
MS Access cria uma coluna chamada ID com tipo de dados AutoNumber. Após
definir uma coluna com AutoNumber, todas as vezes em que uma linha for
inserida na tabela, o MS Access adicionará automaticamente um valor a essa
coluna, começando com 1 e aumentando em uma unidade a cada nova linha
adicionada. Além disso, não é possível incluir esta coluna em comandos insert
– o Access não permite editar esse valor de modo algum. O MS SQL Server
174
utiliza a propriedade da coluna “Identity” (identidade) para atender a uma

finalidade similar. Em MS SQL Server, uma tabela pode ter, no máximo, uma
coluna definida como “Identity”. Essa coluna se comporta de modo similar a
coluna do MS Access com tipo de dados AutoNumber.
O Oracle não dá suporte ao tipo de dados AutoNumber ou à propriedade

de coluna “Identity”. Em vez disso, pode-se utilizar uma “sequencia” para
atribuir valores a uma coluna de tabela. Mas as sequencias do Oracle são muito
diferentes do AutoNumber do Access e merecem uma análise mais detalhada.
- São objetos independentes no banco de dados (não são um tipo de dados).

- Possuem um nome e podem ser utilizadas em qualquer posição de comando
em que se espere um valor.
- Não são atreladas a uma tabela ou coluna.
- Geram um valor numérico automático que pode ser atribuído a qualquer
coluna de qualquer tabela.
- O atributo de tabela ao qual é atribuído um valor com base em sequência pode
ser editado e modificado.
- É possível editar e excluir uma sequência do Oracle a qualquer momento.
2.3 VIEWS
Uma view é uma espécie de tabela virtual que o Oracle disponibiliza para
visualização de dados. Ela pode ter diversos fins, como formatação de dados,
obtenção de informações calculadas com base em dados, segurança etc. É um
objeto que está construído para retornar informações de um select.
Rob e Coronel (2011, p. 294) nos dão um exemplo de aplicabilidade das views.
Suponha que, no fim de cada dia, deseje-se obter uma lista de todos
os produtos que devem ser encomendados, ou seja, produtos cuja
quantidade disponível é menor ou igual a uma quantidade mínima. Em
vez de digitar a mesma consulta no fim de cada dia, não seria melhor
salvar essa consulta de forma permanente no banco de dados? Essa é a
função de uma visualização relacional. Uma visualização é uma tabela
virtual baseada em uma consulta select.
Na citação acima entenda visualização relacional como um termo designado

para definir uma view. Segue a sintaxe básica da criação de uma view.
create view nome_da_view as comando select;
Não existe muito segredo quanto a sua definição. O comando é extremamente

simples. Entretanto, vale a pena ser discutida a sua aplicação.
175
UNIDADE 3 | SQL
Morelli (2000) cita dois exemplos onde à criação de uma view pode ser
aplicada. No primeiro, ele explica que uma view pode ser criada para evitar que
usuários não autorizados tenham acesso a todos os dados de uma tabela. Para isso,
cria-se uma visão com apenas uns campos.
Outro exemplo que esse mesmo autor nos dá se refere à associação de uma
visão a consultas que utilizam critérios de seleção complexos, facilitando assim a
vida dos usuários.
Voltando novamente o foco para o nosso modelo de dados, poderíamos

criar uma visão para mostrar todas as consultas que um médico vai atender ou já
atendeu e seus respectivos pacientes. Assim, teríamos facilidade maior em fazer
uma pesquisa com os dados. Segue o comando de criação da view.
create or replace view medico_consulta_paciente as

select a.nr_sequencia nr_seq_medico,
a.nm_medico,
a.crm_medico,
a.cpf_medico,
a.fone_medico,
b.nr_sequencia nr_seq_consulta,
b.dt_hora_inicio,
b.dt_hora_fim,
b.ds_observacao,
c.nr_sequencia nr_seq_paciente,
c.nm_paciente,
c.cpf_paciente,
c.fone_paciente
from medico a,
consulta b,
paciente c
where b.nr_seq_medico = a.nr_sequencia
and c.nr_sequencia = b.nr_seq_paciente;
A partir de agora, os comandos de seleção de dados ficam mais fáceis. Por

exemplo, se desejarmos uma lista de médicos com todos os pacientes que já se
consultaram ou vão se consultar, apenas buscamos os campos que precisamos sem
necessidade de acessar mais de uma tabela.
select distinct nm_medico, nm_paciente

from medico_consulta_paciente
order by nm_medico
E o resultado é:
176
NM_MEDICO NM_PACIENTE
---------------------------------------- ---------------
Cabral Rodrigues Augusto Pereira
Cabral Rodrigues Marcio Junior Silva
Cabral Rodrigues Josiane Silva
Fernando Ferreira Marcio Junior Silva
Fernando Ferreira Marta Campos
Fernando Ferreira Marcos Rocha
Fernando Ferreira Maria Quadros
Jader Fonseca Josiane Silva
Jader Fonseca Maria Quadros
Jader Fonseca Juca Pedro
Jader Fonseca Marcio Junior Silva
Jader Fonseca Juca Pedro
Jader Fonseca Tiago Prado
Marleide Benta Marcio Junior Silva
Marleide Benta Priscila Chaves
Marleide Benta Pedro Almeida
Perceba que foi utilizado o comando distinct no select porque um paciente

pode ter consultado mais de uma vez um médico e caso o distinct seja retirado,
alguns registros irão se repetir.
ATENCAO
O comando distinct normalmente está relacionado a uma performance baixa

no momento da execução do mesmo. Ele torna, em alguns casos, o trabalho de retornar
um resultado um pouco mais lento que o normal. Utilize-o somente em casos quando for
extremamente necessário.
3 PL/SQL
Até este momento você aprendeu a utilizar comandos SQL para criar
estruturas de dados como tabelas, índices, sequences, views etc. Outro foco era a
manipulação de dados, com comandos de inserção, atualização, deleção e seleção.
A partir deste momento, vamos falar de uma linguagem procedural, com

comandos de if/else, while, for etc. Estamos nos referindo a PL/SQL, a linguagem
implementada pelo banco de dados Oracle.
Outros bancos também têm suas linguagens próprias, como é o caso

do PostgreSQL que utiliza o PgSQL como sua linguagem de programação. Essa
abordagem traz alguns benefícios, dentre eles uma melhoria no desempenho e
uma centralização das regras de negócio.
177
UNIDADE 3 | SQL
Em relação à centralização de regras de negócio, Rob e Coronel (2011, p.

360) fazem uma breve consideração.
Uma abordagem melhor é isolar o código fundamental e, em seguida,

fazer com que todos os aplicativos chamem esse código compartilhado.
A vantagem de tal abordagem modular é que o código de aplicação é
isolado em um único programa, resultando, assim, em melhor controle
de manutenção e lógica.
Quanto à melhoria de desempenho, podemos considerar um fato bem básico.

Quando os dados são todos processados dentro do próprio banco de dados, eles
não trafegam pela rede, diminuindo bastante o tempo de resposta. Claro que essa
afirmação pode sofrer variações, pois ela não é verdadeira no caso em que a máquina
que hospeda o banco de dados não tenha um bom poder de processamento.
Focando especificamente no PL/SQL, vamos ver apenas quatro recursos de

programação: procedure, function, package e triggers. A linguagem PL/SQL possui
uma série de outros recursos, entretanto o que vamos mencionar faz parte da base
da linguagem e é pré-requisito para adquirir conhecimentos mais avançados.
3.1 PROCEDURES
Uma procedure é um agrupamento de comandos SQL que podem conter
estruturas de seleção, controle e repetição para gerenciá-los. Uma das características
é que uma procedure pode fazer alterações de dados em tabelas e não retorna um
valor no final do seu processamento.
Como a linguagem PL/SQL tem vários recursos no que se refere à

programação, não vamos mais trabalhar com a ideia de sintaxe dos comandos. Ao
invés disso, vamos apresentar um exemplo de uma necessidade acompanhada da
implementação do código fonte.
Voltando para o nosso modelo de dados, suponhamos que seja necessário

atrasar uma determinada consulta em um dia. Podemos criar uma procedure
que recebe o código da consulta (nr_sequencia da tabela consulta) e executa um
update no horário de início e horário de fim. Caso a solicitação de atraso tenha sido
solicitada pelo paciente, colocar uma mensagem no campo ds_observacao com os
seguintes dizeres: “Paciente solicitou alteração de data da consulta. A data antiga
era em data_antiga”.
O código fonte a seguir mostra a implementação desta procedure.
create or replace procedure p_atrasa_consulta
( p_consulta consulta.nr_sequencia%type
, p_solic_paciente varchar2) is
l_data_hora_inicio_ant date;
178
begin
-- se atraso foi solicitado pelo paciente

-- busca as datas antigas para armazenar no campo ds_
observacao
if(p_solic_paciente = 'S') then
select dt_hora_inicio
into l_data_hora_inicio_ant
from consulta
where nr_sequencia = p_consulta;
-- atualiza o campo de observação

update consulta set ds_observacao = 'Paciente solicitou
alteração de consulta. A data antiga era ' || to_char(l_data_
hora_inicio_ant, 'DD/MM/YYYY HH24:MI:SS')
end if;
-- atrasa a consulta em um dia

update consulta set dt_hora_inicio = dt_hora_inicio + 1,
dt_hora_fim = dt_hora_fim + 1
end p_atrasa_consulta;
Se sua base de dados contém uma consulta cujo nr_sequencia = 110, o

comando a seguir executa a procedure, fazendo com que a data seja alterada e a
observação gerada.
exec p_atrasa_consulta(110, ‘S’);

commit;
3.2 FUNCTION
Uma function tem os mesmos princípios de uma procedure, porém retorna
um valor no final de sua execução. Vamos a um exemplo prático: todo CPF válido
deve ter 11 caracteres. Vamos fazer uma function que recebe um CPF e retorna S no
caso de ter 11 caracteres e N para qualquer outro caso. Segue o código fonte.
create or replace function f_valida_cpf(p_cpf varchar2)

return varchar2 is
l_result varchar2(1);
179
UNIDADE 3 | SQL
begin
l_result := 'N';
if(length(p_cpf) = 11) then

l_result := 'S';
end if;
return l_result;
end f_valida_cpf;
Para testar a função você pode usar o comando a seguir, variando o número
do CPF que é passado para a função.
select f_valida_cpf(‘numero do cpf’) from dual;
ATENCAO
Para fins de esclarecimento, o número do CPF possui uma fórmula para validação.
Como nosso foco aqui é meramente educativo, decidimos validar apenas a presença de 11
caracteres.
3.3 PACKAGES
Até o momento, vimos o conceito de procedure e function. Tivemos um exemplo
de declaração de cada tipo para elucidar a forma de trabalho de uma linguagem de
banco de dados procedural. Com o passar do tempo, quando programamos, muitas
vezes, percebemos que determinada function está ligada logicamente a um conceito
que uma procedure pode abranger.
Nesse ponto entra o conceito de package. É um agrupamento de procedures,

functions e outros objetos que estão relacionados a alguma situação específica. É uma
espécie de empacotamento de funcionalidades com um foco comum. Segue uma package
com o nome teste_package.
create or replace package teste_package is

-- definição de functions e procedures (somente a definição)
create or replace function f_valida_cpf(p_cpf varchar2)

returnvarchar2;
end teste_package;
create or replace package body teste_package is
180
-- definição de functions e procedures (definição e implementação)
create function f_valida_cpf(p_cpf varchar2) returnvarchar2is
l_result varchar2(1);
begin
l_result := 'N';
if(length(p_cpf) = 11) then

l_result := 'S';
end if;
return l_result;
end f_valida_cpf;
end teste_package;
Perceba que a criação de uma package é dividida em dois momentos. O

primeiro contém apenas o cabeçalho das procedures ou functions e o segundo trata
da definição propriamente dita. A função f_valida_cpf foi incluída para fins de
demonstração. Se uma function ou procedure for criada dentro do body de uma
package e não for declarada no cabeçalho, a mesma não poderá ser acessada por
comandos que estejam fora da package. Segue um exemplo para executar a função
criada em uma estrutura de package.
select teste_package.f_valida_cpf(‘numero do cpf’) from

dual;
3.4 TRIGGERS
Uma trigger tem a finalidade de executar alguma rotina de programação
quando são feitas manutenções ou inserções de registros em tabelas. É basicamente
um gatilho que é acionado conforme foi designado na sua programação.
É possível, por exemplo, a criação de uma trigger que execute determinado

comando quando for dado update em alguma tabela. Isso vale também para ações
de insert e delete.
Algumas aplicações práticas são: log dos dados alterados, alimentação de

dados redundantes, validação das informações inseridas ou atualizadas etc. Nosso
exemplo irá supostamente tratar a inserção de CPF inválido na tabela paciente.
Sempre que um CPF for considerado inválido, o Oracle emitirá uma mensagem de
erro. Segue a implementação.
181
UNIDADE 3 | SQL
create or replace trigger valida_cpf_paciente

before insert or update on paciente
for each row
begin
if(f_valida_cpf(:new.cpf_paciente) = 'N') then
raise_application_error(-20500, 'CPF inválido');
end if;
end valida_cpf_paciente;
Uma trigger tem uma forma interessante de acessar os valores da tabela

que está sendo alterada. Ela usa :new.nome_do_campo para buscar o valor após a
alteração e :old.nome_do_campo para retornar o valor antigo. Para executar a trigger,
realize um update na tabela paciente em algum CPF como no exemplo a seguir.
update paciente set cpf_paciente = '565' where nr_

sequencia = 11;
Esse comando fará com que a trigger seja disparada e retorne um erro, pois
o CPF só tem três caracteres. Não se esqueça de trocar o nr_sequencia = 11 para
nr_sequencia = algum nr_sequencia cadastrado na sua base. Se acaso tudo estiver
certo, a trigger não irá gerar erro algum.
UNI
Caro(a) acadêmico(a)! A Leitura Complementar a seguir traz uma visão sobre

performance em PL/SQL. Ele trata de duas questões: a troca de contexto e o manutenção de
dados em tabelas temporárias. Entenda a troca de contexto como um comando SQL sendo
executado dentro de um PL/SQL e tabelas temporárias como sendo a mesma filosofia de
uma tabela normal, porém seus dados são temporários, ou seja, quando o scritp terminar de
executar a tabela estará vazia.
182
DICAS PARA OBTER PERFORMANCE EM PL/SQL
O primeiro tópico que eu gostaria de abordar é questão da troca de

contexto. Muita gente não sabe disso, então convém citar uma breve introdução.
No Oracle, existem duas engines distintas que vão se encarregar de fazer o parse
do seu código e executá-lo: a engine SQL e a engine PL/SQL. Acontece que, quando
você envia para o Oracle um comando SQL, ele vai diretamente para a engine SQL
para executar a validação do comando, o parse, a elaboração do plano e por fim a
execução e fetch. Agora, se você envia um comando PL/SQL, tudo aquilo que não
for relacionado ao SQL é executado pela engine de PL/SQL, como por exemplo,
alocação de memória para arrays, atribuição de variáveis, cálculos, etc. Porém,
quando o seu bloco chega em uma instrução SQL, ele vai simplesmente passar a
informação adiante para a engine SQL processar. Neste evento ocorre a chamada
troca de contexto, que nada mais é o ponto onde a engine PL/SQL para e passa o
controle para a engine SQL.
O que acontece é que esta troca de contexto tem um custo para o banco... no
meu banco eu fui capaz de medir em uma situação muito especifica um tempo de troca
de contexto da ordem de 18us (microssegundos). Parece pequeno, mas não é. Pense
neste tempo dentro de um loop for que executa um milhão de vezes, por exemplo.
Um caso típico de troca de contexto que pode ser otimizada é o “Select ...
Into ... From Dual;”. Muita gente utiliza este comando com o objetivo de atribuir
valores a variáveis, quando na verdade deveria estar simplesmente fazendo a
atribuição da forma “x := y;” que não envolve nenhuma troca de contexto.
Remover a troca de contexto desnecessárias de blocos PL/SQL em processos

intensivos foi responsável, na minha experiência prática, por ganhos de até 30%
na velocidade de execução. Já houve um tempo que o PL/SQL não dispunha da
maioria das funções disponíveis no SQL, porém hoje em dia a grande maioria está
implementada nas duas engines e, portanto, não há mais necessidade de fazer
chamadas com Select from dual. Uma exceção que eu poderia citar é a função
REVERSE (que inverte uma string) que, pelo menos na versão do banco que eu
estou trabalhando (10g R2), não existe no PL/SQL. Podem existir outras exceções,
mas o importante é remover aqueles pontos que não há necessidade.
Outra questão que gera grande degradação de performance em processos é o

uso excessivo de tabelas temporárias. Eu sei que esta é uma prática herdada de outros
bancos, mas no Oracle o abuso destas tabelas pode dar muita dor de cabeça. Num
outro caso de tuning de sucesso que eu executei, uma tabela temporária estava sendo
utilizada para passar valores múltiplos para uma procedure. Esta é uma abordagem
muito comum em Sybase e SQL Server, porém em Oracle o correto é passar os valores
através de um array, especialmente pelo que vou descrever a seguir.
183
UNIDADE 3 | SQL
A tabela temporária funcionava muito bem quando havia uma única

chamada de procedure, porém, quando o sistema evoluiu houve a necessidade
de chamar este processo dentro de um processo externo que fazia um loop em
certa massa de dados. Além disso, como vários pontos do processo usavam
tabelas temporárias, não era possível fazer truncate de nenhuma tabela, pois este
comando gera um commit implícito que esvazia todas as tabelas temporárias da
sessão (exceto as on commit preserve rows, o que não é o caso).
Enfim, o efeito colateral desta modelagem é que antes de cada chamada

da procedure era necessário fazer um delete desta temporária. E, embora o fato
das tabelas temporárias serem minimamente logadas, ou seja, gerarem o mínimo
de undo, elas geram redo e redo gera undo. Além disso, a operação de delete é
uma daquelas que mais gera undo e redo nas temporárias. No fim das contas, o
problema de performance que encontrávamos neste processo se devia ao excessivo
uso de redo e undo logs. A solução, para não quebrar a compatibilidade com o
código existente, foi criar parametros opcionais para que a procedure aceitasse
também arrays como metodo de passagem de valores.
A alteração teve um resultado extremamente positivo, resultando no ganho

de até 40% no desempenho da procedure em questão.
Sei que estas dicas são meio vagas sem um caso de estudo acompanhando,
portanto em breve espero postar dois casos simples reproduzindo estas situações
que comentei. Fiquem ligados!
FONTE: Disponível em: <http://oraculodosul.blogspot.com.br/2011/11/performance-com-plsql.

html>. Acesso em: 6 fev. 2013.
184
RESUMO DO TÓPICO 3
• Para complementar o gerenciamento e manipulação de dados existem outras

estruturas de dados como índices, sequences e views.
• Índices servem exclusivamente para questões relacionadas à recuperação de

dados em um banco de dados. Tem um grande compromisso com a performance,
ou seja, o rápido retorno na solicitação de algum dado.
• PL/SQL é uma linguagem procedural utilizada pelo Oracle para permitir a criação
de rotinas com características idênticas à de uma linguagem de programação.
Ficam armazenadas e são executadas no servidor de banco de dados.
• Triggers são funções que são chamadas automaticamente durante a alteração de

dados em tabelas conforme a sua programação.
185
AUTOATIVIDADE
1 Defina o que é uma sequence em um banco de dados.
2 O que é uma view?
3 De acordo com o que foi estudado, descreva o que é PL/SQL.
4 Qual é a principal diferença entre procedures e functions?
5 O que é uma trigger e quando ela é executada?
186
REFERÊNCIAS
DATE, Christophe J.. Introdução a sistemas de bancos de dados. 8. ed. São
Paulo: Elsevier, 2003.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed.

São Paulo: Pearson, 2011.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Instituto de

informática da UFRGS, 2001.
KORTH, Henry F.; SILBERSCHATZ, Abraham. Sistemas de bancos de dados. 2.

ed. São Paulo: Makron Books, 1995.
MACHADO, F. N. R. Projeto de banco de dados: uma visão prática. São Paulo:

Érica, 2009.
__________. Banco de dados: projeto e implementação. São Paulo: Érica, 2004.
MILANI, André. MySQL: Guia do pogramador. São Paulo: Novatec, 2007.
MORELLI, Eduardo M. Terra. Oracle 8: SQL, PL/SQL e Administração. São

Paulo: Érica, 2000.
ROB, Peter; CORONEL, Carlos. Sistemas de banco de dados: Projeto,

implementação e administração. São Paulo: Cengage Learning, 2011.
SIEBRA. Sandra de Albuquerque. Banco de dados. v. 2, Recife: UFRPE, 2010.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de

banco de dados. 5. ed. São Paulo: Campus, 2006.
187
ANOTAÇÕES
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
188
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
189

Principio Banco de Dados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Principio Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Princípios de Banco

Prof. Décio Lehmkuhl

Revisão, Diagramação e Produção:

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

ISBN 978-85-7830- 684-7

A sociedade vive em torno de dados. Sua conta de energia elétrica,

Pense em um documento pessoal, por exemplo, o seu CPF. Ele deve

Isso pode tornar o conteúdo desta disciplina muito interessante.

Sendo assim, temos muito para aprender! Bons estudos!

Prof. Décio Lehmkuhl

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

TÓPICO 1 – INTRODUÇÃO A BANCO DE DADOS ..................................................................... 3

TÓPICO 2 – EVOLUÇÃO DOS BANCOS DE DADOS .................................................................. 27

TÓPICO 3 – TENDÊNCIAS E PERSPECTIVAS ................................................................................ 45

UNIDADE 2 – MODELAGEM DE DADOS ....................................................................................... 71

TÓPICO 1 – MODELOS DE DADOS .................................................................................................. 73

TÓPICO 2 – MODELO ENTIDADE-RELACIONAMENTO .......................................................... 83

TÓPICO 3 – TIPOS DE RELACIONAMENTOS ............................................................................... 93

TÓPICO 4 – MODELO RELACIONAL ............................................................................................... 101

TÓPICO 5 – NORMALIZAÇÃO DE DADOS ................................................................................... 111

UNIDADE 3 – SQL .................................................................................................................................. 123

TÓPICO 1 – INTRODUÇÃO À LINGUAGEM SQL ........................................................................ 125

TÓPICO 2 – MANUTENÇÃO DOS DADOS .................................................................................... 147

TÓPICO 3 – OUTRAS ESTRUTURAS DE DADOS ......................................................................... 169

• apresentar o que é um banco de dados;

• demonstrar como foi a evolução dos bancos de dados;

• apresentar perspectivas e tendências desta tecnologia.

TÓPICO 1 – INTRODUÇÃO A BANCO DE DADOS

TÓPICO 2 – EVOLUÇÃO DOS BANCOS DE DADOS

TÓPICO 3 – TENDÊNCIAS E PERSPECTIVAS

INTRODUÇÃO A BANCO DE DADOS

Esse tópico tem como objetivo apresentar ao(a) acadêmico(a) conceitos de

FIGURA 1 – DADO, INFORMAÇÃO E CONHECIMENTO

Também será abordado um histórico do gerenciamento dos dados. O

Para fins conclusivos, veremos quais são os principais bancos de dados

2 CONCEITOS DE BANCO DE DADOS

2.1 DADO E INFORMAÇÃO

FIGURA 2 – FORMULÁRIO DE COLETA DE DADOS PARA A PESQUISA

Assim que os usuários responderem à pesquisa, os dados vão sendo

FIGURA 3 – DEPÓSITO DE DADOS DA PESQUISA

Para responder a estas perguntas, precisamos fazer uma análise de todas

FIGURA 4 – INFORMAÇÕES DE PARTE DO RESULTADO DA PESQUISA

A informação gera conhecimento. Rob e Coronel (2011, p. 11) nos dizem

As informações podem ser utilizadas para tomada de decisão. No exemplo da

2.2 BANCOS DE DADOS

Um banco de dados é uma coleção de dados relacionados. Com dados,

Um banco de dados também pode ser chamado de base de dados. Os dados

Para exemplificar melhor, pense em um sistema de vendas de ingressos

Para simplificar a definição, podemos dizer que o minimundo é tudo o que

FIGURA 5 – CONCEITO DE MINIMUNDO

Bancos de dados existem normalmente para serem utilizados por aplicações.

FIGURA 6 – SGDB E SEU UNIVERSO

FONTE: Disponível em: <http://www.devmedia.com.br/conceitos-fundamentais-

Detalhes do funcionamento e filosofias do SGDB serão vistos em tópicos

3 HISTÓRICO DO GERENCIAMENTO DOS DADOS

Voltando no tempo, quando a informática estava dando seus primeiros

Para evidenciar de forma mais clara essa ideia, considere a seguinte

Esse acontecimento faz com que seja necessário um sistema de computador.

De uma forma resumida, podemos dizer que existiam programas de

FIGURA 7 – GERENCIAMENTO DE DADOS EM SISTEMA DE ARQUIVOS

Seguindo essa linha, podemos concluir que se a estrutura de dados de

Esse problema é conhecido pelo nome de dependência estrutural, em que