Prévia do material em texto
2013
PrincíPios de Banco
de dados
Prof. Décio Lehmkuhl
Prof. Djayson Roberto Eger
Copyright © UNIASSELVI 2013
Elaboração:
Prof. Décio Lehmkuhl
Prof. Djayson Roberto Eger
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:
III
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!
Prof. Décio Lehmkuhl
Prof. Djayson Roberto Eger
IV
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!
UNI
Olá acadêmico! Para melhorar a qualidade dos
materiais ofertados a você e dinamizar ainda mais
os seus estudos, a Uniasselvi disponibiliza materiais
que possuem o código QR Code, que é um código
que permite que você acesse um conteúdo interativo
relacionado ao tema que você está estudando. Para
utilizar essa ferramenta, acesse as lojas de aplicativos
e baixe um leitor de QR Code. Depois, é só aproveitar
mais essa facilidade para aprimorar seus estudos!
UNI
V
VI
VII
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
LEITURA COMPLEMENTAR .............................................................................................................. 41
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
sumário
VIII
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
LEITURA COMPLEMENTAR .............................................................................................................. 65
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
LEITURA COMPLEMENTAR .............................................................................................................. 77
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
LEITURA COMPLEMENTAR .............................................................................................................. 90
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
IX
4.3 CHAVE ALTERNATIVA ................................................................................................................ 105
LEITURA COMPLEMENTAR .............................................................................................................. 106
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
LEITURA COMPLEMENTAR .............................................................................................................. 141
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
LEITURA COMPLEMENTAR .............................................................................................................. 164
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
X
3 PL/SQL ................................................................................................................................................... 177
3.1 PROCEDURES ................................................................................................................................. 178
3.2 FUNCTION ...................................................................................................................................... 179
3.3 PACKAGES ....................................................................................................................................... 180
3.4 TRIGGERS ........................................................................................................................................ 181
LEITURA COMPLEMENTAR .............................................................................................................. 183
RESUMO DO TÓPICO 3 ....................................................................................................................... 185
AUTOATIVIDADE ................................................................................................................................ 186
REFERÊNCIAS ........................................................................................................................................ 187
1
UNIDADE 1
FUNDAMENTOS DE BANCO
DE DADOS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
Esta unidade tem por objetivos:
• apresentaro que é um banco de dados;
• demonstrar como foi a evolução dos bancos de dados;
• apresentar perspectivas e tendências desta tecnologia.
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
2
3
TÓPICO 1
UNIDADE 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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
4
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
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
5
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
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
6
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.
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.
DICAS
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.
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
7
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
8
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 pastase 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”.
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
9
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
10
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.
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
11
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
12
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 maisresumida, 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
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
13
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
14
• 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.
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
15
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
16
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.
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
17
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.
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 baixoní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>.
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
18
5.3 POSTGRESQL
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>.
É 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.
Leia a seguir um texto retirado do site da comunidade brasileira de
PostgreSql.
UNI
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
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
19
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
20
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>)
Sitenacional (<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.
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
21
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
22
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.
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.
UNI
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:
LEITURA COMPLEMENTAR
TÓPICO 1 | INTRODUÇÃO A BANCO DE DADOS
23
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)
24
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.
25
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 relacionaisdisponí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)?
AUTOATIVIDADE
26
27
TÓPICO 2
EVOLUÇÃO DOS BANCOS DE DADOS
UNIDADE 1
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!
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
28
2 HISTÓRICO DA EVOLUÇÃO DOS BANCOS DE DADOS
2.1 PRIMEIRA GERAÇÃO
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.
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
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.
PAI
FILHO FILHO FILHO
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
29
FIGURA 14 – ESTRUTURA DE UM BANCO DE DADOS HIERÁRQUICO
FONTE: Os autores
A figura a seguir demostra a estrutura dos dados que estão na figura
anterior.
FONTE: Os autores
FIGURA 15 – ESTRUTURA DE DADOS DA FIGURA 14
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.
RAIZ
RAIZ
Marcos Silva
NOME CPF
Nº CONTA Nº CONTASALDO SALDO
CPFNOME
João Trindade469.206.617-21 227.428.671-04
R$ 150,00R$ 700,0070948 12496
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
30
FIGURA 16 – ESTRUTURA DE DADOS NO MODELO REDE
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).
Marcos Silva
João Trindade
469.206.617-21
227.428.671-04 R$ 150,00
R$ 700,0070948
12496
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
31
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 podeter 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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
32
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.
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
33
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.
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.
IMPORTANT
E
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?
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
34
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.
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
35
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
3.1 ARQUITETURA CENTRALIZADA
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
parabancos 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.
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
36
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.
Veremos nos próximos tópicos a evolução das arquiteturas centralizadas.
ESTUDOS FU
TUROS
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
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
37
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)
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.
ESTUDOS FU
TUROS
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.
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
38
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.
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
39
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
FONTE: Rob e Coronel (2011, p. 503)
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.
Veja o quadro a seguir, que mostra as vantagens e desvantagens desse modelo
de arquitetura.
NOTA
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
40
QUADRO 1 – VANTAGENS E DESVANTAGENS DE BANCOS DE DADOS DISTRIBUÍDOS
Vantagens
Os dados ficam localizados próximo do local de
maior demanda. Os dados em um sistema de
banco de dados distribuído são dispersos para
atender às necessidades comerciais.
Maior rapidez de acesso aos dados. Os
usuários finais costumam trabalhar apenas
com um subconjunto dos dados da empresa,
armazenado localmente.
Maior rapidez de processamento de dados. Um
sistema de gerenciamento de banco de dados
distribuídos divide a carga de trabalho do
sistema, processando dados em vários locais.
Facilidade de ampliação. É possível adicionar
novos locais à rede sem afetar as operações de
outros locais.
Aprimoramento das comunicações. Como os
sites locais são menores e mais próximos dos
clientes, promovem melhor comunicação entre
os departamentos e entre os clientes e a equipe
da empresa.
Custos operacionais reduzidos. Do ponto de
vista dos custos, é mais eficiente adicionar
estações de trabalho a uma rede do que
atualizar um sistema de mainframe. O trabalho
de desenvolvimento é feito de modo mais
rápido e barato em PCs de baixo custo do que
em mainframes.
Interface amigável. Os PCs e as estações de
trabalho costumam ser equipados com interface
gráfica de usuário (GUI) fácil de usar. A GUI
simplificao treinamento e utilização dos usuários
finais.
Menor risco de falha em ponto único. Quando
um componente dos computadores falha, o
trabalho é mantido por outras estações. Os
dados também são distribuídos em vários
locais.
Independência do processador. O usuário final
é 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.
Desvantagens
Complexidade de gerenciamento e controle. As
aplicações devem reconhecer a localização dos
dados e ter a capacidade de integrá-los a partir de
vários locais. É necessário que os administradores
tenham capacidade de coordenar as atividades
do banco de dados, evitando sua degradação em
função de anomalias.
Dificuldade tecnológica. É necessário tratar
e solucionar a integridade dos dados,
o gerenciamento de transações, o controle
de concorrência, o backup, a recuperação, a
otimização de consultas, a seleção do caminho
de acesso etc.
Segurança. A probabilidade de falhas de
segurança aumenta quando os dados são
armazenados em vários locais. A responsabilidade
do gerenciamento dos dados será compartilhada
por diferentes pessoas em diversos locais.
Falta de padrões. Não há protocolos de
comunicação padronizados no nível de banco
de dados. (Embora o TCP/IP seja, na prática, um
padrão no nível de rede, não há padronização
no nível de aplicação.) Por exemplo, diferentes
fornecedores de banco de dados empregam
técnicas diferentes e geralmente incompatíveis
de gerenciamento da distribuição de dados e
processamento no ambiente de SGBDD.
Ampliação das necessidades de armazenamento
e infraestrutura. São necessárias várias cópias
de dados em diferentes locais, exigindo, assim,
espaço adicional de armazenamento em disco.
Aumento de custos com treinamento. Os custos
com treinamento costumam ser mais elevados em
modelos distribuídos do que em centralizados,
às vezes a ponto de compensar as economias
operacionais e de hardware.
Custos. Os bancos de dados distribuídos exigem
infraestrutura duplicada para operar (localização
física, ambiente, pessoal, software, licenciamento
etc.).
FONTE: Rob e Coronel (2011, p. 502)
TÓPICO 2 | EVOLUÇÃO DOS BANCOS DE DADOS
41
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.
LEITURA COMPLEMENTAR
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
42
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.
43
RESUMO DO TÓPICO 2
Neste tópico, você viu que:
• 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.
44
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.
AUTOATIVIDADE
45
TÓPICO 3
TENDÊNCIAS E PERSPECTIVAS
UNIDADE 1
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 apontadascomo 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!
46
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
2 CLASSIFICAÇÃO DOS BANCOS DE DADOS
2.1 BANCOS DE DADOS DE INFORMAÇÕES GEOGRÁFICAS
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.
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
47
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.
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.
UNI
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.
48
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
49
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.
O texto a seguir detalha a necessidade e a motivação para a recuperação baseada
em semelhança.
UNI
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.
50
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
A noção desemelhanç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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
51
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.
O site <http://pt.scribd.com/doc/58841709/Banco-de-Dados-biologico> traz
alguns exemplos de bancos de dados biológicos.
UNI
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.
52
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
53
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.
54
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
55
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.
56
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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.
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.
UNI
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
57
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.
58
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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.
Tudo é feito para melhorar a tomada de decisão das empresas. O texto a seguir
mostra como isso é possível.
UNI
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
59
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 é
traduzidaem 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.
60
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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
3.4 DATA MARKETING
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.
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.
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.
UNI
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
61
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.
62
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
63
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.
UNI
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ênciaem 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.
64
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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.
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.
UNI
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
65
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.
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.
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
LEITURA COMPLEMENTAR
66
UNIDADE 1 | FUNDAMENTOS DE BANCO DE DADOS
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 cadacaso.
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.
TÓPICO 3 | TENDÊNCIAS E PERSPECTIVAS
67
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.
68
RESUMO DO TÓPICO 3
Neste tópico, você viu que:
• 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.
69
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?
AUTOATIVIDADE
70
71
UNIDADE 2
MODELAGEM DE DADOS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
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.
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
72
73
TÓPICO 1
MODELOS DE DADOS
UNIDADE 2
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.UNIDADE 2 | MODELAGEM DE DADOS
74
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
TÓPICO 1 | MODELOS DE DADOS
75
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.
UNIDADE 2 | MODELAGEM DE DADOS
76
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))
)
TÓPICO 1 | MODELOS DE DADOS
77
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
);
Caso você não tenha entendido o script gerado, não se preocupe, pois
abordaremos mais detalhes sobre este assunto na Unidade 3.
UNI
LEITURA COMPLEMENTAR
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)).
UNIDADE 2 | MODELAGEM DE DADOS
78
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.
TÓPICO 1 | MODELOS DE DADOS
79
FONTE: Disponível em: <http://www.fernandoans.site50.net/curso/curso06/UFPE-BancoDeDados.pdf>. Acesso em: 26 fev. 2013.
80
RESUMO DO TÓPICO 1
Neste tópico, você viu que:
• 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.
81
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.
82
83
TÓPICO 2
MODELO ENTIDADE-RELACIONAMENTO
UNIDADE 2
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.
UNIDADE 2 | MODELAGEM DE DADOS
84
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.
TÓPICO 2 | MODELO ENTIDADE-RELACIONAMENTO
85
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
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).
UNI
UNIDADE 2 | MODELAGEM DE DADOS
86
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
TÓPICO 2 | MODELO ENTIDADE-RELACIONAMENTO
87
Para que a entidade seja relevante ao projeto MER, ela deverá ter pelo menos um
ou mais atributos.
UNI
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 normalmenteseus 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:
UNIDADE 2 | MODELAGEM DE DADOS
88
• 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.
TÓPICO 2 | MODELO ENTIDADE-RELACIONAMENTO
89
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
UNIDADE 2 | MODELAGEM DE DADOS
90
LEITURA COMPLEMENTAR
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.
FONTE: Disponível em: <http://www.fernandoans.site50.net/curso/curso06/UFPE-
BancoDeDados.pdf>. Acesso em: 26 fev. 2013.
91
RESUMO DO TÓPICO 2
Neste tópico, você viu que:
• 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.
92
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?
93
TÓPICO 3
TIPOS DE RELACIONAMENTOS
UNIDADE 2
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ânciase 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
94
UNIDADE 2 | MODELAGEM DE DADOS
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.
TÓPICO 3 | TIPOS DE RELACIONAMENTOS
95
Um TIME deverá participar em pelo menos um CAMPEONATO, podendo
participar de no máximo até dois CAMPEONATOS.
3 GRAU DO RELACIONAMENTO
3.1 RELACIONAMENTO UM PARA UM
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:
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.
96
UNIDADE 2 | MODELAGEM DE DADOS
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:
TÓPICO 3 | TIPOS DE RELACIONAMENTOS
97
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:
• 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”.
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.
98
UNIDADE 2 | MODELAGEM DE DADOS
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.
99
Neste tópico, você viu que:
• 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.
RESUMO DO TÓPICO 3
100
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.
101
TÓPICO 4
MODELO RELACIONAL
UNIDADE 2
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:
102
UNIDADE 2 | MODELAGEM DE DADOS
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.
TÓPICO 4 | MODELO RELACIONAL
103
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.
104
UNIDADE 2 | MODELAGEM DE DADOS
FIGURA 47 – TABELA COM CHAVE ESTRANGEIRA
• 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.
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.
TÓPICO 4 | MODELO RELACIONAL
105
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.
Em alguns SGDB, é possível criar uma chave estrangeira referenciando uma chave
alternativa.
UNI106
UNIDADE 2 | MODELAGEM DE DADOS
LEITURA COMPLEMENTAR
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.
TÓPICO 4 | MODELO RELACIONAL
107
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.
FONTE: Disponível em: <http://www.fernandoans.site50.net/curso/curso06/UFPE-
BancoDeDados.pdf>. Acesso em: 26 fev. 2013.
108
RESUMO DO TÓPICO 4
Neste tópico, você viu que:
• 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.
109
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?
110
111
TÓPICO 5
NORMALIZAÇÃO DE DADOS
UNIDADE 2
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.
112
UNIDADE 2 | MODELAGEM DE DADOS
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.
TÓPICO 5 | NORMALIZAÇÃO DE DADOS
113
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 como 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.
114
UNIDADE 2 | MODELAGEM DE DADOS
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.
TÓPICO 5 | NORMALIZAÇÃO DE DADOS
115
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
→ Aplicação da 2FN
→ 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.
• Entidades na 2FN
→ Aplicação da 3FN
→ 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.
116
UNIDADE 2 | MODELAGEM DE DADOS
→ 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.
• Entidades na 3FN
→ 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
→ Aplicação da 5FN
→ 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.
TÓPICO 5 | NORMALIZAÇÃO DE DADOS
117
• 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/>.
118
UNIDADE 2 | MODELAGEM DE DADOS
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.
TÓPICO 5 | NORMALIZAÇÃO DE DADOS
119
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.
120
UNIDADE 2 | MODELAGEM DE DADOS
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.
121
RESUMO DO TÓPICO 5
Neste tópico, você viu que:
• 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.
122
1 O que você entendeu sobre o processo de normalização de dados?
AUTOATIVIDADE
123
UNIDADE 3
SQL
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
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.
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 À LINGUAGEMSQL
TÓPICO 2 – MANUTENÇÃO DOS DADOS
TÓPICO 3 – OUTRAS ESTRUTURAS DE DADOS
124
125
TÓPICO 1
INTRODUÇÃO À LINGUAGEM SQL
UNIDADE 3
1 INTRODUÇÃO
“Transportai um punhado de terra todos os dias e fareis uma montanha”.
(Confúcio)
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!
UNIDADE 3 | SQL
126
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.
2 O QUE É SQL
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.
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
127
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.
UNIDADE 3 | SQL
128
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.
ATENCAO
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
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
129
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.
UNIDADE 3 | SQL
130
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 paraum 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.
Tipo Descrição
char (n) Cadeia de caracteres de tamanho fixo n. O default é 1 e o máximo, 255.
varchar2(n)
Cadeia de caracteres de tamanho variável com o
máximo de n e pode ter o valor de até 4.000. Para que
duas variáveis desse tipo sejam consideradas iguais,
elas devem possuir, além do mesmo conteúdo, o mesmo
tamanho.
long
Cadeia de caracteres de tamanho variável com o
máximo de 2 gigabytes. Só pode existir um campo desse
tipo por tabela.
raw e long raw
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
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.
number(p, e)
Valores numéricos em que p indica a precisão (máximo
de 38) e indica a escala (número de casas decimais) que
varia de -84 a + 127. Por exemplo, number(5,2) especifica
um número na faixa entre -999,99 e +999,99.
date Armazena data e hora, incluindo século, ano, mês, dia, hora, minuto e segundo. Ocupam 7 bytes.
QUADRO 3 – TIPOS DE DADOS PARA CAMPOS DE TABELAS DO ORACLE
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
131
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.
UNIDADE 3 | SQL
132
FIGURA 57 – COMANDO DO EDITOR SENDO EXECUTADO
FONTE: Os autores
A partir deste momento, a tabela paciente existe no nosso banco de dados.
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 (“;”).
IMPORTANT
E
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.
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
133
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
UNIDADE 3 | SQL
134
Como pôde ser visto, a tabela paciente não existe mais na nossa base de
dados.
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.
ATENCAO
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.
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
135
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.
IMPORTANT
E
create table consulta (
nr_sequencia number(10),
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 (
nr_sequencia number(4),
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.
UNIDADE 3 | SQL
136
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_MEDICONUMBER(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.
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
137
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_SEQUENCIA NOT NULL NUMBER(10)
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);
UNIDADE 3 | SQL
138
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);
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.
ATENCAO
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).
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
139
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);
UNIDADE 3 | SQL
140
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.
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.
UNI
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
141
LEITURA COMPLEMENTAR
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 nospermite 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.
UNIDADE 3 | SQL
142
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.
TÓPICO 1 | INTRODUÇÃO À LINGUAGEM SQL
143
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.
144
RESUMO DO TÓPICO 1
Neste tópico, você viu que:
• 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.
145
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.
146
147
TÓPICO 2
MANUTENÇÃO DOS DADOS
UNIDADE 3
1 INTRODUÇÃO
“A persistência é o menor caminho do êxito.”
(Charles Chaplin).
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.
148
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
SILVAPara 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'
DICAS
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?
TÓPICO 2 | MANUTENÇÃO DOS DADOS
149
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
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
--------------------------- -------- ----------------
NR_SEQUENCIA NOT NULL NUMBER(6)
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.
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
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.
150
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.
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (1, 10, 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'))
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.
TÓPICO 2 | MANUTENÇÃO DOS DADOS
151
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.
DICAS
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.
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (5, 1, 1, to_date('04/02/2013 16:00:00', 'DD/
MM/YYYY HH24:MI:SS'), to_date('04/02/2013 15:00:00', 'DD/MM/
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.
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).
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
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.
152
UNIDADE 3 | SQL
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.
DICAS
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.
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 umrollback. Não é
possível desfazer as alterações com um rollback após ter dado um commit.
TÓPICO 2 | MANUTENÇÃO DOS DADOS
153
QUADRO 4 – FUNÇÕES DE CONVERSÃO DE DADOS DO ORACLE
Função Descrição
to_char(número ou data,
‘formato’)
Converte um campo numérico ou data em uma
cadeia de caracteres do tipo varchar2, com o
formato definido pela variável formato.
to_number(char) Converte uma cadeia de caracteres numérica em número inteiro
to_date(char, ‘formato’)
Converte uma cadeia de caracteres, especificando
uma data, no tipo date, de acordo com a variável
formato (se omitida, é assumido ‘DD-MMM-
AA’).
nvl(coluna, valor) Converte um null que encontre na coluna, em um 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.
154
UNIDADE 3 | SQL
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.
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/>.
TÓPICO 2 | MANUTENÇÃO DOS DADOS
155
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.
156
UNIDADE 3 | SQL
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.
DICAS
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.
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.
TÓPICO 2 | MANUTENÇÃO DOS DADOS
157
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.
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (1, ‘Marcio Silva’, ‘16834865101’, ‘(47)89899999’);
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (2, ‘Juca Pedro’, ‘76820503903’, ‘(47)89748596’);
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (3, ‘Maria Quadros’, ‘62052125442’,
‘(47)12256897’);
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (4, ‘Pedro Almeida’, ‘84828752137’,
‘(47)89452541’);insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (5, ‘Josiane Silva’, ‘38145048524’,
‘(49)58574859’);
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (6, ‘Marcos Rocha’, ‘30305222619’, ‘(51)37865247’);
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (7, ‘Tiago Prado’, ‘18131028640’, ‘(39)85697454’);
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (8, ‘Augusto Pereira’, ‘03660633321’,
‘(41)45859687’);
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (9, ‘Priscila Chaves’, ‘67742258706’,
‘(45)25417896’);
158
UNIDADE 3 | SQL
insert into paciente (nr_sequencia, nm_paciente, cpf_
paciente, fone_paciente)
values (10, ‘Marta Campos’, ‘43407732805’,
‘(49)65897485’);
insert into medico (nr_sequencia, nm_medico, crm_medico,
cpf_medico, fone_medico)
values (1, ‘Jader Fonseca’, ‘1002365’, ‘94269268018’,
‘(99) 12438080’);
insert into medico (nr_sequencia, nm_medico, crm_medico,
cpf_medico, fone_medico)
values (50, ‘Fernando Ferreira’, ‘105263’, ‘56624682736’,
‘(45) 58996452’);
insert into medico (nr_sequencia, nm_medico, crm_medico,
cpf_medico, fone_medico)
values (51, ‘Marleide Benta’, ‘1089745’, ‘21764632184’,
‘(48) 49564586’);
insert into medico (nr_sequencia, nm_medico, crm_medico,
cpf_medico, fone_medico)
values (52, ‘Cabral Rodrigues’, ‘2035698’, ‘13167468106’,
‘(44) 89745214’);
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
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’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (101, 10, 50, to_date(‘05/02/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘05/02/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (102, 9, 51, to_date(‘10/02/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘10/02/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
TÓPICO 2 | MANUTENÇÃO DOS DADOS
159
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (103, 8, 52, to_date(‘04/02/2013 11:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘04/02/2013 12:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (104, 7, 1, to_date(‘20/02/2012 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘20/02/2012 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (105, 6, 50, to_date(‘11/04/2013 16:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘11/04/2013 17:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (106, 4, 51, to_date(‘13/06/2013 17:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘13/06/2013 18:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (107, 5, 52, to_date(‘14/09/2012 14:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘14/09/2012 15:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (108, 2, 1, to_date(‘24/01/2011 13:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘24/01/2011 14:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (109, 1, 50, to_date(‘07/04/2013 15:30:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘07/04/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (110, 3, 1, to_date(‘08/11/2010 13:30:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘08/11/2010 14:30:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
160
UNIDADE 3 | SQL
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (111, 3, 50, to_date(‘02/12/2012 19:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘02/12/2012 20:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (112, 2, 1, to_date(‘05/03/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘05/03/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (113, 1, 52, to_date(‘19/07/2012 15:30:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘19/07/2012 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (114, 5, 1, to_date(‘11/01/2013 14:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘11/01/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (115, 1, 51, to_date(‘28/04/2013 13:40:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘28/04/2013 15:20:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (116, 1, 1, to_date(‘10/08/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘10/08/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (117, 1, 50, to_date(‘09/02/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘09/02/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (118, 1, 1, to_date(‘27/11/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘27/11/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
TÓPICO 2 | MANUTENÇÃO DOS DADOS
161
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (119, 1, 52, to_date(‘09/05/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘09/05/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
insert into consulta (nr_sequencia, nr_seq_paciente,
nr_seq_medico, dt_hora_inicio, dt_hora_fim)
values (120, 1, 1, to_date(‘14/05/2013 15:00:00’, ‘DD/
MM/YYYY HH24:MI:SS’), to_date(‘14/05/2013 16:00:00’, ‘DD/MM/
YYYY HH24:MI:SS’));
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.
162
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_pacientefrom 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
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
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.
TÓPICO 2 | MANUTENÇÃO DOS DADOS
163
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
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
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.
164
UNIDADE 3 | SQL
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:
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.
UNI
LEITURA COMPLEMENTAR
TÓPICO 2 | MANUTENÇÃO DOS DADOS
165
SELECT id, nome, sobrenome FROM autores WHERE nome =
‘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:
SELECT id, nome, sobrenome FROM autores WHERE nome =
‘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.
166
RESUMO DO TÓPICO 2
Neste tópico, você viu que:
• 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.
167
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?
168
169
TÓPICO 3
OUTRAS ESTRUTURAS DE DADOS
UNIDADE 3
1 INTRODUÇÃO
“Não são as ervas más que afogam a boa semente,
e sim a negligência do lavrador”. (Confúcio)
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!
UNIDADE 3 | SQL
170
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);
TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS
171
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.
UNI
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.
UNIDADE 3 | SQL
172
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
sequencia Nome da sequência que não pode ser o nome de uma tabela ou view.
increment by n Especifica de quanto será o incremento ou decremento da sequência. O default é 1.
start with n Especifica o primeiro número a ser gerado. O default é 1.
maxvalue n Especifica o valor máximo que a sequência pode assumir. O default é nomaxvalue, indo até 1027.
TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS
173
FONTE: Morelli (2000, p. 73)
minvalue n
Especifica o valor mínimo para sequências que estejam
sendo decrementadas. É mutuamente exclusiva à
anterior.
cycle | nocycle
Indica que, quando atingir o valor máximo, a
numeração continuará a partir do valor inicial. O
default é nocycle.
cache n | nocache Especifica quantos valores o Oracle pré-aloca e mantém em memória. O default é 20.
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
UNIDADE 3 | SQL
174
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.
DICAS
Segue o exemplo de um comando insert utilizando a sequence criada.
insert into paciente (nr_sequencia, nm_paciente, cpf_
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.
O texto a seguir compara o comportamento de uma sequence no Oracle com os
recursos que outros bancos de dados disponibilizam.
UNI
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
TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS
175
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.
FONTE: Rob e Coronel (2011, p. 352)
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.
UNIDADE 3 | SQL
176
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 é:
TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS
177
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.
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.
ATENCAO
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.
UNIDADE 3 | SQL
178
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ódigofundamental 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;
TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS
179
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')
where nr_sequencia = p_consulta;
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
where nr_sequencia = p_consulta;
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);
UNIDADE 3 | SQL
180
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;
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.
ATENCAO
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
TÓPICO 3 | OUTRAS ESTRUTURAS DE DADOS
181
-- 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.
UNIDADE 3 | SQL
182
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.
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.
UNI
TÓPICO 3 | OUTRAS ESTRUTURASDE DADOS
183
LEITURA COMPLEMENTAR
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.
UNIDADE 3 | SQL
184
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.
185
Neste tópico, você viu que:
• 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.
RESUMO DO TÓPICO 3
186
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?
187
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.
188
ANOTAÇÕES
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
________________________________________________________________________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
189
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________Mais conteúdos dessa disciplina
Avaliação da Disciplina - Arquitetura Big Data- (31)994408961- RESOLVIDO-Aula pratica Bancos de dados nao relacionaisAula pratica Bancos de dados nao relacionais
- (31)994408961- RESOLVIDO- Aula Pratica Programacao e Desenvolvimento de Banco de Dados
- (31)994408961- RESOLVIDO- Aula Pratica Banco de dados em nuvem
- Avaliação I - Individual
- Avaliação II - Individual
- Resumo de Questões sobre ETL e Análise de Dados
- Mapa Mental - MySQL Básico
- Cinco caixas de carga (C1, C2, C3, C4, C5) devem ser carregadas em sequência em uma aeronave. Qual é a ordem correta de carregamento? R E STR I Ç ÕE S
- Dashboards são ferramentas importantes em Business Intelligence porque: 1. Fornecem uma visão detalhada dos dados em cubos multidimensionais. 2. Possi
- No processamento paralelo, qual tipo de arquitetura utiliza vários processadores para executar a mesma operação em diferentes partes de um conjunto...
- Durante uma partida de tênis crucial, uma tenista de alto rendimento começa a cometer erros não característicos. Ela acerta bolas fora da quadra, erra
- Considere o sistema de banco de dados MongoDB, que possui uma base de dados chamada Produtos. Marque a alternativa que corretamente realiza a inse...
- Sobre bancos de dados SQL e NoSQL, analise as afirmativas a seguir e assinale-as com V (verdadeiro) ou F (falso): ( ) O NoSQL nem sempre é a mel...
- Em relação às características de banco de dados NoSQL, analise as alternativas a seguir e marque a opção verdadeira: Grupo de escolhas da pergunta Tod
- O pensamento visual em comunicação de dados é importante, entre outras coisas porque: a. Substitui completamente os números por imagens, sem perder si
- Qual é o principal propósito do storytelling de dados na comunicação de informações complexas? a. Transformar dados técnicos em narrativas que despert
- A arquitetura de processamento de dados distribuída exige uma série de componentes e tecnologias para garantir que os dados sejam processados de ma...
- s componentes do Spark (2.0 ou superior) têm como objetivo facilitar o desenvolvimento de projetos com finalidades específicas. Nesse sentido, sele...
- create create 4 create create 7 8 9 10 11 12 13 14 15 16 17 18 19 20 O feedback negativo, quando na devolutiva de uma avaliação de desempenho, deve...
- Qual das seguintes afirmações melhor descreve a diferença entre dados estruturados e não estruturados? Alternativas: Dados estruturados e não estrutur
- Manual Instalação e Configuração do Driver Godex EZ320 Vs1 0
- Ai_gestao_projetos_FGV (1)
