Você está na página 1de 54

CAPITULO 21

Apoio deciso
INTRODUO
Nota: David McGoveran foi o autor original deste captulo.
Os sistemas de apoio deciso so sistemas que ajudam na
anlise de informaes do negcio. Sua meta ajudar a
administrao a definir tendncias, apontar problemas e
tomar... decises inteligentes [21.71. As razes de tais
sistemas pesquisa operacional, teorias comportamentais e
cientficas de gerncia e controle de processos estatsticos
surgiram no final da dcada de 1940 e no incio da dcada
de 1950, bem antes dos computadores se tornarem disponveis
de modo geral. A idia bsica era, e claro que ainda ,
coletar dados operacionais do negcio (consulte o Captulo 1)
e reduzi-los a uma forma que pudesse ser usada para analisar
o comportamento do negcio e modificar esse comportamento de
maneira inteligente. Por razes bastante bvias, a extenso
em que os dados eram reduzidos nesses tempos iniciais era
mnima, naturalmente, e em geral envolvia pouco mais que a
gerao de relatrios simples de totalizao.
No final dos anos sessenta e no incio dos anos setenta,
pesquisadores de Harvard e do MIT comearam a promover o uso
de computadores para ajudar no processo de tomada de decises
[21.231. A princpio, esse uso era limitado (principalmente)
a automatizar a tarefa de gerao de relatrios, embora
recursos analticos rudimentares tambm fossem fornecidos s
vezes [21.2 e 21.3, 21.6, 21.261. Esses primeiros sistemas de
computadores ficaram conhecidos inicialmente como sistemas de
decises gerenciais; mais tarde, eles tambm se tornaram
conhecidos como sistemas de informaes gerenciais.
Preferimos a expresso mais moderna sistema de apoio
deciso, porm, como possvel considerar todos os sistemas
de informao inclusive, por exemplo, os sistemas OLTP
(online transaction processing) podem ou devem ser
considerados como `sistemas de informaes gerenciais
(afinal, todos eles esto relacionados com a gerncia do
negcio e a influenciam). Ficaremos com o termo mais moderno
no texto a seguir.
A dcada de 1970 tambm viu o desenvolvimento de vrias
linguagens de consulta, e vrios sistemas personalizados
(internos) de apoio deciso foram construdos ao redor
dessas linguagens. Eles foram implementados com o uso de
geradores de relatrios como RPG ou produtos de busca de
dados como Focus, Datatrieve e NOMAD. Esses sistemas foram os
primeiros a permitir que usurios finais com conhecimentos
adequados tivessem acesso direto a depsitos de dados de
computadores; isto , eles permitiam que usurios formulassem
consultas relacionadas com o negcio sobre esses depsitos de
dados e executassem essas consultas diretamente, sem terem de
esperar pela ajuda do departamento de IT.
claro que os depsitos de dados apenas se referiam em sua
maioria a arquivos de dados bastante simples a maior parte
dos dados comerciais da poca eram mantidos em tais arquivos,
ou possivelmente em bancos de dados no relacionais (os
sistemas relacionais ainda estavam nos domnios da pesquisa).
598 Mesmo no ltimo caso, em geral os dados tinham de ser
extrados do banco de dados e copiados em arquivos antes de
se tornarem acessveis por um sistema de apoio deciso.
Somente no incio dos anos oitenta, os bancos de dados
relacionais comearam a ser usados em lugar de arquivos
simples para fins de apoio deciso. De fato, o apoio
deciso, a consulta ad hoc e a gerao de relatrios estavam
entre os primeiros usos comerciais da tecnologia relacional.
Embora os produtos de SQL estejam agora amplamente
disponveis, a idia de processamento de extrao isto ,
copiar dados do ambiente operacional para algum outro
ambiente continua a ser muito importante; ele permite que
os usurios operem sobre os dados extrados da maneira que
desejarem, sem interferirem mais com o ambiente operacional.
E, claro, a razo para a execuo de tais extraes com
muita frequncia o apoio deciso.
Devia ficar claro a partir do breve histrico anterior que o
apoio deciso na realidade no faz parte da tecnologia de
bancos de dados em si. Em vez disso, ele um uso dessa
tecnologia (embora um uso importante) ou, para sermos mais
precisos, corresponde a vrios usos, distintos mas
entrelaados. Os usos em questo respondem pelos nomes de
data warehouse, data mart, depsito de dados operacionais,
processamento analtico on-line (OLAP), bancos de dados
multidimensionais e minerao de dados (entre outros).
Discutiremos todos esses tpicos nas sees seguintes.
Cuidado: observamos de imediato que algo que todas essas
reas tm em comum que os princpios do bom projeto lgico
raramente so seguidos em qualquer uma delas! A prtica de
apoio deciso, lamentavelmente, no to cientfica quanto
poderia ser; de fato, frequentemente, ela bastante ad hoc.
Em particular, tende a ser orientada muito mais por
consideraes fsicas que por consideraes lgicas (na
verdade, a distino entre questes fsicas e lgicas
muitas vezes bastante indistinta no ambiente de apoio
deciso). Em parte por essas razes, empregamos neste
captulo a SQL, e no Tutorial D, como a base para nossos
exemplos, e utilizamos a terminologia de SQL mais
complicada de linhas, colunas e tabelas, em lugar de nossa
terminologia preferida de tuplas, atributos e valores de
relaes, e ainda de variveis (variveis de relaes). Alm
disso, usaremos as expresses esquema lgico e esquema fsico
como sinnimos para aquilo que chamamos no Captulo 2 esquema
conceitual e esquema interno, respectivamente.
Ento, o plano do captulo o seguinte. Na Seo 2 1.2,
discutiremos certos aspectos de apoio deciso que motivaram
determinadas prticas de projeto que acreditamos estarem um
tanto mal orientadas. A Seo 21.3 descreve nossa abordagem
preferida para lidar com esses aspectos. A Seo 21.4 examina
ento a questo de preparao de dados (isto , o processo de
obter dados operacionais em uma forma tal que eles possam ser
teis para fins de apoio deciso); ela tambm considera
rapidamente os depsitos de dados operacionais. A Seo
21.5 discute os data warehouses, os data marts e os esquemas
dimensionais. A Seo 21.6 explora o processamento analtico
on-line (OLAP) e bancos de dados multidimensionais. A Seo
21.7 discute a minerao de dados. A Seo 21.8 apresenta um
resumo.
21.2 ASPECTOS DO APOIO DECISO
Os bancos de dados de apoio deciso exibem certas
caractersticas especiais, das quais a mais importante : o
banco de dados principalmente (embora no totalmente)
apenas de leitura. A atualizao que existe limitada em
geral a operaes peridicas de carga ou renovao (refresh)
(e essas operaes por sua vez so dominadas por operaes
INSERT as operaes DELETE so feitas ocasionalmente e as
operaes UPDATE quase nunca). Nota: s vezes, a atualizao
feita sobre certas tabelas de trabalho auxiliares, mas os
processos normais de apoio deciso quase nunca atualizam o
banco de dados de apoio deciso propriamente dito.
As caractersticas adicionais a seguir dos bancos de dados de
apoio deciso tambm merecem ser examinadas (voltaremos a
nos aprofundar sobre elas na Seo 21.3). Observe que as trs
primeiras tm natureza lgica, enquanto as trs ltimas so
fsicas.
- Colunas tendem a ser usadas em combinao.
- Em geral, a integridade no uma preocupao (supe-se que
os dados esto corretos quando
so carregados pela primeira vez e no so atualizados
subsequentemente). 599
- As chaves frequentemente incluem um componente temporal
(consulte o Captulo 22).
- O banco de dados tende a ser grande (especialmente onde
como ocorre com frequncia os detalhes de transaes* de
negcios se acumulam com o tempo).
- O banco de dados tende a estar fortemente indexado.
- O banco de dados envolve frequentemente vrios tipos de
redundncia controlada (consulte o Captulo 1).
As consultas de apoio deciso tambm exibem caractersticas
especiais; em particular, elas tendem a ser bastante
complexas. Aqui esto alguns tipos de complexidades que podem
surgir:
- Complexidade de expresso booleana: as consultas de apoio
deciso frequentemente envolvem expresses complexas na
clusula WHERE expresses difceis de escrever, difceis de
entender, e difceis para que o sistema possa lidar com elas
de forma adequada. (Em particular, os otimizadores clssicos
tendem a ser inadequados, porque so projetados para avaliar
apenas um nmero limitado de estratgias de acesso.) Um
problema comum o das consultas que envolvem o fato tempo;
normalmente, os sistemas atuais no fornecem um bom suporte
para, por exemplo, consultas que solicitam linhas com um
valor de timbre de hora mximo em um perodo de tempo
especificado (mais uma vez, consulte o Captulo 22). Se
houver quaisquer junes, essas consultas rapidamente se
tornaro de fato muito complexas. O resultado final em todos
esses casos ser, claro, um desempenho fraco.
- Complexidade de juno: as consultas de apoio deciso
frequentemente exigem acesso a muitos tipos de fatos. Como
consequncia, em um banco de dados corretamente projetado
isto , totalmente normalizado essas consultas em geral
envolvem muitas junes. Infelizmente, a tecnologia de
processamento de junes nunca procurou se manter em dia com
as demandas crescentes de consultas de apoio deciso.**
Assim ,muitas vezes, os projetistas decidem desnormalizar o
banco de dados, desfazendo a juno de certas tabelas.
Porm, como vimos no Captulo 12 (na Seo 12.5), essa
abordagem raramente bem-sucedida, quase sempre causando
tantos problemas quantos os que resolve. Alm disso, o desejo
de evitar junes tambm pode levar ao uso ineficiente de
operaes relacionais, com grandes quantidades de dados sendo
retornadas e o processamento de junes sendo feito dentro da
aplicao, em vez de ser realizado no SGBD.
- Complexidade de funo: as consultas de apoio deciso
frequentemente envolvem funes estatsticas e outras funes
matemticas. Poucos produtos tm suporte para tais funes.
Como resultado, muitas vezes necessrio desmembrar uma
consulta em uma sequncia de consultas menores, as quais so
ento executadas intercaladas com procedimentos escritos pelo
usurio que calculam as funes desejadas. Essa abordagem tem
a consequncia desafortunada de que grandes quantidades de
dados podem precisar ser retornadas; alm disso, claro que
ela torna muito mais difcil escrever e entender a consulta
global.
- Complexidade analtica: as questes de negcios raramente
so respondidas em uma nica consulta. No apenas difcil
para os usurios escrever consultas de complexidade extrema,
mas limitaes de implementaes de SQL podem impedir que uma
tal consulta seja processada. Um modo de reduzir a
complexidade dessas consultas (novamente) desmembr-las em
uma srie de consultas menores, mantendo resultados
intermedirios em tabelas auxiliares.
* Aqui e ao longo deste captulo faremos distino entre
transaes de negcios (por exemplo, venda de um produto) e
transaes no sentido da Parte IV deste livro, empregando
sempre o qualificador de negcios quando se tratar de uma
transao de negcios (a menos que o contexto torne o
significado bvio).
** O autor (McGoveran), trabalhando em sistemas de apoio
deciso desde 1981, observou que uma juno de trs tabelas,
mesmo de tamanho moderado, poderia levar facilmente vrias
horas. Junes de quatro a seis tabelas eram em geral
consideradas muito dispendiosas. Hoje, junes de seis a dez
tabelas muito grandes so comuns, e normalmente a tecnologia
funciona bem. No entanto, ainda fcil (e no incomum) gerar
consultas que juntam mais tabelas que a tecnologia pode
tratar de modo razovel. Consultas que renem mais de doze
tabelas podem se tornar rapidamente uma aventura e ainda
assim a exigncia
600 dessas consultas algo comum!
Todas as caractersticas precedentes, tanto as de bancos de
dados de apoio deciso quanto as de consultas de apoio
deciso, conduzem a uma forte nfase sobre o projeto visando
o desempenho em especial, o desempenho da insero batch e
da busca ad hoc. Entretanto, em nossa opinio (que ser
aprofundada na prxima seo), essa situao atual s deve
afetar o projeto fsico do banco de dados, no o projeto
lgico. Infelizmente, porm, como observamos na Seo 21.1,
os fornecedores e usurios de sistemas de apoio deciso com
frequncia deixam de distinguir de modo adequado entre
questes lgicas e fsicas;* de fato, muitas vezes eles
renunciam por completo ao projeto lgico. Como consequncia,
as tentativas para lidar com as vrias caractersticas que
discutimos antes tendem a ser ad hoc e conduzem com
frequncia a dificuldades insuperveis ao se tentar
equilibrar requisitos de correo, facilidade de manuteno,
desempenho, escalabilidade e adequao ao uso.
21.3 PROJETO DE BANCOS DE DADOS PARA APOIO DECISO
Como declaramos anteriormente neste livro (na introduo
Parte III em particular), nossa posio que o projeto de
bancos de dados sempre deve ser feito em pelo menos duas
fases, a fase lgica e depois a fase fsica:
a. O projeto lgico deve ser feito primeiro. Nessa fase, o
enfoque est em correo : as tabelas devem representar
relaes de forma apropriada, garantindo assim que as
operaes relacionais funcionaro como se deseja e no
produziro resultados surpreendentes. Domnios (tipos) so
especificados, as colunas definidas neles e as dependncias
entre colunas (FDs etc.) so identificadas. A partir dessas
informaes, a normalizao pode prosseguir com a definio
das restries de integridade.
b. Em segundo lugar, o projeto fsico deve ser derivado do
projeto lgico. Nessa fase, claro, o foco est em
eficincia de armazenamento e desempenho. Em princpio,
qualquer organizao fsica dos dados permitida, desde que
exista uma transformao que preserve a informao, que possa
ser expressa na lgebra relacional [2.5], entre os esquemas
lgico e fsico. Observe em particular que a existncia de
tal transformao implica que existe vises relacionais do
esquema fsico que a tornem semelhante ao esquema lgico e
vice-versa.
claro que o esquema lgico pode mudar mais tarde (por
exemplo, para acomodar novas espcies de dados ou novas ou
recm-descobertas dependncias), e essa mudana
naturalmente tambm exigir uma mudana correspondente no
esquema fsico. Essa possibilidade no nos interessa aqui. O
que nos interessa a possibilidade de que o esquema fsico
possa mudar enquanto o esquema lgico no se altera. Por
exemplo, suponha que a juno de tabelas FP (remessas) e P
(peas) seja de longe o padro de acesso dominante. Ento,
poderamos desejar fazer a pr-juno das tabelas FP e P no
nvel fsico, reduzindo assim a E/S e os custos de juno.
Contudo, o esquema lgico deve permanecer inalterado se a
independncia de dados fsica tiver de ser mantida.
(Naturalmente, o otimizador de consultas precisar estar
ciente da existncia da pr-juno armazenada e us-la de
modo apropriado, se pretendemos obter as vantagens de
desempenho desejadas.) Alm disso, se o padro de acesso
mudar mais tarde para um que seja dominado por acessos a
tabelas individuais e no a junes, devemos ser capazes de
mudar novamente o esquema fsico de modo que as tabelas FP e
P fiquem fisicamente separadas, mais uma vez sem qualquer
impacto no nvel lgico.
Deve ficar claro do que foi dito antes que o problema de
proporcionar independncia de dados fsica basicamente o
problema de admitir a atualizao de vises (a no ser que,
como ocorre com o problema da atualizao de fragmentos
discutido no Captulo 20, ele se manifeste em um ponto
diferente na arquitetura geral do sistema). Agora, vimos no
Captulo 9 que, em teoria, todas as vises relacionais so
* Os especialistas em data warehouse e OLAP tendem a ser
especialmente culpados sob esse aspecto; com frequncia, eles
argumentam que o projeto relacional est simplesmente
errado para apoio deciso, afirmando que o modelo
relacional incapaz
de representar os dados e deve ser evitado. Esses argumentos
quase sempre esto ligados ao insucesso na tentativa de
distinguir o modelo relacional de sua implementao fsica.
601
atualizveis. Ento, em teoria, se o esquema fsico
derivado do esquema lgico da maneira descrita, ser
alcanada a mxima independncia de dados fsica; qualquer
atualizao expressa em termos do esquema lgico poder ser
automaticamente traduzida em uma atualizao expressa em
termos do esquema fsico e vice-versa, e as mudanas no
esquema fsico no exigiro por si prprias mudanas no
esquema lgico. Nota: observamos de passagem que a nica
razo para se fazer tais mudanas no esquema fsico deve ser
a de melhorar a eficincia de armazenamento ou o desempenho.
Porm, infelizmente, os produtos de SQL de hoje no admitem
corretamente a atualizao de vises. Em consequncia, o
conjunto de esquemas fsicos permissveis consideravelmente
(e desnecessariamente) limitado nesses produtos. Para sermos
especficos, se (a) imaginarmos as tabelas bsicas no nvel
lgico como vises e as verses armazenadas dessas vises
no nvel fsico como tabelas bsicas, ento (b) o esquema
fsico deve ser tal que o produto em questo possa
implementar todas as atualizaes logicamente possveis sobre
essas vises em termos dessas tabelas bsicas. Nota: na
prtica, pode ser possvel simular o prprio mecanismo de
atualizao de vises por meio de procedimentos armazenados,
procedimentos trigger, middleware ou alguma combinao desses
recursos. Porm, essas tcnicas esto alm do escopo deste
captulo.
Projeto lgico
As regras de projeto lgico no dependem do uso pretendido do
banco de dados as mesmas regras se aplicam,
independentemente dos tipos de aplicaes desejados. Assim,
em particular, no deve fazer nenhuma diferena se essas
aplicaes so operacionais (OLTP) ou de apoio deciso: de
qualquer modo, o mesmo procedimento de projeto deve ser
seguido. Ento, vamos rever as trs caractersticas lgicas
de bancos de dados de apoio deciso identificadas no incio
da Seo 21.2 e considerar suas implicaes para o projeto
lgico.
- Combinaes de colunas e menor nmero de dependncias
As consultas de apoio deciso e as atualizaes, quando
for o caso muitas vezes tratam combinaes de colunas como
uma unidade, significando que nunca se tem acesso s colunas
individuais (ENDEREO um exemplo bvio). Vamos concordar em
fazer referncia a uma combinao de colunas como uma coluna
composta. Ento, de um ponto de vista de projeto lgico,
essas colunas compostas se comportam como se de fato no
fossem compostas! Para sermos mais especficos, seja CC uma
coluna composta e C alguma outra coluna da mesma tabela.
Ento, dependncias envolvendo C e componente(s) de CC se
reduzem a dependncias envolvendo C e CC em si. Alm disso,
dependncias envolvendo componentes de CC e nenhuma outra
coluna so irrelevantes e podem simplesmente ser ignoradas. O
efeito final que o nmero total de dependncias reduzido
e o projeto lgico se torna mais simples, com menor nmero de
colunas e possivelmente com nmero ainda menor de tabelas.
Nota: vale a pena mencionar que o suporte completo e
apropriado para colunas compostas no trivial, pois ele
depende do suporte para tipos definidos pelo usurio.
Consulte a referncia [21.111 e os Captulos 5 e 25 para ver
uma discusso adicional.
- Restries de integridade em geral
Tendo em vista que j explicamos que (a) os bancos de dados
de apoio deciso so em grande parte somente de leitura e
(b) a integridade de dados verificada quando o banco de
dados carregado (ou renovado), frequentemente se supe que
no existe nenhum motivo para a declarao de restries de
integridade no esquema lgico. Contudo, no esse o caso.
Embora seja verdade (se o banco de dados de fato somente de
leitura) que as restries nunca podem ser violadas, o valor
semntico dessas restries no deve ser ignorado. Como vimos
no Captulo 8 (Seo 8.10), as restries servem para definir
o significado das tabelas e o significado do banco de dados
global. A declarao das restries fornece assim um meio de
informar aos usurios o que os dados significam, ajudando-os
em sua tarefa de formular consultas. Alm disso, a declarao
das restries tambm pode fornecer informaes cruciais ao
otimizador (veja a discusso
602 sobre otimizao semntica no Captulo 17, Seo 17.4).
Nota: a declarao de certas restries em produtos SQL causa
a criao automtica de certos ndices e outros mecanismos de
imposio, um fato que pode aumentar significativamente o
custo de operaes de carga e renovao. Por sua vez, esse
fato pode servir para encorajar os projetistas a evitarem
declaraes de restries. Porm, uma vez mais, o problema
deriva de uma confuso sobre questes lgicas e fsicas; deve
ser possvel de especificar restries de integridade de
forma declarativa no nvel lgico e especificar os mecanismos
de imposio correspondentes em separado no nvel fsico.
Contudo, infelizmente, os produtos de SQL atuais no
diferenciam de modo adequado entre os dois nveis (alm
disso, eles raramente reconhecem o valor semntico de
restries).
- Chaves tem porais
Os bancos de dados operacionais normalmente envolvem apenas
dados atuais. Em contraste, os bancos de dados de apoio
deciso, em geral envolvem dados histricos e, portanto,
tendem a incluir um timbre de hora na maioria ou em todos
esses dados. Como resultado, as chaves em tais bancos de
dados muitas vezes incluem colunas de timbre de hora. Por
exemplo, considere nosso banco de dados de fornecedores e
peas habitual. Vamos supor que precisamos estender esse
banco de dados a fim de mostrar, para cada remessa, o ms em
particular (de 1 a 12) no qual essa remessa ocorreu. Ento, a
tabela de remessas FP deve ser semelhante da Figura 21.1.
Observe que a coluna adicional IDM (ID do ms) realmente
parte da chave dessa verso estendida da tabela FP. Observe
ainda que consultas envolvendo FP devem agora ser formuladas
com muito cuidado, a fim de evitar o acesso a dados com
timestamps diferentes (a menos que esse acesso seja
exatamente o que se deseja, claro). Mencionamos rapidamente
tais assuntos na Seo 21.2; o Captulo 22 discute esses
temas em profundidade.
Nota: a incluso de colunas timestamps em uma chave pode
levar necessidade de alguma mudana de projeto. Por
exemplo, vamos supor de modo um tanto artificial, que a
quantidade de cada remessa determinada pelo ms em que a
remessa ocorre (a mostra de dados da Figura 21.1
consistente com essa restrio). Ento, a verso revisada da
tabela FP satisfaz dependncia funcional IDM > QDE e
portanto no est na quinta nem mesmo na terceira forma
normal; assim, ela deve ser ainda mais normalizada, como
indica a Figura 21.2. Infelizmente, os projetistas de
sistemas de apoio deciso raramente se preocupam em
considerar tais dependncias induzidas.
FP
FIGURA 21.1 Amostra de valores para a tabela FP, incluindo
IDs de meses
603
F# P# 1DM QDE
T1 P1 3 300
F1 P1 5 100
F1 P2 1 200
F1 P3 7 400
E1 P4 1 200
F1 P5 5 100
F1 P6 4 100
F2 P1 3 300
F2 P2 9 400
F3 P2 6 200
F3 P2 8 200
F4 P2 1 200
F4 P4 8 200
F4 P5 7 400
F4 P5 11 400
Equivalente normalizada da Figura 21.1
Projeto fsico
Dissemos na Seo 21.2 que os bancos de dados de apoio
deciso tendem a ser grandes e fortemente indexados e a
envolver vrios tipos de redundncia controlada. Nesta
subseo, desenvolvemos rapidamente esses assuntos de projeto
fsico.
Primeiro, vamos considerar o particionamento (tambm
conhecido como fragmentao). O particionamento representa um
ataque ao problema do banco de dados grande; ele divide uma
dada tabela em um conjunto de parties disjuntas ou
fragmentos para fins de armazenamento fsico (veja a
discusso sobre a fragmentao no Captulo 20). Esse
particionamento pode melhorar de modo significativo a
facilidade de gerenciamento e de acesso da tabela em questo.
Em geral, cada partio recebe a atribuio de certos
recursos de hardware mais ou menos dedicados (por exemplo,
disco, CPU), minimizando assim a competio por esses
recursos entre parties. As tabelas so particionadas
horizontalmente* por meio de uma funo de particionamento, a
qual usa valores de colunas selecionadas (a chave de
partio) como argumentos e retorna um nmero ou endereo de
partio. Tais funes normalmente admitem o particionamento
de intervalos (range partitionig), de hashing e de rodzio
(round-robin), entre outros tipos (consulte a anotao
referncia [17.58j no Captulo 17).
Agora, vamos tratar da indexao. claro que sabemos que o
uso do tipo correto de ndice pode reduzir drasticamente a
E/S. A maioria dos primeiros produtos de SQL oferecia apenas
um tipo de ndice, a rvore B, mas vrios outros tipos se
tornaram disponveis ao longo dos anos, especialmente em
conexo com bancos de dados de apoio deciso; eles incluem
ndices de bitmap, de hashing, de vrias tabelas (multi-
table), booleanos e funcionais, alm dos ndices de rvore B
em si. Vamos comentar rapidamente cada um deles.
- Indices em rvore B: os ndices em rvore B proporcionam
acesso eficiente para consultas de intervalos (a menos que o
nmero de linhas se torne grande demais). A atualizao de
rvores B relativamente eficiente.
- Indices de bitmap: suponha que a tabela indexada T contenha
n linhas. Ento, um ndice de bitmap sobre a coluna C da
tabela T contm um vetor de n bits para cada valor no domnio
de C, definindo o bit correspondente linha R se linha R
contm o valor aplicvel na coluna C. Esses ndices so
eficientes para consultas envolvendo conjuntos de valores,
embora se tornem menos eficientes quando os conjuntos ficam
grandes demais. Observe em particular que vrias operaes
relacionais (junes, unies, restries de igualdade, etc.)
podem ser executadas inteiramente
FP
FIGURA 21.2
MS QDE 1DM QDE
1 200
2 600
3 300
4 100
5 100
6 200
7 400
8 200
9 400
10 100
11 400
12 50
604 O particionamento vertical, embora talvez seja vantajoso,
no muito usado porque a maioria dos produtos no o admite.
F# P# 1DM
F1 P1 3
F1 P1 5
Fi P2 1
F1 P3 7
F1 P4 1
Fi P5 5
Fi P6 4
F2 P1 3
F2 P2 9
F3 P2 6
F3 P2 8
F4 P2 1
F4 P4 8
F4 P5 7
F4 P5 11
dentro dos ndices por meio de operaes booleanas simples
(AND, OR, NOT) sobre os vetores de bits; o acesso aos dados
reais no absolutamente necessrio at o conjunto do
resultado final ter sido retornado. A atualizao de ndices
de bitmaps relativamente ineficiente.
. Indices de hashing (tambm conhecidos como endereamento de
hashing ou apenas hashing): os ndices de hashing so
eficientes para acesso a linhas especficas (no a
intervalos). O custo computacional linear com o nmero de
linhas, desde que a funo de hashing no precise ser
estendida para acomodar valores de chaves adicionais. O
hashing tambm pode ser usado para implementar junes de
modo eficiente, como descrevemos no Captulo 17.
- Indices de vrias tabelas (tambm conhecidos como ndices
de juno): em essncia, uma entrada de ndice de vrias
tabelas contm ponteiros para linhas de diversas tabelas, em
vez de ponteiros para linhas em uma nica tabela. Esses
ndices podem melhorar o desempenho de junes e a
verificao de restries de integridade de vrias tabelas
(isto , de bancos de dados).
- Indices booleanos (normalmente conhecidos como ndices de
expresses): um ndice booleano indica para quais linhas de
uma determinada tabela uma expresso booleana especificada
(envolvendo colunas da tabela em questo) tem o valor
verdadeiro. Tais ndices so particularmente valiosos quando
a expresso booleana relevante um componente comum de
condies de restrio.
- Indices funcionais: um ndice funcional executa a indexao
das linhas de uma tabela, no com base nos valores dessas
linhas, mas sim com base no resultado da invocao de alguma
funo especificada sobre esses valores.
Alm de tudo o que foi dito antes, foram propostos vrios
tipos de ndices hbridos (combinaes dos ndices listados).
difcil caracterizar o valor desses hbridos em termos
gerais. Um nmero enorme de tipos especializados de ndices
tambm foi proposto (por exemplo, rvores R, que so
destinadas ao trabalho com dados geomtricos). No tentaremos
realizar a tarefa assustadora de descrever todos esses tipos
de ndices neste livro; por exemplo, consulte a referncia
[25.27] para ver uma ampla discusso sobre o assunto.
Por ltimo, voltamos questo da redundncia controlada. A
redundncia controlada uma ferramenta importante para
reduzir a E/S e minimizar a conteno. Como explicamos no
Captulo 1, a redundncia controlada quando administrada
pelo SGBD e est oculta dos usurios. (Observe que, por
definio, a redundncia controlada de forma apropriada no
nvel fsico invisvel no nvel lgico, de modo que no tem
nenhum efeito sobre a correo desse nvel lgico.) Existem
dois tipos gerais de tal redundncia:
- O primeiro envolve a manuteno de cpias exatas ou
rplicas dos dados bsicos. Nota: o que poderia ser
considerado uma forma menos ambiciosa de replicao, o
gerenciamento de cpias, tambm amplamente aceito (ver a
seguir).
- O segundo envolve a manuteno de dados derivados alm dos
dados bsicos, mais frequentemente na forma de tabelas de
resumo e/ou colunas calculadas ou ainda colunas com putadas
ou derivadas.
Vamos discutir cada um deles.
Os conceitos bsicos de replicao foram explicados no
Captulo 20, nas Sees 20.3 e 20.4 (veja em especial a
subseo Propagao de atualizaes na Seo 20.4); aqui
apenas repetimos alguns pontos de destaque dessas discusses
e fazemos algumas observaes adicionais. Primeiro, lembre-se
de que a replicao pode ser sncrona ou assncrona:
- No caso sncrono, se uma dada rplica atualizada, ento
todas as outras rplicas do mesmo fragmento de dados tambm
so atualizadas dentro da mesma transao, implicando que (em
termos lgicos) existe apenas uma verso dos dados. A maioria
dos produtos implementa a replicao sncrona atravs de
procedimentos trigger (possivelmente ocultos e gerenciados
pelo sistema.) 605
Porm, a replicao sncrona tem a desvantagem de impor uma
sobrecarga sobre todas as transaes que atualizam qualquer
rplica (podendo acarretar tambm problemas de
disponibilidade).
. No caso assncrono, as atualizaes feitas em uma rplica
se propagam para as outras em algum momento posterior, no
dentro da mesma transao. A replicao assncrona introduz
assim um retardo de tempo ou uma latncia durante a qual as
rplicas de fato podem no ser idnticas (e ento o termo
rplicas no mais muito apropriado, pois no estamos mais
falando sobre cpias exatas). A maioria dos produtos
implementa a replicao assncrona pela leitura do log de
transaes ou de uma fila estvel de atualizaes que
precisam ser propagadas.
A vantagem da replicao assncrona que a sobrecarga de
replicao desacoplada da transao de atualizao, que
pode ser de misso crtica e altamente sensvel ao
desempenho. A desvantagem que os dados podem se tornar
inconsistentes (ou seja, inconsistentes na viso do usurio);
isto , a redundncia pode transparecer no nvel lgico
significando, em termos estritos, que a expresso
redundncia controlada no mais muito apropriada.*
Observamos que, pelo menos no mundo comercial, o termo
replicao significa principalmente ( na verdade, quase
exclusivamente), a replicao assncrona (como notamos no
Captulo 20).
A diferena bsica entre replicao e gerenciamento de cpias
dada a seguir. Com a replicao, as atualizaes feitas em
uma rplica so (eventualmente) propagadas para todas as
outras de forma automtica. Em contraste, com o
gerenciamento de cpias, no existe nenhuma propagao
automtica; em vez disso, as cpias de dados so criadas e
mantidas por meio de algum processo batch ou em segundo plano
que desacoplado no tempo das transaes de atualizao. Em
geral, o gerenciamento de cpias mais eficiente que a
replicao, pois grandes quantidades de dados podem ser
copiadas de uma s vez. A desvantagem que na maior parte do
tempo, as cpias no so idnticas aos dados bsicos; na
verdade, geralmente os usurios devem estar cientes de quando
os dados so sincronizados. O gerenciamento de cpias costuma
ser simplificado pela exigncia de que as atualizaes sejam
aplicadas de acordo com algum tipo de esquema de cpia
primria (consulte o Captulo 20).
O outro tipo de redundncia que consideramos aqui o de
colunas calculadas e tabelas de resumo. Essas construes so
particularmente importantes no contexto de apoio deciso;
elas so usadas para conter valores de dados pr-calculados
(isto , valores calculados a partir de outros dados mantidos
em algum outro lugar no banco de dados). Claramente, essas
construes evitam a necessidade de recalcular esses valores
toda vez que eles so necessrios em alguma consulta. Uma
coluna calculada uma coluna cujo valor em qualquer linha
determinada derivada de algum modo de outros valores na
mesma linha.** Uma tabela de resumo uma tabela que contm
agregaes (totais, mdias, contagens, etc.) de valores em
outras tabelas. Essas agregaes frequentemente so pr-
calculadas para vrios agrupamentos diferentes dos mesmos
dados de detalhe (consulte a Seo 2 1.6). Nota: se as
colunas calculadas e as tabelas de resumo so mesmo
instncias de redundncia controlada, elas precisam estar
totalmente ocultas dos usurios; porm, nos produtos atuais
em geral elas no esto.
As tabelas de resumo e as colunas calculadas so
implementadas com maior frequncia atravs de procedimentos
trigger gerenciados pelo sistema, embora tambm possam ser
implementadas por meio de cdigo procedural escrito pelo
usurio. A primeira abordagem permite manter a consistncia
entre os dados bsicos e os dados derivados (desde que ambos
sejam atualizados na mesma transao, o que ocorrer ou no;
mesmo que ocorra, observe que um nvel elevado de isolamento
pode ser crucial para
* Observe tambm que rplicas podem se tornar inconsistentes,
e essa inconsistncia pode ser difcil de evitar e de
corrigir. Em particular, podem surgir conflitos sobre a ordem
em que as atualizaes so aplicadas. Por exemplo, seja a
transao T1 que insere uma linha na rplica RX, e seja a
transao T2 que elimina essa linha; e seja ainda RY uma
rplica de RX. Se as atualizaes se propagam para RY, mas
chegam a RY em ordem inversa (por exemplo, devido a atrasos
de roteamento), T2 no encontra nenhuma linha para eliminar e
T1 insere a linha depois. O efeito final que RY contm a
linha, enquanto RX no a contm. A administrao de conflitos
e a imposio de consistncia entre rplicas so problemas
difceis, e esto alm do escopo deste livro.
** De forma alternativa, o valor calculado pode ser derivado
de valores em vrias linhas, na mesma tabela ou em alguma(s)
outra(s) tabela(s). Porm, essa abordagem implica que a
atualizao de uma linha poderia exigir que muitas outras
linhas tambm
606 fossem atualizadas; em particular, ela pode ter um efeito
muito negativo sobre operaes de carga e renovao.
se obter essa consistncia). A ltima abordagem tem maior
probabilidade de expor inconsistncias para o usurio.
Erros comuns de projeto
Nesta subseo, comentaremos rapidamente algumas prticas de
projeto que so comuns no ambiente de apoio deciso e que
ainda assim no consideramos boas idias:
. Linhas duplicadas: os projetistas de apoio deciso
frequentemente afirmam que seus dados no tem nenhum
identificador exclusivo e que, portanto, eles tm de permitir
duplicatas. As referncias [5.3] e [5.6] explicam em detalhes
por que as duplicatas so um equvoco; aqui, apenas
observamos que a exigncia surge normalmente porque o
esquema fsico no derivado de um esquema lgico (que
provavelmente nunca foi criado). Observamos tambm que em tal
projeto, as linhas com frequncia tm significados no
uniformes (em especial se houver nulos presentes)
isto , elas no so todas instanciaes do mesmo predicado
(consulte o Captulo 3, Seo 3.4, e tambm o Captulo 18).
Nota: as duplicatas s vezes so at permitidas
deliberadamente, em especial se o projetista tem uma
experincia em sistemas baseados em objetos (consulte o
ltimo pargrafo da Seo 24.2 no Captulo 24).
. Desnormalizao e prticas relacionadas: em um esforo mal
orientado para eliminar junes e reduzir a E/S, os
projetistas muitas vezes fazem a pr-juno de tabelas,
introduzem colunas derivadas de vrios tipos, etc. Essas
prticas poderiam ser aceitveis no nvel fsico, mas no se
elas podem ser detectadas no nvel lgico.
- Esquemas em estrela: os esquemas em estrela (tambm
conhecidos como esquemas dimensionais) so mais
frequentemente o resultado de uma tentativa de fazer um
curto-circuito na tcnica de projeto apropriada. H pouca
vantagem nesses atalhos. Com frequncia, tanto o desempenho
quanto a flexibilidade sofrem medida que o banco de dados
cresce, e a resoluo dessas dificuldades atravs da
repetio do projeto fsico tambm impe mudanas de foras
em aplicaes (porque os esquemas em estrela so na realidade
esquemas fsicos, embora sejam exposto a aplicaes). O
problema global reside na natureza ad hoc do projeto. Nota:
discutiremos os esquemas em estrela com mais detalhes na
Seo 21.5.
- Nulos: com frequncia, os projetistas tentam poupar espao
permitindo nulos em colunas (esse artifcio poderia funcionar
se a coluna em questo fosse de algum tipo de dados de
comprimento varivel e se o produto em questo representasse
nulos em tais colunas por strings vazios no nvel fsico).
Porm, essas tentativas geralmente so mal orientadas. No
apenas possvel (e desejvel) projetar de modo a evitar
nulos [18.20], mas os esquemas resultantes muitas vezes
oferecem melhor eficincia de armazenamento e melhor
desempenho de E/S.
- Projeto de tabelas de resumo: a questo do projeto lgico
de tabelas de resumo frequentemente ignorada, levando
redundncia descontrolada e a dificuldades para manter a
consistncia. Em consequncia disso, os usurios podem ficar
confusos quanto ao significado dos dados de resumo e ao modo
de formular consultas que os envolve. Para evitar tais
problemas, todas as tabelas de resumo no mesmo nvel de
agregao (veja a Seo 2 1.6) devem ser projetadas como se
formassem um banco de dados prprio. Certos problemas de
atualizao cclica podem ento ser evitados (a) proibindo-se
que as atualizaes se estendam a vrios nveis de agregao
e (b) pela sincronizao das tabelas de resumo, fazendo-se
sempre a agregao do nvel de detalhe para cima.
- Vrios caminhos de navegao: os projetistas e os
usurios de apoio deciso com frequncia mencionam
(incorretamente) a existncia de uma multiplicidade de
caminhos de navegao para alguns dados desejados,
significando que os mesmos dados podem ser alcanados atravs
de vrias expresses relacionais diferentes. As vezes, as
expresses em questo so verdadeiramente equivalentes, como
no caso de, por exemplo, A JOIN (B UNION C) e (AJOIN B) JOIN
C (consulte o Captulo 17); s vezes, elas s so
equivalentes porque existe alguma restrio de integridade em
efeito que as torna assim (mais uma vez, 607
consulte o Captulo 17); e, s vezes, elas no so de modo
algum equivalentes! Como um exemplo do ltimo caso, suponha
que as tabelas A, B e C tenham todos uma coluna comum K;
ento, seguir o caminho K de A para B e da at C
certamente no o mesmo (em geral) que seguir o caminho K
diretamente de A para C.
claro que os usurios podem ficar confusos em tais casos e
inseguros sobre qual expresso devem usar e se haver ou no
alguma diferena no resultado. Uma parte desse problema s
pode ser resolvida, claro, pela educao adequada do
usurio. Outra parte pode ser resolvida se o otimizador fizer
seu trabalho corretamente. Porm, existe ainda uma outra
parte que se deve ao fato de projetistas permitirem
redundncias no esquema lgico e/ou permitirem que os
usurios tenham acesso direto ao esquema fsico, e essa parte
do problema s pode ser resolvida atravs de uma prtica de
projeto apropriada.
Em suma, acreditamos que muitas das dificuldades de projeto
que supostamente surgem das exigncias de apoio deciso
podem ser resolvidas seguindo-se uma abordagem disciplinada.
Na verdade, muitas dessas dificuldades so causadas por no
se seguir tal abordagem (embora seja razovel acrescentar que
elas frequentemente so agravadas por problemas com a SQL).
21.4 PREPARAO DE DADOS
Muitas das questes relacionadas que envolvem o apoio
deciso esto relacionadas com as tarefas de obteno e
preparao inicial dos dados. Os dados devem ser extrados de
vrias fontes, limpos, transformados e consolidados,
carregados no banco de dados de apoio deciso, e depois
periodicamente renovados. Cada uma dessas operaes envolve
suas prprias consideraes especiais.* Examinaremos cada uma
por sua vez, depois encerraremos a seo com uma breve
descrio dos depsitos de dados operacionais.
Extrao
A extrao o processo de capturar dados de bancos de dados
operacionais e outras fontes. Muitas ferramentas esto
disponveis para ajud-lo nessa tarefa, inclusive utilitrios
fornecidos pelo sistema, programas de extrao personalizados
e produtos comerciais de extrao (de uso geral). O processo
de extrao tende a ser muito intenso em termos de E/S, e
assim pode interferir com operaes de misso crtica; por
essa razo, ela com frequncia realizada em paralelo (isto
, como um conjunto de subprocessos paralelos) e em nvel
fsico. Porm, essas extraes fsicas podem causar
problemas para o processamento subsequente, porque podem
perder informaes em especial, informaes sobre
relacionamentos representadas de algum modo fsico (por
exemplo, atravs de ponteiros ou por proximidade fsica). Por
essa razo, os programas de extrao s vezes oferecem um
meio para preservar tais informaes, introduzindo nmeros de
registros sequenciais e substituindo ponteiros por aquilo que
chamamos valores de chaves estrangeiras.
Limpeza
Poucas fontes de dados controlam a qualidade dos dados
adequadamente. Como resultado, os dados com frequncia exigem
limpeza (cleansing) (em geral, batch) antes de poderem ser
introduzidos no banco de dados de apoio deciso.
Normalmente, as operaes de limpeza incluem o preenchimento
de valores omitidos, a correo de erros de digitao e
outros erros de entrada de dados, o estabelecimento de
abreviaes e formatos padro, a substituio de sinnimos
por identificadores padro, e assim por diante. Os dados
reconhecidos como errados e que no podem ser limpos so
rejeitados. Nota: as informaes obtidas durante o processo
de limpeza s vezes podem ser usadas para identificar a causa
de erros na fonte, e assim melhorar a qualidade dos dados com
o tempo.
* Observamos de passagem que essas operaes frequentemente
poderiam se beneficiar dos recursos de nvel de conjuntos dos
608 sistemas relacionais, embora na prtica isso raramente
ocorra.
Transformao e consolidao
Mesmo aps terem sido limpos, os dados provavelmente ainda
no estaro na forma que o sistema de apoio deciso exige,
e assim precisaro ser transformados de modo apropriado. Em
geral, a forma exigida ser um conjunto de arquivos, um para
cada tabela identificada no esquema fsico; como resultado,
a transformao dos dados pode envolver a diviso e/ou a
combinao de registros de origem de acordo com as
diretrizes discutidas no Captulo 1 (Seo 1.5). Nota: os
erros de dados que no foram corrigidos
durante a limpeza s vezes so encontrados no decorrer do
processo de transformao. Como antes, quaisquer dados
incorretos geralmente so rejeitados. (Tambm como antes, as
informaes obtidas como parte desse processo podem s vezes
ser usadas para melhorar a qualidade da origem de dados.)
A transformao particularmente importante quando vrias
origens de dados precisam ser mescladas, em um processo
chamado consolidao. Nesse caso, quaisquer relacionamentos
implcitos entre dados de origens distintas precisam se
tornar explcitos (pela introduo de valores de dados
explcitos). Alm disso, datas e horas associadas com o
significado dos dados para o negcio precisam ser mantidas e
correlacionadas entre as origens, um processo que se chama
sincronizao de tempo [sic].
Por razes de desempenho, operaes de transformao
frequentemente so executadas em paralelo. Elas podem
utilizar intensamente operaes de E/S e da CPU.
Nota: a sincronizao de tempo pode ser um problema difcil.
Por exemplo, vamos supor que desejamos encontrar a renda
mdia de clientes por vendedor e por trimestre. Suponha que
os dados de clientes versus renda sejam mantidos por
trimestre fiscal em um banco de dados de contabilidade,
enquanto os dados de vendedores versus clientes sejam
mantidos por trimestre civil em um banco de dados de vendas.
claro que precisamos mesclar os dados dos dois bancos de
dados. Consolidar os dados de clientes fcil basta
fazerem corresponderem as IDs de clientes. Contudo, a questo
da sincronizao de tempo muito mais difcil; podemos
encontrar rendas de clientes por trimestre fiscal
(provenientes do banco de dados de contabilidade), mas no
podemos saber quais vendedores eram responsveis por quais
clientes nessa poca, nem podemos de modo algum encontrar
rendas de clientes por trimestre civil.
Carga
Os fornecedores de SGBDs deram importncia considervel
eficincia de operaes de carga. Para nossos fins,
consideramos que as operaes de carga incluem (a) mover os
dados transformados e consolidados para o banco de dados de
apoio deciso; (b) verificar a consistncia dos dados (isto
, fazer a verificao de integridade); e (c) construir
quaisquer ndices necessrios. Vamos comentar rapidamente
cada etapa:
a. Mover os dados: os sistemas modernos normalmente fornecem
utilitrios de carga em paralelo. Algumas vezes, eles faro a
formatao prvia dos dados conforme o formato fsico interno
exigido pelo SGBD de destino antes da carga real. (Uma
tcnica alternativa que responde pela eficincia de cargas
pr-formatadas a de carregar os dados em tabelas de
trabalho que reflitam o esquema de destino. A verificao de
integridade necessria pode ser feita nessas tabelas de
trabalho consulte o pargrafo b. e so usadas ento
operaes INSERT em nvel de conjunto para mover os dados de
tabelas de trabalho para as tabelas de destino.)
b. Verificao da integridade: a maior parte da verificao
de integridade nos dados a serem carregados pode ser feita
antes da carga real, sem referncia a dados j presentes no
banco de dados. Porm, certas restries no podem ser
verificadas sem o exame do banco de dados existente; por
exemplo, uma restrio de unicidade geralmente ter de ser
verificada durante a carga real (ou batch, aps a concluso
da carga).
c. Construo de ndices: a presena de ndices pode diminuir
drasticamente a velocidade do processo de carga, pois a
maioria dos produtos atualiza ndices medida que cada linha
inserida na tabela subjacente. Por essa razo, s vezes
uma boa idia descartar ndices antes da carga, e depois
cri-los de novo mais tarde. Contudo, essa abordagem no vale
a pena quando a razo de novos dados para dados existentes
pequena, ao custo de criar um ndice no ser proporcional ao
tamanho
609
da tabela a ser indexada. Alm disso, a criao de um ndice
extenso pode estar sujeita a erros de alocao
irrecuperveis, tornando tais erros mais provveis medida
que aumenta o tamanho do ndice. Nota: a maioria dos produtos
de SGBDs admite a criao de ndices em paralelo, como um
esforo para acelerar os processos de carga e construo de
ndices.
Renovao
A maioria dos bancos de dados de apoio deciso (nem todos)
exige renovao peridica dos dados, a fim de mant-los
razoavelmente atualizados. Em geral, a renovao envolve uma
carga parcial, embora algumas aplicaes de apoio deciso
exijam que se descarte tudo no banco de dados e se faa o
recarregamento completo dos dados. A renovao envolve todos
os problemas associados com a carga, mas tambm pode ser
necessrio execut-la enquanto os usurios tm acesso ao
banco de dados. Consulte o Captulo 9, Seo 9.5, e tambm as
referncias [9.2] e [9.6].
Depsitos de dados operacionais
Um depsito de dados operacionais (ODS operational data
store) uma coleo de dados orientada por assunto,
integrada, voltil (isto , atualizvel), atual ou quase
atual [21.19]. Em outras palavras, um tipo especial de
banco de dados. A expresso orientada por assunto significa
que os dados em questo esto relacionados com algum assunto
especfico (por exemplo, clientes, produtos). Um depsito de
dados operacionais pode ser usado (a) como uma rea
provisria para reorganizao fsica de dados operacionais
extrados, (b) para fornecer relatrios operacionais, e (c)
para dar suporte a decises operacionais. Ele tambm pode
servir (d) como um ponto de consolidao, caso os dados
operacionais venham de vrias fontes. Assim, os ODSs servem a
muitas finalidades. Nota: tendo em vista que eles no
acumulam dados histricos, os ODSs (em geral) no crescem
muito; por outro lado, eles costumam estar sujeitos
renovao muito frequente ou mesmo contnua de origens de
dados operacionais. * Os problemas de sincronizao de tempo
(veja a subseo Transformao e Consolidao anterior)
podem ser abordados com sucesso dentro de um ODS, se a
renovao for bastante frequente.
21.5 DATA WAREHOUSES E DATA MARTS
Os sistemas operacionais normalmente tm exigncias estritas
de desempenho, cargas de trabalho previsveis, pequenas
unidades de trabalho e utilizao elevada. Em contraste, os
sistemas de apoio deciso normalmente tm requisitos de
desempenho variveis, cargas de trabalho imprevisveis,
grandes unidades de trabalho e utilizao irregular. Essas
diferenas podem tornar muito difcil combinar o
processamento operacional e de apoio deciso dentro de um
nico sistema, em especial com respeito ao planejamento da
capacidade, ao gerenciamento de recursos e ao ajuste de
desempenho do sistema. Por essas razes, os administradores
de sistemas operacionais em geral relutam em permitir
atividades de apoio deciso em seus sistemas, da a
abordagem familiar de sistema dual.
Nota: observamos a propsito que a situao nem sempre foi
essa; os primeiros sistemas de apoio deciso funcionavam de
fato sobre sistemas operacionais, mas em baixa prioridade ou
durante a chamada janela batch. Considerando-se recursos de
computao suficientes, h vrias vantagens nessa
organizao, das quais talvez a mais bvia seja a de evitar
todas as operaes possivelmente dispendiosas de cpia de
dados, reformatao e transferncia (etc.) exigidas pela
abordagem de sistema dual. De fato, o valor da integrao de
atividades operacionais e de apoio deciso vem sendo cada
vez mais reconhecida. Porm, os detalhes adicionais dessa
integrao esto alm do escopo deste captulo.
Apesar do pargrafo anterior, permanece o fato de que, pelo
menos no momento em que escrevemos, os dados de apoio
deciso normalmente precisam ser reunidos a partir de uma
variedade de sistemas
* A replicao assncrona das origens de dados operacionais
para o ODS usada s vezes para esse fim. Desse modo, os
dados 610
podem frequentemente ser atualizados dentro de poucos
minutos.
operacionais (com frequncia, sistemas discrepantes) e
mantidos em um depsito de dados prprio em uma plataforma
separada. Esse depsito de dados separado um data
warehouse.
Armazns de dados
Como um depsito de dados operacionais (e como um data marts
consulte a prxima subseo), um data warehouse um tipo
especial de banco de dados. O termo parece ter tido origem no
final dos anos oitenta [21.13], [21.17], embora o conceito
seja um pouco mais antigo. A referncia [21.18] define um
data warehouse como um depsito de dados orientado por
assunto, integrado, no voltil, varivel com o tempo para
apoiar as decises da gerncia (onde o termo no voltil
significa que, uma vez inseridos, os dados no podem ser
alterados, embora possam ser eliminados). Os data warehouses
surgiram por duas razes: primeiro, pela necessidade de
fornecer uma origem de dados nica, limpa e consistente para
fins de apoio deciso; segundo, pela necessidade de faz-lo
sem causar impacto sobre os sistemas operacionais.
Por definio, as cargas de trabalho de data warehouses so
cargas de trabalho de apoio deciso e, portanto, fazem uso
intensivo de consultas (com atividades intensivas ocasionais
de insero batch); alm disso, os prprios armazns de dados
tendem a ser bem grandes (frequentemente acima de 500 GB,
crescendo cerca de 50% em um ano). Como resultado, o ajuste
de desempenho difcil, embora no impossvel. Porm, a
escalabilidade pode ser um problema. Os fatores que
contribuem para esse problema incluem (a) erros de projeto de
bancos de dados (discutidos na subseo final da Seo 21.3):
(b) uso ineficiente de operaes relacionais (mencionadas
rapidamente na Seo 21.2); (c) fraqueza na implementao do
modelo relacional do SGBD; (d) falta de escalabilidade do
prprio SGBD; e (e) erros de projeto de arquitetura que
limitam a capacidade e impedem a escalabilidade da
plataforma. Os itens (d) e (e) esto alm do escopo deste
livro; ao contrrio, os itens (a) e (b) j foram discutidos
neste captulo, e o item (c) foi discutido com detalhes em
outras partes do livro.
Data marts
Os data warehouses geralmente so destinados a fornecer uma
nica origem de dados para todas as atividades de apoio
deciso. Porm, quando os data warehouses se tornaram
populares no incio dos anos noventa, logo se percebeu que os
usurios com frequncia executavam extensivas operaes de
relatrios e anlise de dados sobre um subconjunto
relativamente pequeno do data warehouse completo. Na verdade,
os usurios provavelmente repetiam as mesmas operaes sobre
o mesmo subconjunto dos dados toda vez que eles eram
renovados. Alm disso, algumas dessas atividades por
exemplo, a anlise de prognsticos (previso), a simulao, a
modelagem what if de dados de negcios envolvia a criao
de novos esquemas e dados, com atualizaes subsequentes
desses novos dados.
A execuo repetida dessas operaes sobre o mesmo
subconjunto do armazm completo obviamente no muito
eficiente; a idia de construir alguma espcie de armazm
limitado e de uso especial, adaptado finalidade imediata,
parece assim uma idia muito boa. Alm disso, em alguns
casos, talvez seja possvel extrair e preparar os dados
exigidos diretamente de fontes locais, fornecendo acesso aos
dados mais depressa do que se eles tivessem de ser
sincronizados com todos os outros dados a serem carregados no
armazm completo. Essas consideraes levaram ao conceito de
data marts.
Na realidade, existe alguma controvrsia sobre a definio
precisa do termo data marts. Para nossos fins, podemos
defini-lo como um depsito de dados especializado, orientado
por assunto, integrado, voltil e varivel no tempo que
fornece apoio a um subconjunto especfico de decises da
gerncia. Como podemos ver, as principais distines entre
um data marts e um data warehouse so as de que um data
warehouse especializado e voltil. Por especializado,
queremos dizer que ele contm dados para apoio a uma rea
especfica (somente) de anlise de negcios; por voltil,
queremos dizer que os usurios podem atualizar os dados, e
talvez at mesmo criar novos dados (isto , novas tabelas)
para algum propsito.
Existem trs abordagens principais para criao de um data
marts:
. Os dados podem simplesmente ser extrados do data warehouse
na verdade, seguindo uma abordagem de dividir e
conquistar para a carga de trabalho global de apoio
deciso, a fim de obter melhor desempenho e escalabilidade.
Normalmente, os dados extrados so carregados em um banco de
dados com um esquema fsico que lembra bastante o subconjunto
aplicvel destinado ao data warehouse; contudo, pode ser
possvel simplific-lo um pouco, graas natureza
especializada do data marts.
. Apesar do fato de o data warehouse se destinar a fornecer
um nico ponto de controle, um data marts pode ainda ser
criado de modo independente (ou seja, no atravs de extrao
do data warehouse). Tal abordagem poderia ser apropriada se o
data warehouse fosse inacessvel por alguma razo, digamos
por razes financeiras, operacionais, ou mesmo polticas (ou
o data warehouse poderia nem sequer existir ainda consulte
o item imediatamente a seguir).
. Algumas instalaes seguiram uma abordagem de data marts
primeiro, na qual os data marts so criados conforme seja
necessrio, com o data warehouse global sendo criado
eventualmente como uma consolidao dos diversos data marts.
As duas ltimas abordagens sofrem de possveis problemas de
falta de correspondncia semntica. Os data marts
independentes so particularmente suscetveis a tais
problemas, pois no existe nenhum modo bvio de verificar
problemas de falta de correspondncia semntica quando os
bancos de dados so projetados de forma independente. A
consolidao de data marts em um data warehouse em geral
falha, a menos que (a) seja construdo primeiro um nico
esquema lgico para o data warehouse, e (b) os esquemas para
os data marts individuais sejam ento derivados desse esquema
de warehouse. ( claro que o esquema do armazm pode evoluir
supondo-se que seja seguida uma boa prtica de projeto
at incluir a questo do assunto de cada novo data marts
conforme seja necessrio.)
Uma nota sobre o projeto de data marts: uma deciso
importante a ser tomada no projeto de qualquer banco de dados
de apoio deciso a granularidade do banco de dados. O
termo granularidade se refere aqui ao nvel mais baixo de
agregao de dados que ser mantido no banco de dados. Agora,
a maioria das aplicaes de apoio deciso exige acesso a
dados de detalhe mais cedo ou mais tarde; assim, no caso do
data warehouse, a deciso fcil. Para um data mart, ela
pode ser mais difcil. Extrair grandes quantidades de dados
de detalhe do data warehouse e armazen-los no data mart pode
ser muito ineficiente se esse nvel de detalhe no for
necessrio com muita frequncia. Por outro lado, s vezes
difcil enunciar de forma definitiva qual realmente o nvel
mais baixo de agregao necessrio. Em tais casos, o acesso
aos dados de detalhe pode ser feito diretamente a partir do
data warehouse se e quando necessrio, com dados um pouco
agregados sendo mantidos no data mart. Ao mesmo tempo, a
agregao total dos dados no costuma ser feita, porque as
muitas possibilidades de agregao dos dados produzir
quantidades enormes de dados de resumo. Esse tema discutido
com mais detalhes na Seo 2 1.6, mais adiante.
Um ponto adicional: como os usurios de data marts
frequentemente empregam certas ferramentas analticas, o
projeto fsico muitas vezes determinado em parte pelas
ferramentas especficas a serem usadas (veja a discusso
sobre ROLAP versus MOLAP na Seo 21.6). Essa circunstncia
infeliz pode levar a esquemas dimensionais (que
discutiremos em seguida), que no combinam com a boa prtica
de projeto relacional.
Esquemas dimensionais
Vamos supor que desejamos reunir um histrico de transaes
de negcios para fins de anlise. Como observamos na Seo
21.1, os primeiros sistemas de apoio deciso normalmente
manteriam esse histrico como um simples arquivo, ao qual se
teria acesso por meio de varredura sequencial. No entanto,
medida que o volume de dados aumenta, torna-se cada vez mais
desejvel admitir o acesso direto para busca no arquivo a
partir de vrias perspectivas diferentes. Por exemplo,
poderia ser til a possibilidade
612
de encontrar todas as transaes de negcios que envolvessem
um determinado produto, ou todas as
transaes de negcios que ocorressem dentro de um perodo de
tempo especfico, ou ainda todas as transaes de negcios
referentes a um certo cliente.
Um mtodo de organizao que admite esse tipo de acesso foi
chamado banco de dados de vrios catlogos (multi-catalog)
. * Continuando com nosso exemplo, esse banco de dados
consistiria em um grande arquivo de dados central contendo os
dados de transaes de negcios, juntamente com trs arquivos
de catlogo individuais para produtos, perodos de tempo e
clientes, respectivamente. Esses arquivos de catlogo se
assemelham a ndices pelo fato de conterem ponteiros para
registros no arquivo de dados, mas (a) as entradas podem ser
inseridas explicitamente pelo usurio (manuteno de
catlogo), e (b) eles podem conter informaes suplementares
(por exemplo, endereo de cliente) que podem ento ser
removidas do arquivo de dados. Observe que os arquivos de
catlogo so normalmente pequenos em comparao com o arquivo
de dados.
Essa organizao mais eficiente em termos de espao e de
E/S que o projeto original (o qual envolve apenas um arquivo
de dados). Em particular, observe que as informaes sobre o
produto, o perodo de tempo e o cliente no arquivo de dados
central agora se reduzem a identificadores de produto,
perodo de tempo e cliente.
Quando essa abordagem imitada em um banco de dados
relacional, o arquivo de dados e os arquivos de catlogo se
tornam tabelas (imagens dos arquivos correspondentes), os
ponteiros nos arquivos de catlogo se transformam em chaves
primrias nas tabelas de imagens de arquivos de catlogo, e o
identificadores no arquivo de dados se tornam chaves
estrangeiras na tabela de imagem do arquivo de dados. Em
geral, a chave primria e as chaves estrangeiras so todas
indexadas. Nesse tipo de organizao, a imagem do arquivo de
dados chamada uma tabela de fatos e as imagens dos arquivos
de catlogo so chamadas tabelas de dimenses. O projeto
global chamado esquema dimensional ou esquema em estrela,
devido sua aparncia quando desenhado como um diagrama de
entidades/relacionamentos (a tabela de fatos circundada e
est conectada s tabelas de dimenses). Nota: a razo para a
terminologia de dimenses ser explicada na Seo 2 1.6.
Como ilustrao, vamos modificar o banco de dados de
fornecedores e peas mais uma vez, agora com a finalidade de
mostrar para cada remessa o perodo de tempo especfico em
que essa remessa ocorreu. Identificamos perodos de tempo
atravs de um identificador de perodo de tempo (TP#), e
introduzimos outra tabela TP para relacionar esses
identificadores com os perodos correspondentes em si. Ento,
a tabela de remessas revisada FP e a nova tabela de perodos
de tempo TP seriam semelhantes s da Figura 2 1 .3 . Na
terminologia do esquema em estrela, a tabela FP a tabela de
fatos e tabela TP uma tabela de dimenses (como tambm a
tabela F de fornecedores e a tabela P de peas ver Figura
21.4). Nota:
lembramos mais uma vez que a questo geral de tratamento de
dados de perodos de tempo ser discutida em detalhes no
Captulo 22.
A consulta a um banco de dados de esquema em estrela
normalmente envolve o uso de tabelas de dimenses para
encontrar todas as combinaes de chaves estrangeiras de
interesse, e depois usar essas combinaes para obter acesso
tabela de fatos. Supondo que os acessos a tabelas de
dimenses e o acesso subsequente tabela de fatos estejam
todos incorporados em uma nica consulta, a melhor maneira de
implementar essa consulta em geral atravs daquilo que se
chama juno em estrela. Juno em estrela uma estratgia
especfica de implementao de juno; ela difere das
estratgias usuais pelo fato de comear deliberadamente pelo
clculo de um produto cartesiano, ou seja, o produto
cartesiano das tabelas de dimenses. Como vimos no Captulo
17, em geral os otimizadores de consultas tentam evitar o
clculo de produtos cartesianos [17.54 e 17.551; porm, nesse
caso, formar primeiro o produto das tabelas de dimenses
muito menores, e depois usar o resultado para executar
pesquisas baseadas em ndices sobre a tabela de fatos quase
sempre mais eficiente que qualquer outra estratgia. Segue-se
que os otimizadores tradicionais exigem alguma reengenharia
para lidar com consultas a esquemas em estrela de modo
eficiente.
* No existe nenhuma relao com catlogos no sentido moderno
do termo para bancos de dados.
**As colunas DE e PARA da tabela TP contm dados do tipo
timbre de hora. Para simplificar, no mostraremos valores
reais de
timbre de hora na figura, mas em vez disso vamos represent-
los simbolicamente. 613
TP# DE PARA
FIGURA 21.3 Amostra de tabela de fatos (FP) e tabela de
dimenses (TP)
FIGURA 2 1.4 Esquema em estrela para fornecedores e peas
(com perodos de tempo)
Neste momento voc deve estar agora imaginando qual a
diferena entre um esquema em estrela e aquilo que
consideraramos propriamente um projeto . De fato, um esquema
em estrela simples como o que discutimos antes pode parecer
muito semelhante (at mesmo idntico) a um bom projeto
relacional. Porm, infelizmente, existem vrios problemas com
a abordagem geral de esquema em estrela:
1 . Em primeiro lugar, ela ad hoc (baseia-se na intuio,
mais que em um princpio). Essa falta de disciplina torna
difcil mudar o esquema de modo apropriado quando (por
exemplo) novos tipos de dados so acrescentados ao banco de
dados ou quando as dependncias mudam. De fato, os esquemas
em estrela frequentemente so construdos pela simples edio
de um projeto anterior, e esse projeto anterior por sua vez
muitas vezes elaborado por tentativa e erro.
2. Os esquemas em estrela na verdade so fsicos, e no
lgicos, embora sejam mencionados como se fossem lgicos. O
problema que realmente no existe na abordagem do esquema
em estrela nenhum conceito de projeto lgico como algo
distinto do projeto fsico.
3. A abordagem do esquema em estrela nem sempre resulta em um
projeto fsico legtimo (isto , um projeto que preserve
todas as informaes em um projeto lgico correto, de acordo
com os princpios relacionais). Essa deficincia se torna
tanto mais aparente quanto mais complexo o esquema.
4. Como existe pouca disciplina, os projetistas muitas vezes
incluem vrios tipos diferentes de fatos na tabela de fatos.
Em consequncia, as linhas e colunas da tabela de fatos em
geral no tm uma interpretao uniforme. Alm disso, certas
colunas se aplicam ento tipicamente apenas a certos tipos de
fatos, implicando que as colunas em questo devem permitir
nulos. A medida que mais e mais tipos de fatos so includos,
torna-se cada vez mais difcil manter e entender a tabela, e
o acesso fica cada
FP
TP
F L FNOME STATUS CIDADE TP [TP# DE PARA FP [LL..JLrP# 1 QDE
P PNOME COR PESO CIDADE
614
F#
Fi P#
P1 TP#
TP3 QDE
300
Fi P1 TP5 100
Fi P2 TP1 200
Fi P3 TP2 400
Fi P4 TP1 200
Fi P5 TP5 100
Fi P6 TP4 100
F2 P1 TP3 300
F2 P2 TP4 400
F3 P2 TP1 200
F3 P2 TP3 200
F4 P2 TP1 200
F4 P4 TP3 200
F4 P5 TP2 400
TP1 ta tb
TP2 tc td
TP3 te tf
TP4 tg th
TP5 ti ti
vez menos eficiente. Por exemplo, poderamos decidir
modificar a tabela de remessas para controlar compras de
peas, bem como remessas de pea. Ento, precisaremos de
algum tipo de coluna flag para mostrar quais linhas
correspondem a compras e quais a remessas. Em contraste, um
projeto apropriado criaria uma tabela de fatos distinta para
cada tipo distinto de fatos.
5. Novamente, devido falta de disciplina, as tabelas de
dimenses tambm podem se tornar no uniformes. Em geral,
esse erro ocorre quando a tabela de fatos usada para manter
dados que pertencem a diferentes nveis de agregao. Por
exemplo, podemos (de forma equivocada) acrescentar linhas
tabela de remessas que mostrem as quantidades totais de peas
para cada dia, cada ms, cada trimestre, cada ano, e at
mesmo o total geral at a data atual. Primeiro, note que essa
mudana faz com que as colunas do identificador de perodo de
tempo (TP#) e da quantidade (QDE) na tabela FP tenham
significados no uniformes. Suponha agora que cada uma das
colunas DE e PARA da tabela de dimenses TP seja substituda
por uma combinao de colunas ANO, MES, DIA, etc. Ento,
todas essas colunas ANO, MES, DIA, etc. devem agora permitir
nulos. Alm disso, bem provvel que tambm seja necessria
uma coluna flag, a fim de indicar o tipo do perodo de tempo
aplicvel.
6. Com frequncia, as tabelas de dimenses no esto
completamente normalizadas.* O desejo de evitar junes
muitas vezes leva os projetistas a reunirem nessas tabelas
informaes distintas que seria melhor manter separadas. No
caso extremo, colunas a que somente se deva ter acesso em
conjunto so mantidas juntas na mesma tabela de dimenses.
Devemos deixar claro que seguir uma disciplina to extrema
e no relacional quase certamente levar a uma redundncia
descontrolada e provavelmente incontrolvel.
Observamos finalmente que uma variante do esquema em estrela
o esquema em floco de neve, que normaliza as tabelas de
dimenses. Novamente, o nome derivado da aparncia do
esquema quando traado como um diagrama de
entidades/relacionamentos. Os termos esquema de constelao e
esquema de temporal (ou nevasca) tambm tm sido muito
ouvidos recentemente, com os significados bvios (?).
21.6 PROCESSAMENTO ANALITICO ON-LINE
O termo processamento analtico on-line (ou OLAP, de online
analytical processing) foi cunhado em um white paper escrito
para aArbor Software Corp. em 1993 [21.10], embora (como
ocorre com o termo data warehouse), o conceito seja muito
mais antigo. Ele pode ser definido como o processo
interativo de criar, administrar, analisar e gerar relatrios
sobre dados e habitual acrescentar que os dados em
questo so percebidos e manipulados como se estivessem
armazenados em um array multidimensional. Porm, optamos
por explicar as idias primeiro em termos de tabelas
convencionais no estilo de SQL, antes de entrarmos na questo
da representao multidimensional propriamente dita.
O primeiro ponto importante que o processamento analtico
exige invariavelmente algum tipo de agregao de dados,
normalmente de muitos modos diferentes (isto , de acordo com
muitos agrupamentos diferentes). De fato, um dos problemas
fundamentais do processamento analtico que o nmero de
agrupamentos possveis se torna muito grande bem depressa. E
ainda que os usurios precisam considerar todos ou a maioria
deles. Agora, claro que as linguagens relacionais oferecem
suporte para tal agregao, mas cada consulta individual em
uma dessas linguagens produz apenas uma tabela como seu
resultado (e todas as linhas nessa tabela tm a mesma forma e
o mesmo tipo de interpretao). Desse modo, obter n
agrupamentos distintos exige n consultas distintas e produz n
tabelas de resultados distintas. Por exemplo, considere as
seguintes consultas sobre o banco de dados de fornecedores e
peas usual:
1. Obter a quantidade total de remessas.
2. Obter as quantidades totais de remessas por fornecedor.
3. Obter as quantidades totais de remessas por pea.
* Aqui temos um conselho extrado de um livro sobre data
warehouses: [Resista ] normalizao Os esforos para
normalizar qualquer das tabelas em um banco de dados
dimensional unicamente para poupar espao em disco [sic] so
um desperdcio de tempo ... As tabelas de dimenses no devem
ser normalizadas ... Tabelas de dimenses normalizadas
destroem a capacidade de procura [21.211]. 615
4. Obter as quantidades totais de remessas por fornecedor e
por pea. Nota: claro que a quantidade total para um dado
fornecedor e uma determinada pea apenas a quantidade real
para esse fornecedor e essa pea. O exemplo seria mais
realista se usssemos o banco de dados de fornecedores, peas
e projetos. Porm, vamos ficar com fornecedores e peas por
simplicidade.
FP
Vamos supor que existam apenas duas peas, P1 e P2, e a
tabela de remessas seja semelhante a esta:
1. SELECT SIJM(QDE) AS QDETOTAL FROM FP
GROUP BY O
2. SELECT F#,
SUM(QDE) AS QDETOTAL
FROM FP
GROUP BY (F#)
F# QDETOTAL
3. SELECT P#,
SUM(QDE) AS QDETOTAL
FROM FP
GROUP BY (P#) ;
4. SELECT F#, P#, SUM(QDE) AS QDETOTAL
FP FROM
FP GROUP BY (F#,P#) ;
Ento, aqui esto formulaes de SQL* das quatro consultas e
os resultados correspondentes:
As desvantagens dessa abordagem so bvias: a formulao de
tantas consultas similares mas distintas tediosa para o
usurio, e a execuo de todas essas consultas com a
passagem repetitiva sobre os mesmos dados provavelmente
ser bastante dispendiosa em tempo de execuo. Desse modo,
parece valer a pena tentar encontrar um modo de (a) solicitar
vrios nveis de agregao em uma nica consulta e assim (b)
oferecer implementao a oportunidade de calcular todas
essas agregaes de forma mais eficiente (isto , em uma
nica passagem). Essas consideraes so a motivao que rege
as opes GROUPING SETS, ROLLUP e CUBE na clusula GROUP BY.
Nota: essas opes j so admitidas em diversos produtos
comerciais. Elas tambm esto includas em SQL3 (consulte o
Apndice B).
A opo GROUPING SETS permite ao usurio especificar
exatamente os agrupamentos particulares a serem executados.
Por exemplo, a instruo SQL a seguir representa uma
combinao das consultas
2 e 3:
* Talvez devssemos dizer pseudoformulaes de SQL, porque
a SQL/92 no permite que operandos de GROUP BY sejam
includos entre parnteses, nem permite de modo algum uma
clusula GROUP BY sem operandos (embora, omitir por inteiro a
616 clusula GROUP BY seja logicamente equivalente a
especificar uma dessas clusula sem operandos).
QDETOTAL
1600
F1
F2
F3
F4
500
700
200
200
F# P# QDE
F1 P1 300
F1 P2 200
F2 P1 300
F2 P2 400
F3 P2 200
F4 P2 200
QDETOTAL
i_ P1 300
F1 P2 200
F2 P1 300
F2 P2 400
F3 P2 200
F4 P2 200
SELECT F#, P#, SUM(QDE) AS QDETOTAL
FROM FP
GROUP BY GROUPING SETS ( (F#), (P#) )
Aqui, a clusula GROUP BY est efetivamente pedindo ao
sistema que execute duas consultas, uma na qual o agrupamento
por F# e outra na qual ele feito por P#. Nota: na
realidade, os parnteses internos no so necessrios nesse
exemplo, pois cada um dos conjuntos de agrupamento envolve
apenas uma coluna; contudo, mostramos esses parnteses por
questo de clareza.
Agora, a idia de reunir vrias consultas distintas em uma
nica instruo dessa maneira pode ser inquestionvel em si
(embora devamos dizer que seria prefervel ver essa questo
muito genrica atacada de um modo mais geral, sistemtico e
ortogonal). Infelizmente, porm, a SQL continua a reunir os
resultados dessas consultas logicamente distintas em uma
nica tabela de resultados! * No exemplo, essa tabela de
resultados seria semelhante a:
Esse resultado pode ser realmente imaginado como uma tabela
(na realidade, uma tabela no estilo de SQL), mas dificilmente
uma relao. Observe que as linhas de fornecedores (aquelas
que tm nulos na posio P#) e as linhas de peas (que tm
nulos na posio F#) tm interpretaes muito diferentes.
Alm disso, o significado dos valores de QDETOTAL varia de
acordo com o fato de eles aparecerem em uma linha de
fornecedor ou em uma linha de pea. Ento, qual o predicado
para essa relao?
Observamos tambm que os nulos nesse resultado constituem
ainda outro tipo de informao omitida. Sem dvida, eles
no significam valor desconhecido ou valor no aplicvel,
mas o que querem dizer exatamente muito obscuro. Nota: a
SQL pelo menos oferece um meio de distinguir esses novos
nulos de outros tipos, mas os detalhes so tediosos e foram
efetivamente o usurio a um tipo de raciocnio de uma linha
de cada vez. Omitimos esses detalhes aqui, mas voc pode ter
alguma idia do que est envolvido a partir do exemplo a
seguir (que indica qual possivelmente teria de ser na prtica
a aparncia do exemplo de GROUPING SETS mostrado antes):
SELECT CASE GROUPING (F#) ver Apndice A re CASE
WHEN 1 THEN `?????`
ELSE F#
AS F#,
CASE GROUPING (P#) ver Apndice A re CASE
WHEN 1 THEN
ELSE P#
AS P#,
SUM(QDE) AS QDETOTAL
FROM FP
GROUP BY GROUPING SETS ( (F#), (P#) )
Vamos voltar especificamente a GROUP BY. As outras duas
opes de GROUP BY, ROLLUP e CUBE, so ambas abreviaes para
certas combinaes de GROUPING SETS. Primeiro, vejamos
ROLLUP. Considere a seguinte consulta:
* Essa nica tabela pode ser considerada uma unio externa
(outer union) na verdade, uma forma extremamente bizarra de
unio externa desses resultados. Deve ficar claro pelo que
foi dito no Captulo 18 que, mesmo em sua forma menos
bizarra, a unio externa no uma operao relacional
respeitvel. 617
=i== P# QDETOTAL
F1 nulo 500
F2 nulo 700
3 nulo 200
4 nulo 200
nulo P1 600
nulo P2 1000
SELECT F#, P#, SUM(QDE) AS QDETOTAL
FROM FP
GROUP BY ROLLUP (F#), (P#)
Nesse caso, a clusula GROUP BY logicamente equivalente a:
GROUP BY GROUPING SETS ( (F#,P#), (F#), O )
Em outras palavras, a consulta uma formulao de SQL que
rene as consultas 4, 2 e 1. O resultado semelhante a este:
O termo ROLLUP deriva do fato de que (no exemplo) as
quantidades so reunidas para cada fornecedor (isto ,
reunidas ao longo da dimenso de fornecedor consulte a
subseo Bancos de dados multidimensionais, mais adiante).
Em geral, GROUP BY ROLLUP (A, B, ..., Z ) informalmente,
reunir ao longo da dimenso A significa agrupar por
todas as combinaes seguintes:
( A, B, . . . ,
( A, B, . . .
( A, B
(A)
Observe que, em geral, existem muitos agrupamentos distintos
ao longo da dimensoA (depende de quais so as outras
colunas mencionadas na lista_com_vrgulas de ROLLUP). Observe
tambm que GROUP BY ROLLUP ( A, B ) e GROUP BY ROLLUP ( B, A)
tm significados diferentes isto , GROUP BY ROLLUP ( A, B)
no simtrica em A e B.
Agora vamos tratar de CUBE. Considere a seguinte consulta:
SELECT F#, P#, SUM(QDE) AS QDETOTAL
FROM FP
GROUP BY CUBE ( F#, P# )
Agora, a clusula GROUP BY logicamente equivalente a:
GROUP BY GROUPING SETS ( (F#,P#), (F#), (P#), O )
Em outras palavras, a consulta uma formulao de SQL que
rene as nossas quatro consultas originais, 4, 3, 2 e 1. O
resultado semelhante a:
618
P# QDETOTAL
F1 P1 300
F1 P2 200
F2 P1 300
F2 P2 400
F3 P2 200
F4 P2 200
F1 nulo 500
F2 nulo 700
F3 nulo 200
F4 nulo 200
nulo nulo 1600
o termo CUBE, no muito esclarecedor, deriva do fato de que,
na terminologia de OLAP (ou pelo menos na terminologia
multidimensional), os valores de dados podem ser percebidos
como estando armazenados nas clulas de um array
multidimensional ou hipercubo. No caso, (a) os valores de
dados so quantidades; (b) o cubo tem apenas duas
dimenses, uma dimenso de fornecedores e uma dimenso de
peas ( e ento o cubo de fato plano!); e, claro, (c)
essas duas dimenses tm tamanhos desiguais (ento, o cubo
no nem sequer um quadrado, mas sim um retngulo geral). De
qualquer modo, GROUP BY CUBE ( A, B, ..., Z ) significa
agrupar por todos os subconjuntos possveis do conjunto { A,
B, ..., Z }.
A clusula GROUP BY pode incluir qualquer mistura de
especificaes de GROUPING SETS, ROLLUP e CUBE.
Tabulaes cruzadas
Os produtos de OLAP frequentemente exibem resultados de
consultas no como tabelas no estilo de SQL, mas como
tabulaes cruzadas (vamos usar crosstabs para abreviar).
Considere uma vez mais a consulta 4 (Obter quantidades
totais de remessas por fornecedor e pea). Aqui est uma
representao de crosstab do resultado dessa consulta. A
propsito, observe que mostramos as quantidades da pea P1
para fornecedores F3 e F4 (corretamente) como zero; em
contraste, a SQL diria que essas quantidades devem ser nulas
(consulte o Captulo 18). De fato, a tabela que a SQL possui
em resposta consulta 4 no contm nenhuma linha para
(F3,P1) ou (F4,P1)! e, em consequncia disso, a produo da
crosstab a partir dessa tabela no inteiramente trivial.
P1 P2
Essa crosstab sem dvida um modo mais compacto e legvel de
representar o resultado da consulta 4. Alm disso, ela se
parece um pouco com uma tabela relacional. Porm, observe que
o nmero de colunas nessa tabela depende dos dados reais;
para sermos especficos, existe uma coluna para cada tipo de
pea (e assim a estrutura da crosstab e o significado das
linhas dependem ambos dos dados reais). Desse modo, uma
crosstab no uma relao, mas sim um relatrio: para sermos
mais especficos, um relatrio formatado como um array
simples. (As relaes tm um predicado que pode ser deduzido
a partir do(s) predicado(s) para a(s) relao(es) da(s)
qual(is) elas derivam; em contraste, o predicado para uma
crosstab se isso pudesse at mesmo existir, em geral no
pode ser derivado do(s) predicado(s) para a(s) relao(es)
da(s) qual(is) ela deriva pois, como acabamos de ver, ele
depende de valores de dados.)
Crosstabs como essas que acabamos de ver so consideradas com
frequncia como de duas dimenses, nesse caso fornecedores e
peas. As dimenses so tratadas como se fossem variveis
independentes; as clulas de interseo contm ento
valores das variveis dependentes correspondentes. Consulte a
subseo Bancos de dados multidimensionais a seguir para
ver uma explicao adicional.
Aqui est outro exemplo de crosstab, representando o
resultado do exemplo de CUBE anterior:
P# QDETOTAL
P1 300
F1 P2 200
F2 P1 300
F2 P2 400
F3 P2 200
F4 P2 200
F1 nulo 500
F2 nulo 700
F3 nulo 200
F4 nulo 200
nulo P1 600
nulo P2 1000
nulo nulo 1600
F1 300 200
F2 300 400
F3 0 200
F4 0 200
A coluna da extremidade direita contm totais de linhas (isto
, totais para o fornecedor indicado atravs de todas as
peas), e a linha inferior contm totais de colunas (isto ,
totais para a pea indicada por todos os fornecedores). A
clula de parte inferior direita contm o total geral, que
a linha total de todos os totais de colunas e a coluna total
de todos os totais de linhas.
Bancos de dados multidimensionais
At agora, estivemos supondo que nossos dados OLAP esto
armazenados em um banco de dados de SQL convencional (embora
tenhamos mencionado algumas vezes a terminologia e conceitos
de bancos de dados multidimensionais). De fato, descrevemos
tacitamente aquilo que s vezes se chama ROLAP (OLAP
relacional). Porm, muitas pessoas acreditam que MOLAP
(OLAP multidimensional) uma forma melhor. Nesta subseo,
examinaremos mais de perto o MOLAP.
O MOLAP envolve um banco de dados multidimensional, um banco
de dados no qual os dados esto armazenados conceitualmente
nas clulas de um array multidimensional. (Nota: dizemos
armazenados conceitualmente, mas de fato a organizao
fsica em MOLAP tende a ser bem parecida com a organizao
lgica.) O SGBD de suporte chamado SGBD multidimensional.
Como um exemplo simples, os dados poderiam ser representados
como um array de trs dimenses, correspondendo a produtos,
clientes e perodos de tempo, respectivamente; cada valor de
clula individual pode ento representar a quantidade total
do produto indicado vendido ao cliente indicado no perodo de
tempo indicado. Como j observamos, as crosstabs da subseo
anterior tambm podem ser consideradas arrays desse tipo.
Agora, em um conjunto de dados bem compreendido, todos os
relacionamentos seriam conhecidos, e as variveis
envolvidas (no-variveis no sentido usual de linguagens de
programao) poderiam ento ser classificadas de modo
informal como dependentes ou independentes. Considerando-se o
exemplo anterior, produto, cliente e perodo de tempo seriam
as variveis independentes e quantidade seria a nica
varivel dependente. De modo mais geral, as variveis
independentes so variveis cujos valores determinam juntos
os valores de variveis dependentes (da mesma forma que, em
termos relacionais, uma chave candidata um conjunto de
colunas cujos valores determinam os valores de outras
colunas). Desse modo, as variveis independentes formam as
dimenses do array pelo qual os dados so organizados e
formam um esquema de endereamento para esse array,* e
valores de variveis dependentes que constituem os dados
reais podem ento ser armazenados nas clulas desse array.
Nota: a distino entre valores de variveis independentes ou
dimensionais e valores de variveis dependentes ou no
dimensionais s vezes caracterizada como local versus
contedo.
Infelizmente, a caracterizao anterior de bancos de dados
multidimensionais um pouco simplista, porque a maioria dos
conjuntos de dados no so bem compreendidos. Na verdade,
por essa razo que desejamos analisar os dados: para obter
uma compreenso melhor. Frequentemente, a falta de
compreenso severa o suficiente para no sabermos com
antecedncia quais variveis so independentes e quais so
dependentes variveis independentes so escolhidas muitas
vezes com base na crena atual (isto , hiptese) e o array
resultante ento testado para ver como ele funciona
(consulte a Seo 2 1.7). Essa abordagem vai envolver
claramente muita repetio, alm de tentativa e erro. Por
essas razes, o sistema em geral permitir que variveis
dimensionais e no dimensionais sejam trocadas, uma operao
conhecida como pivoteamento. Outras operaes admitidas
incluiro transposio de arrays e reordenao dimensional.
Tambm haver um modo para acrescentar dimenses.
*Assim, as clulas de arrays so endereadas simbolicamente,
e no pelos subscritos numricos associados de forma mais
convencional com arrays. 620
P1
P2
Total
F1 300 200 500
F2 300 400 700
F3 0 200 200
F4 O 200 200
Total 600 1000 1600
A propsito, deve ficar claro da descrio anterior que
clulas de arrays com frequncia estaro vazias, e assim os
arrays muitas vezes sero esparsos. Por exemplo, suponha que
o produto p no tenha sido vendido ao cliente c em todo o
perodo t; ento, a clula (c,p,t) estar vazia (ou, na
melhor das hipteses, conter zero). Os SGBDs
multidimensionais admitem vrias tcnicas para armazenar
arrays esparsos de algum modo mais eficiente (compactado).*
Observe ainda que essas clulas vazias correspondem a
informaes omitidas, e os sistemas precisam assim oferecer
algum suporte computacional para elas e os sistemas em
geral o fazem, de um modo semelhante ao de SQL
(infelizmente). Note que o fato de uma determinada clula
estar vazia pode significar que a informao desconhecida,
no foi capturada, ou no aplicvel, alm de ter muitos
outros significados (consulte o Captulo 18 mais uma vez).
As variveis independentes frequentemente esto relacionadas
em hierarquias, as quais determinam meios para agregar dados
dependentes. Por exemplo, existe uma hierarquia temporal
relacionando segundos a minutos, horas, dias, semanas, meses,
anos. Como outro exemplo, poderia haver uma hierarquia
relacionando peas a kits de montagem, componentes, placas e
produtos. Com frequncia, os mesmos dados podem ser agregados
de vrias maneiras diferentes (isto , a mesma varivel
independente pode pertencer a muitas hierarquias distintas).
O sistema fornecer operadores para percorrer essas
hierarquias para cima (drill up) e para abaixo (drill
down); drill up significa ir de um nvel mais baixo de
agregao at um nvel mais alto, enquanto drill down
significa o oposto. Numerosas outras operaes tambm esto
disponveis para se lidar com tais hierarquias (por exemplo,
uma operao para reorganizar os nveis hierrquicos).
Nota: existe uma diferena sutil entre drill up e roll
up, assim: roll up a operao de criar os agrupamentos e
as agregaes desejadas; drill up a operao de obter
acesso a essas agregaes. No caso de drill up, um exemplo
poderia ser: dada a quantidade total de remessas, obter as
quantidades totais para cada fornecedor individual. claro
que os dados mais detalhados devem estar disponveis (ou
poder ser calculados) em ordem para sermos capazes de
responder a tal solicitao.
Em geral, os produtos multidimensionais tambm fornecem uma
variedade de funes estatsticas e outras funes
matemticas para ajudar a formular e testar hipteses (isto
, relacionamentos hipotticos). Ferramentas para
visualizao e gerao de relatrios tambm so fornecidas, a
fim de ajudar nessas tarefas. Porm, infelizmente, ainda no
existe nenhuma linguagem padro para consulta
multidimensional, embora estejam sendo realizadas pesquisas
para se desenvolver um clculo no qual esse padro poderia se
basear [21.27]. Tambm no h nada anlogo teoria de
normalizao que pudesse servir como uma base cientfica para
o projeto de bancos de dados multidimensionais.
Fechamos esta seo observando que alguns produtos combinam
as abordagens de ROLAP e MOLAP; HOLAP (OLAP hbrido).
Existe uma controvrsia considervel sobre qual das trs
abordagens melhor, e pouco se pode fazer aqui para ajudar
a resolver essa controvrsia.** Porm, de modo geral, os
produtos MOLAP oferecem computao mais rpida, mas admitem
quantidades de dados menores que os produtos ROLAP
(tornando-se menos eficientes medida que a quantidade de
dados aumenta), enquanto os produtos ROLAP oferecem recursos
de escalabilidade, concorrncia e gerenciamento mais
amadurecidos que os de produtos MOLAP.
21.7 MINERAO DE DADOS
A minerao de dados pode ser descrita como anlise de dados
exploratria. O objetivo procurar padres interessantes
nos dados, padres que possam ser usados para definir a
estratgia do negcio ou
* Observe o contraste com sistemas relacionais. Em um anlogo
relacional apropriado do exemplo, no teramos uma linha
(c,p,t) com uma quantidade clula vazia, mas simplesmente
no teramos nenhuma linha (c,p,t). Assim, o conceito de
arrays esparsos ou melhor, de tabelas esparsas no
surge, e no h necessidade de tcnicas elegantes de
compresso para lidar com eles.
** Contudo, ainda existe algo que precisa ser dito. Com
frequncia, afirma-se que tabelas so planas (isto ,
bidimensionais), enquanto dados reais so multidimensional,
e portanto que as relaes so inadequadas como uma base para
OLAP. Porm, esse tipo de discusso serve para confundir
tabelas e relaes! Como vimos no Captulo 5, tabelas so
apenas retratos de relaes, no relaes propriamente ditas.
Alm disso, embora seja verdade que esses retratos so
bidimensionais, as relaes no o so: em vez disso, elas so
n-dimensionais, onde n o grau. Para sermos mais precisos,
cada tupla em uma relao com n atributos representa um ponto
no espao n-dimensional, e a relao como um todo representa
um conjunto desses pontos. 621
para identificar um comportamento pouco usual (por exemplo,
um aumento sbito na atividade de um carto de crdito
poderia significar que o carto foi roubado). As ferramentas
de minerao de dados aplicam tcnicas estatsticas a grandes
quantidades de dados armazenados, a fim de procurar por tais
padres. Nota: a palavra grande precisa ser enfatizadas aqui.
Os bancos de dados de minerao de dados com frequncia so
extremamente grandes, e importante que os algoritmos sejam
escalveis.
FIGURA 21.5 Atabela VENDAS
Considere a tabela (no muito grande!) VENDAS mostrada na
Figura 21.5, que fornece informaes relativas a transaes
de vendas de um certo negcio de varejo.* O administrador do
negcio gostaria de executar uma anlise de cesta de mercado
sobre esses dados (onde o termo cesta dc mercado se refere
ao conjunto de produtos adquiridos em uma nica transao),
descobrindo assim, por exemplo, que um cliente que compra
sapatos provavelmente tambm comprar meias como parte da
mesma transao. Essa correlao entre sapatos e meias um
exemplo de uma regra de associao; ela pode ser expressa (de
modo um pouco informal) assim:
FORALL tx ( Sapatos e tx = Meias etx
(onde Sapatos tx a regra antecedente, Meias 6 tx a
regra consequente, e tx varia sobre todas as transaes de
vendas).
Introduzimos alguma terminologia. O conjunto de todas as
transaes de vendas no exemplo chamado populao. Qualquer
regra de associao dada tem um nvel dc suporte e um nvel
de confiana. O suporte a frao da populao que satisfaz
regra. A confiana a frao dessa poro da populao em
que o antecedente satisfeito, na qual o consequente tambm
satisfeito. (Observe que o antecedente e o consequente
podem envolver qualquer nmero de produtos diferentes cada
um, no necessariamente apenas um produto.) Por exemplo,
considere esta regra:
FORALL tx ( Meias e tx = Gravata e tx
Considerando-se a amostra de dados da Figura 21.5, a
populao 4, o suporte 50% e a confiana
66,67%.
Regras de associao mais gerais poderiam ser descobertas a
partir de agregaes apropriadas dos dados fornecidos. Por
exemplo, o agrupamento por cliente nos permitiria testar a
validade de regras
* Observe que (a) a chave {TX#,PRODUTO}; (b) a tabela
satisfaz s FDs TX# * CLIEN# e TX# * TIMESTAMP e poranto
no est em FNBC; (c) uma verso da tabela em que a coluna
PRODUTO tem valor de relao (e TX a chave) estaria em FNBC
e poderia ser mais adequada para o tipo de explorao
envolvida no caso em estudo (mas provavelmente no seria
ade622 quada para outros tipos).
VENDAS
TX# CLIEN# TIMBREHORA PRODUTO
TX1 Cl dl Sapatos
TX1 Cl dl Meias
TX1 Cl dl Gravata
TX2 C2 d2 Sapatos
TX2 C2 d2 Meias
TX2 C2 d2 Gravata
TX2 C2 d2 Cinto
TX2 C2 d2 Camisa
TX3 C3 d2 Sapatos
TX3 C3 d2 Gravata
TX4 C2 d3 Sapatos
TX4 C2 d3 Meias
TX4 C2 d3 Cinto
como se um cliente compra sapatos, provvel que ele tambm
compre meias, embora no necessariamente na mesma transao.
Outros tipos de regras tambm podem ser definidos. Por
exemplo, uma regra de correlao de sequncia poderia ser
usada para identificar padres de compra ao longo do tempo
(Se um cliente compra sapatos hoje, provvel que ele
compre meias dentro de cinco dias). Uma regra de
classificao poderia ser usada para ajudar a decidir se uma
aplicao de crdito deve ser concedida (Se um cliente
possui renda superior a $ 75.000 por ano, provvel que ele
seja um bom risco de crdito); e assim por diante. Como as
regras de associao, as regras de correlao de sequncia e
as regras de classificao tambm tm um nvel de suporte e
um nvel de confiana.
A minerao de dados um assunto enorme por si s [21.11 e
claro que no possvel entrarmos em muitos detalhes aqui.
Ento, vamos nos limitar a encerrar com uma breve descrio
de como as tcnicas de minerao de dados poderiam se aplicar
a uma verso estendida de fornecedores e peas. Primeiro (na
ausncia de outras fontes de informaes), poderamos usar
induo neural para classificar fornecedores por sua
especialidade (por exemplo, grampos versus peas de
mquinas), e a previso de valores para prever quais
fornecedores tero maior probabilidade de poder fornecer
quais peas. Podemos ento usar o clustering demogrfico para
associar as despesas de remessas com a localizao
geogrfica, designando assim fornecedores para regies de
remessas. A descoberta da associao poderia ento ser usada
para descobrir que certas peas em geral so obtidas juntas
em uma nica remessa; a descoberta do padro sequencial para
descobrir que remessas de grampos geralmente so seguidas por
remessas de peas de mquinas; e a descoberta da sequncia
temporal semelhante para descobrir que existem mudanas
sazonais de quantidade em remessas de determinadas peas
(algumas dessas mudanas ocorrendo no outono e algumas na
primavera).
21.8 RESUMO
Examinamos o uso de tecnologia de bancos de dados com a
finalidade de oferecer apoio deciso. A idia bsica
coletar dados operacionais e reduzi-los a uma forma que possa
ser usada para ajudar a gerncia a entender e modificar o
comportamento da empresa.
Primeiro, identificamos certos aspectos de sistemas de apoio
deciso que os distinguem de sistemas operacionais. O ponto
fundamental que o banco de dados principalmente (embora
no em sua totalidade) somente de leitura. Os bancos de dados
de apoio deciso tendem a ser muito grandes e fortemente
indexados, e tambm a envolver uma grande quantidade de
redundncia controlada (em especial, sob a forma de replica
o e de agregaes pr-calculadas), as chaves tendem a
envolver um componente temporal, e consultas tendem a ser
complexas. Como consequncia de tais consideraes, existe
uma nfase em projetar visando ao desempenho; concordamos com
a nfase, mas acreditamos que ela no deve interferir com a
boa prtica de projeto. O problema que, na prtica, os
sistemas de apoio deciso em geral no fazem distino
adequada entre consideraes lgicas e fsicas.
Em seguida, discutimos o que est envolvido na preparao de
dados operacionais para apoio deciso. Examinamos as
tarefas de extrao, limpeza, transformao e consolidao,
carga e renovao. Tambm mencionamos rapidamente os
depsitos de dados operacionais, que podem ser usados (entre
outras coisas) como rea de apoio durante o processo de
preparao de dados. Eles tambm podem ser usados para
fornecer servios de apoio deciso sobre dados atuais.
Ento, consideramos os data warehouses e data marts; um data
marts pode ser considerado um data warehouse especializado.
Explicamos a idia bsica de esquemas em estrela, nos quais
os dados esto organizados como uma grande tabela de fatos
central e em vrias tabelas de dimenses muito menores. Em
situaes simples um esquema em estrela no pode ser
distinguido de um esquema normalizado clssico; porm, na
prtica, os esquemas em estrela se afastam dos princpios
clssicos de projeto de vrias maneiras, sempre por razes de
desempenho. (Novamente, o problema que os esquemas em
estrela tm, na realidade, uma natureza mais fsica do que
lgica.) Tambm mencionamos a estratgia de implementao de
junes conhecida como juno em estrela, e uma variante do
esquema em estrela chamada
esquema de floco de neve. 623
Em seguida, voltamos nossa ateno para o OLAP. Discutimos os
recursos de SQL GROUPING SETS, ROLLUP e CUBE (todos eles so
opes da clusula GROUP BY e fornecem meios para a
solicitao de vrias agregaes distintas dentro de uma
nica consulta de SQL). Observamos que a SQL (infelizmente,
em nossa opinio) reuniu os resultados dessas agregaes
distintas em uma nica tabela contendo uma grande
quantidade de nulos. Tambm sugerimos que, na prtica, os
produtos OLAP poderiam converter essas tabelas em crosstabs
(arrays simples) para fins de exibio. Observamos ento os
bancos de dados multidimensionais, em que os dados esto
conceitualmente armazenados, no em tabelas, mas em um array
multidimensional ou hipercubo. As dimenses desse array
representam variveis independentes e as clulas contm
valores das variveis dependentes correspondentes. As
variveis independentes em geral esto relacionadas em vrias
hierarquias, que determinam os meios pelos quais os dados
dependentes podem ser agrupados e agregados de modo sensato.
Por fim, consideramos a minerao de dados. A idia bsica
aqui que, como os dados de apoio deciso frequentemente
no so bem entendido, podemos a capacidade do computador
para nos ajudar a descobrir padres nesses dados.
Consideramos rapidamente vrias espcies de regras regras
de associao, classificao e correlao de sequncia e
discutimos as noes associadas de nveis de suporte e
confiana.
EXERCICIOS
21.1 Quais so alguns dos principais pontos de diferena
entre bancos de dados de apoio deciso e bancos de dados
operacionais? Por que as aplicaes de apoio deciso e as
aplicaes operacionais em geral utilizam depsitos de dados
diferentes?
21.2 Resuma os passos envolvidos na preparao de dados
operacionais para apoio deciso.
21.3 Faa distino entre redundncia controlada e no
controlada. D alguns exemplos. Por que a redundncia
controlada importante no contexto de apoio deciso? O que
acontece se a redundncia no controlada?
21.4 Mostre a diferena entre data warehouses e data marts.
21.5 O que voc entende pelo termo esquema em estrela?
21.6 Em geral, os esquemas em estrela no so totalmente
normalizados. Qual a justificativa para essa situao?
Explique a metodologia pela qual tais esquemas so
projetados.
21.7 Explique a diferena entre ROLAP e MOLAP.
21.8 De quantas maneiras os dados poderiam ser resumidos se
fossem caracterizados por quatro dimenses, cada uma das
quais pertencente a uma hierarquia de agregao de trs
nveis (por exemplo, cidade, municpio, estado)?
21.9 Usando o banco de dados de fornecedores, peas e
projetos (consulte o Exerccio 4.1 no Captulo 4), expresse
os seguintes itens como consultas de SQL:
a. Obter o nmero de remessas e as quantidades mdias de
remessas para fornecedores, peas e projetos considerados aos
pares (isto , para cada par F#-P#, cada par P#-J# e cada par
J#-F#).
b. Obter as quantidades mxima e mnima de remessa para cada
projeto, cada combinao de projeto/pea e global.
c. Obter quantidades totais de remessas reunidas ao longo da
dimenso de fornecedor e ao longo da dimenso de pea.
Ateno: h uma armadilha aqui.
d. Obter quantidades mdias de remessas por fornecedor, por
pea, por combinaes de fornecedor/pea e globais.
Em cada caso, mostre o resultado que a SQL produziria,
considerando-se a amostra de dados da Figura 4.5 (ou alguma
amostra de dados de sua escolha). Alm disso, mostre esses
resultados como crosstabs.
21.10 Perto do incio da Seo 21.6, mostramos uma verso
simples da tabela FP, contendo apenas seis linhas. Vamos
supor que essa tabela inclusse tambm a seguinte linha
(significando talvez! que o fornecedor F5 existe mas, no
momento, no fornece nenhuma pea):
F5 nu'o nulo 1
624 Discuta as implicaes para todas as diversas consultas
de SQL mostradas na Seo 21.6.
21.11 O termo dimensiona! tem o mesmo significado nas
expresses esquema dimensional e banco de dados
multidimensional? Explique sua resposta.
21.12 Considere o problema da anlise de cesta de mercado.
Esboce um algoritmo pelo qual as regras de associao que tm
nveis de apoio e confiana maiores que limiares
especificados possam ser descobertas. Sugesto: se alguma
combinao de produtos desinteressante porque ocorre em
poucas transaes de vendas, o mesmo ser verdadeiro para
todos os superconjuntos dessa combinao de produtos.
REFERNCIAS E BIBLIOGRAFIA
21.1 Pieter Adriaans e Dolf Zantinge: Data Mining. Reading,
Mass.: Addison-Wesley (1996).
Embora descrito como uma viso geral em nvel executivo, esse
livro realmente uma introduo bastante detalhada (e boa)
ao assunto.
21.2 S. Alter: Decision Support Systems: Current Practice and
Continuing Chailenges. Reading, Mass.: Addison-Wesley (1980).
21.3 J. L. Bennett (editor): Building Decision Support
Systems. Reading, Mass.: Addison-Wesley (1981).
21.4 M. J. A. Berry e G. Linoff: Data Mining Techniques for
Marketing, QTY, and Customer Support. Nova York, N.Y.:
McGraw-Hill (1997).
Uma boa explicao dos mtodos de minerao de dados e de seu
valor para aspectos selecionados do negcio.
21.5 J. B. Boulden: Com puter-Assisted Planning Systems. Nova
York, N.Y.: McGraw-Hill (1975).
Esse texto inicial focaliza muitas das preocupaes que mais
tarde vieram a ser reunidas sob o ttulo de apoio deciso.
Como indica o ttulo, a nfase est no planejamento da
administrao no sentido clssico.
21.6 R. H. Bonczek, C. W. Holsapple e A. Whinston:
Foundations of Decision Support Systems. Orlando, Fla.:
Academic Press (1981).
Um dos primeiros textos a promover uma abordagem disciplinada
aos sistemas de apoio deciso. Os papis da modelagem (no
sentido geral de modelagem emprica e matemtica) e de
cincia de administrao so enfatizados.
21.7 Charles J. Bontempo e Cynthia Maro Saracco: Database
Management: PrincipIes and Products. Upper Saddle River,
N.J.: Prentice-Hali (1996).
21.8 P. Cabena, P. Hadjinian, R. Stadler, J. Verhees e A.
Zanasi: Discovering Data Mining: From Concept to
Implementation. Upper Saddle River, N.J.: Prentice-HalI
(1998).
21.9 C. L. Chang: DEDUCE A Deductive Query Language for
Relational Data Bases, em C. H. Chen (editor), Pattern
Recognition and Artificial Intelligence. Nova York, N.Y.:
Academic Press (1976).
2 1.10 E. F. Codd, S. B. Codd e C. T. Salley: Providing OLAP
(Online Analytical Processing) to User-Analysts: An IT
Mandate, disponvel na Arbor Software Corp. (1993).
Como observamos no texto do captulo, esse artigo a origem
do termo OLAP (embora no do conceito). E interessante
notar que, prximo ao seu incio, o artigo declara
categoricamente que a necessidade que existe NAO de outra
tecnologia de bancos de dados, mas sim de ferramentas de
anlise robustas. Em seguida, ele comea a descrever e a
discutir outra tecnologia de bancos de dados! com uma nova
representao conceitual de dados, novos operadores (para
atualizao e tambm para busca), suporte multiusurio
(incluindo recursos de segurana e concorrncia), novas
estruturas de armazenamento e novas caractersticas de
otimizao; em outras palavras, um novo modelo de dados e um
novo
SGBD.
21.11 C. J. Date: We Don't Need Composite Columns, em C. J.
Date, Hugh Darwen e David McGoveran, Relational Database
Writings 1994-1997. Reading, Mass.: Addison-Wesley (1998).
O ttulo desse artigo se refere ao fato de que tentativas
(malsucedidas) foram feitas no passado a fim de introduzir o
suporte para colunas compostas sem base-lo no suporte para
tipos definidos pelo usurio. Se o suporte apropriado para
tipos definidos pelo usurio for oferecido, as colunas
compostas atingiro eventualmente o ponto desejvel.
625
21.12 Barry Devlin: Data Warehouse from Architecture to
Implementation. Reading, Mass.: Addison-Wesley (1997).
21.13 B. A. Devlin e P. T. Murphy: An Architecture for a
Business and Information System, IBM Sys.J. 27, Nmero
1(1988).
O primeiro artigo publicado a definir e usar o termo armazm
de informaes.
2 1.14 Herb Edelstein: Data Mining: Products and Markets.
Potomac, Md.: Two Crows Corp. (1997).
21.15 T. P. Gerrity, Jr.: The Design of Man-Machine Decision
Systems: An Application to Portfolio Management, Sloan
Management Review 12. Nmero 2 (inverno de 1971).
Um dos mais antigos artigos sobre sistemas de apoio
deciso. Ele descreve um sistema para apoio a gerentes de
investimentos em administrao de carteiras de aes.
21.16 Jim Gray, Adam Bosworth, Andrew Layman e Hamid
Pirahesh: Data Cube: A Relational Aggregation Operator
Generalizing Group-By, Cross-Tab, and Sub-Totais, Proc. l2th
IEEE Int. Conf. on Data Engineering, Nova Orleans, La.
(fevereiro de 1996).
O artigo que primeiro sugeriu a incluso de opes como CUBE
na clusula GROUP BY de SQL.
21.17 W. H. Inmon: Data Architecture: The Information
Paradigm. Wellesley, Mass.: QED Information Sciences (1988).
Discute a gnese do conceito de data warehouse e qual seria
na prtica a aparncia de um data warehouse. O termo data
warehouse apareceu pela primeira vez nesse livro.
21.18 W. H. Inmon: Building the Data Warehouse. Nova York,
N.Y.: Wiley (1992).
O primeiro livro dedicado a data warehouses. Ele define o
termo e discute os problemas fundamentais relacionados com o
desenvolvimento de um data warehouse. O artigo se preocupa
principalmente em justificar o conceito e com questes de
projeto operacional e fsico.
21.19 W. H. Inmon e R. D. Hackathorn: Using the Data
Warehouse. Nova York. N.Y.: Wiley (1994).
Uma discusso para usurios e administradores do data
warehouse. Como outros livros sobre o assunto, ele se
concentra em questes fsicas. O conceito de depsito de
dados operacionais discutido com algum detalhe.
21.20 P. G. W. Keen e M. S. Scott Morton: Decision Support
Systems: An Organizational Perspective. Reading, Mass.:
Addison-Wesley (1978).
Esse texto clssico um dos primeiros seno o primeiro a
examinar explicitamente o apoio deciso. A orientao
comportamental e cobre a anlise, o projeto, a implementao,
a avaliao e o desenvolvimento de sistemas de apoio
deciso.
21.21 Ralph Kimball: The Data Warehouse Toolkit. Nova York,
N.Y.: John Wiley & Sons (1996).
Um livro prtico. Como o subttulo Practical Techniques for
Building Dimensional Data Warehouses sugere, a nfase est
em questes pragmticas, no tericas. A suposio tcita em
todo o texto a de que no existe essencialmente nenhuma
diferena entre os nveis lgico e fsico do sistema. Essa
suposio tambm vlida para produtos atuais, claro;
porm, achamos que seria melhor tentar melhorar a situao em
vez de efetivamente apenas endoss-la.
2 1.22 J. D. C. Little: Models and Managers: The Concept of
a Decision Calculus, Management Science 16, Nmero 8 (abril
de 1970).
Esse artigo introduz um sistema (Brandaid) projetado para dar
suporte a decises sobre produtos, promoo, preos e
publicidade. O autor identifica quatro critrios para
projetar modelos com o objetivo de dar suporte tomada de
decises gerenciais: robustez, facilidade de controle,
simplicidade e completeza de detalhes relevantes.
21.23 M. 5. Scott Morton: Management Decision Systems:
Computer-Based Support for Decision Making. Universidade de
Harvard, Division of Research. Graduate School of Business
Administration (1971).
Esse o artigo clssico que introduziu o conceito de
sistemas de decises gerenciais, trazendo o apoio deciso
claramente para o mbito dos sistemas de computadores. Um
sistema de decises gerenciais especfico foi elaborado
para coordenar o planejamento de produo de equipamentos de
lavanderia. De626 pois, ele foi submetido a testes
cientficos, tendo como usurios gerentes de marketing e
produo.
21.24 K. Parsaye e M. Chigneli: Intelligent Database Tools
and Applications. Nova York, N.Y.: Wiley (1993).
Esse livro parece ser o primeiro a se dedicar aos princpios
e tcnicas de minerao de dados (embora se refira ao assunto
como bancos de dados inteligentes).
2 1.25 A. Pirotte e P. Wodon: A Comprehensive Formal Query
Language for a Relational Data Base, R.A.I.R.O.
Informatique/Computer Science 11, Nmero 2 (1977).
2 1.26 R. H. Sprague e E. D. Carlson: Building Effective
Decision Support Systems. Englewood Cliffs, N.J.: Prentice-
Hali (1982).
Outro texto clssico.
2 1.27 Erik Thomsen: OLAP Solutions: BuildingMulti-
Dimensional Information Systems. Nova York, N.Y.: Wiley
(1997).
Um dos primeiros livros sobre OLAP e talvez o mais completo.
O foco est na compreenso dos conceitos e mtodos de anlise
usando sistemas multidimensionais. Uma tentativa sria de
injetar alguma disciplina em um assunto confuso.
2 1.28 R. Uthurusamy: From Data Mining to Knowledge
Discovery: Current Challenges and Future Directions, em U.
M. Fayyad, G. Piatetsky-Shapiro, P. Smyth e R. Uthurusamy
(editores): Advances in Knowledge Discovery and Data Mining.
Cambridge, Mass.: AAAI Press/MIT Press (1996).
RESPOSTAS A EXERCICIOS SELECIONADOS
21.8 Existem oito (= 2) agrupamentos possveis para cada
hierarquia; ento, o nmero total de possibilidades
8 = 4.096. Como um exerccio complementar, voc pode
considerar o que est envolvido no uso da SQL para obter
todas essas totalizaes.
21.29 Com respeito s consultas de SQL, mostramos somente as
clusulas GROUP BY:
a. GROUP BY GROUPING SETS ( (F#,P#), (P#,J#), (J#F#) )
b. GROUP BY GROUPING SETS ( J#, (J#,P#), O )
c. A armadilha que a consulta ambgua a expresso (por
exemplo) reunida ao longo da dimenso de fornecedor tem
muitos significados possveis. Porm, uma interpretao
possvel da exigncia conduzir a uma clusula GROUP BY como
esta:
GROUP BY ROLLUP (F#), ROLLUP (P#)
d. GROUP BY CUBE ( F#, P#
Omitimos as tabelas de SQL resultantes. No caso de crosstabs,
deve ficar claro que crosstabs no so uma boa maneira de
exibir um resultado que envolva mais de duas dimenses (e,
quanto mais dimenses houver, pior ela ficar). Por exemplo,
uma crosstab correspondente a GROUP BY F#, P#, J# seria
semelhante a esta (em parte):
P1 P2
Ji J2 J3 Ji J2 J3
200 0 O O O 0
F2 O 0 O O 0 O
F3 O O O O O O
F4 O O 0 O O O
F5 O 200 O O O O
Em resumo: os ttulos so desajeitados e os arrays so
esparsos.
627