Вы находитесь на странице: 1из 394

Preencha a ficha de cadastro no final deste livro

e receba gratuitamente informações sobre


os lançamentos e promoções da Elsevier.

Consulte também nosso catálogo completo,


últimos lançamentos e serviços exclusivos no site
www.elsevier.com.br
Carlos
Barbieri

BI2 - Business Intelligence


Modelagem & Qualidade
H+022
 ( 

C

  

 
   
 ( o3E20 23/0+/2335
' @ 
 
  I% 
    
 I 
 
 
J.
 
 
  
-  K 
 L 
 

 %.
.  


Copidesque:!  C  
Revisão:><  :
Editoração Eletrônica:&$'  <
 C  
( 


 ( 
@    
M 

)&  & 222,2Eo


+0060#00E,  ,)  * ,)*,$


)N  467,5o
086E3#022,$O ,&%",&",$


&   <     


0500#0+E6780

Q 


!&$'345#56#76+#84++#0

Nota:> I      


  %
'     

   % 

%  .. 


@ A


  

 %

&   <      . 



  
 @.
%
'     

 .. 

     

 




 
  


 %


 
 @
 @

 
  
%

-
 .. 

    



.. . 


 

 
. 
 


!"#$
 % 
&   ' 
 
 ( 
)*
_________________________________________________________________________
B191b $  

$!+,$


!    -   .  /


$  
,)  * -
+022

!   
!&$'345#56#76+#84++#0

2!  :    ;< 


%= + >  %   

; %= 7 ?
%  @     8 < 
% ,
! 
 A 
!CD 

FF-E658027
22#+E57 FG-E6502+++
_________________________________________________________________________
A Beth, por tudo, por sempre.
A Ana Luiza, Roberto, Flávio e Maria Alice, meus filhos, e
Rodrigo, nossa paixão.
A Luiz Antônio, Geraldo (in memoriam) e Inimá, participantes
fundamentais da minha família.
A Tibum, companheira felina que, ao meu lado, testemunhou
por completo a escrita destas páginas e partiu exatamente no dia em que
eu coloquei o ponto final no Capítulo 11.
Agradecimentos

A Fabia Russano Yazaki, pela parceria no Capítulo 7, que eu não


teria escrito sozinho.
À Sociedade Softex, nas figuras de Arnaldo Bacha, José Antônio
Antonioni, Kival Weber, Ana Regina Rocha e Nelson Franco, por terem
me apresentado o programa MPS, de onde extraí as ideias seminais de
qualidade, transpostas para o BI2.
A Welington Teixeira Santos, Wilson Lima, Mauro Lambert,
Márcio Tibo, Thiago Maia, Rosângela Mendonça, Isabella Fonseca,
Cláudio Filardi, Michele Horta, Cláudio Fróes, Marlene Ribeiro,
Rosane Matos, Daisy Melo e à equipe de comunicação (Pedro Ivo
Martins, Liliane Duarte, Stefânia Faria e Gracielle Santos), por terem
me ajudado a alavancar uma estrutura de consultoria em qualidade de
processos com MPS.BR na Fumsoft, que nos orgulha a todos.
A Flávio de Almeida Pires, Paulo Vasconcelos e Marcelo
Oliveira, da Assesso – Engenharia de Sistemas, uma das grandes empresas
da área, pelas ricas discussões práticas sobre qualidade de dados, quando
conversamos como velhos amigos, embora somente tivéssemos nos
encontrado naquela manhã cinzenta de outubro.
A Otávio Lanna, que me proporcionou os contatos com a
Assesso – Engenharia de Sistemas e a QIBRAS, e a Jamir Lopes (CIO
da Cemig), pelas indicações nas entrevistas.
A Marco Antônio Canela, da Livraria Cultura – SP, pela presteza
na orientação a respeito das editoras que pudessem ter interesse nesta
obra.
A Rodrigo Baroni, espécie de irmão mais novo ou filho mais
velho, pelas orientações sobre publicação e bibliografia.
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

A Marcelo Lamounier, da MGInfo, ex-aluno e hoje um craque


do BI, pelas discussões sobre modelos dimensionais para gerência de
projetos.
A Dário Arantes Nunes, amigo, irmão e consultor renomado na
área de reputação corporativa, pelas discussões a respeito do tema.
A Fernando Colares, ex-aluno, ex-consultor da minha equipe,
hoje um brilhante designer gráfico, pelas sugestões da capa.
A Marco Pace, editor da Elsevier, Silvia Barbosa Lima,
coordenadora de produção editorial, e Rachel Sant’Anna Murta, pela
revisão criteriosa e profissional dos textos.
A Adler Diniz, Alex Prado, Andriele Ribeiro, Carlos Pietrobom,
César Ávila, Dhanyel Nunes, Fabiana Bigão, Fabiana Borges, Fernando
Moreira, Geovanne Nogueira, Isabella Fonseca, José Luis Braga, Juliano
Santos, Junilson Souza, Rosângela Mendonça, Rosilane Mota, João Righi,
Luciana Martins e Bruno Satler, consultores da equipe do CCOMP.MG-
Fumsoft, e Ana Liddy Magalhães, da Quality Focus.
A Celso Tolentino, Delcio Martins, Eduardo Vidal, Fernando
Cota, Joel Gerken, Milton Ramalho e Wagner Bernucci, que, em todas as
primeiras quintas-feiras do mês, me orientam na resolução dos problemas
transcendentais e quânticos da humanidade, entre cervejas, licores e
amizades duradouras.

VIII
Introdução

O livro BI2-Business Intelligence: modelagem e qualidade, que você


folheia neste momento, teve três grandes motivações na sua concepção:
a primeira foi o ainda intenso interesse demonstrado pela comunidade
de informações (acadêmica e técnica) pelo livro anterior BI-Business
Intelligence: modelagem e tecnologia, esgotado. Esgotado, diga-se de passagem,
não necessariamente por seus méritos, mas pelo desaparecimento da
empresa que o editou. Que Deus a tenha...
Editado em 2001, o livro ainda continua sendo uma fonte
bastante citada, conforme evidencia o Dr. Google nas suas mais de 30
páginas de links referenciados. Isso é reiterado por diversos e-mails que
recebo periodicamente, vindos de universidades e profissionais, a respeito
de como obtê-lo, mesmo dez anos depois do seu lançamento. Assim, o
BI2 cumprirá parte de seu objetivo, ampliando, revisando e atualizando
os conceitos existentes no seu irmão mais velho e trazendo novas
discussões sobre altos volumes, novas formas de acesso e de estruturação
de informações.
A segunda grande motivação se deu pela minha incursão,
ao longo destes últimos seis anos, na implementação de projetos de
qualidade, por meio do Programa MPS.BR da Softex. Foram mais de 50
implementações através da Fumsoft-MG. Embora o movimento MPS.
BR seja fortemente focado em qualidade de processos de software e
serviços correlatos, fui despertado por uma daquelas vozes internas que
nos sopram aos ouvidos, principalmente nas madrugadas insones que
sucedem a derrota do time querido. Ela me perguntava o porquê da
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

qualidade de dados não ter ainda alcançado um patamar de importância


corporativa semelhante à qualidade dos processos. De pronto, respondi
“depende”, esfarelando qualquer resquício de lógica e me valendo do
clichê fundamental da indústria da consultoria. Mesmo assim, prometi
ao meu alter ego cruzmaltino pensar, pesquisar e escrever a respeito.
Até porque em toda a minha vida profissional estive profundamente
envolvido com dados. Desde a minha tese de mestrado no Inpe, nos anos
70, passando pela minha carreira profissional de quase 30 anos na Cemig,
onde comecei como DBA, comandei a área de Dados e me aposentei
como responsável pela área de Tecnologia. Sempre me envolvi com eles.
Mesmo assim, os diversos trabalhos de consultoria por aí afora, a escrita
de um dos primeiros livros sobre Modelagem de Dados publicados no
Brasil, e o primeiro livro de BI, sempre me apontaram esse caminho, mas
nunca me ajudaram na resposta ao alter ego insone. Quando ouvi pela
primeira vez sobre os movimentos de Governança de Dados, entendi que
o momento que eu sempre imaginara importante para os dados estava
prestes a chegar. E por que colocar num livro de BI assuntos de qualidade
e governança de dados? A resposta é clara e forte como a silhueta das
montanhas de Minas. As informações colocadas e estocadas nos grandes
depósitos hoje (sejam DW ou DMarts) têm oferecido um lado sombrio,
quando analisadas sob a luz da qualidade. Não são poucas as empresas
onde ouço que o BI vai bem, porém a qualidade das informações por ele
produzidas, nem tanto.
A terceira motivação se dá pela minha paixão velada pelos
dados, sejam eles os cubinhos com faces enumeradas de 1 a 6, ou os
elementos atômicos de informações e geração de conhecimentos. A
língua portuguesa tem essa feliz coincidência semântica, inexistente
nas outras. Essa minha fixação em dados (informações) foi aguçada pela
perspectiva do crescimento absolutamente incontrolável do conteúdo
do universo digital. Com o aparecimento de celulares, redes sociais,
câmeras etc., o elemento “dado” passou a circundar as nossas vidas como
nunca antes, chamando atenção, não só pelo seu volume estonteante,
mas principalmente pela maneira pela qual nos impactarão. Essas novas
formas de análises que serão feitas sobre nós quando investidos de leitores,
blogueiros, internautas, twiteiros, transeuntes observados por câmeras

X
ELSEVIER
I I NTRODUÇÃO
etc., também foram pesquisadas no que chamei de BHI (Behavior
Intelligence). Já se foi o tempo em que o BI era somente dados de varejo
e transações comerciais. No lugar de transações, veremos interações e
atitudes.
Enfim, o livro procura ser um pouco provocador no sentido
de que as empresas deverão se preocupar com os dados como um ativo
organizacional, da mesma forma com que nós, os human bits, estaremos
vivendo o lado doce e amargo da nossa nova personalidade de “seres
digitais”.
Para melhor orientá-los na leitura do BI2, gostaria de mostrar as
trilhas do volume. No Capítulo 1, vocês terão uma visão gerencial, com
o viés histórico sobre a evolução ou revolução dos aspectos de dados,
informação e conhecimento, testemunhado por esse escriba, desde o
momento em que rodei o primeiro programa Fortran, na época da CPU
à lenha.
No Capítulo 2, procurei associar o conceito de reputação
e de novos posicionamentos das empresas a respeito de competição,
virtualidade, marcas etc., com aspectos subliminares de qualidade.
No Capítulo 3, tangencio o assunto qualidade de processos,
muito mais com intuito de contextualização de uma qualidade parceira
do que com a pretensão de ser detalhista nesse domínio. No Capítulo
4, falamos sobre Qualidade e Governança de Dados, discutida num
viés condicional e fundamental para uma boa implementação de BI
e a consequente assunção dos dados como ativos organizacionais
das empresas. Neste capítulo discutiremos os conceitos seminais de
Governança de Dados, algumas propostas para sua implantação e certos
modelos de maturidade aplicados. É um dos capítulos provocadores.
Os Capítulos 5 e 6 focam BI, com os seus conceitos estruturantes e
os aspectos correlacionados ao assunto, como Conhecimento, Inteligência
competitiva etc. Manteve a essência do livro anterior, focando aspectos
colaterais do BI.
No Capítulo 7, falamos sobre Data Mining, que escrevi com
Fábia Russano Yazaki, amiga e grande estatística e que hoje trabalha na
ONU em NYC, onde nos encontramos quase que religiosamente nos
janeiros gelados da Big Apple. O conteúdo é também muito próximo

XI
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

do originalmente publicado no primeiro livro, mas foi revisado


e ligeiramente expandido à luz das novas aplicações da matemática
computacional.
Os Capítulos 8, 9 e 10 são dedicados aos projetistas e arquitetos
de DW, DMart e soluções de bases de dados, tendo um conteúdo
caracteristicamente técnico. Não dá para escrever com graça e lirismo
parágrafos que versam sobre indexações multidimensionais, com mapas
de bits ou chaves randômicas. No Capítulo 8 falamos sobre conceitos
avançados de modelagem dimensional, que permanecem estáveis desde
Kimball e Inmon. No Capítulo 9, a discussão é sobre projetos de
aplicações de BI, com incursão em modelos iterativos, como forma de
encolher os grandes cronogramas de projetos dessa natureza. O Capítulo
10 tem um foco bem bit-byte mesmo. Diversas formas de indexações e
suas evoluções foram pesquisadas e analisadas. Na parte final do capítulo,
focamos em grandes volumes, com soluções sendo desenvolvidas,
exatamente para estes novos cenários, como Hadoop, indexações
colunares etc.
O Capítulo 11 tem um sabor especial e, novamente, tenta
provocar e sugerir reflexões. Ele sintetiza os conceitos em torno do
que chamei de BI2, ou seja, as diversas alternativas de aplicações de BI
em domínios diferentes. Falamos do BHI (Behavior Intelligence), BI
aplicado a GP (Gerência de Projetos), Geo-BI, BI com agilidade etc.,
além dos aspectos de volumes de dados e seus impactos em segurança e
privacidade.
Este é o enredo do BI2: jogar algumas luzes em cima do BI
estabilizado há mais de 15 anos, provocando reflexões sobre qualidade e
governança dos dados, altos volumes com “Big Data”, MDM, projetos
iterativos e novas formas de aplicações.

Espero que gostem. Boa leitura.

XII
CAPÍTULO 1

A revolução dos dados,


da informação e do conhecimento

Quando Seymour Pappert, um dos grandes gurus do mitológico MIT (Instituto


de Tecnologia de Massachussets), disse, nos idos dos anos 1970, que os dados e seus cor-
relatos seriam responsáveis por uma revolução na sociedade digna de se comparar com a
imprensa de Gutemberg, muitos duvidaram. Seria mais uma manifestação ufanista, própria
dos gurus de tecnologias herméticas, aos quais eram concedidas tolerantes licenças de
delírio em público? Ou seria uma sinalização de que a sociedade deveria se preparar para
algo, naquela época difícil de imaginar, principalmente para uma geração de informatas
juniores que desembarcava dos cursos de engenharia, administração e economia, e se mos-
trava deslumbrada com os arquivos indexados-sequenciais que se avizinhavam?
Os dados, até então, eram, na realidade, meros coadjuvantes de um processo de
desenvolvimento de sistemas, em que o empirismo metodológico de muitos e a inspira-
ção de alguns definiam os caminhos a trilhar. A primeira geração de sistemas de gerência
de dados havia surgido com um modelo hierárquico que, sob certo ângulo, simulava o
estilo de relações que as empresas praticavam (rigidamente estruturadas em níveis) e, de
certa forma, também o que os sistemas de governo (militarismo) e a sociedade de en-
tão (ainda machista e patriarcal) compartilhavam. Essas estruturas sofisticadas de dados
permitiram que sistemas complexos fossem implantados, ainda que sob um foco mais
tecnológico do que negocial. Espaçonaves foram lançadas, suportadas por esses sistemas,
assim como sistemas de faturamento foram desenvolvidos substituindo vários arquivos
por uma (então) inédita estrutura de árvores e ponteiros de dados.
Nos anos 1980, com o surgimento dos novos movimentos metodológicos, que
tentavam espantar o empirismo culinário presente no desenvolvimento de sistemas, os
dados atingiram uma espécie de estrelato, pela primeira vez. Foi a época do surgimento
da administração de dados, da modelagem de dados, da engenharia da informação e da
análise de dados, tudo se contrapondo fortemente ao estilo “processista” vigente. Surgiu
o modelo relacional, trocando a rigidez das estruturas hierárquicas pela flexibilidade das
relações – algo, de certa forma, também emblemático.
Começou-se a falar em estruturas matriciais nas empresas e, por espelhamento,
nos bancos de dados relacionais, em que campos e registros se transformavam em ma-
trizes bidimensionais, e relações e relacionamentos ganharam ênfase. Ainda assim, o
foco permaneceu muito mais centrado no tecnológico, com pouca ênfase no campo
negocial, não obstante a intensidade do discurso praticado.
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Os anos 1990 chegaram para confirmar os vaticínios dos anos 1970. Com os da-
dos atingindo o status grã-fino de objetos e o casamento tecnológico entre informação
e comunicação festejado em todas as esquinas do planeta, a nossa sociedade começou a
fazer uma plástica cultural definitiva. Diferentemente da Revolução Industrial, quando
as benesses não chegavam a todos diretamente, a revolução dos dados e da informa-
ção, capitaneada pela internet, tornou-se democrática, invasiva e de amplo alcance. O
cidadão comum, com o trio micro-modem-telefone, podia navegar pela grande teia,
visitando a home page do seu time favorito, comprando livros na primeira loja virtual
do planeta ou discutindo a doença rara do sobrinho em um fórum virtual específico.
Perigava, por um lado, de se enrolar nos labirintos do excesso de opções, enquanto, por
outro, desfrutava de uma tecnologia que lhe concedeu um grau de liberdade e profun-
didade jamais imaginados. Tudo isso suportado por um arsenal que misturava compu-
tadores e redes, e lhe oferecia principalmente... dados que ele começava a transformar
no combustível mais precioso dos anos 2000: a informação. Era o início da cristalização
das visões de outro guru dos anos 1960 (Marshall McLuhan), que havia previsto algo
que ousara chamar de aldeia global. Uma espécie de comunidade virtual e globalmente
conectada, com possibilidades de relacionamentos remotos de amizade, flerte, compra,
venda, envio de mensagens etc. e que hoje identificamos como sistemas de comércio
eletrônico, e-mail, chats, Orkut, Twitter, Facebook etc. A decantada aldeia global chegou
e, hoje, formada de outras aldeias, resulta em um arco infinito de opções para discussão
de assuntos plurais, que vão do exótico ao desnecessário, do pífio ao fundamental.
No final dos anos 1990, esse processo evolutivo dos dados defrontou-se com o
primeiro obstáculo produzido pela interação romântica e libertária entre o homem e
a máquina que processava: o bug do milênio. Os dados e seus metadados haviam sido
registrados de forma descuidada, sem a preocupação com a sua utilização para além
do século novo, que forçaria a transposição dos anos registrados como 98, 99 para um
esquisito 00. Sem grandes arranhões, as empresas, na média com muita diligência e
certa precaução, lanternaram os seus sistemas, corrigiram seus arquivos e espantaram
um problema que depois se mostrou um pouco menor do que fora imaginado. Menos
mal que todos tenham cumprido o seu dever de casa e preservado a funcionalidade
de seus sistemas e a integridade de seus dados fundamentais. Alguns países com forte
intimidade com catástrofes naturais (nevascas, enchentes, tufões, tsunamis etc.) e com
uma cultura mais ajustada ao alarmismo gastaram muito mais do que deviam. Outros,
como o nosso, mais adaptados à catástrofe dos homens públicos e dos políticos que
escolhemos, souberam lidar adequadamente com o problema, e todos saíram ilesos e
saltitantes. As empresas, passada a fase pós-bug, começaram a ser induzidas a oferecer
aos seus dirigentes melhores informações como forma de preparo para as disputas
cada vez mais árduas na arena da competitividade, sem o que, certamente, derrapariam
nas curvas dos balancetes futuros. Aos seus consumidores e clientes, lhes coube, cada
vez mais, a obrigação de acenar com produtos e serviços com mais qualidade, opção,
menor preço e maior rapidez na entrega. Chegou a era da fidelização, da customiza-
ção, da sedução do cliente e da inteligência aplicada aos negócios. Tudo isso também
através daquela nova e emergente vitrine corporativa, a internet, cada vez mais oni-
presente e onipotente. Para tal, os grandes bancos de dados organizacionais começa-

2
ELSEVIER
C APÍTULO 1 I A R EVOLUÇÃO DOS D ADOS , DA I NFORMAÇÃO E DO C ONHECIMENTO

ram a produzir variantes, como os depósitos de dados (data warehouse), exatamente


com a finalidade de entregar aos tomadores de decisão a informação na forma mais
precisa e palatável possível. Os volumes de dados cresciam, e os tratamentos anteri-
ormente dispensados não se mostravam os mais ajustados. O exagero das termino-
logias, produzindo nomes e rótulos diferentes, se fazia presente, alavancado por uma
indústria cada vez mais forte: o marketing. Uma empresa holandesa especializada em
sistemas e tecnologias para informações gerenciais criou o conceito de destilaria de
dados, o que sugeria informações, no mínimo, inebriantes, para decidir o futuro das
nossas empresas. Assim, você poderia optar por um data warehouse de 8 ou 12 anos
com dados estatísticos e gerenciais? Tim-tim, salute.
Hoje, a tecnologia dos dados e das informações apresenta o conceito de “mash
up”, que, traduzido de forma aberta e livre, seria “mistureba”. Você pode criar um site
formado de dados oriundos de vários outros, publicados através de APIs disponíveis e
fáceis de serem implementadas, abrigando e costurando textos e gráficos, como quem
mistura ingredientes em uma receita culinária inédita. Assim, enquanto nos anos 1990
ouvimos sobre as destilarias de dados, chegamos aos anos 201x com o mexidão de
dados e informações para consumo imediato e sem restrições geográficas. A internet,
considerada o maior instrumento social dos últimos séculos, tem grande participa-
ção nisso tudo. Espelho fiel do gênero humano, a internet se tornou um verdadeiro
simulador das nossas atitudes, e as empresas perceberam nela o canal perfeito de que
precisavam para que a aldeia global de Marshall pudesse comprar e vender. Assim, os
clientes, através dela, passaram a ter à sua disposição cada vez mais acesso a opções de
produtos e serviços, não só para escolher melhor o que desejam, mas também para
acompanhar seus pedidos, colocar os seus anseios e registrar as suas queixas. Algumas
empresas já haviam pensado nisso há algum tempo, quando a grande teia ainda era,
digamos, imberbe e adolescente. Uma grande empresa mundial de entrega de pacotes
(delivery) desde a metade dos anos 1990 permitia que se acompanhasse, via internet,
o trajeto de uma encomenda, enviada de Belo Horizonte a Kathmandu, no Nepal,
e, para isso, investiu na construção de um data warehouse de muitos terabytes de ar-
mazenamento e de vários megadólares de custo. Outra, do ramo mundial de varejo,
triplicou o seu data warehouse, levando-o ao (hoje não mais) estratosférico volume de
mais de 50 terabytes de dados. A sinalização de que o primeiro depósito informacio-
nal (data warehouse) de 1 petabytes (1 quatrilhão de bytes) estava previsto para chegar
na metade dos anos 2000 indicava que um volume crescente de informações, nas mais
variadas formas de mídia, deveria ser armazenado nos arquivos de depois de amanhã.
Indicava, também, que essas unidades numéricas assustadoramente grandes deixariam
as páginas das histórias de Tio Patinhas para chegar aos nossos data centers. Os bits e
bytes seriam contados em quinquilhões, como gostava de clamar o rabugento pato
milionário de Walt Disney. Os dados que outrora eram meros representativos de fatos
mundanos, como nome, endereço, telefone etc., hoje se sofisticam na representação de
imagens, vídeos, sons, registros temporais, indicadores econômicos, planilhas, páginas
HTML e estruturas XML, acompanhando as mudanças solicitadas por uma sociedade
agora alavancada por outras indústrias, como entretenimento, comunicação, comércio
eletrônico e processamento sociocolaborativo.

3
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Em 2010, o Google tinha quase 100 milhões de buscas por dia, e no YouTube
eram colocados aproximadamente 75.000 novos vídeos por dia, sendo que mais de
100 milhões de clipes eram vistos diariamente. O Twitter alcançou, no final de maio
de 2010, a incrível marca de 15 bilhões de posts colocados na sua rede social. Tudo isso
transforma a grande rede em um mercado persa virtual e espacial, no qual milhares de
barraquinhas eletrônicas são disponibilizadas a cada instante em que você clica o seu
browser preferido. Você dá uma passadinha por lá para comprar, vender, namorar, rezar,
velar os mortos ou somente consumir os dados e as informações da nova era digital.
Até o lado mais escondido dos dados já está sendo, cada vez mais, alvo de inte-
ressantes aplicações. É o conceito de data mining (garimpagem de dados), que objetiva
melhorar o uso desses gigantescos arsenais de informação através da identificação de
padrões de correlação normalmente invisíveis em análises convencionais. Indicadores
de produtos comprados em conjunto, ou de padrões de fraudes praticadas, ajudarão os
gerentes de empresas, no seu cotidiano, a descobrir sinuosas correlações que certamente
o levarão a melhor dispor a gôndola do seu mercadinho “brick, real” ou “click, virtual”,
ou modificar os critérios de análise de riscos de uma proposta de empréstimo. O web
usage mining hoje já chegou para buscar padrões de comportamento dos internautas,
não mais no ato da compra pelas lojas virtuais, mas também das suas atitudes cotidianas,
expressões e preferências. Informações sobre blogs hoje são garimpadas pela indústria,
transformando a opinião livre e francamente expressa nos diários pessoais da web em
informações qualitativas de comportamento, via o web content mining. Esse tipo de cap-
tura espontânea de informações entrou até na fórmula dos planejadores de campanhas
políticas, que, hoje, já montam esquadrilhas de observadores virtuais prontos para inter-
vir em blogs, injetando antídotos em manifestações contrárias às de seus contratantes.
O conceito de text mining chegou para permitir pesquisas em textos, com bus-
cas semânticas, através de um processo sofisticado de categorização, criação de taxono-
mias, extração de conceitos e de entidades, e derivação de relacionamentos entre elas.
Essa técnica, por sua vez, vem ao encontro do BI aplicado sobre os dados textuais não
estruturados, como e-mails, relatórios, memorandos, atas etc., fechando um ciclo funda-
mental de ações que se iniciou com os dados estruturados e alcança os dados em todas
as suas variantes de manifestações.

BI2
Chegamos à era do BI2, com a inteligência de negócios, aprofundando em cam-
pos nos quais já pisava e entrando em outros que reclamam por suas aplicações. Dados
de projetos, de blogs e de redes sociais, e de comportamento das pessoas nos seus mais
variados papéis, vêm para se juntar ao mundo do varejo, onde tudo começou. O mundo
do BI2 também falará de BA-Business Analytics, que misturará o BI em tempo real
com mining e análises preditivas. Isso permitirá a criação de mecanismos inferenciais de
negócios com latência quase zero e exigirá maior conteúdo qualitativo das informações.
Como vimos, de início, a informática fez os dados. Depois transformou-os em infor-
mação. Agora o objetivo é usinar conhecimentos, a partir daquelas matérias-primas.
Existe até uma escala, definida por James Cates, que propõe uma evolução conceitual
dos dados em degraus cada vez mais crescentes em semântica e valor.

4
ELSEVIER
C APÍTULO 1 I A R EVOLUÇÃO DOS D ADOS , DA I NFORMAÇÃO E DO C ONHECIMENTO

Começamos com a gerência dos dados (data management), tradicional nos anos
1970, logo no início da era de SGBD. Depois de amadurecida, chegamos à era da ge-
rência da informação (information management), que cobre o período em que tivemos o
aparecimento dos primeiros depósitos de recursos informacionais, como data warehou-
se e data marts, que testemunhamos até os dias de hoje. Neste momento, estamos aden-
trando uma nova fronteira, a gerência do conhecimento (knowledge management), em que
algumas outras variáveis entram na fórmula de informação, gerando os conhecimentos,
classificados e catalogados segundo modelos taxonômicos definidos em domínios.
Cada empresa, com suas especialidades, gerará os seus modelos de conhecimento
e acumulará essa nova forma de informações em depósitos acessados e divulgados para
todos. A gerência de conhecimento entra com uma forte pitada de envolvimento de
um engine complexo, o ser humano, responsável pelas interpretações e avaliações desse
novo tipo de acervo. As empresas que caminham hoje pelas trilhas de modelos de
qualidade no processo de desenvolvimento de sistemas já buscam a estruturação de
repositórios de conhecimentos, mecanismos de buscas e grupos de produção, desse que
se mostra o grande ativo organizacional e combustível imprescindível dos anos 201x:
o conhecimento. Mas isso não para por aí. Outras fronteiras estão sendo discutidas nas
trincheiras acadêmicas e, embora ainda mostrem pequena musculatura, já têm os seus
embriões em formação. Entre elas estão: gerência do entendimento (understanding mana-
gement) e a gerência da sabedoria (wisdom management), em que o componente intuição
será contemplado, além de outros conceitos, ainda por explorar. Essas formas ascenden-
tes de estruturação do saber levarão a sociedade a patamares maiores de compreensão
do homem nos seus diversos papéis, como empregado, empregador, cliente, paciente,
fornecedor, amante, internauta, participante de redes sociais, comprador on-line, escri-
tor de blog etc.
Como reflexão de final de capítulo, costumo dizer que, no Brasil, somos cam-
peões em uma outra fronteira ainda não detectada nos estudos avançados dessas uni-
versidades que pesquisam a escala do saber: a gerência da esperteza, que denominei
cheating management, na qual desenvolvemos técnicas e conceitos imbatíveis de como
levar vantagem em tudo. Infelizmente...

5
CAPÍTULO 2

Reputação corporativa e
uma nova ordem empresarial

O que você acha da empresa Y? Você gosta do produto Z? Você já fez seguros
pela corretora W? Um dos pontos estratégicos mais importantes que uma empresa deve
observar, nesse mercado plural, capilar e cheio de informações e conhecimentos em
que vivemos hoje, é o conceito de reputação. A reputação é aquela percepção, intuição,
sentimento ou sensação que temos e é expressa na forma de opinião definida sobre algo,
alguém ou uma empresa. No caso da reputação corporativa, é julgamento construído ao
longo do tempo e baseado em ações e comportamentos da empresa, e capturado pelos
seus grupos de relacionamentos, via os pontos de contato com ela. Pela sua importância
e capilaridade, a reputação corporativa é considerada hoje um importante ativo orga-
nizacional. Vários fatores definem a reputação corporativa, e o somatório deles compõe
a percepção final sobre ela. Muitas empresas primam por ter sua personalidade corpora-
tiva mais atrelada a uma das dimensões da reputação, seja por sugerir transparência, seja
por atuar e cultivar valores sociais e ambientais ou por inspirar liderança. Entretanto, a
qualidade dos seus produtos e serviços entra como um dos maiores pesos na equação
final do complexo conceito de reputação. Os principais domínios da reputação corpo-
rativa, variáveis da sua equação final, transitam por:
 desempenho financeiro, associado aos resultados positivos e à perspectiva de
seu crescimento;
 liderança de mercado, baseada na posição de destaque e pela sua visão de
futuro;
 ambiente de trabalho oferecido, redundando em um clima organizacional
propício a oportunidades e reconhecimentos;
 responsabilidade social, em que se destacam iniciativas em torno de ações
ambientais e sociais;
 capacidade de inovação;
 transparência definida por uma política de governança corporativa;
 qualidade de processos e de produtos.
Com a dinâmica dos mercados e a evolução dos negócios e da competitividade,
algumas empresas rapidamente sobem e descem desse ranking das nossas percepções. Por
exemplo, Lehman Brothers e Merryl Linch, empresas pulverizadas pelo tsunami finan-
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

ceiro de 2008/2009, certamente ocuparam, em passado recente, posições de destaque


no imaginário da sociedade americana, no que tange à reputação. Outras, como MSI,
Enron, Qwest, dissolvidas em escândalos há anos, também já habitaram esse patamar
de boa imagem e hoje viraram poeira. O Reputation Institute, organismo internacio-
nal especializado em gestão de reputação, imagem, marca e identidade organizacional,
apontava em 2006, 2007 e 2008, respectivamente, a Gerdau e a Petrobras (esta, por dois
anos seguidos) como as mais destacadas no mercado brasileiro. Em 2009, a Petrobras
teve a Sadia como companheira brasileira no ranking de reputação corporativa. Na mes-
ma faixa de tempo, no âmbito internacional, a Barilla italiana, a Lego (Dinamarca) e
a Toyota (Japão) apareceram como destaques, respectivamente, de 2006 a 2008. Essas
empresas marcam, no imaginário da sociedade e de seus clientes e consumidores, a im-
pressão de boa reputação, no arco de valores discutidos.
Um dos fatores mais importantes da reputação corporativa é a forma pela qual
uma empresa gera os pilares fundamentais do seu ciclo de vida: a qualidade de pro-
cessos e de seus produtos. A Toyota, grande montadora de carros japonesa, pode ser
observada como uma das empresas com maior reputação em qualidade, tendo várias
publicações dessa área associadas ao seu nome. Empresa pioneira na adoção de pro-
cessos inovadores na área de manufatura, ela desenvolveu essa vocação pela qualidade,
quando, ao entrar no mercado americano, não lhe foi permitido ter concessionárias
com serviços de manutenção. Motivada por essa restrição, a empresa transformou o
conceito de qualidade em fator fundamental para a sua sobrevivência. Uma simples
pesquisa na Amazon.com mostra diversos livros associados ao tema qualidade, to-
dos com a palavra Toyota como elemento direcionador e sinônimo dessa importante
característica corporativa. Entretanto, mesmo com toda a aplicação em qualidade de
produtos e processos, ninguém é infalível. Em fevereiro de 2010, o presidente da
empresa veio a público pedir perdão ao mundo por falhas que levaram a diversos
recalls em todo o planeta. O presidente, neto do fundador da empresa, num misto de
constrangimento e expressão de dignidade, convocou a imprensa para pedir desculpas
sobre os problemas de freio do modelo Prius 2010, conforme noticiou O Globo, de
6/2/10. Os problemas implicaram sérios acidentes, com algumas mortes. Se houve
falha nos processos, pelo menos mostrou qualidade no caráter. Todas essas empresas
que passaram por problemas de qualidade têm buscado um processo imediato de
recuperação, tentando remover os incômodos arranhões instalados no chassi da sua
reputação. Ao longo dos próximos anos, muitas continuarão enfrentando essa peleja,
dando mostras de que o fator qualidade é algo com tom desafiador na sua inoculação
e muito mais difícil ainda na sua preservação.
A Figura 2.1 mostra um mapa mental com os conceitos que definem o círculo
de reputação corporativa. A dimensão da qualidade, conforme mostrado, é considerada
uma das mais importantes, pois reflete diretamente na percepção da sua marca e da força
da sua imagem, atrelada aos produtos e serviços. Hoje, as empresas sabem que o cami-
nho da qualidade tornou-se um elemento de extrema necessidade, não somente como
formador de imagem e reputação, mas como conceito demandado em seus produtos,
sistemas e ambientes. Muitas empresas mostram movimentos estratégicos que apontam
para a busca de maior competitividade, aumento do market-share, redução de custos,

8
ELSEVIER
C APÍTULO 2 I R EPUTAÇÃO C ORPORATIVA E UMA N OVA O RDEM E MPRESARIAL

redução do time-to-market e, para tal, se transformam em partícipes de uma nova era


de conscientização empresarial. Uma empresa que executa seus processos empresariais
com qualidade, apoiada por dados também revestidos do mesmo conceito, certamente
terá maiores chances de tocar o mercado com produtos e serviços de melhor qualidade,
construindo, nesse domínio, uma percepção positiva de sua reputação. Essas empresas,
diferentemente dos paradigmas de ontem, entendem hoje que outros valores serão con-
siderados em um futuro próximo, quando estarão todas munidas dos mesmos arsenais
tecnológicos de software e hardware. Naquele momento, o fator diferencial serão os
elementos abstratos, como inovação, virtualidade, capital intelectual, as pessoas como
recursos fundamentais, a informação e o conhecimento acumulados e estruturados de
forma adequada, a reputação formada, a força de sua marca e de suas alianças, além da
qualidade de seus processos e dados. Essas serão, cada vez mais, as armas que definirão os
vencedores na corrida afunilada pelo mercado. Alguns desses conceitos são discutidos
a seguir.

Figura 2.1
Mapa mental do conceito de reputação corporativa.

INOVAÇÃO E VIRTUALIDADE
Elementos como a virtualidade, proporcionada pela crescente melhoria das ca-
madas de comunicação, e a portabilidade de serviços têm contribuído fortemente para
o aparecimento de empresas com alto teor de inovação. Uma importante companhia
de aviação americana, que opera no Brasil, utiliza senhoras mórmons trabalhando nos
seus domicílios para formar um poderoso call-center virtual. Diferentemente dos grandes
andares, com inúmeras baias cheias de jovens pilotando um fone de ouvido e um com-

9
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

putador, a nova espécie de call-center virtual utiliza senhoras trabalhando no ambiente


doméstico, podendo atender a uma chamada de reserva de passagem enquanto obser-
vam o seu bebê, postado ao seu lado, na vigilância de um possível engasgo. A empresa
aproveitou a cultura religiosa da região, que sugere a permanência da mulher no lar, e
criou uma rede virtual de atendentes, que somente uma vez por semana se reúnem no
QG da empresa para direcionamentos e acompanhamentos.
Outro exemplo se dá pela abordagem de muitos contadores americanos, que
prestam serviços de declaração de imposto de renda e terceirizam os seus trabalhos
para contadores indianos, para quem enviam as declarações recebidas. Aproveitando a
diferença de fuso, os contadores indianos preparam as declarações enquanto se dor-
me nos Estados Unidos e retornam os trabalhos prontos, na manhã do dia seguinte
americano. O mesmo fenômeno se dá com relação a interpretações de tomografias
de muitas clínicas americanas, que usam os serviços dos médicos indianos, transitan-
do pela internet as imagens, os resultados e os laudos. A virtualidade se manifesta
também em empresas que criaram verdadeiras linhas de produção plural, podendo
fabricar desde games, consoles, câmeras fotográficas, antenas etc., em uma espécie de
“multifábrica”, na qual linhas variadas de produção e montagem são armadas e desar-
madas na medida da demanda – uma espécie de fábrica “faz-tudo”, com flexibilidade
de modelos de negócios.
A própria característica de virtualidade parece também passar por transforma-
ções, voltando, numa espécie de movimento pendular, para uma aproximação com a
parte mais física da empresa. A venda pela internet em uma grande livraria americana
começa a se hibridizar com a entrega física, aproveitando a grande capilaridade de sua
rede de lojas. Ou seja, você compra pela internet, aproveitando o conforto de casa, na
hora em que lhe é conveniente, mas não tem de ficar esperando pelo Sedex.Vai buscar
na loja mais próxima. É a aproximação do click (virtual) com o brick (físico, de tijolo).
E até as empresas puramente virtuais já espicham o olho para a possível parceria com
aquelas de tijolo, que funcionariam como uma espécie de entreposto onde os clientes
do mundo virtual buscariam os seus produtos. Dessa forma, a sociedade vai moldando o
modelo que melhor lhe aprouver, e as empresas, com inovação e agilidade, devem estar
prontas para as adaptações demandadas por uma sociedade cada vez mais exercendo a
sua demanda criativa pela qualidade.

COOPETIÇÃO
Um ponto importante que deverá diferenciar as empresas em um futuro pró-
ximo será o sentido de coopetição. Essa palavra, neologismo formado pela união de
cooperação e competição, tem o sentido de compor parcerias de negócios que podem
contrastar à primeira vista, sugerindo inviabilidade. Seria um relacionamento formaliza-
do mesmo entre empresas que disputam leoninamente certos segmentos de mercados,
porém estão dispostas a ser aliadas em outros. Dois grandes jornais do Brasil (um de São
Paulo e outro do Rio de Janeiro), concorrentes no segmento editorial, se uniram para
formar um diário especializado que entrou no mercado para abater o até então único
veículo especializado em dados econômicos e financeiros do país. Esse jornal, alvo da fe-

10
ELSEVIER
C APÍTULO 2 I R EPUTAÇÃO C ORPORATIVA E UMA N OVA O RDEM E MPRESARIAL

roz coopetição planejada, acabou fechando suas portas em 29/05/09. Da mesma forma,
dois grandes jornais de São Paulo, também concorrentes ferinos, se uniram para montar
uma única empresa de distribuição de jornal, otimizando os seus custos operacionais,
embora distribuindo os jornais concorrentes, respeitando, acima de tudo, a opção do as-
sinante. Uma gigante coreana se dividiu em duas empresas (Components e Eletronics).
A primeira vai vender seus componentes para a segunda e também para as concorrentes
da sua irmã, em uma espécie de autocoopetição.

MODELOS PLURAIS DE NEGÓCIOS


As empresas também estão buscando maior adaptabilidade e expansão de suas
linhas de negócios. A Amazon, gigante do comércio eletrônico de livros, se transfor-
mou, na sua primeira mudança de pele, em grande varejista on-line, passando a vender
de CDs, DVDs e brinquedos a leitores de livros digitais. Depois evoluiu ainda mais,
em 2000, quando passou a oferecer sua plataforma de vendas para terceiros, tendo
vários nomes expressivos como clientes: CDNow, Target, Timex, Marks & Spencer
e Lacoste, todas usando o seu expertise em varejo on-line desenvolvido ao longo dos
anos. Isso fez com que a empresa conseguisse maximizar seus investimentos em tec-
nologia, transformando-se em uma companhia de serviços e deixando de ser somente
uma varejista. Os seus próprios clientes/consumidores podem vender livros, CDs e
DVDs, usando a sua estrutura básica desenvolvida, em outro exemplo de coopetição.
Desse jeito, a empresa consegue aproveitar ao máximo o tráfego e atrair para o seu site
um mundo de interessados e até de desinteressados momentâneos. O passo seguinte
da gigante foi a expansão em direção ao mercado de computação na rede (clouding
computing). A empresa oferece hoje serviços de locação de servidores softwares e data
storages virtuais e remotos, acessíveis por qualquer empresa, que, pagando via cartão
pré-pago, se utilizam desses recursos para estabelecer seus ambientes operacionais nas
nuvens.
Além da Amazon, a Google, a IBM e outras também aderiram ao mercado de
aluguel desses hosts virtuais, como novo segmento de serviços. Em 2009, a Amazon lan-
çou a sua última novidade: o Kindle, leitor de livros e jornais digitais, solução que ainda
passa por certa resistência cultural, próprio das quebras de paradigmas. Sua primeira
versão foi lançada em 2007, e gradativamente vai atraindo aficionados por tecnologia,
até alcançar o patamar de convencimento dos famosos leitores de banheiro, que não
abrem mão do histórico “papiro” como mídia de comunicação impressa, principalmen-
te quando acomodados em louças da grife Celite ou Neorest 600, o Jaguar dos vasos
sanitários. Mesmo assim, o produto livro digital vendeu, pela primeira vez, mais que
os tradicionais livros de papel no Natal de 2009. A grande rede americana de livrarias
físicas Barnes & Noble também lançou o seu leitor digital de livros, aproveitando a
experiência no assunto. É o Nook, concorrente do Kindle. Em todas as lojas da B&N
existe uma seção dedicada à demonstração e venda do leitor digital, bem como à lista de
milhões de títulos já disponíveis. A Apple lançou, no mesmo movimento, o seu tablet,
confirmando o seu olhar sempre atento para hábitos de consumo dos clientes ávidos
por gadgets portáteis.

11
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

NOMES E MARCAS
Também com relação à identidade visual, as empresas, nessa nova ordem corpo-
rativa, estão buscando marcas e nomes simples, neutros, estéticos e memorizáveis, com
forte descolamento do business principal da empresa. Marcas como OI, UAI, Vale, Claro,
SIM, Vivo, Taí, Dotz etc. demonstram que não existe mais espaço para nomes comple-
xos que procuravam sintetizar no seu conteúdo o objetivo de seu negócio. Uma fábrica
de software com um nome como “Fapronsa” (“Fábrica de Programa Nossa Senhora
Aparecida”) viraria exemplo de como não se deve batizar as empresas nesta nova ordem
empresarial. Alguns nomes são produzidos por projetos caros e longos, desenvolvidos
por empresas especializadas.
Accenture, por exemplo, é um nome dessa nova lavra, que sugere percepções su-
tis (accent, em inglês significa sotaque, entonação, e centure sugere algo temporal e perene
como século), mas não representa um vocábulo formalmente existente. O mesmo pode
ser considerado com Ascential (ascent, essential), mas sem significado específico, além de
um nome com boa sonoridade e tons inconscientes de direcionamento para cima e
para algo essencial.
Outros nomes produzidos segundo essa ideia são: Myrant, Gennuity, Nexxa,
Axxiom, Braxton etc. É claro que os nomes deverão ser produzidos com certo cuidado,
a fim de evitar perigosas colisões sonoras e semânticas com conceitos e vocábulos de
outras culturas, como os nomes de duas gigantes japonesas de telecomunicação, que
omito por questões óbvias. A mania de utilizar nomes insólitos pode chegar ao paroxis-
mo de se batizar uma criança como “John Cusack 2.0”, numa alusão direta às versões de
software, conforme noticiado no New York Times, de novembro de 2004. Isso talvez até
possa sugerir mudanças na forma de educar, com aplicações de service packs de correções,
em vez de reprimendas orais.
Com relação aos nomes, há quem diga que eles, como os olhos, mandam men-
sagens expressas diretamente da nossa alma. Recentemente, uma grande rede de fast-food
americana, especializada na venda de frango frito e correlatos, analisou a possibilidade
de mudança no seu nome. A Kentucky Fried Chicken sempre trouxe no nome o seu
produto carro-chefe (frango frito). Pois bem, com a implacável onda do alimento sau-
dável, dos ingredientes funcionais, da correção no hábito da alimentação, o passado
do verbo to fry do seu nome virou preocupação no altar da grande meca do consumo
mundial: o mercado americano. Dessa forma, a empresa, na reformatação da sua marca,
não explicita mais o termo fried, nem o nome do estado Kentucky, que, segundo dizem,
estaria exigindo, por nova legislação, a participação no faturamento. O resultado é que
a empresa agora é simplesmente KFC, sem significados explícitos de suas letras. Esse
assunto veio à tona no início de 2010, quando a empresa montou um painel gigantesco
em Times Square, Nova York, onde mostrava um “frangômetro”, contador on-line que
indicava, em milhões de unidades, os lanches vendidos pela rede, em todo o mundo. A
KFC, de forma sutil e com baixo ruído, tenta escapar de ser frita pelo fogo implacável
do antimarketing inconsciente.

12
ELSEVIER
C APÍTULO 2 I R EPUTAÇÃO C ORPORATIVA E UMA N OVA O RDEM E MPRESARIAL

INFORMÁTICA COMO DRIVER DE NEGÓCIOS


Além dessas mudanças, vividas por empresas de toda ordem, também as or-
ganizações de TI passam por lanternagens específicas. Os núcleos de informática das
empresas, nascidos como os antigos CPDs, se transformam hoje em núcleos com obje-
tivos muito mais amplos. Originalmente devotados a serem provedores de recursos de
TI, esses núcleos estão sendo cada vez mais convocados para a missão de participar da
estratégia de negócios da empresa, com desafios de melhorias em processos, adoção de
modelos de qualidade, otimizações de custos via novos modelos de utilização de seus
recursos, definição de estratégias de transformações de dados em informações e destes
em conhecimento etc.
No final de 2008, duas gigantes multinacionais deslocaram os seus CIOs para
um patamar hierárquico abaixo do CFO, numa clara alusão ao momento em que os
resultados financeiros devem ser os drivers principais dos negócios. Curiosamente, isso
foi um revival dos anos 1970, quando os antigos CPDs, que nasciam naquele momento,
eram colocados sob a capa hierárquica da área financeira. O mundo gira, e os fenôme-
nos se repetem.

RESUMO DA ÓPERA
Um dos elementos-chave e fundamentais dessa nova ordem corporativa é a
adoção formal dos conceitos de qualidade. A qualidade, em uma empresa, pode ser vista
em função dos seus processos, dos seus dados e dos produtos, advindo dessa combinação
o efeito psicológico transmitido pela sua imagem. Não basta a intenção despretensiosa
da alta gerência da empresa de praticar discursos modernos de qualidade. É preciso
muito comprometimento, algum investimento e bastante suor para abraçar a qualidade,
principalmente em uma indústria como a da informática, que nasceu sob a marca da
improvisação e da inspiração dos ninjas da programação Assembler.
A qualidade deverá ser perseguida em duas trilhas que se tocam constante-
mente: os processos e os dados. Se compararmos uma empresa com o corpo humano,
podemos mapear a estrutura organizacional e seus processos corporativos como os
órgãos fundamentais que compõem o nosso sistema biológico. Nessa analogia, os
dados seriam o sangue, capaz de levar os elementos vitais (informações e conheci-
mentos) às suas diversas regiões e fronteiras corporais. Aliado a esses dois elementos
fundamentais, junta-se um terceiro vértice, cada vez mais crítico na propulsão dos
fatores de qualidade da empresa: o recurso humano, conforme mostrado na Figura
2.2. O peopleware representa o agente condutor dos processos e os consumidores e
produtores dos dados e informações, formando a base do capital intelectual, talvez o
maior ativo dos anos 201x.

13
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 2.2
Processos, dados e pessoas, como o alicerce fundamental do capital
intelectual das empresas.

14
CAPÍTULO 3

Governança e qualidade de processos

Existe uma máxima em Minas Gerais que diz que de cano sujo não sai água
limpa. Talvez essa frase, simples como o capim, seja eloquente para justificar a escrita
dos dois próximos capítulos, nos quais discutiremos qualidade, em um livro que se pre-
tende de BI – Business Intelligence. Como veremos que BI é um processo fortemente
transformador de dados, podemos inferir que a qualidade dos processos e de seus dados con-
sumidos e produzidos em uma empresa seja fator crítico de sucesso na implementação
correta de BI. Afinal, se os processos são a tubulação de uma empresa, por onde circu-
lam os dados, de que adiantará termos uma forte camada de produção de informações e
conhecimentos, via sistemas de BI, se o insumo fundamental – que são os dados – chega
com qualidade duvidosa no momento da sua transformação?
Um dos jargões que ganharam mais “holofote” nos últimos sete ou oito anos,
dentro do universo corporativo, foi o termo “governança”. Nascida nas esteiras dos
escândalos americanos, como MCI, Enron etc., a palavra foi criando híbridos, a partir
do termo central, e produzindo derivações que tangenciaram aspectos diversos, mas
acabaram desaguando em qualidade e, em última análise, em reputação, em cuja pulve-
rização tudo começou.
Segundo a definição da Wikipédia, governança corporativa ou governo das so-
ciedades ou das empresas1 é o conjunto de processos, costumes, políticas, leis, regula-
mentos e instituições que regulam a maneira como uma empresa é dirigida, administra-
da ou controlada. O termo inclui também o estudo sobre as relações entre os diversos
atores envolvidos (os stakeholders) e os objetivos pelos quais a empresa se orienta. Os
principais atores tipicamente são os acionistas, a alta administração e o conselho de
administração. Outros participantes da governança corporativa incluem funcionários,
fornecedores, clientes, bancos e outros credores, instituições reguladoras (como a CVM,
o Banco Central etc.), o meio ambiente e a comunidade em geral.
A definição mais especializada de governança de TI, conforme o professor João
Roberto Peres, da FGV, consultor renomado e citado em várias fontes da internet, é:

Governança de TI é um conjunto de práticas, padrões e relacionamentos estruturados,


assumidos por executivos, gestores, técnicos e usuários de TI de uma organização, com a
1 Disponível em: http://pt.wikipedia.org/wiki/Governança_corporativa. Acesso em: 6 set. 2010.
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

finalidade de garantir controles efetivos, ampliar os processos de segurança, minimizar os


riscos, ampliar o desempenho, otimizar a aplicação de recursos, reduzir os custos, suportar
as melhores decisões e, consequentemente, alinhar TI aos negócios.

Embora não mencione diretamente os conceitos de processos e dados, é percep-


tível que esses dois ingredientes estão incluídos no contexto anterior. Sem qualidade
de processos e governança de dados, uma empresa não alcança controles efetivos, não
minimiza riscos, não gerencia segurança, não oferece suporte às melhores decisões e,
dificilmente, alinha TI aos negócios. Assim, pensar em governança de TI é também
considerar governança de dados, assunto do próximo capítulo, e qualidade de processos,
que contextualizamos a seguir.
A qualidade dos processos está sendo buscada nas empresas através da adoção
de modelos e normas que definem seus princípios. Essas normas, no fundo, quando
seguidas, permitem à empresa definir ou ajustar processos, por vezes já em execução,
porém agora revestidos de um controle mais efetivo que conduza à qualidade. A seguir
discutiremos, para efeito de contextualização da qualidade, alguns desses modelos, guias
e regulamentações adotadas e suas especificidades.
O padrão COBIT (do inglês Control Objectives for Information and related Technolo-
gy), é um guia voltado para a gestão de TI e possui foco mais em controles e auditorias,
fornecendo uma série de recursos que podem servir como modelo de referência para
gestão da TI nesse domínio. O COBIT é um guia de boas práticas apresentado como
framework e dirigido para a gestão de tecnologia de informação. Criado e mantido
pelo ISACA (Information Systems Audit and Control Association), possui uma série
de recursos que podem servir como modelo de referência para gestão da TI, incluindo
sumário executivo, framework, controle de objetivos, mapas de auditoria, ferramentas
para a sua implementação e, principalmente, um guia com técnicas de gerenciamento.
Especialistas em gestão e institutos independentes recomendam o uso do COBIT como
meio para otimizar os investimentos de TI, melhorando o retorno sobre o investimen-
to (ROI) percebido, fornecendo métricas para avaliação dos resultados (KPIs, KGIs
e CSFs). A ISACA já tem presença em algumas capitais do Brasil e se prepara para
estabelecer, em Minas Gerais, um dos seus capítulos. Mais informações sobre ISACA e
COBIT podem ser obtidas no link: http://www.isaca.org/.

ITIL
Para as áreas de infraestrutura de TI existe o ITIL (Information Technology
Infrastructure Library), desenvolvido originalmente pela CCTA (Central Computing
and Telecommunications Agency) e hoje sob custódia do OGC (Office for Government
Commerce). O padrão ITIL possui 12 gerências e se concentra na área de operações e
serviços. Basicamente, duas grandes áreas são definidas: suporte a serviços e entrega de
serviços.

16
ELSEVIER
C APÍTULO 3 I G OVERNANÇA E Q UALIDADE DE P ROCESSOS

Suporte a serviços
Inclui as áreas de:
1) Gerenciamento de incidentes, que possui o objetivo de reduzir os tempos
de indisponibilidade dos serviços.
2) Gerenciamento de problemas, que objetiva reduzir o impacto causado por
incidentes e impedimentos gerados por erros de infraestrutura de TI e criar
mecanismos de prevenção para a reincidência desses erros. Mantém uma
relação de similaridade com áreas de garantia da qualidade e de inspeções e
testes (verificação e validação), presente nos modelos CMMI e MPS.BR.
3) Gerenciamento de configuração, que objetiva identificar e controlar os
ativos de TI e itens de configuração (IC) definidos na organização, esta-
belecendo a rastreabilidade deles com os serviços oferecidos. Possui forte
mapeamento com a GCO (CM) – gerência de configuração de itens de
software –, presente nos modelos CMMI e MPS.BR.
4) Gerenciamento de mudanças, que objetiva minimizar os efeitos de mu-
danças solicitadas ou definidas como correção sobre a estrutura existente,
preservando a qualidade dos serviços oferecidos. Mantém uma relação de
similaridade com as atividades de controle de mudanças de requisitos no
ambiente de software, fator considerado crítico como agente de problemas
e de impedimentos.
5) Gerenciamento de liberações, que objetiva garantir que as instalações de
versões de hardware e de software sejam realizadas de forma segura, tes-
tada e devidamente autorizada pelos responsáveis e notificadas aos usuários.
Também tem um forte mapeamento com a GCO(CM) – gerência de con-
figuração de itens de software –, presente nos modelos CMMI e MPS.BR,
aplicada nas liberações de versões de software.

Entrega de serviços
Inclui as seguintes gerências:
1) Gerenciamento do nível de serviço, que objetiva garantir o respeito ao
acordo de nível de serviço (SLA) definido entre as partes envolvidas (for-
necedor e cliente).
2) Gerenciamento financeiro para TI, que objetiva definir e demonstrar com
transparência o custo real dos serviços prestados e gerenciá-lo adequadamente.
3) Gerenciamento de disponibilidade, que objetiva garantir a disponibilidade
e a confiabilidade dos recursos de TI, a fim de assegurar a satisfação do cli-
ente e a reputação do negócio.
4) Gerenciamento de capacidade, que objetiva garantir que a capacidade ins-
talada de infraestrutura esteja em consonância com as demandas de negó-
cios, oferecida e disponível no momento necessário.
5) Gerenciamento de continuidade, que objetiva prover a continuidade (não
interrupção) dos recursos, de forma que sejam recuperados quando reque-
ridos e em tempo hábil.

17
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

À Mais informações sobre ITIL e sobre o ITIL V3 podem ser obtidas no link
http://www.itilfoundation.org/ ou no livro de Marcelo Gaspar, Thierry
Gomez e Zailton Miranda, TI – mudar e inovar, da Editora Fenac (2010).

Lei Sarbanes-Oxley
A Lei Sarbanes-Oxley (Sarbanes-Oxley Act) é uma lei norte-americana as-
sinada em julho de 2002, proposta pelo senador Paul Sarbanes (democrata de
Maryland) e pelo deputado Michael Oxley (republicano de Ohio), motivada por
escândalos financeiros corporativos, dentre eles o da Enron, MCI etc., que acabou
por afetar drasticamente algumas empresas de auditoria e indiretamente a sociedade
americana, que investia em empresas aparentemente sólidas, porém com uma fra-
gilidade escondida. Essa lei foi redigida com o objetivo de evitar o esvaziamento
dos investimentos financeiros e a fuga dos investidores causada pela aparente in-
segurança a respeito da governança adequada das empresas. A lei Sarbanes-Oxley,
apelidada de Sarbox ou Sox, visa a garantir a criação de mecanismos de auditoria
e segurança confiáveis, incluindo regras para a criação de comitês encarregados de
supervisionar suas atividades e operações, de modo a mitigar riscos aos negócios,
evitando a ocorrência de fraudes, ou definindo formas de assegurar a sua detecção,
proporcionando transparência na gestão das empresas. Tornou-se obrigatória para
as grandes empresas com operações financeiras no exterior, além daquelas que
mantêm ADRs (American Depositary Receipts) negociadas na Bolsa de Nova York,
como Petrobras, Sabesp, Tam, OI, Ultrapar, Pão de Açúcar, Banco Itaú, Vivo e
Cemig, entre outras.
O resumo é que todo processo que busca qualidade – no sentido de controle,
transparência de produtos e serviços que atendem às expectativas de alguém – deve
pautar a sua aplicação por preceitos e práticas definidas, testadas e carimbadas como as
mais adequadas. Adotá-las não significa uma submissão cega e irrestrita aos preceitos
definidos, mas um encaixe de suas práticas no ambiente da empresa, moldando pessoas
e culturas, por vezes cristalizadas em procedimentos antigos e desenvolvidos pela intui-
ção. Mais informações sobre SOX podem ser obtidas em http://www.sarbanes-oxley-
-forum.com/.

CMMI
O CMMI (Capability Maturity Model Integrated) foi gestado e desenvolvido
pelo SEI (Software Engineering Institute) da Universidade de Carnegie Mellon, na
Pensilvânia.
O CMM(I) surgiu para desenvolver projetos grandes, de gerência altamente
complexa, torneados com escopo imutável e custo definido, além de altíssima aversão
a riscos. Os primeiros projetos CMM surgiram para a fabricação de softwares que visa-
vam a controlar naves espaciais, satélites inovadores e armamentos de tecnologia inédita.

18
ELSEVIER
C APÍTULO 3 I G OVERNANÇA E Q UALIDADE DE P ROCESSOS

O modelo foi publicado em 1989, por Watts Humphrey, no seu livro Managing the soft-
ware process. Watts Humphrey, considerado o pai do modelo, faleceu em 28 de outubro
de 2010, pouco depois de terem sido escritas estas linhas.
O Departamento de Defesa (DoD) americano, responsável por esses pro-
jetos estratégicos, não tinha outra saída, naquele momento, senão sugerir méto-
dos altamente estruturados, com forte gerência de requisitos e estrito controle das
partes envolvidas. Um ambiente no qual o escopo era (ou tinha de ser) definido
rigorosamente, pois o software era tido como um componente de algo maior, cuja
infalibilidade era a premissa primeira, até porque naves espaciais, satélites, equipa-
mentos médicos etc. implicavam aspectos de segurança de vida. Os usuários não
eram stakeholders colaborativos, como agora temos, e entravam no circuito do pro-
cesso somente para os testes, tendo pouca intervenção durante o ciclo do projeto.
Esse conceito era chamado de low trust. O sistema era desenvolvido por processos
cuidadosamente definidos, centrados no menor risco, na fortíssima padronização e
em relacionamentos amplamente costurados por contratos rígidos entre clientes e
desenvolvedores. Isso acabou moldando a personalidade do modelo CMMI para
ambientes que os americanos chamavam de high ceremony e low trust, ou seja, com
alto nível de controle de risco e aplicação de gerência e com baixa interveniência
dos usuários. As entregas, por sua vez, também obedeciam a uma receita da época:
os deliveries eram monolíticos e infrequentes. Por quê? Porque a parada de um avião
caça de guerra para troca de possível componente (software incluído) ou a suspen-
são da funcionalidade de um aparelho médico podia custar muitas horas de logística.
Na época, é claro, não se baixava um software pela internet. Além disso, entregar
o componente funcionando na sua plenitude, no primeiro delivery, era premissa de
primeira ordem. Tudo isso em um projeto gigantesco, com envolvimento de múlti-
plas empresas, com inúmeras equipes e entrelaçado por contratos governamentais
exigentes em termos de baixo risco.
Com o tempo, o CMM ganhou variantes para outros projetos (não somente
de software) e não demorou o pleito para que todas essas derivações fossem empaco-
tadas em um único modelo, nascendo assim o CMMI, em 1998. O CMMI foi evo-
luindo e hoje forma o framework, com um conjunto melhorado de padrões, práticas e
ideias. Mas a sua gênese trouxe marcas que definiram o método e que se observa no
seu genoma:
1) Aplicado a projetos grandes e de alta complexidade.
2) Aplicado a projetos com múltiplas equipes, oriundas de empresas diferen-
tes e até competidoras entre si, em que a competitividade influía e o alto
protocolo definido substituía a confiança (trust) e a coesão das equipes,
definindo um ambiente com traços de low trust. Ou seja, a confiança entre
as equipes não se dava por coesão, integração e interação constante delas
(valor do relacionamento do capital humano), mas pelo nível de cerimônia,
rigor e protocolo que o processo impunha.

19
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

3) Aplicado a projetos nos quais os deliveries eram monolíticos e infrequentes,


pois a logística de parada dos seus receptores de software (aviões, satélites e
devices médicos) implicava sérios riscos. A ideia era entregar o “todo” com
“quase tudo” funcionando na primeira vez.
4) Os projetos precisavam ter baixos riscos (aversão intensa a riscos) devido
às suas características técnicas especiais e ao alto investimento de recursos
públicos, dadas as características dos projetos.

Assim nasceu um modelo CMMI, fortemente estruturado, revestido pelo rigor


das regras e com baixa interação do capital humano (entre equipes), porém aplicado a
projetos gigantes e de alta complexidade operacional e gerencial. Isso, entretanto, não
significa que o modelo não pode ou não deve ser aplicado em projetos que possuem
estilo e ciclos de vidas diferentes. Um modelo, qualquer que seja, deve ser visto como
um guia e não como uma regra ortodoxa calcada sobre preceitos imutáveis. Mais infor-
mações sobre CMMI podem ser obtidas em http://www.sei.cmu.edu/cmmi/.

ISO
A International Standard Organization (ISO) define normas em vários
segmentos da indústria, além de software. Conforme o Wikipédia, disponível em
http://pt.wikipedia.org/wiki/ISO_12207, e acesso em 15 de fevereiro de 2011, a ISO
12207 é uma norma definida pela International Organization for Standardization, que
se aplica em engenharia de software. Ela estabelece um processo de ciclo de vida do
software, contendo processos, atividades e são aplicadas durante a aquisição e configu-
ração dos serviços do sistema, de forma a melhorá-los. A norma 12207 estabelece um
conjunto de processos fundamentais (5), processos de apoio (8) e processos organiza-
cionais (4). Além dela, existe a ISO 15504, que define normas sobre métodos de ava-
liação de qualidade nas empresas. A Norma ISO/IEC 15504, conforme disponível em
http://pt.wikipedia.org/wiki/ISO/IEC_15504 e acesso em 15 de fevereiro de 2011,
define um modelo bi-dimensional que tem por objetivo a realização de avaliações de
processos de software com o foco da melhoria dos processos (gerando um perfil dos
processos, identificando os pontos fracos e fortes, que serão utilizados para a elaboração
de um plano de melhorias) e a determinação da capacidade dos processos viabilizando
a avaliação de um fornecedor em potencial.

À Mais informações sobre a ISO 12207 podem ser obtidas em http://


www.12207.com/. Para mais informações sobre a ISO 15504, acessar:
http://www.isospice.com/categories/ISO%7B47%7DIEC-15504-Standard/.

MPS.BR
Quem trabalha há muitos anos com informática, como eu, sabe que ela nasceu
nos anos 1940 e se desenvolveu nos anos 1960 e 1970 com forte viés de artesanato.
Os então analistas de sistemas se baseavam muito em feeling e intuição para definir pro-
cedimentos, algoritmos e modelos, muitos calcados no estilo de um artesão intelectual.

20
ELSEVIER
C APÍTULO 3 I G OVERNANÇA E Q UALIDADE DE P ROCESSOS

Tal como um escultor escolhe e lapida um bloco de mármore para transformá-lo em


uma obra, o analista de sistema daquela época assim procedia, esculpindo a sua lógica
com um processo próprio e personalizado. Essa fase romântica da informática produziu
grandes sistemas e soluções validadas pelo tempo. Entretanto, com uma nova ordem
empresarial, centrada em informação e competitividade, os aspectos de qualidade passa-
ram a exigir processos e atitudes mais planejadas e menos intuitivas.
O artesanato de software nos permitia reconhecer, sem ler o prólogo de um pro-
grama, o autor das suas linhas de código, tal como hoje identificamos um Van Gogh ao
observar estilos e pinceladas impressionistas do mestre holandês. A característica pessoal
aplicada como um artista levava à fácil identificação do autor pela simples observação
do estilo adotado nos loops, if/then/else etc. Hoje, tente identificar o autor de um código
Java olhando diretamente as chamadas de métodos e instanciações de objetos. Você não
conseguirá! Além das características de linguagens diferentes, vivemos a transição do
processo de artesanato para a fase da engenharia de software. Nesta, processos, melhores
práticas, padrões de projetos (design patterns), refactoring etc. servem como driver para a
aplicação da criatividade, que continua, como sempre, fundamental ao bem fazer de um
sistema ou projeto. Isso não significa dizer que os talentos estarão tolhidos ou subjuga-
dos nessa nova forma de fazer sistema. Significa que eles serão mais bem aproveitados
em um processo que todos entendem e são capazes de repetir. Os gênios farão mais
rápido do que os mortais, mas todos serão capazes de fazer, seguindo a receita correta-
mente definida.
Dentro dessa linha de qualidade de processo, diversas correntes foram definidas,
por diferentes organismos. No Brasil, hoje, existem duas correntes, com objetivos seme-
lhantes, porém com públicos diferentes: o CMMI, discutido anteriormente, focado em
empresas com maior capacidade de investimento, e o MPS.BR (Melhoria de Processo
de Software Brasileiro), focado nas empresas da base da pirâmide.
O MPS.BR nasceu dentro da Softex (Associação para a Promoção da Exce-
lência do Software Brasileiro), buscando um modelo que melhor absorvesse os pontos
positivos do CMMI e da ISO, criando uma proposta ajustada à realidade brasileira,
contemplando as suas dificuldades e seus aspectos culturais. Nascido dessa forma, o
MPS. BR traz alguns conceitos mais evoluídos em implementação e avaliação de
qualidade nas empresas, focando pontos aos quais o CMMI não havia dispensado
muita atenção. Por exemplo, o modelo MPS.BR não permite que a mesma equipe
de implementadores seja também aquela que vai realizar a avaliação. Além disso, o
MPS.BR já nasceu com um período de validade para o seu selo (três anos), conceito
somente adotado recentemente pelo CMMI. A adoção do modelo se suaviza quando
comparada com o CMMI, pelo fato de se terem definido sete níveis de maturidade,
o que permite uma ascensão mais gradual e planejada na escala de maturidade, con-
forme as Figuras 3.1, 3.2 e 3.3.

21
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 3.1
Modelo MPS.BR – processos dos níveis G
e F (equivalentes ao nível 2 do CMMI).

Figura 3.2
Modelo MPS.BR – processos dos níveis E, D
e C (equivalentes ao nível 3 do CMMI).

22
ELSEVIER
C APÍTULO 3 I G OVERNANÇA E Q UALIDADE DE P ROCESSOS

Figura 3.3
Modelo MPS.BR – processos dos níveis B e A
(equivalentes aos níveis 4 e 5 do CMMI).

À Todas as informações sobre o modelo MPS podem ser obtidas direta e gra-
tuitamente nos respectivos guias, publicados no site da Softex: http://www.
softex.br/mpsbr/_guias/default.asp.

Resumindo, o conceito de qualidade de processo está diretamente relacionado


com a qualidade dos dados por eles consumidos ou produzidos. Os diversos modelos
estão evoluindo em busca de maior alcance no universo empresarial, visando a um alar-
gamento do espectro da qualidade. Hoje, por exemplo, o CMMI se desloca em direção
a outros segmentos, criando o que se chama de “constelação”, e se especializando em
CMMI-DEV (CMMI for Development), focado no desenvolvimento de software, no
CMMI-SVC (CMMI for Services), focado no segmento de serviços, e CMMI-ACQ
(CMMI for Acquisition), para aquisição e terceirização de bens e serviços.
O MPS também foca em aquisições de software e serviços correlatos, atentan-
do para a área crítica de compras. O ITIL V 3, lançado em 2007, também apresenta
evoluções na área de serviços. A ISO, originalmente mais ampla, apresenta a ISO 9126,
focada em qualidade específica na área de produtos de software. Isso tudo se junta ao
conceito mais amplo e emergente de BPM (Business Process Management), com foco na
otimização de resultados das empresas através da melhoria de seus processos de negó-
cios. Essas melhorias, aplicadas aos processos seminais da empresa, nasceram há alguns
anos com a chegada dos pacotes ERPs e continuam em alta. O conceito de BPM apon-
ta para modelagem, controle e automatização de processos, e este tem sido um grande

23
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

momento para o entendimento e o resgate dos ativos de informação que circulam por eles.
Assim, a máxima mineira de que “de cano sujo não sai água limpa” é eloquente para
sugerir que os processos deverão estar bem entendidos e definidos para que os dados
e as informações estejam num teor adequado de qualidade e prontos para as tomadas
de decisões dos níveis estratégicos, táticos e operacionais da empresa. Conceitualmente
simples, porém desafiador na prática; quanto mais não fosse, pelo fato de os dados terem
sido sempre considerados uma espécie de combustível colateral dos processos e não um
ativo empresarial.

24
CAPÍTULO 4

Governança e qualidade de dados

Qualquer empresa que mantenha intenções de competitividade nesta arena leo-


nina dos anos 201x deverá ter, além da preocupação com a melhoria dos processos,
como visto no capítulo anterior, um foco no outro lado do espectro: os dados. Essa
dualidade entre dados e processos sempre existiu e mostra que esses dois pilares são
fatores críticos em empresas que tencionam seguir os caminhos da reputação via qua-
lidade. Fazendo uma comparação superficial, é como entender que um bom prato é
fruto de uma boa receita (processo) e de bons ingredientes (dados). Se um dos dois
não estiver adequado, o produto final poderá perder em qualidade. Além disso, como a
proposta de BI (business intelligence) é transformar dados em informações que possam
ser usadas para ações analíticas, tomadas de decisões tático-estratégicas e até definições
operacionais, a qualidade dos dados que serve como input para o BI se reveste, cada vez
mais, de extrema importância. Lembre-se de que BI é um processo fundamentalmente
transformador; logo, a qualidade do seu input vai refletir diretamente na correção das
tomadas de decisões efetuadas.

CONCEITOS E MOTIVAÇÕES PARA GOVERNANÇA DE DADOS (GD)


Governança de dados é uma expressão recentemente produzida na esteira dos
jargões que brotaram a partir do termo “governança”. Extraída do contexto maior da
governança corporativa e meio implícita na governança de TI, a de dados foca prin-
cípios de organização e controle sobre esses insumos essenciais para a produção de
informação e conhecimento das empresas. O controle mais estrito e formal de dados
não é um desafio surgido nos dias de hoje. Os dados, entre os insumos corporativos, são
aqueles que mais apresentam características de fluidez, pois perpassam diversos proces-
sos, sofrem mais transmutações porque são trabalhados em diversos pontos do seu ciclo
de vida, dando origem a outros, além de nem sempre possuírem uma fonte e um destino
claramente formalizados.
Com o advento dos bancos de dados, nos anos 1970, essa necessidade de maior
controle formal sobre esses ativos apareceu com o nome de administração de dados.
Algumas empresas desenvolveram áreas e processos para definir controles sobre esses
recursos, mas sempre com resultados relativamente frágeis. A administração de dados
objetivava a definição controlada de modelos integrados, regras de utilização, criação
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

de dicionário de dados em que cada elemento pudesse ter uma definição corporativa
única, com ampla riqueza de metadados, além de critérios para uso e aplicações de
padrões de segurança. Tudo isso se mostrava importante e atraente. Porém, o sucesso e
a efetividade conseguidos na administração de bancos de dados não puderam ser re-
petidos na área de administração de dados. Vários pontos podem ser analisados como
possíveis justificativas para essa baixa adoção: um deles, o fato de que qualquer pro-
posta deve estar pronta no momento certo em que sua necessidade é plenamente de-
mandada. Talvez a AD já estivesse quase pronta, porém faltou a força da necessidade,
o que impediu a sua plena adoção naquela época. Além desses fatores, o surgimento
de soluções empacotadas, como os ERPs, relativizou a importância da AD, visto que
os pacotes já traziam no seu cerne modelos de dados preestabelecidos, aos quais as
empresas deveriam se ajustar. Ou seja, os modelos conceituais de dados, um dos ob-
jetivos da AD, já chegavam prontos às empresas, definidos, integrados e empacotados
por soluções blindadas de ERP.
O fenômeno do processamento descentralizado, encaixado no conceito de
downsizing, também influiu na diminuição de importância daquela proposição, vis-
to que os dados foram democraticamente distribuídos entre os departamentos da
empresa, dificultando sobremaneira o seu controle. Os dados eram duplicados, re-
plicados e “eneplicados”, à medida que os departamentos desejavam ou precisavam.
Hoje, com o mundo empresarial premido por valores como reputação, competitivi-
dade, globalização, regulamentações etc., os cenários são diferentes. Nos tempos de
hoje, com grande taxa de fusão/merge e parcerias de empresas, o aspecto de replica-
ção de cadastros de dados mestres nas empresas tornou-se um problema recorrente.
Informações sobre clientes, fornecedores, colaboradores, materiais etc. são replica-
das à medida que as empresas são incorporadas, com potenciais efeitos negativos.
Além dessas replicações por aquisições de empresas, outros tipos de dados, como
os semiestruturados e os não estruturados (e-mails, fotos, vídeos etc.), em volumes
cada vez maiores, passaram a ser produzidos no âmbito da economia digital e do
advento da internet.
Novamente, uma luz amarela foi acesa nos domínios da administração des-
ses insumos fundamentais. Algo deverá ser repensado nesse campo. A apatia que se
estabeleceu sobre esses importantes ativos organizacionais deverá ser revista com
os cuidados demandados pela sociedade da informação. Assim, os conceitos de go-
vernança corporativa e de TI foram estendidos para os domínios de governança de
dados, visando não somente à organização desses acervos, mas também a aspectos
típicos desses novos tempos. Os cuidados singulares com a segurança de dados, a
necessidade da sua definição clara e sem ambiguidade, maior fluidez na sua dis-
tribuição e o uso democrático e controlado se tornaram alguns drivers dessa nova
fronteira. Além disso, existem alguns vetores apontando para o fato de que, em al-
guns países, a governança de dados poderá ser obrigatória em breve, dentro de uma
capa regulatória que demandará que o valor dos dados seja considerado um ativo da
empresa e que a sua qualidade seja traduzida em métricas, compondo indicadores-
-chave de desempenho da área de TI. Isso foi definido pelo fato de que a qualidade

26
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

dos dados implica riscos corporativos que a nova TI e o novo papel de CIO deverão
estar preparados para mitigar.
Diferentemente dos tempos em que os dados eram simples combustíveis de
programas Cobol ou “eneplicados” aos borbotões pelas áreas negociais das empre-
sas, agora eles se tornam elementos fundamentais do capital intelectual da empresa,
geradores que são de informação e conhecimento. Por tudo isso, a governança de
dados será um tema recorrente nos próximos anos, e as empresas deverão se pre-
parar para adotá-la ou, no mínimo, entendê-la com a profundidade com que será
discutida.
A definição de governança de dados (GD) é ampla e plural. É um concei-
to em evolução, que envolve o cruzamento de diversas disciplinas, com foco em
qualidade de dados, passando por avaliação, gerência, melhoria, monitoração de seu
uso, além de aspectos de segurança e privacidade associados a eles. Para tal, as em-
presas deverão definir objetivos organizacionais e processos institucionalizados, que
deverão ser implementados dentro do equilíbrio fundamental entre TI e áreas de
negócios. Através da GD, as empresas hoje também definem mecanismos para ana-
lisar os processos que se abastecem de dados ou os produzem, criando um sentido
maior de qualidade conjunta entre esses dois elementos seminais (dados e processos)
e contribuindo para a valorização desses ativos através do pleno conhecimento da
cadeia produtiva de informação e conhecimentos. Como processo organizacio-
nal, a GD estabelece políticas e diretrizes corporativas legislando sobre os dados e
atribuindo papéis de criadores/produtores (collectors), mantenedores (custodians) e
consumidores de dados (consumers), gerando a trinca CCC (collectors, custodians and
consumers), destaques na era de GD. Acoplados com os preceitos de GD surgem com
muita força os aspectos de qualidade de dados e de informação. Assim, a GD pode
ser vista como um guarda-chuva conceitual sob o qual se abrigarão diversas ações
que, no fundo, visam à melhoria desses insumos, agora fundamentais à luz dos novos
tempos: os dados.

ALGUNS FRAMEWORKS PARA DEFINIÇÃO DOS COMPONENTES


DA GOVERNANÇA DE DADOS
Dentro dessa linha de arcabouço conceitual, discutiremos alguns frameworks de
GD, que contemplam essas variedades de conceitos e propostas. O framework de go-
vernança de dados da Figura 4.1 mostra, por exemplo, os componentes principais que
embasam a sua proposta, centrada na abordagem do 5W2H:

27
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 4.1
Visão geral sobre governança de dados com 5W e 2H.

1) O quê? (What): definir claramente a governança de dados como um com-


ponente dentro da visão de governança corporativa e de TI, voltada para os
recursos de dados, as informações e os conhecimentos da empresa, o seu uso
controlado, a sua qualidade e as diretrizes para o seu consumo e produção.
2) Por quê (Why): como os domínios de dados de uma empresa são amplos
e sensíveis, há que se definir claramente os objetivos que se deseja alcançar
com a adoção de um programa de governança de dados. Por exemplo, é
possível basear-se na missão da empresa e em alguns de seus valores, anali-
sados sob certos prismas:
 Dimensão empresa, mercado e clientes: a constante preocupação com a di-
nâmica do mercado, que pode envolver aspectos de regulação, aderência às
normas e aos relacionamentos com clientes, além de fatores surgidos por
fusões e parcerias etc.
 Dimensão da qualidade: pode ser baseada na qualidade corrente de dados
do sistema, no número de erros e reclamações decorrentes dessa qualidade, e
dos riscos pelas perdas de valores reais ou de reputação devido aos problemas
originados na manifestação da baixa qualidade desses ativos.
 Segurança dos dados: pelo crescimento do volume de dados, o aumento da
conectividade da empresa e o consequente volume de acessos aos dados,
criando fronteiras mais expostas e aumentando as chances de invasões, adul-

28
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

terações e uso indevido de dados e informações. Os aspectos de privacidade


de dados são fatores também considerados nesse ponto.
 Liquidez e disponibilidade da informação: pela crescente necessidade de ob-
ter mais rapidamente as informações competitivas e confiáveis demandadas
por áreas estratégicas da empresa, nem sempre integradas pelos dados. Além
disso, pela demanda por novos aplicativos em novos domínios (mineração de
comportamento de clientes, de colaboradores, gerência de projetos, dados
não estruturados etc.), geração e retenção cada vez maior de conhecimento
do negócio da empresa, sempre considerando o dado como elemento cen-
tral na produção de informação e derivação de conhecimento.
Uma forte motivação organizacional é fator preponderante na adoção corpora-
tiva e no engajamento e comprometimento com um programa cuja implementação não
é trivial. Ela envolve esforços e investimentos, além de fortes alterações culturais visando
quebrar paradigmas enraizados, como o “proprietarismo” , as “paróquias” de dados e a
indulgência sobre o descontrole a que esses importantes ativos foram relegados.
3) Onde (Where): como qualquer programa de natureza organizacional, de-
verá seguir os preceitos de pensar globalmente e agir localmente. Definir
claramente que áreas deverão ser focos prioritários dos trabalhos de GD
é um dos primeiros passos. Por exemplo, áreas críticas em que residem os
MD (Master Data – dados mestres), como clientes, fornecedores, produ-
tos, locais etc. Os dados considerados mestres já são focos de uma perna
da GD denominada MDM (Master Data Management), que explora-
remos adiante. As áreas escolhidas deverão ser aquelas que apresentam
maior sensibilidade aos negócios, permitindo abordagem que objetive a
produção mais consistente de dados e informações para a geração de co-
nhecimentos estratégicos e melhoria nos processos de tomadas de decisão
da empresa.
4) Quando (When): planejar a implementação dos programas de GD em ci-
clos, com iterações que possam produzir melhorias metrificadas em termos
de qualidade, controle e segurança de dados. Um projeto dessa natureza
certamente requererá iterações com entregas periódicas de resultados, que
permitam a sua reavaliação constante e o seu amadurecimento ao longo
do caminho. Uma abordagem com ciclo de vida “cascata” num processo
dessa natureza certamente implicará altos riscos. De novo, vale a filosofia de
pensar globalmente e agir localmente.
5) Quem (Who): identificar e trabalhar com os principais envolvidos nas áreas
críticas definidas, contemplando os CCC (Creators/Collectors, Consumers
e Custodians), que, traduzidos, seriam os criadores, mantenedores e consu-
midores dos dados. Definir um grupo capaz de conduzir as ações propostas,
numa espécie de escritório de dados que, através de reuniões, acompanhe o
desenvolvimento e a implementação da estratégia, envolvendo todos os in-
teressados e definindo caminhos e alterando rotas, quando necessário. Seria
o equivalente ao PMO para os projetos e o SEPG (Software Engineering

29
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Process Group) para os processos. Seria algo como o DGPG, ou Data


Governance Process/Program Group, ou DMO (Data Management
Office). Um conselho de governança de dados, composto por elementos
de várias áreas de negócios e TI, atuando como um comitê de supervisão, é
fator fundamental na solidificação do programa na consolidação da parceria
TI e negócios, e na resolução de conflitos.
6) Como (How): pensar em definir as regras e as diretrizes do processo de GD
através de políticas que deixem claro quais são as restrições, suas aplicações e
os envolvidos. Também a definição de direitos, padrões e responsabilidades
associados ao uso, à atualização e à liberação das informações. Definir como
se pretende a implantação dos mecanismos ou subprojetos de melhoria e
alcance dos objetivos traçados na missão. Por exemplo, implantando um
plano de qualidade de dados, baseado na filosofia de TDQM (Total Data
Quality Management), do MIT, para as ações de melhoria de qualidade, ou
desenvolvendo projetos na área de MDM (Master Data Management), para
tratamento de cadastros mestres considerados estratégicos. Definir objetivos
e métricas que possam ser usadas para medir o alcance do programa, dentro
da ótica de que somente se gerencia aquilo que se mede. Por exemplo, di-
minuição de erros em dados, redução de número de reclamações/erros por
liberações de sistemas e produtos, redução de dados mestres duplicados em
áreas recentemente submetidas a fusão/merging, diminuição da proliferação
de bancos de dados setorizados etc.
7) Quanto (How much): o programa de GD deverá contemplar um con-
junto de projetos que, por definição de prioridades, implicará custos
de várias naturezas. Custo de pessoal envolvido, custo de software/har-
dware, custo de treinamento, consultoria e mentoring etc. Tentar obter
ROI pode ser uma tarefa difícil, devido aos ganhos intangíveis que a
qualidade, ou a falta dela, traz à imagem, à marca e à reputação da em-
presa. Uma boa estratégia a adotar é trabalhar com o “custo negativo”:
imagine o custo de uma área pública de saúde com dados mal contro-
lados sobre cidadãos atendidos em suas unidades. Imagine, por hipótese,
que dois cidadãos atendidos tenham o mesmo nome: José Ferreira dos
Santos. Imagine também que um tenha problema de diabetes (hipergli-
cemia) e o outro tenha crises de hipoglicemia. Imagine as complicações
produzidas se as fichas forem trocadas por falta de identificação mais
efetiva de registros, ou seja, um descontrole na qualidade dos dados.
Imagine o quanto os problemas de qualidade de dados podem significar
em termos de reputação ou de valores mais significativos do que esse!
Larry English, no seu livro Information Quality Applied, da Editora Wiley
(2009), apresenta, no capítulo 1, uma tabela com dezenas de exemplos
que mostram o alto custo da baixa qualidade.
A Figura 4.2 mostra outro framework de governança de dados, que permite uma
visão alternativa de seus componentes e implementação.

30
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

Figura 4.2
Framework de governança de dados.

À O framework da Figura 4.2 foi adaptado do artigo “Five Steps to Data


Governance”, de Mike Cochrane, publicado na revista Information Magazine,
de março de 2009. Disponível em: http://www.information-management.
com/2007_56/10014953-1.html. Acesso em: 4 jan. 2010.

 Definição da estratégia: a governança de dados deve ter um driver clara-


mente estratégico, movido por objetivos oriundos da missão da empresa.
Isso permitirá a definição formal de áreas que organizem e planejem as
ações de GD, dando a devida autoridade e garantindo o comprometimento
requerido.
 Definição de papéis: os papéis deverão ser enumerados, a começar pela alto
board, que deverá definir as políticas, as regras e os padrões. Além desse
board, os papéis dos responsáveis pelos dados, no sentido de seu registro,
manutenção e controle, além dos outros envolvidos na sua utilização tática
e operacional (CCC). A definição de um grupo de implantação do progra-
ma de GD deverá ser formada a partir da alta gerência, envolvendo as áreas
prioritárias da empresa, sendo fator crítico a presença das áreas de negócios.
 Definição de políticas, regras e padrões: as políticas e padrões deverão ter
escopo interno, buscando dar o arcabouço de apoio ao processo a ser se-
guido, e também o escopo externo, focando a aderência a possíveis normas

31
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

e regulamentações internacionais, e a reputação e a imagem da empresa.


Algumas métricas deverão ser definidas para garantir uma monitoração nu-
mérica do projeto.
 Definição de processo para GD: um processo deverá respaldar os projetos
que comporão o programa de governança de dados. Alguns projetos envol-
verão a definição da arquitetura de dados, de processos e a apuração da qua-
lidade de dados de áreas estratégicas da empresa, entre outros. Esse processo
corporativo de GD deverá ser baseado em práticas de melhorias de processo.
Pela experiência vivenciada em implementação de processos de qualidade
para empresas de software, adiante discutiremos processos para esse tipo de
implementação.
 Apoio tecnológico: essa camada será composta pelo arsenal de tecnologia
disponível para alcançar os objetivos da GD. Envolve ferramentas de quali-
dade e segurança de dados, de BI, de mining, de MDM, EAI, metadados etc.,
todas associadas diretamente aos aspectos de dado, integração, transformação
e utilização.
Além das proposições anteriores, compostas de conceitos mais amplos, existem
algumas que são frutos das ações diretas de grandes empresas de serviço e de consultoria,
voltadas para essa nova seara.

FRAMEWORK DE GOVERNANÇA DE DADOS – IBM


A IBM, por exemplo, define um framework de GD, conforme a Figura 4.3. Os
elementos que compõem a sua proposta são os seguintes.

Figura 4.3
Visão sobre governança de dados – framework – IBM.

32
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

Resultados
Nesse contexto, a IBM propõe duas grandes ações: a primeira foca os riscos
apresentados pelos dados com relação aos aspectos de qualidade, com impactos sobre
a reputação corporativa, e os aspectos de aderência a normas internacionais. Os riscos
deverão ser identificados, qualificados, quantificados e depois analisados para definir
mecanismos de mitigação, contingência, aceitação ou transferência. Além disso, nesse
mesmo contexto de resultados (outcomes), a IBM aponta a necessidade de valoração dos
ativos de informação, ou seja, um processo de aculturamento corporativo que reflita so-
bre os valores dessa nova camada de ativos (ativos de informação), ainda hoje com uma
formalização relativamente incipiente.

Viabilizadores
No framework apresentado, a IBM aponta elementos que viabilizarão a implan-
tação de um programa de GD. A parte mais proeminente mostrada é a conscientização
sobre a importância da GD e a definição de uma estrutura organizacional que estabe-
leça um nível mútuo de responsabilidade entre TI e áreas de negócios, aplicado sobre
os dados em diferentes camadas de gerência. Nesse contexto, são destacadas as políticas
que definem direcionamentos estratégicos, apontando o comportamento desejado pela
empresa a respeito da forma de atuação dos envolvidos no programa.
Também surge como viabilizador o conceito de data stewardship, disciplina de
controle de qualidade para garantir o cuidado custodial dos dados visando à sua melho-
ria e a gerência de riscos envolvidos. O conceito de custódia se aplica no sentido de que
os dados, sendo um ativo corporativo, portanto não pertencentes a ninguém, estarão, ao
longo do seu ciclo de vida, sob os cuidados de departamentos, áreas etc., responsáveis
por parte do seu ciclo de vida. Algumas propostas sugerem a combinação de criadores
de dados (creators) com proprietários (owners) e outras consideram mais a custódia como
elemento de responsabilidade atribuído à área de TI, por seus procedimentos de arma-
zenamento, administração de dados e de banco de dados. Independentemente da forma
estabelecida, essas definições estratificadas de responsabilidade deverão ser exercidas,
gerenciadas e auditadas.

Disciplinas centrais
Nesta parte do framework aparece a gerência de qualidade de dados, composta
de processos definidos para medir, melhorar e certificar a qualidade e a integridade dos
dados, nos seus diferentes domínios, de produção a teste e arquivos históricos (archival).
A essa proposta se associa a gerência do ciclo de vida da informação, com processos
definidos para coleta, uso, retenção e eliminação de informações. Essa camada termina
com as considerações sobre segurança e privacidade da informação, visando ao controle
e à proteção desses ativos com relação à sua utilização.

Disciplinas de apoio
Nessa última camada do framework da IBM aparecem disciplinas de suporte, com
ênfase na arquitetura dos dados, objetivando a definição ou documentação de modelos

33
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

de dados, no âmbito dos dados estruturados ou não estruturados, que visam a garantir o
entendimento que facilitará a disponibilidade e distribuição desses ativos. Uma arquite-
tura de dados e seus modelos não poderão prescindir da definição dos metadados, que
representam a semântica dos elementos de informação, regras de negócios e tipos de da-
dos, e que fazem a junção entre o conhecimento humano e os processos automatizados.
Finalmente, o framework se fecha com uma camada na qual serão gerados procedimentos
de controle, como auditoria, visando à monitoração do processo e às consequentes
ações de ajustes de rumo consideradas necessárias.
Como pode ser percebido pela análise dos frameworks mostrados, alguns ele-
mentos são seminais na formação dos conceitos de GD. A definição de uma estrutura
corporativa formal, composta por elementos de TI e de negócios, de políticas amplas
de dados, de projetos de qualidade de dados, de definição de metadados, de auditorias
e de métricas é fundamental para o estabelecimento das primeiras camadas de GD de
uma empresa que se convenceu de que os ativos de dados e informações não poderão
mais ser vistos como produtos colaterais da execução de processos empresariais. Como
esse processo de GD não se mostra trivial, essas empresas certamente começarão por
implementações e modificações culturais gradativas, alcançando patamares crescentes de
maturidade, conceito discutido a seguir.

MATURIDADE EM GOVERNANÇA DE DADOS


A adoção de certas práticas exige determinado grau de amadurecimento das
empresas, principalmente quando falamos de mudanças que passam pela cultura or-
ganizacional, como é o caso. Na esfera de processos, o CMMI (Modelo Integrado de
Capacidade e Maturidade) prescreve cinco níveis para serem trilhados, e o MPS.BR
(Melhoria do Processo de Software Brasileiro) tem sete na sua escala. A ideia por trás
dessas escalas é que nenhuma empresa consegue galgar pontos de maturidade em tempo
menor do que a sua cultura permite. Ou seja, tal como nós, as empresas precisam rodar
durante certos períodos, aplicando as práticas apontadas e criando uma camada cultural
que lhes permita gradativamente ascender na escala do modelo. Alguns modelos de
maturidade e qualidade se valem dessa necessidade de amadurecimento gradual e de-
finem níveis que são planejados pelas empresas, de acordo com o oxigênio disponível
para abraçar tais mudanças. Diferentemente do CMMI e do MPS.BR, o conceito de
governança de dados, numa espécie de metaproblema, ainda carece de maior amadure-
cimento na definição do que venha a ser maturidade em GD. Assim, existe um conjun-
to de fatores que, se observados de perto, deverão sugerir um grau de maturidade nesse
complexo domínio dos dados:
1) Preocupação organizacional: representa a percepção de que os problemas de
dados, nos aspectos de áreas responsáveis, nos domínios de modelagem e inte-
gração, na esfera dos metadados, na preocupação com qualidade e segurança
etc., estão formalmente na tela de radar dos gestores da empresa, grandes pa-
trocinadores do plano de GD. Essas preocupações poderão ser originadas de
fontes como o posicionamento estratégico com a qualidade de dados, a mo-
delagem de processos de negócios ou de posicionamentos frente a exigências
regulatórias. Poderão ser manifestadas através de políticas organizacionais.

34
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

2) Definição de papéis: um dos primeiros passos nesse caminho é bem definir


os papéis dos responsáveis pelos diferentes recursos de dados (stewardship),
passando pelos seus gestores, produtores, mantenedores e consumidores. As
empresas mais maduras em GD já se estruturam com alguns desses papéis.
3) Definição de políticas: as políticas deverão ser definidas como um conjunto
de regras, diretrizes e orientações de alto nível que aponte caminhos de
cunho corporativo para a implantação da GD. Deverá ser um instrumento
que confira direcionamentos, tenha visibilidade de toda a empresa, seja
revista periodicamente e tenha o pleno endosso da alta gerência, compro-
metida com o programa de GD.
4) Definição de métricas: os conceitos de valor agregado em função de ado-
ção de processos de qualidade não são facilmente explicitados. Por isso, a
adoção de métricas que permitam comparações e benchmarks deve ser uma
das primeiras ações de monitoração de um processo dessa natureza. Esses
argumentos, na forma numérica, devem ser buscados e tornados públicos e
claros, pois são eles que facilitam a argumentação de adoção e manutenção
de uma estratégia de GD que poderá ser onerosa e longa.
5) Gerência de riscos: a definição de um processo de risco aplicável ao plano
de implementação de GD e uma demonstração de riscos de não possuir
uma governança de dados são encontradas nos primeiros graus de ma-
turidade. Os dados, como elementos vitais dos sistemas das organizações,
deverão ter os riscos intrínsecos de sua falta de qualidade e de aspectos de
segurança e de privacidade devidamente considerados no plano de im-
plementação de GD. Nesses planos deverão constar classificações e taxo-
nomias de riscos, processos de priorização através de análise de impacto e
probabilidade de incidência, além de ações de monitoração que permitam
movimentos de mitigação e de contingência.
6) Segurança, privacidade e aderência: definem os aspectos que controlam
o uso dos dados, garantindo a sua segurança, a manutenção de sua priva-
cidade e sua correção, quando das atividades de auditorias de aderência
aos modelos. Essas práticas, no fundo, estão associadas à gerência de
riscos, definida anteriormente. Os aspectos de segurança deverão seguir
normas formais, passando por segurança lógica (acessos, invasões etc.)
e segurança física (backups e mecanismos de recuperação de dados).
Os aspectos de privacidade deverão obedecer a regras de permissões
seletivas de acesso por papéis, considerações sobre divulgação impró-
pria de informações etc. Os aspectos de aderência a normas regulatórias
poderão ser o elo entre a governança de dados com modelos como
ITIL, Cobit, Sox etc. Essas considerações sugerem um grau mediano de
maturidade em GD.
7) Arquitetura de dados: define regras sobre a criação de arquiteturas integra-
das de modelos de dados, com mecanismos para a sua utilização. Deverão

35
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

ser analisados e considerados os diferentes ambientes corporativos, como


ambientes transacionais e informacionais. Os ambientes transacionais, que
conferem o suporte aos sistemas básicos da empresa, contemplando pro-
cessos vitais como venda, aquisição, pessoal, contas a pagar e a receber,
estoque etc., seriam a base da arquitetura. Os sistemas informacionais, como
centro da camada de inteligência de negócios, contemplando arquiteturas
de depósitos de dados (data warehouses, data marts) e as camadas de ETC
(Extração, Transformação e Carga), complementariam a arquitetura. Esses
dois modelos possuem estruturas de dados diferentes que sugerem arquite-
turas e processos diferentes.
8) Qualidade de dados: define os aspectos de qualidade nos seus diversos
domínios, conforme já discutidos anteriormente. Os diferentes tipos de
processos de verificação e acerto de dados estariam nesse contexto. A
qualidade de dados poderá adotar, por exemplo, o TQDM – proposta de
Total Quality Data Management, do MIT –, que define que os dados de-
vem ser vistos e controlados como um produto de transformação, sendo
insumo e resultante de processos que deverão ser definidos e mapeados.
Aqui a governança de dados se encontra com o BPM (Business Process
Management).
9) Classificação de dados e definição de seus metadados: esse ponto é considera-
do de fundamental importância, pois implica a catalogação de todos os dados
existentes na empresa, classificando-os e enriquecendo o seu conteúdo com
uma camada semântica normalmente não encontrada em tabelas de bancos
de dados. A ideia é a criação/manutenção de um dicionário ou repositório
de dados, que concentre a definição dos dados com metadados, colocados em
ambientes acessíveis, com facilidade de mecanismos de busca. Aqui a gover-
nança de dados se encontra também com a gestão de conhecimento.
10) Gerência do ciclo de vida da informação: define as fases que deverão ser
contempladas na vida do dado/informação, desde seu nascimento até o seu
descarte. Todas as etapas deverão ser documentadas, na forma de atividades,
com entradas, saídas, responsáveis, sequência etc., tal como um processo
definido em modelos de maturidade. Nesse ponto é fundamental a identi-
ficação da trinca CCC. Aqui a governança de dados tangencia a definição
de processos.
11) Auditoria: define os processos organizacionais que serão aplicados visando
à auditoria dos processos em que os dados são produzidos, transformados,
divulgados etc., criando medições sobre a eficácia do processo e a variação
da qualidade dos dados neles percebida. Aqui a governança de dados se
encontra com a área de qualidade e de medições.
Com o crescimento da discussão sobre o conceito de governança de dados apa-
receram algumas propostas para definir maturidade nesse domínio. Grande parte dos
conceitos discutidos anteriormente aparece disposta em camadas crescentes de maturi-
dade das empresas.

36
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

MODELO GARTNER – EIM (ENTERPRISE INFORMATION


MANAGEMENT)
O Gartner Group, empresa de alta reputação na área de consultoria e análise de
tendências em TI, definiu um modelo, chamado EIM (Enterprise Information Manage-
ment), conforme mostrado na Figura 4.4. O Gartner definiu seis níveis de maturidade
em governança de dados, descritos a seguir.

Figura 4.4
Maturidade em governança de dados. Gartner – EIM (Entreprise
Information Management).

Nível 0
Ausente (Unaware): nível em que as decisões estratégicas são feitas baseadas em
informações quase sempre não controladas pela ótica da qualidade. As empresas neste
nível normalmente não mostram uma arquitetura de informações, além de desconhe-
cerem princípios e políticas que regulem o compartilhamento de informações. Os con-
ceitos básicos de GD discutidos anteriormente, como segurança e metadados, também
não estão presentes. As ações cabíveis nessas empresas estão associadas com sensibiliza-
ção da alta gerência, com o desenvolvimento de projetos de medição de qualidade, via
pesquisas qualitativas ou análises quantitativas em arquivos fundamentais. Esses resulta-
dos podem iluminar os riscos existentes pela baixa qualidade dos dados corporativos,
principalmente no campo da reputação ou de regulamentação e aderência a normas.

Nível 1
Consciente (Aware): neste nível já há o entendimento sobre o valor da informa-
ção como ativo. Os primeiros insights sobre a necessidade de padrões comuns e sobre
os riscos que advêm dos aspectos de se ter fontes inadequadas de dados aparecem neste
nível. As ações cabíveis nesse patamar estão associadas ao desenvolvimento estratégico

37
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

de EIM (no jargão Gartner), alinhadas com objetivos da empresa. As sementes para o
desenvolvimento da arquitetura corporativa são lançadas neste nível.

Nível 2
Reativo (Reactive): a consciência sobre o valor da informação como ativo im-
portante da empresa e o seu compartilhamento em projetos cross-functional surgem neste
nível. Também o uso compartilhado de dados entre departamentos é notado. O con-
ceito de qualidade é considerado, embora ainda de forma reativa, dependendo de cada
projeto ou de iniciativas pontuais. As relações entre as áreas, do ponto de vista de dados,
ainda é da forma ponto a ponto, e são realizadas as primeiras ações para coletas de me-
dições que indiquem o estado da qualidade dos dados na empresa. Neste nível deve-se
intensificar as ações que tratam dos aspectos de compartilhamento de informações entre
departamentos ou unidades de negócios.

Nível 3
Proativo (Proactive): a informação e o seu valor passam a ser vistos como elemen-
tos estratégicos da empresa, e seu compartilhamento necessário para a viabilização de
iniciativas no âmbito corporativo. A arquitetura de informações da empresa é criada e
mantida, e a estrutura de GD e os papéis relacionados são formalizados. Os princípios
de GD são incorporados ao PDS (Processo de Desenvolvimento de Sistemas) da em-
presa. As ações nesse nível identificam oportunidades de gerencia efetiva e melhoria em
unidades organizacionais dependentes de dados críticos.

Nível 4
Gerenciado (Managed): neste nível, a empresa passa a considerar os dados como
recursos críticos. Políticas, padrões e procedimentos são definidos e aceitos por toda a
empresa. A área de GD existe e se afirma como elemento de resolução de aspectos re-
lacionados à gerência de informação cross-functional. Métricas são definidas como forma
quantitativa de monitoração das ações empreendidas e dos projetos desenvolvidos. As
ações de qualidade de dados são definidas na forma de um conjunto integrado de pro-
jetos, sempre com os resultados analisados juntamente com a alta gerência da empresa,
fechando o ciclo de resultados que espessam a consciência sobre os dados como ativos
críticos da organização.

Nível 5
Efetivo (Effective): o valor da informação é obtido através da cadeia de supri-
mentos de informação e são estabelecidos níveis de acordo de serviços. A alta gerência
percebe as vantagens competitivas de explorar os ativos de informação da empresa. A
GD tem atuação corporativa institucionalizada. As ações se resumem à manutenção do
estado alcançado e os cuidados com os controles e auditorias visando a se resguardar de
possíveis complacências e não conformidades com relação aos processos estabelecidos.

38
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

MODELO IBM – MATURIDADE EM GOVERNANÇA DE DADOS


A IBM também apresenta um framework estratificando as possíveis camadas de
maturidade por que passa uma empresa com relação à governança de dados. A Figura
4.5 ilustra a proposta e está detalhada a seguir. O modelo da IBM, baseado no CMMI,
tem cinco níveis:

Figura 4.5
Maturidade em governança de dados – IBM.

Nível 1
Inicial: neste nível, as empresas têm um processo imprevisível, reativo, totalmen-
te dependente de pessoas e de iniciativas isoladas. Os dados são produtos colaterais da
execução de um conjunto de processos da empresa e não são vistos como um recurso
corporativo. Existe um grau de redundância instalada, e os dados são elementos docu-
mentados em níveis de departamentos e/ou sistemas, sem uma visão integrada e ampla.
Não existe a aplicação do conceito de metadados.

Nível 2
Definido: neste nível, os processos são parcialmente definidos, sendo aplicados
em projetos separados. As primeiras preocupações com os dados são localizadas e de-
senvolvidas em projetos, sem ainda uma visão corporativa integradora. Os primeiros
conceitos de governança de dados, metadados e arquitetura corporativa são discutidos.
Os processos desenvolvidos são repetidos em projetos separados.

Nível 3
Definido: neste nível já existe uma orquestração corporativa buscando processos
mais padronizados que possam ser usados e adaptados nos diferentes projetos. Uma ar-

39
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

quitetura corporativa é definida com controle centralizado de metadados. Os papéis de


data stewardship começam a ser implementados, e uma espécie de escritório central de
dados (DMO) controla e aplica os conceitos de governança de dados.

Nível 4
Gerenciado quantitativamente: neste nível, os processos passam a ser controlados
de forma numérica, com definição de medições e análise de seus comportamentos.
Alguns processos, considerados mais críticos, são escolhidos para serem trabalhados na
forma de gerência estatística, buscando a sua estabilização e o controle das causas raízes
de variação.

Nível 5
Processo otimizado: neste nível, os entendimentos quantitativo e qualitativo são
usados objetivando a melhoria contínua dos processos. Há plena consciência da impor-
tância da governança de dados e dos dados como ativos fundamentais da empresa.

À As considerações e elaborações sobre os frameworks anteriores (IBM e


Gartner) foram baseadas na publicação NASCIO Governance Series, Data
Governance Part-II Maturity Models – A Path to Progress. Disponível em:
http://www.nascio.org/publications. Acesso em: 25 maio 2010.

MODELO DE MATURIDADE EM GOVERNANÇA E QUALIDADE DE


DADOS
A Tabela 4.1 mostra outra visão de maturidade em governança e qualidade de
dados com suas respectivas características. Os níveis mostrados são também baseados
nos mesmos preceitos do modelo CMMI e foram adaptados das definições de David
Loshin, do livro The Practitioner’s Guide to Data Quality Improvement (Burlington, MA:
Morgan Kaufmann, 2011, p. 45-51):
 Nível inicial, em que não existe formalização corporativa sobre dados, e
todos podem fazer da maneira que desejarem.
 Nível repetido: alguns procedimentos isolados são aplicados e repetidos, sem
conotação de uma visão organizacional uníssona.
 Nível definido: os primeiros procedimentos, regras e políticas começam a
ser delineados e há a indução para o uso dos dados de forma mais orques-
trada e corporativa.
 Nível gerenciado: estruturas mais formais, métricas e tecnologia são imple-
mentadas na empresa, visando ao controle mais estrito dos dados.
 Nível otimizado: caracteriza-se pelo alto grau de automação e pela busca da
melhoria contínua.

40
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

Tabela 4.1
NÍVEIS DE MATURIDADE EM GOVERNANÇA E QUALIDADE DE DADOS

NÍVEL CARACTERÍSTICAS

Inicial As ações sobre a qualidade de dados são reativas; não há expecta-


tivas de qualidade centradas em medidas/métricas, por exemplo; as
políticas de dados, se existem, são informais e não documentadas;
ações são tomadas separadamente sem coordenação; os erros de
qualidade de dados descobertos são corrigidos sem coordenação
com os processos de negócios; as causas raízes de erros não são
identificadas e os erros se repetem no tempo; pouco ou nenhum
aspecto associado à qualidade de dados; não há o papel de data
steward (gestores de dados/informação); as responsabilidades para
correção são atribuídas de forma aleatória; há pouco ou nenhum
padrão definido (ou respeitado); os dados são representados em
estruturas replicadas; não há ferramentas adequadas para filtros
ou monitoração de dados falhos/imprecisos; os impactos propor-
cionados pelos dados “impuros” são manifestados e descobertos
tempos depois dos fatos geradores do erro.

Repetido Há uma antecipação tímida de erros relativos aos dados; algumas


expectativas sobre dimensões de qualidade são articuladas (preci-
são, consistência estrutural, consistência semântica, completude,
atualidade, disponibilidade etc.); há tentativas de se organizarem
fontes únicas de dados (single source of truth data sets); privacida-
de e controle de uso são definidos separadamente; políticas iniciais
sobre dados são delineadas; há a habilidade de se identificar erros
de não completude ou de sintaxe e estrutura inválida; análises de
causas raízes de erros são inicialmente identificadas; melhores prá-
ticas começam a ser adotadas por áreas separadas; princípios para
políticas, procedimentos e regras de qualidade de dados começam
a ser desenvolvidos.

Definido Procedimentos e processos são definidos para precisão e validação


de dados; qualidade de dados implementada nas principais linhas
de negócios/áreas funcionais com a criação do papel de gestores
de dados; validação feita automaticamente e ações de correção
analisadas manualmente; a estrutura organizacional de GD aparece
com políticas, guias documentadas e aprovadas; padrões corpo-
rativos e gerência de metadados são instituídos; procedimentos
padronizados para uso de ferramentas de análise de qualidade de
dados; ferramental tecnológico para análise de qualidade de dados
implementado.

Gerenciado Certificações de fontes de dados são aplicadas; arquivos mestres


identificados e controlados (MDM-I); há auditoria de qualidade de
dados; GD com membros representantes das principais linhas de
negócios da empresa; há reuniões periódicas colaborativas de GD;
GD direcionada por SLA de qualidade de dados; gerência quantita-
tiva de qualidade de dados.

41
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Otimizado Processos automatizados de detecção de problemas; sistemas de


autogerência em uso; controles de dados ao longo de toda a em-
presa; métricas e políticas constantemente revisadas e melhoradas;
MDM-II (gerência de dados mestres) implementada.

Fonte: Baseada em Loshin, D. The Practitioner’s Guide to Data Quality Improvement.


Burlington, MA: Morgan Kaufmann, 2011, p. 45-51.

Como resumo, uma espécie de “Road map” de GD ou os 12 mandamentos, que


deverão ser observados:
1) Criação de um grupo de estudo envolvendo a TI e as áreas de negócios
cujos dados sejam mais sensíveis e críticos, como dados financeiros, de clien-
tes, de vendas etc. É fator crítico de sucesso o alto envolvimento das áreas de
negócios.
2) Definir políticas para a conceituação de dado, como um ativo (asset) da
empresa e diretrizes para a formação do comitê de governança de dados da
empresa.
3) Definir os riscos de dados “impuros” (data flaws) ou como os aspectos de
baixa qualidade dos dados criam impactos no negócio da empresa. A defi-
nição de riscos potenciais ou de “business cases” de problemas derivados de
qualidade de dados é fator crítico na aprovação de um programa de gover-
nança de dados, pela alta gerência.
4 ) Inventariar, nas áreas envolvidas, TI inclusive, as principais fontes de dados, de
forma a se ter uma visão do grau de replicação de arquivos considerados críticos,
como BD de clientes, de pessoal, de materiais, financeiro etc. Esse item, que
oferece uma visão qualitativa do problema, compõe parte do item 3.
5) Selecionar as bases de dados consideradas mais críticas para tratamento
quantitativo de qualidade. Buscar e aplicar soluções de data profiling em
bases escolhidas baseadas em priorização, visando demonstrar o grau de qua-
lidade dos dados considerados críticos.
6) Analisar as lacunas observadas e o nível de maturidade atual em dados. Com
eles, fazer a proposição de plano de ação, que poderá envolver a criação de
gestores de dados (data steward) localizados em áreas críticas de negócio da
empresa. Os gestores de dados atuam em áreas funcionais/linhas de negócios
com a responsabilidade de aplicar e preservar as políticas, regras, diretrizes de
qualidade, como criação, uso, replicação etc.
7) Sempre atuar com o conceito de quick hits, ou seja, realizar ações que retor-
nem rapidamente resultados visíveis e importantes.
8) Pensar a GD em camadas funcionais distintas:
 A camada estratégica, onde está o comitê de GD ou conselho de dados,
ou que nome venha a ter. Formado por gerentes funcionais de áreas (TI,
inclusive), terá o objetivo de estabelecer as políticas e diretrizes que definem

42
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

o dado como um ativo da empresa. Resolverá impasses que certamente


surgirão e será uma espécie de comitê consultivo.
 A camada tática com o grupo de implementação do programa de GD
(DGPG, Data Governance Program/Process Group), formado pela gerência
média, responsável pela execução dos planos de ação. As palavras-chave aqui
são: envolvimento, cooperação e convencimento por resultados concretos.
A gerência de uma área de negócios deverá ter pleno entendimento das
definições de GD, vindas daquele comitê, a fim de apoiar as ações de seus
gestores de dados e as definições do DGPG.
 A camada operacional, com os gestores de dados (data steward) alocados nas
áreas e linhas de negócios, responsáveis pelas atividades do dia a dia. Por exem-
plo, na área de faturamento de uma empresa de energia elétrica, poderá haver
gestores de dados divididos em domínios ou subdomínios como faturamento
secundário/primário/grandes consumidores de alta tensão etc. O aproveita-
mento de recursos humanos nas áreas de negócios, com grande conhecimen-
to do assunto (subject area), pode ser considerado uma excelente estratégia
na definição dos gestores de dados (data steward). Esse conceito é chamado
de “governança de dados não invasiva” e foi definido por Robert Seiner, da
Kikconsulting, especialista em governança e administração de dados.
9) Iniciar ações para conhecer e entender os dados existentes através de levan-
tamento de termos de negócios, visando a formação do repositório de meta-
dados, contendo definições, relacionamentos e áreas de negócio responsáveis
pela sua criação, custódia e consumo (CCC).
10) Definir mecanismos de monitoração do programa, através de ações de medi-
ções (MED) ou de garantia da qualidade (GQA), criando indicadores, como
número e tipos de “incidentes” relativos a dados, problemas de reclamações
externas devido a erros de dados, não conformidades com definições regu-
latórias detectadas etc.
11) Pensar a governança de dados em alguns projetos específicos, selecionados pela
prioridade, como MDM (Master Data Management), segurança de dados, qua-
lidade dos dados para tomada de decisão (BI com Analytics), dados não estru-
turados (Geo-BI, por exemplo) etc. Por exemplo, na trilha MDM, identificar as
ações para reduzir as replicações de fontes de dados críticos (consumidor, órgãos,
produtos etc.), levantados no item 4. Envolver as áreas de negócios que atuam
no domínio daquele dado e criar ações alinhando business e TI. Esses projetos
devem ser vistos como iterações do processo maior de GD, aplicando-se neles
as atividades de identificação de metadados, definição de métricas, garantia da
qualidade etc. Na trilha de BI com Analytics, considerar aspectos de governança
no sentido de identificar por áreas de negócios: os seus usuários, os relatórios
ou cubos produzidos e consumidos, o valor de retorno dessas informações de
BI para o usuário, frequência e tipo de solicitações atendidas etc. Esse trabalho
deverá ser feito com envolvimento do BICC (núcleo de BI) e apontará, de certa
forma, o grau de maturidade com que a área de BI atua.Ver mais adiante deta-

43
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

lhamento sobre maturidade em BI, conforme pesquisa da TDWI. Na camada


de dados não estruturados, entender que 80% dos dados de uma empresa hoje
estão na forma semiestruturada ou não estruturada. Assim, aspectos relacionados
com dados de mapas, GED (gestão eletrônica de documentos) etc. devem ser
observados, e também merecer os olhares da GD.
12) Por fim, entender que GD é um programa e não um projeto, portanto, tem
características contínuas, e que o processo desenhado para implementá-lo
deverá ser constantemente avaliado por medições e ganhos tangíveis, o que
viabiliza a sua continuidade e minimiza os riscos de seu colapso.

MATURIDADE EM BI – MODELO TDWI (THE DATA WAREHOUSE


INSTITUTE)
A essência deste livro, na sua primeira versão, era o conceito de BI com aprofun-
damentos em modelagem e tecnologia, como sugere o título lançado em 2001. A nova
versão, BI2, procura estabelecer uma ligação entre dois conceitos que, há algum tempo,
se desenvolvem em trilhas paralelas: BI e qualidade de dados. Os aspectos de maturidade
em gerência, governança e qualidade de dados, descritos anteriormente, guardam uma
forte correlação com BI, à medida que um BI será tão mais amadurecido quanto maior
for a qualidade dos dados que transitam pelas camadas de ETC. Assim, aspectos de ma-
turidade em BI também estão sendo pensados, talvez buscando um conjunto de fatores
que possam personalizar a maturidade de sua aplicação. Uma das primeiras propostas para
uma escala de maturidade de empresas nos domínios do BI foi feita em 2002 pelo TDWI
(The DataWarehouse Institute), núcleo de altíssima competência em aspectos de BI, data
warehousing, mining etc. O TDWI sugeria uma escala horizontal, representando fases
diferentes por que passam as empresas à medida que evoluem em certos domínios do BI.
A proposta do TDWI usa notação semelhante ao do desenvolvimento do ciclo de vida
de uma pessoa: pré-natal (prenatal), infância (infant), criança (child), adolescente (adolescent),
adulto (adult) e maduro (sage). O TDWI, hoje, define um conjunto de domínios sobre
os quais essa avaliação de posicionamento das empresas é feito. Essa análise pode ser feita
acessando o site da TDWI (http://tdwi.org/pages/misc/benchmark-your-bi-maturity-
-with-tdwis-new-assessment-tool.aspx) e respondendo a um questionário no qual são
levantados atributos de cada domínio. Ao final, o TDWI mostra o nível de posicionamen-
to dos seus dados com relação à população já avaliada. Os domínios avaliados são: escopo,
patrocínio, apoio financeiro, retorno, arquitetura, dados, desenvolvimento e entrega.

Escopo
O escopo se refere à amplitude com que o grupo de BI da empresa, também
chamado de BICC (BI Competency Center) atua. Podem ser classificadas como: apli-
cações pessoais, com desenvolvimento para a própria área; departamental local, com o
desenvolvimento para um departamento dentro de uma unidade de negócios; depar-
tamental empresa, com desenvolvimento para um departamento que atende a várias
unidades de negócios; unidade de negócio, desenvolvendo para todos os departamentos
dentro de uma unidade de negócios; corporativo, para todas ou várias unidades de negó-

44
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

cios; e, finalmente, intercorporativo, desenvolvendo para todas as unidades de negócios e


mais clientes e fornecedores, ou seja, ultrapassando os limites da empresa e alcançando
uma espécie de BI colaborativo, envolvendo parceiros de negócios.
O escopo de atuação da equipe de BI dá sinais de certa maturidade alcançada pela
empresa à medida que indica o grau de aceitação dos conceitos e aderência por parte das
unidades corporativas. Outra indicação é a forma pela qual os executivos percebem os ob-
jetivos do BICC: um núcleo dessa natureza pode ser visto como um centro de custo da área
de TI ou como um recurso de nível tático, sendo convocado somente em certos momentos
de tomada de decisão. Também pode ser observado como um recurso de missão crítica,
atuando em faixas de sistemas de maior importância, ou como um recurso estratégico,
tendo atuação-chave para o alcance de objetivos de desempenho. Finalmente, o grupo de
BICC pode ser observado como um diferencial competitivo, sendo considerado chave para
objetivos como manutenção de clientes e/ou expansão de mercados etc. Essa percepção
é fundamental, pois dá a ideia do grau de retorno por parte dos usuários, com relação ao
papel desempenhado pelo núcleo de BI da empresa e o quanto é a sua contribuição para
o consumo de informações nas diferentes camadas da empresa.

Patrocinador
Esta dimensão aponta o nível e o poder do patrocinador e/ou apoiadores mais
fortes do BICC: pode ser o CIO ou um diretor de TI, ou um patrocinador de uma uni-
dade de negócios/departamento, ou múltiplos patrocinadores oriundos de várias unidades
de negócios ou, finalmente, múltiplos níveis de comitês de supervisão pluridepartamental
orientados a negócios. Além de ter um patrocinador, é importante o grau de compro-
metimento dele com relação ao programa de BI/DW da empresa e o quanto ele é con-
siderado responsável pelos resultados obtidos pela BICC, com relação à solução de BI/
DW. Esse talvez seja um dos fatores mais importantes na consolidação de uma área de BI.

Apoio financeiro
Nesta dimensão, a empresa é avaliada na sua maturidade, através do tipo de or-
çamento de que dispõe, como orçamento departamental ou de unidade de negócios, ou
orçamento corporativo ou recursos próprios. Também a facilidade ou o esforço com que
o orçamento é obtido denotam o grau de maturidade da empresa em termos de BI.

Retorno
Representa a demonstração de resultados através de valores de negócios quan-
tificáveis e dos valores de retornos intangíveis, produzidos pelo BICC. Outro ponto
importante se refere a como os usuários constantes (power users) e os usuários casuais
(casual users) veem o valor retornado pelo BICC, graduado em: irrelevante para as suas
funções, com valor relativamente marginal, pois o BI tangencia suas funções; relevante,
pois são impactados pelas ações do BICC; crítico ou considerado fator-chave de su-
cesso, quando dependente em alto e muito alto grau, respectivamente. Essa é, no fundo,
uma expressão qualitativa do ROI (retorno de investimento).

45
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Arquitetura
A arquitetura representa a forma mais usual como as soluções de BI são imple-
mentadas. Pode ser na forma de spreadmarts (criados e mantidos por uma pessoa para
atender a necessidades pontuais de relatórios e de análise) ou data marts não integrados
(criados para servir a um departamento ou atividade de negócios cujo metadado é isola-
do e mantido sem compatibilidade com outras unidades da empresa), ou data warehouse
não integrado (formado de várias fontes, cujo metadado também não se reconcilia com
outros sistemas da empresa), ou data warehouse integrado (seguindo tanto a linha de Bill
Inmon quanto a de Ralph Kimball) ou, finalmente, um serviço de BI, estratégia que
usa uma interface comum para acessar via web services ou camada de EII (Interprise
Information Integrator) os recursos de informação.

Dados
Nesta dimensão de dados são avaliados vários fatores. Um deles é o grau
em que determinado usuário consegue acessar (acessibilidade) os dados de que
necessita, com graduações que vão da alta dificuldade até o nível muito alto de
acessibilidade, quando consegue acessar todos os dados requeridos. Também o grau
de liberdade que o BICC definiu as tecnologias e os padrões de ferramentas (au-
tonomia) e o nível em que os grupos e outras áreas aderiram a eles indicam
maturidade alcançada na aplicação de BI. Além disso, é avaliado o grau em que o
BICC estabeleceu, documentou e implementou definições, regras e métricas sobre
BI. Outro fator que nos remete ao ponto central da dualidade BI e qualidade é
também levantado: o grau de confiança que os usuários demonstram com relação
ao ambiente de BI/DW definido/gerenciado pela área BICC. Esse item sugere que
a qualidade dos dados deverá, cada vez mais, ser considerada como elemento-chave
nos insumos de dados usados nos processos de BI. Ainda dentro desse arco de qua-
lidade, há a indagação sobre a forma como os modelos de dados são sincronizados,
denotando preocupação com os aspectos de integração entre eles. Alguns dados
numéricos são levantados dentro desta dimensão de dados: quantas fontes de dados
o ambiente de BI/DW trata e, na média, qual é a frequência com que a maioria
dos dados são atualizados (refreshed). Esse ponto tem a ver com a frequência defi-
nida para as atividades de ETC (extração, transformação e, principalmente, carga).
Finalmente, no domínio de dados, uma avaliação sobre a integração de dados não
estruturados, mostrando uma tendência do BI2, que passa a se preocupar com esse
crescente tipo de insumo. Para as perguntas de cunho qualitativo, as alternativas de
respostas variam entre baixo, moderado, alto e muito alto.

Desenvolvimento
O domínio do desenvolvimento se relaciona com a forma pela qual a empresa
realiza o desenvolvimento das aplicações de BI. A graduação vai de desenvolvimento
isolado de aplicações ad hoc, usando as ferramentas necessárias, independentemente de
estarem alinhadas com padrões definidos, ou de aplicações isoladas, porém usan-

46
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

do o conjunto de ferramentas alinhadas com as definições do BICC, ou de portfólios


de aplicações integradas usando os processos e as ferramentas padrão, alinhadas com a
arquitetura definida, e, finalmente, na forma federada, permitindo que as unidades de
negócios desenvolvam suas aplicações desde que respeitando os padrões, os processos e a
arquitetura corporativa definida. Associado a esse item também está o grau de liberdade
com que o grupo de BICC define, documenta e implementa padrões de desenvolvi-
mento, teste e implementação de aplicações de BI/DW. Outros pontos considerados
na avaliação da maturidade são o grau em que os gerentes de projetos acompanham o
cronograma dos projetos de BI, o número de projetos concorrentes realizados nos últi-
mos meses (com relação à pesquisa do TDWI), além do tempo médio demandado para
se incluir uma nova área (Subject area) no ambiente de BI/DW.

Entrega
Para a dimensão “entrega” são avaliados diversos itens. O primeiro passa pela
opção que melhor descreve o objetivo de alto nível do seu ambiente de BI. Pode va-
riar entre a produção de relatórios para consumo organizacional ou a possibilidade de
análise de tendências, ou a monitoração de eventos de negócios para possibilitar ações
proativas, ou fazer previsão de resultados e modelar planos e, finalmente, automatizar
processos, incluindo interações com clientes.Também a forma como os usuários casuais
são considerados é sintoma de maturidade e pode ser forma não controlada ou forma
self-service, com produção de relatórios usando as ferramentas padrão, ou forma delega-
da, em que um grupo treinado de usuários (super-users) cria relatórios para determinado
grupo ou área, e, finalmente, a entrega customizada, quando o BICC desenvolve uma
série de relatórios e dashboards parametrizados, que poderão ser usados pelos usuários
casuais. Um ponto muito importante levantado no benchmark é a forma de utiliza-
ção dos metadados. Essa preocupação é uma das diretivas da GD e pode ser avaliada
das seguintes formas: não há uso de metadados ou o usuário consulta os relatórios de
metadados periodicamente distribuídos, ou o usuário faz consulta de metadados nos
vários repositórios existentes, ou o usuário consulta metadados no repositório central,
ou ainda o usuário acessa metadados com um clique, dentro do contexto em que tra-
balha. Um outro indicador é a relação entre usuários constantes e casuais, o que denota
a maturidade da empresa, quando o primeiro supera em muito o número do segundo.
Finalmente, a definição do número de usuários, clientes e fornecedores que consomem
conteúdo do seu ambiente de BI/DW, dando ideia do grau de intensidade em que a
empresa aplica o BI colaborativo.

À Essa análise de maturidade em BI foi elaborada com base na pesquisa


(survey) realizada pelo TDWI (The Data Warehouse Institute). Disponível
em: http://tdwi.org/pages/misc/benchmark-your-bi-maturity-with-tdwis-
-new-assessment-tool.aspx. Acesso em: 28 jul. 2010. Você pode entrar com
as informações sobre o perfil de sua área de BI, e o site mostra o resultado,
enquadrando a sua empresa em um comparativo com as outras que preen-
cheram a mesma pesquisa.

47
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

DEFINIÇÃO DE PROCESSO PARA IMPLANTAÇÃO DE PROJETOS


DE GOVERNANÇA DE DADOS
Nesse contexto, vamos conduzir o conceito de GD de forma mais ampla, de
maneira que possamos incluir sob o seu guarda-chuva todas as iniciativas importantes
sobre os ativos de dados da empresa. Poderão ser iniciativas de pesquisa para a melho-
ria de qualidade dos dados, desenvolvimento de aplicações MDM em bases de dados
mestres, implementação de sistemas de segurança de dados, criação de metadados,
implantação de sistemas de qualidade de dados ou de desenvolvimento de aplicativos
BI, mining etc. Nesse contexto, o conceito de GD se amplifica, conforme sugere o
DAMA – The Data Management Association, para além das fronteiras de normatiza-
ções e aspectos regulatórios de dados, criando um ambiente adequado para gerenciar
dados em variadas dimensões. Isso significa que o conceito de governança de dados,
quando visto como um processo, poderá ser definido por um metaprocesso genérico
(estilo PDCA), através do qual serão criados processos específicos para cada uma de
suas áreas de atuação. Teríamos, por exemplo, um processo para ser aplicado na pró-
pria definição e estruturação da área de GD, um processo definido para projetos de
qualidade e profiling de dados, um processo para projetos de MDM ou para projetos
de segurança, projetos de BI, mining etc. Isso permitirá que, sob a capa conceitual de
GD, tenhamos diversos processos padrão, definidos através de um metaprocesso e que
suportarão projetos dentro do programa de GD. A Figura 4.6 mostra, na forma de um
diagrama de classes, os conceitos de processo padrão de GD e dos vários processos
definidos (adaptados) para alguns dos projetos, de acordo com a sua natureza. Adiante
mostraremos, com detalhes, um processo definido para projetos de MDM.

Figura 4.6
Processo padrão para GD e alguns processos definidos.

A pergunta que cabe neste ponto é como definir um processo de GD com os


seus processos específicos. A resposta vem pela aplicação dos conceitos de maturidade
do CMMI e MPS.BR, que definem formas de descrição de processos. A definição de
um processo padrão para executar o desenvolvimento de um projeto de software ou de

48
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

qualquer natureza deve seguir certa receita. Para escrever um processo, ou um conjunto
deles, há que se ter um processo-guia. Nesse ponto, as coisas entram em certo loop, pois
passamos a falar de um processo que será necessário para definir outros processos. Esse
conceito, chamado de metaprocesso, pode ser visto na realidade como uma autoajuda
que orienta na definição e escrita de um processo específico. A Figura 4.7 mostra um
esquema que ilustra um pouco mais esses conceitos.

Figura 4.7
Processo padrão para projetos de governança de dados.

Primeiramente, aparece um grupo de GD, que foi denominado DGPG (Data


Governance Process/Program Group), similarmente aos encontrados nos tradicionais
projetos de engenharia de software, denominados SEPG (Software Engineering Process
Group). Esse grupo seria o responsável pelas ações e definições de processos na área de
GD, devendo ter a presença imprescindível de pessoas da área de negócios da empresa,
descaracterizando os movimentos de GD como sendo iniciativa da área de TI. Esse grupo
se valerá de um metaprocesso escolhido, que pode ser PDCA, IDEAL ou qualquer outro,
para definir e escrever os processos da área de GD. Nesse caso, a ilustração é de um me-
taprocesso PDCA. Todas essas ações que objetivam a definição e a escrita de processos de
GD deverão estar sob a capa de um ou mais projetos da empresa, exatamente para que se-
jam considerados todos os recursos necessários para tal alcance. Dessa forma, o projeto no
qual desenvolveremos o processo padrão usará como guia o metaprocesso PDCA. Assim,
serão criados os processos de GD, ou seja, um processo padrão, ou vários processos padrão
específicos (um para cada tipo de projeto), ou um processo padrão que dará origem, por
adaptação, a vários processos definidos. Esses processos, após a sua aprovação, serão usados
nos projetos de GD aplicados na empresa. Observe que, no gráfico mostrado, existem
dois símbolos que se referem às adaptações. As adaptações são procedimentos aplicados
em processos, necessários para ajustá-los de acordo com as características dos projetos nos

49
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

quais serão aplicados. No linguajar de engenharia de software, os processos adaptados a


partir do processo padrão são denominados processos definidos. A primeira adaptação
mostrada é do próprio metaprocesso, que aqui representa o primeiro nível de processo
padrão (mais geral), e a segunda adaptação é a do processo padrão escrito, quando da sua
aplicação nos projetos específicos de GD, gerando o processo definido para cada projeto.
Um processo padrão, dentro do contexto de engenharia de software, possui
normalmente processos ou disciplinas fundamentais, relacionados a requisitos e pla-
nejamento/acompanhamento de projetos. Além desses, possui também processos or-
ganizacionais de apoio, que envolvem normalmente a área de medições, qualidade,
configuração e portfólios, e os processos de engenharia, que compreendem a parte
de projeto de solução técnica, integração, desenvolvimento e testes. Dependendo dos
projetos a serem implementados na esfera de GD, outros processos/disciplinas poderão
aparecer (recursos humanos, gerência de decisões, gerência de riscos etc.) ou adaptações
do processo padrão poderão ocorrer. Agora vamos analisar a Figura 4.8. O conceito de
metaprocesso, embora à primeira vista seja confuso, é, no fundo, uma sequência óbvia
de atividades necessárias para realizar qualquer ação, desde um projeto de software a
uma aquisição de serviços. No fundo, o metaprocesso detalha um conjunto de ações
reguladas pelo bom senso que passam pelo planejamento (Plan) do que será executado,
seguido da execução (Do) do que foi planejado, seguida das atividades de monitoração/
acompanhamento (Check), concluindo com as observações de aprendizado (Act), para
melhorar e corrigir os erros em ciclos subsequentes. As fases padrão do PDCA são:

Figura 4.8
PDCA aplicado em governança de dados.

50
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

 Plan: planejar. Fase em que devemos planejar o que desejamos realizar.


Nesta fase, detalharemos que melhorias ou desenvolvimentos desejamos
incorporar no conceito de governança de dados, que podem ser a escrita
de um processo de segurança, de qualidade de dados, de BI ou de MDM.
Definido esse objetivo, com os detalhamentos do que desejamos, fazemos
o plano de projeto para a implantação desse processo. O plano de projeto
terá uma formação clássica, contendo objetivos, cronograma com atividades,
equipe/papel, plano de comunicação, recursos, formas de acompanhamento,
documentação, controle de documentos, aspectos de verificação da quali-
dade etc. Nesta e em outras fases, atividades organizacionais de gerência de
configuração, medições e garantia da qualidade serão desenvolvidas como
forma de apoio. As atividades de configuração seguirão uma disciplina que
busca a definição de atributos, padrões e elementos de controle dos artefa-
tos, documentos e códigos produzidos. As atividades de medições definirão,
coletarão, analisarão e divulgarão as métricas e seus resultados, buscando
parâmetros que mostrem o andamento do projeto e a aplicação do processo,
servindo como uma bússola para ajustes e adequações de rotas. É o início
da busca por uma visão quantitativa do projeto. As atividades de GQA, ou
garantia da qualidade, aplicam conceitos que visam à avaliação das ativida-
des do processo e os produtos delas derivados, tornando-se um elemen-
to de auditoria crítica, capaz de apontar não conformidades que também
servirão para ajustes de comportamentos e ferramentas. Ações de gerência
de riscos (GRI) amplificam os pontos já observados no planejamento do
projeto, quando os riscos foram levantados, agora com um pouco mais de
cuidado para as atividades de mitigação e contingência. A parte de recur-
sos humanos também levantada no plano do projeto pode ser amplificada
por ações de GRH, como recrutamento, seleção, treinamento de recursos
necessários para os projetos de GD, além dos primeiros passos para a gestão
de conhecimentos desenvolvidos a respeito de GD. Em resumo, podemos
considerar que qualquer processo, seja de desenvolvimento de software, seja
de qualidade e controle de dados, pode ser pensado na forma de processos
fundamentais e de apoio organizacional.
 Do: executar. Fase em que as atividades planejadas anteriormente serão
efetivamente realizadas, com ações de desenvolvimento e de acompanha-
mento. As atividades de controle organizacional também serão aplicadas
nessa etapa, seguindo os mesmos preceitos definidos anteriormente.
 Check: verificar. Fase em que o foco é analisar como se deu (ou se dá) o
andamento dos trabalhos. Essa verificação pode ser feita por reuniões de
acompanhamento, medições efetuadas e suas respectivas análises, avaliações
de gerência superior etc.
 Act: avaliar corretivamente. Fase em que se analisam resultados, lições
aprendidas, registra-se a geração de conhecimento e se realizam ajustes ou
adequações para serem aplicadas nas iterações e nos ciclos subsequentes,

51
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

servindo como elemento de redirecionamento ou de corroboração de ações


previamente definidas.
Dessa forma, seguindo o metamodelo, escrevem-se os processos necessários para
as ações de GD que depois serão aplicados nos diversos projetos dentre desse escopo.
Os projetos de GD deverão ser priorizados, com base em critérios definidos pela alta
gerência em função de aspectos relacionados a deficiências percebidas na qualidade
de dados da empresa, necessidades de integração de informações mestres, aspectos de
segurança ou de necessidade de produção de informações gerenciais. Essas necessidades
balizarão também os processos que deverão ser prioritariamente definidos e escritos, e
que serão usados nos projetos.
Um processo, ao ser definido, deverá ter uma série de resultados esperados, pró-
prios da sua natureza. Por exemplo, um processo de MDM deverá ter um conjunto de
requisitos definidos, um levantamento inicial dos arquivos mestres usados na empresa,
a verificação do nível de composição e utilização desses arquivos etc. Além desses re-
sultados, qualquer processo definido deverá apresentar um conjunto de atributos mais
genéricos, que sintetizam a sua essência e são descritos a seguir:
 Políticas: conjunto de diretrizes e normas, aprovadas e revisadas em âmbi-
to corporativo, que representam o que a empresa espera daquele processo.
Por exemplo, um processo de segurança na empresa definirá uma série de
políticas relacionadas a uso e controle de recursos, autorizações e permis-
sões, cuidados com senha etc. Um processo de qualidade de dados definirá
aspectos de criação, custódias de dados, atualizações, retenção e eliminação
de dados, dentre outros aspectos.
 Planejamento da execução do processo: um processo terá um conjunto de
atividades a serem cumpridas para que se alcance o seu propósito. Essas ati-
vidades devem ser planejadas a fim de que se tenha uma visão cronológica
de seu desenvolvimento, além das necessidades de recursos demandadas para
cada uma. O cronograma das atividades ilustra bem esse conceito.
 Monitoração: o processo deverá ser monitorado para garantir que os seus
resultados serão alcançados. A monitoração pode ser feita por reuniões de
acompanhamento das atividades do processo e de medições definidas sobre
o seu desempenho.
 Recursos: todo processo demanda um conjunto de recursos humanos e de
outras naturezas, como financeiros, materiais etc., que deverão ser planejados
na sua execução.
 Responsabilidades: todo processo, formado por um conjunto de atividades,
tem um conjunto de pessoas/papéis que possuem responsabilidades por suas
execuções e garantirão o seu desempenho.
 Recursos humanos: todo processo precisa qualificar as pessoas que estarão
com responsabilidade de executar as suas atividades. Isso envolve treinamen-
to, mentoring, coaching, autoestudo etc.

52
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

 Comunicação: todo processo demanda que os papéis envolvidos na sua exe-


cução se comuniquem através de variadas formas, como reuniões, e-mails
etc., a fim de manter e garantir a sua execução.
 Revisão: todo processo demanda também que as suas atividades sejam re-
visadas com a alta gerência, no sentido de prover visibilidade, a fim de que
possam ser feitos ajustes em suas atividades, seus produtos e procedimentos,
corrigindo a sua rota.
 Avaliação: todo processo deverá ser auditado nas suas atividades e nos pro-
dutos delas derivados. Essa auditoria de qualidade efetuada sobre os proces-
sos garante que eles sejam executados conforme definidos e que os produtos
esperados sejam efetivamente produzidos.
 Controle: todo processo deverá ter os seus artefatos devidamente contro-
lados nas diversas formas, como versionamento ou linhas de base, o que
garantirá a integridade física e funcional dos seus produtos de trabalho.

À As elaborações feitas sobre processos para governança de dados estão cen-


tradas no modelo MPS.BR (Melhoria de Processo do Software Brasileiro), da
Sociedade Softex, cujos guias podem ser obtidos no endereço http://www.
softex.br/mpsbr/_guias/default.asp.

QUALIDADE DE DADOS
Um dos principais focos da governança de dados está centrado na área de quali-
dade de dados, visto ser esse atributo fundamental nos aspectos de reputação, valoração
da marca e resposta efetiva a certas ações regulatórias de algumas empresas. Aspectos de
baixa qualidade de dados, cada vez mais, aumentam os riscos de maiores custos internos,
além de evidenciar sinais de baixo controle dos insumos fundamentais de uma empresa.
Uma pesquisa da PWC (Price WaterhouseCoopers), PricewaterhouseCoopers
LLP, Global Data Managementn Survey 2001 – The new economy is the data economy,
realizada numa amostra de empresas Top 500, com ações focadas em e-business, revelou
uma série de preocupações com os aspectos de qualidade de dados. Cerca de 75% dos
CIOs, diretores de TI ou equivalentes em empresas nos Estados Unidos, Austrália e
Reino Unido mostraram fortes preocupações com a qualidade de seus dados. Dessa
forma, um dos primeiros projetos de GD que podem ser implementados é uma afe-
rição da qualidade atual dos dados sensíveis da empresa. Esse projeto permitiria uma
clara visão do nível qualitativo das informações de que dispõe a empresa e poderia
ser usado como elemento alavancador para o apoio às iniciativas de GD. Esse projeto
realizaria uma avaliação dos atributos dos dados existentes nos arquivos/bancos de
dados considerados mais importantes e usados em sistemas/unidades organizacionais
prioritários. O conceito de qualidade de dados pode ser definido em vários domínios.
A classificação apresentada a seguir está dentro dos preceitos definidos pelo professor
Richard Wang, do TDQM-MIT (Total Data Quality Management, do Massachussets
Technology Institute). Nessa visão, os dados são analisados segundo a qualidade in-
trínseca, contextual, de acessibilidade e de representação.

53
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Dentro do conceito de qualidade intrínseca, os atributos contemplados são: pre-


cisão, objetividade, credibilidade e reputação do dado.
 Precisão. Define o quanto aquele dado representa efetivamente algo no
mundo real, normalmente comparado com certo valor de referência que
o corrobora. No momento em que escrevo estas linhas, sinto na pele um
problema direto de falta de qualidade de dados. Fui a Nova York, viajando
por uma companhia aérea brasileira. Check-in ok, cartão de fidelidade ok
etc. Na volta, vou confirmar os créditos de milhagem. A companhia somen-
te creditou a minha ida. A volta, diz o e-mail da área de relacionamentos
com clientes, não será considerada. A mensagem enviada é clara e diz, mais
ou menos, o seguinte: milhagem não considerada, pois outra pessoa voou
no lugar do cliente. Ou seja: algum detalhe de nome anotado erradamente
pela operadora, talvez um Barbiere com “e”, em vez de Barbieri com “i”,
pode ter contribuído para que eu tivesse de enviar uma carta ao setor recla-
mando os meus créditos de milhagem. A resposta chegou, evidenciando a
detecção do erro e a reconsideração das milhas viajadas. Na mesma viagem,
minha esposa, que, como eu, tem dupla cidadania, também teve milhagens
não creditadas. Como ela apresentou o passaporte italiano, que por aspectos
legais daquele país registra o nome de solteira, os problemas apareceram.
A compra da passagem foi feita com a identidade brasileira, que registra o
nome de casada. Logo, a mesma pessoa pode, em certas circunstâncias, ter
dois nomes. Os algoritmos de qualidade e verificação de dados já têm idade
suficiente para descobrirem se dois nomes são da mesma pessoa, verifican-
do dados complementares, como endereço, CPF etc. A precisão dos dados
pode interferir de forma séria, e às vezes trágica, na vida dos cidadãos. Um
dos grandes problemas no segmento de transplantes de órgãos no Brasil é
ter a garantia da precisão do endereço do doador. Por vezes, os doadores
são cadastrados e registram endereços que, quando acessados, se mostram
desatualizados, impedindo que o transplante se realize e uma vida seja salva.
 Objetividade. Define o quanto os dados foram produzidos e manifestam
fatos de forma isenta de tendências, preconceitos ou parcialidade. Por vezes,
dados de natureza econômica são ajustados, dados de estatísticas sociais são
inflados, e dados de violência urbana são subdimensionados para atenderem
a outros interesses que não a realidade dos fatos. Assim, esses aspectos de
objetividade também são elementos de qualidade dos dados.
 Credibilidade. Define o quanto aqueles dados representam algo que possa
ser usado como elemento informacional verossímil e sem risco. Por exem-
plo, os dados do INSS (Instituto Nacional de Seguridade Social) apresentam
um coeficiente de baixa credibilidade, permitindo o convívio de 1,6 milhão
de fichas de pensão sem o CPF do beneficiário e de três milhões de fichas
sem o nome do favorecido, nem da mãe, segundo dados da Folha de S. Paulo
de 18/6/2004;

54
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

 Reputação. Indica o quanto aqueles dados, quando vistos externamente,


podem melhorar ou prejudicar a reputação da área, da empresa, do projeto
a que servem ou que os utilizam. Por exemplo, em maio de 2009, foram
descobertos dados sobre o Projeto Bolsa-Família que evidenciaram a fragi-
lidade de seus controles. Foram identificados benefícios pagos a 577 políti-
cos, a 3.791 pessoas comprovadamente mortas, a 106.329 donos de carros,
caminhões e tratores com marcas sofisticadas como Pajero, Hilux, Civic,
concessões a 1,1 milhão de famílias fora dos limites definidos, segundo O
Globo de 7/5/2009.
 Qualidade de acessibilidade. Corresponde aos aspectos de acesso e de
segurança dos dados, com foco em vazamento, privacidade, respeito à indi-
vidualidade etc. Foca, fundamentalmente, como os dados estão garantidos,
através de acessos, protocolos e serviços de criptografia, por exemplo. Em
janeiro de 2010, os dados de clientes do Google na China foram “quebra-
dos”, causando uma desconfortável celeuma entre a grande empresa ameri-
cana e o governo chinês. As contas invadidas eram de ativistas contrários ao
regime do país. Os hackers foram direto neles, e o Google ameaçou deixar
a operação naquele país. Enquanto escrevia estas linhas, em 3/8/2010, a
mídia divulgava o vazamento de informações de quase 12 milhões de alu-
nos que fizeram o Enem (Exame Nacional do Ensino Médio) nos últimos
três anos. Em dezembro de 2010, o mundo foi sacudido pelo vazamento
de telegramas (cables) diplomáticos mostrando um conjunto de informa-
ções embaraçosas, explicitamente liberadas por uma organização sem fins
lucrativos, cujo objetivo claro é trazer informações ao público, não obstante
a sua criticidade e os efeitos que possam produzir. A organização Wikileaks
persegue uma espécie de dogma que estabelece que as informações exis-
tem para serem conhecidas, não importando a sua carga explosiva ou o seu
conteúdo eventualmente comprometedor. Isso aponta, de forma implacável,
para a rigidez com que devem ser tratadas certas informações no âmbito
organizacional ou institucional e para a importância da governança de dados
nos próximos anos.
Quanto à qualidade contextual, temos os atributos:
 Relevância, ou seja, a característica de importância dos dados, por exem-
plo, no grupo dos MDM, dados mestres de clientes, fornecedores etc., que
representam os acervos básicos da empresa. A discussão sobre MDM será
feita a seguir.
 Valor agregado, ou seja, o quanto aquele dado com a importância definida
pode agregar valor para os negócios da empresa. Aqui entra um conceito
importante sobre a disponibilização dos dados na forma de venda ou de
uso para clientes preferenciais. Por exemplo, as concessionárias de serviços
(eletricidade, telefonia) podem disponibilizar os dados de seus assinantes na
forma de estatísticas de consumo, como elemento de reciprocidade. Você
pode acessar, via web, os últimos consumos de energia ou as últimas li-
gações efetuadas, numa espécie de arquivo individual, caracterizando um

55
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

valor agregado a eles. Além disso, existem os aspectos de venda de dados. Os


dados, que por natureza podem ser convertidos em informações vendáveis,
desde que mantidos os aspectos de preservação de privacidade, podem se
transformar em excelente fonte de negócios. Assim fazem algumas editoras
que vendem dados de assinantes, ou conjunto de perfis, por região, profissão
etc. Esse ponto, ainda relativamente tímido no Brasil, é muito comum em
outras sociedades, como a norte-americana, na qual inclusive os aspectos de
privacidade são muito mais sensíveis. Um exemplo desse tipo de negócios
é a empresa Choicepoint, considerada uma data aggregation company. Basea-
da em Alpharetta, perto de Atlanta, no estado da Georgia, o seu negócio
é centrado em serviços de inteligência privada atendendo ao governo e à
indústria. A Choicepoint foi comprada pelo grupo Reed Elsevier em fe-
vereiro de 2008, por US$3,6 bilhões. A empresa combina dados pessoais
de variadas fontes públicas e privadas que são vendidos aos interessados no
setor do governo e da indústria. A empresa mantém 17 bilhões de registros
sobre indivíduos e negócios que são vendidos a aproximadamente 100 mil
clientes, incluindo agências federais, estaduais e municipais de segurança. A
empresa tem uma esquadrilha de coletores de dados de diferentes fontes,
como endereço, telefones, óbitos, registros policiais, cartórios de registros ci-
vis etc., e faz uma consolidação, que redunda, hoje, em registros de cerca de
250 milhões de pessoas, parte significativa da população norte-americana. A
empresa vende essas informações ou ajuda as autoridades na busca de serial
killers ou na identificação de vítimas de grandes desastres.1
 Disponibilidade: refere-se aos dados estarem prontos no momento em
que são demandados e produzidos na periodicidade necessária. Aqui o BI
novamente entra com um conceito importante relativo à latência zero, ou
seja, a distância em tempo entre um fato gerador de importância e a infor-
mação disponibilizada sobre ele, de forma limpa e acessível, servida aos to-
madores de decisão da empresa. Os conceitos de RTE (Real Time Enterprise),
acoplados à rosácea de BI, também sugerem essa característica de imediata
liquidez da informação.
 Completude: refere-se, obviamente, aos dados estarem completos e sem
lacunas, não apresentando vazios na sua composição. Alguns atributos são
mandatórios, requerendo um valor em todas as suas ocorrências, como, por
exemplo, o campo data de nascimento. Outros são opcionais, permitindo a
sua ausência, quando pertinente. Por exemplo, o campo nome do cônjuge,
que nem todos têm. Outros podem não ser aplicados, como nome de soltei-
ra, válido somente para mulheres. Assim, a completude representa o quanto
o dado está disponível para aquele fim a que se propõe em amplitude e
profundidade. Por exemplo, se defino que todos os campos do endereço
postal ou endereço web devem estar preenchidos mas parte deles não está,
os dados estarão comprometidos nesse item de qualidade, pois isso pode di-
1 Fonte: Wikipédia. Disponível em: http://en.wikipedia.org/wiki/ChoicePoint. Acesso em: 8 ago. 2010.

56
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

ficultar uma tomada de decisão ou comprometer a correta entrega de uma


correspondência fundamental, por exemplo. Essa característica é muito im-
portante em empresas com negócios que passam por entregas postais, como
concessionárias de luz e água, que remetem periodicamente contas aos seus
clientes ou daquelas que se baseiam em web mailing.
 Quantidade devida e necessária: corresponde ao atributo dos dados
estarem armazenados na quantidade devida e necessária para se poder rea-
lizar a análise desejada. Por exemplo, tenho de ter as 12 últimas notas fiscais
registradas para que se possa realizar uma análise anual média das vendas. Os
dados estarão completos se tivermos somente dez ocorrências?
Quanto à qualidade de representação, observamos os atributos:
 Interpretabilidade, ou seja, a qualidade de um dado poder ser interpretado
corretamente dentro de um contexto que permita a aplicação de uma aná-
lise racional que conduza a conclusões corretas. Isso está diretamente rela-
cionado com a linguagem, os símbolos e as unidades em que os dados foram
produzidos/escritos. Por exemplo, os metadados de um grande pacote de
aplicativos por muito tempo ainda descreviam as suas tabelas relacionais na
língua alemã, dificultando a interpretação pela equipe técnica.
 Facilidade de entendimento, que representa o fato de os dados estarem
em uma forma amistosa, que permita o seu entendimento com facilidade,
sem a necessidade de especialistas. Por exemplo, os dados poderão estar num
control chart (gráfico de controle), que mostra a média dos valores objetos
da análise e as linhas de dispersão. Também poderão estar representados na
forma de histograma ou qualquer forma gráfica que facilite a sua interpre-
tação. Os dashboards e faróis, desenvolvidos na esfera dos aplicativos de BI,
mostram a importância desse item na agilidade de interpretação e tomada
rápida de decisão. Aqui entra uma nova e forte vertente complementar à
qualidade de dados, no domínio de facilidade de seu entendimento: a visua-
lização de dados. Essa disciplina, que mistura computação, arte e informação,
mostra-se com fortes tendências de desenvolvimento dentro do complexo
universo dos dados. Softwares dedicados à visualização de dados, como o
Tableau Software, e sites que permitem o upload de seus dados e a definição
de formas criativas de visualização estão cada vez mais presentes. Experi-
mente http://www.swivel.com ou http://manyeyes.alphaworks.ibm.com/
manyeyes (uma empresa da IBM). Além da visualização de gráficos estáticos,
também a possibilidade de se produzir gráficos com dados em movimento
pode ser vista como uma nova tendência na visualização de dados, como em
http://www.gapminder.org/data/. A máxima de que “uma figura vale mais
que mil palavras” certamente ganhará um upgrade de valor nos próximos
anos, quando as técnicas de visualização se consolidarem plenamente.
 Forma consistente: a qualidade da forma sintática, que estabelece
como a representação daquela informação, expressa como um elemento
de dado, está definida segundo as regras corporativas. Por exemplo, é

57
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

definido que um endereço deve ser formado de nome do logradouro,


número, complemento, CEP, bairro etc. Todos os dados que represen-
tam aquele mesmo fato (endereço) estão dentro dessa sintaxe, no mes-
mo formato? Também a qualidade dentro da forma semântica, definida
por regras naturais ou de negócios, que impõem, por exemplo, que um
campo de salário não pode ter valor menor do que o valor do salário
mínimo vigente. Também o conceito de consistência se refere ao fato de
certos dados estarem com valores consistentes, quando comparados com
valores em outros conjuntos.
A consistência não implica correção. Por exemplo, se um dado de uma ordem
de compra armazena o seu valor total, esse dado estará consistente quando comparado
com o somatório dos valores dos itens daquela ordem de compra. Nesse caso, existe
consistência, mas isso não necessariamente garante a correção, ou seja, que aquele valor,
na sua essência, esteja correto.
 Representação concisa significa o grau em que o dado é apresentado de
forma sucinta, enxuta, sintética, sem perder os seus atributos informacionais.
A qualidade nesse domínio é evitar os dados prolixos, extensos e cansativos,
como visto em alguns campos de textos ou descritivos.
 Facilidade de manipulação, ou seja, os dados estão apresentados em
uma forma que permita trabalhar sobre eles. Por exemplo, através de pi-
vot table no Excel ou de cubos no Analysis Services, podemos analisar os
dados e eventualmente manipulá-los a fim de realizar simulações. Essas
ferramentas normalmente exigem algum grau de especialidade, não sendo
diretamente pilotadas por executivos, que preferem a visualização didática
dos faróis e dashboards. Hoje, com o crescimento dos dados não estru-
turados, essa facilidade de manipulação muda de eixo, saindo dos dados
encontrados em formatos tradicionais para outras representações, como
imagem, arquivos em XML, áudio etc., em que a facilidade de manipula-
ção não é mais tão trivial em funções de pesquisas, por exemplo, como são
nos dados estruturados.
Outras caracterizações de qualidade de dados existentes na literatura, advindas
da camada de tecnologia, podem de certa forma ter sobreposições com as definições
mostradas anteriormente:
 Unicidade: refere-se à capacidade de se referenciar unicamente a determi-
nada entidade, considerando certo contexto. Isso significa que aquela en-
tidade não possui duplicidade e, normalmente, oferece um atributo-chave
que permite identificá-la. Esses conceitos são muito bem mapeados em
modelos de classes e relações, com exemplos tradicionais, como clientes,
produtos, locais, cada qual com uma unívoca forma de identificação. A qua-
lidade desses dados nesse contexto é garantida pelos próprios mecanismos
de implementação e pelos refinamentos pré-carga realizados nos dados. Os
campos que conferem unicidade às entidades de dados podem ser campos
do próprio domínio do sistema ou um campo, digamos, artificial, produzi-

58
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

dos por algoritmos/rotinas de geradores de números sequenciais, normal-


mente baseados em um valor inicial e mais um incremento. Essas chaves, em
modelos relacionais, são denominadas chaves surrogates e são sempre fortes
concorrentes aos postos de chaves primárias em tabelas e relações de dados.
Esse conceito se associa ao fato de que certas entidades de arquivos ou ban-
cos de dados deverão ser únicas e não oferecer o perigo do uso duplicado
e indevido, como citado no exemplo, em que unidades de saúde usando o
campo nome para identificar um cidadão poderão implicar riscos sérios nos
casos de homônimos, com doenças de tratamentos opostos (hiperglicemia
e hipoglicemia).
 Integridade de referência: conceito também muito aplicado no mundo
dos bancos de dados, caracterizado pela coerência de valores entre dois da-
dos que foram definidos em entidades diferentes, com o propósito de definir
uma forma implícita de relacionamento entre elas.
 Atualidade: refere-se ao fato de mantermos regras para o estabelecimento
de dados com validade por certo tempo, visando à manutenção da sua atua-
lidade. Está na razão direta da frequência com que aquele dado deverá ser
atualizado.

FERRAMENTAS DE QUALIDADE DE DADOS


O Gartner Inc., empresa mundialmente conhecida, especializada em pesquisa
de tecnologia da informação, realiza periodicamente levantamentos sobre o posiciona-
mento de fornecedores nos diversos domínios da TI. O famoso quadrante mágico de
Gartner é um gráfico que dispõe as empresas em um espaço bidimensional, posicionan-
do-as de acordo com a sua visão e sua habilidade para executar aquela tecnologia. Para
as ferramentas de qualidade de dados, a Gartner define algumas características que os
fornecedores devem prover nas suas soluções e ferramentas:
 Profiling e visualização: devem oferecer funcionalidades para análises de
atributos (por exemplo, mínimo, máximo, distribuição de frequência) e aná-
lise de dependências (entre tabelas e entre arquivos). As ferramentas devem
apresentar os seus resultados em forma tabular ou de interface gráfica. Os
resultados deverão ser armazenados, com possibilidades de análises de ten-
dências, pela comparação de várias séries armazenadas.
 Parsing: devem permitir a identificação e a extração de componentes tex-
tuais, como nomes, endereços, e-mail e outras informações relacionadas. Os
algoritmos e as regras de parsing devem ser aplicados a um amplo espectro
de tipos de dados e de domínios, e devem permitir configurações para ex-
tensões por parte do cliente.
 Matching: devem permitir “batimento” de dados dentro e entre fontes
definidas, via regras que possibilitem a construção de cenários configu-
ráveis. Devem também permitir a auditoria e a calibragem (tuning) dos
cenários ao longo do tempo. A funcionalidade de matching não deve ser

59
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

limitada a tipos específicos de dados e domínios, nem restrito com re-


lação ao número de atributos que podem ser considerados nos cenários
de matching.
 Cleansing (padronização e limpeza): devem prover regras nativas e possi-
bilidades de extensões para o tratamento de sintaxe (formato) e semântica
(conteúdo de valores), a fim de garantir a conformidade com regras de
negócios. Devem permitir alterações de dados a fim de ajustes a regras de
negócios e padrões definidos.
 Monitoração: deve oferecer mecanismos que permitam garantir que os
dados continuarão conformes com as regras definidas.
As funcionalidades devem ser oferecidas em mais de uma língua e para vários
países.2

Como implantar um programa de qualidade de dados


Uma das grandes dificuldades na implantação de programas de qualidade, seja
de processos ou de dados, é o convencimento da alta gerência sobre os ganhos reais
de um programa como esse. A busca de um ROI nem sempre é facilmente obtida em
projetos dessa natureza. Uma das alternativas mais adequadas é o convencimento pela
prova concreta, através de cases implementados na própria empresa ou em congêneres.
Uma abordagem tática de convencimento seria montar um plano com os seguintes
passos:
 Faça um case com medidas reais, mostrando a qualidade dos seus dados,
ou melhor, a possível falta dela. Centre a sua análise com foco na perda da
reputação, do dinheiro e de oportunidades em função dos dados “ruins”,
criando alertas:
 Escolha um domínio de dados que seja significativo para o business da
empresa, por exemplo, clientes, produtos etc. Centre-se nos aspectos de
custo, lucro, qualidade, reputação, logística etc.
 Escolha KPI: indicadores-chave de processos com certos impactos.
Por exemplo, se tenho 9% dos meus clientes sem o nome do meio,
isso pode significar um problema de baixa relevância. Entretanto, se
tenho 7% dos meus clientes sem CEP, isso pode ser de alta relevância
e, caso tenha um milhão de clientes (potenciais), teria 70.000 po-
tenciais problemas no recebimento de documentos. Entretanto, se a
métrica definida é sobre o BD de billing (cliente/cobrança), as coisas
ficam mais críticas ainda, destacando que a falta de qualidade pode
implicar perdas diretas de faturamento por problemas de cobrança.
Isso significa alerta.

2 FRIEDMAN, Ted; BITTERER, Andreas. Magic Quadrant for Data Quality Tools, Gartner. Disponível em:
http://www.gartner.com/technology/media-products/reprints/trillium/200603.html. Acesso em: 9 ago.
2010.

60
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

 Avalie e demonstre possíveis impactos: se, nos últimos seis meses, 8% dos
clientes on-line tiveram de esperar mais tempo para o recebimento de
seus produtos comprados, devido à falta de consistência entre as chaves
do produto no BD de estoque e a chave do produto no BD de pedidos,
isso significa alerta.
 Suponha que tenho definida uma estratégia de racionalizar a minha linha
de produtos e analiso os relatórios de BI visando a obter os de menor
venda. Entretanto, se os relatórios de BI não batem diretamente com os
dados do sistema de vendas, terei um problema de credibilidade levando
a uma decisão postergada. Isso significa alerta.
 Procure enquadrar o seu case de convencimento escolhendo as devidas
dimensões de qualidade do dado: estrutura, conformidade, precisão, com-
pletude, disponibilidade, unicidade, consistência, relevância etc.
 Defina ferramentas e processos para os levantamentos de qualidade dos
dados, na dimensão escolhida. A escolha de uma consultoria especializa-
da associada à ferramenta correta diminui o tempo de resposta.
 Obtenha medições/indicadores sobre os campos definidos, associando os
possíveis impactos advindos do índice de qualidade encontrado.
 Prove a importância das medições efetuadas considerando as dimensões
escolhidas.
A metodologia Total Data Quality Management (TDQM) do MIT sugere duas
abordagens para o levantamento da qualidade dos dados de uma empresa. Uma delas
se baseia em pesquisa sobre a qualidade dos dados. Essa pesquisa deverá ser aplicada nas
áreas usuárias mais sensíveis aos dados em análise, através de questionários, com foco no
tripé CCC (collectors, custodians e consumers). O livro Journey to Data Quality, de Leo Pipi-
no,Yang Lee, James Funk e Richard Wang, do MIT Press (2006), apresenta um roadmap
que pode ser usado por equipes de DGPG para o planejamento detalhado e para uma
implementação viável de um programa de qualidade de dados, dentro do guarda-chuva
da governança de dados. O livro apresenta princípios, estratégias, técnicas e ferramentas,
dentre elas modelos de questionários para o levantamento sobre qualidade de dados na
empresa (p. 41-51 e 191-200). A segunda abordagem centra-se em aplicações de ferra-
mentas para levantamento dos perfis de dados (data profiling), através de varreduras de
arquivos e bancos de dados importantes da empresa. Enquanto a primeira abordagem
foca o domínio qualitativo, a segunda centra-se em aspectos quantitativos. A Figura 4.9
mostra uma visão geral da abordagem de qualidade de dados, destacando essas duas
visões. A Figura 4.10 mostra uma visão da aplicação de entrevistas para levantamentos
sobre aspectos qualitativos dos dados, com um conjunto de tópicos aplicados na for-
mulação das questões a serem pesquisadas. A Figura 4.11 mostra uma visão sintética
sobre as ações de levantamento quantitativo, via ferramentas, com um conjunto de fun-
ções encontradas em ferramentas de limpeza, transformação e remoção de duplicados
(deduplicação) de dados.

61
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 4.9
Pesquisa sobre qualidade de dados. Adaptada de PIPINO, Leo L.;
LEE, Yang W.; WANG, Richard Y.; FUNK, James D. Journey to Data Quality.
Cambridge: The MIT Press, 2006, p. 30.

Figura 4.10
Pesquisa sobre qualidade de dados – informações levantadas.

62
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

Figura 4.11
Medições sobre qualidade de dados.

A Figura 4.12 mostra uma forma estruturada de um processo aplicado para tratar
a qualidade de dados de uma empresa. As principais etapas são:

Figura 4.12
Fases de um processo de qualidade de dados.

63
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Visão inicial dos dados: nessa etapa deve-se atentar para o conhecimento
inicial dos dados da empresa. A abordagem anteriormente discutida, rea-
lizada por questionários, pode ser o primeiro passo dessa fase, mas oferece
uma percepção qualitativa. Depois, a aplicação de ferramentas que reali-
zam análises preliminares sobre cadastros pode evidenciar a ausência de
padrões de preenchimento, além da violação de certas regras de negócios
e de domínios de atributos. Essa visão inicial permite definir a estratégia
para a empresa em questão, entendendo as suas regras de negócios espe-
cíficas. Nessa fase são detectados também vícios de preenchimento, ob-
servando-se a ocorrência de repetição de valores, normalmente fruto de
introdução de dados sem critérios. Por exemplo, é comum, na análise de
cadastros de empresas de seguros, observar a repetição do mesmo número
de telefone para várias apólices. Isso pode ser explicado pela participação
dos corretores, que, desejando se manter como a interface entre o cliente
e a seguradora, colocam o seu número de telefone no lugar do número
do cliente. Em um outro cadastro, em outra área de negócios, certa vez
foi detectada a repetição de um CNPJ que, depois de analisado, mostrou
ser de uma grande fabricante de cigarros. A funcionária responsável pela
entrada de dados, quando não tinha a informação fornecida pelo cliente,
colocava o número obtido facilmente do maço à sua frente. Esse diagnós-
tico também detecta nomes mal preenchidos ou colocações de palavras
suspeitas ou obscenas. Um exemplo foi uma grande empresa da área de
utilities na qual a atendente acrescentou “PQP” por extenso no endereço
da cliente, após uma discussão entre ambas, causando problemas jurídi-
cos para a companhia. Por fim, um cadastro de registro de milhagens de
clientes, quando analisado, encontrou extensa repetição de um número
de telefone que, depois, foi verificado como sendo de um comprador de
milhagens. Como a entrada de dados é uma parte crucial do processo,
mas nem sempre se conseguem mecanismos efetivos de controle sobre
ele, esses exemplos são eloquentes na ilustração da fragilidade potencial
encontrada nessa forma de input.
 Análise de colunas e domínios: essa etapa, que pode ter sobreposição com
a anterior, foca objetivamente a análise de cada coluna/campo, batendo
com os seus diversos domínios. Os domínios são os variados padrões que
aquele dado pode assumir quando se instanciam em determinada coluna
de uma tabela. Por exemplo, existem vários padrões de datas (padrão
americano, brasileiro etc.). Dependendo do negócio, por exemplo, em
bancos de dados de registros de arte, históricos ou geológicos, a data
pode vir com marcações do tipo AC/DC, incomum, porém factível. Os
conteúdos das colunas de um arquivo serão, dessa forma, validados contra
o domínio aplicado àquela instância. Aqui cabem avaliações de valores
fixos, range de valores, conjuntos discretos de valores, e, dependendo do
campo, pode ter até o metadado incluído no conteúdo do campo (grau

64
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

= superior), em que “grau” é o metadado e “superior” é o valor. Algu-


mas colunas, como nome, endereço postal, telefone e e-mail, são foco
de tratamentos especiais, principalmente no segmento de marketing, no
qual o acesso ao cliente é vital. O nome é analisado na sua estrutura, com
decomposição de primeiro nome, conectores (da, de), nome do meio,
pós-nome etc. Existem vários padrões (domínios) para escrita de nome,
dependendo da cultura, da empresa etc. Algumas escrevem o nome antes
do sobrenome, outras o fazem de forma invertida. Os nomes de pessoas
jurídicas também são analisados, procurando-se variações, como nome
fantasia da empresa, além de resolver a repetição do CNPJ para empre-
sas do mesmo grupo etc. Assim, cada projeto tem de ser bem avaliado
antes da definição de seus parâmetros de varredura, o que permitirá que
as ferramentas de análise sejam customizadas adequadamente. Isso varia
também com o tipo de negócios de cada empresa, a qualidade e a idade
de seus cadastros, além do grau de controle nos mecanismos de entrada
de dados. O tratamento de endereços, por sua vez, é dos mais desafiadores,
pois pode haver mudanças e há a necessidade de manutenções constantes.
Para isso, as empresas especializadas se valem de cadastros de organismos
oficiais, como o Cadastro Nacional dos Correios (endereços), de empre-
sas de telecomunicações (para códigos de discagem) ou mesmo de edito-
ras, que têm no endereço uma informação imprescindível para a entrega
de seus produtos ou de suas cobranças. Os endereços são mantidos atua-
lizados com base nessas referências. Por vezes, no campo de endereço, são
usados nomes de cidades na sua forma oficial, diferente das publicamente
conhecidas, como Armação de Búzios (Búzios) ou Campos dos Goya-
tacazes (Campos). Para colunas cujo conteúdo é sabidamente de escrita
complicada, podem ser aplicados algoritmos que criam coeficientes de
similaridade, que permitem uma resolução probabilística. Por exemplo, a
Avenida Juscelino Kubitschek, em São Paulo, é um exemplo de endereço
com altíssimo grau de incidência de erro de transcrição. A aplicação des-
ses algoritmos fonéticos de similaridade ajuda a resolver essas situações.
Já a inversão de São Paulo para São Apulo, também comum e produzido
por digitação apressada, não pode ser resolvido pela mesma técnica, por
produzir coeficientes baixos de similaridade com a palavra correta. Os
endereços, quando bem resolvidos, servem para formatar um conceito
importante em marketing, denominado householding, ou seja, o conjunto
de pessoas, contas, cartões etc. que ocupam o mesmo domicílio. Assim,
se você, a sua esposa e os seus filhos têm cartões de crédito da mesma
bandeira e formam um householding, isso pode ser bom para vocês e para
a marca do cartão. Da mesma forma, os moradores de um prédio ou de
um condomínio também poderão ser observados como um subconjunto
interessante para oferecer promoções ou para facilidade e agilidade nas
instalações, como no caso das empresas de TV a cabo.

65
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Os endereços de internet são resolvidos com os padrões tradicionais e


com a atualização dos domínios novos (.org, .edu, .com etc.), via os ór-
gãos mantenedores da internet. Dentro dessa etapa podem ser aplicados os
padrões para quaisquer campos, com máscaras válidas (T999**99), como
começando com T, seguido de três dígitos, depois de duas letras quaisquer
e mais dois dígitos. A presença de campos nulos (ou não preenchidos)
também deve ser considerada e, em algumas situações, consegue-se a ob-
tenção da informação ausente através de cruzamento com outros dados.
Por exemplo, uma pessoa chamada Iracy Almeida, cujo campo sexo não
está preenchido, poderá ter a determinação dessa informação ausente
através de cruzamentos de outras informações (planos de saúde, registros
de atendimentos médicos etc.), se existirem.
 Análise de estrutura e de inter-relações: essa etapa envolve o cruzamento
entre informações de colunas da mesma linha ou de linhas e colunas
entre tabelas diferentes. Aqui entram abordagens para buscar atributos-
chave que possam ser usados para definir a unicidade dos objetos. Por
exemplo, se duas linhas de uma tabela tiverem CPF repetidos, a resolução
da unicidade poderá se dar pelo cruzamento do nome com o endereço.
O nome, por si só, não seria suficiente para caracterizar a unicidade,
por exemplo. Aqui entram os conceitos de dependência funcional, intro-
duzidos no modelo relacional. Por exemplo, o nome tem dependência
funcional do CPF na medida em que um CPF somente aponta para
um endereço (considerando uma relação normalizada). O uso conjugado
de duas colunas de uma mesma linha serve para conferir certo grau de
qualidade. Por exemplo, o batimento entre o endereço do cliente e o seu
DDD pode sugerir que o telefone esteja correto mas não pode garantir
que não esteja, pois o cliente pode ter dado o telefone do trabalho. Uma
das possibilidades de análise é definir uma distância limite entre os dois
domicílios (do cliente e do relativo ao DDD). Caso haja distância menor
do que, digamos, 100 km, a informação será considerada como aceita.
Acima desse limite, um sinal amarelo será levantado. A análise de sinôni-
mos de colunas na mesma linha ou em tabelas diferentes também pode
ser feita para garantir a compatibilidade de domínios e a qualidade dos
dados. As ferramentas de análise também possuem módulos para a corre-
ção dessas imperfeições. Uma das mais comuns aplicadas é a deduplicação,
ou seja, a eliminação e/ou a integração de linhas duplicadas correspon-
dentes ao mesmo objeto. Esse conceito se alinha com o conceito maior
de MDM, que objetiva a unificação de cadastros mestres.
 Análise de regras de negócios: essa etapa trata da verificação da qualidade
dos dados, sob a perspectiva de regras de negócios. As regras de negócios
são definições amplas que podem permear todos os conceitos dos da-
dos, envolvendo seus domínios e os seus relacionamentos. São claramente
dependentes da empresa, da sua linha de negócios, e influenciadas por

66
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

fatores externos como legislação, mercado etc. As regras de negócios não


são obtidas pela análise dos dados, mas sim aplicadas sobre eles. Normal-
mente estão escondidas em processos de negócios, stored procedures, triggers
etc. Devem habitar um repositório de regras consideradas como um dos
metadados fundamentais da empresa. Existem alguns tipos de regras de
negócios com foco em alguns tipos de dados. Por exemplo, as regras de
negócios aplicadas em campos do tipo data de evento, data de admissão,
data de aposentadoria, data da última promoção são muito claras e pre-
sentes. Por exemplo, uma data de pedido não pode ser maior que a data
de envio. Uma data de entrega não pode ser menor que a data do pedido,
e a data de renovação de um contrato deve ser maior que a data de assi-
natura inicial e acontecer x meses após aquele evento. Existem regras de
negócios aplicadas em outros tipos de campos, principalmente naqueles
que separam objetos dentro de certo domínio. Por exemplo, o campo
sexo pode ter valores M, F; os tipos de contas podem ser x, y, z; os tipos
de estados de certo objeto transitando por um fluxo podem ser ativo,
inativo, suspenso etc. As regras de negócios também podem ser aplicadas
para a criação de novos atributos, baseados em operações sobre valores
existentes.
 Resolução de casos na “zona cinzenta”: existem alguns tipos de verifi-
cação de qualidade de dados que não podem ser 100% resolvidos por
códigos, de forma automática. Muitos produtos oferecem soluções con-
templando etapas nas quais as não conformidades detectadas são analisa-
das pelo engine “humano”, chegando a uma conclusão analítica sobre ela.
 Resolução geoespacial dos dados: com o crescimento das informações
georreferenciadas, popularização de GPS etc., torna-se importante a as-
sociação dessas informações com aquelas relacionadas aos dados de ne-
gócios como clientes, fornecedores, prospects etc. Uma das aplicações mais
importantes, associada com o conceito de Geo-BI, é o mapeamento de
atributos como CEP e endereços com coordenadas (latitude e longitu-
de). Essa associação permite a obtenção de uma visão de distribuição de
pontos de contatos (agências, lojas etc.) e a sua proximidade com os seus
clientes, fornecedores e prospects. Pela associação de outras informações
obtidas do IBGE, como região censitária, pode-se ter uma rica informa-
ção de perfis socioeconômicos localizados perto dos pontos de business.
Isso, obviamente, permitirá que a empresa possa planejar melhor as suas
demandas naquela região específica, em função dos clientes e dos prospects
que ali moram.
 Ferramentas e serviços de qualidade de dados: uma das maiores empresas
em qualidade de dados e líder no mercado no Brasil é a Assesso – En-
genharia de Sistemas (www.assesso.com.br). A empresa oferece um
conjunto de ferramentas (Data Care) voltado para os tratamentos discu-
tidos, na forma de módulos independentes e parametrizáveis, usados hoje

67
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

em grandes empresas da área bancária, de publicações, telecomunicações,


seguradoras etc. A empresa trabalha aplicando os conceitos de qualidade
TDQM (Total Data Quality Management) do MIT (Massachussets Insti-
tute Technology) e tem fortes iniciativas na área, sendo uma das criadoras
da qualidade da informação Brasil-QIBRAS (www.qibras.org), organi-
zação que objetiva fornecer as habilidades fundamentais para o mercado
entender e superar os desafios da qualidade dos dados e das informações.
A QIBRAS também objetiva, além de agregar os princípios da gestão
da informação, proporcionar programas de certificação para as empresas,
marco regulatório e difusão da metodologia TDQM no Brasil.

METADADOS
Nesse contexto de governança de dados e qualidade de dados, um dos pontos
que mais se destaca e se discute é a necessidade da devida formação dos metadados. Esse
assunto, sempre em pautas de discussão, tem tido grande dificuldade de decolagem e en-
frenta barreiras significativas, centradas no binômio tempo e dinheiro. Desde os tempos
da antiga administração de dados, o conceito de metadados vem sendo discutido sem
grande efetividade em sua aplicação e seu desenvolvimento. Alguns SGBD trouxeram
os primeiros DD (dicionários de dados), banco de dados dedicado ao armazenamento
dos metadados. Entretanto, somente aqueles produtos que eram dinâmicos ou ativos
conseguiram alguns resultados. Esses dicionários ativos captavam automaticamente os
dados, suas estruturas e seus contextos, produzindo um primeiro nível de metadados,
sem abastecimento manual do repositório, o que mitigava os fatores de tempo e dinhei-
ro, já citados. Depois, bastava que os AD (administradores de dados) complementassem
a informação com dados no plano conceitual, como modelos, atributos, relacionamen-
tos etc. Agora, cada vez mais, o conceito de metadados se torna importante, pois tangen-
cia as fronteiras da gerência de conhecimento. Os dados, para produzirem devidamente
informações e conhecimentos, deverão ter a sua definição completa e uníssona. E a
definição dos dados é a essência de metadados. Costumo dizer, metaforicamente, que
metadados é como aquela plaquinha que fica ao lado dos pratos em restaurante self-
service. Por vezes, você quase identifica o prato dentro daqueles recipientes de aço, base-
ado na sua aparência, aroma etc., mas sempre pairam dúvidas. Quando a plaquinha está
ali dizendo que é um fettuccine ao pesto, você se inteira completamente do prato, do seu
possível sabor e até da sua composição e ingredientes. Assim são os metadados também.
Eles servem para você saber o que está consumindo em termos de dados, informações
e conhecimento.
Os metadados podem ser classificados como sintáticos, semânticos e estruturais.
Os sintáticos definem as regras de formação dos nomes dos dados, garantindo padro-
nizações como: todo campo dia será DIA_xxxxx, em que xxxx será o complemento.
Os metadados semânticos definem o sentido que se dá àquele elemento informacional,
garantindo o seu pleno entendimento nos contextos organizacionais em que é produ-
zido ou consumido. Esse é mais parecido com a plaquinha. Definirá, por exemplo, que
a data_efetivação_da_apólice será a data em que o corretor efetivamente fez o registro

68
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

oficial no sistema, através da entrada via seguradora. Os metadados estruturais definem


como o dado é composto em partes menores e detalha a sua formação estrutural. A
data_efetivação_da_apólice é formada de dia, mês, ano e estampa de tempo, com hora,
minuto e segundo, por exemplo. É como se a plaquinha listasse todos os ingredientes
do prato.
Os metadados também podem ser vistos nos domínios de negócios e técnicos.
Os metadados técnicos até que já existem por aí. Os SGBDs usam um catálogo no
qual armazenam os metadados técnicos necessários ao seu processo de otimização de
consultas. Ali residem tabelas contendo informações sobre tabelas relacionais, campos,
índices, usuários, triggers, stored procedures etc. Para cada campo, há metadados como
nome, tipo, tamanho, indexação, cardinalidade etc. Esses dados são fundamentais para
o SGBD na definição e escolha dos melhores caminhos de acessos existentes dentro
de um comando SQL. Os metadados podem habitar a mesma estrutura do objeto que
documentam, como as tags <META> das páginas HTML, estar em documentos se-
parados, porém associados, como as DTDs ou Schemas XML, ou em estruturas físicas
totalmente independentes, como os catálogos/dicionários dos SGBDs. Os metadados
terão papel extremamente importante no conceito de web semântica, à medida que,
nesse contexto, os conteúdos serão cada vez mais acessados e processados por algorit-
mos inteligentes. Para tal, será necessária melhor definição semântica de seus objetos.
Isso se chama metadados.
No plano de negócios, a fronteira dos metadados com a gerência de conheci-
mento se dá por modelos ontológicos que definem domínios maiores, nos quais aquele
dado se contextualiza. Com a extensão dos conceitos de BI (BI2, como chamamos) aos
conceitos de governança de dados e de processos, os metadados poderão representar
certas propriedades dos dados associados a processos do ambiente de desenvolvimento
de software. Por exemplo, os aspectos de reutilização de dados poderão se beneficiar so-
bremaneira dos metadados na medida em que se pode caracterizar melhor a semântica
dessas unidades de informações (classes, componentes, módulos, rotinas etc.) passíveis de
serem reutilizadas em um contexto mais amplo.
A utilização de metadados ainda se mostra relativamente incipiente e deverá
gradativamente seguir uma trilha de amadurecimento, semelhante aos níveis de matu-
ridade existentes nos modelos de qualidade de software. Em um nível inicial caótico
ou aleatório, os metadados poderão ser definidos sem um processo formal, um pouco
à revelia de definições, dependendo diretamente das necessidades de cada aplicação. A
seguir virá um patamar no qual os metadados serão descobertos e levantados, ainda sem
um processo mais formal, porém obedecendo a certas regras iniciais. Depois deveremos
alcançar um nível no qual uma gerência de metadados será formalizada por políticas
corporativas mais amplas, culminando com uma fase em que o processo de levanta-
mento, análise e formação dos metadados será otimizado com mecanismos de captura
automática. Esses níveis graduais de maturidade no tratamento de metadados deverão
ser fatores críticos de sucesso para a sua adoção como elemento fundamental no con-
trole dos ativos de informação e de conhecimento. A Tabela 4.2 é um exemplo de uso
de metadados, contemplando alguns atributos.

69
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Tabela 4.2
ELEMENTO DE INFORMAÇÃO - 12345
Domínio Material
Subdomínio Estoque, controle de inventário
Nome de negócio Número da peça
Alias Código da peça
Significado de negócio Número gerado internamente pelo depar-
tamento de material e atribuído ao dado.
Identifica univocamente cada item do es-
toque e não pode ser alterado. Evidencia
se o item é de compra nacional ou inter-
nacional. O item de compra internacional
exige a aderência ao processo de com-
pras internacionais da empresa

Tipo de dado Caractere


Tamanho do dado Tamanho mínimo e máximo de 8 carac-
teres
Regras de formatação O padrão definido exige: o primeiro carac-
tere deve ser uma letra em uppercase (I
ou N), que identifica se o item é de com-
pra internacional ou nacional. Os dígitos
restantes devem ser numéricos, variando
de 0 a 9
Regras de codificação Num_peça
Regras de versionamento Esse elemento poderá ser versionado ao
longo do seu ciclo de vida, desde que haja
modificações nos seus atributos. A regra
de versionamento deverá seguir o proces-
so de configuração da empresa
Processo gerador Cadastramento de novo material
Processos transformadores N/A
Regras de transformação Nos processos de ETC, o número da peça
será substituído por uma chave surrogate
nas tabelas-fato
Requisitos de testes e de validação Verificação da correção sintática do ele-
mento, baseada na regra de formação
definida
Indicadores de qualidade Não deverá haver duas peças com o mes-
mo número de peças
Regras para reutilização Veja processo de engenharia de reutiliza-
ção

MASTER DATA MANAGEMENT (MDM)


O conceito de MDM é uma das grandes novidades deste final da primeira
década do novo século. Novidade mesmo? Nem tanto. A Informática, eu já disse isso
diversas vezes, tem a propriedade de produzir conceitos novos, a partir de outros, em
um eterno ciclo de lanternagem de temas e conceitos que, às vezes, até confunde. O
conceito de MDM é algo nesse contexto. Significa gerência de dados mestres.

70
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

O que são os dados mestres? Os dados mestres são os dados mais importantes
existentes dentro de uma organização. É claro que qualquer organização tem como
dados mestres clientes, produtos, locais, fornecedores, contas contábeis etc. Mas esses
não foram sempre os dados-alvo de todas as propostas de inovação vindas com ban-
cos de dados, BI etc.? Sim, foram. E por que uma nova forma de abordagem chega
agora? A resposta tem várias nuances: uma delas está atrelada a uma subliminar ne-
cessidade de produzir conceitos novos para tocar as engrenagens da indústria da con-
sultoria, visto que a técnica de bancos de dados já virou commodity e o BI já está bem
internalizado, aceito, dominado etc. A outra nasceu pela apatia como as empresas
trataram os seus dados fundamentais nessas últimas décadas. Apareceu o MDM como
proposta para tratar os dados mestres, com conceitos, de novo, voltados para os as-
pectos de qualidade. Aqui o MDM toca os conceitos de governança de dados. É um
controle mais efetivo e menos anárquico dos dados, com observações mais voltadas
para qualidade, aderência a padrões regulatórios, controle de replicação etc. A grande
alavancagem, entretanto, surgiu na fase pós-CRM, quando muitos projetos fracassa-
ram pelo fato de não conseguirem montar uma base única, confiável, limpa, estável
e disponível com todos os dados sobre os clientes. Por quê? Porque os dados tidos
como mestres são normalmente encontrados em diversas bases diferentes, atrelados
a usuários, processos e plataformas diferentes, com graus de precisão, completude e
consistência extremamente variáveis e com contornos frágeis e pouco confiáveis. O
próprio conceito de dados mestres pode variar de amplitude.
Os dados mestres clássicos são os dados estruturados, os mesmos que conhe-
cemos desde anteontem. Eles têm uma formatação estrutural bem definida, os con-
ceitos são modelados como entidades conhecidas (cliente, fornecedor, item, locais
etc.). Os dados mestres, dependendo da natureza do negócio, podem ser também não
estruturados: são dados produzidos com o crescimento da sociedade da informação,
que vão de documentos pdf, páginas em portais corporativos, mensagens em redes
sociais, e-mails etc. Estes, aliás, são parcialmente estruturados, visto que os campos
remetente, destinatário, cópia e cópia oculta são até meio estruturados. O conteúdo
já não é estruturado, pois tem forma e tamanho livres.
Os dados mestres também devem ser observados segundo outra lupa. Os da-
dos mestres normalmente possuem relacionamentos com outros dados. Não vivem
sozinhos. Esses relacionamentos são originados dos eventos a que os dados mestres
são submetidos nas suas relações de negócios. Por exemplo, um cliente se cadastra,
um cliente compra produtos ou serviços, um cliente paga sua fatura, uma ordem de
despacho é enviada a ele com o material comprado, o cliente eventualmente reclama
etc. Todos esses eventos em torno do dado mestre (cliente, no caso) caracterizam
relacionamentos com outros dados, como dados de entrega, registro de reclama-
ção no call-center, nota fiscal etc. Esses relacionamentos acabam criando uma ligação
hierárquica, denotando que um conjunto de outros dados está subordinado àquele
conjunto de dados mestres.
Além dessa informação, outra se torna fundamental no entendimento dos
dados mestres: os seus atributos. Um dado mestre, representado por uma entidade

71
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

ou classe, tem um conjunto de atributos que lhe confere identificação e caracteri-


zação. O problema é que, através dos diversos canais de relacionamentos que aquela
entidade tem com a empresa, diferentes atributos podem ser definidos para a mesma
entidade, dependendo da forma de relacionamento. Imagine o dado mestre cliente.
Ele tem obviamente um conjunto de atributos próprios (identificação, CPF, nome,
endereço etc.). Entretanto, o cliente, quando se cadastra via portal, poderá ter outras
informações, relacionadas ao domínio e contexto específico em que tangencia a
empresa naquele momento. Do ponto de vista de pagamento das suas faturas, outros
atributos poderão ser criados. Isso significa que certo dado mestre terá um conjunto
fixo de atributos que interessa a todos os domínios da empresa e um conjunto variá-
vel que interessa a domínios e contextos específicos, dependentes daquele relacio-
namento particular. Seria uma espécie de dados mestres principais e dados mestres
complementares, dependentes de cada domínio de negócios. E aqui se chega a um
ponto crítico no tratamento dos dados mestres, que objetiva ter uma fonte única,
verdadeira, íntegra e confiável de dados. Teremos uma entidade completa, com todos
os campos de interesse de todos os domínios, mesmo que, para alguns deles, certos
atributos não sejam pertinentes. Isso, no fundo, é uma espécie de volta ao começo.
Tudo começou exatamente dessa forma. Nos anos 1960, pré-banco de dados,
os sistemas de arquivos eram todos dessa forma. Diversos arquivos, específicos de
áreas possuíam dados replicados do então chamado cadastro mestre. Por necessidade
e falta de definições corporativas claras, algumas áreas acabavam montando o seu
próprio cadastro ou “banquinho de dados”, como diziam de forma cautelosa, a jus-
tificar a redundância consentida. Tudo sugere que talvez estejamos com problemas
semelhantes, passados 50 anos da introdução dos conceitos de banco de dados.
Dessa forma, além de entender os seus relacionamentos e atributos, como se
faz na tradicional modelagem de dados, agora na modelagem MDM também deve-
mos entender o ciclo de vida de cada entidade mestre, visto que temos de ser bem
seletivos na definição do que será gerenciado. Temos de analisar o famoso CRUD,
agora aplicado ao MDM. O CRUD significa que um dado é criado (C), lido na
forma de relatórios, pesquisas, cubos etc. (R), alterado (U) e eliminado (D). Portanto,
a engenharia MDM deverá se preocupar com esses ciclos por que passam os dados
mestres. Isso tudo está soando como um déjà vu? Está? Pois é isso mesmo, só que
com a diferença de que agora estamos imersos em ambientes de alta competitividade,
nos quais a qualidade torna-se fundamental, a reputação é fator crítico de sucesso no
mercado, o volume de dados é muito maior e os pontos de tangência com o business
são muito mais amplos. O dado mestre de um cliente de uma empresa de telecomu-
nicações poderá ser criado, hoje, em pontos diferentes da superfície da empresa. Pode
ser criado via internet, no portal corporativo ou numa loja do agente autorizado,
por exemplo.
Outros dois pontos importantes entram nesse jogo de análise dos arquivos
do escopo MDM: a cardinalidade e a volatilidade. A cardinalidade de uma entidade
representa o número de valores diferentes para certo campo que deverá ser conside-
rado. Em última análise, seria: quantos clientes diferentes eu tenho no meu cadastro

72
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

ou quantos departamentos, ou quantos produtos diferentes existem na minha tabela


mestre? Alguns dados mestres com baixa cardinalidade não viabilizam o investimen-
to, pois a sua gerência poderá ser feita sem grandes impactos.
A volatilidade, que representa o grau de alteração a que aquela entidade é
submetida, é outro fator a se considerar. Alguns dados mestres mudam mais do que
outros. Por exemplo, a volatilidade das informações de clientes é intrinsecamente
maior que a de produtos ou de departamentos. Ou seja, aqui também deveremos
analisar o quanto a mudança afetará o meu projeto, até porque o MDM não somente
visa ao cadastro inicial dos dados mestres, mas à sua contínua manutenção. Os clien-
tes tendem a mudar de estado civil, de endereço e até de sexo, sei lá, pode-se esperar
certa incidência. Já os produtos tendem a ser mais estáveis mantendo seus atributos
inalterados ao longo do seu ciclo de vida. No capítulo relativo à modelagem di-
mensional de dados, voltaremos a esse assunto, com algumas abordagens para tratar a
parte fixa e a parte variável desses dados, quando dispostos em dimensões.

DADOS MESTRES E A REUTILIZAÇÃO


Outro ponto importante tocado pela abordagem MDM é o aspecto de reu-
tilização. Essa também foi uma das grandes promessas da tecnologia de BD nos
anos 1960, promovendo depósitos centralizados em que todos poderiam obter os
dados e as informações de que precisavam. Aqui falamos de reutilização de dados
e informações. A reutilização ganha também espaço, gradativamente, nos processos
de desenvolvimento de software, incentivando a adoção de políticas, estruturas e
ferramentas que proporcionem aos desenvolvedores a reutilização de códigos, ar-
tefatos e conhecimentos. Como a reutilização de códigos e artefatos, a de dados
também tem obstáculos de natureza cultural. Os desenvolvedores se sentem mais
confortáveis quando criam as suas próprias estruturas de dados. Evitam a reutili-
zação, como se ela fosse uma declaração de incapacidade de buscar uma solução.
O antídoto para isso passa por aspectos de motivação para programas de incentivo
ao reuso de código e pelo estabelecimento de políticas de governança para dados.
A redundância de códigos é nefasta à medida que gasta mais espaço e pode trazer
impactos na atualização de suas diversas instâncias. As suas consequências são, diga-
mos, mais internas, com o dispêndio de maior esforço. Já a redundância de dados
pode provocar mais danos na visibilidade, pois os dados são registros de fatos inter-
nos e externos, associados diretamente ao negócio da empresa, tendo elos diretos
com clientes, fornecedores, agências reguladoras etc. Um nome errado, um valor
incorreto ou o envio de um documento importante a um endereço inexistente po-
dem implicar custos financeiros e, pior, trincar conceitos, imagens e reputações. Daí
o esforço para se reduzir a redundância dos dados com o incentivo à reutilização,
lembrando os mesmos preceitos nascidos nos ventres das primeiras ideias de bancos
de dados.
O que é MDM, como proposta? A proposta de MDM é simplesmente esta:
fazer uma base lógica única, com os dados na sua forma una e verdadeira. O objetivo
é nobre e passa pela busca de qualidade no tratamento dos dados mestres que, no

73
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

fundo, são os mais importantes de uma empresa. A qualidade dos dados poderá evitar
problemas de reputação e desconfortos no trato com os clientes à medida que au-
menta a probabilidade de ter valores representando a realidade, clientes com nomes
corretos e com endereços certos, devidamente alcançados pelas correspondências
enviadas, com as faturas nos justos valores do que foi comprado, além das milhagens
creditadas corretamente após a realização da viagem etc. Simples assim. Os dados
representam os fatos verdadeiros. O conceito de MDM, dessa forma, pode ser defi-
nido como um processo que envolve ferramentas, pessoas, procedimentos, visando à
criação e à manutenção de bases de dados mestres únicas, do ponto de vista lógico,
contendo informações precisas e consistentes.

Convergência entre MDM e BI


A técnica de BI não oferece proposta para resolver isso? Sim, daí esses dois
conceitos terem certa área de tangência. O conceito de Operational Data Store
(ODS), para onde convergem os dados oriundos de diversas fontes, onde são de-
vidamente integrados, escovados, limpos com o devido banho de qualidade, tem
similaridades com as propostas MDM. O MDM tenciona ter uma fonte única de
dados, fortemente transacional, que constitui a verdade dos fatos e atende a uma
plateia mais operacional. O BI, com ODS, data mart e DW, foca mais os dados infor-
macionais, com integração, agregação, sumarização, e tende a atender a uma plateia
mais gerencial. Mas o BIRT, o BI em tempo real, tende também a trabalhar mais
diretamente nos dados transacionais ou diminuir o gap entre eles e o mundo infor-
macional (dos DW e data marts). Dessa forma, percebe-se que esses dois movimentos
são convergentes e se traduzem em processos que estão dentro de um guarda-chuva
maior de GD, por considerarem os ativos de dados, seja no nível operacional, seja no
transacional ou no informacional, como elementos fundamentais da qualidade de
produtos e de serviços.

Definição de processo para projetos de MDM


Um processo para a realização de projetos em MDM é constituído por um
conjunto de políticas, procedimentos, papéis e recursos humanos, tecnológicos e
financeiros que possa ser aplicado na implementação de projetos dessa natureza. Esse
e outros processos estarão dentro do guarda-chuva de governança de dados, confor-
me discutido anteriormente. A Figura 4.13 mostra um framework que representa as
atividades de um projeto de MDM, baseado em um modelo de ciclo de vida itera-
tivo incremental, com três ciclos: o ciclo de release, que envolveria uma fase mais de
análise e planejamento, a fase de iterações, com foco no desenvolvimento das diversas
soluções de MDM, e o ciclo de acompanhamento diário, que representa a visão de
uma gerência próxima, resolvendo impedimentos. Essa abordagem é muito próxima
do modelo ágil com scrum, aplicado em projetos de desenvolvimento de software.

74
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

Figura 4.13
Framework com atividades de um projeto de MDM.

Os passos principais de um projeto MDM são:


1) Identificar as áreas de negócios e papéis-chave na organização, capazes de
serem beneficiados com um programa de MDM.
 Estabelecer os devidos valores de negócios e criar justificativas sólidas. Um
processo de MDM não é algo fácil de ser implementado e demanda fortes pi-
lares de convencimento, devido à necessidade de envolvimento de alta gerên-
cia, áreas de negócios, além de substancial investimento em tempo e recursos.
 Identificar papéis envolvidos, principalmente aqueles capazes de fornecer
suporte para o projeto, ou seja, os potenciais stakeholders. Envolver gerência
sênior, representantes de áreas de negócios, responsáveis por aplicações, além
de representantes das áreas de GD (governança de dados) e da área de TI. Os
representantes da área de GD desempenham um importante papel relativo à
resolução de possíveis conflitos originados por diversos usuários (produto-
res e consumidores) dos mesmos dados corporativos. No caso de existência
de merges e fusões recentes na empresa, os MD (dados mestres) deverão ser
analisados, incluindo essas recentes unidades incorporadas, caso isso esteja
dentro da política de governança definida na corporação.
75
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

2) Levantar os principais dados mestres (objetos) usados na empresa, candida-


tos a um processo de integração e unificação.
 Definir participantes da tarefa de levantamento (definido no plano de pro-
jeto, via matriz de responsabilidades).
 Realizar os levantamentos e entrevistas com o objetivo de obter e entender
os modelos de processos de negócios, que darão origem aos modelos de
dados (classes).
 Modelar os processos com foco na visão de como capturam, usam e/ou
atualizam os objetos de dados.
 Criar uma lista de dados candidatos a mestre (MD). Para cada um dos
objetos mestres mapeados, identificar os seus atributos.
 Associar os papéis desempenhados no processo com as ações efetuadas
sobre aquele objeto mestre, identificando os CCC, ou seja, os produtores
(collectors), mantenedores (custodians) e consumidores (consumers) dos da-
dos mestres: nessa atividade deverão ser identificados os sistemas, aplicati-
vos e programas que produzem os MD e quais aplicativos usam os dados
mestres para consumo. Um MD poderá ser produzido nas suas diversas
manifestações por diferentes sistemas da empresa. Os sistemas produtores
e mantenedores são aqueles que criam, alteram e eliminam elementos
dos dados mestres. Os sistemas que usam o fazem como consumidor, sem
alterá-los. Caso haja alteração, serão considerados dentro da categoria de
produtores e atualizadores.
 Validar com os envolvidos das áreas de negócios, buscando as similari-
dades e diferenças entre as visões obtidas no levantamento efetuado e na
perspectiva desejada.
 Consolidar os metadados, criando um glossário ou dicionário de termos, identi-
ficando e padronizando elementos comuns. Aplicar os padrões, já em consenso
com as definições da GD. Os dados mestres deverão ser cuidadosamente analisa-
dos segundo a visão dos metadados, conforme os aspectos sintáticos, semânticos
e estruturais. Os metadados deverão apontar nomes, tipos de dados, tamanhos,
regras de validação aplicáveis, significado de negócio e suas restrições etc. Além
disso, deverá ser capturada a visão de negócios dos dados. O uso de ferramental
é importante aqui, pois essa captura poderá implicar buscas extensas em diversas
estruturas de dados (bancos de dados, catálogos, dicionários de dados, bibliotecas,
fontes etc.). Para tal, a atividade de definição de ferramentas e de ambientes de
trabalhos será de extrema importância nessa fase. Os metadados levantados de-
verão ser armazenados em dicionários ou catálogos que ofereçam condições de
documentação e busca, via palavras-chave associadas a eles e aos seus atributos.
3) Resolver as diferenças semânticas entre as variadas instâncias do mesmo
MD, considerando-se cenários e objetivos, definições de negócios, priori-
dades e hierarquias.

76
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

 Analisar os metadados para obter consenso e harmonização dos conceitos


eventualmente discrepantes resultantes de cenários nos quais há vários con-
sumidores e produtores atuando sobre os mesmos dados.
 Institucionalizar os padrões e políticas definidos pela GD, considerando um
novo ambiente no qual os dados não mais pertencerão a um proprietário
em particular.
4) Analisar a viabilidade de extração, compartilhamento e entrega dos dados
instanciados, agora dentro de uma visão unificada e padronizada para aten-
der às várias aplicações.
 Definir a viabilidade do projeto, analisando o grau de sobreposição de uso
dos objetos mestres.
 Definir planos de integração dos dados e de migração das aplicações envol-
vidas, no caso de a viabilidade existir.
5) Implementar as arquiteturas de MDM. A arquitetura deverá mostrar os di-
versos componentes participantes, como os sistemas fontes, possíveis cama-
das de mapeamento, transformação, armazenamento e documentação. Essa
solução poderá ser prototipada a fim de mostrar, em fase de prova de con-
ceito, o alcance dos requisitos definidos para aquele projeto de MDM. Por
exemplo, um protótipo poderá mostrar as ações de captura, transformações
e armazenamento dos MDM, bem como uma exemplificação de seu uso
por um sistema existente.
6) Implementação de interfaces transparentes ou de ajustes de aplicações
clientes para o uso das novas visões e arquiteturas unificadas do MD.
7) Estabelecer, via GD, os aspectos necessários para controle e garantia de
integração contínua dos novos dados e aplicativos no framework de MDM.
Definir mecanismos de controle de garantia de qualidade, auditoria etc. a
serem aplicados no ambiente MDM.

Arquiteturas MDM
A seguir discutiremos algumas opções arquiteturais para a implementação de
soluções MDM.
Para efeito didático, a Figura 4.14 mostra a situação anterior à implementação
das técnicas de MDM. O cenário se mostra com a redundância clássica, em que vários
aplicativos têm os seus MD, fazendo leitura e atualização sobre eles. Nesse contexto
não existe nenhum controle e política de GD, ficando as informações dependentes dos
diversos dados replicados, sem integração e totalmente expostos aos fatores de vulnera-
bilidade dos dados em qualidade.

77
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 4.14
Arquitetura MDM, visão com redundância.

Características da Arquitetura – Situação Pré-MDM, Cenário de Redundância


a) Vários aplicativos leem (seta tracejada) e atualizam (seta cheia) o Dado Mestre 1
redundado nos seus diferentes domínios.
b) Ambiente sem controle e gerência de MD e sem política de GD.
c) Estilo de redundância, como antigamente.

A Figura 4.15 mostra uma solução chamada consolidação, formada por um re-
positório consolidado a partir de importações batchs de várias fontes. Essa arquitetura é
semelhante aos processos de ETC usados nos sistemas de BI e serve melhor aos siste-
mas informacionais. Normalmente, os dados não retornam aos mestres originais, que
continuam com sua independência. Essa arquitetura não oferece sistemas de replicações
(publicação e subscrição), e os movimentos são efetuados por utilitários batchs.

Figura 4.15
Arquitetura MDM, visão de consolidação.

78
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

Características da Arquitetura MDM: Consolidação


a) Faz importação batch para um ambiente integrador.
b) Realiza a consolidação e a integração.
c) Exporta batch para ambientes desejados (targets).
d) Não envolve replicação (subscrição), com os movimentos sempre feitos por utilitários
batches.

A Figura 4.16 mostra uma solução de diretório centralizado. Vários aplicativos


leem um diretório que mantém as informações de relacionamentos entre diferentes dados
mestres. Suponha que, no sistema de CRM, exista um registro para Carlos Barbieri, e no
sistema de cadastro via web, também. Os dois registros mestres de Carlos Barbieri estarão
relacionados no diretório (via chaves primárias, por exemplo), mostrando que quem ler o
registro mestre de Carlos Barbieri no sistema CRM e desejar mais informações poderá ir
ao diretório e buscar a outra chave que apontará para o sistema web, no qual também ha-
verá informações sobre ele. Um sistema de consultas distribuídas permitirá que uma visão
virtual seja montada em um aplicativo, composta de dados oriundos das várias fontes. A
desvantagem clara dessa abordagem é o trabalho que teremos em buscas federadas distri-
buídas em várias bases, podendo haver comprometimento de desempenho. Um aplicativo
mantenedor desse diretório deverá ser definido. No fundo, esse conceito de MDM por
diretório se aproxima do conceito de EII (Entreprise information Integration), camada
capaz de promover buscas federadas heterogêneas em dados.

Figura 4.16
Arquitetura MDM, visão com diretório ou registry.

79
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Características da Arquitetura MDM: Diretório/Registry


a) Um diretório contém informações das entidades e atributos do DM nas diversas fontes.
b) No diretório existem apontadores globais para cada DM, com serviços de pesquisa
e busca.
c) Permite a criação de uma visão virtual dinamicamente montada e normalmente read-
only (RO), realizada via consulta federada (estilo Enterprise Information Integration – EII).

A Figura 4.17 mostra a solução de coexistência: nessa solução arquitetural, os


MD continuam sob o domínio de cada aplicativo, porém existe um protocolo de co-
existência, como o nome sugere. Os MD poderão ser buscados por transação ou por
replicação nas outras fontes. Nessa arquitetura aparecem os serviços, no conceito SOA,
permitindo os acessos ou mecanismos de publicação e subscrição.

Figura 4.17
Arquitetura MDM, visão com coexistência.

80
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

Características da Arquitetura MDM: Coexistência


Cada sistema mantém os seus dados.
b) Permite referência cruzada entre eles e possibilita a pesquisa e a busca de outros
dados mestres em outras fontes, através de SOA – camada de serviços.
c) No caso o aplicativo 1 lê e atualiza os seus MD e pode buscar outro MD em outro
aplicativo (x), através de transações ou via replicação (publicação/subscrição).
d) Risco, se houver redundância não controlada entre os MD.
e) Estilo de BD particionado.

A Figura 4.18 mostra a solução de centralização, chamada também de transação.


Nessa arquitetura, um único MD é montado, com os outros processos e sistemas fazen-
do acesso e atualização. Essa forma centralizada é realizada através de camadas transacio-
nais com plena capacidade de isolamento, logs, auditoria, controles de acessos etc. Essa
arquitetura implica a alteração das interfaces dos sistemas fontes.

Figura 4.18
Arquitetura MDM, visão com centralização.

Características da Arquitetura MDM: Centralização/Transação


a) Vários aplicativos leem o Dado Mestre 1 via serviços.
b) Um aplicativo mantenedor lê e atualiza.
c) Garante uma política centralizada de MD, com autorização concedida via GD.
d) Permite o conceito de transação, com integridade transacional entre diversos processos.
e) Estilo: BD centralizado.
Obs.: Impacto na alteração de todas as interfaces dos aplicativos, para lerem o MD em
vez de lerem seus arquivos.

81
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

CONSIDERAÇÕES IMPORTANTES SOBRE OUTRAS ATIVIDADES


EM UM PROJETO MDM
Em paralelo, outras atividades poderão/deverão ser realizadas, visando à com-
plementação do projeto de MDM. Por exemplo, ao detalhamento do modelo MDM
também se junta o detalhamento do ambiente, em que, dentre outras coisas, se esta-
belece o conjunto de ferramentas a serem usadas. Essas ferramentas deverão realizar
as funções de qualidade e profiling de dados como a resolução de correspondência, ou
seja, se vários possíveis registros de clientes correspondem à mesma pessoa; funções
de padronização de dados, ou seja, como serão mantidas a semântica e a estrutura do
dado de endereço; funções de limpeza de campos, ou seja, a eliminação de valores
sem sentido, preenchimentos com brancos, 9 etc., e a resolução de valores ausentes,
com defaults ou definidos por regras de negócios.
A solução MDM também deverá contemplar os aspectos de versões dos re-
gistros, definindo a necessidade ou não de se manter controle de versões sobre os
registros que foram trabalhados, a fim de garantir, no futuro, possíveis resoluções de
problemas ou conflitos gerados. Por exemplo, suponha que um determinado registro
de cliente tenha sido obtido e armazenado no MD através do tratamento de vários
registros oriundos de sistemas clientes. Caso algum erro se manifeste tempos depois,
será importante ter o controle de gerência de configuração desses elementos, a fim
de saber corretamente quais foram as fontes que deram origem àquele registro com
problema. Por isso é que a gerência de configuração torna-se um processo importan-
te nesse tipo de sistema no qual os dados são submetidos a intensas transformações.
Ainda deveria ser contemplada a realização de um plano de teste, a fim de garantir,
em ambiente controlado, o processamento correto das atividades de alterações e
criações dos sistemas e dados envolvidos.
A fase de construção (ciclo das iterações), segundo a nossa abordagem, seria o
momento em que as atividades de implementação e testes se concentram. Teríamos
nessas iterações as atividades de construção dos depósitos de MDM, a modificação
dos sistemas envolvidos (tanto os sistemas clientes quanto os sistemas produtores),
seguindo-se as atividades de testes. As atividades de manutenção dos processos que
atualizam os MD complementariam a fase de construção. Do ponto de vista de
processos de verificação e validação, nessa fase seriam feitos os testes e inspeções de
códigos (ênfase na verificação), testes de regressão (ênfase na integração) e, eventu-
almente, validações nos ambientes pretendidos.
As atividades de validação poderiam ocorrer ao final de cada iteração ou, caso
pertinente, no final do release. Seriam as atividades de testes de aceitação e obtenção
do aceite final que complementariam as atividades de verificação e validação. Ao final
dessa fase, ocorreriam os registros das lições aprendidas naquela iteração, com a for-
mação de bases históricas e o registro de conhecimentos desenvolvidos.
De forma ortogonal a essas fases, as principais gerências aplicadas em nível de
maturidade de desenvolvimento de soluções poderiam ser consideradas:

82
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

 GPR: processo responsável pelo planejamento e acompanhamento do


projeto de implementação MDM, que está fortemente acoplado às dis-
ciplinas de requisitos, planejamento e acompanhamento de projeto.
 Os processos de apoio organizacional, como GCO (gerência de configu-
ração), garantirão a consistência dos diversos artefatos e produtos de traba-
lhos desenvolvidos ao longo das fases. O processo de GQA garantirá, com
auditorias, a aderência das atividades planejadas e dos produtos esperados,
com o processo definido para projetos MDM. E, finalmente, o processo de
medições garantirá um acompanhamento mais quantitativo dos indicado-
res de evolução do projeto, permitindo acertos de rotas.
Da mesma forma, um processo de qualidade deverá ter, além de processos
fundamentais e de apoio organizacional, um conjunto de atributos e resultados es-
perados, presentes em todos os processos. As Figuras 4.19 e 4.20 mostram, em forma
de mapa mental simplificado, os resultados dos atributos do processo para projetos
MDM. Esses resultados representam os diversos aspectos que deverão ser conside-
rados no projeto MDM. Os 14 resultados representados estão associados ao modelo
MPS.BR, no nível F de maturidade. O resultado 1 representa o conjunto de ativi-
dades desenvolvidas especificamente nos processos MDM, e os resultados restantes
(de 2 a 14) formam os resultados de atributos que seriam aplicados em todos os
processos definidos sob a capa de governança de dados.

Figura 4.19
Atributos de processos para projetos MDM – parte I.

83
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 4.20
Atributos de processos para projetos MDM – parte II.

A SITUAÇÃO DOS PROJETOS DE MDM EM 2010


Um excelente estudo sobre a efetiva aplicação das técnicas de MDM é a pesquisa
Master Data Management Projects in Practice, conduzida pela empresa The Information
Difference (http://www.informationdifference.com), patrocinada pelas empresas
Baseline Consulting (www.baseline-consulting.com) e Talend (www.talend.com), esta
provedora de ferramentas de integração de dados open source. A Baseline Consulting
foi adquirida em 2011 pela Data Flux, subsidiária da SAS, gigante de BI e BA (Business
Analytics), para os aspectos de qualidade e governança de dados, evidenciando a forte
convergência desses conceitos.
Os dados, disponíveis para download na internet em http://www.baseline-
consulting.com/mdm-survey, foram publicados em dezembro de 2009 e acessados em
fevereiro de 2010. O estudo mostra um interessante retrato da aplicação de projetos
MDM em empresas pelo mundo. Os principais pontos da pesquisa são:
1) Abrangência da pesquisa: as empresas que foram pesquisadas eram, na ordem
de predominância, da área de finanças/bancos e seguros, seguida da área de
manufatura e, em terceiro lugar, da esfera farmacêutica/saúde. Eram empre-
sas com faturamento predominantemente acima US$100 milhões anuais,
com mais de 70% delas oriundas dos Estados Unidos/Canadá (maior inci-
dência) e da Europa, e em torno de 22% da macrorregião da Australásia.
2) Respondentes: a maior parte dos respondentes da pesquisa tinha o título
de arquiteto corporativo ou arquiteto-chefe. Cabe uma observação sobre
esse novo papel que surge nas empresas. O arquiteto corporativo, segundo

84
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

a definição do MIT, é aquele responsável pelo acoplamento entre os pro-


cessos de negócios da empresa e a infraestrutura de TI, de forma a refletir
os requisitos de integração e padronização da empresa. A arquitetura cor-
porativa, como definida pelo IFEAD (Institute for Enterprise Architecture
Developments), é a completa expressão da empresa através de um plano
mestre que age como uma força de colaboração entre aspectos gerais de
negócios, como objetivos, visão, estratégias e princípios de governança;
aspectos de operação de negócios, como termos de negócios, estruturas
organizacionais, processos e dados; aspectos de automação, como siste-
mas de informação e bancos de dados; e viabiliza a infraestrutura para o
negócio da empresa, provendo computadores, redes, sistemas operacionais
etc. No fundo, esse papel é uma espécie de zelador de três elementos fun-
damentais: a “arquitetura de negócios”, que move a empresa no plano do
mercado, a “arquitetura dos sistemas de informações”, que define processos
e dados para suportar esses movimentos, e a “arquitetura de tecnologia”,
que serve como substrato de ferramental para que a segunda arquitetura
aconteça, objetivando o alcance da primeira. Existem dois frameworks im-
portantes dentro do conceito de arquitetura corporativa: o TOGAF 9 (The
Open Group Architecture Framework-9) e o de John Zachman, publicado
inicialmente em 1987 no IBM System Journal, volume 26. O framework
de Zachman foi posteriomente estendido e hoje é uma das referências
para arquitetura corporativa. O livro Modelagem de dados (1994), de Carlos
Barbieri, já detalhava, nas páginas 24 e 25, o framework de Zachman.
3) Perfil dos projetos: a grande maioria dos projetos (56%) era em cima de
dados de clientes e de produtos. Os projetos tinham volumes variados de
registros, indo de 1 a 990 milhões, com valor médio de três milhões de regis-
tros. Um terço dos respondentes disse ter volumes na faixa de um milhão de
registros; 33% das empresas disseram ter empreendido mais de dois projetos
MDM, o que sinaliza a ultrapassagem do ponto de beta-teste da tecnologia
e a entrada na operação do dia a dia. O aparecimento dos dados mestres de
clientes e produtos é sintomático e sinaliza as bases que mais possuem varia-
ções de formatos e diversidade de qualidade de dados, devido à sua grande
exposição nas fronteiras dos negócios.
4) Apoio de consultoria na implementação do MDM: 26% das empresas res-
ponderam que estavam sendo apoiadas por um serviço de SI (integrador
de sistemas), enquanto 16% responderam que não usavam SI, mas sim re-
cursos e conceitos próprios. Em torno de 13% disseram que não estavam
empreendendo um projeto MDM, mas que não intencionavam usar um SI
quando o fizessem. Doze por cento responderam que não estavam fazendo
um projeto MDM, mas que contratariam um SI quando decidissem fazê-lo.
E, finalmente, 22% dos respondentes não tinham intenções e planos para
MDM. Isso mostra que 67% das empresas haviam cogitado movimen-

85
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

tos em direção ao MDM, independentemente de fazê-lo com SI ou não,


o que confere ao movimento certa indicação crescente de necessidade.
Com relação ao uso de metodologias, 57% disseram ter usado sua própria
abordagem, ficando 36% com o uso de metodologias trazidas pelos inte-
gradores (SI). Dentre os players de destaque desse segmento de mercado,
aparecem em ordem de incidência: IBM GBS (Global Business Services),
Accenture, a indiana Wipro e, juntas, a EMC Business Edge Solutions,
braço de serviços da gigante da indústria de data storage, e a também
indiana HCL. A pesquisa também indagou sobre a satisfação que as em-
presas demonstraram com os seus integradores, e a resposta foi: 11% se
disseram muito satisfeitos; 51%, satisfeitos; 14%, insatisfeitos; e19%, muito
insatisfeitos. Esses valores se ligam à questão seguinte, que indagou sobre a
avaliação da experiência do SI escolhido: 59% acharam que o SI escolhido
foi adequadamente experiente, enquanto 49% apontaram seus SIs como
muito inexperientes. Para fechar esse quesito, a pesquisa perguntou sobre
a “marca” da tecnologia usada na solução MDM implementada, ou seja, a
família de softwares voltados para essa abordagem. O resultado, por ordem
de incidência: IBM, SAP e Kalido, esta uma empresa menos conhecida de
BI, mas que tem movimentos inovadores na área de modelagem de dados,
nascidos de pesquisas na Shell. Nesse segmento, ela ficou à frente da Oracle
(incluindo os produtos coligados Hiperion e Siebel) e da SAS, famosa por
produtos em BI preditivo, com o seu DataFlux, um produto nascido no
berço direto dos softwares voltados para qualidade de dados. Também apa-
recem nessa lista a Initiate, recentemente adquirida pela IBM, e a Siperian,
adquirida pela Informática. Esse movimento de aquisições de empresas é
sintomático.Vem desde a época das aquisições de empresas bem-sucedidas
de BD e também de BI. As grandes e mais poderosas ficam de olho nas
pequenas, porém competentes e inovadoras. Nessa área de MDM e de
integração de dados, a Data Flux foi comprada pela SAS, a Initiate foi ad-
quirida pela IBM, e a Siperian foi incorporada pela Informática.
5) A respeito dos grandes benefícios, os respondentes apontaram que a qualida-
de de dados foi o grande elemento alcançado, associado ao maior entendi-
mento das consequências do dado “sujo”. A obrigatoriedade sobre definição
de padrões, entendimento de processos e de regras de negócios foi apontada
também como grande objetivo alcançado. A unificação de dados mestres, é
claro, foi apontada como um elemento obtido, até porque era o seu grande
objetivo. A criação de área de governança de dados, com a definição de data
stewards ou responsáveis pelos dados dentro da esfera de negócios, foi ou-
tro elemento apontado como objetivo alcançado. Na barra das dificuldades
foram apontados os problemas de conversão de dados, as dificuldades no
entendimento dos processos e das regras de negócios (mostradas também
como fator positivo), a falta de pessoal qualificado, além de fortes requisitos
de conhecimentos negociais, além dos técnicos. Dentro dessa linha, uma

86
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

pergunta óbvia sobre os fatores ou sugestões a adotar a fim de evitar ou


minimizar problemas: em bom português, qual seria o caminho das pe-
dras? Os respondentes apontaram alguns óbvios, como ter um projeto com
escopo bem definido, com envolvimento e clareza na definição de papéis
e responsabilidades, e a adoção de uma abordagem incremental a fim de
evitar gigantismos com obituários definidos. Outros que soam como boas
dicas: entender que esses projetos são mais da esfera de negócios do que do
âmbito de TI; alavancar a oportunidade de se definirem os conceitos de go-
vernança de dados com a criação dos papéis de data stewards (responsáveis),
o lançamento do que chamei de DGPG (grupo de processo/programa de
governança de dados), que seria uma espécie de centro de competência em
MDM, mesclando elementos da área de negócios com a área técnica e obter
o apoio inequívoco da alta gerência para o projeto, que se mostrará mais
complexo e oneroso do que o planejamento sinalizará na fase de concepção.
A produção de um business case para mostrar a verdadeira face do projeto de
MDM talvez seja uma das grandes sugestões, tendo sido adotada por mais de
60% dos respondentes. O estabelecimento de governança de dados foi feito
por 86% dos respondentes.
A pesquisa em questão também fez uma abordagem inversa, direcionando ques-
tões aos implementadores de MDM, empresas integradoras de sistemas que partici-
param desse tipo de projeto. Alguns dados importantes foram obtidos por esse outro
ponto de vista. Por exemplo, com relação à arquitetura utilizada nas soluções MDM,
a pesquisa mostrou que 38% dos respondentes usam a alternativa de consolidação e
31%, a de transação (centralizada). O número apontado para a solução centralizada é
significativamente alto à luz da sua complexidade em termos de impactos nos sistemas
existentes. Essa solução, como vimos anteriormente, passa pela alteração das camadas
de acesso para buscar, a partir de um ponto, os dados MD centralizadamente em uma
única fonte.
Com relação à tecnologia dominante, a Oracle se apresentou com a maior fatia,
55%, seguida de ferramentas próprias com 34%. IBM, Kalido e SAP vieram atrás, com
30%.
Com relação ao tamanho de projetos de MDM, para 25% foi o envolvimento
com iniciativas de 100 milhões de registros. O valor mediano é de 6,5 milhões, e o valor
médio é de 80 milhões.
O esforço (número de recursos humanos por tempo) envolvido em um projeto
MDM tem o valor mediano de 5,5 pessoas/ano, com média de 23. Os projetos MDM
pesquisados estão centrados em valores de seis milhões de registros, com envolvimento
de cinco pessoas/ano e com seis meses de duração.
Sob o ponto de vista dos implementadores, alguns dos benefícios encontrados
nas empresas após a implementação foram: maior fluidez nos processos de gerência de
dados; reação mais rápida quando da mudança de negócios, com reflexo direto no ma-
peamento dos MDM; desenvolvimento confiável de uma única fonte de dados mestres;
percepção surpreendente da quantidade de erros “imperceptíveis” no mundo dos dados
da empresa e consequente melhoria na sua qualidade.

87
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Com relação aos obstáculos, problemas e dificuldades encontrados, produzindo


dicas e conselhos, foram apontados: o MDM não é, na realidade, um projeto, mas uma
mudança cultural na forma como a empresa considerará os seus dados, devendo-se
focar primeiramente os aspectos de governança, mapeando claramente os processos dos
dados. As aplicações MDM podem ser facilitadas depois do estabelecimento dessa base,
e a iniciativa deve ser orientada a negócios, via os data stewards, com o devido envol-
vimento dos níveis gerenciais até o operacional. Finalmente, a sugestão quase sempre
encontrada em projetos inovadores: pense grande e comece pequeno, buscando sempre
retornos imediatos e resultados rápidos, que ajudam no processo de avaliação ampla e
na sua adoção sem maiores obstáculos.

EXEMPLOS DE CASOS DE SUCESSO NO TRATAMENTO,


ADMINISTRAÇÃO E GOVERNANÇA DE DADOS

WalMart
O conglomerado da WalMart, segundo dados de 2008/2009, possui mais de
5.000 lojas, sendo 4.000 só nos Estados Unidos. O gigante atua em 11 países, com taxa
de abertura de 300 lojas por ano, possuindo em torno de 2,5 milhões de empregados e
cerca de 100 milhões de clientes. Tem um faturamento de US$400 bilhões, ou seja, em
torno de 2% do PIB americano. É uma empresa que, se fosse um país, teria o PIB maior
que 90% dos restantes países do planeta. A empresa teve, nesse período, um lucro em
torno de US$10 bilhões, e compra 10% de tudo o que a China vende para os Estados
Unidos. Se fosse um país, seria o oitavo maior parceiro comercial da China, à frente de
Rússia, Austrália e Canadá. Possui o segundo maior parque de processamento de dados
do mundo, com muitos petabytes de armazenamento. Desde 1988, investe maciça-
mente em TI e procura não inventar novidades. Existe a célebre frase de Sam Walton,
o fundador do WalMart, que diz: “Todas as coisas significativas da minha vida eu copiei
de alguém.” Assim caminha uma das maiores empresas do mundo. Apesar disso ou por
causa disso, o gigante do varejo mundial é um grande exemplo de uso de tecnologia de
BI, foco em dados, seu insumo fundamental. A empresa controla rigorosamente todas
as movimentações de seus PDV, possuindo um DW que armazena todos os registros de
vendas de todos os produtos, todos os dias, em todas as lojas, num modelo que, incluin-
do informações de cartão de fidelidade de seus clientes, concentra o maior depósito
de informações sobre varejo do planeta. Qualquer informação sobre uma lata de massa
de tomates vendida em qualquer ponto de sua rede viajará até Bentoville, no estado de
Arkansas, onde fica o QG da empresa. Periodicamente, os dados de todas as vendas são
registrados no seu DW, considerado ícone para os apaixonados pelo BI. Esses milhares
de terabytes concentrados, estimados em 1800, em agosto de 2010, quando minerados
oferecem valiosos recursos de planejamento de marketing e de vendas, que a empresa
considera o seu ativo mais importante. Da mesma forma, as informações de vendas
de produtos da rede abastecem os seus fabricantes que conseguem melhor planejar
suas linhas de produção. O WalMart usa, desde muito, a tecnologia da informação e a

88
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

administração e a gerência de dados, com foco no varejo, como elemento estratégico


para alavancar seus negócios, tendo investido, desde 1988, muitos bilhões de dólares no
desenvolvimento de uma gigantesca estrutura tecnológica que lhe dá suporte.

A garimpagem do comportamento de compras durante os furacões


Um exemplo interessante de bom uso de dados, nos domínios de BI, aconteceu
quando da aproximação do furacão Frances, em setembro de 2004, que se desenhava de
forma ameaçadora, caminhando em direção à região sul dos Estados Unidos. A empresa
resolveu garimpar os dados de consumos registrados nos estados daquela região, cons-
tantemente área-alvo dos furacões de agosto/setembro, e observou que por ocasião da
passagem dos tufões anteriores (Charley, em agosto do mesmo ano) houve significativo
aumento de compra de produtos não tão óbvios para a situação de emergência. Através
dessas análises, o WalMart percebeu que, em vez de lanternas, lonas, pregos e placas, uma
simples torta de morango (strawberry tarts) havia tido um consumo sete vezes maior
que a média. Observou também que o item de maior venda na fase pré-furacão era a
cerveja. De posse dos dados, a rede operou uma gigantesca logística de deslocamento
de estoques daqueles produtos para as áreas que seriam potencialmente atingidas. O
resultado obtido da análise preditiva se consumou, e o WalMart, baseado nas análises
históricas de seus dados, pôde realizar grandes lucros. O WalMart entendeu o compor-
tamento dos americanos aflitos quando expostos aos riscos de um furacão, minerando
um DW. Agora cabe à psicologia americana entender o porquê de as insossas tortas de
morango serem os elementos de escape de uma sociedade acostumada às grandes guer-
ras, tragédias e aos riscos...

O uso do BI colaborativo
O WalMart estabeleceu uma forte relação com os seus fornecedores, permitindo
que, via extranet, eles façam uso cooperativo de BI, acessando os grandes depósitos de
informações da empresa, possibilitando, assim, acesso a dados de vendas de seus produtos
e, consequentemente, produzindo inputs importantes para seu planejamento de produ-
ção. Mais de 17.000 de seus fornecedores acessam informações sobre vendas, despachos,
retornos, reclamações etc., com média de mais de dois milhões de transações por mês,
somente oriundas dessa forma cooperativa de relacionamento entre fornecedor e clien-
te. Vender para a grande rede é uma espécie de loteria. Em um dia da semana de Natal,
uma grande fabricante de computadores vende 400 mil unidades através das quase
5.000 lojas do WalMart. Uma marca japonesa de televisor, que fabrica seus produtos nos
Estados Unidos, alcançou, em 2006, o número de 50 milhões de unidades vendidas ao
longo da sua parceria com a grande rede.3
Ultimamente, o gigante do varejo tem investido pesado em etiquetagem por
radiofrequência, o que facilita toda a logística de recebimento e armazenamento das
gigantescas cargas de produtos que diariamente chegam aos seus mais de 200 centros de

3 FRIEDMAN, Thomas. O mundo é plano – uma breve história do século XXI. Rio de Janeiro: Objetiva, 2005-
2006, p. 162.

89
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

armazenamento/distribuição. As embalagens e os produtos já vêm com emissores de ra-


diofrequência capazes de enviar informações sobre identificação, tipo, embalagem etc.,
captadas por receptores, sem intervenção manual e interferência de obstáculos. A grande
rede de varejo possui forte presença nas relações com os seus fornecedores devido ao
seu calibre de grande comprador. Atua fortemente na pontualidade de seus fornece-
dores, com domínio completo do ciclo de supply-chain: compra-entrega-venda, ado-
tando estilo de empresas RTE (Real Time Enterprise). Ou seja, quando, por qualquer
motivo, um caminhão de entrega se vê com problemas, o sistema central aciona uma
estratégia de contingência, sempre com o intuito de manter a cadeia compra-fabri-
cação-entrega-venda funcionando no seu ciclo completo. O WalMart também adota
uma política de imagem centrada na popularidade. Tem forte apelo popular, atuando
em segmentos mais baixos do extrato social, para quem atua como um grande banco.
Grande parte de seus clientes não possui conta bancária e usa o supermercado como
agência de desconto de contracheques. Além de permanecer com boa imagem no
inconsciente popular, a gigantesca rede atrai os consumidores de forma subliminar
para o seu reduto de compra, através da oferta de vantagens que nada têm com os
conceitos clássicos de varejo. De olho nos novos tempos, o conglomerado já vislum-
bra novos caminhos nos domínios do varejo, analisando a possibilidade de juntar a loja
virtual para compras e as de tijolos para entrega.
Até então centrado na poderosa tecnologia Teradata, especializada em volumes
gigantescos de informação, o WalMart, em 2007, causou grande frisson na comunidade
que acompanha o maior ícone do mundo de varejo, anunciando mudanças. A empresa,
em maio de 2007, anunciou uma parceria com a HP, que era novata no mundo de DW.
Acontece que a HP havia desenvolvido uma tecnologia interna chamada Neoview, por
meio da qual produziu uma solução dentro do mais puro conceito de DW appliance:
uma solução integrada envolvendo as suas poderosas e respeitadas máquinas, com seus
famosos sistemas de armazenamento, e debutou um sistema de bancos de dados (o
que ela nunca teve), trazido nas ondas de diversas aquisições realizadas no surto de
“engole-engole” dos anos 2000. Em certo momento havia um grande SGBD voltado
para altíssimo desempenho e tolerância a falhas, chamado NonStop, da antiga Tandem
Computers. Essa empresa fora adquirida, em 1997, pela Compaq, quando a mediana
produtora de microcomputadores cresceu e virou gente grande. Passado algum tempo,
a HP comprou, em 2002, a Compaq e fechou o ciclo. Além do trio SGBD, CPU espe-
cializada e disco rápido, a solução applicance também traz serviços embutidos. Ou seja,
é a solução que chamamos no interior de “porteira fechada”. A solução Neoview foi
introduzida no mundo dos DWs do WalMart, não se sabendo, com detalhes, se como
coadjuvante do já consagrado Teradata existente ou se como substituta dele. Os detalhes
desses lances chegaram a ser quase cinematográficos: os dois grandes executivos da HP
que comandaram essa ação rocambolesca foram: o CEO Mark Hurd, que outrora foi
o chefe da divisão da NCR-Teradata, e o CIO Randy Mot, que outrora foi CIO do
próprio WalMart. Para completar esse lado “revista Caras” deste capítulo, Mark Hurd
deixou a HP em 2010, envolto em crises espessas e foi imediatamente contratado pela
Oracle, do sempre ousado e polêmico Larry Ellison.

90
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

BT (British Telecommunications)
Considerada uma das maiores empresas de telecomunicações do mundo, a BT
evoluiu através de diversos processos de merges e aquisições. Com cerca de 20 mi-
lhões de clientes, a gigante inglesa tinha, em 1997, aproximadamente 700 sistemas que
gravitavam sobre as suas linhas de produtos. Esses sistemas consumiam diversos “silos”
de dados, denominação dada aos arquivos, bancos de dados ou estruturas informacio-
nais como data marts, que não apresentam níveis de integração capazes de garantir
a integridade das informações que nele residem. Premida pela alta dispersão de seu
acervo e pela vigilância da EU-Data Protection Act, rigorosa legislação europeia que
dispõe sobre segurança e privacidade de dados pessoais de clientes, a empresa empre-
endeu um plano de GD. Com a estratégia de “pense globalmente, aja localmente”,
a empresa iniciou com uma equipe pequena se atrevendo a entender e pesquisar a
qualidade dos dados que circulavam por seus sistemas de negócios. Depois de entre-
vistar 30 dos principais stakeholders-chave dos negócios da empresa, obteve uma visão
sobre a qualidade dos dados da empresa. Subsequentemente, empreendeu ações na área
de marketing através de projetos de qualidade e profiling de dados, usando as ferra-
mentas da Trilium, empresa do grupo Harte-Hanks, especializada em limpeza, inte-
gração e governança de dados. Partiu também para uma estratégia de visão integrada
de clientes, estabelecendo os primeiros pilares da GD. Com a semente de GD lançada,
nasceram as primeiras políticas definindo, de forma corporativa, o sentido de quali-
dade da informação, contemplando atributos já discutidos, como precisão, completu-
de, confiabilidade, acessibilidade e disponibilidade. Com forte plano de comunicação
empresarial, definiu ferramentas padronizadas para as unidades organizacionais, para
posteriormente unificar, em um só grupo, todos os envolvidos em qualidade de da-
dos das diversas unidades de negócios. Assim, foi criado o que chamamos de DGPG,
centro de excelência em governança e qualidade de dados. Os primeiros resultados
em economia direta, fator único que efetivamente sensibiliza os patrocinadores de um
programa como esse, vieram a partir de 2002. Estima-se que a empresa tenha tido um
retorno na faixa de um bilhão de dólares com o programa de GD implementado.4

SITUAÇÃO NO BRASIL
O conceito de qualidade de dados, embora já em uso por empresas em certos
segmentos de negócios mais sensíveis, ainda tem um grande campo para se desenvolver
no Brasil; maior ainda, a governança de dados. O BI, como concebido na sua primeira
geração, já se encontra em uso em muitas empresas, com aplicações interessantes, como
relata a revista Época Negócios, de novembro de 2010, na sua reportagem “Tiro Certo”,
de Carlos Rydlewski e Raquel Salgado (p. 126-135). A reportagem mostra a aplicação
da maior empresa atacadista do Brasil, com 217 mil clientes que compram 16 mil itens
em cerca de 5.000 cidades pelo país. Com a aplicação de mining, a empresa otimizou o
processo de ofertas especiais de produtos para os seus clientes. A garimpagem de dados

4 SARSFIELD, Steve. The Data Governance Imperative. Ely: ITGP, 2009, p. 143-147.

91
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

mostrou com mais precisão quem comprava mais o quê, e isso aumentou a eficiência da
equipe de marketing ao realizar a abordagem de seus clientes.
A reportagem relata também a aplicação de uma das maiores operadoras de saú-
de do Brasil, que resolveu aplicar as técnicas de mining em ações preventivas. Uma delas,
através da mineração de dados de clientes do sexo feminino, segmentados por áreas de
trabalho, percebeu um comportamento padrão em termos de faixa de idade, quando
ficam grávidas. Com isso, pode calcular com maior precisão os gastos médios de cada
grupo e, assim, ajustar devidamente os preços de seus serviços. Com a outra, visando à
redução dos custos com internações hospitalares, a empresa desenvolveu um projeto de
garimpagem entre os seus mais de cinco milhões de beneficiários, identificando, pelos
dados registrados, aqueles que tinham características/sintomas de obesidade, hiperten-
são, diabetes ou indicadores elevados de colesterol e outros marcadores. Acoplando essas
informações com ações de um call-center treinado, a empresa começou a interagir com
a base identificada, procurando a conscientização sobre essas condições, numa estratégia
preventiva que resultou na redução de 48% das internações. Esse é um exemplo emble-
mático da importância da qualidade dos dados como entrada para as funções de BI/mi-
ning. Diferentemente de informações sobre vendas de biscoitos ou cervejas, o business,
nesse caso, é saúde, domínio em que erros de informações podem ter consequências
mais críticas do que acertos eventuais de estoques ou reajustes de pedidos de compras.
Este capítulo poderia ser resumido em um conceito desenvolvido pela equipe
do MIT, capitaneada por Richard Wang e detalhado no capítulo 8 do livro Journey to
Data Quality. A informação deve ser tratada como produto (information as product) e não
como consequência colateral de processos e sistemas (information by products). A diferença,
muito mais do que a semântica das definições, pode ser entendida por um exemplo
eloquente: uma grande rede de óticas americana tinha um processo bem definido que,
simplificadamente, se resumia na comunicação entre dois players: o técnico em ótica,
responsável pela prescrição da receita na loja, e o técnico responsável pela elaboração
das lentes nos laboratórios. Dentro do conceito desenvolvido até aqui, um (o técnico
em ótica) seria o criador da informação e o outro (o laboratorista) seria o consumidor
da informação. Enquanto a informação era um produto do processo, a empresa estava
enfrentando alto índice de correções/descartes nas lentes vendidas. Quando a prescri-
ção passou a ser tratada como um produto em si, com foco nos campos preenchidos e
na retidão de seus dados, observaram-se as diferenças. Algumas informações relevantes
preenchidas pelo técnico da ótica estavam sendo colocadas em campos adicionais da
prescrição, o que não era plenamente considerado pelo laboratorista, pois estava fora
das definições do processo. Isso custou em torno de US$1 milhão e 40.000 lentes re-
jeitadas por ano. Embora os conceitos de governança de dados ultrapassem as fronteiras
da qualidade da informação, através dela a empresa começa a pensar as suas informações
como ativos organizacionais ou produtos entregáveis revestidos de controle, segurança
e acessibilidade. Como o BI é uma camada transformadora, é importante evitar o con-
ceito de GIGO (Garbage in Garbage out) e procurar o QIQO (Quality In , Quality out).

92
ELSEVIER
C APÍTULO 4 I G OVERNANÇA E Q UALIDADE DE D ADOS

RESUMO
A implantação de um processo de melhoria de qualidade em uma empresa de
software não é tarefa trivial. Exige mais do que investimento financeiro. Exige alto grau
de comprometimento da diretoria, pois implica fortes mudanças culturais e passa pela
maturidade também do capital humano. Os conceitos aplicados para GD tornam-se
mais desafiadores à medida que os dados são elementos fluidos, normalmente sem res-
ponsáveis definidos para sua criação, manutenção e consumo. A implementação de BI
em uma empresa, cada vez mais, requererá os aspectos de qualidade de dados discutidos
até então. Projetos de MDM também serão elementos importantes nos cenários em
que as empresas passam por fusões e geram dados mestres replicados, comprometendo
as arquiteturas de BI e a integridade das informações ali trabalhadas e disponibilizadas.
Processos de MDM permitem consolidações, limpeza e sincronismo em dimensões
fundamentais do negócio, como clientes, produtos, fornecedores etc., e o BI não pode
desconsiderar essa associação. Os desafios impostos por essas soluções requerem ações
sobre as camadas gerenciais da empresa, principalmente a gerência média, responsável
pelas ações concretas definidas em um processo e que, no fundo, rodam o negócio da
empresa. A sua cooptação aos processos definidos na área de software e de dados é fator
crítico de sucesso nesses domínios de aculturamento e evolução de maturidade, maior
mesmo que os aspectos financeiros envolvidos neles. A área de DGPG, semelhante-
mente ao SEPG, responsável pela condução dessas ações, deverá saber lidar com as
armadilhas encontradas nas trilhas que passam por essa camada gerencial, fundamental
para o sucesso desses projetos. O seu envolvimento constante, a definição de valores
retornados pela evolução da maturidade e os resultados apresentados em curto prazo são
recomendações saudáveis para se alcançar os objetivos de melhorias nos domínios dos
dados. O exemplo da maior e mais lucrativa rede de varejo do mundo que usa os dados
como elemento de diferencial competitivo é eloquente e claro. Os dados, quando trata-
dos como ativos empresariais, podem ajudar a empresa a montar um vetor diferencial
que favoreça os seus clientes e fornecedores, tornando-a imbatível na arte de competir.

93
CAPÍTULO 5

Conceitos estruturantes de BI

O conceito de BI (Business Intelligence), de forma mais ampla, pode ser en-


tendido como a utilização de variadas fontes de informação para definir estratégias
de competitividade nos negócios da empresa. Podem ser incluídos nessa definição os
conceitos de estruturas de dados, representadas pelos bancos de dados tradicionais, data
warehouse e data marts, criados objetivando o tratamento relacional e dimensional
de informações, bem como as técnicas de data mining aplicadas sobre elas, buscando
correlações e fatos “escondidos”. Com o desenvolvimento dos conceitos de KMS (ge-
rência de conhecimento) e de CI (Competitive Intelligence), essas duas aproximações
analíticas também podem ser incluídas dentro de um cenário mais amplo de BI, como
formas evoluídas de tratamento de informações. A primeira, como forma de transfor-
mação, levando a informação para a fronteira seguinte do conhecimento, grande ativo
dos anos 201x. A outra, CI (Inteligência Competitiva), atuando no plano externo da
empresa, como uma perna de BI que conjuga informações externas, competidores e
ameaças de mercado. Neste capítulo, entretanto, o foco primário de BI será voltado para
o desenvolvimento de depósitos de informações montados em estruturas de data wa-
rehouse, data marts e suas aplicações de data mining. No capítulo seguinte discutiremos
CI, KMS e BSC, como elementos correlatos de BI. Conforme visto até aqui, como
o BI atua como uma camada de transformação, visando à produção de informação e
agora de conhecimento, torna-se fundamental a conexão com os preceitos de qualidade
desenvolvidos no capítulo anterior.

MODELAGEM DE DADOS – INTRODUÇÃO


As técnicas que foram criadas para identificação, registro e entendimento dessa
coisa volátil chamada dados têm passado por frequentes processos de lanternagem ao
longo do tempo. Debutadas oficialmente pelas mãos de Peter Chen com a criação de
seu modelo de entidades e relacionamentos, essas abordagens, após os ajustes personali-
zados de James Martin, Clive Finkelstein, Nijssen, IDEF1X, engenharia de informações
e outros, entraram para o domínio das propostas UML (Unified Modeling Language),
em que se reencontraram com sua alma gêmea, os códigos, habitando o mesmo casulo
conceitual, denominado classe. Como se percebe, código, que no fundo representa
processo, e dados estão sempre juntos. Os dados também passaram por um estágio,
digamos, mais algébrico, com a introdução do modelo relacional, no qual são tratados
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

como entes de conjuntos e sujeitos a manipulações da álgebra relacional, elaboradas


pelo mítico Dr. Codd, pai do modelo relacional. Enquanto isso, uma de suas ramifi-
ramifi-
cações, devidamente ajustada, se transforma em uma técnica fundamental nos projetos
atuais de data warehouse, base dos conceitos de business intelligence. É a modelagem
dimensional de dados, técnica de projeto que na realidade conduz os dados a uma fase,
digamos, cubista, na qual a informação reside na interseção de várias dimensões. Até
por uma feliz coincidência (exclusiva) da língua portuguesa, a palavra dado (no sentido
de informação) é homógrafa e homófona da outra dado (cubo, elemento geométrico
tridimensional, conceito muito usado nas aplicações de data warehouse). A modelagem
dimensional permite que o usuário perceba os dados em uma forma próxima de seu
entendimento, com várias perspectivas possíveis, dentre elas as dimensões que nos são
mais conhecidas: o tempo e o espaço.
Essas técnicas de modelagem dimensional nasceram para modificar alguns
conceitos cristalizados nos projetos tradicionais de bancos de dados, principalmente
após a fase relacional. A rígida blindagem da normalização, por exemplo, se curva,
vez por outra, nesses projetos, à necessidade de estruturas mais ágeis, mesmo com
um sintomático aumento no custo do armazenamento. A retilínea premissa da não
redundância também não resiste a muitos projetos de DW, em que as tabelas de agre-
gados se tornam fatores decisivos de desempenho e são, no fundo, dados replicados.
A técnica também traz propostas claras de desnormalização das dimensões, como no
esquema estrela, conforme será discutido adiante. Afinal, estamos falando de tabelas
que poderão conter muitos milhões de registros, com muitos terabytes e alguns petas
de tamanho e, portanto, qualquer concessão que venha aditivar a velocidade de acesso
é vista como positiva.
O conceito de BI está, assim, na sua essência, relacionado com formas alterna-
tivas de tratamento de informações. A abordagem tradicional de dados, desenvolvida
ao longo dos últimos 20-30 anos, foi um instrumento de extrema utilidade na for-
matação de estruturas capazes de serem implantadas e entendidas pelos gerenciadores
de bancos de dados. Com variados estilos, essa abordagem sempre primou pela re-
presentação de estruturas que melhor se ajustassem às características transacionais dos
processamentos de então. Na realidade, sempre foram boas opções para o sistema de
crédito/débito, de folha de pagamento ou o de ordens de compras e pedidos. Esses
sistemas existem ainda hoje e constituem a camada básica e essencial de processos
operacionais das empresas, quer estejam implantados nos velhos e empoeirados sis-
temas legados, quer habitando os novos e não tão mais emergentes ERP (Enterprise
Resource Planning). Com o desenvolvimento de outras necessidades, alavancadas por
aspectos de competitividade e busca de diferenciais de negócios e consequente to-
mada de decisão, esses modelos se mostraram inadequados. As suas características de
pulverização de informações (campos) por estruturas diferentes (tabelas), motivadas
pelos rigores das regras de normalização de dados (seis regras de distribuição semân-
tica de dados por entre tabelas) se mostraram, desde o início, imperfeitos para os
processamentos demandados pela ótica dimensional.

96
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

MODELAGEM DIMENSIONAL DE DADOS – INTRODUÇÃO


O que significa essa visão dimensional? No fundo, a estrutura dimensional mo-
difica a ordem de distribuição de campos por entre as tabelas, permitindo uma formata-
ção estrutural, mais voltada para muitos pontos de entradas específicos (as chamadas
dimensões) e menos para os dados granulares em si (os chamados fatos). Isso significa
que, numa estrutura dimensional, os dados estarão em uma forma quase estelar, em que
várias tabelas de entradas estarão se relacionando com algumas (poucas) tabelas de infor-
mações, criando uma notação mais sintética, legível e objetiva. O modelo dimensional
oferece, clara e diretamente, os elementos de que se precisa para buscar as informações
(“fato”) via dimensões de referências, diferindo da malha relacional, ou de rede, próprias
dos modelos anteriores, nos quais não existem estruturas específicas de entrada.
Observe o modelo da Figura 5.1. O modelo representado é um clássico de um
sistema de vendas a varejo. As principais entidades são: LOJA, que emite várias NOTAS
FISCAIS, cada qual com vários ITENS e cada ITEM associado a um PRODUTO.
Além disso, existe uma PROMOÇÃO, associada a um período de tempo. São relacio-
namentos tipicamente 1:N. Além disso, o modelo mostra a entidade ESTOQUE, que
representa a resolução do relacionamento M u N entre LOJA e PRODUTO, e a figura
do ATENDENTE daquela venda específica.

Figura 5.1
Exemplo de modelo de entidades e relacionamentos.

Observe agora o mesmo modelo, na forma dimensional, na Figura 5.2. Nesse


modelo temos uma tabela fato e seis tabelas dimensão (tempo, produto, loja, promoção,
atendente e nota fiscal). A tabela fato, chamada de vendas, representa as vendas de um
PRODUTO, em um tempo (digamos DIA) feito no âmbito de uma PROMOÇÃO,
numa LOJA, realizada por um atendente e registrada numa nota fiscal. Observe que a
tabela fato relativa a vendas tem como métricas desejadas somente os campos quanti-

97
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

dade vendida e valor em reais, que, na realidade, eram os dados do item da nota fiscal.
Outra tabela fato surgiu também para registrar os aspectos de estoque, visando à reso-
lução de outro domínio. Essa segunda tabela fato também se relaciona com algumas das
dimensões já identificadas para a primeira (tempo, loja e produto) e registra a quantida-
de em estoque, como métrica principal.

Figura 5.2
Exemplo de modelo dimensional equivalente ao modelo E/R da Figura 5.1.
Dessa forma, observe que o que houve, no fundo, foi um remanejamento de
dados e tabelas, criando-se entradas de acesso (as tabelas dimensão) e algumas tabelas
que contêm os fatos relevantes (tabelas fato), como vendas e estoque. Isso significa que
posso, agora, acessar as minhas métricas desejadas, entrando e combinando atributos
das diversas dimensões, de forma muito mais objetiva e direta, sem grandes percursos
de navegação. As tabelas fato são normalmente associadas a documentos originados
de transações de negócios. Por exemplo, são potencialmente candidatos à tabela fato:
pedidos, despachos, pagamentos, transações bancárias, reservas, admissões em hospital,
hotel etc.
Esse é o conceito de modelos dimensionais, que, por sinal, data de muito tem-
po, havendo registros de suas ideias iniciais muito antes da formalização dos modelos
de entidades e relacionamentos, que serviram de base para os modelos transacionais.

98
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

Dessa forma, podemos entender que a criação de uma tabela fato com suas dimensões
circundantes forma uma estrutura que atende a certos objetivos organizacionais, cen-
trados na presença das métricas ali definidas. Também posso entender que, na medida
das necessidades dos requisitos, posso criar outros esquemas dimensionais (tabela fato
com as suas dimensões) e que o conjunto desses esquemas, relacionados por dimen-
sões comuns, forma a minha estrutura dimensional maior. Ou seja, o conceito de
repositório informacional (data warehouses e data marts) pode ser visto, na realidade,
como uma rede de esquemas dimensionais, entrelaçados por dimensões comuns com-
patíveis dentro dos diversos assuntos modelados. A divisão de um grande conjunto
de dados em esquemas contendo uma tabela fato circundada por algumas dimensões
é até explicada pela chamada cognitive bandwidth, ou seja, a capacidade inata do ser
humano de entender a complexidade das coisas pela divisão em partes menores. Há
experiências que apontam para a ideia de que uma tabela fato é normalmente circun-
dada por um número que varia entre sete e mais ou menos duas dimensões, que seria
exatamente a capacidade da banda cognitiva de que dispomos para reter informações.
Também a colocação das dimensões em modelos hierárquicos é considerada uma
forma facilitadora de retenção e entendimento de informações, conforme observado
por Hebert Simon, vencedor de Prêmio Nobel, em seus trabalhos sobre psicologia
cognitiva. Quanto mais não fosse, a hierarquia está presente em diversas manifestações
de registros naturais de informação, como os capítulos de um livro, os estados de um
país etc. Em capítulos seguintes estudaremos a modelagem dimensional de dados com
maior detalhe.
A Tabela 5.1 sintetiza as diferenças entre os modelos relacional e dimensional.

Tabela 5.1
COMPARAÇÃO ENTRE MODELO RELACIONAL (E/R)
E MODELO DIMENSIONAL

MODELO DIMENSIONAL MODELO RELACIONAL (E/R)


Padrão de estrutura mais fácil e intuitiva Modelo mais complexo
Ênfase nos bancos de dados
Anterior ao MER – anos 1960
relacionais – anos 1970
Tabelas que representam da-
Tabelas fato e tabelas dimensão
dos e relacionamentos
Todas as tabelas são nor-
Tabelas fato são o núcleo – normalizadas
malmente normalizadas
As tabelas são indistinta-
Tabelas dimensão são os pontos de entrada e de filtro mente acessadas, não sen-
inicial e podem ser desnormalizadas do caracterizados pontos de
entradas
Maior dificuldade de join
Modelo mais facilmente joined pelo número maior de ta-
belas
Maior dificuldade de leitura
Leitura mais fácil do modelo por usuários não especiali-
pelo usuário não especiali-
zados
zado

99
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Nas Figuras 5.3 a 5.7, são mostrados, respectivamente, os conceitos de ponto,


plano (Slicing), cubo (Dicing), indicadores e rotação ou pivotamento, para um mode-
lo dimensional com as dimensões produto, tempo e região. O valor pontual (ponto)
representa a interseção de valores (fato) com relação aos três eixos (dimensões). Qual
a quantidade de venda do PRODUTO P1, no DIA D1 na CIDADE C1? Seria uma
venda granular registrada no modelo dimensional, como, por exemplo, quanto de suco
de laranja, embalagem de 1 litro, foi vendido na cidade de São Paulo, digamos, no dia 24
de julho de 2009. O exemplo mostra somente três dimensões (visão de cubo), por ques-
tões óbvias de percepção, mas um modelo pode ser visto como uma representação de
n dimensões (visão de hipercubo ou hiperespaço). O plano (Slicing) mostra o conceito
de plano ou fatia, evidenciando, por exemplo, os produtos P1 a Pn que foram vendidos
na cidade C1, no período compreendido entre os dias D1 e Dn. Seria, por exemplo,
a materialização de quanto do produto da categoria suco (agrega os produtos de P1 a
Pn, daquela categoria), vendido na cidade de São Paulo, no mês de junho (envolve a
agregação dos dias 1 a 30).

Figura 5.3
Representação dimensional – valor pontual.

100
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

Figura 5.4
Representação dimensional – valores em planos. Fatias (slicing).

Figura 5.5
Representação dimensional – valores em cubos (dicing).

101
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 5.6
Representação dimensional – valores na tabela fato – métricas.

Figura 5.7
Representação dimensional – rotação de planos.

102
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

O conceito de dicing (cubos) mostra os produtos entre P1 e Pn, vendidos nas


cidades entre C1 e Cn, no período compreendido entre os dias D1 e Dn. Seria a mate-
rialização de quanto de produtos da categoria suco foi vendido no estado de São Paulo
(compreende o agregado de todas as cidades do estado), no mês de junho (compreende
o agregado de todos os dias daquele mês).
O conceito de indicadores, na Figura 5.6, mostra que em um ponto de inter-
seção do modelo podem existir vários indicadores, normalmente numéricos, relativos
àquela combinação de dimensões. O exemplo mostra um fato contendo três valores:
unidades vendidas, valor de venda e valor de custo. Esses valores estariam dentro da
tabela fato.
O conceito de rotação de planos ou pivotamento está relacionado com a mu-
dança dos eixos das dimensões, permitindo transformações na visualização dos dados.
Lembre-se de que a visualização, normalmente planar, exigirá pivotamento (rotação)
para que as diversas dimensões possam ser mostradas. Por exemplo, de início, posso
mostrar, como numa planilha bidimensional, os valores relativos a produto e cidade,
com a dimensão dia sendo fixada. Depois, por pivotamento, posso fixar cidade e
mostrar os valores dos produtos ao longo dos dias (tempo). E, assim sucessivamente,
posso realizar os pivotamentos que melhor se ajustam na dinâmica do fornecimento
das informações requeridas. O conceito de cubo é muito usado como sinônimo de
data mart ou da parte que é extraída para atender às necessidades de certas aplicações,
e representa um conjunto de dados de dimensões e de fatos, extraídos de um universo
maior, objetivando o atendimento específico de necessidades. Exatamente por ser um
sólido de três dimensões é usado como elemento de simbolismo do modelo dimen-
sional. A Figura 5.7 ilustra o conceito de rotação de planos ou pivotamento.

Drill-down e Roll-up
Outros conceitos de operadores dimensionais, além do pivotamento, estão relacio-
nados com o nível de granularidade dos dados armazenados. São os conceitos de drill-down
e roll up, às vezes também conhecido como drill-up. Por exemplo, observe o modelo dimen-
sional da Figura 5.8. Nesse caso, as informações relacionadas à dimensão geografia estão
estruturadas segundo uma hierarquia: PAÍSoREGIÃOoESTADOoCIDADEoLOJA,
e as relacionadas à dimensão tempo estão estruturadas segundo uma hierarquia de
SEMESTREoMÊSoDIA. O conceito de drill -down está diretamente relacionado com
o fato de sairmos de um nível mais alto da hierarquia e buscarmos informações mais
detalhadas, ou seja, em níveis menores. Por exemplo, se você já obteve as informações de
vendas no nível de ESTADO e agora deseja o detalhe por CIDADES, está solicitando
um DRILL-DOWN. O inverso é o conceito de ROLL-UP. Assim, se você está com as
informações de vendas em nível de DIA e deseja uma posição, digamos, consolidada em
nível de MÊS, está solicitando um ROLL-UP. Todas as ferramentas OLAP estão aptas
a executar esses dois operadores, que são absolutamente básicos dentro do conceito de
manipulação dimensional de data warehouse.

103
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 5.8
Representação dos principais comandos dimensionais – I.

Drill-across
Observe novamente a Figura 5.8. O conceito de DRILL-ACROSS está re-
lacionado com a ideia de você poder “pular” de um esquema para outro, desde que
ambos tenham algumas dimensões em conformidade, ou seja, as mesmas dimensões
estão compartilhadas. Nesse caso, você estaria comparando informações de VEN-
DAS e ENTREGAS de forma coerente, pois as dimensões são comuns. O comando
DRILL-ACROSS permitiria o tratamento dessas informações que, embora correla-
cionadas, estão em estruturas separadas, porém unidas por algumas dimensões coe-
rentes. É como se fosse uma espécie de join dimensional, entre estruturas relacionadas.
O join relacional permite que você busque informações em outra tabela, a partir de
campos comuns, ou seja, do pareamento entre as chaves primárias e estrangeiras. O
comando DRILL-ACROSS faz o equivalente entre esquemas dimensionais, quando
unidos por dimensões compatíveis.

Drill-through
O conceito de DRILL-THROUGH está relacionado com a ideia de você
desejar uma informação em nível de detalhe menor do que aquele colocado na ta-
bela fato e permitido pela sua granularidade. Suponha que você tenha armazenado
na tabela fato sobre VENDAS as informações em nível de granularidade de produto
por dia e por loja. Isso significa que o menor nível que se pode alcançar naquela

104
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

estrutura é a informação sobre produto. Mas é claro que você tem as informações
em nível de nota fiscal, que foram totalizadas em produto, dia e loja para dar origem
ao fato granular armazenado. Acontece que essa informação mais detalhada do que
a granularidade com que foi armazenada a tabela fato está, por exemplo, em outro
arquivo ou ambiente diferente do DW/DM. Poderia ser, por exemplo, o próprio sis-
tema transacional de origem, caso houvesse compatibilidade de software entre os dois
ambientes ou um armazenamento do tipo ODS (Operational Data Store). O DRILL-
THROUGH seria essa operação que permite uma busca de informações além do
nível de granularidade existente na estrutura dimensional. Nesse exemplo, você es-
taria acessando as notas fiscais e os itens que deram origem (por agregação) ao fato
armazenado em cada linha da tabela fato. É como se fosse um drill-down, só que com
a propriedade de buscar o detalhe em outra estrutura, além do esquema dimensional.
A Figura 5.9 ilustra o conceito explicado.

Figura 5.9
Representação dos principais comandos dimensionais – II.

Outros comandos
Algumas ferramentas possuem um conjunto muito variado de operadores di-
mensionais, estatísticos e temporais. As mais comuns são RANKING (classifica de-
terminada informação baseada nos n melhores indicadores), LAST-WEEK (mostra
os valores relacionados à semana anterior, tendo como referência a semana atual) ou
PRIOR-WEEK (somente os valores relacionados ao período compreendido nos últi-
mos sete dias, tendo como referência a data atual), YEAR-TO-DATE (compreendendo
o período do ano de referência até a data de hoje) etc.

105
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Os comandos dimensionais, na realidade, são produzidos pelos comandos SQL


ou SQL-like, que operam na retaguarda. Quando um usuário realiza um drill-down,
ele está, no fundo, solicitando um SQL, que irá modificar o seu GROUP BY, ob-
tendo o dado na granularidade solicitada. Acontece que, dependendo das solicitações
efetuadas, as instruções SQL se tornarão extremamente complexas para serem codi-
ficadas, por exemplo, num único comando. Hoje, muitas ferramentas se incumbem
de traduzir as requisições de um comando OLAP em um ou mais comandos SQL.
De qualquer maneira, os administradores desses ambientes de data warehouse e data
marts deverão desenvolver um bom skill em codificação SQL, para eventuais análises
de problemas ou ajudar em codificações complexas, além de ter grande utilidade nos
processos de preparação e carga dos dados. Alguns produtos de mercado, hoje, já pos-
suem uma espécie de dialeto SQL voltado para tratamentos dimensionais. O padrão
MDX é um deles. Apoiado pela Microsoft, ele objetiva a definição de uma linguagem
SQL-like, voltada para tratamentos dimensionais. O próprio padrão ofioficial
cial da lingua-
gem SQL evolui nessa direção, sensível ao crescimento dos projetos de DW/DM em
ambientes relacionais. As principais extensões da linguagem, visando às facilidades
de codificação de comandos complexos, vieram pelo aumento da ortogonalidade da
linguagem, com as subconsultas escalares e de conjunto. Nesse caso, tornou-se pos-
sível a construção de subcomandos com produtos escalares diretamente na projeção
do comando, bem como a construção de subcomandos com resultados conjuntivos
na cláusula from. Além disso, existe uma clara evolução também no arsenal de funções
internas (built-in) permitindo a obtenção direta de valores que, de outra forma, exi-
giriam complexos comandos separados para a sua obtenção. Alguns exemplos dessas
funções internas são discutidos a seguir:
 Ranking. Define uma classificação em função dos valores de uma coluna. O
exemplo ilustra o conceito:
SELECT NOME, DATA_ADMISSÃO as TEMPO-SERVIÇO, RANK (TEM-
PO_SERVIÇO) as SENIORIDADE FROM EMPREGADOS ORDER BY NOME.
O resultado seria:
NOME TEMPO-SERVIÇO SENIORIDADE
AB 199703 2
AC 199703 2
AD 199804 3

 Soma acumulativa. Acumula a soma de um conjunto ordenado de linhas,


oferecendo o valor corrente em nível de cada linha. O exemplo ilustra:
SELECT , …CSUM (VENDA, ITEM,DATA)… O resultado seria algo como:
DATA VENDA_ACUMULADA
AB D1 20
AB D2 35
AB D3 38
AC D1 25

106
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

 Média móvel. Calcula a média móvel nos últimos x dias especificados. O


exemplo ilustra:
SELECT MAVG (VALOR_FECHAMENTO, 30, DIA). O resultado seria:A
VALOR_FECHAMENTO MÉDIA
D1 10,50 10,32
D2 10,11 10,45
D3 10,56 10,48

Nesse exemplo, ele está fazendo a média dos valores nos últimos 30 dias.
 Soma móvel. É baseada no mesmo princípio da anterior, com a sintaxe
MSUM.
 Diferença móvel. Calcula a diferença entre valores em um período de tempo
especificado.
Por exemplo, o comando:
SELECT MDIFF (VOLUME_VENDA, 1,DIA) daria o seguinte resultado:
VD1 10 ?
D2 15 5
D3 23 8

 Quantile. São funções que calculam a distribuição de valores por faixas defi-
nidas dentro do conjunto (decis para 10 partes, percentis para 100 partes, tercis
para três partes etc.). O exemplo ilustra o conceito:
SELECT ...VALOR_LUCRO, QUANTILE (10,VALOR_LUCRO) AS DE-
CIL…

DIFERENÇA ENTRE DADOS OPERACIONAIS E DADOS


INFORMACIONAIS
A Tabela 5.2 mostra as principais diferenças entre os dados de natureza opera-
cional e informacional. Esses dois tipos básicos de dados possuem objetivos diferentes,
e basicamente estão relacionados, respectivamente, aos sistemas tradicionais de infor-
mações implementados sobre bases de dados e aos sistemas de BI implementados sobre
data warehouse ou data marts.

107
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Tabela 5.2
COMPARAÇÃO ENTRE DADOS DE NATUREZA OPERACIONAL E
INFORMACIONAL
CARACTERÍSTICAS DADOS OPERACIONAIS DADOS INFORMACIONAIS
Valores sumarizados, calculados, in-
1. Conteúdo Valores correntes
tegrados de várias fontes
2. Organização dos Por aplicação/sistema de in-
Por assuntos/negócios
dados formação
3. Natureza dos Estática até o refreshment dos da-
Dinâmica
dados dos, de tempos em tempos
4. Formato das Relacional, próprio para com- Dimensional, simplificado, próprio
estruturas putação transacional para atividades analíticas
5. Atualização dos Acesso granular ou agregado, nor-
Atualização campo a campo
dados malmente sem update direto
Altamente estruturado em Estruturado em fatos e dimensões,
6. Uso tabelas, processamento re- com processamento analítico/predi-
petitivo tivo
7. Tempo de Otimizado para faixas abai- Análises mais complexas, com tem-
resposta xo de 1 seg pos de respostas maiores

O conceito de business intelligence, além das características dimensionais, ex-


plicadas anteriormente, também está centrado nas estruturas de seus depósitos infor-
macionais.

DATA WAREHOUSE E DATA MART


O conceito de BI pode ser entendido, numa das suas vertentes, como direta-
mente relacionado ao apoio e ao subsídio aos processos de tomada de decisão baseados
em dados trabalhados especificamente para a busca de vantagens competitivas. Os dados
que habitam os tradicionais sistemas legados, normalmente implementados nos ERP
(Enterprise Resource Planning), ou pacotes integrados de gestão que constituem a
base dos processos de negócios das empresas, estão formatados e estruturados da forma
transacional, dificultando, dessa maneira, o seu tratamento informacional, conforme já
discutido anteriormente. O conceito de BI, assim, deve ser entendido como o processo
de desenvolvimento que objetiva implementar:
 Estruturas especiais de armazenamento de informações como data wa-
rehouse (DW), data marts (DM) e ODS (Operational Data Store), com
o objetivo de montar uma base de recursos informacionais capaz de
sustentar a camada de inteligência da empresa e possível de ser aplicada
aos seus negócios, como elementos diferenciais e competitivos. Junta-
mente com o conceito de DW, DM e ODS, o conceito de BI contempla
também o conjunto de ferramentas de desenvolvimento de aplicações e
de ferramentas ETC (extração, tratamento e carga), fundamentais para a
transformação do recurso de dados transacional em informacional. En-
quanto DW e DM se referem a estruturas (relacionais ou dimensionais)

108
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

de dados, remodeladas com o objetivo de prover análises diferenciais, o


conceito de ODS, por sua vez, está relacionado com o armazenamento e
tratamento de dados operacionais, de forma também consolidada, porém
sem características dimensionais e voltado para a carga e a formação das
duas anteriores. Ou seja: o ODS pode ser entendido como um cadastro
consolidador de informações, porém mantidas ainda as características
de granularidade e de estruturação não dimensional, originadas dos sis-
temas legados e ERP. O conceito de ODS nasceu como uma solução
intermediária entre os muitos arquivos e dados espalhados pela empresa,
que careciam de certa uniformização, e a proposta final de DW e DM. O
ODS, além de ser a metade do caminho entre o legado e o DW, também
oferece informações importantes do ponto de vista decisório, devido à
sua característica de consolidação e integração de várias fontes de dados.
Hoje, os conceitos de MDM (Master Data Management), discutidos no
capítulo de governança e qualidade de dados, endereçam, de certa forma,
soluções para os problemas para os quais os ODS foram planejados: a
consolidação de dados mestres da empresa.
 Aplicações especiais de tratamento desses dados, como OLAP e data
mining. O termo OLAP (On-Line Analytical Processing), hoje muito
difundido, traduzido para processamento analítico on-line, representa
essa característica de trabalhar os dados com operadores dimensionais,
possibilitando uma forma múltipla e combinada de análise, conforme
visto nos comandos explicados anteriormente. O conceito de data mi-
ning, por outro lado, está mais relacionado com os processos de análise
de inferência do que com os de análise dimensional de dados e repre-
senta uma forma de busca de informação baseada em algoritmos que
objetivam o reconhecimento de padrões escondidos nos dados e não
necessariamente revelados pelas outras abordagens analíticas, como o
OLAP.
A Figura 5.10 mostra esquematicamente a arquitetura chamada de data wa-
rehouse corporativo. Nessa arquitetura, os dados são coletados das fontes opera-
cionais e trabalhados numa camada intermediária de tratamento e armazenamento
de dados denominada Staging. Nessa camada, os dados são submetidos a um trata-
mento de limpeza, combinação, acertos e batimentos (matches), que serão a fonte de
carga do DW corporativo. Um BD, denominado ODS (Operational Data Store),
poderá ser criado nessa camada, visando a formar um depósito intermediário, pre-
paratório para a carga do DW. Esse depósito tem características relacionais e poderá
ser usado para acessos de informações integradas sobre certo assunto, oferecendo
normalmente excelente tempo de resposta. Nessa arquitetura, o DW corporati-
vo fornecerá os insumos para a carga dos data marts departamentais, por assun-
tos ou linhas de negócios, numa abordagem tipicamente top-down. As funções de

109
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

ETC (extração, transformação e carga), responsável pelas ações de coleta, limpeza,


preparação e carga desses depósitos de informações, estão representadas pela cama-
da de Staging. Os processos de mining, presentes no canto superior do framework,
trabalharão sobre um extrato de dados especialmente preparado para essa forma de
tratamento com foco mais estatístico. Os dados em qualquer desses depósitos po-
derão ser analisados pelas ferramentas diversas disponíveis, que permitem: geração
de relatórios ou cubos com análises dimensionais OLAP ou ferramentas de mining,
com aplicações específicas em diversos domínios.

Figura 5.10
Data warehouse corporativo.

A Figura 5.11 mostra a alternativa arquitetural de construção de data warehouse,


caracterizada pela criação inicial dos data marts integrados, que serão criados separada-
mente a partir dos dados operacionais trabalhados pela camada de Staging. Nessa arqui-
tetura, os data marts serão criados de forma integrada, observando-se a conformidade
entre as dimensões e a coerência das suas métricas. Essa forma, bottom-up, permite que
o data warehouse corporativo seja formado de forma distribuída através da criação dos
data marts separadamente. As demais considerações da Figura 5.10 se aplicam a essa
figura também.

110
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

Figura 5.11
Data warehouse por integração de data marts dependentes.

A Figura 5.12 mostra uma variante da arquitetura anterior, porém agora com
a introdução de alguns conceitos do BI2. O BI2 contemplará, além dos dados tradi-
cionais, também o tratamento e análise dos DNE (Dados Não Estruturados), envol-
vendo e-mails, relatórios, resultados, laudos, imagens etc. Haverá também uma forte
concentração na definição e no uso dos metadados, os dados sobre os dados, que
deverão estar presentes nas ações de governança de dados, tema dentro do espectro
que definimos como BI2. Na parte de consolidação e integração de dados, o BI2 se
encontra com os conceitos de MDM (Master Data Management). A disponibilização
de ferramentas da família EII (Entreprise Information Integration) potencializará os
conceitos de DW/DM virtuais, vindo ao encontro da ordem empresarial das RTE
(Real Time Enterprises), empresas que demandam uma latência menor entre os fatos
e as informações derivadas deles. Seria um bypass, com todos os seus prós e contras,
sobre a camada do ETC, produzindo em tempo real visões dimensionais obtidas dire-
tamente das fontes transacionais de dados. Também a parte de mining, hoje presente,
deverá ter foco com ênfase estendida na análise de texto (text mining) ou de web
mining, dividida em análises via estrutura e relacionamento dos sites (structure mi-
ning), dos seus conteúdos (content mining) e a forma pela qual são usadas pelos seus
visitantes (usage mining).

111
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 5.12
Componentes de um ambiente de BI2 – novos temas envolvidos.

ABORDAGENS INICIAIS PARA PROJETOS DE DATA WAREHOUSE


E DATA MART
Os primeiros projetos de data warehouse caminharam pelas trilhas metodoló-
gicas originadas basicamente em duas fontes de inspiração: Bill Inmon e Ralph Kim-
ball. Esses dois gurus se constituíram, em meados dos anos 1990, nas referências mais
fortes em termos de projeto e construção de armazéns de dados e possuíam culinárias
ligeiramente diferentes. O primeiro, Bill Inmon, é considerado o pai do conceito de
data warehouse, e, hoje, via sua empresa Inmon Consulting Services, é um dos nomes
mais respeitados nas abordagens top-down, que pregam a construção completa desses
armazéns de informação. Estabelecido no meio de bancos de dados há muito tempo,
Bill Inmon é autor de vários livros a respeito do assunto (tanto de BD quanto de data
warehouse), e iniciou na década de 1970 uma forte incursão aos conceitos de bancos de
dados aplicados aos sistemas de tomada de decisão que, segundo ele, seriam a saída para
resolver problemas de baixa liquidez de informação.
Por outro lado, Ralph Kimball tem uma origem diferente. Foi o inventor do
workstation star, um produto desenvolvido pela Xerox e que constituiu o primeiro pro-
duto comercial a usar os conceitos revolucionários de usabilidade por janelas (windows,
ícones e mouse). Posteriormente fundou uma companhia de software de bancos de

112
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

dados especializado em sistemas de data warehouse (Red Brick Systems) e hoje, fora
dela, é um dos mais famosos consultores independentes de data warehouse dos Estados
Unidos. É considerado o pai do conceito de star schema (esquema estrela), uma abor-
dagem de modelagem de dados que prioriza a estruturação de dados na forma dimen-
sional, fugindo da maneira normalizada e canônica originada dos preceitos relacionais.
É um dos nomes mais respeitados no círculo de BI, com forte influência nas abordagens
bottom-up. Paternidade à parte, essas duas referências metodológicas têm sabores ligeira-
mente diferentes, conforme discutido a seguir.

Abordagem de Bill Inmon


A abordagem de Inmon se concentrou inicialmente no estilo mais tradicional de
construção de bancos de dados, muito próximo daquele surgido nos primeiros projetos
de bancos de dados, nos quais se buscava uma forte integração entre todos os dados da
empresa que habitavam áreas funcionais diferentes. Isso seria representado num modelo
único, integrado e coeso, mas que por vezes se mostrou rígido e de difícil consecução. A
sua ênfase sempre foi um grande depósito central de informações empresariais tratadas,
limpas e integradas, construído inicialmente, e de onde outros depósitos secundários
(data marts ou mercados de dados) são originados e construídos.
O autor, hoje, apresenta uma nova proposta chamada DW2.0, na qual introduz
alguns conceitos que são trazidos no arco do BI2, como ênfase em metadados, dados
não estruturados, mas também sugere algumas ideias diferenciadas, como o armazena-
mento no DW ser feito de acordo com a idade dos dados. Classifica o ciclo de vida dos
dados em interativos, integrados, quase in-line (near line) e separados (archival), de acordo
com o seu tempo de vida. Por exemplo, os dados com mais de cinco anos seriam ar-
mazenados na região archival, uma espécie de arquivo morto. Entre três e cinco anos,
ficariam na região near line, ou seja, próximo de uma disponibilidade quase imediata.
Os dados com idade entre horas e alguns meses ficariam na região Integrada do DW
(integrated). Os mais atuais, com maior probabilidade de consumo, ficariam na região
denominada interactive. Na esfera de metodologia para desenvolvimento de DW, In-
mon oferece uma visão mais próxima dos projetos em espirais, com implementações
menores, bem diferente do que sugeriam as suas proposições iniciais. Na realidade, vem
ao encontro de abordagens mais ágeis, definindo iterações de, no máximo, três meses
e forte prototipação. Também faz alerta para os aspectos, cada vez mais necessários, de
monitorar o ambiente do DW, nas suas diversas camadas, do ETC ao front-end, devido
aos volumes crescentes e à importância que os dados de BI desempenham hoje nas em-
presas. Os detalhes das novas propostas de Bill Inmon para DW estão no livro DW2.0
– The Architecture for the Next Generation of Data Warehousing, de Derek Strauss e Genia
Neushloss, editado em inglês pela Morgan Kauffman, em 2008.

ABORDAGEM DE RALPH KIMBALL – STAR SCHEMA


A abordagem de Ralph Kimball veio com um estilo mais simples e incremen-
tal. Diferentemente da abordagem anterior, a metodologia star schema aponta para
projetos de data marts separados, que deverão ser integrados na medida da sua evolu-
ção. O autor já rebatizou essa abordagem de supermarts. Os projetos serão menores,

113
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

independentes, focando áreas ou assuntos específicos e terão a sua conexão com o


passar do tempo, desde que mantida a compatibilidade dimensional entre chaves das
tabelas. Tem o mesmo sabor das abordagens de projetos de BD relacionais, recente-
mente aplicadas nas empresas com enfoque departamentalizado ou por assunto. Tem
como desvantagem a possibilidade de produzir diversos DM, sem uma perfeita coesão
entre eles, além de uma provável duplicação de esforços na fase de extração, prepara-
ção e carga dos dados.
A essência da abordagem de Kimball está na etapa de projeto dos DM. Centra-
da na modelagem dimensional, com o conceito de esquema estrela (star schema), essa
abordagem transforma os dados em tabelas fatos (nas quais se concentram os dados de
interesse, passíveis de manipulação numérica e estatística) e em tabelas dimensão (tabelas
satélites que possuem as chaves de entrada do modelo, além das informações descritivas
de cada dimensão).
A abordagem de Ralph Kimball (www.rkimball.com), como a outra, também
está sendo aplicada em vários projetos nos Estados Unidos, com ênfase em grandes
empresas de varejo e de utilidade pública. Possui diversas referências sobre o assunto,
indispensáveis a quem está envolvido com projetos dessa natureza.
É fácil observar que essas duas vertentes não são necessariamente excludentes,
embora representem (ou representassem?) correntes ligeiramente diferenciadas, do pon-
to de vista de início do projeto. Em uma, o data warehouse, segundo Inmon, deve(ria)
ser um depósito central devidamente preparado a partir dos dados operacionais. E dele
deveriam nascer os data marts. Com o amadurecimento dessas abordagens pelas reais
necessidades de mercado, Inmon hoje incorpora na sua metodologia original os concei-
tos de data mart, originados diretamente dos dados operacionais, desde que devidamen-
te orquestrados por um processo de alinhavo, que os integre sem rupturas.
A outra, de data mart, aceita a ideia de que esses bancos de dados informacionais
mais contextualizados possam ser derivados (de forma incremental) diretamente dos
dados operacionais, sem a presença necessária de grande depósito inicial que os origine.
De qualquer maneira, os métodos de projeto de Kimball podem ser plenamente uti-
lizados na metodologia de Inmon, desde que ajustados devidamente ao foco desejado.

CONVERGÊNCIA ATUAL DE ABORDAGENS


De início, como descrito, a construção de data warehouse pressupunha um pro-
jeto integrado, monolítico, no qual um modelo único contemplaria, com detalhes, todas
as informações “fato” e suas respectivas “dimensões”. Isso significava modelar grande
parte da empresa (ou a sua totalidade) em busca de informações gerenciais, numa abor-
dagem muito parecida com as gigantescas estratégias top-down, discutidas no início dos
anos 1970, quando os bancos de dados debutavam, no auge de sua adolescência. Depois
de pronto o grande depósito, seriam criados, a partir dele, os data marts ou mercados de
dados específicos para cada espaço de negócios da empresa.
Os projetos de data warehouse, elaborados nessa linhagem, começaram a demo-
rar mais do que o suportado pelas gerências reprimidas pela ausência crônica de infor-
mações para decidir. Além disso, começaram a abocanhar altas fatias de investimento,
sem retornos palpáveis em curto prazo. Era preciso fazer alguma coisa. Pensou-se, é cla-

114
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

ro, na imediata limitação dos escopos desses almoxarifados de dados, para contemplarem
somente algumas regiões negociais da empresa (com prioridade para cliente, marketing,
finanças etc.). Uma espécie de DW em menor escala e com escopo mais defi definido.
nido. Sur-
giram, assim, os DW de escopos limitados, rebatizados de data marts, ou seja, aconteceu
certa inversão de abordagem. Dessa forma, gradativamente se iria construindo o data
warehouse corporativo, a partir do somatório lógico e das integrações dimensionais dos
diversos data marts, agora factíveis em tempo e custo. Uma boa ideia? Sim e não. Sim,
pois um projeto de DM pode ser finalizado em 4-10 meses com custos mais viáveis,
enquanto os outros (DW monolítico) nunca eram terminados antes de três anos com
valores muitas vezes maiores. Por outro lado, essa abordagem pode apresentar riscos de
produção de ilhas de informações dimensionais.
Como era de se esperar, os propositores da estratégia monolítica estrilaram.
Vários papers foram publicados na mídia, comparando os data marts aos fast foods, que
saciam a fome momentaneamente, mas não satisfazem as necessidades básicas, im-
portantes para uma saúde duradoura. Os DW, por seu lado, representariam a refeição
completa e saudável, de alto valor nutricional/informacional. Hoje, ambas as propos-
tas atingiram um ponto de convergência e equilíbrio. Os data marts evolutivos, ou
super marts, como agora são chamados, são feitos de maneira a convergirem para um
framework, que, com certa visão prévia de conformidade de dimensões, os integrará à
medida que forem projetados. Os vendedores/construtores de data warehouse mono-
líticos, por seu lado, já atualizaram suas estratégias de venda e anexaram o termo data
mart à sua estratégia de venda de produtos e serviços. Como visto anteriormente, o
conceito de DW2.0, trazido por Inmon em 2009, já contempla projetos em espirais,
com entregas menores em curto espaço de tempo. Conclusão: a ideia prevalente é
que você começa a construir o seu data warehouse pelos primeiros data marts de-
mandados. Uma fase inicial que define a compatibilidade de dimensões dos data marts
planejados e alguns padrões de dados “fatos” são fatores fundamentais para minimizar
possíveis rupturas. Os outros, a seguir, deverão ser integrados, mantida a conformidade
entre as dimensões. Isso, é claro, pode não ser facilmente atingido, visto não haver
consenso entre todos os usuários da empresa sobre os fatos e dimensões já existentes.
Esse é o risco da integração bottom-up, mas que provavelmente compensará quando
comparado com os ganhos de oferecer uma alternativa rápida e que atenda à dinâmica
de negócios da empresa. Hoje, os termos data warehouse e data marts evolutivos/in-
tegrados ou super marts são praticamente (quase) intercambiáveis, do ponto de vista
semântico, e todos se preparam para construir os seus depósitos de informações de
negócios, sejam eles chamados de data warehouse ou data marts/super marts. Neste
livro, estamos usando as siglas DW e DM indistintamente para designar esses depósitos
de dados, sendo que DW tem como premissa uma arquitetura mais abrangente, com
foco mais amplo, e DM significa o depósito particular em desenvolvimento, coerente
e plenamente acoplado no framework maior do DW corporativo. A Figura 5.13 ilus-
tra o conceito de data marts evolutivos, em que os aspectos de integração através de
dimensões conformes e a manutenção da compatibilidade das métricas são fatores
críticos de sucesso.

115
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 5.13
Estratégia de implementação gradativa de data marts.

CENÁRIOS DE APLICAÇÕES DE DATA WAREHOUSE E DATA


MARTS
Várias empresas, algumas no Brasil e muitas nos Estados Unidos e Europa, hoje
centralizam os seus processos de tomada de decisão nesses bancos de dados de carac-
terísticas dimensionais. Um dos maiores DW do planeta, sempre citado nas palestras e
seminários, é o da grande rede de varejo americana WalMart, cujo exemplo de aplicação
e de governança de dados foi descrito no capítulo anterior.
Outros segmentos da indústria usam aplicações de data warehouse. As áreas mais
fortes e normalmente as primeiras são as relacionadas com clientes. Isso, no fundo, tem
certa origem nos sistemas de database marketing que, de certa forma, podem ser con-
siderados como os precursores de data marts para clientes. Informações sobre vendas
de produtos por tipo, região, promoção, vendedores são exemplos clássicos. Outra área
de grande aplicação é a financeira, na qual marts de clientes, produtos bancários, agên-
cia etc. são sempre encontrados. Aplicações na área de seguradoras também são fortes
candidatas a BI, principalmente com relação às técnicas de data mining, adequadas ao
rastreamento de fraudes e análises de risco. Áreas de assinantes, como revistas e TV a
cabo, são também potencialmente clientes de BI, devido a aspectos de fidelização, pro-
moções, custos e índices de satisfação etc. As empresas de utilidades, após os movimen-
tos de desregulamentação de mercados, iniciaram um processo cuidadoso de melhor
conhecer os seus clientes, que sempre foram cativos, mas cujo processo de privatização
e de mudanças de regras transformou em ativo a ser melhor cuidado. Em vários países

116
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

onde os serviços de água e energia foram privatizados, já é possível a escolha das melho-
res ofertas desses produtos. Nessas empresas, o foco das aplicações em data warehouse
está voltado para o melhor conhecimento do cliente também. Os valores históricos de
consumo, por classe de consumidor, por região, por período são os mais óbvios numa
primeira abordagem. Indicadores de interrupções por período e por região apontam
para serviços de preservação de qualidade, indispensáveis em mercados competitivos.
Dados para acompanhamentos de obras, por tipo, região, período são outras possíveis
aplicações, com potencial para reduções de custos.
Uma famosa companhia de cartão de crédito com volume diário de muitos mi-
lhões de lançamentos de débitos e créditos se utiliza de um DW com essas informações
a fim de garimpar toda a riqueza contida nos subterrâneos dessas informações. Desses
dados, grande quantidade de correlações pode ser feita; o perfil socioeconômico dos
correntistas versus os gastos em Miami ou a preferência de destino de férias dos corren-
tistas que ganham mais de R$120 mil reais/ano e que pagaram passagem com o cartão.
Esses dados poderão estar à disposição de usuários ou parceiros do referido cartão em
busca dessas informações escondidas e que poderão definir novos rumos e estratégias de
marketing. Um DW dessa natureza, com grandes volumes diários, poderá atingir níveis
de armazenamento na casa de petabytes (1 quatrilhão de bytes ou 10**15), e alguns
projetos mais audaciosos já sinalizam armazéns de dados na casa de 10**18 bytes, estre-
ando o patamar dos exabytes.
Normalmente costuma-se pensar em data warehouse e data marts como depósitos
de informações internas da nossa empresa e com os quais tocaremos os nossos processos
negociais. Outra visão, porém, começa a aparecer em algumas empresas: a construção de
DW e DM para venda de informações. Uma grande empresa distribuidora de produ-
tos médico-farmacêuticos americana, com faturamento de US$3 bilhões/ano, que supre
centenas de hospitais e sistemas de saúde, resolveu também vender informações. Oferece
um sistema de acesso a informações, via web, espetado num gigantesco data warehouse,
de onde seus clientes e fornecedores buscam dados sobre compras de empresas e azeitam,
dessa forma, suas máquinas de comercialização. Outra empresa, gigante da área de semi-
condutores, também resolveu transformar informações em dólares. Vende, via seu data
warehouse, informações detalhadas de seus mais de 30.000 produtos diferentes, devida-
mente modeladas dimensionalmente e prontas para o consumo de interessados. Você deve
estar se perguntando sobre aspectos de segurança, confidencialidade etc. É claro que esses
parâmetros deverão ser considerados nos projetos de DW para vendas de informações, mas
o importante é não matar a ideia no nascedouro.

RESUMO
Observar os fatores críticos de sucesso em projetos de data warehouse e data
marts.
1) Ter um foco bem definido: é fundamental, em um projeto de data warehouse,
saber exatamente o que se deseja obter, mesmo que isso leve tempo para
ser garimpado. A falta de objetivo ou de um foco melhor definido sobre os
produtos a serem entregues é fator primordial para o insucesso de qualquer

117
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

projeto, e não seria diferente nos de data warehouse. Até porque, neles, os
produtos a serem obtidos são definidos por usuários que normalmente não
conseguem definir claramente quais são os seus problemas de negócios e o
que desejariam para solucioná-los. Cuidados especiais devem ser dirigidos
ao escopo do projeto, evitando-se a todo custo gigantismo de propostas ou,
por outro lado, projetos particularizados demais. Pense de forma mais ampla,
contemplando integrações futuras, caso seja possível, porém desenvolva o
projeto por partes, oferecendo, sempre em tempo razoável, produtos bem
definidos e plenamente acordados entre as partes. Os conceitos de BI ágil,
com projetos iterativos e incrementais, crescentes no segmento de inteligên-
cia de negócios, são discutidos no capítulo de BI2.
2) Conseguir um patrocinador forte: é fundamental que, em um projeto que
possa atingir áreas correlatas, haja uma presença forte do usuário, com poder
para definir pendências e dirimir dúvidas na esfera negocial. Converse bas-
tante com esse usuário, seduzindo-o pelo lado da viabilidade e da qualidade
e importância dos produtos a serem obtidos do DW. Faça-o participante
de todas as reuniões de trabalho do projeto e dê a ele a responsabilidade
de ser o grande patrocinador do projeto, com todos os ônus e bônus dessa
condição. Com o crescimento dos conceitos de GD (governança de dados),
a formulação de uma política de dados certamente influirá nesses aspectos de
estratégias, construção e patrocínios dos grandes depósitos de informações
da empresa.
3) Obter os dados necessários: antes de definir quaisquer compromissos com
os patrocinadores do projeto, verifique cuidadosamente a fonte dos dados.
Lembre-se de que um projeto de DW não produz dados, a não ser aqueles
obtidos in-flight por cálculos. É fundamental que o mapeamento das fontes
de dados seja feito com rigoroso critério de qualidade, certificando-se da na-
tureza dos dados, sua periodicidade de atualização, sua qualidade atual, seus
sistemas mantenedores e a perspectiva de duração daquela fonte de dados.
Lembre-se de que muitos sistemas legados estão sendo substituídos por ERP,
com modificações acentuadas nos dados (fontes, significado, objetivo etc.).
Considere a fonte dos dados e a sua acessibilidade. Que tipos de middleware
serão necessários para a coleta periódica dos dados e quais são os impactos?
Verifique se os dados históricos necessários no primeiro dia de vida do
DW existem armazenados na empresa. Observe sua qualidade, busque seus
leiautes e entenda a sua semântica. Depois de cuidadosamente verificadas
essas condições, assuma o compromisso pelo projeto. Os conceitos de quali-
dade de dados deverão entrar nesse ponto como elemento considerado fator
crítico de sucesso para o projeto, e as aplicações de BI terão mais sucesso
quanto maior a consideração da empresa sobre os dados como um ativo
organizacional forte.
4) Obter alto envolvimento dos usuários: faça a evangelização dos usuários do
projeto, mostrando claramente as condicionantes para o sucesso do projeto

118
ELSEVIER
C APÍTULO 5 I C ONCEITOS E STRUTURANTES DE BI

(o item anterior, por exemplo, é um deles). Motive-os pelos possíveis alcan-


ces vislumbrados pelo projeto e obtenha os compromissos necessários para a
remoção dos obstáculos naturais de um projeto dessa amplitude. Consolida-
ção de dados, acertos com relação a dimensões desejadas, granularidade re-
querida poderão demandar compromissos entre áreas envolvidas no projeto.
Mantenha-os aderidos.
5) Formar uma boa equipe no projeto: lembre-se de que um projeto de DW
é realizado por versões ou etapas e, de preferência, em várias iterações. Para
tal, mantenha uma equipe coesa, motivada, fortemente associada ao pro-
jeto, com condições para a realização de suas várias etapas. Tenha na equipe
pessoas com qualificação tecnológica suficiente para resolver problemas de
bancos de dados, comandos SQL agigantados, conexões entre máquinas de
protocolos diferentes, problemas de tempo de resposta etc. Pelo lado funcio-
nal, escolha analistas com grande conhecimento dos aplicativos que darão
origem aos dados do DW. Isso facilitará as eventuais modificações para a
captura de dados em sistemas ativos no âmbito transacional. Tenha sempre
um representante forte da área de negócios mais diretamente envolvida no
projeto em contato direto com a equipe do projeto, mimetizando os con-
ceitos de PO (Product Owner) das abordagens Scrum.
6) Definir uma boa arquitetura tecnológica: de nada adiantará um belo modelo
dimensional, cheio de tabelas fato e tabelas dimensão, bem balanceadas, se
o ferramental de suporte físico não condisser com as demandas do projeto.
Analise cuidadosamente a plataforma na qual habitará o SGBDR (sistema
gerenciador de bancos de dados relacional) ou dimensional, seu sistema ope-
racional básico, capacidade de processamento, tipos de índices, capacidade de
paralelização, sistemas de armazenamento etc. O mesmo para os middlewares
usados, caso demandados, e para a plataforma de desenvolvimento dos cubos
de informação e dos aplicativos. Lembre-se da “escalabilidade” de máquinas
e da maturidade geral dos produtos que sustentarão o projeto de DW. No
capítulo associado a projetos físicos de DW/DM exploraremos mais esse
tópico.
7) Criar e divulgar: disponibilizados os primeiros produtos do sistema de DW,
faça marketing. Anuncie no seu portal corporativo a disponibilidade de in-
formações gerenciais, ilustre os requisitos e as formas de solicitação de uso e
venda, principalmente para o público-alvo desses sistemas. Promova palestras
de demonstração, envolvendo a alta gerência e convença-a de que a relação
custo u benefício do projeto (até aquele ponto) foi favorável.
8) Acompanhar a sua utilização: acompanhe a utilização do produto que você
disponibilizou e analise os motivos de possíveis declínios no seu uso. Envol-
va os usuários patrocinadores e ouça, como um bom samaritano, todas as
possíveis imperfeições do projeto e, é claro, parta para corrigi-las. Observe
cuidadosamente os dados dormentes, ou seja, aqueles que têm tido pouca
utilização no contexto da empresa. São os dormant data.

119
CAPÍTULO 6

Conceitos correlatos de BI

GERÊNCIA DE CONHECIMENTO
A gerência de conhecimento (KMS – Knowledge Management Systems) objetiva
estabelecer uma aproximação integrada e colaborativa para capturar, criar, organizar,
disseminar e usar todos os ativos de informação de uma empresa. Enquanto a aborda-
gem de BI é mais compartimentada, objetiva e focada em estruturas definidas, a KMS
trabalha o ativo de informações, independentemente de sua forma, estrutura e domínio.
Nesse cenário, entram informações estruturais, documentos de fontes díspares, fatos,
opiniões e conhecimentos empíricos não formalmente documentados. Se fizéssemos
uma analogia dos conceitos de BI e KMS com um ambiente de condomínio, eu diria
que os balancetes formais, estruturados, de onde se obtêm os gastos por dimensões de
tempo, natureza, empregados etc. representam a abordagem de BI. O conjunto orga-
nizado de atas, circulares, orçamentos, notas fiscais, contratos de serviços, plantas de
reformas, opiniões e experiências dos diversos moradores e síndicos, ao longo da vida
do edifício, representaria a gerência/acervo de conhecimento.
O grande desafio das empresas, hoje, é definir modelos de taxonomia que contem-
plem os domínios de seus conhecimentos. Os modelos de maturidade de processos, como
MPS.BR (Melhoria de Processos do Software Brasileiro), já apontam a obrigatoriedade
de práticas visando à elaboração e à gerência desse novo insumo – os conhecimentos. As
empresas deverão mapear os seus principais domínios, baseados nas suas áreas de atuação,
e se preparar para, através deles, criar e disseminar os seus insumos de conhecimentos.
Por exemplo, uma empresa de software que fabrica um produto voltado para o controle
acadêmico possui um forte acervo de conhecimento nesse domínio, podendo modelá-lo
via estruturas de classes semânticas. Nela é perceptível uma forte experiência nessas classes
de domínios, regras de negócios e seus atributos e objetos correlatos como matrícula,
alunos, disciplinas, grades semestrais, regras do MEC etc. Rotinas já desenvolvidas e tes-
tadas sobre esses domínios poderão fazer parte do conhecimento da empresa e, o que
é melhor, permitir a sua disseminação e o seu compartilhamento, se juntando a uma
nova tendência, a engenharia de reutilização. Outra empresa, por exemplo, com forte
vocação para sistemas na área ambiental, também poderá elaborar modelos semânticos
e acumular conhecimentos na área específica. Dominará legislação ambiental, tipos de
manejos de áreas florestais, aspectos de conservação, conceitos de infrações e punições etc.
Esses modelos de conhecimentos serão traduzidos em repositórios que armazenarão es-
ses conceitos de domínios e, mais importante, as diversas experiências sobre eles, obtidos
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

nos diversos desenvolvimentos de sistemas, naquele domínio. Essas experiências deverão


ser coletadas em marcos do projeto de desenvolvimento, através de lições aprendidas e
relatos de colaboradores e gerentes. Um mecanismo de busca por palavras-chave ou um
sistema mais elaborado de BI poderá ser acoplado ao repositório, facilitando a busca e o
consumo equilibrado dos conhecimentos acumulados. Esse acervo de conhecimentos e a
sua utilização serão de fundamental importância nos próximos ciclos de desenvolvimento
de projetos da empresa, em que o conhecimento prévio sugerirá medições e práticas mais
recomendáveis, num ciclo virtuoso de reaproveitamento de conceitos, experiências e re-
utilização de códigos e artefatos.
Um fator importante associado com a gerência de conhecimento é essa possibi-
lidade de reaproveitar elementos como códigos e artefatos. Numa era em que as lingua-
gens orientadas a objetos oferecem mecanismos que favorecem esse reaproveitamento, as
empresas mais maduras deverão definir processos que permitam esse ganho substancial.
O MPS.BR possui dois processos definidos em níveis de maturidade mais elevados (nível
E, GRU – gerência de reutilização; e nível C, DRU – desenvolvimento para reutilização),
que apontam esses caminhos de reaproveitamento de elementos armazenados na forma
de ativos reutilizáveis e de ativos de domínios. Também define ações específicas sobre o
campo da gerência de conhecimento, dentro do espectro da gerência de recursos huma-
nos. A aplicação de técnicas de BI poderá favorecer esse resgate, através da definição de
modelos dimensionais que possibilitem a análise daquele ativo específico no conjunto de
projetos da empresa. A Figura 6.1 ilustra o conceito de gerência de conhecimento.

Figura 6.1
Visão geral de um sistema de gerência de conhecimento.

122
ELSEVIER
C APÍTULO 6 I C ONCEITOS C ORRELATOS DE BI

Nessa visão, haverá um repositório central de conhecimento corporativo abas-


tecido por relatos de experiências de pessoas em papéis desempenhados em projetos,
bem como por modelos, políticas, documentos, dados e medições de projetos, lições
aprendidas, opiniões, teorias, ideias e sugestões, conforme ilustrado na Figura 6.2.

Figura 6.2
Elementos formadores do conhecimento.

Esses conhecimentos serão armazenados através de modelos semânticos, com ta-


xonomias definidas de acordo com o business da empresa. O repositório deverá oferecer,
além das facilidades de entrada, uma camada de busca por categorias, palavras-chave, as-
suntos etc. A estrutura auxiliar de BI poderá entrar nessa composição como o elemento
que promoverá a transformação desses componentes de conhecimentos em produtos
para análise e distribuição, via ferramentas OLAP e de mining. Enquanto as aborda-
gens anteriores (informações e conhecimentos), de certa forma, olham para dentro da
empresa, uma terceira via observa o mundo exterior da empresa. É o conceito de CI
(competitive intelligence).

INTELIGÊNCIA COMPETITIVA
Em um mundo cada vez mais competitivo, todo processo de produção de-
manda um forte conhecimento da concorrência, dos clientes e dos fatores externos
que interferem na disputa de mercado, contemplando ameaças e oportunidades en-
volvidas. A importância desse conhecimento se faz mais presente se for considerado

123
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

que, no terceiro milênio, a organização vencedora será aquela que entender que o que
mantém uma organização competitiva é o seu ativo de conhecimento, representado
pelos seus colaboradores. O conhecimento dos clientes, de certa forma, é alcançado
por um dos braços do BI, através da análise de seu ciclo de vida, desde a sua captura
até a sua desistência.
A ideia básica de CI (competitive intelligence) é explorar o outro lado da trin-
cheira, obtendo informações detalhadas sobre os competidores e o mercado no qual
se guerreia pela opção do cliente. O desenvolvimento da inteligência competitiva se
baseia no fato de que, ao conhecer melhor o ambiente externo, amplia-se o diferen-
cial competitivo em relação às outras empresas, criando uma camada organizacional,
com apoio da tecnologia da informação, capaz de se apoiar no jogo de adversidades
do ambiente turbulento a que as organizações estão submetidas. O monitoramento
constante do ambiente competitivo e a sistemática busca, formatação, estruturação,
distribuição e análise de informações auxiliam na identificação de potenciais opor-
tunidades, desafios e ameaças do mercado, e suprem as organizações com informações
que devem ser utilizadas de forma inteligente, visando ao aumento da vantagem
competitiva.
Estratégia nada tem a ver com espiões de capa preta e quebradores de
códigos secretos e indecifráveis, como poderia sugerir. Até porque grande parte
das informações necessárias a essa guerra se encontra em páginas da internet,
manifestadas de forma indireta ou espontânea. A dificuldade está mais em focar
exatamente sobre o palheiro digital da grande rede para encontrar as agulhas que
espetarão nossos concorrentes. O manuseio está mais para mecanismos de busca,
rastreadores digitais, procuradores de catálogos e de palavras-chave do que para
ferramentas OLAP. Estas virão na fase subsequente, depois que as pilhas de in-
formações brutas sobre relatórios financeiros, press-releases, balancetes publicados,
patentes concedidas, marcas registradas, anais de conferências, registros públicos
etc. forem devidamente escovadas, limpas, classificadas, indexadas e armazenadas
em depósitos específicos de CI.
Podemos entender CI como um BI aplicado ao mundo fora de nossas fronteiras
empresariais, focado primariamente em informações textuais e factuais que dizem res-
peito aos movimentos do mercado e dos concorrentes, detectando as suas ameaças e
oportunidades. O conceito de CI se refere a um processo muito maior, que engloba
a obtenção e o tratamento de informações informais e não estruturadas advindas das
redes mantidas pelos sistemas de inteligência competitiva nas quais o BI entra como um
poderoso arsenal de ferramentas. A estratégia de CI passa pelas vizinhanças dos concei-
tos de KMS (gerência de conhecimento) e se acopla aos de mining, com a diferença
de que os sites de procura como Google,Yahoo, Microsoft apontarão o mapa da mina,
e os garimpadores inteligentes de textos e assuntos farão o papel dos espiões digitais da
nova economia.
De forma simplificada, a gestão do conhecimento está associada ao “que já se
sabe”. Corresponde às experiências, aos valores, à informação contextual e às opiniões

124
ELSEVIER
C APÍTULO 6 I C ONCEITOS C ORRELATOS DE BI

de especialistas, que permitem a avaliação e incorporação de novas ideias e de infor-


mação nas organizações. Muitas vezes, esses elementos estão contidos não apenas nos
documentos e repositórios, mas também nas rotinas organizacionais, nos processos, nas
práticas e normas, que, no fundo, compõem o acervo de conhecimentos.
A ideia de CI, por sua vez, está mais associada ao “que se precisa descobrir”
para ganhar competitividade. O objetivo é “usar e aplicar o que já se sabe para reduzir
a distância entre passado e futuro”. A gestão do conhecimento cria condições para que
o conhecimento seja criado, socializado e externalizado dentro da empresa, transfor-
mando-o de tácito em explícito. Já a inteligência competitiva está mais voltada para a
produção do conhecimento referente ao ambiente externo da empresa. Inteligência
competitiva e gestão do conhecimento são áreas que se acoplam e se complementam.
A Figura 6.3 ilustra o conceito de CI, com ênfase no monitoramento constante do
mercado visando à coleta de oportunidades e ameaças.

Figura 6.3
Conceito de Inteligência Competitiva.

Também o repositório central de IC, com informações insumos de CI, oriundo


de diversas fontes, como relatórios financeiros, balancetes, editais etc., está associado
às estruturas de BI como elemento de apoio à distribuição e análise dos dados de CI,

125
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

via técnicas de OLAP e de mining. A Figura 6.4 mostra um mapa mental, no qual se
delineia o ciclo de criação das estruturas de CI na empresa, com os detalhes:

Figura 6.4
Atividades de um processo de CI (Inteligência Competitiva).

1) Uma área de CI, composta por analistas de informações, profissionais com


alta capacidade inferencial, pesquisadores e administradores de redes de
contatos etc. Além disso, a equipe deverá ter técnicos em recuperação de
informação, com especializações em web e text mining.
2) A criação de um projeto de CI, que começaria pela definição dos KIT (Key
Intelligence Topics), que na essência seriam os assuntos sobre os quais se
procurariam os elementos de ameaças e oportunidades.
3) Um papel de analista de fontes externas e internas, visando à coleta e estru-
turação de informações competitivas.
4) Um papel de análise e interpretação dos dados, visando à busca de diferen-
cial competitivo.
5) Uma área dedicada à distribuição das informações para as áreas-chave da
empresa.

126
ELSEVIER
C APÍTULO 6 I C ONCEITOS C ORRELATOS DE BI

BSC: BALANCED SCORECARD


Com a adoção dessas diferentes manifestações de tecnologia e metodologia, no
bojo do ERM (Enterprise Relationship Management), mostrado na Figura 6.5, cabe
uma singela pergunta de arremate: como avaliar o efetivo retorno de tudo isso? Como
medir a capacidade de alavancar negócios e preparar a empresa para os novos tempos,
induzida por essas propostas tecnológicas recentemente introduzidas? Como saber do
retorno de investimentos em business intelligence ou da efetividade na adoção de novos
modelos de negócios visando a uma incursão nos mercados virtuais? Como garantir
que o CRM transformou-se em solução para melhor reter e agradar os nossos clientes?
Como assegurar que a implementação de um processo de melhoria de software trouxe
benefícios diretos ao meu negócio? Para obter respostas a essas perguntas, só nos resta
aferir as estratégias empresariais que motivaram a incorporação dessas melhorias nego-
ciais, respaldadas agora por aquelas camadas de tecnologia.

Figura 6.5
Visão geral – ERM (Enterprise Relationship Management).

Mas como alinhar essas estratégias empresariais e transformá-las em indicadores


numéricos que possam sugerir se a empresa se encontra no norte correto? Como criar

127
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

uma espécie de cockpit corporativo no qual a alta gerência encontre a velocidade do


vento, a altitude definida, a direção de rota e o nível de combustível já gasto e demanda-
do para esse novo voo empresarial que se deseja empreender? A resposta já se encontra
disponível na forma de mais uma camada de software cujo objetivo é a transformação
dessas estratégias em singelos indicadores, palatáveis para a alta gerência da empresa. Seu
nome: BSC (Balanced ScoreCard).
O BSC foi criado por Robert Kaplan e David Norton, em meados dos anos
1990, e tem uma diferença com relação aos outros processos de planejamento e avalia-
ção gerencial. Usa o conceito de balanceamento de quatro perspectivas fundamentais
para avaliação correta da empresa e de seus projetos: o retorno dos recursos financeiros
neles investidos; a satisfação dos clientes que consomem seus produtos e serviços; a agi-
lidade, a fluidez e a melhoria dos processos internos que os executam e controlam; e a
dimensão do recurso peopleware, com seus anseios, frustrações, evoluções e alinhamentos,
conforme a Figura 6.6.

Figura 6.6
Visão geral – BSC (Balanced ScoreCard).

128
ELSEVIER
C APÍTULO 6 I C ONCEITOS C ORRELATOS DE BI

A proposta também contempla a possibilidade de a empresa expandir essas pers-


pectivas e agregar outras, que de certa forma são correlacionadas com aquelas originais:
acionistas, sociedade, tecnologia etc., por exemplo, seriam expansões cabíveis. Para essas
perspectivas definidas, serão associados indicadores numéricos que deverão apontar ob-
jetivamente para o desempenho daquela dimensão específica. Por exemplo, os indica-
dores de treinamento efetuado para os projetos, o grau de envolvimento dos técnicos
e gerentes, e os índices de pesquisa de moral dos empregados são alguns elementos da
dimensão peopleware. Os índices de reclamação de clientes, taxa de produtos devolvi-
dos e graus de inadimplência seriam alguns da perspectiva “cliente”. Os investimentos
em mapeamento e melhorias de processos, via adoção de padrões de qualidade, por
exemplo, seriam marcadores da dimensão “processos internos”. Os clássicos indicadores
econômico-financeiros, como taxas de retorno, lucro e custo formariam alguns dos
marcadores da dimensão “financeira”.
A área de BI estará envolvida nos projetos de BSC, provendo os dados históricos
dos indicadores (planejado e realizado), obtidos do DW e marts das áreas funcionais da
empresa. Antes da carga, os usuários do BSC deverão estabelecer as relações de causa e
efeito entre os indicadores, tanto do ponto de vista estrutural (o indicador x influencia
e é influenciado por y, z e t) como quantitativo (o quanto o indicador x, se aumentado,
aumenta y?), o que permitirá ao sistema a realização das possíveis análises de perspectivas.
Um projeto de BSC não é trivial, exige grande envolvimento da alta gerência
e a presença fundamental de um patrocinador forte para se transformar em efetiva
abordagem de acompanhamento e medição de desempenho corporativo. Sem essas
considerações, o BSC se transformará em mais um componente do playground tec-
nológico que muitas empresas aprenderam a cultivar, sem retorno para seus negócios.
A Figura 6.7 mostra um exemplo de possível aplicação BSC, em que as dimensões
financeira, cliente, processos e aprendizados foram contextualizadas numa empresa de
desenvolvimento de software, que recentemente implantou um processo de melhoria,
introduzindo indicadores atrelados às dimensões gerenciais estratégicas. A cadeia de
indicadores, analisada de cima para baixo, mostra a influência de certas métricas de
engenharia de software (erros de requisitos e NC – não conformidades de qualidade
e teste) na redução de prazo de entrega, que, por sua vez, influenciam a satisfação do
cliente, que poderá aumentar a sua participação, chegando até ao aumento de receita
que finaliza com o aumento de rentabilidade. Os dados que abastecerão esses proces-
sos serão obtidos de repositórios de medidas, aplicadas a projetos e processos, o que
será discutido no Capítulo 11.

129
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 6.7
Exemplo de aplicação de BSC em ambiente de empresas de software.

À O exemplo da Figura 6.7 foi baseado no diagrama do curso de BSC,


Governança de TI através de BSC, sob responsabilidade de Ricardo Karsten,
da Beringer Consulting, ministrado em junho de 2006, em Belo Horizonte.

RESUMO

Embora não sejam diretamente associadas aos conceitos centrais de BI, as dis-
ciplinas correlatas como BSC e CI podem ser vistas como consumidoras de informa-
ções produzidas por aquela camada. Já a KMS (gerência de conhecimento) pode ser
interpretada como uma nova fronteira, além daquela de dados e de informações, em
que se concentram os conceitos de BI e entram nesse contexto como uma sinalização
dos novos domínios que surgirão e que permitirão a gerência desse novo elemento do
capital intelectual das empresas: o conhecimento.

130
CAPÍTULO 7

Data mining*

INTRODUÇÃO
Costumo dizer que a criatividade na produção de rótulos de informática ainda
vai causar problemas de conselho regional. Após a produção do conceito de filosofia de
dados, de administração de dados, de engenharia de informações, de arquitetura de dados,
outros tantos continuam sendo criados, sempre com o objetivo de melhor definir as
propostas de tratamento de dados e informações.
Os conceitos de garimpagem ou mineração de dados (data mining) estão rela-
cionados com a tendência (para aplicações comerciais) de buscar correlações escondidas
em altos volumes de dados, nem sempre evidentes, principalmente no tratamento coti-
diano dos sistemas de informações. Após a cristalização dos conceitos de data warehouse
e de data mart como forma de montagem de depósitos de dados, visando ao consumo
gerencial e voltada para tomadas de decisões, surgiu o conceito de garimpagem/mi-
neração de dados objetivando melhorar o uso desses arsenais de informação, em cujos
projetos normalmente é realizado alto investimento. É uma forma de capitalizar em
cima dessas informações, tentando descobrir padrões de comportamento de clientes
ou identificando, por exemplo, estilos de ações fraudulentas em cartões de crédito ou
em seguradoras. A mídia tem veiculado exemplos clássicos de data mining, como as
correlações entre produtos comprados na mesma cesta de supermercados (salsicha e
catchup, fraldas com cerveja ou... axé music com remédio para o fígado). O problema
dessa abordagem é que, além da possibilidade de garimpagem de relacionamentos inú-
teis, o número de correlações possíveis de serem obtidas é muito grande, o que impede
a análise de cada uma delas, exigindo, dessa forma, algoritmos inteligentes que possam
selecionar os padrões mais relevantes para certas aplicações.
O processo de mining tem certas diferenças com relação ao que vimos até agora,
nos capítulos relacionados a tratamento de informações. Enquanto as técnicas OLAP
objetivam trabalhar os dados existentes, buscando consolidações em vários níveis, traba-
lhando fatos em dimensões variadas, a técnica de mining busca algo mais que a interpre-
tação dos dados existentes. Ela visa, fundamentalmente, a realizar inferências, tentando
“adivinhar” possíveis fatos e correlações não explicitadas nas montanhas de dados de
um DW/DM.

* Este capítulo foi escrito em parceria com Fabia Russano Yazaki.


BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Mining, no fundo, também busca identificar atributos e indicadores capazes de


melhor definir uma situação específica. Por exemplo, em uma empresa de seguros, as
ferramentas OLAP responderiam a perguntas do tipo: qual é o valor médio de paga-
mentos de seguros de vida para não fumantes, na região sul do estado, em agosto de
1999? Já as ferramentas de mining seriam usadas para definir os melhores atributos de
clientes, capazes de ajudar como previsores de possíveis acidentes de automóvel. Em
uma empresa de serviços, as ferramentas OLAP responderiam, por exemplo, à pergunta:
qual é o valor médio de faturamento de clientes do tipo industrial, da área de alumínio,
nas regiões da Mantiqueira, comparando-se os anos de 1998 e 1999? Enquanto isso, as
ferramentas de mining serviriam para indicar quais atributos de clientes seriam impor-
tantes para ser considerados numa possível e indesejável quebra de fidelização (migra-
ção do cliente para o concorrente). Em uma empresa de crédito, as técnicas de OLAP
produziriam gráficos mostrando os percentuais comparativos de compras com cartões
de crédito roubados e válidos. As ferramentas de mining indicariam os padrões associa-
dos a certo comportamento fraudulento com cartões de crédito.
As ferramentas de mining estão muito mais relacionadas com tratamento espe-
cial da informação do que com estruturações de dados, embora um subconjunto de
dados extraídos do DW e DM provavelmente seja o alvo dessas análises mais sofisticadas.
A Figura 7.1 ilustra os três diferentes espaços de conhecimentos que podemos definir: o
espaço dos dados, relacionado com os bancos de dados; o espaço de informação analíti-
ca, referente aos data warehouses e data marts; e os espaços de influência e de variação,
relacionados com as aplicações de data mining, em que a influência de uma variável
sobre outras e as variações provocadas por sua influência estão entre os objetivos mais
importantes a serem buscados numa aplicação dessa natureza.

Figura 7.1
Visão geral dos diversos espaços de conhecimento.

132
ELSEVIER
C APÍTULO 7 I D ATA M INING

FATORES CRÍTICOS DE SUCESSO EM DATA MINING


O processo de mining é metodologicamente diferente do processo de pro-
jeto de DW/DM e deve ser embasado em alguns fatores considerados críticos.
Responda cuidadosamente às perguntas a seguir antes de se aventurar num projeto
de data mining:
 O entendimento do negócio e de seus objetivos e metas está claramente
definido?
 Você sabe exatamente de que necessita? Existem requerimento de análises
complexas, tendências escondidas, inferências, detecções de fraude, perfil de
comportamentos, análise de grau de fidelização, formulações e verificação
de hipóteses colocadas pela direção da empresa?
 A sua organização está preparada para usufruir das vantagens de data mi-
ning? Você não está sendo influenciado pela força da palavra “inteligência”,
tão vendida em produtos variados, desde anti-inflamatórios a elevadores, e
deseja isso para a sua empresa também?
 Você sabe com detalhe qual é o seu problema?
 Você definiu o grau de sua expectativa? Qual é o resultado desejado?
 Você tem os dados necessários, na granularidade desejada, no detalhe de-
mandado, na qualidade exigida? Caso negativo, você sabe onde e como esses
dados poderiam ser obtidos?
 Você tem bom usuário patrocinador do projeto de data mining?
 Você detém as técnicas necessárias e possui equipe com domínio de estatís-
tica, indicadores de negócios e business intelligence?
 Você sabe que um projeto de data mining poderá demandar, dependendo
do escopo, uma arquitetura de tecnologia relativamente robusta para realizar
certos tratamentos de dados?
 Você sabe que o data mining é, na realidade, mais do que um projeto iso-
lado e deve ser visto como um projeto contínuo de busca de inteligência e
inferência aplicada aos dados?
Se você respondeu às perguntas anteriores com muitos “sim”, está apto a entrar
em um projeto de data mining e conduzir a sua empresa para um ambiente de aplica-
ções mais elaboradas e complexas.

VISÃO GERAL DO PROCESSO DE DATA MINING


A Figura 7.2 mostra, numa visão geral, os passos principais de um projeto de data
mining. A figura mostra esquematicamente os grandes blocos de um projeto de data mi-
ning, com as fases de preparação, mineração, análise e aplicação.

133
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 7.2
Visão geral do processo de data mining.

Preparação
 Construir um banco de dados separado para os dados sujeitos ao mining.
 Coletar o dado que será garimpado. A fonte poderá ser DW/DM da em-
presa ou outros dados de natureza interna ou externa.
 Definir os metadados: entender a semântica dos campos documentando nú-
mero de campos, de colunas, de campos com valores nulos etc. Para cada
campo, definir nome, tipo, definição, descrição, fonte, unidade de medida,
valores únicos, periodicidade etc.
 Selecionar o subconjunto de dados a ser aplicado no projeto de mining. Al-
gumas ferramentas ajudam nesse processo, analisando a relevância de certos
dados e a sua provável efetividade no processo de mining.
 Atentar para a qualidade dos dados: os campos devem estar com valores cor-
retos, e o conjunto selecionado sem dados irrelevantes. Definir as regras para
campos ausentes, definindo valores defaults ou atribuindo valores estatísticos
como média, moda etc., para as informações ausentes.
 Definir para campos consolidados os critérios de reconciliação, como, por
exemplo, diversos endereços do mesmo cliente e resolver diferenças de vá-
rios nomes para a mesma entidade ou diferentes entidades com o mesmo
nome.
 Carregar o banco de dados para o processo de mining.

134
ELSEVIER
C APÍTULO 7 I D ATA M INING

Como diria a metáfora citada por Joseph Bigus, “é muito mais fácil garimpar
em uma mina que tenha boas estradas e pontes de acesso do que uma localizada no
meio da floresta, onde todas as ferramentas têm de ser transportadas por via aérea”.
Afinal de contas, ter acesso à matéria-prima faz parte dos custos operacionais e, por-
tanto, afeta a eficiência de um processo.
A preparação dos dados a serem utilizados em um projeto vai variar de acordo
com o algoritmo de mining escolhido. Dependendo desse algoritmo, os dados serão
formatados de maneiras diferentes. Esse processo pode envolver desde a limpeza dos
dados, incluindo campos omissos ou dados muito fora do normal – os outliers – até a
junção de variáveis ou linhas, combinação de campos e transformação de variáveis.
A seleção e a manipulação dos dados, em geral, devem ser feitas por alguém
que conheça bastante do assunto abordado e dos números em estudo. Esse processo
de preparação dos dados é essencial e crucial para o sucesso do data mining, e costuma
consumir mais de 50% do tempo e dos recursos destinados ao projeto.

Mineração
 Criar os modelos de data mining
 Definir amostras ou população.
 Selecionar dados para treinar o modelo.
 Definir a formatação requerida pelas ferramentas. Por exemplo: redes neu-
rais exigem os dados na forma dicotômica (sim/não) e árvores de decisão
demandam agrupamentos como bom, médio e ruim.
 Criar os previsores ou atributos-chave para a análise do negócio. Por exem-
plo: risco de crédito depende de valor-renda e histórico de pagamento.

Análise
Existem algumas técnicas básicas definidas para o processo de garimpagem de
dados. As principais são:
 Associação: é definida como a função que indica um coeficiente de afi-
nidade entre registros de certos fatos. Como certos fatos e eventos acon-
tecem associados? Qual é a influência que um impõe sobre o outro? A
associação está relacionada normalmente com as aplicações que buscam
identificar os produtos de uma cesta de supermercado ou equivalentes.
Com que porcentagem um produto X é comprado na mesma transação
com o produto Y? Qual é o valor médio das compras em que esses itens
aparecem em conjunto? Qual é o lucro médio dessas transações? Teria
sentido colocá-los em promoção no mesmo período? Por exemplo, anali-
sando um DW contendo os registros diários de venda de uma grande rede
de discos no Brasil, qual seria a associação entre músicas sertaneja e pagode
compradas na mesma transação? O que deve ser feito para incrementar a
venda de pagode?

135
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Como exemplo didático e simplificado, vamos considerar que, na análise de


transações de uma rede de lojas de disco, encontraram-se os seguintes registros de com-
pras de gênero musical, nas 10 transações analisadas:
PAGODE, SERTANEJO, CLÁSSICO, SAMBA
CLÁSSICO, SAMBA
PAGODE, SERTANEJO, SAMBA
SERTANEJO, CLÁSSICO, SAMBA
SAMBA
CLÁSSICO
PAGODE, CLÁSSICO
SERTANEJO
PAGODE, SERTANEJO, SAMBA
PAGODE, SERTANEJO, CLÁSSICO, SAMBA
Alguns coeficientes podem ser obtidos na análise de associação efetuada:
 Valor de confiança (Confidence) da regra ou probabilidade de a cesta con-
tendo sertanejo (A) conter também pagode (B):
 Sertanejo aparece em seis transações
 Pagode aparece em conjunto com sertanejo em quatro transações
 Confidence = 4/6 (67%)
 Quanto maior esse valor, mais forte é a correlação entre eles
 Valor de suporte (Support) da regra:
 Pagode e sertanejo aparecem juntos em quatro transações
 Total de transações = 10
 Support = 4/10 (40%)
 Quanto maior esse valor, maior a probabilidade de que a regra seja válida
 Valor de alavancagem (Lift) da regra – sertanejo alavancando a venda de
pagode:
 Pagode aparece em 5 das 10 das transações (aleatoriamente seria a minha
probabilidade de achar pagode numa venda) 5/10 = 50%
 Pagode aparece em quatro das seis transações, com sertanejo (agora a
probabilidade que existe com a associação com sertanejo) 4/6 = 67%
 Lift = 67/50 = 1,34
 Esse valor indica quantas vezes a associação com sertanejo aumenta a
probabilidade de vender pagode. Ou seja, nessa amostra há indicação de
que existe 1,34 vez mais chance de vender pagode quando associado a
sertanejo.
 Valor de alavancagem (Lift) da regra – pagode alavancando a venda de
sertanejo:

136
ELSEVIER
C APÍTULO 7 I D ATA M INING

 Sertanejo aparece em 6 das 10 das transações (aleatoriamente seria a mi-


nha probabilidade de achar pagode numa venda) 6/10 = 60%
 Pagode aparece em quatro das seis transações, com sertanejo (agora a
probabilidade que existe com a associação com sertanejo) 4/6 = 67%
 Lift = 67/60 = 1,12
 Esse valor indica quantas vezes a associação com pagode aumenta a pro-
babilidade de vender sertanejo. Ou seja, nessa amostra há indicação de
que existe 1,12 vez mais chance de vender sertanejo quando associado
a pagode.
Algumas conclusões simples, baseadas na análise de associação:
 Posso aumentar a venda de pagode promovendo a sua associação com venda
de sertanejo. O inverso já não é tão forte.
 Potencialmente poderia aumentar o preço dos discos de pagode (ou não
colocá-los em promoção), pois a sua venda está associada e pode ser alavan-
cada pela venda de outro gênero, que é mais forte.
 As lojas deveriam ter sempre os dois gêneros em disponibilidade, simulta-
neamente.
Outras análises mais complexas poderiam ser feitas, trabalhando valores de ven-
das e simulações:
 Como isso impacta nos lucros?
 Como a promoção impactaria no custo da compra total?
É importante observar que o exemplo considerou somente a associação em
grau 2, ou seja, dois gêneros. O problema poderia se tornar muito mais complexo em
termos de volume de dados e de tempo de processamento caso tivéssemos considerado
associações de grau mais elevado.
 Padrões sequenciais: são definidos como processos que visam à identificação
de fatos que implicam outros fatos, em momentos diferentes do tempo.
Aqui o tempo entre os dois eventos é considerado. Suponha o mesmo caso
de uma grande rede de lojas de discos que realiza vendas com um cartão de
fidelidade de cliente. Nesse caso, é possível estabelecer correlações como:
60% dos clientes que compram discos de lambada, num espaço máximo
de dois meses, voltam para comprar um CD de João Donato ou Al Jarreau,
certamente como elemento de desintoxicação. No mercado financeiro, esses
padrões sequenciais poderiam indicar que, quando uma determinada ação
X tem o seu preço aumentado de 10% durante um período de cinco dias,
uma outra ação Y será aumentada de 5%-8% na semana subsequente. Aná-
lise de comportamento de fraudes e evolução de perfis de consumidores se
encaixam nesse exemplo.
 Classificação: são processos que definem agrupamentos de itens em classes,
segundo referências estabelecidas. São usados para definir grupos ou classes
de elementos, com base em certos parâmetros preestabelecidos. São usados,

137
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

por exemplo, em sistemas de análise de risco de crédito, em que os clientes


são classificados em aprovados e rejeitados segundo padrões estabelecidos de
atraso de pagamento, classe socioeconômica, idade etc. Com base nesses re-
gistros, modelos de referência são construídos.Várias abordagens são usadas
para definir esses modelos (redes neurais, árvores de decisão, com base em
regras), sendo que algumas permitem a definição explícita da classe (árvore
de decisão), e outras, o seu modelo implícito (redes neurais), este último
usado em aplicações de classificação de imagens e voz, por exemplo. Depois
dos modelos definidos, e com base neles, determinado cliente é analisado
para verificar a sua aderência a determinada classe.
 Agregação: atua em conjunto de registros, como a abordagem anterior, po-
rém com a diferença de que os registros não estão previamente classifica-
dos ou definidos em conjuntos conhecidos. Dessa forma, nenhuma classe é
conhecida no momento em que o operador de agregação é invocado, e o
seu objetivo é a obtenção de agrupamentos com base na similaridade apre-
sentada pelos dados. Diferentes funções de agregação produzem diferentes
agregados e são usadas em trabalhos práticos de segmentação de mercado,
análise de defeitos e análise de feições morfológicas em aplicações de sen-
soriamento remoto.
Esses modelos de garimpagem de dados podem ser usados de forma integrada,
realizando análises em cascata, com operadores aplicados sobre resultados de outros. Por
exemplo, uma análise de associação de dados de compras é efetuada para identificar
produtos comprados em conjunto. O resultado pode ser analisado para definir classes
desses produtos.

Aplicação
Depois de definido e testado o modelo, a aplicação se dá pela utilização daqueles
algoritmos ajustados em situações reais de sistemas. Alguns produtos permitem que seja
produzido um código-fonte, resultante dos modelos e algoritmos definidos e compi-
lados, que poderá ser incorporado em sistemas tradicionais e invocado para a execução
das análises requeridas. O detalhamento de várias aplicações de data mining está apre-
sentado nos itens subsequentes, quando da discussão das técnicas estatísticas utilizadas.
Uma das mais interessantes aplicações de data mining desenvolvidas pela IBM,
além da já conhecida análise de cesta de supermercado, é o projeto de scout avançado
para a NBA. Esse projeto, desenvolvido em conjunto com a Associação Nacional de
Basquete (NBA-USA), objetivou definir um sistema de interpretação e análise de da-
dos coletados em todos os jogos da NBA. Os dados foram sincronizados com o “reló-
gio universal da NBA”, que também é gravado em todos os videoteipes dos jogos
daquele certame. Isso permitiu a visualização/confirmação dos fatos garimpados através
da TV. Os dados foram garimpados para a detecção de correlações e fatos escondidos,
quase sempre não observados pelas comissões técnicas. Por exemplo, no jogo entre
Cleveland Cavaliers e New York Nicks, em 6 de janeiro de 1995, enquanto o jogador
do Cleveland (Mark Price) esteve em quadra na posição de ala, o atacante John William
converteu (todas) as quatro tentativas de arremessos efetuadas. Isso contrastou com a

138
ELSEVIER
C APÍTULO 7 I D ATA M INING

média de conversões do time, que foi de 49,3%, e não teria sido percebido se não fosse
o scout avançado da IBM.

Padrões metodológicos de data mining


Uma das primeiras propostas para o estabelecimento de padrões em cinco sur-
giu em 1996, com a criação do CRISP-DM 1.0 ou Cross Industry Standard Process
for Data Mining (www.crisp-dm.org). O grupo proponente, com origem na Europa,
teve a participação/colaboração destacada da NCR da Dinamarca, da SPSS do Reino
Unido (agora incorporada pela IBM Corp), da Daimler Chrysler (agora Daimler Benz)
da Alemanha e a OHRA da Holanda. A proposta, ainda uma das mais usadas em em-
presas de serviços de mining, segundo pesquisas, planejou uma nova versão para 2006
(CRISP-DM 2.0), que não foi concretizada. A proposta original é composta de seis
fases básicas e absolutamente intuitivas, conforme a Figura 7.3:

Figura 7.3
Visão geral do ciclo de um projeto de data mining.

 Entendimento do negócio: fase em que se entendem os negócios, seus ob-


jetivos, seus requerimentos e limitações, e traduz-se isso para aplicações em
data mining.

139
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Entendimento dos dados: fase que consiste na identificação dos dados exis-
tentes, suas características, suas limitações qualitativas e quantitativas, e as
primeiras definições sobre subconjuntos capazes de prover informações es-
condidas. Poderá ter interação com a fase anterior, visando ao melhor en-
tendimento dos requisitos de negócios.
 Preparação dos dados: planeja todas as atividades para chegar ao ponto final
de carga dos dados no ambiente de mining. Envolve seleção, preparação,
limpeza e tradução dos dados.
 Modelagem: envolve a seleção e aplicação das técnicas sobre os dados se-
lecionados. Várias técnicas diferentes podem ser aplicadas para o mesmo
problema de mining e, por vezes, exigem formatos de dados diferentes, o
que sugere prováveis retornos à fase anterior.
 Avaliação: nesse momento, o modelo terá sido construído e deverá ser cri-
teriosamente avaliado sobre a sua aplicação para o problema sugerido, po-
dendo provocar revisões nos objetivos de negócios.
 Implantação: fase que será realizada pelos usuários e consiste na aplicação do
modelo desenhado na produção dos dados requeridos, nas análises desejadas,
avaliando-se o alcance dos objetivos planejados.

DATA MINING GROUP


Nesse intervalo, com o aparecimento e fortalecimento da linguagem XML, apa-
receu um novo grupo, com raízes americanas, que objetiva a formalização de uma
linguagem padrão para o uso na área de mining. O DMG (Data Mining Group, www.
dmg.org) desenvolveu a linguagem PMML (Predictive Model Markup Language), que
objetiva, via schemas XML, a definição de linguagem para modelos encontrados nos
domínios de mining, como associações, modelos de regressão, clustering, modelo Naive
Bayes, redes neurais etc. As empresas que integram esse grupo são: IBM, MicroStrategy,
SAS, além de outras com status de membros associados e contribuintes, como Pervasive
Software, Equifax, KNIME, Nasa, Oracle, National Center for Data Mining 
Universidade de Chicago etc.

Técnicas estatísticas empregadas nos processos de data mining


Um conjunto de técnicas de natureza estatística é utilizado nos processos de
data mining, normalmente embutidos em softwares dedicados a essas aplicações. As
principais são:
 Árvore de decisão (Answer/Decision Tree).
 Análise de conglomerados (Cluster Analysis).
 Redes neurais: não é exatamente uma técnica estatística, mas um recurso
matemático/computacional que pode ser usado na aplicação delas.
 Análise de regressão (linear e não linear).
 Métodos preditivos com séries temporais.

140
ELSEVIER
C APÍTULO 7 I D ATA M INING

ÁRVORE DE DECISÃO
A árvore de decisão é uma técnica que, a partir de uma massa de dados, cria e
organiza regras de classificação e decisão em formato de diagramas de árvores, que vão
classificar suas observações ou predizer resultados futuros. Se seus dados estiverem divi-
didos em classes dicotômicas, como bons pagadores contra maus pagadores, assinantes
contra não assinantes, infectados contra não infectados, seus clientes contra clientes da
concorrência etc., uma árvore de decisão pode ser construída para criar regras que clas-
sifiquem casos já existentes ou casos novos, com precisão.
Começa-se com um único grupo, que reúne todos os casos em estudo. À me-
dida que a árvore vai se expandindo, essa base é dividida em nódulos que representam
categorias das variáveis analisadas. Cada galho da árvore é formado por esses nódulos,
que vão se abrindo em subgrupos mutuamente exclusivos. Cada nódulo e cada galho
apresenta uma proporção de obtenção da resposta em estudo.

Empregos da técnica de árvore de decisão


Genericamente falando, o emprego da técnica de árvore de decisão é abrangente
e se dá em abordagens como as descritas a seguir:
 Segmentação: identificação de grupos baseada na identificação de característi-
cas em comum apresentadas pelos elementos. Ex.: segmentação de mercado,
dividindo-se a base de clientes de uma empresa de acordo com o perfil de
uso de seus produtos.
 Estratificação: determinação de regras para que se possa designar cada caso a
uma dentre várias categorias existentes, como, por exemplo, classificar um
cliente tomador de crédito em grupo de risco elevado, risco médio, risco
baixo.
 Predição: criação de regras para aplicação em eventos futuros. Por exemplo, se
identificarmos os sintomas que geralmente representam determinado diag-
nóstico, os futuros pacientes que apresentarem o mesmo quadro serão enca-
minhados para fazer exames específicos daquela doença. A predição também
pode ser utilizada na tentativa de identificar relações entre atributos predi-
tivos e valores de uma variável contínua. Por exemplo: a identificação de
quais ações de marketing estão levando a aumento significativo nas vendas.
 Redução de dados e filtro de variáveis: quando se tem demasiadas variáveis em
um processo, pode-se utilizar técnicas de árvore de decisão para identificar
quais têm mais influência sobre a resposta, diminuindo assim o volume de
variáveis em estudo.
 Identificação de interações: identificação de interações pertinentes somente a
determinados subgrupos e especificação delas em modelos paramétricos
formais.
 Combinação de categorias e “discretização” de variáveis contínuas: significa a pos-
sibilidade de recodificação de variáveis categóricas e contínuas com perda
mínima de informação. Ex.: no estudo de câncer de pulmão, em que se

141
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

coletou o número de cigarros fumados pelos pacientes por dia, as quanti-


dades de cigarro que levarem a uma probabilidade similar de aparecimento
do câncer podem guiar o pesquisador sobre como agrupar esses números,
como de 1 a 4, de 5 a 10 etc.

Aplicações típicas de árvore de decisão


Alguns exemplos de aplicações típicas de uso de árvore de decisão são:
 Mala direta: o grande problema do envio de malas diretas é o custo muito
elevado, se comparado às baixas taxas de retorno. Estudos já mostraram
que as taxas de retorno para malas diretas que oferecem prêmios àqueles
que as responderem giram em torno de 20% somente. Imagine o retorno
daquelas que são meramente informativas. Tendo isso em mente, a árvore
de decisão se torna uma forte aliada dos departamentos de marketing à
medida que permite, a partir dos dados coletados em experiências an-
teriores ou em amostras experimentais, a determinação de quais grupos
demográficos apresentam a maior taxa de resposta. Direcionando suas
campanhas para o público certo, os investimentos obviamente serão mais
bem empregados.
 Credit scoring: também conhecida como escoragem de crédito, essa técni-
ca é utilizada na concessão de crédito para operações que trazem lucros
pequenos se vistas individualmente, mas que representam um ganho alto
por existirem em grande quantidade. Um uso muito difundido do credit
scoring é na análise de propostas para concessão do cartão de crédito do
banco. Nesse produto, o lucro das operadoras por consumidor é peque-
no, tornando-se significativo à medida que se aumenta a carteira de cli-
entes. Por isso, é necessário ter uma técnica rápida e de baixo custo para
a análise do crédito. Para chegar à árvore de decisão, utilizam-se os dados
históricos de operações já realizadas com seus respectivos desempenhos.
A resposta, nesse caso, é se o cliente vai se tornar inadimplente ou não.
As variáveis e os atributos que fazem parte dos galhos da árvore são as
características do cadastro do cliente, as quais mostraram ter correlações
significativas com seu comportamento de pagamento. Dessa forma, para
o próximo cliente que estiver pleiteando um cartão de crédito, verificar-
se-á, por exemplo, sua renda, seu estado civil, o número de dependentes,
o sexo e outras variáveis que tiverem se destacado no perfil dos clien-
tes bons e dos clientes maus para determinado produto. O crédito será
concedido àquele cliente que apresentar um perfil de bom pagador, de
acordo com o histórico dos já clientes da empresa que estiver conce-
dendo o cartão.
Muitas empresas utilizam a árvore de decisão como um recurso de “repescagem”
dos clientes rejeitados por outro método de seleção, geralmente aqueles feitos com aná-

142
ELSEVIER
C APÍTULO 7 I D ATA M INING

lise de regressão. A árvore, então, é desenvolvida somente com os clientes previamente


rejeitados, para se detectar, dentre eles, quais ainda poderiam ter crédito por apresenta-
rem um perfil de baixa taxa de sinistro.
Vejamos um exemplo da árvore de decisão na Figura 7.4, cuja resposta é: clientes
bons e clientes maus. Cada nódulo traz uma taxa de sinistro (ou inadimplência) corres-
pondente. Analisando o diagrama apresentado no canto dessa figura, temos uma amostra
de 4.477 clientes, que foram subdivididos de acordo com algumas variáveis selecionadas
durante o processo da árvore de decisão. Para que tenhamos melhor visualização dos
resultados, foi dado um zoom na parte central dessa árvore. Interpretando cada nódulo,
temos o número de clientes bons n (0) e seu percentual naquele nódulo %, e o n e % de
maus (1). Por último, estão n e % que aquele nódulo representam no total da amostra,
naquele nível da árvore. Cada quadrinho tem um pequeno gráfico em que, à esquerda,
estão representados os clientes bons e, à direita, os clientes maus.

Figura 7.4
Diagrama geral de uma árvore de decisão.

Inicialmente, os clientes foram separados por tempo de conta-corrente. Podemos


notar que, quanto mais recente a conta, maior o risco do cliente, pois mais altas
foram as taxas de sinistro observadas. Dentro dessa variável havia cinco categorias,

143
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

que foram agrupadas em três. A primeira é formada por clientes com até um ano de
conta (taxa de sinistro = 52,71%), a segunda por clientes com um a dois anos (taxa
de sinistro = 35,23%) e a terceira por aqueles acima de dois anos de conta (taxa de
sinistro = 22,75%).
Para aprofundar nos níveis da árvore, escolhemos o galho central, que consiste
em clientes com um a dois anos de conta-corrente. Para eles, a próxima variável
selecionada foi renda (já dividida em classes). Como podemos observar, a maior “si-
nistralidade” estava concentrada entre os indivíduos com renda até R$600,00 (taxa de
sinistro = 43,69%). Até esse ponto, os proponentes mais “seguros” seriam, portanto,
aqueles com renda de R$1.501,00 a R$2.500,00, para os quais a taxa de sinistro foi
de 24,6%.
Somente dois nódulos foram mais uma vez subdivididos, como se pode veri-
ficar: o das rendas mais baixas e o de renda entre R$1.501,00 e R$2.500,00. O
primeiro originou o quarto nível, com a variável tipo de renda. É possível notar que
somente os assalariados foram significativamente distintos dos demais, com taxa
de sinistro de 34,57%, um tanto menor que a taxa dos outros tipos de renda, de
60,84%. Até agora, as taxas de sinistro estão bem elevadas, mas já sabemos que, para
os proponentes de um a dois anos de conta-corrente e com renda baixa, daríamos
preferência aos assalariados. Ainda no mesmo nível, os clientes do outro nódulo
foram subdivididos segundo a variável sexo, em que se pode constatar que o menor
risco ou a menor taxa de sinistro constatada foi para os clientes do sexo feminino,
com 13,58% de inadimplência.
Se limitássemos a taxa de sinistro suportável pela empresa a 15%, concederíamos
crédito aos proponentes com um a dois anos de conta, R$1.501,00 a R$2.500,00 de
renda, do sexo feminino. Se a árvore tivesse sido desenvolvida para repescagem, isso
significaria que aproveitaríamos os clientes descritos, mesmo se eles tivessem sido rejei-
tados na primeira seleção por algum outro método.
Outra utilidade já mencionada, além da predição, é a determinação de quais
variáveis são realmente importantes em determinado processo. Somente figuraram na
árvore de decisão aquelas que exerciam influência significativa e atendiam aos parâme-
tros dos testes realizados. As demais não apareceram na árvore final, como, por exemplo,
idade e estado civil.

À A Figura 7.4 foi desenvolvida no Answer Tree, um módulo stand alone do


software SPSS/IBM.

 Análise de mercado: na determinação de diretrizes a serem seguidas para o


aumento da receita de uma empresa, a área de marketing pode utilizar
sua base de dados para determinar quais variáveis – preço, localização
geográfica dos pontos de venda, características dos consumidores, dentre
outras – realmente afetam de forma significativa o volume de vendas.
Nesse exemplo, a resposta poderia ser crescimento ou decrescimento das

144
ELSEVIER
C APÍTULO 7 I D ATA M INING

vendas. A árvore de decisão traçaria quais variáveis seriam incluídas e


em qual ordem. Cada “galho” da árvore representaria uma probabilidade
diferente de obter um aumento nas vendas.
 Controle de qualidade: fazendo-se um levantamento de todas as variáveis en-
volvidas nos processos de fabricação de determinado produto e tendo como
resposta o refugo ou a aprovação da mercadoria, a árvore de decisão pode
ser uma ferramenta muito útil na identificação de fatores que estejam con-
tribuindo para a boa ou má qualidade da linha de produção.
 Recursos humanos: a árvore de decisão pode auxiliar no entendimento de
práticas anteriores de recrutamento de pessoal e criar regras de decisão
que darão diretrizes a esse processo. Como muitas informações entram
em jogo na hora de decidir sobre a contratação de um novo funcionário,
incluindo experiência anterior, grau de escolaridade, resultados de testes
psicotécnicos, entre outros, essa técnica pode ser útil na padronização
de critérios de escolha e no grau de acerto dessa decisão. Ela pode aliar
todas as informações obtidas nos processos de recrutamentos passados
aos resultados de satisfação da empresa com os candidatos finalmente
contratados.
 Pesquisas médicas: considerando-se pacientes que apresentem o mesmo
problema, um estudo pode ser montado para determinar o melhor trata-
mento indicado para cada perfil de sintomas apresentados. Primeiramente,
a árvore de decisão será utilizada para segmentar os clientes, dividindo-os
em grupos. Dentro de cada grupo ficarão as pessoas que apresentarem um
quadro de sintomas similares. Cada grupo ou, melhor dizendo, cada galho
da árvore de decisão será submetido a mais de um tipo de tratamento e
determinar-se-á o tratamento mais eficaz para cada um. Assim feito, para
os próximos casos que forem diagnosticados, o médico poderá indicar
o tratamento mais eficaz com base nas características e nos sintomas do
paciente.
 Estudos de políticas internas: a árvore de decisão pode auxiliar na análise de da-
dos coletados em pesquisas de opinião. Geralmente, nesse tipo de pesquisa,
muitos dados são obtidos e é necessário que sejam organizados e seleciona-
dos, de maneira que se transformem em informações, as quais trarão repostas
e decisões até mesmo sobre qual política seguir.

Análise de conglomerados ou cluster analysis


O objetivo da análise de conglomerados é identificar a existência de diferen-
tes grupos dentro de um conjunto de dados e, constatada essa existência, agrupar os
elementos estudados de acordo com as semelhanças entre si, considerando-se as carac-
terísticas analisadas.

145
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Para calcular a similaridade entre cada um dos objetos amostrais, há vá-


rias medidas matemáticas a serem utilizadas, dependendo do comportamento dos
dados. Entre elas estão: distância euclidiana, distância generalizada e distância de
Minkowski.
Outra decisão a ser tomada nesse processo é o método de formação de con-
glomerados que deverá ser escolhido. Ele poderá ser dos tipos hierárquico ou não hie-
rárquico.
As técnicas hierárquicas são classificadas em aglomerativas e divisivas. Dada
uma amostra de n elementos, as técnicas aglomerativas iniciam-se com n conglo-
merados de tamanho 1 cada, e a cada estágio eles vão sendo agrupados e formando
novos conglomerados. Uma vez unidos, dois elementos não serão mais separados. Já
as técnicas divisivas, como o nome diz, são o contrário. Partem de um único con-
glomerado de tamanho n e a cada estágio do processo esse conglomerado inicial vai
se subdividindo em novos grupos. As técnicas mais utilizadas são as aglomerativas,
principalmente por já terem maior suporte computacional.

Considerações sobre a análise de conglomerados


Técnicas hierárquicas
 Por não considerarem as fontes de erro e variação dos dados em estudo, os
procedimentos hierárquicos são sensíveis a pontos de valores extremos, ou
“ruídos”.
 Exatamente devido à sua estrutura de combinações hierárquicas, se um ele-
mento tiver sido alocado incorretamente no começo do processo, não é
possível realocá-lo. Consequentemente, a configuração final dos clusters deve
sempre ser cuidadosamente examinada por uma pessoa que entenda do ne-
gócio e da base de dados sendo analisada.
 Sempre que possível, é aconselhável testar mais de um método de combi-
nação e de cálculo das distâncias entre os elementos, para obter a melhor
partição.
 A estabilidade do modelo obtido pode ser verificada inserindo-se pequenas
perturbações (erros) nas unidades amostrais do banco de dados. Se os grupos
estão bem distinguidos, as divisões antes e após as perturbações devem coincidir.
No caso de acontecerem empates nos cálculos de distâncias, agrupamentos di-
ferentes podem resultar. Isso não é necessariamente ruim, mas o usuário deve saber de
sua existência para que os dendogramas de agrupamentos possam ser adequadamente
interpretados. Pode-se até aproveitar essa situação e escolher determinado agrupamento
de acordo com a conveniência da natureza do negócio.

Técnicas não hierárquicas


Aqui são frisadas algumas desvantagens de predeterminar o número K de con-
glomerados:

146
ELSEVIER
C APÍTULO 7 I D ATA M INING

 A existência de um outlier pode resultar em um cluster formado por elemen-


tos bem dispersos.
 Se dois ou mais elementos que pertenceriam a um mesmo grupo forem
escolhidos como sementes, é bem provável que os agrupamentos finais te-
nham pouca distinção entre si.
 Mesmo se for conhecido que a população em estudo se divide em k grupos,
é possível que, na amostra coletada, os dados do grupo mais raro não tenham
sido contemplados. Dessa forma, a amostra teria de ser dividida em k  1
grupos, mas isso só será descoberto durante o processo de agrupamento.

Empregos da análise de conglomerados


Suponha que uma empresa de telefonia celular queira expandir sua área de
atuação para o interior do estado. Para formar regionais nas quais será feita uma prio-
rização da estratégia de ampliação de seu mercado, é preciso agrupar as cidades mais
semelhantes, segundo características de interesse levantadas pela empresa. Essas caracte-
rísticas podem ser: PIB da cidade, número de habitantes, número de fábricas de grande
porte instaladas, número de linhas de telefonia fixa instaladas, entre outras. A partir da
análise de conglomerados é possível determinar quais cidades apresentam maior seme-
lhança entre si e, dados os clusters finais, é possível priorizá-los de acordo com suas ca-
racterísticas e com o perfil de público-alvo desejado pela empresa. Assim, não somente
determinam-se quais cidades devem compor uma mesma regional de gerenciamento,
como também qual regional deve ser focada primeiramente de acordo com a estratégia
de expansão da companhia.
Outra aplicação muito utilizada é a segmentação de mercado. Na política de
fidelização de clientes, muitas vezes é necessário premiá-los de maneira diferenciada.
Mas como determinar quais são os clientes top, os premium e os standard, por exem-
plo? Diversas variáveis podem estar em questão. A percepção adequada de hábitos e
comportamentos dos clientes é essencial em política de fidelização. Para isso, a análise
de conglomerados auxilia muito, dividindo a carteira em grupos distintos, cada um
apresentando um perfil de consumo ou de receita que determinará a sua classifica-
ção. Além de classificar cada cliente em determinado grupo de fidelização, a empresa
poderá estimar o quanto cada grupo traz de receita diferenciada e, consequentemente,
qual é a grandeza de prêmios que poderão ser atribuídos a cada tipo de cliente
visando a gerar estímulos adequados de consumo. A Figura 7.5 ilustra o conceito de
análise de conglomerados, mostrando a formação de quatro “nuvens” ou clusters, com
alguns pontos sendo atraídos para cada nuvem em função das distâncias calculadas.
O exemplo mostra o uso de duas variáveis (renda e experiência), com a proposta de
quatro núcleos iniciais.

147
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 7.5
Visão esquemática do resultado de análise de conglomerado (clustering analysis).

REDES NEURAIS
As redes neurais são uma tecnologia cada vez mais usada em data mining. Sua
grande vantagem está basicamente na habilidade de aprendizagem a partir das experiên-
cias, não ficando restritas a uma ordem sequencial prefixada. Elas consistem em algorit-
mos e procedimentos computacionais que imitam a capacidade de aprendizagem do
cérebro. Essa técnica é formada de nódulos cujo processamento se assemelha ao dos
neurônios, daí seu nome. Não é considerada técnica estatística por não apresentar a
robustez de uma. Não oferece estimadores definidos, e o comportamento de uma rede
neural, com certa massa de dados, nem sempre se repetirá com outra. No entanto, é um
recurso que permite o emprego de estatística em modelos não lineares.
A Figura 7.6 mostra como são constituídas as redes neurais. Os nódulos são
conectados como uma rede e funcionam paralelamente. A primeira fase de nódulos
é composta pelos nódulos de entrada. Eles recebem o input das variáveis fornecidas
pelo banco de dados, transformam-no de acordo com uma função – chamada função
de ativação –, produzindo uma informação de saída que será enviada à próxima fase
de nódulos, a qual, por sua vez, receberá diversas informações dos nódulos de entrada
como seu input. Essa fase é formada pelos nódulos ocultos, que, em redes neurais mais
complexas, podem formar diversas camadas. Por fim, têm-se os nódulos de saída. Eles

148
ELSEVIER
C APÍTULO 7 I D ATA M INING

processam as informações recebidas e produzem uma resposta, mas não a enviam para
outro nódulo, pois essa saída já é o resultado final da rede. Se a rede é de classificação, o
nódulo de saída já é a classe final. Para o caso de modelos de previsão, o nódulo de saída
representa um valor preditivo.

Figura 7.6
Visão esquemática de rede neural.

Para entender melhor como funciona cada módulo, basta observar a Figura 7.7.
Ela mostra que o nódulo recebe uma quantidade de informação de entrada, x1, x2, x3,
ponderada, respectivamente, por p1, p2, p3. A função de ativação f transforma as entradas
recebidas em uma informação de saída que servirá de entrada para a próxima fase de
nódulos. Portanto, a saída final da rede neural é a soma ponderada dos nódulos ocultos.
As funções de ativação são geralmente não lineares, o que dificulta a interpretação dos
modelos de redes neurais.

149
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 7.7
Visão esquemática de um nódulo de rede neural.

Geralmente só são permitidas conexões em um único sentido, ou seja, não há


conexões de volta.
Assim como os neurônios cerebrais, as redes precisam ser treinadas. Esse trei-
namento consiste em estimar os valores dos parâmetros das funções de ativação y =
f( x,T) de tal forma que os valores preditos sejam o mais próximo possível dos valores
observados. Isso é obtido por meio de uma amostra aleatória do conjunto de dados,
contendo entradas (x) e saídas (y). Primeiramente escolhem-se valores iniciais de T.
Posteriormente, uma nova estimativa é obtida quando as observações (xi, yi) da amostra
aleatória de treinamento são consideradas. Esse procedimento é repetido até se obter
convergência, isto é, um ponto ótimo global.
Com base nas estimativas dos parâmetros, obtidas a partir da amostra de treina-
mento, ajusta-se o modelo com os dados completos. Tal modelo pode ser avaliado com
uma amostra de validação, possibilitando a verificação do ajuste de forma independente.
O analista deve tomar cuidado para que a rede neural não sofra uma overdose de
treinamento, ou seja, para que a rede não comece a explicar todas as relações entre os
nódulos e acabe representando até o erro aleatório no modelo. Já que sempre existirá
um erro, um ruído nos dados, o importante é tentar controlá-lo e não esperar que ele
desapareça. Esse problema de supertreinamento pode ser evitado simplesmente deter-
minando-se um limite máximo de erro tolerado. Quando a rede atingir esse limite, o
treinamento é dado como finalizado.

Aplicações de redes neurais


É importante salientar que não existe uma técnica universalmente melhor
que todas. O sucesso do data mining depende muito da experiência e sensibilidade

150
ELSEVIER
C APÍTULO 7 I D ATA M INING

do pesquisador, o qual terá de identificar qual é a melhor ferramenta a ser utilizada,


de acordo com o tipo de resposta procurada e com o modo como se encontram seus
dados. Por isso, os exemplos de aplicações dos métodos relacionados neste capítulo
podem se repetir.

Marketing
Modelos de classificação – informações demográficas e de compras dos clientes,
contidas na base de dados de uma empresa – são utilizados para segmentar a carteira
baseando-se em suas similaridades, sejam elas de comportamento de compras, de nível
socioeconômico ou de seus interesses e hobbies, demonstrados por seus perfis de consu-
mo. Segmentando-se a base de clientes, torna-se mais fácil e preciso o desenvolvimento
e o oferecimento de produtos a um público específico.

Modelos preditivos
As redes neurais, a partir dos dados de clientes e seu comportamento perante a
empresa, podem auxiliar identificando o perfil dos clientes mais propensos ao churning
– término de contrato –, ou à inadimplência. Dessa forma, pode-se aumentar a taxa de
retenção dos consumidores, intervindo de forma preventiva quando um cliente sina-
lizar probabilidade de churning ou de inadimplência. Como se sabe, é muito mais caro
conquistar um novo cliente do que vender para um já cliente. Isso significa que essa
estratégia pode ter um impacto significativo no aumento de receita.
Cruzando informações de preferências dos clientes com características dos
produtos existentes, podem ser promovidas campanhas que provoquem um aumento na
média de consumo de determinados segmentos da carteira.

Vendas
Analogamente a outras técnicas de data mining, as redes neurais podem ser
utilizadas para detectar associações entre fatores, inclusive com sua relação ao longo do
tempo. Um exemplo, dentro da área de vendas, é quando alguém compra um vestido
novo. Com as redes neurais pode-se detectar que essa compra tem forte probabilidade
de ser seguida de uma compra de sapatos novos, meias e outros acessórios. Com isso
em mente, uma grande loja de departamentos pode procurar expor esses produtos de
maneira que fique fácil para o cliente enxergá-los e pegá-los, antes que ele vá a algum
outro estabelecimento para adquiri-los.

Finanças
Além de serem úteis na determinação do perfil do bom e do mau pagador
(credit scoring), as redes neurais são utilizadas para detectar padrões de potenciais usos
fraudulentos de cartão de crédito. Companhias de cartão de crédito costumam bloquear
cartões que sinalizam tais usos, pois geralmente correspondem a cartões roubados ou
clonados.

151
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Diversas empresas de ações fazem uso de redes neurais para predizer flutuações
nas taxas de juros e de câmbio. Tendências e mudanças no movimento do mercado
como um todo ou em segmentos específicos também são acompanhadas por meio
dessa técnica.
De acordo com o Banco Central do Brasil, todas as operações de crédito devem
ser classificadas de acordo com o risco que representam para quem está concedendo o
capital. Como muitas variáveis são envolvidas na classificação de risco de um cliente, as
redes neurais são uma ferramenta importante. Nos casos de grandes empréstimos, por
exemplo, o indício de falência de uma companhia pode evitar que uma grande soma
seja concedida em uma operação que não será recuperada. A utilização dessa informa-
ção pode, portanto, diminuir a margem de perda de uma instituição financeira.

Energia
Concessionárias de energia elétrica sofrem muitas oscilações de demanda de
consumo. Mudanças nas condições do tempo podem aumentar o consumo de uma
região em questão de horas. Devido a isso, decisões precisam ser tomadas rapidamente,
no sentido de acionar ou desativar usinas como forma de manutenção preventiva. As
redes neurais têm sido usadas para auxiliar nessa tomada de decisão, dados fatores como
mudança de massas de ar, região de consumo contemplada, capacidade da usina, entre
outros.
Grandes consumidores de energia, como empresas metalúrgicas, costumam ser
cobrados de acordo com o seu pico de consumo. Por isso é importante que se gerencie
o consumo, objetivando minimizar as demandas excessivas.
Na pesquisa por novos poços de óleo e gás natural, as redes neurais têm sido
de grande utilidade, auxiliando na análise dos resultados de sonorização de testes de
perfuração realizados para detectar mudanças em estratos de rochas e identificar áreas
propensas à existência de depósitos minerais (BIGUS, 1996).

Produção
Alguns ambientes de produção, na busca por qualidade e eficiência, podem ser
bastante complexos. As redes neurais já são utilizadas para controles estatísticos de pro-
cessos, definição de sequências de processos, otimização de processos químicos e, con-
forme mencionado, minimização de consumo de energia.
No controle estatístico de processos, as redes neurais podem ser usadas na de-
tecção de possíveis refugos. Dadas determinadas amostras prévias de produtos, com
diversas características ao longo de sua produção, as redes são treinadas a discernir quais
serão as variabilidades dos fatores e condições que resultarão em produto com ou sem
falhas. Pode-se até utilizar as redes para classificar os produtos de acordo com seu grau
de qualidade, determinando, a partir disso, seu público-alvo e seu preço.
Para determinar as sequências ótimas da utilização do maquinário e da organiza-
ção da linha de produção, é preciso respeitar condições intrínsecas ao processo, como
qual passo precisa ser realizado antes de outro (soldagem da lataria antes da pintura, por

152
ELSEVIER
C APÍTULO 7 I D ATA M INING

exemplo). Mas, além disso, existem processos que podem ser combinados de forma a
economizar tempo, esforços e energia, como quais materiais podem ser processados
por uma mesma máquina em uma única configuração, o que pode ser feito em uma
peça antes que ela seja movida a uma próxima estação etc. As redes neurais têm sido
empregadas para projetar sequências ótimas de processos, com custos minimizados e
produção maximizada.
Nos processos químicos, as redes neurais são usadas tanto para detectar possíveis
anormalidades que possam causar defeitos irreversíveis nos produtos finais, e possíveis
danos ao maquinário, quanto para melhorar a qualidade.

ANÁLISE DE REGRESSÃO
Esta técnica vem sendo uma das mais utilizadas em data mining devido à sua
facilidade de execução e, principalmente, de interpretação. A análise de regressão pro-
cessa as informações de uma base de dados de maneira a determinar um modelo (uma
equação) que represente o relacionamento existente entre as variáveis em estudo. Os
principais objetivos da análise de regressão são: sumariação dos dados, predição, controle
e estimação. Uma só análise pode atender a mais de um objetivo ao mesmo tempo.
Como as equações de regressão são calculadas com base em dados passados, elas
não poderão ser utilizadas para predição de dados futuros, caso a relação entre y e x se
modifique. O mesmo pode ser dito para o caso de extrapolação na predição, isto é, não
se recomenda a utilização da equação para predizer y em situações nas quais os valores
de x estão fora do intervalo dos valores de x observados quando do desenvolvimento
da equação.
Os tipos mais comuns de análise de regressão são a regressão linear simples, em
que só existem duas variáveis: a variável resposta, também chamada de variável depen-
dente ou preditora, e a variável explicativa, regressora ou independente. O outro tipo
mais comum é a regressão linear múltipla, em que se tem a variável reposta e mais de
uma variável explicativa, como y = E0 + E1x1 + ... + Ekxk + H. Por fim, a regressão logís-
tica, própria para quando a variável dependente for binária. Na equação anterior, os E
são os parâmetros ou pesos a serem estimados e H é o erro aleatório dado pela diferença
entre o valor observado y e o valor resultante da reta E0 + E1x1 + ... + Ekxk. A análise
de regressão consiste em técnicas que determinam a equação que traduz a relação real
entre os dados, minimizando os erros de estimação, isto é, a equação na qual a diferença
entre o valor calculado e o valor observado da variável resposta seja a menor possível.
Vale ressaltar que a regressão linear é assim denominada por sua linearidade nos
parâmetros E1 a Ek e não por y ser função linear dos x. Portanto, uma equação tal como
y = E0 + E1x1  E 2 x 2  E 3 x 3  H é um modelo de regressão linear múltipla, ao
4 2

passo que a equação y = E0 + E1x14  E 2 x 2E3  H não é.


Como na maioria dos modelos estatísticos, é importante observar suas supo-
sições para que o pesquisador se certifique de que determinada técnica possa ser em-
pregada na massa de dados. As suposições dos modelos de regressão linear, assim como

153
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

mais explicações técnicas, podem ser encontradas em Johnson; Wichern (1998) e, para
a regressão logística, Hosmer; Lemeshow. A Figura 7.8 ilustra o conceito de análise de
regressão.

Figura 7.8
Visão esquemática de análise de regressão.

Aplicações de análise de regressão


Sumariação
Imagine o cálculo de volume de produção de uma equipe de corretores de
seguro para premiação do melhor funcionário. Nesse caso, têm-se vários aspec-
tos considerados na produtividade, como número de novos clientes conquistados,
número de clientes mantidos, número de contratos alterados e que trarão maior
receita para a seguradora. A análise de regressão pode ser usada para sumariar esses
dados, dando uma equação com pesos determinados que vai calcular a produtivi-
dade de cada funcionário em função de cada desempenho exercido. Ao final, será
possível calcular um só índice de produtividade por funcionário e, dessa forma,
ordená-los do melhor ao pior.

Predição
Um dos principais aspectos da economia na atualidade é o crédito. A análise
de regressão pode ser empregada no auxílio do gerenciamento da carteira de certo
produto. Isso é feito com a determinação de quais variáveis realmente afetam o com-
portamento de pagamento dos indivíduos e com qual intensidade. Com isso, é possível

154
ELSEVIER
C APÍTULO 7 I D ATA M INING

predizer ou calcular a probabilidade de um cliente vir a se tornar inadimplente em


certo espaço de tempo, dado seu comportamento ao longo do período de observação.
Instituições financeiras podem, então, aumentar ou diminuir a oferta de crédito a seus
clientes a partir da forma como estes estão se portando. Esse emprego é denominado
behavior scoring ou análise comportamental. Um banco pode empregar o behavior score em
sua carteira de cheque especial para estabelecer regras de aumento ou diminuição de
limite, oferecimento de taxas de juros reduzidas, política de compensação de cheques,
estratégias de cobrança mais ou menos agressivas, entre outras. Tudo isso observando o
resultado da equação de regressão ou score, o qual pode sinalizar um grande potencial
do cliente em absorver mais produtos ou uma emergente dificuldade de pagamento do
crédito tomado.

Controle
No controle de produção de uma fábrica, muitas vezes uma linha é avaliada
por meio de testes destrutivos em amostras. Esses testes são assim chamados por se
caracterizarem pela necessidade de destruição e consequente perda das unidades
amostrais, como o teste de resistência antiquebra de um prato de vidro. Para esse
produto, um índice de qualidade pode ser o tamanho do impacto necessário para
quebrar o prato. Nesse caso, tem-se de exercer impactos de diferente intensidade até
que o prato se quebre, quando, naturalmente, não pode mais ser comercializado. Se
for constatado, por meio de uma reta de regressão, que o fato de o prato se romper
ou não está ligado ao seu peso e, digamos, volume, pode-se evitar a perda das uni-
dades amostrais passando a medir essas duas variáveis e calculando a probabilidade
de rompimento do produto. Isso pode representar enormes reduções de gastos para
uma empresa.

Estimação
É sabido que há determinados produtos cujo consumo está diretamente ligado
à renda do comprador. Suponhamos que uma empresa queira expandir sua rede de
distribuição e esteja fazendo a prospeção de locais onde as lojas devam ser construídas.
Dado que essa loja comercialize produtos baratos e de baixa qualidade, presume-se que,
à medida que a renda da pessoa aumenta, suas compras passam a ser concentradas em
outros produtos de qualidade menos inferior; portanto, quanto menor a renda, mais
dentro do alvo da empresa a pessoa se encontra. Se essa relação de renda e consumo for
constatada estatisticamente, com os devidos parâmetros, uma pesquisa sobre a renda dos
moradores ou frequentadores de certa região poderá determinar se vale a pena estabe-
lecer a loja naquele determinado local.

SÉRIES TEMPORAIS
Séries temporais são uma técnica estatística utilizada principalmente no cál-
culo de previsão de um conjunto de observações, dados seus valores ao longo do
tempo. O que faz essa técnica tão especial é a possibilidade de considerar, na análise,

155
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

a sazonalidade ou os ciclos intrínsecos ao processo, utilizando-os na predição de


valores futuros da série em questão ou na investigação de seu mecanismo gerador.
A série, em geral, é uma função do tempo, mas pode também ser uma função de
outro parâmetro físico, como espaço ou volume. Pode-se querer estudar o tráfego
de jovens, crianças e adultos em determinado ponto de um shopping center. Aí a série
analisada será em função do espaço.
Pensando-se em business, uma das mais importantes aplicações de séries tempo-
rais seria prever o volume de vendas, produção e estoque necessário em um período
futuro. Pode-se também analisar o comportamento dos índices diários das bolsas de
valores, fazer estimativas de inflação, entre outros. Negócios à parte, essa técnica é lar-
gamente utilizada em previsões climáticas (índices pluviométricos, previsões de tempe-
ratura etc.).
Na maioria dos negócios, a época do ano influencia o nível de demanda dos
produtos, devido às datas já consagradas pelo comércio, como Natal, Dia das Mães etc.,
ou devido ao clima, ou seja, há sazonalidade e ela deve ser levada em consideração para
evitar a detecção de falsas tendências do mercado, identificando-se tendências e varia-
ções reais.
Para que isso seja possível, é preciso que sejam armazenadas informações das
variáveis ao longo de um período que não pode ser curto, permitindo que sejam obser-
vadas repetidamente em ciclos distintos (várias vezes nos mesmos meses de diferentes
anos, por exemplo).
Um dos objetivos de uma análise de séries temporais seria investigar o mecanis-
mo gerador de uma série. Por exemplo, observando uma série de vendas de vestuário
feminino, pode-se querer analisar as causas das melhoras ou pioras desse ramo comercial.
Outro objetivo seria o estudo do comportamento de uma série. Só o fato de detectar
ciclos, tendências ou variações sazonais já pode ser útil na administração ou compreen-
são de um processo.
A complexidade dessa técnica está na escolha do modelo que melhor se adapte
à série observada e na definição dos parâmetros. Veja Previsão de séries temporais, de
Morettin e Toloi (1989).

MERCADOS E PRODUTOS DE DATA MINING


Com o crescimento dos conceitos de BI, com forte propensão às aplicações em
segmentos variados da indústria, os produtores de ferramentas especializadas em mining
se preparam para disputar um mercado com claras tendências de crescimento.
Os produtos de data mining podem ser classificados de maneira geral nos se-
guintes.

Ferramentas independentes de aplicação genérica


São ferramentas mais conhecidas por oferecerem um amplo conjunto de téc-
nicas e mecanismos de visualização. Podem oferecer abordagens mais simples, como
análise de regressão, até as mais complexas, como redes neurais, passando por regras

156
ELSEVIER
C APÍTULO 7 I D ATA M INING

de associação e análises de agrupamentos (clustering). Requerem uma equipe com for-


mação estatística para a preparação dos dados a serem garimpados, demandando um
tempo maior para a implantação do projeto. Entre os principais representantes dessa
classe estão: IBM DB2 Intelligent Miner, da IBM Corp; Enterprise Miner, do SAS Inc;
Clementine, da SPSS, que, após a incorporação da IBM, passou a se chamar IBM SPSS
Modeler; e a família Knowledge, da Angoss Software Corp. Alguns produtos, como o
da SPSS/IBM, permitem que todo o projeto de mining (desde a extração dos dados até
a publicação do modelo) seja exportado como um programa em C, por exemplo, para
ser aplicado modularmente em diversos sistemas de decisão da empresa. O produto da
IBM, DB2 Intelligent Miner, por sua vez, se apresenta em duas versões diferentes, sendo
uma dedicada exclusivamente ao mining de textos (IBM DB2 Intelligent Miner for
Text) e a outra à garimpagem de dados em geral (IBM DB2 Intelligent Miner for Data).

Ferramentas orientadas para algoritmos


São ferramentas mais voltadas para a aplicação de certos algoritmos e podem
oferecer melhor desempenho por essa causa. É necessário um perfeito entendimento do
problema a ser resolvido para o perfeito encaixe da melhor técnica a ser aplicada. Dessa
forma, essa classe de ferramentas mais específicas pode oferecer melhor resultado, se
comparado com as outras alternativas. Alguns dos produtos dessa classe são: Knowledge
Seeker, da Angoss, com ênfase em árvores de decisão, e NeuralWorks, da NeuralWare,
para as aplicações que requerem os complexos algoritmos de redes neurais.

Ferramentas orientadas a aplicações específicas


São ferramentas que sofreram certas adaptações para trabalhar com segmentos
específicos de aplicações, como CRM, data base marketing, textos e outras. São mais fá-
ceis de ser usadas, permitindo o desenvolvimento de aplicações orientadas por tutoriais,
mas devem ser consideradas sempre focadas em certos tipos de sistemas, não permitindo
grandes variações. Dentre os produtos dessa classe destacam-se o Portrait Customer
Analytics, da Portrait Software, adquirida pela Pitney Bowes, e os produtos da FICO
(Fair Isaac Company).

Ferramentas embutidas em soluções OLAP


São as ferramentas normalmente associadas a produtos de bancos de dados e
de aplicações de BI ou OLAP. Normalmente oferecem soluções mais simples, com al-
goritmos triviais, e são de fácil aplicação. Os representantes mais importantes dessa classe
são Business Miner, da Business Object, agora dentro da família SAP; o Scenario, da
Cognos, agora incorporado pela IBM; as ferramentas de data mining dentro do SQL/
Server 2008 da Microsoft; e a suíte de data mining da Oracle. A opção da IBM, com o
IBM DB2 Intelligent Miner, poderia também ser classificada nesse grupo, por sua forte
associação com o produto DB2, mas, na realidade, deve ser entendido mais como uma
solução independente que oferece robustos algoritmos de mining desenvolvidos pelos
laboratórios da empresa.

157
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Ferramentas e serviços de provedores externos


Representam soluções mais completas, pois envolvem a prestação dos serviços
de mining, além da utilização das ferramentas. Os serviços compreendem desde a abor-
dagem de metodologias para data mining até o hosting dos serviços de garimpagem de
dados, e se enquadram no novo conceito de DW Appliance, oferecido por gigantes
como IBM, Oracle e HP.

RESUMO
Este capítulo mantém praticamente as informações originalmente descritas
no livro BI – modelagem e tecnologia, com pequenas atualizações. Isso acontece até
porque as técnicas de data mining continuam as mesmas, centradas firmemente nas
sementes estatísticas e nos algoritmos preditivos. Na essência, sua aplicação dentro do
guarda-chuva conceitual de BI se dá pela forte aplicação que as técnicas de minera-
ção de dados desempenharão nesses novos ambientes de big data e de novas análises
sobre comportamentos (BHI), quando se fala de atitudes de compradores, de blo-
gueiros, de leitores e visitantes de sites etc., com ênfase em text mining e web mining.
Hoje já se percebem extensões nos domínios de suas aplicações. As redes neurais,
dentro do escopo de mining, têm sido aplicadas a tratamentos de inferências, atra-
vés da simulação do mecanismo cerebral fantástico de que fomos dotados quando
muitos milhões de neurônios se comunicam, formando uma rede de intercâmbio
de sinais que busca racionalizar um entendimento, por exemplo, para uma tomada
de decisão que fazemos. Como numa espécie de “síndrome do gato escaldado”, os
mecanismos neurais aprendem as consequências das diversas tomadas de decisões,
registrando aquelas que melhor se ajustaram às nossas intenções. Assim, toda vez que
uma situação semelhante for trazida para decisão, os circuitos neurais se incumbirão
dos devidos desvios, ativados pelos aspectos de cautela e alertas armazenados nas de-
cisões anteriores. No livro Super crunchers, de Ian Ayres, da Ediouro, alguns exemplos
de aplicações neurais ilustram a diversidade de domínios para onde se estendem as
aplicações de mining. Por exemplo, a Universidade do Arizona desenvolveu sistemas
de mining neural para previsão de ganhadores de corridas de cachorro, com a intro-
dução de mais de 50 tipos de informação, coletados de inúmeras corridas: atributo
físico do cachorro, treinadores, condições da corrida e classificação dos cães. Depois
de muitas simulações, alterando pesos para as variáveis etc., chegaram a uma equa-
ção estabelecida sobre centenas de corridas. Para avaliar a força do método, chama-
ram três especialistas em corridas e estabeleceram uma aposta de U$1 em 100 cães
diferentes. O modelo teve desempenho superior dos especialistas na previsão dos
vencedores. Também a previsão de faturamento de filmes, antes mesmo de serem
rodados, considerando diversas variáveis como atores, tema, cenas de sexo, locali-
zação, época prevista de lançamento, trilha musical etc., já está sendo aplicada por
empresas especializadas que dão consultoria aos grandes estúdios de Hollywood.
Outros segmentos estão sendo expostos à força dos algoritmos de mining. Por
exemplo, o Dr. Atai Winkler, renomado consultor em data mining, criou um BD

158
ELSEVIER
C APÍTULO 7 I D ATA M INING

com todos os livros da lista de best-sellers do NYTimes, de 1955 a 2004. Associou


a esse conjunto de dados um método baseado em regressão para estimar se certo
livro poderia se tornar best-seller, analisando um conjunto de 11 variáveis contidas
no título: O título começa com verbo? É um título metafórico, como Lágrimas de
pedra? Há verbo na primeira palavra, como Eram os deuses astronautas? Existe pro-
nome no início, como Seu sorriso de ontem? Os títulos são curtos ou longos? etc.
O estudo provou que títulos metafóricos e longos sempre se destacavam, entre
outros, mais literais e curtos. O modelo, claro, apresentou diversas imperfeições: o
livro com o título Um crime adormecido (Sleeping murder), de Agatha Christie, que
teve relativo sucesso de vendas, ficou no lugar mais alto dentre os avaliados como
os mais promissores (83%), enquanto O código da Vinci não recebeu alta cotação de
best-seller (36%), embora tenha se tornado um blockbuster. Esse ponto nos remete a
uma reflexão sobre a força da matemática computacional em produzir inferências
válidas ou até na produção de títulos, disputando espaço com os nossos mecanismos
mais elementares de criatividade.1**

1
Fonte: “Computador dá receita para titular best-seller”, obtido em: http://www2.uol.com.br/entrelivros/
noticias/computador_da_receita_para_titular_best-seller.html. Acesso em: 31 dez. 2010.

159
CAPÍTULO 8

Modelagem dimensional
de dados – detalhamento

INTRODUÇÃO
Os conceitos a serem discutidos neste capítulo são refinamentos da abordagem
dimensional vista no Capítulo 5. Naquele capítulo fizemos uma abordagem inicial so-
bre os modelos de dados, em geral, e os modelos dimensionais, em particular. Partimos,
então, daquele ponto, lembrando que o produto final da modelagem dimensional é um
modelo conceitual dimensional, formado por tabelas fato e tabelas dimensão.
 As tabelas fato servem para armazenar, normalmente, medidas numéricas
associadas a eventos de negócio. Uma tabela fato contém vários fatos, cor-
respondentes a cada uma de suas linhas. Cada fato pode armazenar uma
ou mais medidas numéricas, que constituem os valores objetos da análi-
se dimensional. Possuem como chave primária, normalmente, um campo
multi-key, formado pelas chaves primárias das dimensões que com ela se
relacionam. Normalmente armazenam muito mais linhas do que as tabe-
las dimensão e merecem cuidado especial em função do seu alto volume
e taxa de atualização. Contêm dados normalmente aditivos (manipulados
por soma, média etc.) e relativamente estáticos. Originam-se das entidades
encontradas no modelo relacional que representam ações, eventos, aconte-
cimentos, enfim, fatos que desejamos registrar. Daí a origem do seu nome.
Normalmente associadas também a eventos de negócios, as tabelas fato re-
presentam: pedidos, despachos, pagamentos, transações bancárias, reservas de
hotel, reservas aéreas, admissões em hospital, matrículas etc.
 As tabelas dimensão representam entidades de negócios e constituem as
estruturas de entrada que servem para armazenar informações como tempo,
geografia, produto, cliente etc. As tabelas dimensão têm uma relação 1:N
com a tabela fato e possuem um número significativamente menor de linhas
do que as tabelas fato. Possuem múltiplas colunas de informação, algumas
das quais representam a sua hierarquia. Apresentam sempre uma chave pri-
mária que lhes confere unicidade, chave esta que participa da tabela fato
como parte da sua chave múltipla. Devem ser entendidas como as tabelas
que realizam os filtros de valores aplicados na manipulação dos fatos e por
onde as consultas entram no ambiente do DW/DM. Normalmente estão
niveladas em hierarquia, apresentando entre os níveis um relacionamento
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

1:N também. Originam-se, normalmente, das entidades objetos encontradas


no modelo relacional: local, cursos, equipes, produtos, clientes etc.

A Figura 8.1 ilustra o conceito de tabelas fato e dimensão, num modelo dimen-
sional clássico. Nela aparecem três tabelas dimensão (produto, dia e loja) e uma tabela
fato (vendas). A Figura 8.2 ilustra a composição da tabela fato na qual cada linha repre-
senta um fato e as colunas-chave são herdadas das tabelas dimensão associadas. Além das
chaves, a tabela fato tem também as colunas com os valores das medidas definidas para
aquele modelo.

Figura 8.1
Exemplo de modelo dimensional clássico.

Figura 8.2
Composição básica de uma tabela fato.

162
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Após a aplicação de vários projetos de DW, percebe-se que as tabelas fato podem
ter certa taxonomia ou estilos. Podem ser classificadas em: fatos transações, fatos periódi-
cos e fatos acumulados. As tabelas fato transações representam o armazenamento de um
fato no seu nível de maior detalhe (mais granular). A Figura 8.3a mostra um modelo
clássico de controle de fatos de vendas no varejo, em que se armazenam a quantidade e
o valor do fato contextualizado pelo item NF (item da nota fiscal), ou seja, aquele fato
está expressando que naquele item de nota fiscal um produto foi vendido naquela loja,
naquele dia, na quantidade e nos valores especificados. Já a Figura 8.3b mostra uma es-
pécie de fato que, na realidade, acumula todos os itens vendidos relativos a certo produ-
to, em um período de tempo (dia) desaparecendo com a figura do item NF. Esse tipo de
fato é chamado, nessa taxonomia, de fato periódico, ou seja, representa um acumulado
num período de tempo (no caso, dia) definido.

Figura 8.3
Modelo dimensional com hierarquia de dimensões-vendas no varejo.

A Figura 8.4 mostra um fato que possui ligeiras diferenças com relação aos
anteriores. Nessa figura, aparece um fato que expressa o controle de atividades dentro
de um projeto. A dimensão data, presente no modelo, tem dois papéis: um de indicar
o início daquela atividade e outro de indicar o final dela no projeto. Observe que
algumas métricas associadas àquele fato dependem da finalização de outro evento
(término da atividade), além do que iniciou (início da atividade). Isso significa dizer
que aquele fato será criado num certo momento, mas algumas métricas associadas a
ele somente poderão ser produzidas após o fato consumado. Ou seja: esse tipo de fato

163
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

é criado num instante e depois modificado para a atualização de algumas métricas


(valores realizados). Esse tipo de tabela fato, quando possui normalmente diversas
datas para eventos diferentes que podem produzir valores diferentes, é chamado de
tabela fato acumulada.

Figura 8.4
Modelo dimensional atividades de um projeto.

PASSOS DA MODELAGEM DIMENSIONAL


Os passos aqui descritos devem ser considerados dentro de um processo maior,
que poderá ser centrado em uma abordagem ágil ou mesmo na forma tradicional de de-
senvolvimento de projetos de BI. No Capítulo 9 discutiremos os passos para os projetos
de uma aplicação BI e no Capítulo 11, abordaremos a aplicação do BI ágil. Os passos a
seguir descritos, relacionados à modelagem dimensional, devem ser considerados como
atividades naqueles contextos.

Definição de granularidade
A primeira é a determinação da granulidade desejada para o processo a ser
controlado. Essa análise é de fundamental importância, pois define de forma com-
binatória os níveis dimensionais que serão usados para o armazenamento dos dados.
Por exemplo, numa rede de supermercado, que deseja controlar o comportamento
de vendas de produtos por região ao longo do tempo, podemos ter várias possi-
bilidades: a trinca produto-loja-dia seria uma alternativa, como também seriam
possíveis outras variações, como produto-loja-mês (nesse caso, com a consolidação
na dimensão tempo, de dia para mês) ou produto-região-dia (aqui com consolida-
ção da dimensão geografia, de loja para região). Os fatores que definem a escolha
da granularidade estão relacionados diretamente com a necessidade da informação
naquele detalhe, com o volume de dados a ser mantido e com o processamento
necessário para produzi-lo. O volume pode ser estimado através de uma média de
combinação entre as dimensões. Por exemplo, suponha que em cada loja, na média,

164
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

em determinado dia, sejam vendidos 10 mil itens de produtos. Se tivermos 200 lo-
jas e desejarmos armazenar os dados por 10 anos (365*10) teremos algo em torno
de (10.000*200*3650) 7,3 bilhões de registros. Se considerarmos que teremos três
chaves (chave-produto, chave-loja, chave-dia, cada qual com 5 bytes) e três valores
numéricos (cada qual com 4 bytes) teremos a bagatela de 7,3 bilhões de registros
vezes 27 bytes (15 + 12), o que levará a um montante de 189 gigabytes, sem contar
gastos com índices e outras tabelas acessórias.
Note que estamos considerando somente uma tabela fato. Perceba que qualquer
acréscimo em uma das variáveis dimensionais pode elevar o volume calculado a pata-
mares estratosféricos. Aqui caberia, entre outros, um questionamento sobre a dimensão
temporal. Dez anos são suficientes para perceber os padrões escondidos de comporta-
mento de vendas de produtos em lojas cujas ferramentas de data mining se propõem a
revelar? O outro aspecto importante na definição da granularidade é o trabalho para se
chegar a ela.Verifique que, em nosso exemplo, a granularidade foi definida em termos
de produto-loja-dia, o que nos faz pressupor que teremos um processamento diário de
consolidação para transformarmos os nossos registros (transações) de vendas (com os
seus itens) em totais por produto e por loja. Isso pode ser feito automaticamente nos
vários caixas automáticos (PDV) e enviados na janela da noite para uma central de atua-
lização do DW. A granularidade pode variar na dimensão temporal entre diária, mensal
etc. No nível de documentos que definem transações, o item menor pode ser a granu-
laridade ideal. Por exemplo, os itens de uma OC (ordem de compra), NF (nota fiscal),
OE (ordem de expedição) e apólice são normalmente definidos como a granularidade
mais informativa. De maneira geral, deve-se sempre partir de modelos que contemplem
a maior granularidade possível (maior detalhe), pois dela poderão ser obtidos todos os
outros níveis desejados de granularidade superior.

Definição das tabelas dimensão


Note que as dimensões já foram discutidas, até porque a especificação da granu-
laridade, feita no passo anterior, depende delas. No caso, as dimensões definidas foram
produto-loja-dia. Observe que as dimensões geografia e tempo (loja e dia, nesse exem-
plo específico) quase sempre estarão presentes nos projetos de DW. O importante nessa
etapa é a hierarquia das dimensões e a definição dos atributos restantes de cada dimen-
são. Por exemplo, na dimensão tempo, podem existir uma ou mais hierarquias como
ANOoMÊSoDIA, espécie de hierarquia natural ou ESTAÇÃO DO ANOoDIA,
hierarquia formada pela presença de atributos do nível, como ESTAÇÃO DO ANO.
No caso da dimensão PRODUTO, podem existir várias hierarquias também, como
CATEGORIAoPRODUTO ou MARCAoPRODUTO. No caso das lojas, po-
deríamos ter hierarquias como REGIÃOoLOJA, do ponto de vista geográfico ou
REGIÃO-VENDAoLOJA, do ponto de vista de gerência de vendas, montada por
atributo de nível. Todas essas hierarquias de dimensões comporão, na forma de atribu-
tos, os registros das tabelas dimensão. Dessa forma, as nossas tabelas dimensão estariam
assim constituídas:
TdLoja (chave-loja, nome-loja, endereço-loja, cidade-loja, estado-loja, cod-re-
gião, região-venda)
TdProduto (chave-produto, marca, categoria, tipo-embalagem, departamento)
TdDia (chave-dia, mês, ano, período-fiscal, estação-ano)

165
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

A Figura 8.5 mostra um esquema dimensional com as hierarquias de dimensões


das tabelas definidas anteriormente, com a notação destacando os atributos de níveis, em
círculos escuros. Observe que as várias hierarquias de dimensões aparecem no modelo,
possibilitando caminhos alternativos de acesso aos dados da tabela fato.

Figura 8.5
Modelo dimensional-hierarquia de dimensões.

A Figura 8.6 mostra um esquema dimensional semelhante, com maior nível de


detalhamento, tanto nas dimensões quanto em fato. As dimensões estão estruturadas
em níveis de maior profundidade e a fato está com um número maior de métricas.
Também aparecem outros atributos de níveis, como semana e feriado (dia), região de
venda e gerente (loja) e marca comercial e tipo (produto). Nos atributos da classe tipo,
maior riqueza semântica pode ser colocada no esquema. A ideia é a mesma adotada
em modelos tradicionais, quando se usam os conceitos de classificação e generaliza-
ção, também chamados de tipo e subtipo. O objetivo é caracterizar a cobertura do
domínio (total ou parcial) e a disjunção dos valores (disjuntos ou sobrepostos). No
exemplo, mostra-se a combinação DP (disjunção = disjunto e cobertura = parcial).
Isso significa que os produtos poderão ser do tipo (diet, light, normal), não podendo ser
dois deles ao mesmo tempo, ou seja, diet e light simultaneamente. A cobertura parcial
diz que há produtos que se encaixam em outro tipo não elencado naquela lista, ou
seja, a enumeração dos valores é parcial. Esses conceitos são extensões semânticas que

166
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

podem enriquecer o modelo, carregando mais informações relevantes para o projeto.


A Figura 8.6 ainda mostra um atributo de nível, para LOJA (região de venda), que
está associada diretamente ao nível de país. Isso significa que região de venda é um
conceito que extrapola a hierarquia natural de região, estado e cidade, ligando uma
loja a uma hierarquia alternativa PAÍSoREGIÃO-VENDAoLOJA. Esse conceito
é denominado convergência e deve ter a sua integridade verificada no nível de ETC
(fase de extração, transformação e carga), garantindo que toda loja esteja associada a
uma região de venda, válida no país.

Figura 8.6
Modelo dimensional – detalhe.

Normalização das tabelas dimensão


As tabelas dimensão, diferentemente das tabelas fato, estão mais sujeitas ao pro-
cesso de desnormalização. Existem duas correntes diferentes com relação aos aspectos
de normalização das tabelas dimensão:
 STAR SCHEMA. Esquema estrela: abordagem que recomenda a não nor-
malização das tabelas dimensão.
 SNOWFLAKE SCHEMA. Esquema de flocos de neve: abordagem que re-
comenda a normalização das tabelas dimensão.

167
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Observe que na tabela dimensão LOJA (TDLoja), eu tenho o código da re-


gião (cod-região), mas não tenho sua descrição, que provavelmente estará em outra
tabela. Caso eu desejasse manter essa informação de descrição na própria tabela
TDLoja, estaria adotando a estratégia de star schema. Caso contrário, estaria, com
a abordagem snowflake schema, que sugere, na realidade, que as tabelas dimensão
fiquem normalizadas numa espécie de camadas, daí o nome flocos de neve. O mes-
mo acontece com a tabela TDProduto. A descrição da categoria do produto poderia
estar dentro da tabela dimensão produto (star schema) ou na tabela de categoria,
caracterizando o snowflake. A Figura 8.7 mostra um esquema com as duas dimen-
sões projetadas (loja e produto), segundo a abordagem snowflake, com as diferen-
tes informações distribuídas em níveis hierárquicos, com a possibilidade de maior
overhead no processamento das junções entre elas, sendo quatro na dimensão loja e
três na dimensão produto. Na Figura 8.8, a dimensão produto está projetada como
esquema estrela, mostrando as três tabelas unidas em uma só estrutura (categoria,
subcategoria e produto), evidenciando, por outro lado, a redundância, pela replica-
ção dos dados de categoria e subcategoria em cada instância de produto. Nesse caso,
o número de junções foi reduzido a uma.

Figura 8.7
Modelo dimensional – snowflake.

168
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.8
Modelo dimensional – star schema.

A utilização do esquema estrela é extremamente recomendável, pelos aspec-


tos de ganhos de desempenho, quando comparada com o esquema de flocos de neve.
Lembre-se de que a redundância no caso do esquema estrela será amplamente com-
pensada pelas reduções de comandos de junção, que seriam necessários para recom-
por a informação desejada, buscando-a em outras tabelas. Como as tabelas dimensão
requerem menos espaço quando comparadas com as tabelas fato, o que será efetiva-
mente poupado, no caso de snowflake, será certamente desprezível, comparado com
os espaços requeridos pelas tabelas fato. Em um projeto de data warehouse, o grande
espaço consumido fica por conta das tabelas fato, exatamente pelo seu volume expo-
nencial, proporcional à granularidade definida. Considere, para efeito de raciocínio, o
seguinte cenário: suponha uma tabela categoria de produtos, composta de dois campos:
um campo código-categoria, com 2 bytes, e outro campo descrição-categoria, com
13 bytes. Se pensarmos em snowflake, a tabela produto terá somente o código da ca-
tegoria, que será a FK, necessária ao relacionamento, ou seja, mais 2 bytes. Se fosse em
um esquema estrela, a tabela produto teria os dois campos, o que acresceria o tamanho
em 13 bytes. Se considerarmos uma dimensão com 200 mil produtos, teremos um
ganho em snowflake da ordem de 2,6 megabytes, comparado com o esquema estre-
la. Se considerarmos que um DW dessa natureza poderia ter 260 gigabytes, o ganho
na economia de espaço será de 0,00001%, absolutamente desprezível se pensarmos
em termos de desempenho ganho pela supressão dos comandos join entre as tabelas.
Quando vários esquemas estrelas são unidos por dimensões compatíveis, comuns entre

169
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

eles, tem-se uma conformação denominada esquema multiestrela. Essa é a forma de


definir data marts interligados, que gradativamente formarão uma estrutura de data
warehouse, quando se adota a estratégia bottom-up. Para tal, é importante que as di-
mensões guardem entre si uma compatibilidade e as tabelas fato estejam definidas em
granularidade compatível com as diversas dimensões interligadas. A Figura 8.9 ilustra os
conceitos de esquema estrela, esquema flocos de neve e esquema multiestrela, sendo este
último uma forma de integração de esquemas estrelas através de dimensões compatíveis.

Figura 8.9
Modelo dimensional – star schema, snowflake e multiestrela.

Relacionamentos de atributos das tabelas dimensão


As tabelas dimensão carregam atributos que estabelecem relacionamentos entre
si. É necessário um processo cuidadoso de modelagem para melhor distribuí-los no
esquema dimensional. O exemplo anterior mostrou as estratégias de normalização de
tabelas dimensão, separando os atributos em hierarquias e criando o estilo snowflake,
com suas vantagens e desvantagens. De maneira geral podemos caracterizar os relacio-
namentos entre tabelas dimensão da seguinte forma:
 As tabelas dimensão de uma hierarquia normalmente não possuem relacio-
namentos com outras de quaisquer hierarquias e, dessa forma, as dimensões
ficam independentes. Por exemplo,TEMPO e LOJA, num modelo dimensio-
nal de varejo, não guardam relacionamento direto, com exceção da interseção
feita pela tabela fato, que de certa forma estabelece uma junção entre elas.

170
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

 Os níveis dentro da dimensão possuem relacionamento hierárquico rigoro-


so, ou seja, 1:N. Por exemplo, REGIÃOoCIDADEoLOJA guardam estri-
ta forma de 1:N entre elas. Uma loja se relaciona somente com uma cidade,
e uma cidade pertence somente a uma região.
 Os atributos de uma dimensão podem possuir relacionamentos M:N entre eles.
Por exemplo, suponha um modelo dimensional para controle de venda de livros
e arrecadação de direitos, conforme a Figura 8.10. A dimensão LIVRO tem um
relacionamento com AUTOR na proporção M:N, ou seja, um autor pode ter
vários livros, e um livro pode ter vários autores. Essas entidades poderão produ-
zir uma tabela de relacionamento na qual se teria a porcentagem de direito de
cada autor naquele livro e a dimensão LIVRO seria a entidade relacionada com
a tabela fato do modelo. A matriz, abaixo do desenho, na Figura 8.10, mostra
uma possível view contendo os valores vendidos daquele livro, naquele mês, com
a porcentagem de distribuição dos direitos entre os autores.

Figura 8.10
Modelo dimensional – dimensões-relacionamentos M u N.

171
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Definição dos atributos das tabelas fato


Observe a Figura 8.11. Ela apresenta, mais uma vez, a clássica visão produto-loja-
-dia, compondo as vendas na tabela fato. A tabela fato conterá as chaves das dimensões
(chave-produto, chave-loja, chave-dia), além dos dados, normalmente numéricos, que
desejamos registrar para efetivamente abastecer os processos de gerência nas suas to-
madas de decisão. Esses valores estarão na interseção das dimensões e, normalmente,
estão relacionados com quantidade-vendida, valor-vendido, preço-unitário, valor-de-
-custo etc. São chamados de métricas, pois normalmente são somados e trabalhados nas
diversas dimensões.

Figura 8.11
Modelo dimensional – tabela fato com métricas em destaque.

Tipos de métricas
Aditivas
Quando os valores são passíveis de serem somados em todas as dimensões, como,
por exemplo, valor-vendido ou valor-custo.

Semiaditivas
Quando sua soma (ou tratamento estatístico qualquer) tiver sentido somente
em algumas dimensões, mas não em todas, como, por exemplo, quantidade-vendida.

172
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Observe que a quantidade-vendida teria sentido de ser acumulada na dimensão produto


(o velho conceito de quebra por produto). O mesmo valor (quantidade-vendida) acu-
mulado na dimensão loja teria um valor de pouca utilidade (somatório das quantidades
vendidas de todos os produtos na loja), ou seja, estaria somando quantidades de coisas
absolutamente sem sentido (somando laranjas com bananas), o que representa informa-
ção pouco interessante.

Não aditivas
Quando determinado valor não puder ser somado em qualquer dimensão ou
sempre produzir um valor sem nenhum sentido válido. É o caso do valor de porcenta-
gem de lucro (valor-vendido  custo/valor-vendido) ou qualquer outro tipo de rela-
ção/razão entre métricas.

Os cuidados com a aditividade


A colocação de métricas dentro de uma tabela fato deve ser revestida de uma
análise cuidadosa, pois pode implicar resultados errados, quando manipulados por ope-
radores indevidos.
Uma importante ação é observar a natureza da medida. Existem algumas classi-
ficações de métricas que sugerem maior ou menor aditividade:
a) Medidas de fluxo de valores: são normalmente associadas a vendas de
produto, expressas em moedas, como valores vendidos ou expressões de
fatos, como número de nascimentos por unidade de tempo. Essas métri-
cas normalmente são processadas por soma, média, mínimo e máximo.
Por exemplo, a quantidade de produtos P1 vendidos no mês 1 pode ser
somada com a quantidade de produtos P1 vendidos no mês 2. Posso
obter também a média vendida nos dois meses ou obter a maior venda
ou a menor venda, ou seja: há plena aditividade dessa métrica, indepen-
dentemente da dimensão pela qual se faça seu tratamento.
b) Medidas de nível: são normalmente associadas com medições feitas,
que representam valores cumulativos, caracterizando certo nível. Por
exemplo, o número de peças em estoque no mês 1 não pode ser so-
mado com o número de peças em estoque no mês 2. Aqui a soma não
produz resultado correto, mas a média, o máximo e o mínimo podem
ser aplicados.
c) Medidas relativas: são normalmente valores relativizados a uma base. Por
exemplo, porcentagem de desconto ou taxa de conversão de dólar/real. Es-
ses valores normalmente também não são submetidos à operação de soma,
mas podem suportar média, como a porcentagem média de desconto do
trimestre.

173
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Vamos dar um exemplo, analisando algumas ocorrências da tabela fato, mos-


trada na Figura 8.11. Observe que, na Figura 8.11, existe uma tabela fato com
quatro métricas: QUANTIDADE, VALOR, PREÇO-UNITÁRIO MÉDIO e
#CLIENTES (número de clientes). Observe a Figura 8.12 e vamos supor que
no dia D1 houve duas vendas, com emissão de duas notas fiscais (NF1 e NF2), e
no dia 2, uma venda com a emissão da nota fiscal NF3. Cada venda foi feita para
determinado cliente diferente. Nesse espaço de tempo, os dados acumulados na
TFato, seguindo o esquema da Figura 8.11, seriam os mostrados nas quatro ocor-
rências apresentadas. Observe que o número de clientes colocados na tabela fato
corresponde ao número de notas fiscais emitidas que compuseram aquele fato. Os
registros da TFato, devidamente contextualizados pelas suas instâncias de dimensões
(L1,D1,P1; L1,D1,P2; L1,D1,P3; L1, D2,P1), como mostrados, foram produzidos
pelo processamento ao final de cada dia, através do processo ETC (extração, trans-
formação e carga). As Figuras 8.13 a 8.19 mostram as diferentes agregações (group
by), que são os elementos operadores que permitem a manipulação dos valores da
tabela fato e as consequentes operações matemáticas sobre eles. À TFato original
que aparece nessas figuras foram acrescidas duas vendas também da loja L2, para
compor uma amostra mais realista.

Figura 8.12
Exemplo de aditividade de métricas – métricas aditivas,
semiaditivas e não aditivas.

174
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.13
Exemplo de aditividade de métricas – métricas aditivas.

Figura 8.14
Exemplo de aditividade de métricas – métricas aditivas.

175
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 8.15
Exemplo de aditividade de métricas – métricas aditivas e não aditivas.

Figura 8.16
Exemplo de aditividade de métricas – métricas aditivas.

176
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.17
Exemplo de aditividade de métricas – métricas aditivas e não aditivas.

Figura 8.18
Exemplo de aditividade de métricas – métricas aditivas e não aditivas.

177
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 8.19
Exemplo de aditividade de métricas – exemplo de overcounting.

Cada figura mostra o conjunto original de registros na TFato (tabela superior)


e o resultante das respectivas operações, na tabela inferior. O comando de transfor-
mação de uma na outra é o tipo de group by executado. Dependendo do tipo de group
by, teremos valores coerentes ou incoerentes.
Vamos analisar a Figura 8.13, com o operador group by por produto (P) e loja
(L). Isso significa somar, por loja e produto, as quantidades vendidas e os valores vendi-
dos. Observe que houve a agregação do produto P1 na loja L1, somando as suas duas
linhas da TFato e obtendo os valores 25 (10 + 15) e 250 (100 + 150). Os resultados
foram coerentes, ou seja, faz sentido somar valor de venda ou quantidade, fixando ou
agrupando pela dimensão produto.
A Figura 8.14 mostra, na mesma linha de coerência, o agrupamento por pro-
duto, independentemente do dia e da loja (Group by P). Observe que, ainda assim,
existe coerência na agregação das métricas, originando valores possíveis: o quanto
(quantidade) do produto P1 foi vendido em todos os dias (analisados) e em todas as
lojas. Da mesma forma, qual faturamento (valor) do produto P1 foi alcançado em
todos os dias (analisados) e em todas as lojas.
A Figura 8.15 mostra uma agregação feita por loja (Group by L). Estou soman-
do, para cada loja, as quantidades de venda e os valores vendidos de todos os produtos
em todas as lojas. Nesse caso, o atributo valor, presente na métrica, é considerado
métrica aditiva para essa dimensão, pois produz valores plausíveis, ou seja, quanto a

178
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

loja faturou. Já a métrica quantidade não é aditiva, nessa dimensão, pois produz va-
lores sem sentido (quantidade vendida de todos os produtos, em todas as lojas). Estou
somando quantidade de produtos eletrônicos com quantidade de produtos de varejo,
de limpeza etc., produzindo algo não lógico.
A Figura 8.16 mostra a agregação por produto e dia, ou seja, a quantidade de
vendas e os valores vendidos dos produtos, ao longo dos dias. Esse valor terá compor-
tamento semelhante ao da Figura 8.14, produzindo métricas aditivas. Isso quer dizer
que tanto a quantidade quanto o valor vendido podem ser somados ao longo de dias,
não implicando resultados estranhos. No fundo, essa agregação (da Figura 8.16) é uma
forma mais seletiva da agregação apresentada na Figura 8.14. Enquanto na primeira
estavam as métricas para produtos, independentemente de loja e dia vendido, ela agre-
ga considerando a dimensão tempo também.
A Figura 8.17 terá o mesmo comportamento da Figura 8.15, em termos de
aditividade das métricas. A métrica valor-vendido será aditiva ao longo dessas duas
dimensões, mas a métrica quantidade não. Ela continua a produzir agregados que
envolvem coisas de naturezas diferentes.
A Figura 8.18, com a agregação somente por dia, implicará valores estranhos
para quantidade também, pois estou somando quantidade de coisas diferentes, vendi-
das num certo dia.
A Figura 8.19 mostra um exemplo, ligeiramente modificado com relação aos
anteriores, pois passa a contemplar a métrica número de notas fiscais. Observe que
qualquer agregação que seja feita poderá implicar o fenômeno do overcounting, ou seja,
a contagem repetida de valores. No caso, ao agrupar por loja e dia, obteve-se o valor
de quatro notas fiscais, quando, na realidade, a loja L1 vendeu no dia em duas notas
fiscais, conforme a Figura 8.12.

Granularidade das tabelas fato


Observe que, em nosso exemplo, a trinca de chaves da tabela fato oferece
unicidade às linhas (não posso ter mais de uma ocorrência do mesmo produto, ven-
dido na mesma loja, no mesmo dia, visto que existe uma totalização por dia). Uma
alternativa, caso a granularidade fosse em nível de transação, seria definir como chave
primária a concatenação do número-nota-fiscal e o número-item, e dessa forma
o tamanho em bytes da tabela fato cresceria algo em torno de 8 bytes. A tabela fato,
nesse nosso projeto, teria o seguinte leiaute:
TfVendas (chave-loja, chave-produto, chave-dia, nfiscal + item (valor-ven-
dido-real,custo-real, lucro, qtd-vendida), o que corresponderia praticamente a
cada linha de cada nota fiscal vendida naquela loja, naquele dia. Esse seria pratica-
mente o maior nível de detalhamento que se poderia alcançar na TFato, a menos
que se desejasse o controle na dimensão temporal, abaixo de dia. Por exemplo,

179
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

suponha que se desejasse controlar, no exemplo anterior, as vendas em nível de


faixas horárias. Assim, teríamos 24 faixas de horas, supondo que a empresa funcio-
nasse 24 horas. A hierarquia temporal ganharia mais um nível abaixo de dia. Dessa
forma, a chave dia seria substituída por chave-faixa-hora, e o número de linhas
da TFato poderia ser multiplicado por até 24 vezes. Os valores, agregados por dia,
seriam distribuídos em 24 registros, cada um em uma faixa de horário. A Figura
8.20 ilustra o conceito.

Figura 8.20
Modelo dimensional – dimensão tempo com maior granularidade.

Lembre-se de que a granularidade da tabela fato é a grande responsável pelo seu


volume. Assim, o nível de granularidade da tabela fato deverá ser analisado com muito
cuidado, considerando-se:
 O volume de dados que implica o seu armazenamento.
 O nível de detalhe que se deseja alcançar nas análises porque, além do
nível da tabela fato, somente o acesso aos dados transacionais em níveis de
maior detalhe poderia resolver as eventuais necessidades de um relatório
solicitado.

180
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Campos armazenados e campos virtuais na tabela fato


A escolha dos campos da Tabela Fato passa por critérios de custo- benefício,
alguns tradicionais na informática, como espaço de armazenamento versus desem-
penho. Alguns campos, como o lucro, poderiam ser obtidos em tempo de processa-
mento, sem a necessidade de seu armazenamento. Isso elevaria o tempo de resposta
da transação, mas ofereceria economia de espaço, visto serem as tabelas fato as maio-
res consumidoras desse recurso. Em outros casos, alguns campos poderiam ser obti-
dos através de drill-through, com a sua busca nos arquivos de origem, normalmente
nos domínios transacionais e com as mesmas considerações de armazenamento e
desempenho.

MODELAGEM DIMENSIONAL DE DADOS – CONCEITOS


AVANÇADOS

Introdução
Os conceitos a serem discutidos, a partir de agora são refinamentos da abor-
dagem dimensional introdutória mostrada anteriormente. Serão analisados casos
especiais de tabelas fato e tabelas dimensão, considerando-se as seguintes particu-
laridades:
1) Conformidade de dimensões
2) Dimensões especiais
3) Dinâmica das dimensões
4) Dimensões degeneradas
5) Dimensões lixo (junk)
6) Campos-chave de dimensões e fatos
7) Tabelas fato sem dados ou métricas
8) Tabelas fato com classificação ou subtipos
9) Relacionamentos M:N entre fatos e dimensões
10) Agregados

Conformidade de dimensões
A conformidade de dimensões representa a coerência de definições entre
dimensões estabelecidas em momentos diferentes do projeto de DW/DM. É funda-
mental que as dimensões tenham sempre o mesmo sentido semântico para que os
diversos esquemas dimensionais de diferentes DM possam ser “cruzados”, produ-
zindo informações compatíveis. Essa é a principal dificuldade para criar DM (data
marts) evolutivos, pois corre-se o risco de criar modelos dimensionais incompatí-
veis. A equipe de projeto, como já foi dito, deverá cuidar para que na fase de pla-

181
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

nejamento as principais dimensões do negócio em modelagem sejam identificadas,


consentidas e documentadas, criando-se no repositório/catálogo uma forma acessí-
vel de informações sobre elas (as dimensões). Uma regra básica para definir confor-
midade de dimensões é, sempre que possível, defini-las no maior grau de granula-
ridade (mais detalhada) possível. Para as dimensões clássicas, como tempo, procurar
definir a menor unidade desejada (dia ou hora, dependendo da necessidade do
negócio), com as hierarquias completas como ANO-SEMESTRE-TRIMESTRE-
-MÊS-DIA. O uso compartilhado de tabelas dimensão e o objetivo de estabelecer
conformidade entre elas permitirão a consistência na produção de informações e
garantirá a possibilidade de adotar a estratégia evolutiva para DW/DM, inclusive
com equipes diferentes participando dos projetos, em tempos diferentes. Algumas
considerações importantes:

 Existem casos em que as dimensões serão acessadas por usuários diferentes


através de hierarquias diferentes. Por exemplo, considere a dimensão pro-
duto, que poderá ter hierarquias diferenciadas sobre ela. Poderíamos ter
CATEGORIA oPRODUTO ou FABRICANTE oPRODUTO. Am-
bas serão resolvidas, no esquema estrela, através da incorporação das chaves
estrangeiras e outros dados na tabela dimensão produto.
 Existem casos em que a dimensão TEMPO poderá merecer considerações
especiais. Suponha a hierarquia ANO oTRIMESTRE oMÊS oSEMA-
NA oDIA. Observe a leitura que se faz: um ano tem vários trimestres, mas
cada um desses trimestres pertence somente a um ano. Cada trimestre possui
vários meses (três), mas cada mês pertence somente a um trimestre. Cada
mês possui várias semanas (quatro ou cinco), mas cada semana... Aqui existe
um pequeno probleminha. Uma semana pode pertencer a dois meses, caso
em que os dias comecem em um mês e terminem em outro. Isso significa
que SEMANA não faz roll-up com MÊS. Isso exigirá a definição de uma
hierarquia como ANO oTRIMESTRE oMÊS oDIA que, dessa for-
ma, permite roll-up nos seus diferentes níveis. A Figura 8.21 mostra o projeto
com essa hierarquia para a dimensão tempo, com a devida compatibilização
dos roll-ups. Observe que a semana ficou como um atributo do nível dia e
permitirá recuperações de informações, mas não está no caminho do roll-up.
A Figura 8.22 ilustra o conceito de roll-up indevido, caso os cuidados com as
devidas hierarquias de dimensões não sejam observados. Considere que, por
exemplo, os dias D5, D6, D7 sejam do mês M2 e D1, D2, D3 e D4 sejam
dias do mês M1. O roll-up desses dias (soma do nível menor, armazenando
no nível maior) seria armazenado na semana S5, que tem a particularidade
de estar associada a dois meses diferentes. Isso faria com que os valores no
nível dos meses M1 e M2 estivessem indevidos, com soma de valores de dias
que não lhes pertencem.

182
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.21
Roll-up dimensão tempo – semana como atributo.

Figura 8.22
Roll-up dimensão tempo – semana na hierarquia.

Existem algumas propostas para tentar resolver, ou pelo menos atenuar, os im-
pactos de rupturas potencialmente provocadas pelas dimensões em não conformidade.
Uma delas passa pelo estabelecimento de uma grande área de Staging, chamada de
Staging Super Marts, em que as dimensões seriam armazenadas antes de serem levadas
aos data marts que as originou. Nesse banco de dados, as dimensões e suas instâncias

183
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

estariam bem definidas, com os seus relacionamentos consentidos e documentados, via


sinônimos. Um modelo de dados, para essa abordagem, poderia ser algo como sugerido
na Figura 8.23. A figura mostra o clássico modelo recursivo de classes e atributos, usado,
nesse contexto, para armazenar as dimensões, seus sinônimos, suas instâncias e os seus
relacionamentos. Isso permitiria, em certo nível, controle e gerência sobre as dimensões
dos diferentes DM com a possibilidade de maior controle no momento de estabelecer
as ligações entre esquemas dimensionais.

Figura 8.23
Modelo relacional – metamodelo de dados sugerido para controle de
conformidade de dimensões.

Dimensões especiais
Algumas dimensões são consideradas clássicas e presentes em quase todos os
projetos de DW/DM. Estão relacionadas com o TEMPO, o ESPAÇO e o OBJETO
dos sistemas. Como um projeto de DW/DM foca muito a evolução dos dados his-
tóricos, a dimensão TEMPO é de absoluta necessidade nesses projetos. O comporta-
mento dos fenômenos, de maneira geral, além do tempo, varia com o LOCAL. Essa é
outra dimensão comum nos projetos e se manifesta na forma de tabelas como LOJA,
ARMAZÉM, ÓRGÃO, LOCAL etc.Todas essas manifestações estão associadas a uma
hierarquia geográfica de amplitude variando do maior para o menor espaço (PAÍS,
ESTADO, REGIÃO, CIDADE etc.). Combinando com essas duas dimensões clássi-
cas, aparecem as dimensões mais voltadas para o objetivo de negócios do sistema e
seriam, digamos, os objetos personalizados daquela aplicação: CLIENTE, PRODU-
TO, MÚSICA, PESSOAS etc. É importante entender que, quanto mais rica for a

184
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

definição das dimensões, com relação a seus atributos, maior será a possibilidade de
análises complexas e sofisticadas, tanto nas aplicações OLAP quanto nas de MINING.
Lembre-se de que as dimensões são a porta de entrada dos DW/DM. Através delas
(no fundo, via seus atributos), poderemos navegar por pesquisas indexadas que sem-
pre estarão apontando para os fatos a elas relacionados. As dimensões clássicas, como
TEMPO e CLIENTE, já foram exaustivamente detalhadas e encontram-se ricas re-
ferências a respeito.
 DIMENSÃO TEMPO: é uma dimensão clássica e mandatória em projetos
de DW e contém vários atributos. Se a granularidade definida for DIA,
poderemos ter os seguintes atributos, além da chave da dimensão a ser dis-
cutida futuramente:
 DATA-COMPLETA. Ex.: 01- 01-2000
 DIA-SEMANA. Ex.: 6ª-FEIRA
 NÚMERO-DIA-MÊS. Ex.: 01
 NÚMERO-DIA-GERAL-CORRIDO-NO-ANO (01- 365)
 NÚMERO-SEMANA-MÊS (01 a 04 ou 05 )
 NÚMERO-SEMANA-GERAL-CORRIDO (01 a 52)
 MÊS-ANO (janeiro a dezembro)
 NÚMERO-MÊS-GERAL-CORRIDO (01-12)
 TRIMESTRE (01-0 4)
 PERÍODO-FISCAL (normalmente de 01 a 04)
 TAG-DIA-FINAL-SEMANA (indica se sábado ou domingo)
 TAG-ÚLTIMO-DIA-MÊS (indica se é último dia do mês)
 TAG-FERIADO (indica se é feriado)
Observe que existem atributos, como indicador de final de semana, indica-
dor de final de mês, indicador de feriado, que permitirão análises interessantes sobre
acontecimentos e comportamentos dos negócios, nesses momentos. Se estivermos
falando de um DW/DM de vendas poderemos comparar os fatos de vendas nesses
períodos diferenciados. Em um projeto de DW/DM de controle de audiência de TV
a cabo, por exemplo, esses atributos da dimensão tempo tornar-se-ão imprescindíveis
para a análise de comportamento dos assinantes. A dimensão TEMPO deverá ser pla-
nejada de acordo com a sua perspectiva de uso (quatro anos, oito anos etc.) e a tabela
dimensão TEMPO deverá ser carregada na totalidade no início do projeto, já que as
suas informações são conhecidas e independentes das tabelas fato com as quais serão
relacionadas. Quando há necessidade de controlar os fatos em nível de hora, pode-se
criar outra dimensão, composta por Hora-Minuto-Segundo, dependendo da granu-
laridade desejada.
 DIMENSÃO CLIENTE: essa dimensão, obviamente importante em qual-
quer sistema, ganhou maior expressão com o crescimento dos conceitos de

185
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

CRM (Customer Relationship Management) e de CDI (Customer Data Integra-


tion). O detalhamento de informações sobre o cliente passou a ser requisito
fundamental no desenvolvimento de sistemas destinados a definir aspectos
diferenciais de negócios. Quem conhecer melhor o seu cliente, maior chan-
ce terá de manter a sua fidelização, ou de buscar novos negócios através
desses relacionamentos. O conjunto de atributos de um cliente poderá va-
riar com o seu tipo, mas de maneira geral alguns serão sempre importantes,
além da chave:

SAUDAÇÃO Ex.: DR.


PRENOME E NOME DO MEIO Ex.: ROBERTO PEREIRA
SOBRENOME Ex.: CARDOSO
SUFIXO Ex.: JR.
ETNIA DO NOME Ex.: PORTUGUÊS
GÊNERO Ex.: MASCULINO
TÍTULO Ex.: ADVOGADO
E-MAIL Ex.: RCARDOSO@BARBIX.COM.BR
SITE Ex.: WWW.BARBIX.COM.BR
CLASSIFICAÇÃO Ex.: 05
SUBCLASSIFICAÇÃO Ex.: 03
ORGANIZAÇÃO Ex.: BAR@BI-BUSINESS INTELLIGENCE
SUBORGANIZAÇÃO Ex.: DEPARTAMENTO JURÍDICO
SEGUNDO NÍVEL DA ORGANIZAÇÃO Ex.: SEÇÃO DE ANÁLISES DE LITÍGIOS
NÚMERO DO ENDEREÇO Ex.: 4.300
NOME DA RUA Ex.: AVENIDA URUGUAI
TIPO DA RUA Ex.: AVENIDA
DIREÇÃO Ex.: SUL
CAIXA POSTAL Ex.: 2348
CONJUNTO/ALA (SUÍTE) Ex.: B2
COMPLEMENTO Ex.: C1
CIDADE Ex.: BELO HORIZONTE
DISTRITO Ex.: SION
ESTADO Ex.: MINAS GERAIS
PAÍS Ex.: BRASIL
CONTINENTE Ex.: AMÉRICA DO SUL
CODIGO POSTAL PRIMÁRIO Ex.: 30190
CÓDIGO POSTAL SECUNDÁRIO Ex.: 131
TELEFONE-CÓDIGO-PAÍS Ex.: 55
CÓDIGO-ÁREA Ex.: 31
TELEFONE Ex.: 525-8798
FAX-CÓDIGO-PAÍS Ex.: 55
PAGER Ex.: 33-671

186
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Nos projetos de DW/DM de empresas de utilidade, como companhias ener-


géticas, de água, de gás etc., a figura do cliente estará desvinculada da figura do PON-
TO-DE-CONSUMO, embora com relacionamento entre eles. O primeiro conterá os
dados típicos do cliente consumidor dos serviços e o segundo estará vinculado aos da-
dos da unidade consumidora (endereço, logradouro, equipamentos instalados etc.). Essa
desvinculação torna-se importante na medida em que o consumidor poderá mudar de
ponto de consumo ao longo da sua história de relacionamentos com a empresa.

Dinâmica das dimensões


A dinâmica das dimensões está relacionada com as estratégias de manutenção
das informações quando ocorrerem processos de atualização. Algumas dimensões,
por suas características, tendem a ser mais voláteis do que outras. As dimensões
que mais mudam são chamadas Rapidly Changing Dimension, ou dimensões que se
alteram rapidamente. A dimensão cliente tem forte tendência a mudanças de atribu-
tos, como idade, endereço, escolaridade etc. Outras dimensões mudam com menos
frequência ou mais vagarosamente. São as chamadas Slowly Changing Dimension. As
dimensões loja, produto etc. tendem a ser classificadas nessa categoria. Isso definido,
há que se estabelecer uma abordagem para quando houver, por exemplo, atualização
do endereço de uma loja ou uma modificação da descrição do PRODUTO (atribu-
to da dimensão PRODUTO). A manutenção desses dados, com os seus diferentes
valores em função do tempo, é de fundamental importância nos sistemas de DW/
DM e não é muito considerada nos sistemas transacionais, nos quais prevaleciam os
dados do momento, sem grande relevância para os aspectos históricos. A Figura 8.24
mostra basicamente três alternativas para a abordagem das dimensões SCD (Slowly
Changing Dimension):

Figura 8.24
Estratégias para controle de alterações de atributos de dimensões.

187
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Atualização do valor alterado sem manutenção do histórico: é um processo


mais simples, chamado de abordagem tipo 1, porém não preserva a variação
histórica do dado, conforme mostrado na Figura 8.24a. Os dados antigos são
simplesmente substituídos pelos novos.
 Criação de nova ocorrência daquela dimensão: com essa abordagem,
chamada tipo 2, cria-se nova ocorrência da dimensão, que passará,
a partir dali, a se conectar com os fatos. Com essa abordagem, seg-
mentam-se os dados da dimensão e dos fatos em vários subconjuntos
diferentes, tantos quantos forem as variações da dimensão, conforme
mostrado na Figura 8.24b. Essa abordagem é a mais recomendada para
a manutenção do histórico evolutivo das dimensões. Os diversos perfis
da dimensão são preservados ao longo da sua vida. Para ter perfeita
noção de quando aquele novo perfil da dimensão passou a valer, é
importante que se adicionem alguns atributos de controle à dimensão.
Por exemplo:
 Data de início de validade daquele novo perfil.
 Data de fim de validade do perfil (deve corresponder à data de início de
um novo perfil da dimensão), com a consequente criação de uma nova
ocorrência da dimensão.
 Manutenção de dois campos registrados na dimensão: com a abordagem
tipo 3, somente dois registros são mantidos, em estado cíclico, preservan-
do-se apenas a versão anterior do dado juntamente com a versão atual,
ou seja, somente as duas últimas. Resolve o problema parcialmente e
não é a abordagem mais recomendada para aqueles projetos que desejam
maior consistência histórica nos seus dados. A Figura 8.24c ilustra esse
conceito.

No caso de projetos de dimensões com alto volume e alta volatilidade (Ra-


pidly Changing Dimension, RCD), a estratégia recomendada é a divisão dos dados
da dimensão em dois registros diferentes, separando-se os dados estáticos dos dados
voláteis. Essa estratégia, comum nos projetos de bancos de dados tradicionais, criará
uma situação na qual os atributos da dimensão estarão em dois registros diferentes,
com chaves separadas para identificá-los e um relacionamento que permita a junção
deles. A parte volátil da dimensão crescerá à medida que as atualizações da dimen-
são acontecerem. Da mesma forma, os dados da tabela fato estarão segmentados
logicamente em subconjuntos, apontados pela dimensão. A combinação das chaves
que formam a dimensão dividida permite a segregação dos registros fatos associados
àquela combinação.
Essa solução otimiza de certa forma os dados, separando-os por volatilidade, mas
implica maior trabalho nas junções da TFato com a dimensão. A Figura 8.25 ilustra esse
conceito.

188
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.25
Estratégia para implementação de dimensões grandes e voláteis.

Dimensões degeneradas
O conceito de dimensão degenerada está relacionado normalmente com os
objetos do tipo evento, como ordem de compra, nota fiscal ou pedido de serviços. Es-
sas entidades são compostas de itens (item de OC, linha da NF, itens do PS). Quando a
tabela fato está definida no nível de granularidade de itens, o número do documento
maior (número da OC, da NF ou do PS) estará na tabela fato para desempenhar o
papel de integrador ou “alinhavador” dos itens daquele documento. Como a dimen-
são é item e não existe uma dimensão para ordem de compra, ela é considerada uma
dimensão “degenerada”. A Figura 8.26 ilustra o conceito e remete ao conceito de
fato transação, mostrado na Figura 8.3a. Naquela figura, a solução final poderia ser
a transferência do número da nota fiscal para dentro da tabela fato e a colocação de
uma chave sequencial na dimensão item. Isso caracterizaria o uso de uma dimensão
degenerada nota fiscal.

Figura 8.26
Dimensões degeneradas.

189
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Dimensões lixo (junk)


O conceito de dimensões junk (lixo, descartável) está relacionado com a definição
de dimensões para campos com certas características diferenciadas como tag, valores binários
ou campos de baixa cardinalidade. Por exemplo, os campos sexo (M, F), estado civil (casado,
solteiro, desquitado), tag de contribuinte (sim, não), tipo de servidor (estadual, federal). Além
disso, também os campos de tipo texto, às vezes esparsos (nem sempre com todas as ocor-
rências preenchidas), são considerados boas opções para esse conceito. São campos do tipo
miscelânea, que não trazem muita correlação com os outros campos da tabela fato. Embora
sejam campos com essas características, é importante mantê-los como dimensões, pois po-
dem ser usados como filtros nas pesquisas. Poderão ser usados de forma combinada, como,
por exemplo, quando se tem três tags, com valores (Y/N), o que daria oito combinações
(2**3). A Figura 8.27 ilustra um exemplo de uso de tags como dimensão junk. No caso, es-
tou modelando uma situação em que armazeno equipamentos em almoxarifados e existem
certas condições de armazenamento indicadas por tags. Por exemplo, uma tag sobre condi-
ções de armazenamento climatizado (sim ou não), outra tag para condições de manutenção
especial (sim ou não) e outra para condições de transporte especial (sim ou não). A ideia é
definir uma dimensão junk, combinando as três tags para, através dos seus valores, poder aces-
sar os equipamentos naquelas situações específicas. Nesse caso, teríamos oito combinações
possíveis, que serviriam de entradas de acessos para as informações fato.

Figura 8.27
Exemplo de dimensão JUNK para controle de tags.

190
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

A Figura 8.28 mostra outro uso de dimensão junk, agora como artifício para
economia de textos, em que o conteúdo de comentários na TFato será substituído pela
chave da dimensão junk (comentário). Isso permitirá:

Figura 8.28
Exemplo de dimensão JUNK para controle de redundância de textos.

 Resolver a possível ausência de comentários (crio uma classificação artifi-


cial, com chave 00).
 Ganhar espaço, pois permite a substituição de um texto por uma chave, com
tamanho menor.
 Pesquisar, nas dimensões, por textos e strings.
As dimensões junk deverão seguir a regra geral, discutida a seguir, de usar as
chaves surrogate ou artificiais.

Campos-chave de dimensões e fatos


Uma regra básica, extremamente recomendável nos projetos de DW/DM,
é a análise de uma possível utilização de chaves surrogate, sinônimo de substituta
ou artificial. Isso significa definir como campo-chave de dimensões (e das fato, por
consequência) campos sem qualquer valor semântico embutido, mantendo a esta-
bilidade através da neutralidade. Esses campos são campos sequenciais, obtidos no

191
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

próprio SGBD (sistema gerenciador de bancos de dados). Essa alternativa deverá


ser escolhida no lugar de chaves ditas semânticas, aquelas com sentido de negócio
(por exemplo: nome, matrícula etc.) embutido, pois oferecem maior estabilidade
ao projeto. Lembre-se de que qualquer alteração nas estruturas das tabelas, princi-
palmente as fato, normalmente de grandes volumes, pode representar problemas na
manutenção do projeto.
O uso de chaves com valores naturais poderá apresentar problemas relativos a:
 Unicidade: nem sempre poderemos garantir que certa entidade terá va-
lores únicos a identificá-la. Hoje, com as crescentes fusões de empresas,
algumas regras poderão ser quebradas com a incorporação de dados ex-
ternos ao ambiente da empresa. Também a possibilidade de instabilidade
da estrutura e semântica da chave poderá ser evitada com essa abordagem.
Imagine que a sua chave de consumidor, ou de cliente, pode vir a mudar
um dia, quando a sua empresa for, por exemplo, comprada ou passar por
um processo de fusão.
 Ausência: algumas entidades e alguns eventos do mundo conceitual poderão
não ter chaves naturais como identificação.
 Melhor capacidade de implementação das chaves artificiais, normalmente
com 4 bytes de tamanho, o que pode representar vantagens na definição de
índices, como, por exemplo, um número de chaves maior por páginas de
índices. Normalmente, as chaves naturais terão tamanho maior do que as
chaves artificiais ou surrogates,
 Com valor inteiro de 4 bytes, o range de uma chave artificial pode alcançar
até dois bilhões (2**32) de ocorrências, o que é mais do que necessá-
rio para qualquer tabela dimensão. As chaves artificiais na realidade ficam
transparentes para os usuários do sistema, servindo mais como ligação
entre as tabelas fato e dimensão. O usuário, na realidade, usará indexações
amistosas baseadas em campos com semântica do seu domínio de conhe-
cimento. O cuidado que merece o uso de chaves artificiais, entretanto,
está relacionado com o fato de elas serem produzidas automaticamente,
durante os processos de preparação dos DW/DM (limpeza, carga etc.)
e, dessa forma, poderem produzir erros em casos de falhas operacionais
como reprocessamentos etc. Além disso, impedem que as tabelas fato se-
jam processadas diretamente, pois nelas somente existirão chaves surrogates,
que não contêm semântica e as métricas desejadas. Dessa forma, qualquer
pesquisa passará obrigatoriamente pelas tabelas dimensão, em que os cam-
pos de filtro e seleção estão armazenados, impondo sempre a realização de
junções para a resolução das consultas.
Os campos de natureza identity ou similares são encontrados nos diferentes SGB-
Ds existentes no mercado, sendo os candidatos a chaves surrogate ou artificiais.

192
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Tabelas fato sem dados ou métricas


Em certas situações, você poderá se deparar com tabelas fato sem medidas ou
métricas (Factless Fact). Não é muito comum, porém pode acontecer. Nesse caso, a ta-
bela fato estará cumprindo o papel de relacionar as várias tabelas dimensão envolvidas
no modelo, e o valor básico da informação está justamente nesses relacionamentos. A
Figura 8.29 ilustra o conceito, mostrando um modelo dimensional entre ALUNO-
-DISCIPLINA-DIA, no qual a tabela fato não sugere nenhuma métrica e o relaciona-
mento capturado pelas dimensões mostra, por exemplo, as informações de frequência
do aluno. Normalmente, essas tabelas fato são processadas pelo operador Count, visto
não haver métricas para serem tratadas.

Figura 8.29
Exemplo de tabelas fato sem métricas.

Tabelas fato com classificação ou subtipos


Existem casos nos quais o modelo de negócio poderá demandar vários ti-
pos de tabela fato, uma para cada linha de produto oferecido naquele ambiente.
O ambiente bancário/financeiro é exemplo clássico. Quando estiver modelando
um DW/DM dessa indústria, você se defrontará com vários produtos, cada qual
com os seus fatos e métricas diferentes, todos genericamente considerados como
produtos. Contas correntes, contas de poupança, empréstimos, cartões de créditos
etc. são produtos oferecidos e possuem fatos diferentes, embora as dimensões sejam
compatíveis. Como modelar esses sistemas? É o retorno ao conceito clássico de
entidades tipo e subtipo, agora voltado para modelagem dimensional. A estratégia
de abordagem é a mesma usada nos modelos entidades e relacionamentos, mostrada
na Figura 8.30, ou seja, a de usar uma tabela para armazenar dados comuns a todos
os tipos e outras com armazenamentos específicos para cada subtipo. Observe a es-
pecificação dos parâmetros CT, DD, que representam o tipo de cobertura (total, no
caso) e o tipo de disjunção (disjunto, no caso). A cobertura total significa que todos

193
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

os possíveis subtipos daquele tipo estão elencados no relacionamento de classifica-


ção/especialização. A cobertura parcial significa que somente alguns dos subtipos
estão mostrados. A disjunção significa que uma classe tipo somente poderá ter um
subtipo específico. A opção de disjunção sobreposta indica que um subtipo poderá
ter um ou mais subtipos associados a ele. O objetivo é caracterizar a cobertura do
domínio (total ou parcial) e a disjunção dos valores (disjuntos ou sobrepostos). Esses
conceitos são extensões semânticas que podem enriquecer o modelo, carregando
mais informações relevantes ao projeto.

Figura 8.30
Exemplo de modelo de dados E/R com tipo e subtipo.

A abordagem se baseia em três modelos dimensionais diferentes:


 Modelo base: contém os produtos (dimensão PRODUTO) na sua granu-
laridade menor ou consolidados por categoria. Isso permitirá análises com-
parativas mais facilitadas sobre os diversos indicadores de cada produto (por
exemplo, lucratividade de cada um), sem o trabalho de cruzar fatos separa-
dos. Permitiria comparar métricas comuns dos diversos produtos. É claro
que isso impõe certo overhead de armazenamento e deverá ser analisado
sob a ótica de custo-benefício. A Figura 8.31 ilustra o conceito.

194
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.31
Exemplo de modelo dimensional para tratamento de multifatos – tabela base.

 Modelo detalhado: contém várias tabelas fato especializadas para cada tipo
de produto. As dimensões TEMPO, AGÊNCIA e CONTA serão comparti-
lhadas, e a dimensão PRODUTO será específica de cada produto, conforme
a Figura 8.32.

Figura 8.32
Exemplo de modelo dimensional para tratamento de
multifatos – tabelas especializadas.

195
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Dimensões intercambiáveis (Hot Swappable Dimension): essa solução é


mostrada no modelo da Figura 8.33. O modelo define as dimensões com-
partilhadas, como agência, conta e tempo, e define uma forma de troca
dinâmica da dimensão produto, de acordo com o objetivo da consulta.
Observe que a classe produto pode ser considerada uma classe abstrata e
que as diferentes formas de produtos são as classes que efetivamente serão
trabalhadas. Isso herda muito do conceito de classe concreta e abstrata
da teoria de objetos e do conceito de polimorfismo, também presente
naquele ambiente. A ideia é que a dimensão específica seja escolhida no
momento do join pelo lado dinâmico do SQL. Isso permitiria o uso de
diferentes dimensões, com atributos também diferentes para modelar a
dimensão produto abstrata. Essa opção oferece vantagens de desempe-
nho, pois a dimensão joined com a fato é específica e conterá somente os
registros daquele tipo. Esse conjunto de dimensões específicas poderá ser
implementado como tabelas individuais ou, caso possível, com uma única
tabela ampla, com visões específicas, com cada view contemplando os atri-
butos específicos daquele tipo.

Figura 8.33
Exemplo de modelo dimensional para tratamento de multifatos – tabelas especializa-
das, dimensões hot swappable.

196
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Relacionamentos M u N entre fatos e dimensões


Observe a Figura 8.34. O modelo mostra uma estrutura dimensional que poderia
ser usada num data mart para controle histórico de todos os desfiles de escolas de samba,
do grupo especial, por exemplo. As dimensões ENREDO, ESCOLA e ANO são as bási-
cas do modelo. Observe, entretanto, que cada fato registrado está relacionado com vários
JURADOS, ou seja, a nota e a classificação estão relacionadas com vários jurados, caso
exista uma dimensão JURADO. Isso deverá ser resolvido, por exemplo, criando-se uma
tabela ponte chamada CORPO de JURADOS, com a qual as métricas se relacionarão em
1:N. A tabela CORPO de JURADOS contém uma chave do CORPO de JURADOS
daquele ano, mais a chave do JURADO que participou dele. Além disso, poderíamos co-
locar também a chave do quesito e a nota dada para aquela escola, naquele quesito, o que
permitiria uma análise completa dos fatos. A tabela ponte CORPO de JURADOS no
fundo está substituindo os relacionamentos emoldurados no quadrado anexo ao modelo.

Figura 8.34
Exemplo de modelo dimensional para tratamento de relacionamentos M uN.

Agregados
Um importante passo na complementação do projeto lógico de um DW/DM
é a etapa relativa à definição de AGREGADOS. Os valores agregados representam pa-
radoxalmente uma solução e alguns problemas. Solução porque estabelece a definição e
a criação de tabelas prontas, trabalhadas e sumarizadas em várias dimensões, facilitando
os acessos aos dados e agilizando os processos decisórios. Problemas porque agridem,
de certa forma, os processos canônicos de não redundância, estabelecidos nos preceitos
de projetos de bancos de dados desde a sua criação. Além disso, obviamente, gastam

197
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

mais espaço, pois exigirão uma coleção de tabelas fato ou dimensão, agora dedicadas ao
armazenamento de dados em um estado já pré-processado.

Critérios para definição dos agregados


Os critérios para definição dos agregados passam pela análise dos principais tipos
de informação necessários e pela dificuldade de obtê-los diretamente das tabelas gra-
nulares. Suponha o projeto de DW a seguir descrito e constituído das seguintes tabelas
dimensão e fato:
TdLoja (chave-loja, nome loja, endereço-loja, cidade, estado, cod-região).
TdProduto (chave-produto, marca, categoria, tipo-embalagem, departamento).
TdDia (chave-dia, mês, ano, período-fiscal, estação).
TfVendas (chave-loja, chave-produto, chave-dia, valor-vendido-real, custo-real,
lucro, qtd-vendida).
Os campos em negrito representam níveis de hierarquias. Por exemplo, temos
três hierarquias possíveis:
REGIÃOoLOJA; hierarquia com dois níveis.
CATEGORIAoPRODUTO: hierarquia com dois níveis.
ANOoMÊSoDIA: hierarquia com três níveis.
O número de tabelas de agregados está diretamente relacionado com as com-
binações ternárias, binárias e unárias das hierarquias, e o seu volume está diretamente
associado às ocorrências de cada nível combinado. Por exemplo, podemos combinar:
1. Ternária: 2 u 2 u 3 = 12 opções de combinações ternárias.
Por exemplo: região + categoria + ano ou região + categoria + mês etc.
2. Binária: 16 opções, ou seja, (2 u 2 + 2 u 3 + 2 u 3).
Por exemplo, teríamos: região + categoria, ano + loja etc.
3. Unária: 2 + 2 + 3 opções.
Por exemplo, teríamos agregado por loja ou por categoria, ou por mês.
Somando todas as possíveis combinações chegaríamos a 35 combinações pos-
síveis de agregados para analisarmos sob a ótica dimensional. A escolha deverá ser ob-
viamente por aquelas que oferecem maior disponibilidade de informações e também
o melhor coeficiente de redução. Isso significa que, quanto maior for a cardinalidade
da(s) coluna(s) escolhida(s) para compor o agregado, menor efeito trará a sua utiliza-
ção. Em outras palavras, significa que, se as colunas escolhidas tiverem muitos valores
diferentes, os registros agregados serão em grande número e poderão não otimizar
o processamento em termos de desempenho, se comparados com as tabelas granula-
res. Comandos SQL, como o mostrado a seguir, poderão ajudar na análise e viabili-
dade de produzir os agregados, permitindo estabelecer o histograma de seus valores.
Ex.: Verificar a distribuição dos valores agregados por loja:
SELECT NOME-LOJA, COUNT (*)
FROM TfVENDAS
GROUP BY NOME-LOJA

198
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Cuidados na definição dos agregados


Valores aditivos. As tabelas agregadas exigem alguns cuidados nas suas defini-
ções. A principal é a definição dos valores aditivos que estarão habitando os agregados
porque, lembre-se, nem todas as métricas armazenadas nas tabelas granulares são aditivas
em todas as dimensões (algumas são semiaditivas ou não aditivas). Isso significa que os
atributos da(s) tabela(s) fato de agregados poderão ser diferentes dos das tabelas fato
granulares. Esse ponto já foi detalhado anteriormente.
Precisão. Outro cuidado reside no fato de se definir criteriosamente a precisão
dos valores aditivos dos agregados, que deverão ser maiores do que os usados nos respec-
tivos valores das tabelas granulares. Caso contrário, experimentaremos overflow em opera-
ções de adição. Outro aspecto, muito importante, se relaciona com a definição de tabelas
fato agregadas e tabelas dimensão agregadas em estruturas fisicamente diferentes das gra-
nulares. Iniba qualquer impulso de armazenar os valores dos fatos granulares e agregados
na mesma tabela, mesmo que o número de tabelas do seu esquema cresça muito. Embora
esse número grande de tabelas possa parecer um complicador para o usuário, alguns fa-
tores atenuantes, como o mecanismo de navegação de agregados oferecido em certos
pacotes, estão surgindo para criar transparência no uso dessas informações consolidadas de
natureza gerencial, sem que o usuário explicitamente defina sua utilização.

Entendendo e produzindo os agregados


Uma forma de entender melhor os agregados é através dos comandos SQL que
os produzem. Por exemplo, podemos definir alguns agregados (tabela de agregados,
TAG), como a seguir:
1. Agregados por loja: tabela Tag_por_Loja
INSERT INTO TAG_POR_LOJA AS
SELECT NOME - LOJA, SUM (VALOR-VENDIDO-REAL), SUM
(CUSTO-REAL)
FROM TdLOJA, TfVENDAS
WHERE TdLOJA. CHAVE-LOJA = TfVENDAS.CHAVE-LOJA
GROUP BY NOME-LOJA
Equivale à agregação por lojas de todos os produtos, todos os dias. Estamos con-
siderando que o nome-loja é um campo único.
2. Agregados por loja e por mês: tabela Tag_por_Loja_Mês
INSERT INTO TAG_POR_LOJA_MÊS AS
SELECT NOME-LOJA, MÊS, SUM (VALOR-VENDIDO-REAL), SUM
(CUSTO-REAL)
FROM TdLOJA, TfVENDAS, TdDIA
WHERE TdLOJA.CHAVE – LOJA = TfVENDAS.CHAVE - LOJA AND
TdDIA.CHAVE - DIA= TfVENDAS.CHAVE-DIA
GROUP BY NOME-LOJA,MÊS

199
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Equivale à agregação por loja, por mês, para todos os produtos.


3. Agregado por região de venda, por mês, por categoria:
INSERT INTO TAG_POR_REG_MÊS_CATEGORIA AS
SELECT REGIÃO - VENDA, MÊS, CATEGORIA, SUM (VALOR-VEN-
DIDO-REAL),
SUM (CUSTO-REAL)
FROM TdLOJA, TfVENDAS, TdPRODUTO, TdDIA
WHERE TdLOJA.CHAVE-LOJA = TfVENDAS.CHAVE- LOJA AND
TdDIA.CHAVE- DIA = TfVENDAS.CHAVE - DIA AND
TdPRODUTO.CHAVE-PRODUTO = TfVENDAS.CHAVE-PRODUTO
GROUP BY REGIÃO-VENDA, MÊS, CATEGORIA
O projeto e a criação das tabelas agregadas deverão ser revestidos de alguns cui-
dados operacionais:
 As tabelas agregadas deverão compor um modelo separado, com a definição
das tabelas granulares fato e das tabelas dimensão (Figura 8.35). Isso evitará
contenções mútuas no momento da sua carga ou atualização.

Figura 8.35
Estratégia de implementação de dados agregados.

 Uma definição importante no projeto operacional dos agregados é a es-


tratégia de carga total versus a sua atualização incremental. Essa decisão
passa por aspectos relacionados a tempo de processamento (recarga total dos
agregados) e complexidade de programas (atualização incremental);

200
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

 A carga/atualização dessas tabelas agregadas deverá ser analisada com relação


à janela (normalmente noturna) disponível para seu processamento. Pelo
volume e número de tabelas agregadas, é importante considerar processos
paralelos de carga/atualização ou uso de máquinas com sistemas operacio-
nais que explorem paralelismo ou mesmo a análise criteriosa de SGBDs
relacionais que paralelizam comandos SQL.

Uso das informações agregadas


Um aspecto fundamental no projeto dos agregados é a sua efetiva utilização.
Com a possibilidade de ter esquemas com muitas tabelas e objetivando criar mecanis-
mos de transparência para o usuário final, já existe o conceito de navegador de agrega-
dos. Na realidade, é mais uma camada colocada entre a ferramenta OLAP (que solicita
os dados com base na visão granular) e o servidor de DW/DMart. Esse navegador
realiza (transparentemente) a tradução das solicitações, convertendo comandos SQL
granulares nos equivalentes que trabalham informações agregadas.Também, como o de-
senvolvimento da indústria dos otimizadores SQL, hoje esses elementos estão cada vez
mais dotados de inteligência nessas traduções. Além disso, essas ferramentas oferecem no
seu arsenal algumas funções que permitem melhor definir os agregados (com base em
análises de histograma) e monitoram e registram o uso de cada tabela agregada, dando
indicações de sua efetiva utilidade nos processos de tomada de decisão.

METADADOS
Um dos pontos mais importantes na documentação das aplicações OLAP e do
ambiente de data warehouse/data mart é a definição dos seus metadados. O modelo
da Figura 8.36 mostra uma possível estrutura que poderia ser implementada como
apoio ao processo de documentação do ambiente. O modelo apresenta uma série de
entidades e relacionamentos que poderiam ser implementados em tabelas relacionais,
documentando elementos do modelo dimensional. O modelo proposto apresenta
uma tabela com aplicações OLAP, que poderia conter informações sobre o órgão
patrocinador, a data de implementação, o assunto-base relacionado à aplicação etc.
Associados a ela estariam os data marts. Significa que certa aplicação OLAP poderia
utilizar vários marts e que cada data mart poderia estar presente em várias aplicações.
O mesmo se aplica ao conceito de cubo, definido, nesse contexto, como uma com-
binação de dados de tabelas fato ou dimensão. Consideramos que uma TFato está
somente em um cubo e que um cubo teria somente uma TFato. Já um cubo pode
ter várias TDimensão e cada uma delas pode participar de vários cubos. Um cubo
pode ser usado em várias aplicações OLAP, e cada aplicação OLAP logicamente pode
ter vários cubos. Cada DM pode ser formado de várias tabelas fato e várias tabelas
dimensão, enquanto cada uma delas (tabela fato ou tabela dimensão) pode estar sendo
usada em vários marts. No caso de tabelas dimensão, esse alias é um grande trunfo,
quando utiliza dimensões que podem ser compartilhadas por vários projetos de DM
que, dessa forma, gradativamente constituem o DW (data warehouse). O registro his-
tórico, como junção entre elas, representa as informações específicas daquela tabela

201
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

naquele DM; por exemplo, a data em que aquela tabela foi implementada naquele
projeto de DM. Cada tabela teria as suas informações básicas, como identificação,
semântica etc. As tabelas fato e dimensão teriam os seus atributos definidos em ta-
belas separadas. As informações sobre a integridade referencial entre as tabelas fato
e dimensão poderiam estar armazenadas, embora normalmente sejam informações
mais ou menos fixas, como restrição para deleção e inserção. Outra informação que
poderia ser registrada é a forma de tratamento que certa métrica poderia sofrer. Por
exemplo, poderia ser aditiva numa dimensão, mas não aditiva em outra, conforme
mostrado pelo relacionamento ternário proposto.

Figura 8.36
Exemplo de modelo de metadados para um ambiente de data mart e aplicações OLAP.

Com o objetivo de enriquecer o modelo, poderíamos armazenar também as


informações de extração, tratamento e carga de cada valor (atributo) registrado nas
tabelas fato ou dimensão. Essas informações (ORIGEM) poderiam estar armazenadas
nos atributos da tabela dimensão ou nas métricas da tabela fato, ou em outras tabelas
normalizadas. A recursividade entre as tabelas fato mostraria a junção possível entre elas,
via comandos de drill-across. As informações sobre versões de tabelas dimensão também
estariam registradas, visando ao controle das mudanças de estado de atributos de dimen-
sões. Os usuários, em nível de cubos ou em nível de tabelas fato ou dimensão, poderiam
ser registrados, enriquecendo também o modelo. Os aspectos de metadados se tornam

202
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

fundamentais dentro do contexto do BI2, no domínio de qualidade dos dados e de


informações produzidas. Esse tema deverá ser foco de ações da governança de dados,
conforme discutido anteriormente.

LABORATÓRIOS DE MODELAGEM DIMENSIONAL DE DADOS


Introdução
Nesta parte, desenvolveremos alguns exemplos de modelagem, buscando solu-
ções dimensionais ou bancos de dados de informações históricas ou depósitos consoli-
dados, como ODS (Operational Data Store), sempre com o objetivo de reforçar os con-
ceitos de business intelligence. Os exemplos foram desenvolvidos sob a ótica do autor e
não representam, obviamente, a única solução para os problemas propostos. O objetivo
maior é proporcionar uma forma de discussão e aplicação dos conceitos vistos anterior-
mente. Alguns dos modelos apresentados foram implementados pela equipe de bancos
de dados e de business intelligence coordenadas pelo autor. Devem ser considerados
como ponto de partida para projetos reais de DW/DM naquele assunto específico.
1) Data mart para acompanhamento de vendas de CD
Neste exemplo, o modelo dimensional proposto na Figura 8.37 permite o acom-
panhamento de vendas de CD e o consequente valor de seu faturamento. O modelo
é simples e tradicional, com os fatos registrando as quantidades e os respectivos valores
de venda. As dimensões básicas representam o CD vendido naquele período e naquela
região. Observe que existe uma hierarquia de dois níveis na dimensão geográfica e que
a dimensão tempo está representada por uma hierarquia de três níveis, ano-mês-dia. É
importante também observar nesse exemplo que:

Figura 8.37
Modelo dimensional para acompanhamento de venda de CD.

 As dimensões possuem vários atributos não especificados diretamente. Por


exemplo, a dimensão CD poderia ter a gravadora, o gênero de música, o

203
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

cantor ou o grupo. São atributos que podem sugerir uma hierarquia não
mostrada. A dimensão DIA poderia ter atributos de tag final de semana
ou época do ano, por exemplo, e a dimensão ESTADO também teria um
conjunto de atributos como região, população etc.Todos esses atributos po-
derão ser usados para o filtro ou tratamento conjuntivo dos valores da fato.
Por exemplo, a soma de vendas em reais de CD do gênero “samba de raiz”,
no estado do Rio de Janeiro, no período de Carnaval, seria uma das muitas
consultas efetuadas naquele DM e teria um comando SQL equivalente a:
Select SUM(Valor), SUM(Quantidade) from FATO, DIA, ESTADO, CD
where
DIA.chave-dia = Fato.chave-dia and (*)
CD.chave-cd = Fato.chave-cd and (*)
ESTADO.chave-estado = Fato.chave-estado and (*)
DIA.periodo = “Carnaval” and
ESTADO.codigo = RJ” and
CD.genero = “samba raiz”
Observar que as partes da cláusula where marcadas com (*) estão cumprindo o
papel de junção das tabelas dimensão com a tabela fato, enquanto as outras realizam os
filtros desejados.
 Na realidade, o modelo com a dimensão ESTADO, nesse nível, pode ser
considerado uma forma de agregado de CIDADE, que representaria o me-
nor nível de controle desejado. À medida que se decompõe o nível das
dimensões, também se muda a granularidade das informações na tabela fato.
O modelo agregado em nível de ESTADO poderia ter sido obtido por um
comando SQL, sobre o modelo em nível de CIDADE, como a seguir:
Select chave-dia, chave-cd, codigo-estado, SUM(Valor), SUM(Quantidade)
from FATO, DIA, CIDADE, CD
where
DIA.chave-dia = Fato.chave-dia and
CD.chave-cd = Fato.chave-cd and
CIDADE.chave-cidade = Fato.chave-cidade
GROUP BY CIDADE. codigo-estado, chave-dia, chave-cd
2) Data mart para acompanhamento de controle de execução de músicas
O modelo na Figura 8.38 objetiva um controle de execução de músicas por FM.
Apresenta as dimensões TEMPO, hierarquizadas em ano-mês-dia, e as dimensões de ne-
gócios FM e MÚSICA. A métrica desejada é o número de execuções daquela música, o
que permitiria a distribuição de direitos autorais e atenderia, por exemplo, às entidades
arrecadadoras desses direitos. Com esse modelo poderíamos controlar que certa música
foi executada numa rádio FM, certo número de vezes por dia. Os diversos atributos

204
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

“escondidos” das dimensões MÚSICA (gênero, cantor ou grupo, gravadora, duração,


nacionalidade, compositor(es) etc.) e da FM (frequência, estado, estilo de programação
etc.) poderiam ser usados para a definição de informações negociais sobre a quantidade
de execução e pagamento de seus direitos. Observe que o atributo compositor da di-
mensão MÚSICA está na proporção M:N com música e poderia produzir uma tabela
de interseção na qual se registraria a porcentagem de direito de cada um.

Figura 8.38
Modelo dimensional para acompanhamento de execução de músicas.

Como uma música pode ser executada diversas vezes por dia, poderíamos tam-
bém aumentar a granularidade da dimensão TEMPO para faixa horária, o que levaria
às informações estratificadas de execução ao longo das 24 horas do dia. Poderiam ser
faixas de hora em hora ou períodos do tipo manhã, tarde, noite. Considerações sobre
a probabilidade de execução da mesma música mais de uma vez, na mesma faixa de
uma hora, deveriam ser levadas em conta para a definição dessa granularidade maior.
Aqui surge outra discussão: seria mais recomendável a criação de um nível hierárquico
inferior (faixa horária, no caso, subordinado a dia) ou criar uma outra dimensão FAI-
XA-HORÁRIA independente? A resposta, de maneira geral, passa por considerações
sobre o grau de independência dessas dimensões produzidas e o número de registros das
tabelas dimensão resultantes de cada alternativa. Nesse caso, a criação de uma dimensão
faixa horária separada produziria 24 registros (um para cada hora) e não proliferariam
os registros da dimensão DIA (suponha um calendário com 1.825 registros relativos a
cinco anos e 365 dias/ano). A combinação entre faixa horária e dia seria realizada pela
tabela fato, caso fosse uma dimensão independente, ou pela hierarquia, caso estivessem
na mesma dimensão. A tabela fato se expandiria em mais uma chave, caso houvesse in-
dependência, devido à criação de mais uma dimensão.
3) Data mart para controle de frequência em diversões de um parque temático
O objetivo é criar uma estrutura dimensional que permita o controle de visitantes
de um parque temático, gerenciando a frequência de utilização dos brinquedos (diver-

205
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

sões), por período e por tipo de passaporte (tíquete de entrada, que dá direito ao uso de
vários brinquedos). Suponha que, de posse do passaporte, o usuário possa entrar em cada
diversão, bastando para isso, passar o cartão na roleta de entrada de cada brinquedo. O
modelo é simples, com a dimensão PASSAPORTE hierarquizada por tipo, a dimensão
DIVERSÃO, que caracteriza o brinquedo utilizado, hierarquizada por categoria, e o tem-
po representado pela hierarquia ano-mês-dia, com as riquezas de uma dimensão típica de
calendário (marcação de final de semana, feriado, estação do ano etc.). O modelo traz uma
novidade documentacional que seria a notação de dependência interdimensional, uma
espécie de constraint que poderia ser adicionada, sinalizando certa condição a observar. No
caso, está sendo definido que certas diversões têm funcionamento limitado em função de
condições climáticas do dia, caracterizada como um atributo de dimensão. A partir do
modelo granular (Figura 8.39a) pode-se obter o modelo agregado por mês, tipo de pas-
saporte e categoria da diversão (Figura 8.39b) por um comando SQL equivalente a este:
Select código-categoria-diversão, mês, código-tipo-passaporte,
SUM(frequência-diversão) from FATO, DIA, CARTÃO, DIVERSÃO
where
DIA.chave-dia = Fato.chave-dia and
PASSAPORTE.chave-passaporte = Fato.chave-passaporte and
DIVERSÃO.chave-diversão = Fato.chave-diversão
GROUP BY código-categoria-diversão, mês, código-tipo-passaporte

Figura 8.39
Modelo dimensional inicial para tratamento de informações sobre parques temáticos.

206
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

As Figuras 8.39a e b mostram, respectivamente, o modelo granular e o modelo


agregado obtido, com a mesma métrica de frequência de utilização.
4) A Figura 8.40 mostra um modelo dimensional para a implementação de um
sistema de acompanhamento de campanha de marketing. O modelo tam-
bém está simplificado, mostrando as dimensões CAMPANHA, REGIÃO,
PRODUTO e TEMPO. Esse modelo, no fundo, representa uma visão agre-
gada de um modelo mais granular e permite o acompanhamento do de-
sempenho de venda do produto, em função da campanha, no período e na
região. Como sugestão, defina um modelo mais granular que se ajuste a esse
modelo apresentado.

Figura 8.40
Modelo dimensional para sistema de acompanhamento de campanhas de marketing.

5) A Figura 8.41 mostra um modelo dimensional para acompanhamento de


informações em uma cadeia de hotéis. As dimensões são HÓSPEDE, HO-
TEL, DIA (de entrada e saída), CARTÃO e AGÊNCIA de TURISMO
utilizada na reserva. A dimensão DIA tem dois relacionamentos (um para
check-in e outro para check-out) com a tabela fato. As dimensões CARTÃO e
AGÊNCIA estão marcadas com cardinalidade zero (bolinha) e representam
a possibilidade de um fato não ter associação com uma ocorrência especí-
fica daquela dimensão. Isso deverá ser implantado com uma ocorrência de
dimensão, do tipo nula (pagamento sem cartão ou reserva feita diretamente),
associada à tabela fato, e permitirá controles gerenciais sobre esses tipos de
eventos. Algumas dimensões não estão representadas por suas hierarquias
e atributos completos que deverão fazer parte do modelo. Por exemplo, a
dimensão hóspede teria, entre outros atributos, identificação, profissão, ida-
de, procedência, destino etc. A dimensão agência teria informações sobre

207
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

classificação Embratur, cidade, especialização etc. A dimensão cartão teria


bandeira, validade, portador, categoria etc., e o hotel teria as informações
geográficas, categorização, informações de quartos etc. Todos esses atributos
poderiam ser usados como elementos de filtro e de agregação na produção
de informações negociais. Por exemplo, a consulta: qual é o valor médio de
gastos com frigobar, para os hóspedes que vieram pela agência Floripatur,
que fazem checkout nas sextas-feiras, nos hotéis da Região Nordeste e que
pagam com cartão MasterCard? Observe que a consulta se inicia pela ex-
pressão da métrica desejada (valor-frigobar), do seu tratamento (média) e
em seguida das condições de filtros (agência igual a Floripatur, cartão igual
a MasterCard, dia de checkout às sextas-feiras).

Figura 8.41
Modelo dimensional para controle de hospedagem em hotel.

6) Vamos considerar um modelo para um sistema de uma empresa transporta-


dora por caminhão, que atenda às seguintes regras de negócio:
 Toda carga tem um local de origem e um local de destino, além de uma
identificação e da quantidade transportada.
 Toda carga tem duas datas associadas: a do despacho e a da entrega.
 O preço do frete, por tonelada transportada, é dependente dos pontos de
origem e destino.
 O preço final é o frete multiplicado pela quantidade transportada.

208
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Solução:
 Observe a Figura 8.42. Para as regras propostas, a solução é clássica, com as
dimensões LOCAL, DIA DE ENTREGA, DIA DE DESPACHO, CAR-
GA, VEÍCULO e CLIENTE. A granularidade da dimensão ENTREGA
seria no nível de item de entrega, ou seja, uma ordem de transporte pode
ter vários itens de entrega. Na mesma ordem de transporte posso ter itens
para vários CLIENTES. As métricas de negócios seriam a quantidade trans-
portada, o valor do frete e a duração da viagem. A quantidade gasta de com-
bustível poderia ser calculada, e isso permitiria apurar com precisão a lucra-
tividade de cada viagem, em função dos locais de destino e origem, tipo de
carga transportada e a época da viagem. Observe que as dimensões LOCAL
e DATA aparecem com dois relacionamentos no modelo (local de origem
e destino) e (data de entrega e despacho), respectivamente. Essa duplicação
de relacionamentos de dimensões por vezes aparece nos modelos de dados.
Do ponto de vista de DM seria uma única tabela, com o uso de sinônimos
para diferenciá-las nos tratamentos via SQL. O contexto de cada tabela seria
diferenciado por um apelido conferido a ela, como:
Select c1, c2 FROM destino LOCAL, origem LOCAL where…

Figura 8.42
Modelo dimensional para acompanhamento de entregas.

209
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

A dimensão LOCAL é, na realidade, uma manifestação da hierarquia da dimen-


são geográfica do modelo, caracterizada por PAÍSoESTADO.
Caso se desejasse agrupar os itens de entrega por ordem de entrega, sem criar
uma dimensão ORDEM de TRANSPORTE, poderíamos adotar a estratégia de di-
mensão “degenerada”, colocando esse número (Ordem-Transporte) na tabela fato, sem
uma dimensão correspondente. Relembre o conceito de dimensão degenerada. A dura-
ção da viagem poderia ser calculada pela diferença entre as datas de despacho e entrega
e ser materializada on-line, em vez de ser armazenada. Essa é uma análise de custo-
benefício que deverá ser feita considerando-se o volume de dados da tabela fato e o
tempo de processamento para a obtenção in-flght daquela informação.
A Figura 8.43 apresenta um modelo variante do anterior, válido para qualquer
tipo de transporte, caracterizado pelo courrier. Nele estão envolvidos a dimensão depósi-
to, que representa a origem da entrega, o courrier propriamente dito, e o pedido aparece
na hierarquia da dimensão cliente. Basicamente, a TFato é a mesma, com exceção das
chaves primárias das dimensões. As métricas são mantidas. A Figura 8.44 mostra outra
variante do mesmo modelo, em que aparece uma forma de definir dependências entre
registros de dimensões. No caso, a taxa a ser aplicada no produto depende do país da
venda e da categoria do produto.

Figura 8.43
Modelo dimensional para acompanhamento de entregas – visão genérica.

210
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.44
Modelo dimensional para acompanhamento de
entregas – definição de dependências.

7) Solução de business intelligence para um sistema da National Basketball


Association (NBA)
O objetivo é manter informações sobre a realização de todos os campeonatos da
NBA, com detalhes sobre jogos, desempenho histórico dos times ao longo dos campeo-
natos e a história de cada jogador em suas participações. Análises sobre público e renda
serão necessárias para planejamentos estratégicos de negócios no cenário da NBA.
Solução:
Observe a Figura 8.45, que mostra um modelo de dados convencional, que pode-
ria ser o de um ODS (Operational Data Store), no qual as informações desejadas estariam
consolidadas, mas armazenadas de forma não dimensional. O ODS consolida informa-
ções operacionais de várias fontes e serve como um stage para os DW/DM. Esse modelo
proveria informações sobre a participação de atletas e times nas diversas edições da NBA,
com os leiautes de tabelas e sugestões de índices mostrados na Figura 8.46. O modelo é
clássico, com relacionamentos M:N transformados em 1:N para armazenar informações
de interseção, como participação (do atleta na campanha do time, naquela edição). O mo-
delo da Figura 8.47 mostra uma proposta dimensional para controle de métricas (público,
renda e resultados) que permitiria a análise desses fatos em função de TIME, LOCAL,

211
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

DATA e JUIZ. Os times aparecem na mesma dimensão, com papéis diferenciados (visi-
tantes e mandantes). Os dois juízes da partida estão também numa única dimensão. Uma
das inúmeras consultas que poderiam ser feitas sobre esse modelo dimensional é: qual é a
média de pontos que o Los Angeles Lakers fez como time visitante durante a temporada
de 2007? A propósito, qual é o comando SQL que atenderia a essa consulta?

Figura 8.45
Modelo para acompanhamento dos campeonatos da
NBA – modelo entidade relacionamento.

Figura 8.46
Modelo para acompanhamento dos campeonatos da NBA – detalhe de tabelas.

212
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.47
Modelo dimensional para acompanhamento dos campeonatos da NBA.

Comece pela montagem da métrica desejada e do tratamento necessário (média,


soma etc.). Depois faça a junção das tabelas dimensão envolvidas com a tabela fato. Para
isso use as igualdades entre campos-chave dessas tabelas. Depois, ainda na cláusula whe-
re, aplique os filtros desejados sobre os campos das tabelas dimensão. Lembre-se de que,
se você adotou a estratégia de chaves surrogate (campo sem semântica e conteúdo), 99%
das condições de seleção serão aplicadas nos atributos das tabelas dimensão, ficando as
métricas quase exclusivamente para tratamentos aditivos.
8) Data mart para controle de uma empresa de transporte aéreo
O exemplo da Figura 8.48 mostra um modelo transacional (relacional) para
o possível controle de uma empresa de transportes aéreos. Esse modelo poderá dar
origem a uma primeira abordagem dimensional mostrada na Figura 8.49. O mode-
lo destaca novamente o aparecimento de dimensões com significados diferentes. A
dimensão LOCAL está com dois papéis diferentes (ORIGEM e DESTINO), assim
como a dimensão DATA (INÍCIO e FINAL). A semântica do modelo mostra um
VOO dividido em vários trechos ou segmentos, que são a granularidade definida
para os fatos. O código do bilhete foi colocado na tabela fato, como uma dimensão
degenerada, permitindo o alinhavo de todos os seus segmentos. O código do voo
também serve como um alinhavador dos trechos, reforçando o seu papel de dimensão

213
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

degenerada. O elemento principal nessa proposta é a associação com os passageiros


do voo, estabelecendo um controle de milhagens por trecho, além de um mecanismo
de compensação, na forma de milhagens adicionais, para os atrasos além de certo li-
mite. Esse mecanismo de fidelização de clientes é muito comum em certas empresas
aéreas hoje. A métrica obtida pela contabilização das horas de atraso serve também
como instrumento de medição de qualidade dos voos, em função de locais (origem
e destino), de época do ano (data-início e data-final do voo) e de horário. A Figura
8.50 mostra uma variante do modelo anterior, com as métricas da tabela fato não
mais associadas a passageiro, mas aos indicadores operacionais de cada trecho, como
assentos vagos, ocupados, custo do voo, duração, atraso etc.

Figura 8.48
Modelo relacional para uma empresa de transporte aéreo.

214
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.49
Modelo dimensional para empresa de transporte
aéreo – fatos sobre passageiros.

Figura 8.50
Modelo dimensional para empresa de transporte aéreo – fatos sobre
indicadores operacionais de trechos.

215
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

9) Data mart para informações de recursos humanos


O objetivo é mostrar um conjunto de estruturas dimensionais, que poderão ser
implementadas na forma de DM separados ou na forma de cubos obtidos dinamica-
mente de um DW maior.
As principais dimensões são ÓRGÃO e ANO-MÊS, caracterizando a localiza-
ção e a variação temporal dos dados dos empregados da empresa. As Figuras 8.51 e 8.52
mostram, respectivamente, DM com informações de movimentação de pessoal e de
absenteísmo nas dimensões FUNÇÃO, TEMPO de SERVIÇO, FAIXA ETÁRIA e
FAIXA SALARIAL, além de ÓRGÃO e ANO-MÊS.

Figura 8.51
Modelo dimensional para sistema de recursos
humanos – Movimentação de pessoal

216
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.52
Modelo dimensional para sistema de recursos
humanos – absenteísmo.

As principais métricas para movimentação de pessoal seriam:


 Fatos de informações gerais: quantidade de empregados admitidos, quanti-
dade de empregados efetivos, licenciados, aprendizes, demitidos e total.
 Fatos de função: quantidade de empregados naquela função, no órgão, na-
quele período.
 Fatos de tempo de serviço: quantidade de empregados com aquele tempo
de serviço, naquele órgão, naquele período.
 Fatos de faixa etária: quantidade de empregados naquela faixa etária, naque-
le órgão, naquele período.
 Faixa salarial: quantidade de empregados naquela faixa salarial, naquele ór-
gão, naquele período.
As principais métricas para absenteísmo de pessoal seriam:
 Fatos de informações gerais: quantidade de acidentes sem ônus, quantidade
de licenças-maternidade, quantidade de cedidos com ônus, quantidade de
cedidos sem remuneração e os valores de índices de frequência e de duração
de absenteísmo.
 Fatos de função: valores de índices de frequência e de duração de absen-
teísmo, por função.

217
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Fatos de tempo de serviço: valores de índices de frequência e de duração de


absenteísmo, por tempo de serviço.
 Fatos de faixa etária: valores de índices de frequência e de duração de ab-
senteísmo, por faixa etária.
 Faixa salarial: valores de índices de frequência e de duração de absenteísmo,
por faixa salarial.

Dimensões recursivas
Um aspecto importante relativo ao exemplo anterior se prende às características
recursivas da dimensão ÓRGÃO. Uma estrutura desse tipo pode ser considerada formada
por outras da mesma natureza. É o exemplo clássico de estruturas hierarquizadas ou de
explosão de materiais, muito comuns nos bancos de dados tradicionais. Na modelagem
dimensional, a abordagem para o tratamento correto dessas dimensões com características
recursivas é a definição de uma tabela ponte entre a tabela dimensão órgão e a tabela fato,
para definir as relações entre as chaves.A Figura 8.53 mostra o caso da dimensão ÓRGÃO
se relacionando com uma ou mais tabelas fato e a definição da tabela ponte, contendo:
 A chave do órgão superior
 A chave do órgão (subordinado)
 A distância em número de níveis entre os órgãos
 Um flag para indicar que o órgão está no menor nível da hierarquia
 Um flag para indicar que o órgão está no maior nível da hierarquia

Figura 8.53
Modelo recursividade-resolução de relacionamento recursivo.

218
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Com essas informações na tabela ponte, pode-se percorrer e agregar os fatos dos
órgãos em quaisquer níveis da hierarquia, utilizando adequadamente a linguagem SQL.
Poderíamos, por exemplo, agregar um órgão A com todos os seus filhos (inclusive ele
próprio, caso tenha métrica independente). Da mesma forma, seria possível agregar o
órgão A em somente alguns de seus níveis filhos (selecionando pela diferença do nível).
Os flags de indicação de folha (menor nível da hierarquia) e de topo (maior nível da
hierarquia) ajudam na formação dos comandos SQL. A Figura 8.54 mostra o exemplo
de uma hierarquia, com os seus nós e as informações que habitariam a tabela ponte, para
um caso ilustrado de certa instância de hierarquização.
No caso de DW/DM em que existem dimensões recursivas, é importante a de-
finição do comportamento das métricas. Por exemplo: se um nó pai não tiver métricas
próprias e o seu valor representar o somatório das métricas dos nós inferiores, bastará
armazenar os fatos nos níveis menores. Caso contrário, as métricas em todos os níveis
deverão ser representadas nas tabelas fato.
A Figura 8.55a ilustra outro exemplo de dimensão recursiva. No caso, a dimen-
são funcionário, que representa uma hierarquização de chefes e subordinados, ilustrados
na Figura 8.55b. Nesse caso, tanto o funcionário chefe quanto o funcionário subordi-
nado possuem métricas. A Figura 8.56 mostra um diagrama com certas ocorrências e
ilustra a possibilidade de aplicação do comando roll-up para somar os valores (métricas
de vendas), tanto do nível subordinado quanto do nível chefia. O comando roll-up po-
deria apresentar a venda própria de cada empregado, a venda dos seus subordinados e a
venda total, que seria a soma das vendas (equivalente à venda daquela equipe).

Figura 8.54
Modelo recursividade – visão da hierarquia recursiva.

219
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 8.55
Modelo recursividade – recursividade de funcionário.

Figura 8.56
Modelo recursividade – Visão da hierarquia recursiva.

220
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.57
Modelo recursividade – recursividade de conta.

A Figura 8.57a mostra outro exemplo de aplicação de dimensões recursivas. No


caso, a dimensão conta, que representa um tipo de classe mais generalizada que pode
encarnar diferentes tipos de elementos contábeis, como lucro líquido formado pela
operação de lucro bruto menos as despesas. O lucro bruto, por sua vez, seria a operação
algébrica de faturamento menos custos. Do outro lado da equação, o valor de salário
somado aos benefícios forma as despesas trabalhistas. Estas, somadas às despesas adminis-
trativas, formam o núcleo das despesas, fechando o ciclo. O interessante de se observar
é que, diferentemente do exemplo anterior, no qual o operador era sempre soma, nesse
caso o operador poderá ser soma ou subtração. O comando roll-up permite também
que, no nível específico da dimensão, o operador seja cadastrado, possibilitando o roll-
-up correto de acordo com a natureza de cada conta. A Figura 8.57b ilustra as diversas
contas com os seus respectivos operadores.
10) A Figura 8.58 mostra um modelo dimensional para acompanhamento de
inserção de anúncios em programas de televisão, com controle de valor
pago e índices de audiência (Ibope) obtidos naquele horário. A dimensão
HORA, com dois relacionamentos diferentes (início e final), poderia ser
definida a priori, contendo registros em nível de minutos corridos para

221
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

um dia todo, contados a partir de meia-noite (24*60 = 1.440 registros).


A dimensão ANUNCIANTE é o foco do modelo, enquanto o código de
programa está entrando como uma dimensão degenerada, para alinhavar
as várias inserções realizadas durante aquele programa.

Figura 8.58
Modelo dimensional para acompanhamento de veiculação de
propagandas em programas de televisão.

Para aplicações que abrangem fusos horários diferentes é importante a definição


da dimensão TEMPO (data e hora) em termos do fuso local e da referência GMT (Gre-
enwich Mean Time), o que permitiria informações consistentes em termos de fusos,
para sistemas em âmbito mundial.
11) Data mart para hospital
O objetivo, neste exemplo, é montar um DM para controlar informações de
uma rede de hospitais. As informações básicas são mostradas no modelo relacional
(Figura 8.59). O modelo relacional mostra as entidades hospital, enfermaria e empre-
gados, num relacionamento 1:N clássico. Chamamos de internação as várias vezes que
o paciente se relacionou com o hospital. Da internação nascem todas as informações
sobre a estada dele (como paciente) no hospital, em certo período de tempo. Durante
essas internações, o paciente foi submetido a vários tratamentos, cujos itens podem
ter sido medicamentos ou procedimentos. Durante a internação, os dados relativos
ao acompanhamento do paciente foram registrados na entidade acompanhamento.
O modelo dimensional, mostrado na Figura 8.60, objetiva acompanhar informações
históricas do paciente ao longo de seus vários tratamentos, com a granularidade em
termos de item de tratamento. Dessa forma, a dimensão tratamento serve como um
alinhavo de todos os medicamentos e procedimentos realizados num período da di-

222
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

mensão TEMPO, para aquele paciente. É a chamada dimensão degenerada, mostrada


em pontilhado no diagrama. O aspecto geográfico do modelo se prende à hierarquia
HospitaloEnfermaria, que serve para relacionar os fatos com as empresas (hospital) e
suas unidades funcionais (enfermaria). As informações registradas na tabela fato serão
o custo (valor cobrado) de cada procedimento/medicamento aplicado naquele dia,
naquele paciente, além das medidas de análises clínicas colhidas sobre o paciente na-
quele dia. Esses últimos são valores normalmente não aditivos e podem ser várias me-
dições como temperatura, pressão etc. Observe as informações da tabela fato: aquele
paciente, internado naquela enfermaria, naquele dia, recebe (vários) medicamentos e
está sob a guarda de (vários) médicos de uma equipe médica. Isso mesmo. Algumas
vezes, os fatos se relacionam com mais de uma ocorrência de certa dimensão, como
já vimos anteriormente. Nesse caso, o fato está relacionado a vários médicos e a
vários medicamentos. É um relacionamento 1:N em vez de 1:1 (da tabela fato para
a tabela dimensão). Para resolver essa questão, temos de criar uma tabela ponte (de
relacionamento) que ligará a dimensão à fato. É o que aconteceu com medicamento e
médico, unidos à fato pelas tabelas ponte EQUIPE MÉDICA/MÉDICO e GRUPO/
MEDICAMENTOS. Para tal, as tabelas ponte ou de junção conterão as chaves que
permitirão a ligação entre as tabelas fato e dimensão, mantendo-se a semântica das
informações.

Figura 8.59
Modelo para sistema de informações hospitalares – modelo E/R.

223
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 8.60
Modelo dimensional para sistema de informações hospitalares.

A entidade ou tabela ponte, nesse exemplo, terá um relacionamento 1: N


com a dimensão (um médico participa de N equipes médicas) e um relacionamen-
to M:N com a tabela fato. Nesse M:N, de um lado, a tabela fato se relacionará, via
chave da equipe médica, com as várias ocorrências da tabela ponte (aquelas que
têm aquele valor para a equipe médica). Por outro lado, cada ocorrência da tabela
ponte (código-equipe e código-médico) se relacionará com as várias ocorrências
da fato que usam aquela mesma equipe médica. O conceito de procedimento no
modelo poderia também ser interpretado como múltiplo, da mesma forma como
desenvolvido para medicamento, mas, por questão de simplificação, não se optou
por essa linha.
É importante observar que o uso de tabelas pontes poderá implicar “overcoun-
ting” no valor associado na Tabela Fato. Para gerenciar esses aspectos, pode-se colocar
no relacionamento indicadores de % (percentagem) que servirão para distribuir os
valores corretamente. É importante também notar que o modelo dimensional deve
sempre refletir a implantação que se deseja e que, por isso, não terá necessariamente
o comportamento radial dos modelos dimensionais clássicos, com uma entidade fato
circundada por entidades dimensão, sugerindo uma topologia sempre bem compor-
tada, conforme os primeiros exemplos mostrados. Outro aspecto importante nesse

224
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

exemplo se refere à possibilidade de manter pesos (valores ponderados) na tabela pon-


te. O que isso significa? Por exemplo, na tabela ponte equipe médica/médico, pesos
podem significar o percentual com que cada membro da equipe participa na métrica
específica (por exemplo, o quanto cada um vai receber do valor cobrado naquele dia).
O importante é que esses percentuais somem 100%, para permitir o rateio correto da
métrica armazenada.

Dimensões com várias hierarquias


Observe a Figura 8.61. Nela aparecem representações de duas hierarquias com-
partilhando logicamente a mesma estrutura de dimensão. A dimensão tempo oferece
duas visões diferentes, com a hierarquia de calendário normal e calendário fiscal. Na
dimensão cliente, o último nível (cliente) tem, na realidade, duas hierarquias acima, uma
para o endereço de entrega e outra para cobrança. Essa representação conceitual, na
realidade, representa, no esquema estrela, a presença de duas chaves diferentes no regis-
tro de mais baixo nível. Assim, teríamos duas datas diferentes na dimensão tempo, bem
como teríamos dois endereços diferentes no nível de cliente.
Às vezes, as hierarquias, dentro da dimensão, são compartilhadas parcialmente,
como mostra a Figura 8.62. Nela, as dimensões depósito e pedido compartilham os
níveis país, estado e cidade.

Figura 8.61
Modelo dimensional – hierarquia compartilhada.

225
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 8.62
Modelo dimensional – hierarquia parcialmente compartilhada.

A Figura 8.63 mostra um modelo dimensional aplicado ao controle de proces-


sos judiciais. Nela há várias manifestações de hierarquias diferentes dentro da mesma
dimensão. A Figura 8.64 tem basicamente a mesma semântica, com a diferença de que
mostra os processos em andamento, portanto sem a data final e as métricas, que seriam
obtidas após a conclusão do processo. Assim, foi criada uma dimensão Status, que dará a
ideia do ponto em que o processo se encontra.

226
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.63
Modelo dimensional – controle de processos judiciais.

Figura 8.64
Modelo dimensional – controle de processos judiciais-estado/andamento.

Dimensões com níveis ausentes


Por vezes, as dimensões não têm a mesma estrutura preenchida em todos os seus
níveis. A semântica da dimensão permite ausência de valores em certos níveis. Veja a
Figura 8.65. Nela é mostrada uma dimensão tradicional com país, estado, condado e
cidade. Para a hierarquia dos Estados Unidos esses níveis são plenamente preenchidos,

227
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

não havendo vácuos. Entretanto, no caso do Reino Unido (UK) e do Vaticano, as hie-
rarquias aparecem com valores ausentes. No Reino Unido não existe o conceito de
estado, fazendo com que os valores do nível imediatamente acima sejam usados. Essa é a
recomendação técnica. No caso do Vaticano, não existe o conceito de estado, condado
e cidade, sendo o próprio valor “Vaticano” usado para preencher os vazios dos níveis
ausentes.

Figura 8.65
Modelo dimensional – níveis ausentes.

Modelo dimensional para o ITunes


Observe a Figura 8.66. Nela, apresentamos um modelo relacional que poderia
ser utilizado para registros de um ambiente ITunes. O elemento central do modelo seria
a dupla de música e gravações armazenadas. Ambas teriam alguns atributos de pesquisa
importantes. As listas formam o conceito de agregado/composição de várias gravações e
servem para ouvir músicas, de forma pré-selecionada. As informações sobre composito-
res e intérpretes fecham o ciclo de informações relevantes em um ambiente de controle
de músicas. A Figura 8.67 mostra o que seria uma solução dimensional, com a métrica
essencial de número de execuções, na granularidade de dia.

228
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

Figura 8.66
Modelo relacional – ITunes.

Figura 8.67
Modelo dimensional – ITunes, número de execuções.

229
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Modelo dimensional para controle de consultorias em MPS.BR


O modelo, apresentado na Figura 8.68, mostra uma visão dimensional que po-
deria ser aplicada no controle dos trabalhos de consultoria em MPS.BR. As dimensões
nível e empresa caracterizam o objetivo dos trabalhos de consultoria. Além da dimen-
são temporal, em nível de dia, aparece a estrutura padrão de relacionamentos M u N,
entre fato e a dimensão consultor, já explicada em exemplos anteriores. O atributo tipo,
em consultoria, serviria para separarmos as diversas naturezas do trabalho: reunião de
diagnóstico inicial, diagnóstico de pré-avaliação, auditorias, consultorias presenciais etc.

Figura 8.68
Modelo dimensional – trabalhos de consultoria MPS.BR.

EXERCÍCIOS PROPOSTOS
A seguir propomos um conjunto de situações para serem modeladas dimensio-
nalmente.
1) Exercício proposto 1
 Cenário:
 Empresa de consultoria.
 Trabalha com
 Consultores (número-empregado, nome-empregado, descrição-cargo, fone-
empregado, endereço-empregado, tag-gerente).
 Atende empresas clientes (código-empresa, nome-empresa, tipo-cliente,
ramo-negócio), nas quais desenvolve:
 Projetos (codigo-projeto, descrição-projeto, tipo-projeto, valor-projeto,
código-cliente, data-início, tempo-estimado, tempo-real, status-projeto).

230
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

 Consultores trabalham em vários projetos.


 Uma empresa pode ter vários projetos de consultoria em andamento.
 Fato principal:
 Controle de horas trabalhadas, despesas e lucros.
 Pede-se:
 Modelo dimensional.
 Sql exemplos de drill-down, drill-up.

2) Exercício proposto 2
 Cenário:
 Rede de farmácias.
 Trabalha com
 Produtos (chave-produto, descrição-produto, marca-produto, tipo-em-
balagem, tamanho-embalagem, categoria-produto, subcategoria-produto,
tipo-tarja, peso, princípio-ativo-produto, tag-tem-genérico, nome-labo-
ratório, nome-distribuidor, tipo-prateleira-necessária-produto).
 Vende em lojas (codigo-loja, nome-loja, endereço-rua-loja, endereço-
-número-loja, endereço-bairro-loja, endereço-cidade-loja, endereço-es-
tado-loja, zip-code, região-loja, número-fone-loja, nome-gerente-loja,
fax-loja, data-abertura-loja, metragem-loja).
 Vende por convênios (codigo-convênio, nome-convênio, nome-empre-
sa-conveniada, data-início-convênio, porcentagem-desconto-convênio,
tipo-documentação-exigida, tipo-faturamento-convênio).
 Dimensão tempo: considerar dia, mês, ano, trimestre, tag-feriado,tag-fim-
-de-semana, estação-do-ano, tag-fim-mês.
 Fato principal:
 Controle de quantidade-vendida, valor-vendido, custo-produto, lucro =
(valor-vendido  custo), margem-lucro = (lucro/valor-vendido), conta-
dor-de-vendas-produto.
 Pede-se:
 Modelo dimensional.
 Sql exemplos de drill-down, drill-up.
 Descrição de fatos aditivos, não aditivos, semiaditivos.

3) Exercício proposto 3
 Cenário:
 Empresa qualquer com controle de almoxarifado.

231
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Trabalha com
 Produtos (chave-produto, descrição-produto, marca-produto, tipo-em-
balagem, tamanho-embalagem, categoria-produto, subcategoria-produto,
peso, tipo-prateleira-necessária-produto).
 Guarda em almoxarifado (codigo-almox, nome-almox, endereço-rua-
-almox, endereço-número-almox, endereço-bairro-almox, endereço-
-cidade-almox, endereço-estado-almox, zip-code, região-almox, num-
-fone-almox, fax-almox, metragem-almox).
 Fato principal:
 Controle de quantidade-em-estoque, custo-médio e tempo médio de
rotatividade do estoque (por exemplo: rodam-se 10 peças por dia. Se
tenho 20 peças, sei que imobilizo por 2 dias). Isso daria ideia de custo de
armazenamento.
 Pede-se:
 Modelo dimensional.
 Sql exemplos de drill-down, drill-up.
 Fatos aditivos, não aditivos, semiaditivos. Sugerir o uso de uma view para
oferecer a informação de custo de armazenamento.

4) Exercício proposto 4
 Cenário:
 Empresa que presta serviços de TV a cabo e trabalha com as seguintes
transações:
 Abre uma conta.
 Fecha uma conta.
 Compra um pacote.
 Atualiza um pacote (muda opções).
 Cancela um pacote.
 Outros componentes:
 Cliente, produto, vendedor (atendente).
 Fato principal: valor
 Abertura de uma nova conta: valor é o valor da taxa mensal.
 Fechamento de uma conta: valor é o valor a ser pago, pelos dias restantes.
 Compra de pacote: valor é o valor mensal pelo pacote. Pode ser pago de
uma vez (considerado outro tipo de pacote).
 Atualização de pacote: acerto de valor proporcional ao restante do mês.

232
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

 Cancelamento de pacote: ressarcimento ao cliente pelo restante (propor-


cional aos dias).
 Obs. = O fato valor tem interpretações diferentes, dependentes da tran-
sação.
 Pede-se:
 O modelo e/r inicialmente e depois o modelo dimensional.
 Quando a granularidade é em nível de transações sugere-se a definição de
um agregado mensal, que consolide tudo no mês e mostre um valor reali-
zado.

5) Exercício proposto 5
 Cenário: olimpíadas
 Um data mart (modelo dimensional) para controle do quadro geral de me-
dalhas de todas as edições de jogos olímpicos realizados, por modalidade
esportiva.
 Modalidade esportiva: representa cada tipo de esporte com as suas varia-
ções. Por exemplo: futebol masculino, futebol feminino, nado livre 50 m,
nado livre 100 m, tiro, boxe categoria leve etc. A classe futebol tem mo-
dalidades futebol masculino, feminino. A classe natação tem natação livre
50 m, costas 100 m etc.
 As modalidades têm variadas formas de contagem de pontos. Por exem-
plo: futebol é medido pelo número de empates, derrotas e vitórias. Iatis-
mo é medido pelo número de pontos alcançados. Atletismo e natação são
medidos pela marca alcançada.
 É importante ter informações no nível de jogos olímpicos, como valor
gasto, número total de atletas, data início dos jogos olímpicos, data final
dos jogos olímpicos etc.
 Um data mart para controle de atletas que compete (em/iram) individual-
mente nas diversas olimpíadas.
 Considere o controle das medalhas ganhas (ouro, prata, bronze) ou nú-
mero de vitórias, empates, derrotas, ou das marcas alcançadas ou dos pon-
tos realizados, conforme o esporte do atleta.
 Um data mart para controle de equipes que competem.
 Considere o controle das medalhas ganhas (ouro, prata, bronze), ou nú-
mero de vitórias, empates, derrotas, ou das marcas alcançadas ou dos pon-
tos realizados.
 Um data mart para controle dos jogos realizados entre equipes que dispu-
tam modalidades de confronto direto (por exemplo, futebol, vôlei, basquete,

233
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

handebol etc.), visando controlar resultado, renda, público etc. Desses jogos
nas diversas fases dos jogos olímpicos.
 Abordagem dimensional:
 Procure, para cada modelo solicitado, inicialmente definir a sua granula-
ridade. Analise os requerimentos e identifique a granularidade (nível de
informação requerida) que atenda. Procure sempre a maior granularida-
de possível.
 Identifique as dimensões – veja que, na fase anterior, você já discutiu
as dimensões ao definir a granularidade. Agora é hora de estendê-las, ou
seja, colocar outros atributos que permitam melhorias de seus acessos.
 Analise as métricas que fazem sentido diante dos requerimentos soli-
citados. Lembre-se de que, às vezes, uma tabela fato pode ter poucas
métricas e a sua função fica mais para estabelecer relacionamentos entre
as diversas dimensões. Veja o sentido de métricas aditivas, semiaditivas ou
não aditivas.
 Procure enriquecer o modelo com outras informações, caso ache ne-
cessário.

234
ELSEVIER
C APÍTULO 8 I M ODELAGEM D IMENSIONAL DE D ADOS – D ETALHAMENTO

RESUMO – PASSOS DA MODELAGEM DIMENSIONAL


1. Definir a área de negócios.
 Prioridades de negócios, percepção de mercado, comportamento de cliente.
2. Definir processo(s) dentro da área de negócios.
3. Definir a granularidade desejada para os dados do processo.
 Considerar volumes e dificuldades de obter o nível granular desejado.
4. Definir os atributos e hierarquia das dimensões.
 Considerar hierarquias múltiplas.
5. Definir as métricas das tabelas fato.
 Observar os valores aditivos, semiaditivos e não aditivos.
6. Algumas dicas importantes na modelagem dimensional:
 Faça ou use um modelo de dados convencional E/R como ponto de parti-
da para o trabalho de modelagem dimensional. Isso poderá ajudar.
 Observe os relacionamentos 1:N existentes – eles podem sugerir dimensões.
 Observe as entidades fortes – elas também podem sugerir dimensões.
 Observe as entidades que expressam documentos como nota fiscal, ordem
de pedido, pedidos de compra etc. – elas podem sugerir fatos.
 Observe os relacionamentos M u N – na sua interseção pode haver valores
numéricos, o que sugere fatos.
 Observe os atributos que estarão na tabela dimensão. Analise a relação de
hierarquias entre esses atributos da dimensão. Atente para relacionamentos
M u N entre eles. Isso pode definir granularidade.
7. Algumas dicas importantes sobre tabelas fato e tabelas dimensão
 As tabelas fato tipicamente armazenam dados valores atômicos ou agregados
obtidos a partir deles.
 As métricas das tabelas fato são normalmente aditivas em certas dimensões.
 As tabelas fato possuem chaves que as conectam às diferentes dimensões que
as circundam. Essa conexão se dá num nível de granularidade compatível
entre elas (fato e dimensão).
 As tabelas dimensão armazenam os valores de filtro, check, acesso e textos
que caracterizam os dados trabalhados.
 As tabelas fato são normalmente normalizadas.
 As tabelas dimensão são normalmente desnormalizadas (opção star schema
ou esquema estrela) ou normalizadas (opção flocos de neve ou snowflake).
 A granularidade combinada da tabela fato com a de suas tabelas dimensão
determina o número de linhas das tabelas do projeto.

235
CAPÍTULO 9

Projeto de aplicações de BI

FASES DE UM PROJETO DE DATA WAREHOUSE/DATA MARTS


Um projeto de DW/data mart se inicia como os outros projetos de bases de
dados do ambiente transacional, porém com uma motivação diferente na sua essência.
Enquanto o primeiro busca uma solução que objetiva facilitar a condução operacional
da empresa, o outro visa à produção de informações necessárias para processos de to-
madas de decisão. Os principais pontos a considerar em um projeto dessa natureza são
os seguintes.

Definição da área de negócio


Uma área de negócio é devidamente escolhida com base nas prioridades emer-
gentes da empresa, principalmente relacionadas às necessidades de informações para
tomadas de decisão. As áreas mais usuais para condução de projetos iniciais de DW
são clientes, finanças, vendas, produção etc., e sempre associadas com as prioridades
reais de negócio da empresa, atreladas aos direcionamentos estratégicos definidos pela
alta direção. Um plano estratégico ou um diagnóstico prévio poderá ser feito para
melhor balizar a escolha das áreas-alvo. Escolhida a área de negócio, parte-se para
definir aqueles que serão os processos-alvo do projeto de BI: varejo, entrega, controle
de pedidos, estatística de venda, assinaturas etc. Os conceitos de mapeamento de pro-
cessos ganharam musculatura com a introdução das técnicas de BPM (Business Process
Modeling) e hoje se encontram na tela de radar de muitas empresas, em um momento
de repensar caminhos e redefinir negócios. Os processos que compõem o modelo de
negócios de certo segmento deverão ser analisados por uma abordagem que permita
o seu pleno entendimento, com o detalhamento de entidades de dados de alto nível,
relacionamentos, atributos principais, interações etc. É a primeira fotografia.

Definição da arquitetura da solução


Em paralelo, uma arquitetura da solução vai definir a forma pela qual as estru-
turas fundamentais de dados e de seus tratamentos serão montadas. A Figura 9.1 mostra
a arquitetura centrada em um DW integrado, também chamada de data warehouse
corporativo, formada por um modelo caracteristicamente relacional, em que tabelas,
relacionamentos, atributos e regras são definidos. Essa arquitetura tem como vanta-
gem o estabelecimento de um ponto central de gerência sobre os dados, criando uma
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

camada de recursos informacionais que será utilizada por várias linhas de negócios. A
desvantagem fica pelo controle demandado, visto envolver interesses de diversas áreas
de negócios da empresa, com potencial conflito no uso desejado da informação e de
sua estrutura básica. Essa arquitetura deverá ser pensada de forma global, de maneira a
atender a diversos aplicativos, e isso pode trazer complexidade para o projeto. Embora
pensada e alinhavada de forma corporativa, a arquitetura poderá ser construída gradati-
vamente a fim de minimizar os riscos envolvidos em projetos agigantados e multifun-
cionais. Embora planejado com uma visão centralizada, o DW corporativo poderá ser
implementado em topologia fisicamente distribuída, embora logicamente centralizada,
caracterizando o conceito de hub and spoke.

Figura 9.1
Arquitetura de DW centralizado.

A outra arquitetura passível de ser definida é mostrada na Figura 9.2, na qual


os elementos são basicamente os mesmos, com a diferença do repositório central que,
no caso, é formado por data marts integrados, ligados por dimensões “conformes”.
Essa arquitetura tem a vantagem de ser construída de forma mais independente, porém
demanda um plano de integração mais cuidadoso, visto que os marts serão construídos
gradativamente atendendo a linhas de negócios separadas, e até independentes, e de-
verão ser integrados por dimensões compatíveis. São estruturas de dados centradas nos
modelos dimensionais e contemplam toda a discussão do capítulo anterior.

238
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

Figura 9.2
Arquitetura de data marts integrados.

Independentemente da arquitetura escolhida, o processo de implementação


de um DW/DM deverá ser baseado tendo a Figura 9.3 como guia. A ideia é definir
uma forma iterativa de projetar uma solução de BI criando uma abordagem ilus-
trada pelos dois ciclos mostrados na figura. O primeiro ciclo (menor) mostra um
conjunto de atividades que será a base do planejamento para o desenvolvimento
mais detalhado no ciclo maior. A proposta seria o ciclo menor definir o contexto
do que chamamos de release, ou seja, um nível de produto que poderia ser um ou
mais segmentos de negócios do DW ou data marts que, gradativamente, formarão o
data warehouse. No ciclo maior, teríamos as diversas iterações que poderão ser exe-
cutadas para desenvolver os respectivos produtos de um projeto de BI. Por exemplo,
uma iteração para criar os elementos centrais de um data mart, como fatos e di-
mensões mais prementes, algumas funções de front-end para a sua utilização e fun-
ções iniciais de ETC para a sua criação básica. Depois, em ciclos sucessivos, outros
segmentos ou submodelos (TFato e dimensão) que complementariam a primeira
camada, com extensões do projeto de front-end e ampliação da camada de ETC.
Assim, sucessivamente, vamos construindo a solução de BI, porém com o cuidado
de sempre prover entregas sucessivas.

239
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 9.3
Visão – ciclo de vida iterativo incremental para projetos de BI.

A proposta tem um forte sabor de abordagens iterativas incrementais, ampla-


mente aplicadas no desenvolvimento de sistemas transacionais. O fundamental, por trás
de uma abordagem dessa natureza, é a agilidade que deve ser observada de forma a
obter resultados entregáveis em ciclos menores de desenvolvimento, criando um clima
de expectativa atendida com relação aos patrocinadores do projeto. Por outro lado, no
ciclo do release é fundamental que aspectos relacionados à visão do “todo” sejam obser-
vados, cuidando para que se construam partes encaixáveis e integráveis, com o menor
nível de ruptura possível. Definidas as áreas/assuntos do primeiro release, parte-se para
estabelecer uma visão que permita amarrá-las, à medida que as implementações forem
realizadas separadamente. Isso, no fundo, significa ter, em um nível razoável, as principais
dimensões requeridas e as métricas (dados) para que esses projetos possam ser coerente-
mente alinhavados.
Para a abordagem de um DW corporativo também se deve atentar para esses
detalhes de modelos relacionais e seus relacionamentos acopláveis entre segmentos de
negócios. Isso não é uma tarefa trivial, pois poderá envolver um trabalho de levanta-
mento e análise, mesmo que introdutório, de várias áreas, podendo estender o cro-
nograma de desenvolvimento do trabalho. O ideal é conseguir estabelecer um meio-
termo entre o desenvolvimento gradual dos projetos de DW/DM e a definição de
elementos “conformes” e compatíveis, que permitam a integração gradativa dos DW/

240
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

DM, sem dilatação dos cronogramas dos projetos. Uma forma de controlar é garimpar
as tabelas/dimensões que serão demandadas em cada área de negócios da empresa, ob-
servando, nessas estruturas, a sua semântica (o que ela significa) para aquele contexto,
os seus atributos e as suas hierarquizações. Isso permitirá o mapeamento de relações/
dimensões em conformidade, o que significa que os elos entre os DM ou regiões
do DW estarão identificados e possibilitarão as conexões futuras e integrações sem
grandes traumas.

CICLO DOS RELEASES


O ciclo dos releases se baseia no levantamento macro das necessidades e no pla-
nejamento das iterações que comporão o desenvolvimento daquela solução (release). As
atividades do ciclo de release envolverão:
1) Levantar as áreas targets dos projetos, definindo os seus objetivos de negó-
cios, seus usuários e patrocinadores fortes, e diagnosticar as dificuldades
de informação encontradas. Envolve também priorizar uma área target
para o ciclo específico do release. Isso significa que você deverá se preparar
para as reuniões com os usuários, quando serão levantadas as suas neces-
sidades de informação, definido o escopo do projeto e seus respectivos
níveis de serviços e produtos planejados. As reuniões serão planejadas no
seu conteúdo, participantes envolvidos, horários acertados, além dos re-
cursos necessários etc. Para essas reuniões de visão macro, tenha foco nos
drivers estratégicos de negócios que regem qualquer empresa como cli-
entes, produtos, qualidade de serviços, mercados, pessoas, conhecimentos
etc. Por exemplo:
 Aumento de faturamento na forma de identificação de novos mercados
e segmentos, ações mais efetivas de vendas, maior rapidez na detecção de
oportunidades de negócios e maior rapidez na entrada no mercado.
 Aumento de lucro, na forma de melhor direcionamento de campanhas, de-
tecção precoce de declínio de mercado, identificação de produtos ou linhas
de produtos com baixo desempenho, identificação de deficiências internas
e melhoria de efetividade no merchandising da empresa.
 Aumento da satisfação dos usuários por melhor conhecimento de suas pre-
ferências, melhor casamento entre eles e seus produtos, melhor resolução de
reclamações e maior qualidade nos seus atendimentos.
 Foco na redução de gastos, com controle de desperdícios com maior efeti-
vidade dos processos internos de gestão.
 Aumento na participação do segmento de mercado (market share), com ex-
pansão da base de clientes ou manutenção da taxa de retenção de clientes.
É claro que, dependendo do business da empresa, esses elementos deverão ser
devidamente mapeados para as respectivas linhas de negócios.

241
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

2) Realizar a análise de dados e processos envolvidos na área target definida. Os


conhecimentos dos processos e dos dados associados são fundamentais para
criar uma forte base para o projeto de BI. Os processos deverão ser anali-
sados de forma macro, porém com abrangência necessária para permitir
uma visão de como os dados focos do projeto são criados, custodiados (ar-
mazenados) e consumidos. São os já famosos CCC (Creators, Custodians e
Consumers). Observe a Figura 9.4, que mostra um esquema ilustrando como
as principais fontes de dados deverão ser mapeadas com os seus respectivos
processos de criação, custódia e consumo, obtendo-se, dentre outras, as se-
guintes informações:
 Qual é o significado daquela fonte?
 Quais são os eventos de negócios relacionados com a fonte?
 Quais são os atributos relevantes da fonte para aquela área de negócios?
 Quais são as métricas obtidas da fonte e quais dimensões potencialmente a
contextualizariam melhor?
 Qual é a frequência de atualização da fonte?
 Quais são os níveis históricos de retenção de informação desejados?

Figura 9.4
Modelo de mapeamento entre fonte de dados e áreas de negócios.

242
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

3) Realizar a análise de qualidade de dados existentes através de mecanismos


de levantamento ou pesquisa dos usuários da área com relação à percepção
de qualidade ou através de um projeto específico de data profiling (análise
quantitativa de qualidade de dados). A avaliação da qualidade dos dados
existentes poderá ser feita em um projeto independente do projeto de BI,
como uma iniciativa da área de governança e de qualidade de dados e re-
comendável que seja anterior ao de BI. Os principais conceitos associados
a essa parte estão descritos no capítulo dedicado à governança e qualidade
de dados.
Importante: Os aspectos de qualidade de dados deverão ser estabelecidos se-
gundo os padrões de governança e qualidade de dados, aplicados em domínios diver-
sos de qualidade: integridade de dados (dados sem erros, com representação concisa,
completos e consistentes) ou utilidade (na quantidade apropriada, com relevância
para os fins a que se destinam, entendíveis e passíveis de serem interpretados) ou com
outros atributos, como credibilidade, acessibilidade, facilidade de manipulação, repu-
tação, disponibilidade, pontualidade, além de segurança e confiabilidade. Todos esses
atributos de qualidade de dados deverão ser contemplados no contexto da governança
e qualidade de dados.
4) Avaliar a infraestrutura disponível na empresa, as opções de tecnologia
e realizar uma análise inicial de riscos. A disponibilidade de dados com
qualidade, aliada à capacidade tecnológica da empresa, é um dos fatores
de risco a serem considerados nessa fase, quando se pensa em um pro-
jeto de BI. Antes de iniciar o projeto de DW/DM deve-se atentar para a
arquitetura tecnológica que servirá de base para o projeto. É fundamen-
tal que os componentes básicos da arquitetura sejam definidos antes do
início do projeto do DW/DM, pois fatores relacionados ao desempenho
e à disponibilidade podem definir níveis de serviços e graus de compro-
missos variados durante o projeto. Os componentes tecnológicos básicos,
conforme as Figuras 9.1 e 9.2, que deverão ser observados além da capa-
cidade da rede corporativa, são:
 Sistema gerenciador de bancos de dados: representa o ambiente no qual o
data warehouse ou os sistemas transacionais residem, devendo ser máquina
mais robusta, e, dependendo do projeto, um ambiente de alta disponibilida-
de, desempenho e segurança.
 Ferramentas de desenvolvimento de sistemas OLAP e mining: são os pro-
dutos que desenvolvem e executam aplicações de BI e, em casos especiais,
aplicações de data mining.
 Ferramentas para processos de extração, transformação e carga: conjunto
de ferramentas desenvolvidas internamente ou adquiridas no mercado com
o objetivo de realizar os processos de extração, transformação e carga dos
dados. Hoje, existe no mercado um conjunto de ferramentas robustas que
integram soluções para atender à camada de ETC.

243
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Catálogo/repositório para controle de metadados: ferramenta desenvolvida


internamente ou adquirida no mercado, que objetiva o controle dos me-
tadados do projeto. Os metadados representam uma importante camada de
documentação dos DW/DM, permitindo que a empresa conheça todas as
informações associadas com o ambiente de BI, e abre uma porta para a en-
trada na nova era de gerência de conhecimento.
 Servidor de data mart/cubos: representa o ambiente no qual reside o ge-
renciador dos data marts. Nele residem os DM, ou parte deles, na forma de
extrações ou cubos, agregados etc., voltados para aplicações analíticas espe-
cíficas. Representa extratos de um conjunto maior de dados, normalmente
estruturados no modelo dimensional. Pode estar no mesmo ambiente físico
do DW.
 Extrato de dados para data mining: representa o armazenamento de in-
formações definido de forma especial e que objetiva atender aos requi-
sitos de mining de dados, aplicados a sistemas de inferência de informa-
ções.
5) Definir requisitos de informação, em nível macro, mapeando os princi-
pais problemas de informações, tomadas de decisão, necessidades de in-
formações no tempo correto etc. Os requisitos de informação levantados
poderão ser mapeados e documentados através de casos de uso de BI, em
nível macro (ou fachada) ou no conceito de temas e épicos, na linguagem
Scrum. O conceito de casos de uso tem sido amplamente usado nos sistemas
transacionais, mas pouco explorado no ambiente de BI. Aqui vão algumas
ideias importantes sobre o uso dessa técnica como elemento de modelagem
de requisitos de informação para sistemas de BI:
 Entender que os sistemas de BI são data driven e que os conceitos originais
de CSU foram desenvolvidos para sistemas action driven/process driven e, por-
tanto, exigirão certas adaptações para o seu uso em BI.
 Entender que um sistema de BI basicamente pode ser visto como composto
de dois grandes segmentos de aplicações, conforme mostrado na Figura 9.5:
aplicações back-end e aplicações front-end. As aplicações back-end com-
preendem todas as atividades de criação e manutenção das camadas de dados
(DW e DMart), além das camadas de Staging e ETC, ou seja, representam
a retaguarda de um sistema de BI. A aplicação de front-end representa a
parte definida para atender diretamente às necessidades de negócios, com
os aplicativos de pesquisa, de geração de relatórios, de planilhas dinâmicas,
de dashboards, de análise inferencial etc. A Figura 9.6 ilustra um conjunto
de aplicações de front-end que atendem às diversas necessidades de infor-
mação de uma área cliente, indo de ferramentas dashboard para indicadores
em níveis mais estratégicos a planilhas dinâmicas, passando por aplicações
OLAP e mining.

244
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

Figura 9.5
Tipos de aplicações de projetos de BI: front-end e back-end.

Figura 9.6
Aplicações de front-end.

245
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Entender que as solicitações de funcionalidade do front-end de BI são dinâ-


micas, fortemente ad hoc e, portanto, nem sempre mapeáveis em um levan-
tamento inicial de requisitos.
 Assim, os CSU para front-end de BI ficam mais no plano conceitual das
consultas, como gerar relatórios, produzir cubos, gráficos, planilhas dinâmi-
cas, aplicações e análises de mining, aplicações OLAP, analytics, quase sempre
inexistindo CSU de alterações de dados.
 No plano de back-end de BI, os requisitos ficam mais voltados para as ativi-
dades operacionais de Staging/ETC, como realizar extração, conferir extra-
ção, carregar dados, gerar cubos etc. Propomos o uso de uma oval cortada
para identificá-los visualmente.
 A Figura 9.7 ilustra um escopo de BI com a modelagem de casos de uso,
seus atores principais e o detalhamento do seu descritivo, definido pelos
atributos a seguir:

Figura 9.7
Modelo de casos de uso para BI.

246
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

 ID DO CSU-BI: CSUBI-001
 Descrição de CSU-BI: consulta que mostra as quantidades vendidas e os
valores de venda de produtos, por categoria, dentro de loja, agregado por mês
 NOME SIMPLIFICADO: por exemplo, relatório de vendas de produtos
por categoria/loja/mês
 CLASSE: CSU de front-end ou de back-end
 TIPO: define o nível de detalhe: fachada/negócio (épico), usuário/detalhe
médio (tema) ou detalhado (história)
 ORIGEM: solicitado via cliente (fornecedor de requisitos) ou da equipe
interna
 ÁREA: domínio de negócios (financeira, marketing, vendas, cliente etc.)
 PAPEL: papel do usuário do CSU-BI
 FONTES DE DADOS: fontes de dados envolvidas no CSU-BI
 DATA-APROVAÇÃO: 99/99/99
 DATA-CRIAÇÃO: 99/99/99
 CENÁRIO PRINCIPAL: nos CSU-BI, o cenário principal é tão impor-
tante quanto os cenários alternativos. Descreve-se aqui a funcionalidade
básica do CSU, estruturando em segmentos de funcionalidades emoldura-
das por rótulos que caracterizam aquela atividade
 CENÁRIOS ALTERNATIVOS: representam as diversas opções de pes-
quisas do CSU-BI
 CENÁRIOS DE EXCEÇÃO: baixa utilidade, para os CSU-BI de front-
end que são read-only. Os de back-end, de natureza operacional, têm
cenários de exceções, mais voltadas para o plano operacional, como erros,
interrupções etc.
 RELACIONAMENTOS: mostra os relacionamentos com outros CSU-
-BI, podendo-se utilizar os conceitos de Include, Extend e Generalize.
 As Figuras 9.8a, 9.8b e 9.9 ilustram casos de uso do ambiente de front-end e
de back-end, usando relacionamentos normais de casos de uso, como extend
e generalize. A Figura 9.8a mostra o uso do relacionamento de <<extend>>,
que representa uma funcionalidade opcional que pode ser adicionada àquele
caso de uso. O caso de uso estendido, porém, é concreto, pois pode existir sem
aquela funcionalidade opcional. No exemplo, os casos de uso Cria Relatório e
Cria Cubo foram estendidos com a funcionalidade de envio para a GS (gerên-
cia sênior). A Figura 9.8b mostra um conjunto de casos de usos de back-end,
com os seus principais atores envolvidos, inclusive o dispositivo temporal,
muito comum nos disparos de funcionalidades de back-end, como execução
de jobs de limpeza, transformação, carga etc. A Figura 9.9 mostra um diagrama
Caso de uso, com um CSU abstrato. Ele estabelece uma forma de relaciona-
mento <<generalize>> com os concretos, caracterizando casos de usos que
executam tipos diferentes de cubos ou relatórios. Nessa fase também se deve

247
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

atentar para a obtenção de dois modelos de dados em nível conceitual: o


primeiro modelo é o modelo dimensional, ou aquele que representa os blocos
conceituais de dados necessários ao alcance dos objetivos do sistema de BI.
Nesse ponto é importante observar que os dados a serem modelados deverão
ser garimpados nos seus vários níveis de detalhes e sumarização. O outro mo-
delo é relacionado com as fontes das informações. É o modelo fonte dos dados.
Nele, deverão ser registrados os blocos conceituais de dados existentes, com
suas respectivas descrições e formas atuais de armazenamento e de uso nos
sistemas, e que provavelmente habitam os variados ambientes operacionais da
instalação ou as fontes externas de dados. Ambos complementam ou esten-
dem as informações já levantadas no item 2 do ciclo de releases.

Figura 9.8
Exemplos de casos de uso para BI: front-end e back-end.

Figura 9.9
Exemplo de CSU – Generalize em casos de uso de BI.

248
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

6) Definir plano do projeto do release com a identificação inicial das suas ite-
rações e seus respectivos produtos previstos. O plano de projeto do release
deverá contemplar os principais ingredientes de qualquer plano de projeto,
como escopo, tamanho, prazo, custo, comunicação, recursos humanos e
conhecimentos, recursos materiais, riscos, acompanhamento etc. As empre-
sas que adotam o modelo PMBOK ou se utilizam de abordagem MPS.BR
poderão se valer dos resultados esperados do processo de GPR, para melhor
definir o plano de projeto, conforme ilustrado na Figura 9.10. Observe
que, atrelados ao plano de projeto, deverão estar os planos de medição, de
garantia da qualidade e de gerência de configuração.

Figura 9.10
Ilustração dos componentes de um plano de projeto aplicado em BI.

 O plano de medição atende à gerência quantitativa de projetos, que


é uma prática gerencial que objetiva definir, coletar, analisar e repor-
tar informações ou atributos de processo, permitindo que um método
analítico comparativo possa ser estabelecido pela empresa para avaliação
numérica de projetos. O objetivo de medições e análise é garantir que
medidas sejam definidas, coletadas e armazenadas em bancos de dados de
tal forma que, ao longo do tempo, os projetos possam ser comparados nos
seus consumos de recursos, avaliados por atributos, criando referências
históricas fundamentais que se retroalimentam. Também objetiva acoplar
o planejamento estratégico da empresa, com seus indicadores de direcio-

249
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

namento associados aos indicadores dos projetos. No Capítulo 11, com


foco no BI2, discutiremos aspectos de definição de repositórios voltados
para esse tipo de dado e a aplicação de técnicas de BI para tratá-los.
 O plano de garantia da qualidade atende à gerência de qualidade, que é
uma prática gerencial que objetiva garantir que os processos e os produ-
tos deles derivados estejam definidos de acordo com os padrões estabele-
cidos pela empresa, dentro da ótica de qualidade. O objetivo da garantia
da qualidade é garantir o preceito de que “de cano sujo não sai água lim-
pa”, ou seja, se a empresa define corretamente um processo de produção
de software e de serviços, presume-se que, desse processo, sairão produtos
com o nível demandado de qualidade, desde que aplicados corretamente.
Além disso, com a garantia de qualidade, procura-se diminuir a incidên-
cia de retrabalho no processo de engenharia do software, além de garantir
um produto que vá atender às necessidades do cliente que demandou a
sua criação.
 O plano de gerência de configuração atende à gerência de configuração,
que é uma prática gerencial que objetiva controlar a evolução de arte-
fatos e documentos de um projeto de software. O controle se baseia na
necessidade de que os diversos artefatos e documentos de um projeto
de software são constantemente alterados e devem manter o nível de
atualidade, coerência e integridade entre eles. O objetivo da gerência de
configuração é garantir que os artefatos e documentos que formam um
produto de software estejam coerentes nas suas relações e íntegros na sua
formação. Isso representa uma grande probabilidade de que o software
formado/documentado por esses itens funcionará corretamente e poderá
ser usado adequadamente.

O CICLO DAS ITERAÇÕES


O modelo das iterações deverá ser visto como uma parte do projeto em que
cada ciclo desenvolverá uma parte relevante e incremental da solução de BI. As princi-
pais fases do ciclo das iterações, conforme a Figura 9.3, são:
 Definir o objetivo da iteração: nesta etapa, busca-se dar certo grau de deta-
lhamento à solução que será desenvolvida e cuja visão mais geral foi forma-
tada no ciclo dos releases.
 Planejar a iteração: o detalhamento do escopo, com uma revisão do plano
de projeto definido no ciclo de releases, agora com foco no desenvolvimento
da primeira iteração, será o produto dessa etapa/atividade. As partes mais
importantes desse novo momento de planejamento, agora detalhado, serão
o esforço e o cronograma, além do detalhamento dos requisitos, anterior-
mente considerados de forma macro.
 Detalhar os requisitos de informação: agora, de posse dos requisitos defi-
nidos em nível macro na fase de release, parte-se para especificá-los. Aqui

250
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

poderão ser usados os CSU-BI em nível detalhado ou de histórias especifi-


cadas, no linguajar Scrum.
 Projetar a aplicação de BI e ETC: a aplicação de BI passa pela definição da
modelagem relacional ou dimensional da solução, no primeiro caso, com
o detalhamento das tabelas, de seus atributos e relacionamentos ou, no se-
gundo caso, das tabelas fato e dimensão, definições de métricas, agregados,
hierarquias etc. A parte de BI deverá ser projetada considerando-se os as-
pectos de mapeamento do modelo relacional em tabelas ou do dimensional
em soluções de bancos de dados, com opções Rolap, Holap e Molap (ver
adiante, em projeto físico). O devido mapeamento entre os dados fontes e as
respectivas tabelas no modelo relacional/dimensional ajuda a melhor definir
o projeto de ETC. A solução de ETC deverá ser projetada, considerando-se
a camada de Staging e os movimentos e processos de extração, transformação
e carga. A Figura 9.11 ilustra alguns conceitos dessas atividades.

Figura 9.11
Exemplo de funções de Back-End – Extração, Transformação e Carga.

 Projetar a aplicação de front-end: nesta etapa serão projetadas as aplicações


diversas que comporão a solução de BI. Poderá envolver o desenvolvimento

251
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

de aplicações OLAP, aplicações de mining etc. Um ponto fundamental a ser


considerado é o desenvolvimento de protótipos que possam ser validados
pelos usuários. Alguns pontos importantes do projeto de front-end: devem
alcançar objetivos de negócios, possuem forte característica centrada em
requisitos não funcionais, como usabilidade (facilidade e conforto de uso),
segurança (garantia de privacidade e disponibilidade das informações), esca-
labilidade (capacidade de evoluir com maior volume de dados e de proces-
samento), extensibilidade (novas funções colocadas sem impactos), confiabi-
lidade (uso de dados e informações com qualidade) etc., e é implementado
na forma de relatórios, cubos, planilhas dinâmicas, produção de gráficos,
dashbords, aplicações de mining, analytics etc.
 Implementar aplicação de front-end: nesta fase acontece o desenvolvimento
da solução, com a produção dos aplicativos. No caso de soluções de BI, não
existe grande intensidade de tarefas de codificação, e sim de definição, ajuste
de ferramentas e execução de scripts.
 Implementar os dados (BI) e ETC: nesta fase, implementam-se as soluções
definidas tanto para a camada de front-end quanto para a de back-end.
 Testar a solução completa, parte front-end e parte ETC: aqui deverão ser
aplicados os planos de testes. A solução de back-end é testada mais do pon-
to de vista de fluxo operacional, pois normalmente envolve ferramentas
prontas que coletam, transformam e carregam dados. É claro que alguns
programas desenvolvidos deverão ser testados. Caso a estratégia de extração
de dados passe por adaptações dos sistemas fontes, isso se torna crítico, pois
envolve sistemas transacionais importantes da empresa. Nesse caso, um ri-
goroso plano de teste deverá ser elaborado. Para as aplicações de front-end,
após a elaboração de protótipos que representam uma forma relevante de
validação, planos de testes deverão ser aplicados nas gerações de relatórios,
cubos etc.
 Treinar os usuários na aplicação de BI: esta parte da transição do sistema
é importante, pois serve como aculturamento aos novos conceitos de BI
implementados e atinge normalmente uma plateia mais exigente, formada
por gerências em diversos níveis.
 Implantar a solução de BI: a implantação da solução de BI é posta em
produção e deverá ser acompanhada. Um dos fatores críticos de sucesso
em uma implantação de solução de BI é o acompanhamento estrito de sua
utilização. Há até algumas propostas para fazer o que se chamaria de BI do
BI, uma espécie de aplicação que acompanharia o uso das soluções de BI da
empresa, dando o perfeito enquadramento do retorno e da validade daquela
solução. Essa aplicação poderia definir como métricas o número de uso/
acesso e usuários de data marts ou cubos, bem como o número de solicita-
ções de evolução da solução.

252
ELSEVIER
C APÍTULO 9 I P ROJETO DE A PLICAÇÕES DE BI

 Avaliar os resultados, o processo aplicado e as lições aprendidas: esta última


etapa pode ser entendida como a avaliação do processo aplicado no desen-
volvimento daquela solução, criando as lições aprendidas a serem observadas
nos ciclos subsequentes de desenvolvimento.

RESUMO
Esta parte é fundamental no projeto do sistema, pois define uma arquitetura
baseada em DW corporativo (modelo relacional) ou em data marts integrados (modelo
dimensional). Define e analisa as diversas fontes de dados sob a perspectiva de sua ade-
rência aos propósitos do negócio, além da qualidade de seus dados. Passa pela definição
dos casos de usos de BI, separando-os em funcionalidades de front-end, dedicadas ao
usuário final, e de back-end, focadas nos procedimentos de ETC e outros. Chega à
implementação e, na validação, está prioritariamente centrado em protótipos amigáveis.
O processo pode ser todo desenvolvido em ciclos iterativos, com releases e iterações
para produzir entregáveis, de âmbito interno ou externo (cliente). Aqui cabe uma forte
conexão com as abordagens ágeis, descritas no BI ágil, no capítulo 11.

253
CAPÍTULO 10

Projeto físico de aplicações de BI

INTRODUÇÃO
Ao longo do ciclo iterativo, em determinado momento, o projeto chegará à fase
de desenho físico do DW/DM, quando passamos a definir as tabelas e seus elementos
correlatos (atributos, regras, índices etc.) dentro do ambiente de gerência de bancos de
dados que suportará o projeto.
Vários aspectos relacionados ao projeto físico de bancos de dados deverão ser
considerados para garantir desempenho, disponibilidade, segurança etc. nos acessos às
estruturas relacionais ou dimensionais, que formam o arcabouço computacional do sis-
tema de BI. Neste texto, discutiremos essencialmente os tópicos relacionados ao SGBD
relacional, com ênfase no Oracle, no SQL-Server da MS e no DB2 da IBM. As Figuras
10.1 e 10.2 mostram, respectivamente, um modelo de entidades e relacionamentos de
uma empresa de vendas e o modelo dimensional equivalente que servirá de exemplo
para os itens discutidos neste capítulo. Os tópicos gerais discutidos são:

Figura 10.1
Modelo relacional usado nos exemplos do capítulo.
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 10.2
Modelo dimensional usado nos exemplos do capítulo.

1) Estimativa do tamanho do DW/DM


2) Criação do data base
3) Criação de espaços de tabelas
4) Criação das tabelas
5) Definição de campos-chave e restrições
6) Definição de índices e estruturas especiais para acessos aos DW/DM
7) Considerações sobre cargas de tabelas
8) Aspectos gerais de desempenho
9) Arquitetura de servidores para DW/DM
10) Tendências tecnológicas para processamento de altos volumes (big data)

Estimativa do tamanho do DW/DM


A estimativa das estruturas informacionais de um projeto de BI, quando em
modelo dimensional, deverá ser realizada de acordo com os seguintes passos:
 Calcular o espaço requerido para a tabela fato: o primeiro passo para o cál-
culo da tabela fato é entender a sua granularidade, com a frequência média
de suas ocorrências e definir o tamanho de cada linha. Para isso deve-se

256
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

somar o tamanho dos campos-chave da fato com o tamanho dos outros


campos, que devem ser as métricas desejadas. Em nosso exemplo, vamos su-
por que temos, na média, cinco transações de clientes por dia e temos 15 mil
clientes. A perspectiva de armazenamento é para seis anos. Logo, teremos
15.000 u 5 u 365 u 6 = 164.250.000 ocorrências. Agora vamos definir o
tamanho de cada linha da tabela fato. O número de chaves na tabela fato será
de seis, cada qual com 4 bytes. As chaves estrangeiras gastarão 4 bytes, pois
serão definidas com o campo IDENTITY no SQL-Server, em nosso exem-
plo, ou qualquer outro tipo de campo de numeração sequencial, formando
uma chave surrogate ou sem conteúdo semântico. Os outros quatro campos
serão também de 4 bytes, pois serão armazenados como valores numéricos.
Logo, o tamanho da linha da tabela fato será de 40 bytes. Multiplicando pelo
número de ocorrências (164.250.000), teremos a estimativa final de 6,6 GB
de espaço previsto.
 Calcular estimadamente o espaço para as tabelas dimensão e para os índi-
ces: para o cálculo das tabelas dimensão e dos índices, podemos adotar um
percentual de 15%-25% do total da fato, o que daria aproximadamente 1,4
GB. Esses valores deverão ser defidefinidos
nidos de início e, gradativamente, a em-
presa deverá buscar métricas históricas acumuladas ao longo do processo de
desenvolvimento de estruturas dimensionais, através de um processo mais
formal de medições.
 Cálculo final: o valor final seria aproximadamente 8 GB para o projeto todo,
conforme o modelo dimensional definido na Figura 10.2.
Observações importantes:
 O cálculo efetivo do tamanho de cada linha deverá considerar as particula-
ridades de cada SGBD.
 Alguns tipos de campos, dependendo do seu tamanho, poderão ter um over-
head que deverá ser considerado no cálculo.
 Alguns SGBDs usam formas variáveis para armazenar a maioria dos seus
data types, dificultando uma estimativa precisa.
 Considere com cuidado o espaço necessário também para as áreas de tra-
balho (sorts, classificações etc.), que serão demandadas em um ambiente de
DW/DM. Esses espaços serão reclamados no momento de execução de
comandos SQL para classificação e agregação de dados, além das criações de
índices. É claro que, em um primeiro momento, não se tem a ideia precisa
desse espaço, e a grande preocupação deve ser a garantia de sua disponibili-
dade, de forma estimada, no momento requerido.
 Considere também o espaço que poderá ser necessário para a criação dos
agregados, que conterão dados consolidados, em variadas combinações de
dimensão e granularidade, e demandarão área adicional de armazenamento.
Caso você já tenha o esquema de agregados definido, esse cálculo será rea-
lizado da mesma forma que o feito para as tabelas fato e dimensão básicas.

257
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Criação do data base


Os parâmetros para a definição de um data base diferem de acordo com o SGBD
usado, e discutiremos aspectos genéricos, destacando as particularidades para Oracle e
SQL-Server, quando pertinentes.
Os pontos importantes a se considerar são:
 Analisar o valor default da página usada pelo SGBD para o armazenamento
dos dados. Normalmente é de 4.096 bytes. Alguns SGBDs não permitem
outros valores. Lembre-se de que o tamanho da página é fator importante
de desempenho nas varreduras sequenciais de tabelas (table scan) e nos “per-
corrimentos” de índices, processamentos muito comuns em sistemas OLAP.
Quanto maior for o tamanho das páginas, maior será a capacidade de ar-
mazenamento de estruturas recuperadas em uma única operação de input/
output (I/O), com ganhos de desempenho. Por outro lado, páginas grandes
exigem mais caches e áreas de memórias. Observar que existem tecnologias
de SGBD que hoje fazem a operação de I/O com blocos de n páginas, ou
seja, o conjunto de páginas é trazido em uma única operação. Isso poten-
cializa o ganho de desempenho.
 Avalie o overhead de cada página para ter a ideia clara do valor líquido de
bytes de cada uma. As páginas deixam certo percentual do espaço reservado
para estruturas internas de controle e não poderão ser contabilizadas como
área útil de armazenamento.

Criação dos espaços de tabelas


Normalmente, as tabelas e os índices que compõem um banco de dados habitam
um espaço lógico denominado espaço de tabela (Table Space), cuja definição precede a
daqueles componentes. Os espaços serão mapeados em arquivos que poderão ser arma-
zenados em unidades diferentes. Algumas considerações importantes:
 Defina, sempre que possível, dados e índices em espaços físicos separados.
 Considere com cuidado os valores de espaços livres deixados como default
pelo SGBD. Lembre-se de que DW/DM são bancos de dados de natureza
diferente daqueles que atendem a sistemas OLTP e que apresentam alta
volatilidade. Os DW/DM são bancos mais estáticos, com estratégias de atua-
lização diferentes das inclusões e modificações on-line de registros daqueles
sistemas. Assim, espaços livres em blocos de sistemas de BI pouco contri-
buem para melhoria de desempenho, devido à sua natureza de atualizações.
 Avalie a possibilidade de distribuir os dados em várias unidades indepen-
dentes de armazenamento e, se possível, em controladoras de discos diferen-
tes. Isso pode ser feito pela distribuição de um espaço de tabelas em várias
unidades de armazenamento. A tabela, por sua vez, poderá ser dividida
logicamente em segmentos ou partições (com base em range de chaves ou
valores, por exemplo) que poderão ser alocados nesses espaços. Isso permi-
tirá que alguns SGBDs que exploram os conceitos de processamento para-
lelo possam decompor certos comandos e entregá-los a processos internos

258
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

diferentes que serão executados em paralelo, em CPUs diferentes, caso a


máquina possua mais de uma. Esses processos realizarão, por exemplo, bus-
cas independentes e paralelas de dados, que serão consolidados a posteriori
pelo SGBD. Isso certamente melhorará alguns processamentos intensivos
no ambiente OLAP, em que a criação de índices e as varreduras de áreas
extensas são comuns e poderão se beneficiar dessas estratégias. Considere a
possibilidade de usar estratégias de distribuição de dados, através do sistema
de gerência de armazenamento. Muitos fornecedores dessas unidades de
armazenamento (storage system) oferecem a tecnologia RAID, que permite a
distribuição dos dados por unidades diferentes. Basicamente nos ambientes
DW/DM deve-se escolher entre as alternativas RAID, baseando-se sempre
nas características de maior disponibilidade (oferecida pela redundância) e
melhor desempenho de leituras (pela forma de distribuição dos dados).
 Os projetos de DW/DM, dependendo de seus objetivos, poderão produzir
tabelas com alguns bilhões de linhas e de registros de índices, consequen-
temente ocupando grandes volumes. Uma forma confortável de trabalhar
com esses números e volumes agigantados é a adoção da estratégia de parti-
cionamento vertical. Essa técnica possibilita a divisão da tabela em segmen-
tos diferentes, o que permitirá a manipulação independente desses espaços
ou partições. Por exemplo, acessos poderão ser apontados pelo otimizador
para somente aquele segmento/partição. A criação de índices e reorganiza-
ções também poderá ser efetuada numa partição, sem impactos nas outras
partições. Para um bom projeto de particionamento é fundamental a es-
colha de um campo adequado para ser a chave de particionamento. Deverá
ser um campo que divida o total de linhas em segmentos/partições bem dis-
tribuídos. Suponha que no exemplo da Figura 10.2 tivéssemos definido um
conjunto de agregados por mês, para armazenar os fatos daquele modelo. A
definição da tabela fato agregada seria feita, em Oracle, da seguinte forma:
Create Table Fato_agregado_por_mes (
Chave_mês number
Chave_produto number
Chave_cliente number
Chave_item number
Chave_vendedor number
Codigo_Pedido varchar (6)
Qtd_vendida number
Val_desconto number
Val_venda number
Val-frete number
Storage initial 100 MB next 10 MB Pctincrease 0)
Pctfree 0

259
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Nologging
Parallel degree (8)
Partition by range (Chave_mês)
(Partition TFAgreg_Jan values less than (‘199902’)
tablespace TFAgreg_Jan,
Partition TFAgreg_Fev values less than (‘199903’)
tablespace TFAgreg_Fev,
Partition TFAgreg_Mar values less than (‘199904’)
tablespace TFAgreg_Mar,
Partition TFAgreg_Abr values less than (‘199905’)
tablespace TFAgreg_Abr….
etc.
 Uma forma comumente encontrada de particionamento de dados em DW/
DM é através de data. Os dados serão separados fisicamente por essa dimen-
são (ano, mês etc.), conforme o exemplo visto. De maneira geral, somente
as tabelas fato e dimensão muito grandes são candidatas ao particionamento.

Criação das tabelas


A criação das tabelas também obedecerá a particularidades do SGBD. Os cam-
pos, conforme já discutido, serão definidos usando-se os tipos de dados particulares de
cada produto. Algumas observações importantes:
 Atentar para o tamanho limite de linha definido para cada SGBD, tanto para
o número de colunas permitido quanto para o tamanho máximo em bytes.
 Atente para a definição default de valores nulos para campos, evitando a sua
definição (nulo) em campos da tabela fato.
 Lembre-se do conceito de Surrogate Key, ou seja, um campo-chave sem
valor semântico específico. Oferece efi eficiência
ciência na indexação e neutralida-
de semântica. As chaves primárias das tabelas fato e dimensão poderão ser
definidas como SUK (Surrogate Key), porém considere os prós e contras
dessa opção. Alguns SGBDs oferecem tipos de campos com valores gera-
dos sequencialmente na criação da ocorrência do registro. Outros, como
o SQL-Server, permitem a definição do campo normal, porém com essa
propriedade atribuída. Esses valores de chaves serão recuperados/gerados no
momento do acesso/criação do registro dimensão e armazenados lá como
tal. Na tabela fato, serão armazenados como chaves estrangeiras, porém
definidos normalmente, sem a mesma propriedade.

Definição de campos chaves e restrições


A principal definição de restrição é para a chave primária e chaves estrangeiras.
 A definição da restrição de chave primária (unique, not null) forçará a uni-

260
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

cidade da linha (não haverá duplicações), não permitindo valores nulos, e


definirá a criação automática de um índice. Será definida em cada tabela
dimensão.
 A definição da restrição de cada chave estrangeira será feita nos campos-
chave da tabela fato. A tabela fato, na realidade, normalmente tem um cam-
po-chave multicoluna, formado pela concatenação das chaves primárias
de cada dimensão, com a qual a tabela fato se relaciona. Essas restrições
garantirão a integridade referencial entre as tabelas fato e cada uma das
tabelas dimensão. Como os dados de carga de um DW/DM normalmente
são originados dos ambientes transacionais, nos quais já foram submetidos
a certo grau de consistência, é importante uma criteriosa análise sobre o
estabelecimento de restrições de integridade em ambientes OLAP. Na carga
inicial do DW/DM existe sempre a opção de se desligar as constraints a fim
de melhorar o desempenho da carga. Entretanto, para tal há que se ter um
pré-processamento rigoroso que garanta a consistência dos dados. Após a
carga inicial, na fase de carga dos processamentos delta, ou seja, das atuali-
zações que aconteceram desde a última carga, a manutenção das restrições
(constraints) pode ser mantida, pois o volume menor de processamento po-
derá não implicar problemas de desempenho.

Definição de índices e estruturas especiais para acesso aos DW/DM


Alguns aspectos sobre índices são importantes de ser observados. As formas mais
comuns de índices (B-Tree e bitmap) hoje estão acompanhadas de outras formas mais
especializadas (Cluster de índice, Cluster Hash, índices virtuais etc.) e de tratamento para
otimização de estruturas dimensionais, índices de junção e pelo emergente armaze-
namento vertical de colunas. A estratégia de bitmap (mapa de bits) também apresenta
evoluções que discutiremos nas linhas a seguir. Alguns desses conceitos podem ser en-
contrados nos principais SGBDs do mercado, mas nem todos as possuem simultanea-
mente.

Índices BTree
Os índices, estruturas auxiliares fundamentais nos aspectos de desempenho, tam-
bém ganham, com o crescimento da tecnologia de DW/DM, nova roupagem e melhor
utilização. Os tradicionais índices estruturados segundo uma árvore B (B-Tree ou B*Tree)
ainda são uma forma efetiva de montar estruturas com alto desempenho, principalmente
para campos de alta cardinalidade (muitos valores diferentes, como o campo CPF, ou
campo matrícula). Os índices B*Tree apresentam uma estrutura hierarquizadas de nós,
que apontam de forma descendente para os níveis abaixo, até chegar ao último nível da
estrutura (nível de folha), no qual ficam os RIDs (row-ids), endereços diretos das linhas das
tabelas normalmente armazenadas em outros espaços. O RID é o CPF de cada linha da
tabela, e é único no espaço do SGBD que controla o ambiente. A Figura 10.3 mostra uma
página com três linhas armazenadas de uma tabela fato, cada qual com o seu RID. O RID
é formado pelo número da página dentro do espaço mais o número do line-index, ou seja,
um campo no final da página que contém o deslocamento da linha dentro da página. Na

261
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

ilustração da Figura 10.3, o RID, da linha fato P1-L1-D1, identificada pela chave surrogate
1, no caso é formado pelo número 3248 e line-index 1. No line-index 1, existe o desloca-
mento daquela linha, relativamente ao início da página. Dessa forma, o RID torna-se um
apontamento único, com característica indireta, pois permite que o registro se desloque
dentro da página, sem comprometimento de seus apontadores, bastando que o SGBD
altere o seu conteúdo, para que não haja quebra de link.

Figura 10.3
Página padrão de um SGBD.

Agora vamos dar uma olhada no índice. Observe a Figura 10.4. Ela mostra um
índice B*Tree em dois flagrantes diferentes (imagem A e imagem B). Na imagem A, o
índice se mostra com três níveis de profundidade, sendo que o registro raiz (A) aponta
para os nós B e E, que apontam, por sua vez, para o nível de folha (último nível), no
qual os RIDs estão associados às chaves do índice. Nesse nível (folha), existe um par
formado por chave e RID(s). Se a chave for PK (primary key), a proporção entre chave
e RID é 1:1, pois somente existe um registro para cada valor de chave. Se a chave for
SK (chave secundária), a proporção é 1:N, ou seja, podem existir vários RIDs para um
dado valor de chave. Nessa figura estamos trabalhando com a suposição de uma chave
surrogate, com um número sequencial que apontará para a tabela fato da figura anterior.
No nível de folha, ao lado de cada valor de chave, existe um RID representado pela
seta com bolinha na extremidade. Em nosso exemplo, o RID ao lado da chave surrogate
1 (valor 1 no nó C) teria o valor de página = 3248 + line-index = 1, o que levaria di-
retamente à linha fato P1L1D1 do diagrama anterior. A característica fundamental que

262
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

difere a B*Tree de sua ancestral BTree é justamente o fato de que somente no nível
de folha ficam os RIDs. Na estrutura de BTree, os RIDs ficavam espalhados por níveis
intermediários. Na B*Tree encontraremos todas as chaves do índice com o(s) RID(s)
no nível de folha. Na B*tree, nos níveis intermediários do índice, as chaves somente
servem para apontar para sub-ramos descendentes que conduzirão ao nível de folha, no
qual se encontrará a chave procurada e o(s) RID(s) desejado(s). Tanto nos níveis inter-
mediários quanto nos níveis de folha, os diversos nós formam uma lista encadeada, ou
seja, os registros de certo nível são conectados, permitindo tratamento sequencial a par-
tir de certo ponto, além da facilidade de manutenção, quando a alteração de estruturas
acontecer por novas inclusões de valores de chaves. A imagem B mostra exatamente um
flagrante após a inclusão de uma chave com valor 6. Observe que a inclusão da chave 6
levou a um overflow (estouro de espaço no nó F) e à consequente quebra (split) do nó
F (imagem A), dando origem aos nós F e G (imagem B) e rearranjo do nó E. O nó G
(imagem A) é o nó H (imagem B).

Figura 10.4
Exemplo de um índice B*Tree, com nós distribuídos em níveis.

Índices de mapa de bits (bitmap)


A estrutura de bitmap é uma alternativa mais eficiente para a criação de índices
de campos de baixa cardinalidade (poucos valores diferentes, como sexo, por exem-
plo, com M e F somente, códigos de bairros etc.). Enquanto os primeiros (B-Trees e
B*Trees) são baseados em RIDs (endereços de linha, normalmente com 4-5 bytes)
alinhados no nível de folha de sua estrutura, os bitmaps acoplam ali uma fileira de bits,
ou seja, são iguais às B-Trees nos níveis superiores, mas diferentes nas folhas, conforme
a Figura 10.5.Vejamos os seguintes números: suponha uma tabela com 100 milhões de

263
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

linhas. Cada linha tem um RID de 4 bytes. Suponha também que se crie um índice por
código de vendedor. O domínio dessa coluna (código de vendedor) me diz que tenho
40 valores distintos (cardinalidade), ou seja, 40 vendedores diferentes. Linearmente, terei
uma média de 2.500.000 linhas da minha tabela associadas a cada valor de código de
vendedor. Em um índice B*Tree, a estrutura de folha seria algo como uma tabela de 40
valores, tendo ao lado de cada um uma lista 2.500.000 RIDs (valor 1–rid,rid,rid,rid….).
Numa estrutura de bitmap, teríamos acoplado ao lado de cada valor de chave um string
de bits que apontariam (de forma ordinal) para a presença (bit com valor 1) ou ausência
(bit com valor zero) daquele valor nos respectivos registros da tabela-base. O bit 1 indica
aceso ou apagado se o registro de ordem 1 tem aquele valor. O bit 2 indica se o segundo
registro tem aquele valor de chave, e assim sucessivamente. Todos os valores de chave
terão o mesmo número de bits, equivalendo ao número de registros. Como são 100
milhões de registros, teríamos um string de 12,5 megabytes (100.000.000/8) acoplado a
cada valor de chave. Comparando os espaços gastos em cada abordagem, teremos:
Btree: 40 u 2.500.000 u 4 = 400 megabytes.
Bitmap: 40 u 12.500.000 u 1 = 500 megabytes.

Figura 10.5
Índice B*Tree e bitmap.

Por esses números, observa-se que, com base em armazenamento, nesse caso, os
bitmaps são reprovados, embora não esteja aí considerado o alto potencial de compres-

264
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

são de uma fileira extensa de bits. Acontece que, se usarmos a mesma técnica para uma
coluna de menor cardinalidade, por exemplo, com 10 valores distintos, já teremos um
ganho comparativo (125 MB para os bitmaps e 400 MB para os Btree). O ponto de
equilíbrio é de 32 valores (que são os bits equivalentes ao RID de 4 bytes). É importan-
te observar que alguns SGBDs usam mais de 4 bytes para compor os seus RIDs (Oracle
usa 6 e DB2 usa 5 bytes). Apesar de centrarmos a argumentação sobre o espaço, essa
não é a melhor das características dos índices bitmaps. A grande força da abordagem é a
rapidez com que os strings de bits são operados “booleanamente”. Enquanto para tratar
listas de RIDs são necessários algoritmos (tipo balance line), áreas de work etc., o proces-
samento de bitmap chega aos limites das operações elementares de um processador.
Logo, além de ganhos lineares de espaço para cardinalidade cada vez mais baixa, essas es-
truturas agilizam sobremaneira a busca de registros, azeitados por uma álgebra booleana,
quase visceral. Isso sem falar da altíssima capacidade de compressão que os bits oferecem.
Por outro lado, essa estratégia exige bases de dados estáveis (sem atualização) devido à
necessidade de sincronização ordinal de seus registros, com os bits do mapa. Os dois
produtos, citados como exemplo deste livro (Oracle e SQL-Server), oferecem esses dois
tipos de índices diretamente, enquanto o DB2 cria esse tipo de índice dinamicamente.

Uso de mapa de bits para indexação de valores numéricos inteiros


Até aqui mostramos que a grande diferença entre os índices B*Tree e bitmap se
concentrava na forma de apontar os registros indexados. Na B*Tree, o fundamento é o
uso dos RIDs, endereçamento único, formado pela página e pelo line-index associado a
cada linha. Hoje já se pode pensar em misturar as duas alternativas, tentando usar o que
de melhor cada uma oferece. O uso do RID, pelo seu acesso direto, é mais voltado para
campos de alta cardinalidade (muitos valores diferentes, como CPF), e os bitmaps, pelo
poder de sua estrutura binária, com alta capacidade de manipulação booleana. Observe
a Figura 10.6. Nela, existe uma tabela fato, com a tripla de chave P + L + D, com va-
lores de métricas. Do lado esquerdo existe uma estrutura de índice misto conjugando
RID com mapa de bits. A ideia é que possamos indexar valores numéricos de tabelas
fato, como a coluna QTD, uma de suas métricas. O índice misto mostra um mapa de
bits, composto de 8 bits (de 0 a 7), com a configuração binária de cada valor de QTD
e o respectivo RID da linha da tabela fato. Com uma estrutura assim, seria possível pes-
quisar valores numéricos na TFato, buscando valores entre faixas definidas, por exemplo,
QTD vendida entre 32 e 120 unidades. A pesquisa via bitmap permite, pela análise dos
bits, uma busca eficaz nesse sentido. Observe que, pela constituição binária do mapa, se
percebe que os valores da faixa poderão ser procurados pelo bit de maior ordem ace-
so. Para os valores entre 32 e 120, no mínimo o bit 5 ou bit 6 deverá estar aceso. Isso
facilita a pesquisa, podendo reduzir o tempo de acesso. Pelo mapa de bits chega-se aos
RIDs e, daí, se acessa a tabela fato pelo seu conjunto de RIDs selecionados. O uso dessa
mesma estratégia para indexação de valores numéricos reais também pode ser aplicado,
seguindo o mesmo raciocínio.

265
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 10.6
Índice misto usando bitmap e RID – aplicação de bitmap na busca
de valores numéricos inteiros.

Uso de mapa de bits para substituição de valores de chaves nos


índices
Neste exemplo, analisaremos o uso de mapas de bits para substituir valores de
chaves nos índices. Observe a Figura 10.7. Ela mostra um índice B*Tree tradicional
com o uso de RIDs. A estrutura mostra uma tabela com os dados de cliente e bairro.
Cada linha possui o seu RID, ou seja, a sua identificação, que aparece nessa tabela so-
mente para formulação do raciocínio. O RI da linha não se encontra na própria linha
da tabela, mas habita uma estrutura auxiliar (o índice) de apontamento. Do outro lado,
o índice mostrado na mesma figura ilustra a estrutura de folha do índice B*Tree, com
os valores de chaves e os respectivos RIDs associados a cada um. É um exemplo de
chave secundária, em que, para cada valor de chave, eu posso ter vários RIDs. Agora
observe a Figura 10.8. Ela mostra uma tabela de codificação que realiza o mapeamento
entre os valores da chave (bairros) e combinações de mapas de bits. No lugar da folha da
B*Tree tradicional, haverá a substituição do valor de chave pela respectiva combinação
binária. Isso permitirá uma forma mais cômoda de pesquisa dos bairros, através da força
booleana de um mapa de bits. Observe que na tabela de codificação se pode ver que os
bairros que começam com a letra A estão com o bit 2 zerado, enquanto aqueles com
letra B têm o mesmo bit com valor 1. Essa forma de mapeamento, embora facilite a
busca pela análise direta de bits de um mapa, deverá ser analisada para se compor cor-
retamente uma associação entre classificação EBCDIC (campos char) e os bits de maior
ordem do mapa.

266
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Figura 10.7
Índice B*Tree com RID.

Figura 10.8
Aplicação de bitmap na substituição de chaves.

267
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Uso de mapa de bits na indexação de dimensões


Observe a Figura 10.9. Do lado esquerdo é mostrada uma tabela dimensão de
produtos, com hierarquização de categoria, subcategoria e produto. A ideia é usar um
mapa de bits para definir uma associação dos bits com os valores da hierarquia. Ob-
serve que o mapa de bits à direita permite pesquisa sequencial, desde que a função de
mapeamento das hierarquias da dimensão seja devidamente definida, como o bit 2
zerado está relacionado à Categoria=Alimentos e o bit 2 com valor 1 está relacionado
à Categoria=Banho. Além disso, o bit 1 deve ser ajustado para se referir à subcategoria
(valor zero = sabonete e valor 1 = xampu).

Figura 10.9
Aplicação de bitmap na indexação de dimensões.

É natural que o modelo de mapeamento leve em consideração a distribuição


de frequência das relações hierárquicas dentro da dimensão. Por exemplo, saber quantas
subcategorias existem por categoria e quantos produtos por subcategoria. Caso tivés-
semos 20 mil produtos, teríamos necessidade de um mapa de 15 bits, pois 2**14=18384.

Uso de índice de junção entre tabela dimensão em esquema estrela e a


tabela fato
Observe a Figura 10.10. Nesse exemplo é mostrado como se pode criar um ín-
dice que facilita a junção entre a tabela fato e uma tabela dimensão, em esquema estrela.
A tabela fato mostra os três campos-chave (P + L + D), com a métrica quantidade. A
tabela dimensão produto está não normalizada, até como característica do esquema es-
trela (star schema), e mostra os atributos categoria e subcategoria, além da identificação
do produto. No meio, existe uma tabela que faz o mapeamento entre os respectivos
RIDs da tabela dimensão produto e da tabela fato. Essa tabela, criada a priori, facilitará a
realização da junção. Uma variante dessa solução é mostrada na Figura 10.11. Ela ilustra
uma tabela de mapeamento de RIDs, agora com a junção das três dimensões com a
tabela fato. Essa estratégia é mais eficiente para consulta com chave completa (três di-
mensões) ou com a chave mais à esquerda. Isso vale para todas as chaves concatenadas,
comuns nas tabelas de relacionamento, o que é o caso da TFato.
268
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Figura 10.10
Índice para join entre dimensão (esquema estrela) e fato.

Figura 10.11
Índice para join entre as dimensões produto, dia, loja
(esquema estrela) e fato.

Uso de índice para agrupamento (clusterização) multidimensional:


Alguns produtos de bancos de dados oferecem soluções particulares para inde-
xação de tabelas em ambientes OLAP. É o caso do DB2 da IBM, com a possibilidade
de indexações multidimensionais. Observe a Figura 10.12. Nela é mostrado um espaço

269
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

de três dimensões, com ano-mês, produto e região. O espaço tridimensional se mostra


como um cubo, com os valores das dimensões dispostos em cada eixo (lado). Existem
quatro valores representados no eixo de produtos, quatro regiões mostradas no eixo de
região e três valores dispostos no eixo ano-mês. Os números mostrados na superfície
do cubo representam os endereços físicos das linhas da tabela fato, na qual aqueles va-
lores que se interceptam estão presentes. Por exemplo, na interseção entre a dimensão
região (valor Região Norte), com a dimensão produto (valor Coca-Cola) aparecem
os endereços físicos 12 e 15. Na interseção entre região (valor Região Nordeste), com
produto (valor Pepsi-Cola) e ano-mês (valor 2009-11) aparecem os endereços 65 e 78.
Esses endereços, diferentemente das estruturas tradicionais que usam Row-id (identi-
ficação de linhas), são Block-IDs (BID), identificadores de blocos. Os blocos são con-
juntos de páginas, passíveis de ser recuperadas via única operação de I/O, ou seja, com
a evolução dos sistemas operacionais e de armazenamento, aliada ao crescimento dos
caches de memórias, os SGBDs mais evoluídos passaram a recuperar blocos (conjunto
de páginas), otimizando as operações de I/O. Esses blocos representam um conjunto de
páginas nas quais aqueles valores específicos de chaves combinadas na tabela fato estão
armazenados. A Figura 10.13 ilustra o conceito, mostrando que os registros com chaves
Nordeste, Pepsi-Cola e 2009-11 estão distribuídos nos blocos 65 e 78, conforme visto
na figura anterior. Cada bloco desses é formado de n páginas pelas quais se distribuem
as linhas da tabela fato com aqueles valores de chaves.

Figura 10.12
Índice multidimensional.

270
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Figura 10.13
Exemplo de uso de índice multidimensional.

As Figuras 10.14, 10.15 e 10.16 mostram, respectivamente, os valores dos en-


dereços físicos, vistos em cada uma das “fatias” (slices), que são os índices (listas) que
podem ser processados por operadores booleanos. Por exemplo, um operador AND,
entre duas listas contendo chaves e BIDs, produz uma lista resultante cujos BIDs serão
pesquisados (varridos) para a busca das linhas que contêm aqueles valores de chaves.
Como os BIDs são identificadores de blocos, a leitura física otimizada trará, para cada
bloco, um conjunto de páginas nas quais as linhas serão encontradas. O DB2 tam-
bém permite a criação de índices combinando valores de duas ou mais dimensões,
de forma a otimizar o processamento das listas obtidas em cada fatia. Por exemplo,
poderia ser criado um índice composto (duas dimensões) por produto e região, ou
por produto e ano-mês, ou por região e ano-mês, ou um índice composto (três di-
mensões) por produto, região e ano-mês.

271
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 10.14
Exemplo de uso de BID (Block-id)-I

Figura 10.15
Exemplo de uso de BID (Block-id)-II.

272
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Figura 10.16
Exemplo de uso de BID (Block-id)-III.

A inserção de novas linhas acontece nas páginas daquela célula em particular


e, quando as páginas ou o bloco estiverem cheios, um novo bloco será alocado para
acolher as inserções.
Com a queda nos custos de armazenamento de disco, observa-se que existe uma
tendência de criação de indexações que previamente facilitem a resolução das consultas,
priorizando-se sempre o tempo de resposta das queries, mesmo que com aumento de
consumo de armazenamento.

Uso de índices especiais criados a partir de consultas


Com a aquisição da Informix pela IBM, a Big Blue incorporou um excelente
engine de bancos relacionais existente na Informix, o Extende Parallel Server. Hoje, a
IBM disponibiliza o DB2 Informix Extended Parallel Server, que oferece algumas for-
mas interessantes de indexações, chamadas de GK (Generalized Keys), conforme descrito
a seguir.

273
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Índices virtuais
Veja a Figura 10.17. Ela mostra um comando Create GK (de índice Generalized
Key) sobre uma Tabela TFato, expresso por um comando Select. Essa é a tônica desses
índices especiais. Eles podem ser criados pela expressão de um comando Select, e o
resultado desse comando se transforma em índice. Para tal o engine coloca o row-id da
linha selecionada e aplica um order by, dando ordenação ao resultado, de forma transpa-
rente e sem aparecer no comando Select. Assim, o resultado da consulta se transforma
em índice que poderá ser usado a posteriori diretamente em outra pesquisa. Voltemos à
Figura 10.17. Ela mostra uma tabela TFato de vendas e o comando de criação de índice
virtual, que cria um índice mostrando a multiplicação da métrica quantidade pela valor-
unitário. No fundo, o índice foi criado em cima de um valor obtido dinamicamente
e, quando forem efetuadas consultas sobre esse campo calculado, o índice poderá ser
usado, com ganhos de desempenho, como no caso da Figura 10.18, que mostra um sub-
conjunto do anteriormente recuperado. No caso da Figura 10.18, a busca é pelo campo
calculado contendo valores maiores que 100. O uso de chaves surrogates no exemplo não
modifica a essência do conceito.

Figura 10.17
Índices especiais baseados no resultado de uma consulta – I.

274
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Figura 10.18
Conceito de índices virtuais.

Veja a Figura 10.19. Ela mostra um exemplo semelhante aos anteriores, porém
contempla uma junção entre a tabela fato e a tabela dimensão, além de um filtro aplica-
do na dimensão, de forma a buscar somente registros da fato que tenham data maior que
D1. A ideia é a mesma: o índice é criado pela expressão de um comando Select que faz
um join da TFato com a TDim Data, e o filtro é aplicado na tabela TDim. Observe que o
índice resultante poderá ser usado na junção entre a TFato e a TDim. Caso retirássemos
a cláusula where, obteríamos o equivalente a um índice de “junção” pronto entre as
duas tabelas. A Figura 10.20 ilustra um exemplo em que se cria um índice nessas mes-
mas circunstâncias, só que fazendo a junção entre três tabelas (a TFato, a TDim produto
e a TDim data, esta presente na figura anterior). A pesquisa que criou o índice lista o
total de vendas (QTD * Preço-Unitário) dos produtos da TFato vendidos na data D1.
O importante é perceber que esses índices criados a partir de expressões de comandos
SQL permitem definir estruturas semiprontas de acesso que poderão ser usadas pelos
otimizadores de buscas relacionais/dimensionais em casos de outras pesquisas cujos re-
sultados estejam contidos no originado por esse comando. Alguns SGBDs possuem na
sua forma de otimização a busca por estruturas prontas que possam atender às consultas,
sem a necessidade de repetir todo o algoritmo oneroso percorrido quando da produção
da estrutura inicial.

275
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 10.19
Índices especiais baseados no resultado de uma consulta – II.

Figura 10.20
Exemplo de índices de junção.

276
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Opções de cluster
O conceito de cluster da Oracle objetiva oferecer um mecanismo que permita
melhor definir a colocação física das linhas de uma tabela, dando ao projetista a opção
de interferir nesse posicionamento. O cluster cria um espaço lógico, no qual linhas
de uma ou mais tabelas poderão habitar as mesmas vizinhanças físicas (mesmo bloco),
desde que tenham uma chave em comum, definida para ser a chave do cluster. Para ge-
renciar essa colocação de registros vizinhos próximos, o Oracle oferece duas alternativas:
uma delas através de um índice denominado índice cluster e outra através de hashing
(randomização), denominada hash cluster.

Índice cluster
A opção de índice cluster poderá ser usada em armazenamentos de tabelas fato
de DW, numa aplicação do conceito de cluster de uma só tabela. Oferece a vantagem
de criar indexações nas quais a chave escolhida como do índice cluster será armazenada
somente uma vez, com as linhas da tabela apontando para ela. Isso significa que, se o
tamanho da chave escolhida for maior do que o pointer usado, haverá ganho significativo
de espaço, com um número menor de linhas sendo varridas, quando objeto de uma
consulta. Outro uso associado dessa estratégia em DW seria promover uma desnor-
malização da tabela fato, agregando a ela vários atributos de dimensão. Esses atributos
seriam motivo do índice cluster, com as economias consequentes de espaço e a pos-
sibilidade de resolver algumas consultas, sem a necessidade de junção. Essa opção deverá
ser cuidadosamente analisada nos seus contras, visto que existem certas limitações dos
índices cluster, como a necessidade de perfeita noção do dimensionamento de espaço
requerido e outras parametrizações impostas pela sua definição física e, portanto, com-
pulsórias para todas as tabelas ali residentes.

Índice hash
A opção de hash cluster permite a definição de um tipo especial de acesso, cuja
principal característica é o cálculo aplicado sobre a chave escolhida, que define a locali-
zação do registro desejado. Embora seja uma forma de cluster, cada linha mantém a sua
chave armazenada, diferentemente do índice cluster. Há desvantagens de obrigar à defi-defi-
nição rigorosa do espaço de endereçamento antes da carga dos registros, com o objetivo
de evitar as colisões de chaves (chaves diferentes que randomizam no mesmo lugar) e
a criação de áreas de overflow para armazenamento, quando da escassez de espaço. O
seu uso em projetos de DW/DM deverá ser cuidadosamente analisado, principalmente
quando se preveem processamentos intensos baseados em busca por faixas de valores.
A Figura 10.21 ilustra o conceito de hashing, em que determinado valor de chave é
submetido a uma função que produzirá um endereço relativo em espaço predefinido.
Os valores diferentes de chaves que colidirem (resultarem no mesmo endereço, devido
à função matemática) serão colocados numa área de overflow. Uma função comumente
aplicada nos cálculos de endereço é a de (valor da chave {módulo} espaço), ou seja, o
resto da divisão inteira do valor da chave pelo espaço predefinido. Exemplo:

277
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Chave de 1 a 100 para alocar em 50 espaços (blocos de 1 registro, enumerados


de zero a n - 1)
O endereço da página será obtido pelo resto da divisão inteira de chave/50.
Analisando-se a aplicação do algoritmo de randomização nas chaves, observa-
mos:
Chave 1: divide-se 1/50, dando zero com resto 1. Dessa forma, o registro com
chave 1 vai para a página 1.
Chave 2: divide-se 2/50, dando zero com resto 2. Dessa forma, o registro com
chave 2 vai para a página 2.
Chave 50: divide-se 50/50, dando 1 com resto zero. Dessa forma, o registro com
chave 50 vai para a página zero.

Figura 10.21
Exemplo de randomização.

Observa-se que, a partir da chave com valor 51, os registros irão para um espaço
de páginas de overflow.
Se dividirmos 51/50, obteremos 1, com resto um. Isso significa que o registro 51
colide com o registro 1. Como o espaço originalmente definido é somente para cada
registro um endereço de randomização, a chave 51 deverá ser deslocada para a área de
overflow.

Estratégia para otimização de manipulação do esquema estrela (star


schema)
O algoritmo de otimização de esquema estrela, de maneira geral, se baseia na
realização de operação de produtos cartesianos entre todas as dimensões. Embora isso
possa parecer algo inconcebível, visto que o produto cartesiano das dimensões pode
levar a uma explosão combinatória como resultado, os testes indicam que, mesmo assim,
oferece melhor desempenho do que a realização de joins individuais entre cada dimen-
são e a tabela fato.
A Oracle desenvolveu uma estratégia de tratamento de esquema estrela (star
schema), baseada na definição de bitmaps. Basicamente, o algoritmo é composto dos
seguintes passos, quando da realização de um comando SQL de manipulação:

278
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

 Usa os critérios da cláusula where para selecionar os registros dimensão.


 Com esses registros, faz um batimento altamente eficiente, via os bitmaps
definidos na TFato, para recuperar os registros fatos que se relacionam com
os previamente selecionados.
 Depois dessa recuperação, volta a fazer uma junção com as dimensões para
complementar as informações. Nesse caso, poderá usar outros métodos de
junção.
A Figura 10.22 ilustra o conceito de otimização de esquema estrela.

Figura 10.22
Conceito de otimização de esquema estrela.

Resumo sobre os índices:


 Defina chave primária para cada tabela dimensão. Isso criará um índice au-
tomático que deverá ser preferencialmente “clusterizado”. Analise sempre a
possibilidade de usar uma chave surrogate (SUK) como chave da dimensão, a
fim de dar neutralidade semântica a esses campos.

279
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 Considere a definição de restrição de chave estrangeira (FK) da fato


com a chave primária (PK) de cada dimensão. Se o uso for de esquema
snowflake, defina também as restrições de PK e FK para as tabelas da
dimensão (suas descendentes). Lembre-se de que os dados poderão já
vir consistidos do ambiente OLTP e, portanto, essas restrições de inte-
gridade poderão não somar muito no ambiente OLAP, além de impor
certos níveis de overhead.
 Defina uma chave primária para a tabela fato, incluindo todas as chaves
estrangeiras de cada dimensão. Isso criará um índice automático que deverá
ser UNIQUE e não “clusterizado”, devido às múltiplas formas de acesso de
uma tabela fato.
 Defina índices separados para cada chave estrangeira na tabela fato.
 Lembre-se de que os índices poderão ser particionados também, da mesma
forma que as tabelas de dados (fato ou dimensão).
 Lembre-se de que os índices bitmap são muito bons para colunas com baixa
cardinalidade, ou seja, poucos valores diferentes no domínio da coluna. Os
índices B-Tree servem para os outros propósitos, principalmente para colu-
nas de alta cardinalidade.
 Lembre-se de que o conceito de índice “clusterizado” (clustered index), ofe-
recido por todos os SGBDs, é diferente do conceito de cluster de índice,
oferecido pela Oracle. O índice “clusterizado” tem as chaves nos seus níveis
de folha, em ordem sequencial, coerente com a classificação do dado na
tabela indexada. Além disso, o SGBD procura, sempre que possível, manter
essa coerência nas inserções futuras.
 Use os índices “clusterizados” para colunas que necessitam de acesso por
range de valores ou por ordem classificada. É recomendado para tabelas di-
mensão.
 Por fim, lembre-se de que existem hoje diversas formas otimizadas de in-
dexações, como índices virtuais, índices multidimensionais, índices especiais
de junção, dependentes de cada tecnologia (SGBD) utilizada. Analise sem-
pre o arsenal oferecido pelo SGBD a ser usado nos projetos de DW e DM,
e considere as opções.
A Figura 10.23 ilustra os principais conceitos discutidos.

280
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Figura 10.23
Índices em modelos dimensionais.

Considerações sobre cargas de tabelas


Definido o projeto físico do DW/DM, chega-se ao momento de pensar nas
formas de carga inicial e atualização desses bancos de dados que certamente atingirão
volumes extensos de armazenamento, com alto tempo de processamento e que, conse-
quentemente, demandarão procedimentos operacionais cuidadosos. Algumas observações
importantes:
 Planeje cuidadosamente a carga dos DW/DM, analisando as estratégias de
mapeamento entre os dados fonte/staging e o DW/DM.
 Considere sempre a possibilidade de usar utilitários de carga oferecidos pelos
SGBD. São programas normalmente otimizados para essa finalidade. Lembre-
se de verificar se esses utilitários registram logs de alterações e analise a pos-
sibilidade de desligá-las, evitando desperdícios no processamento. Normal-
mente, as cargas são reiniciadas, caso qualquer problema aconteça, e as logs se
mostrarão inúteis.
 Lembre-se de que, atingindo certo volume de dados, fica impraticável a carga
total da tabela como processo de manutenção do DW/DM. Isso sugere que a
instalação esteja pronta para a difícil tarefa de atualizações incrementais, quan-
do essa necessidade se configurar. Existem várias ferramentas, mas a base é a

281
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

busca das informações que se alteraram desde o último ciclo para produzir as
atualizações que irão para o DW/DM.Vasculhadores de arquivos logs, arqui-
vos de log de aplicações disparados por triggers etc. podem ser definidos para
automatizar essa captura.
 Considere a possibilidade, já discutida anteriormente, de paralelizar os proces-
sos de manutenção do DW/DM. Um projeto de DW/DM segmentado nas
suas tabelas de dados e índices permitirá ganhos significativos na sua carga,
criação e uso de utilitários.
 Considere a possibilidade de eliminar (drop) os índices antes de efetuar as car-
gas de tabelas e recriá-los posteriormente. Quando a carga das linhas for maior
do que 15% do tamanho da tabela, considere fortemente essa possibilidade.
 Atente para a execução das atualizações de estatísticas após a carga dos bancos
de dados de tal forma que o otimizador possa utilizá-las definindo correta-
mente os melhores caminhos de acessos.

Aspectos gerais de desempenho


Com a consolidação dos conceitos de data warehouse e data marts como soluções
consistentes para o tratamento de informações negociais na empresa, sobra agora, para
os seus analistas e projetistas, a árdua tarefa de domar aquela que certamente será a fera
assustadora a rondar esses verdadeiros gigantes de informação: o desempenho. Pode-se
facilmente imaginar, e os indicadores são bastante concretos apontando para o fato de que
esses depósitos de informações poderão ultrapassar barreiras de armazenamento, provavel-
mente nunca antes atingidas. Os números de bytes de um DW/DM hoje roçam a casa de
alguns petabytes e já apontam para as primeiras unidades de zettabytes para dentro de al-
guns anos. Alguns DW hoje são maiores (em bytes) do que a própria capacidade instalada
de muitas empresas grandes. É claro que, em paralelo com esse crescimento vertiginoso de
estoque de bytes, também a indústria da informática se apressa em produzir soluções que
permitirão uma suave convivência entre a fera e seus domadores. Por ora, discutiremos
algumas nesse contexto.

Estabelecimento de padrões de desempenho


Esse é um aspecto fundamental no sucesso de qualquer projeto dessa natureza. Os
altos volumes de dados definidos pela necessidade de granularidades finas que permitam a
captura dos indicadores de negócios, aliados às possibilidades variadas de combinações de
dimensões, sugerem problemas potenciais de desempenho. É claro que, gradativamente,
esses problemas serão neutralizados pelas melhorias na otimização dos engines SQL, pelo
crescente poder de paralelismo das máquinas de classes robustas e pelas inovações de
técnicas de indexação (bit wise e join índices, processamento em cache, rotinas de SGBD
voltadas para otimizar BI etc., além da presença de estruturas proprietárias otimizadas para
armazenamento. Tudo isso num campo em que as dificuldades estão sendo transpostas
sem grandes experiências acumuladas anteriormente, até porque foram as transações de
estilo OLTP que pautaram os benchmarks oficiais de desempenho. Para preencher essa
lacuna, o TPC (Transaction Processing Council), conselho formado por várias empresas
(IBM, AMD, Microsoft, Dell etc.), com o objetivo de padronizar medidas de desempenho

282
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

para sistemas de tomada de decisão, definiu o TPC-H. O TPC-H é uma espécie de receita
que deve ser seguida por quem deseja medir relações de custo e desempenho para transa-
ções que envolvam acessos complexos a sistemas de bancos de dados com consultas ad hoc.

À Mais detalhes poderão ser obtidos no site www.tpc.org. O antigo padrão TPC-D,
voltado para sistemas de data warehouse, não é mais oferecido.

Estratégias de armazenamento
A estratégia de armazenamento do DW/DM, ou de seus cubos extraídos, permite
as seguintes opções, conforme ilustrado na Figura 10.24:

Figura 10.24
Exemplo de estruturações: Rolap, Molap, Holap e Dolap.

 ROLAP: estratégia pela qual são usados os próprios sistemas de gerência de


bancos de dados relacionais, com as tabelas sendo implementadas como estru-
turas relacionais clássicas. Oferece todas as vantagens de um SGBDR, porém
exige um projeto cuidadoso do ponto de vista de desempenho, em que o
excesso de tabelas normalizadas poderá comprometer a performance das bus-
cas. É importante lembrar dos conceitos de esquema estrela e flocos de neve,
discutidos anteriormente. As tabelas básicas e os agregados (visões ou cubos)
são armazenados nesse formato. O modelo relacional poderá ser usado tanto
para desenhar o projeto físico do data warehouse, considerando a abordagem
top-down, em que o DW será construído primeiramente, a partir dos arquivos
fontes, quanto na abordagem de data marts integrados, em que os data marts,
na forma rolap, embora com modelagem dimensional (estrela, por exemplo),
se utilizarão das estruturas relacionais para essa composição.

283
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

 MOLAP: estratégia pela qual são usados gerenciadores de bancos de dados


proprietários, com características de armazenamentos especiais e ferramen-
tas para tratamento dimensional de dados. Embora disponha de proprieda-
des especiais de armazenamento como matrizes esparsas, operações com
array e indexações de bitmap, não oferece toda a gama de recursos (debug,
paralelismo, log, otimizadores, monitoração etc.) encontrada num SGBDR
de última geração, visto a sua estrita especialidade para análise multidimen-
sional. Exige a migração dos dados do SGBR relacional para o armazena-
mento multidimensional e a sua constante atualização. Pode ser limitada na
sua capacidade máxima de armazenamento, mas por ser voltada exclusiva-
mente para essas aplicações pode apresentar, em tese, melhor desempenho
do que as alternativas. Pode ser entendida como uma planilha multidimen-
sional, e algumas oferecem a opção RAM-MD, permitindo a manipulação
dos dados diretamente em memória. No caso de MOLAP, tanto as estrutu-
ras básicas (maior granularidade) quanto as estruturas agregadas/cubos são
armazenadas nesse formato.
 HOLAP: representa uma abordagem de uso misto das duas estratégias an-
teriores, em que as estruturas relacionais são normalmente utilizadas para
os dados de maior granularidade e as estruturas dimensionais nativas são
dedicadas ao armazenamento de agregados (menor granularidade).
 DOLAP: representa uma abordagem na qual estruturas dimensionais ou re-
lacionais, transferidas do DW/DM para as estações clientes, são armazenadas
com o objetivo de facilitar o desempenho de certas análises, minimizando
o tráfego de informações entre o ambiente cliente e o ambiente servidor.

Solução de armazenamento
Os principais pontos a serem considerados na escolha de uma solução de arma-
zenamento para ambientes críticos de BI são:
Tecnologia RAID. Capacidade de armazenamento com suporte às diversas
tecnologias RAID (Redundant Array of Independent Disks). Os conceitos RAID se ba-
seiam na redundância dos bytes de informações e na sua distribuição, de tal forma a
prover maior segurança e desempenho de acesso. As principais classificações
classificações da tecno-
logia RAID são:
RAID 0: os dados são distribuídos em segmentos (stripes) por discos diferentes
sem nenhum mecanismo de replicação de dados que permita a sua recuperação em
casos de perdas. Oferecem excelente desempenho pela possibilidade de acessos parale-
lizados, entretanto sem características de tolerância a falhas.
RAID 1: os dados são distribuídos em espelhos (duplicações) em discos diferen-
tes, permitindo, dessa forma, uma completa estratégia de tolerância a falhas. Os dados
replicados serão atualizados diretamente pelo próprio sistema de disco, com pequeno
overhead imposto, mas garantirão disponibilidade imediata em caso de perdas nos discos
originais. Oferecem maior capacidade de disponibilidade, porém com custo mais ele-
vado, quando comparados com a anterior. O desempenho de leitura é melhorado, pois

284
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

os discos podem ser lidos simultaneamente, mas o desempenho de atualização é afetado


pela duplicidade de atualizações físicas.
RAID 3: os dados são distribuídos em segmentos, ficando o controle de pari-
dade localizado em disco separado. A distribuição dos dados garante também melhor
desempenho no acesso, pelo paralelismo de controladoras, e o mecanismo de paridade
permite recuperações de informações perdidas em certo nível, garantindo tolerância a
falhas. Nesse caso, todas as informações de paridade necessárias ao processo de recupe-
ração estão no mesmo disco.
RAID 5: os dados são distribuídos em bytes (não mais segmentos) com paridade
também distribuída em discos separados e oferecendo, dessa forma, alto grau de tolerân-
cia a falhas. Oferece, por suas características, excelente relação custo-benefício, sendo
uma das modalidades mais comercializadas.
A Figura 10.25 mostra esquematicamente os principais tipos de RAID.

Figura 10.25
Armazenamento RAID.

Arquitetura de servidores
O crescimento exponencial de volumes de dados armazenados em data warehou-
ses, associado ao grande número de usuários, tem definido certas condicionantes para as
máquinas que deverão servir de hospedeiras para esses tipos de sistemas. Os sistemas com
muitos terabytes de armazenamento, com alta taxa de transações de suporte a decisão, cada
vez mais requerem opções com ótima relação preço/desempenho. Pelas suas características,
esses sistemas tendem a requerer, cada vez mais, opções de processamento paralelo maciço
ou máquinas simétricas com vários processadores (clusters). Essas duas opções arquiteturais

285
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

têm apresentado evolução e estão numa zona cinzenta, levando os seus potenciais clientes
a uma necessidade de tomada criteriosa de decisão, baseada em fatores discutidos a seguir.
As principais opções arquitetônicas para máquinas servidoras são:
Shared everything. A arquitetura shared everything (compartilha tudo) significa
que os vários processadores de um box se utilizarão democraticamente dos espaços de
memória e do sistema de I/O da máquina, que serão únicos para todos. Um SGBD
nesse ambiente despachará suas tarefas na forma de processos que serão encaminhados aos
diferentes processadores.Tudo isso de uma maneira balanceada, dependendo da disponibi-
lidade de cada um. A desvantagem básica fica pelos aspectos de “escalabilidade” limitada,
ou seja, não adiantará aumentar o número desses processadores, pois a parte compartilhada
da arquitetura (buses de comunicação e o sistema de I/O) poderá se transformar em fator
de gargalo. Passar de oito processadores para 16 poderá não significar ganhos lineares de
desempenho, dependendo da opção adotada. As máquinas que utilizam essa arquitetura
são genericamente chamadas SMP (Symmetrical Multi Processors), em que o simétrico signi-
fica a inexistência de processadores especiais, ou seja, todos são devotados ao mesmo tipo
de trabalho. A opção assimétrica seria a existência de processadores dedicados a trabalhos
especiais; por exemplo, totalmente dedicados às operações de entrada e saída. Por essa ca-
racterística de alta ligação entre os componentes (processadores, memória e I/O), eles são
também conhecidos por tightly coupled (fortemente acoplados). A evolução dessa arqui-
tetura se dá pelo maior desempenho obtido por memórias de maior endereçamento (64
bits), processadores mais rápidos e mecanismos de comunicação interna de maior rapidez.
A Figura 10.26 ilustra o conceito da arquitetura SMP.

Figura 10.26
Arquitetura SMPs.
286
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Shared disk. Esta arquitetura se caracteriza pelo compartilhamento do sistema


de I/O, ou, especificamente, pelos discos do ambiente. Os processadores possuem espa-
ços independentes de memória e, portanto, cópias próprias de softwares (sistema opera-
cional e SGBD), e compartilham os dados existentes em pools de discos comuns a todos.
Nessa arquitetura aparecem os chamados clusters. É, simplificadamente, um conjunto de
“boxes independentes” (cada qual com sua memória, seu software e seus buffers), com
acesso a discos comuns. Nesse caso, como os buffers são independentes, há que se ter um
mecanismo de sincronismo fortemente estabelecido para permitir que os SGBDs, cada
qual em seu espaço, possam compartilhar com integridade e segurança os dados que
habitam os discos de acesso comum. A Figura 10.27 ilustra o conceito da arquitetura de
clusters, ou shared disks.

Figura 10.27
Arquitetura de clusters (shared disks).

Shared nothing. Esta arquitetura, como o próprio nome explica, se baseia em


boxes com maior independência de componentes (cada qual com sua memória, seus
buffers, software e sistemas de I/O), de maneira a prover alto desacoplamento entre eles
e, consequentemente, maior “escalabilidade”. É claro que o ambiente é conectado, por
debaixo dos panos, de forma a permitir que as partes, fracamente interligadas (loosely
coupled, como chamadas), sejam “vistas” como um todo. É uma abordagem escolhida
para aplicações especiais e apresenta maior complexidade relativa, tanto operacional

287
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

quanto tecnológica. Os sistemas nessa arquitetura são chamados MPP (Massive Parallel
Processors), e os SGBDs têm de ser muito mais elaborados para extrair todo o potencial
de paralelismo da arquitetura. Nessa abordagem, as tabelas de dados são particionadas
em sistemas diferentes e exigem, por consequência, mais cuidados, tanto por parte dos
analistas de suporte/DBA quanto do próprio SGBD, que deverá ter formas (catálogo
central, por exemplo) de identificar a localização das diferentes partições de dados. A
Figura 10.28 ilustra o conceito da arquitetura MPP, ou shared nothing.

Figura 10.28
Arquitetura Massive Parallel Processing – MPP
(shared nothing).

É importante entender que a classificação das arquiteturas, como definida aqui,


está cada vez mais sendo obscurecida por processos de hibridização entre os seus tipos
básicos. Por exemplo, uma tendência forte parece ser a fusão dos conceitos de SMP e
MPP, em que teríamos a arquitetura MPP (shared nothing) como base, mas em cada box
teríamos um conjunto SMP de processadores (em vez de um único processador, como
na proposta original). A estratégia de clusters, pelo seu lado, também se funde com o
conceito SMP, podendo ter clusters SMP, nos quais cada box conteria vários proces-
sadores dessa natureza, com a manutenção do conceito de shared disks. A arquitetura
NUMA (Non Uniform Memory Access) é outra proposta variante das anteriores, na qual
as memórias separadas de cada nó podem ser consideradas “logicamente” somadas para
compartilhamento entre eles.

288
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

Considerações sobre as arquiteturas MPP e SMP em sistemas de data


warehouse
As soluções MPP tendem a ter melhor posicionamento nos benchmarks quan-
do se considera a “escalabilidade” de processadores. Para DW com volumes acima
de 2 a 5 terabytes e alto processamento, como carga ou pesquisa de tabelas fato com
muitos milhões/bilhões de linhas ou criação de índices de muitos milhões/bilhões
de chaves, as arquiteturas MPP se mostram como as melhores opções e oferecem
o melhor throughput. Como contraponto, essas soluções tendem a mostrar uma re-
lação preço/desempenho maior (mais cara) que as arquiteturas SMP e os clusters,
com ênfase também em maior custo de manutenção, devido à maior complexidade
operacional. Nessa arquitetura, o desafio técnico é o alcance de um perfeito parti-
cionamento dos dados (tabelas fato, normalmente), distribuídos entre as inúmeras
unidades processadoras, cada qual com o seu pool de memória e discos. O particio-
namento se dá por métodos hashing aplicados sobre a chave de particionamento dos
dados. Os SGBDs a serem utilizados no projeto devem permitir com facilidade a
implementação de particionamento de tabelas. A Figura 10.29 ilustra uma forma de
particionamento de tabelas fato por dimensão data. O particionamento de grandes
tabelas em espaços físicos diferentes permite não somente a facilidade de uso por
máquinas com paralelismo, como também implica melhorias operacionais signifi-
cativas, facilitando os trabalhos de reestruturação de tabelas, criação de índices, pes-
quisa sequencial paralelizada, reorganização independente e otimizado de espaços,
recuperação (recovery) de espaços com maior rapidez e monitoração mais efetiva.
Veja a proposta de MapReduce adiante.

Figura 10.29
Exemplo de tabela fato particionada por data.

289
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

As soluções SMP tendem a ter maior limitação na “escalabilidade”, na medida


em que o aumento do número de processadores implica aumento de contenção nos re-
cursos comuns da arquitetura, como memória e disco. Como aspecto positivo possuem
uma relação preço/desempenho mais favorável, mas devem ser analisadas com cuidado
para sistemas de DW com volumes maiores do que 5 TBytes. Também oferecem am-
biente operacional mais simples, se comparado com o ambiente MPP.
As arquiteturas SMP e MPP evoluirão para cenários em que teremos a força da
miniaturização atuando no encolhimento das máquinas. Assim, a tendência será a cria-
ção de pequenos boxes, com chips multi-core. Os chips estão ganhando novas formas,
com dois processadores (dual-core), quatro processadores (quad-core), e a tendência
é que, em pouco tempo, tenhamos 256 a 512 processadores num único chip. Com o
aumento das memórias, também em franco desenvolvimento, num futuro próximo
teremos pequenas unidades em tamanho reduzido (boxes), com altíssima capacidade
de processamento in-memory e muitos petahertz de processamento. Assim, poderemos
testemunhar o BI2 fazendo análises preditivas em tempo real sobre grandes volumes
de dados (Big Data), com a rapidez de um coelho de desenho animado.
Hoje, o conceito novo de data warehouse appliance se baseia no oferecimento
de uma solução completa de hardware, software, serviços etc., e tem sido foco de gran-
des fornecedores de soluções, como DB2, Teradata, HP e Oracle/Sun. A ideia é ofere-
cer algo já pré-instalado e pré-otimizado para o ambiente de DW, atendendo a volumes
de dados entre médio e alto. Muitas dessas soluções de appliance usam arquitetura MPP
visando ao melhor desempenho e escalabilidade.

Tendências tecnológicas para processamento de altos volumes


(Big Data)
Uma pergunta recorrente que aparece é se estamos com tecnologia capaz de
enfrentar esses gigantescos depósitos de informações, buscando cada vez mais rapida-
mente um volume maciço de informações. A resposta vem por conta das evoluções
tecnológicas que normalmente acompanham os movimentos e tendências da sociedade
e da indústria. E ela é: sim, temos arsenal para esse enfrentamento. A começar pelos
tradicionais fornecedores de soluções de BI, IBM, Oracle e Microsoft, a resposta é sim.
Os grandes fornecedores de máquinas estão atualizando as suas plataformas de software
visando à capacitação para grandes consultas em peta/zetta volumes.
Por exemplo, o IBM Smart Analytics System, usado numa operadora inglesa de
telefonia móvel, a Hutchison, trabalha com arquivos de 33 TB e com perspectiva de
mudança para 60 TB em um ano. Além disso, com a aquisição da Cognos, Netezza e
SPSS, este um pacote especializado em aplicações estatísticas, a Big Blue se considera
pronta para o “zettawar”. O SPSS, segundo a IBM, permite a utilização de processa-
mento in-database. Esse tipo de processamento busca aproximar os SGBDs dos dados, na
medida em que oferecem recursos extras, como funções especializadas para tratamentos
analíticos, já dentro do kernel do SGBD, evitando transferências de dados para outros
ambientes a fim de se submeter a um processamento analítico. É algo como um engine
SQL dotado de funções e otimizações de acessos às estruturas específicas dos ambientes
de BI, como modelos dimensionais, por exemplo.

290
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

A Oracle oferece a sua contrapartida, que é o Oracle Exadata V2. O produto,


além de nome oportuno que remete aos exabytes, escala seguinte aos petabytes e
anterior aos zettabytes, se junta aos produtos da Sun-Oracle, procurando, além de
otimizações no kernel do SGBD, também melhorias no campo do processamento
in-memory. Para tal, oferece arrays de memórias flash gigantescas, nas quais se alojam
os dados de um grande depósito informacional, acessados, a partir delas, com veloci-
dade eletrônica. Além disso, com a boa vizinhança da Sun, agora parte da família, há
o inevitável encontro com máquinas MPP, contendo centenas ou milhares de “nós”,
cada qual com sua capacidade de processamento e de armazenamento, focando o
processamento maciço paralelo.
A Microsoft também oferece sua sugestão para o tratamento dos grandes depósi-
tos de informação, com o logotipo Windows. O seu produto é o Microsoft SQL Server
Parallel Data Warehouse, também focado em máquinas MPP.
Além desses três conhecidos, há também a Teradata, empresa que há tempos
se especializou em domar esses mamutes de dados. A Teradata oferece, através de sua
linha especial de produtos para grandes DW, todo esse arsenal de máquinas MPP,
processamento in-database e in-memory, experimentado em enormes DW de grandes
clientes.

Hadoop-MapReduce
A novidade, na realidade, aparece através do surgimento de empresas menores,
porém com muito foco para o tratamento analítico de grandes volumes de dados. Ori-
undos do fenômeno Google, que ensinou ao mundo como processar e pesquisar mon-
tanhas gigantescas de dados, uma nova tendência aparece. Em 2003, quando o Google se
defrontou com o desafio de indexar a internet toda, colocando todas as páginas passíveis
de serem acessadas pelas suas máquinas de buscas, apareceram as primeiras ideias. Para
resolver esse enigma, um conjunto de engenheiros da Google definiu o conceito de
MapReduce, conjugado com o complexo sistema de gerência de dados (FMS) desen-
volvido pela própria Google.
A ideia por trás do MapReduce é um framework de programação que foca
fortemente o processamento e o armazenamento distribuído de dados, além de es-
truturações de dados que em nada lembram as tradicionais tabelas e relações que
conhecemos. Com o melhor da filosofia “dividir para conquistar”, a proposta visa
a quebrar um enorme conjunto de dados em “tascos” menores que serão espalha-
dos por milhares de nós processadores. Um nó controlador, tipo máster, quebra as
perguntas em pequenas consultas que são enviadas aos nós processadores e depois
retornam, quando são agregadas numa resposta coesa. O Google reescreveu todo o
seu sistema de indexação para se utilizar das vantagens da proposta de MapReduce.
Além de trabalhar com essa esquadrilha de nós processadores, o framework ainda pos-
sibilita a estratégia de fault-tolerance, que garante que, mesmo que haja queda em
alguns dos muitos nós, os remanescentes se incumbirão de realizar as tarefas que não
puderam ser terminadas. A proposta foi revolucionária, pois permitiu que, em vez
de um ou alguns supercomputadores, todo o processamento possa ser executado por
máquinas menores, mais baratas e com menor investimento. A tecnologia permitiu

291
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

que a Google tornasse o seu sistema muito mais inteligente, trocando a complexidade
anteriormente existente pelas análises de comportamentos dos usuários Google, com
oferecimento de novos produtos e desenvolvimento de melhorias que alcançaram
também os produtos Google Maps e Google Earth. Os detalhes mais secretos da
tecnologia MapReduce e de seu Google FMS permaneceram proprietários, porém
a empresa permitiu a publicação aberta de alguns conceitos subjacentes. Essas pu-
blicações permitiram o desenvolvimento de alternativas no mercado. Quando o site
Yahoo percebeu a força da proposta do concorrente, juntou esforços para desenvolver
algo semelhante, criando o Hadoop, batizado em função do nome de um brinquedo
(baby elephant). O Hadoop não é considerado propriamente um SGBD (Sistema Ge-
renciador de Bancos de Dados), ficando mais centrado na categoria de gerenciador
distribuído de arquivos – DFMS (Distributed File Management System). É caracterizado
pela ausência de uma linguagem específica como o SQL e por uma forma estrutural
menos rigorosa, como a definida pelo modelo relacional, que é moldado por norma-
lizações e regras de dependências funcionais. O Hadoop, ao contrário, permite uma
forma flexível de definições estruturais e não oferece uma linguagem DML (Data
Manipulation Language) padrão, podendo ser trabalhado por qualquer linguagem do
mercado. O Hadoop tem grande parte de sua força na combinação com a estratégia
de distribuição de dados, através de uma arquitetura MPP, em que uma esquadrilha de
servidores oferece “escalabilidade” linear. O Hadoop aplica o modelo de programa-
ção do MapReduce, possibilitando a criação de aplicativos em qualquer linguagem e
que roda em paralelo, dentro da arquitetura distribuída estabelecida. O Hadoop não
trabalha na forma transacional, sendo vocacionado para processamentos batchs que
executam os programas desenvolvidos. Nesse estágio não há consultas interativas. Não
comporta acessos randômicos aos dados, trabalhando de forma sequencial, o que pode
trazer certas restrições em tipos de processamentos com workload misto (atualização e
consulta) que exigem acessos aleatórios. Hoje, o Hadoop se destaca como um ambi-
ente de processamento com “escalabilidade” infinita, tratando altíssimos volumes de
dados que seriam inviáveis de ser tratados (armazenados e processados) num RDBMS
tradicional. Como um DFMS, o Hadoop permite o tratamento de dados estrutura-
dos, semiestruturados e não estruturados, potencializando o seu uso na web. Hoje o
Hadoop permite a análise do que cerca de 300 milhões de pessoas veem no site do
Yahoo, minerando o seu comportamento e alternando dinamicamente home pages
por onde eles se deslocam. O Yahoo estima um investimento de dezenas de milhões
de dólares no seu desenvolvimento, mas a sua essência é mantida como open-source.
Até a Microsoft, normalmente refratária aos aspectos de open-source, também adotou
o Hadoop quando incorporou a empresa Powerset a fim de melhorar a sua máquina
de busca. No Facebook, o Hadoop é usado para gerenciar 40 bilhões de fotos arma-
zenadas na maior das redes sociais. A empresa Eyealike, por sua vez, aplica o Hadoop
para o reconhecimento facial em fotos. O Hadoop agora é um framework de código
aberto da Apache e está sendo usado por algumas empresas, como Comscore (espe-
cializada em aplicações de inteligência no mercado digital) e CBS Interactive (com
foco em marketing digital), para tratar gigantescos volumes de dados e prepará-los
para estruturas de BI/analytics.

292
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

O produto pode ser obtido na Apache Foundation, em módulos indepen-


dentes, mas pode ser comprado de terceiros, como Cloudera e IBM, em pacotes.
O pacote é uma unidade com vários componentes testados para garantir compati-
bilidade e estabilidade entre as partes, além de vir com suporte e serviços na base
de assinatura. A Cloudera também está desenvolvendo aplicativos focados em seg-
mentos verticais, como financeiro, biotecnologia, energia, varejo e seguros baseados
nos conceitos do MapReduce e em um FMS (File Management System) similar (com
busca paralelizada em sistemas MPP e fault tolerance). Em algumas soluções, como
a da Aster, são desenvolvidas funções de tratamento de pesquisa, otimização, parti-
cionamento de dados, classificação etc., por vezes embutidas numa sintaxe SQL-
like e que são executadas nos “nós” em que partições de dados são previamente
armazenadas. Isso tudo dentro do estilo de arquitetura que envolve centenas de nós,
alguns com objetivos específicos, como armazenamento de metadados, analisador,
otimizador e distribuidor de consultas por entre os diferentes “nós” etc. Com o ob-
jetivo de otimizar os acessos, o Hadoop adota blocos físicos de tamanho grande (64
MB). A solução também foca o processamento in-memory e máquinas MPP (Massive
Parallel Processing). Essa arquitetura é voltada para o tratamento de grandes arqui-
vos, como click-stream data base, que registram os passos de um internauta pelo site
através dos cliques de uma sessão, ou para o processamento de dados da Catalina,
por exemplo, em que pesquisam dados de milhões de clientes que usam cupom,
para montar modelos de comportamento. A parte cuidadosa na adoção de uma
solução dessas é exatamente a sua imaturidade, comparada com o SQL quarentão,
além de conceitos novos, incomuns e não tão fáceis, como os tradicionais relacio-
nais. A Google e a IBM têm programas para o ensino do Hadoop nas universidades,
visando à sua maior adoção.
Pontos fortes da estratégia Hadoop: sempre que as novidades aparecem é impor-
tante analisá-las sob certos aspectos, conforme a seguir.
Custo: o software é livre e, quando comparado com o custo de uma estrutura de
SGBD relacional necessário para tratar dados no volume da era dos zettabytes, torna-se
mais atraente ainda.
Dados: por possuir uma abordagem sem esquema formal de dados, o Hadoop
e o MapReduce trabalham bem com qualquer tipo de dados. O MapReduce inter-
preta os dados em tempo de execução, baseado em estruturas simplificadas do tipo
“chave=valor” definidos em um programa de MapReduce. Dessa forma, o programa
pode trabalhar com facilidade no tratamento de dados estruturados, semiestruturados e
não estruturados, como imagens, textos etc.
Escalabilidade: o produto é um DFMS que trabalha em arquitetura MPP que
roda em um conjunto de servidores, oferecendo “escalabilidade” linear. Possui overhead
pequeno se comparado com os gerenciadores relacionais.
Modelos de dados: o Hadoop é um DFMS que não necessita de um esquema
ou conceitos de normalização para tratar os dados nem uma linguagem especial para
acessá-los. O produto oferece alto desempenho e facilidade, via aplicações como Flume,
para receber, tratar e transferir altos volumes de dados.

293
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Administração do ambiente: o produto gerencia automaticamente as falhas nos


diversos nós da arquitetura, além de oferecer facilidades para manipulação de grandes
clusters de máquinas, rodando programas que executam em arquitetura paralela.
A Figura 10.29 ilustra uma forma de particionamento de tabelas TFato. A
Figura 10.30 ilustra o framework de Hadoop e MapReduce, com a distribuição de
volumes gigantescos de dados em milhares de “nós” processadores, atuando em ar-
quitetura MPP. Os nós são inteligentes e aplicam os algoritmos de mapeamento (map),
através dos quais distribuem as consultas e depois, no retorno, o conceito de reduce
consolida os resultados. Umas das alternativas na estruturação desses dados é o arma-
zenamento colunar, discutido a seguir. A solução tem uma característica de tolerância
a falhas, permitindo que um nó possa assumir o processamento, no caso de falha em
qualquer outro.

Figura 10.30
Framework Hadoop e MapReduce.

As empresas que são early-adopters ou que chegaram ao extremo em volumes de


dados, principalmente dados textos e não estruturados, buscaram esses caminhos alter-
nativos que, a despeito da sua adolescência, vieram para ficar. Essas empresas (Google e
Yahoo) trazem em si uma forte vocação como especialistas em pesquisas complexas, de
alto volume e sobre dados atípicos.

294
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

FUTURO
O produto ainda está em fase inicial, mas existe forte e positiva percepção do
mercado com relação a ele e à sua capacidade de tratar altos volumes de dados. Hoje,
nomes de empresas como a Netezza (agora, IBM), Aster, Greenplum/EMC2 ou Data-
meer, associadas com abordagens novas como MapReduce e Hadoop estão chamando
a atenção do mundo corporativo, em que os gigantescos volumes de dados e o tem-
po otimizado são fatores críticos que nem sempre as estruturas relacionais tradicionais
conseguem resolver. Há um movimento intenso de inovação em torno do produto,
oferecendo componentes que começam a incrementar e a aproximar o Hadoop do pa-
tamar de um DBMS (Data Base Management System). Recentemente foi introduzido o
componente chamado Hive, uma linguagem SQL-like que gera programas MapReduce
em camadas internas, o que dá ao Hadoop um semblante relacional. Também há um
produto denominado PIG, que permite a criação de lógica em MapReduce, de forma
mais acessível do que a oferecida pela codificação em Java de baixo nível.

Hadoop e BI
Sem nenhuma dúvida, a combinação Hadoop e MapReduce fará parte dos
novos cenários do BI2. Alguns vendedores de sistemas de BI já estão adotando os ele-
mentos de Hadoop em suas arquiteturas. Os produtos Aster Data e Greenplum/EMC2
já oferecem suporte para MapReduce. Diversos empresas produtoras de RDBMS e de
ETC, como Pentaho e Talend, têm anunciado interfaces bidirecionais entre os seus en-
gine e o Hadoop, permitindo, assim, movimentação de dados nos dois sentidos. Outros,
como o Data Meer, oferecem interfaces JDBC para Hadoop, de forma que os usuários
possam executar consultas e a geração de relatórios em estruturas Hadoop, usando os
seus produtos. Há expectativas, para breve, do anúncio de grandes nomes do mercado
de BI, como MicroStrategy, SAP/BO, IBM/Cognos, oferecendo suporte ao Hadoop.
Claramente, o Hadoop desempenhará papel importante na era dos grandes volumes
de dados, de tipos variados, que se mostram como forte tendência nos próximos anos.
A IBM, em setembro de 2010, anunciou a aquisição da Netezza, uma das pioneiras no
tratamento de grandes volumes de dados com a tecnologia Hadoop e pela qual pagou
US$1,7 bilhão.

Evolução das arquiteturas e tecnologias de SGBD que


beneficiarão o BI2
Os cenários de BI2 continuarão a testemunhar a já antiga discussão sobre a
melhor estratégia arquitetural para as soluções de BI, num movimento pendular que
vai do BI departamental, centrado em data marts integrados, conforme defende Ralph
Kimball, ao BI corporativo, conforme propõe Bill Inmon. Esse debate seguirá uma
linha decisória que deverá considerar aspectos de tempo e custo de investimento contra
soluções conceitualmente imperfeitas, do ponto de vista de dados corporativos, com
maior probabilidade de redundância e de pontos de fragilidade no campo de qualidade.
Os mais maduros buscarão uma solução equilibrada entre os dois polos. Assim foi com
bancos de dados e assim será com DW/Dmart, que, por coincidência, também são ban-

295
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

cos de dados. Além disso, começa a aparecer uma terceira via, com uma arquitetura to-
talmente nova voltada para volumes gigantescos de dados (Big Data), como as propostas
anteriormente discutidas de MapReduce e Hadoop, que certamente vão mudar alguns
paradigmas e conceitos fincados desde o início do BI. A Figura 10.31 ilustra o conceito
de arquiteturas alternativas, aparecendo a terceira via do MapReduce/Hadoop como
possibilidade para os cenários de zettabytes.

Figura 10.31
Arquiteturas alternativas para cenários de zettabytes (Big Data).

Armazenamento colunar
Na parte de armazenamento de bancos de dados, haverá uma forte tendência
também ao uso do armazenamento por colunas: a expansão do uso de armazenamento
por colunas certamente vai contribuir para a mitigação de certos aspectos de desempenho.
Por quê? A resposta é a seguinte: diferentemente do armazenamento tradicional, no qual
as linhas de uma tabela são armazenadas como unidade de acesso dentro de um bloco, no
armazenamento colunar a forma se inverte. Todas as colunas das tuplas/linhas são arma-
zenadas de forma contígua dentro de um registro, ficando, por exemplo, todas as datas de
vencimento contíguas, todos os nomes de sócios colados uns aos outros etc. Isso, obvia-

296
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

mente, vai facilitar sobremaneira os acessos quando se procura tratamento conjuntivo de


colunas (soma, média, mínimo, máximo, count etc.), mas onera os acessos tradicionais. Essa
forma de armazenamento por coluna também facilita a compressão de dados, permitindo
uma otimização de operação de Is/Os físicos. Quando todos os dados de mesmo domínio
são colocados juntos, cria-se facilidade para os algoritmos de compressão. É claro que essa
nova forma traz overhead para o armazenamento de novas linhas e para os processamen-
tos por conjunto de tuplas. A tendência é que os SGBDs ofereçam uma forma híbrida
de armazenamento (tradicional e colunar) que, embora gaste mais disco, permitirá uma
forma alternativa de acesso em situações de tratamentos por coluna. Entretanto, já está
instalado um posicionamento de contra-argumentação, por parte dos produtores tradicio-
nais de soluções de BI, a respeito da força com que a estratégia de estruturação colunar se
apresenta no mercado. Invertendo a lógica desenhada desde que o primeiro arquivo foi
projetado, a proposição colunar certamente tem vantagens com relação a consultas que
demandam tratamento aglomerado de campos, porém não deve ser considerada como
“bala de prata”, como tendem a ser vistas novidades tecnológicas emergentes. Isso não
quer dizer que, pela obviedade dos volumes gigantescos, as abordagens convencionais de
estruturação não devam ser reavaliadas. Os players que estão oferecendo as soluções colu-
nares com maior projeção são: Aster Data Systems Inc., ParAccel, Vértica, além de Ne-
tezza Inc (IBM), Oracle e SybaseIQ, agora pertencente ao SAP. O SybaseIQ foi um dos
pioneiros nessa área, repetindo a tradição do produto de oferecer novidades tecnológicas,
como quando introduziu os primeiros conceitos de Stored Procedure. Os fornecedores
tradicionais de BI relacional que não adotam estratégias colunares argumentam que a
adoção de arquitetura MPP os torna mais flexíveis do que os colunares, embora sejam
coisas convergentes. Alguns players argumentam que a estratégia colunar funciona bem
em certas situações e pode não ser tão flexível em buscas nas quais as informações sobre
as linhas completas sejam fortemente requisitadas, o que é absolutamente verdadeiro. Al-
guns produtos já oferecem as duas estratégias de forma concomitante, permitindo melhor
flexibilidade na adoção mais adequada. Por exemplo, Netezza, agora IBM, e Greenplum,
esta agora pertencente à EMC2, já oferecem essas alternativas. Alguns produtos oferecem
as duas estratégias de forma concomitante, permitindo melhor flexibilidade na adoção
mais adequada. A bem da verdade, essa forma de armazenamento não constitui nenhuma
novidade, estando presente nos domínios de bancos de dados desde o século passado (de
novo uma falsa impressão de eternidade...). Agora volta, com mais força, devido ao for-
talecimento da sua necessidade e à aproximação da era do Big Data (era dos zettabytes).

Processamento in-database
Esse conceito representa modificações no engine de certos SGBDs que estão
procurando integrar no seu cerne as funções de processamentos analíticos, outrora de
responsabilidade de módulos ou produtos diferentes. A ideia é que, no miolo da máqui-
na de bancos de dados, habite um framework que funcione voltado para os tratamen-
tos analíticos de altos volumes de registros. Esses componentes explorarão com maior
habilidade as características de paralelismo e “escalabilidade” dos processadores e dos
sistemas de armazenamento, possibilitando a resolução de transações analíticas longas
com maior desempenho. Serão elementos fundamentais na necessidade de maior de-

297
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

sempenho demandada por altos volumes de dados e pela tendência de processamentos


em tempo real, evoluindo de “o que aconteceu na semana passada?” para “ o que está
acontecendo agora?”.

Dados em memória
Com a queda abrupta do custo de memórias, os servidores de bancos de dados
tenderão a ter altos volumes de RAM, o que permitirá que um grande volume de dados
seja processado e mantido em memória, reduzindo os tempos de I/O físico. Os caches
serão generosos para receber um número grande de linhas, podendo acolher até tabelas
inteiras (in-memory tables). Isso, quando somado aos itens anteriores, evidencia uma forte
tendência de se ter mitigado os problemas de desempenho, no contexto do BI2.

Arquiteturas e serviços
O modelo de arquitetura do BI2 deverá centrar no padrão Web 2.0, com ca-
madas leves, modulares e escaláveis, permitindo rápidas implementações, em ambientes
já familiares aos usuários. As interfaces para aplicações BI-Mobile serão uma tendência,
podendo o conceito de BI também se encontrar com SaaS (Software como serviços) e
entrar nas “ nuvens” (Cloud).

Tendências em ferramentas open-source de BI2


Além das ferramentas mais tradicionais de BI, outras deverão ter crescimento
na era do BI2: a pilha LAMP (Linux, Apache, MySQL e PHP/Perl ou Python) apa-
recerá com maior desenvoltura nesse cenário, juntamente com o EPF (Eclypse) como
plataforma. Isso implica menor TCO, custo total, devido às facilidades de aquisição das
ferramentas livres. A Pentaho, uma das pioneiras nesse campo, oferece uma suíte de BI
avaliada como competente. A Actuate, outra do mesmo nicho, oferece estrutura de BI
baseada no BIRT (Business Intelligence Report Tool), do Eclypse. A fundação Apache
é responsável pelo Apache Hadoop, conforme visto, uma solução que oferece potencial
para processamentos data-driven, incluindo o framework MapReduce que potencializa
processamentos de transformação de dados e de aplicações analíticas para petavolumes,
ou big data. No mundo open-source, a Talend oferece soluções para integração de dados,
com ferramentas para movimentação, combinação e consolidação de dados. As ferra-
mentas de ETC (extração, transformação e carga) continuarão com presença forte, mas
apresentarão algumas evoluções, se aproximando dos conceitos de BPM. Essa camada,
responsável pela parte crítica que une os dois domínios (transacional e informacional),
teve poucas evoluções com relação aos primeiros momentos da tecnologia BI. A grande
novidade tem sido uma gradativa automatização dos procedimentos desse domínio. Os
processos de ETC, hoje, podem ser planejados com um BPM, no qual as diversas ativi-
dades são definidas e ligadas por condições, de forma a costurar um conjunto de passos
que dão alto grau de transparência ao processo.

Triplestore
Outra forma de estruturação de dados se avizinha, buscando uma maior flexibi-
lidade na definição dos bancos de dados construídos na era dos zettabytes. É chamada

298
ELSEVIER
C APÍTULO 10 I P ROJETO F ÍSICO DE A PLICAÇÕES DE BI

de Triplestore e nasceu como uma forma de embutir dados e metadados na própria


estrutura armazenada. Diferentemente dos modelos relacionais que se baseiam na de-
finição de ênuplas (várias colunas com valores, numa relação normalizada), conceito
simplificado para tuplas, a abordagem de triplestore chega com uma proposta diferente.
A ideia é que a unidade de armazenamento mínima seja uma tripla, ou seja a conju-
gação de <sujeito> <predicado> e <objeto>. Por exemplo, <Barbieri> <escreveu>
<livro>, ou <Isabella> <toca> <violão>, ou <Cláudio> <tem> <30> (idade). Dessa
forma, o armazenamento se dá conjugando os metadados com os dados, explicitados
através da tripla combinação desses elementos. Isso sugere uma maior flexibilização na
incorporação de novos atributos, visto que se insere uma estrutura atômica do mo-
delo, sem impacto direto em conceitos de tabelas, linhas etc. O modelo se baseia no
framework RDF - Resource Description Framework (RDF). Semelhantemente ao
modelo relacional, existe também acoplado a ele uma linguagem de acesso e possibi-
lidades de indexações instantâneas. Os gerenciadores de triplestore já se mostram com
a capacidade para armazenar bilhões de triplas e alguns nomes já surgem nesse novo
cenário, engrossando os conceitos da Web semântica. Por exemplo, 3store, Allegrograph,
Bigdata, BigOWLIM, Sesame, Soprano, Virtuoso etc são nomes que aparecem nesse
cenário de novas alternativas estruturais.O site da W3C http://www.w3.org/wiki/
LargeTripleStores mostra uma relação com diversos produtos desta nova cepa e alguns
resultados alcançados por mais de 15 desses RDF Data Base Engine. Alguns desses pro-
dutos, como Virtuoso apresentam novas formas de indexações com bitmap, conforme
discutido anteriormente.
Com a diminuição de custos de armazenamento e a busca por maior rapidez e
flexibilidade nas estruturações e pesquisas, o conceito de BI2 também se valerá dessas
novas proposições, principalmente para armazenamento de grandes volumes de dados
que se mostram como forte tendência nesta década.

Produtos e tendências da era dos zettabytes (Big Data)


Os produtos que se mostram nas vitrines mais atuais da era do zettabytes são As-
ter Data, Dataupia, Greenplum/EMC2, Infobright, Kognitio, Netezza/IBM, ParAccel,
Vértica, além dos já conhecidos como Sybase Inc. (agora SAP), Teradata e outros tradi-
cionalíssimos, como IBM, Microsoft, Oracle, todos se posicionando corretamente ar-
quitetados para o tratamento de dados na era chamada como Big Data. Alguns poderão
escalar melhor que outros e, além da “escalabilidade”, outros fatores deverão ser con-
siderados. Cada produto oferece certas características próprias. Como cita Wayne Eck-
erson, diretor de educação e pesquisa do TDWI (The Data Warehousing Institute), no
seu relatório Big Data Analytics Checklist Report, isso tem semelhança com a indústria
automotiva, em que carros e modelos oferecem opcionais específicos que podem ser
obtidos caso necessário. Uma dessas características é a chamada in-database analytics, que
permite que funções analíticas sejam aplicadas dentro do próprio SGBD, embutido no
seu núcleo, facilitando um tratamento dentro do hábitat relacional e evitando movi-
mentos de dados para outras camadas, nas quais deveriam ser tratadas com esse objetivo.
O ponto mais incandescente nessa discussão de tendências talvez seja o crescimento
do suporte às consultas via produtos Non-SQL. O algoritmo de MapReduce, cada

299
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

vez mais encontrado nos produtos, já está presente nos produtos AsterData e Green-
plum/EMC2 há dois anos. Recentemente, Netezza, adquirida pela IBM, e Teradata
anunciaram adesão ao protocolo. Também a open-source Talend, empresa com foco em
integração de dados, anunciou suporte ao Hadoop, numa implementação open-source do
MapReduce. Com isso, a empresa permitirá funções in-database em conjunção com BD
compatíveis com o Hadoop. A busca por estruturações de dados mais simples, fugindo
dos aspectos rigorosos do SQL, é justificada pelo fato de que a computação analítica é
por vezes recursiva e requer múltiplas passadas pelos dados no BD. Isso, normalmente,
é difícil de ser executado no SQL e pode ser resolvido mais facilmente pelos preceitos
encontrados nos produtos Non-SQL. Técnicas como MapReduce facilitam o trabalho
de analistas de negócios que podem fazer essas análises, sem a presença de profissionais
de TI. Isso é possível devido às funções de BD customizadas que rodam em ambientes
paralelos. Por exemplo, o Aster Data e o Greenplum/EMC2
/EMC2 permitem a analistas e de-
senvolvedores escrever funções reusáveis em linguagens (Python, Java, C, C++ e Perl) e
que podem ser invocadas por meio de chamadas SQL, quando pertinente.

RESUMO
Nos próximos anos, os conceitos de Big Data estarão, cada vez mais, permeados
das diversas aplicações do mercado. O crescimento do volume de informações, na pro-
porção em que se avizinha na era do zettabytes, exigirá novas formulações nos sistemas
de inteligência de negócios, com foco na rapidez de seu desenvolvimento e no de-
sempenho que serão demandados. Um conjunto de novos arsenais de tecnologia, como
visto anteriormente, estará à disposição para o enfrentamento dos desafios do Big Data.
Quem foi da geração que testemunhou a “era de Aquarius” agora vislumbrará a era do
data ocean ou do oceano de dados, em que de nada adiantará a imensidão do seu volume
se pequena for a sua qualidade.

300
CAPÍTULO 11

BI2 – Novas tendências na aplicação


de inteligência de negócios

BI DE PRIMEIRA GERAÇÃO E SUAS TECNOLOGIAS CORRELATAS


A tecnologia de BI, presente há mais ou menos 15 anos, como todas as outras
manifestações tecnológicas que deram certo, está sofrendo transformações gradativas e,
claro, fundamentais para a sua evolução e consolidação. O conceito de BI hoje abriga
sob a sua sigla um conjunto de abordagens que amplia o seu leque de atuação origi-
nalmente pensado quando foi introduzida. No guarda-chuva do BI se estabeleceram
inicialmente os conceitos de OLAP (processamento analítico), ETC (Extração, Trans-
formação e Carga), data warehousing (DW), data mart (DMarts), e data mining como
elementos fundamentais de preparação, armazenamento e tratamento analítico da infor-
mações. Tangenciaram a sua borda os assuntos de inteligência competitiva, BSC (Balan-
ce Score Card), já alterado para Business Score Card, BAM (Business Activity Monitoring), EII
(Entreprise Information Integration) etc., como espécie de proposições colaterais ao assunto
central. Como as tecnologias não têm fronteiras perfeitamente definidas, esses contatos
entre elas se dão de uma forma, às vezes, direta e total ou, às vezes, indireta e parcial.
A abordagem de EII (Enterprise Information Integration), por exemplo, toca em data wa-
rehousing na medida em que permite a criação de visões dimensionais, acessando dire-
tamente produtos de bancos de dados relacionais, criando uma espécie de DW virtual,
além da possibilidade de acesso a variados tipos de dados, importante para a camada de
ETC. Já o BSC usa dados de variadas fontes, obtidos dos DW ou DMarts, para compor
a sua cadeia de indicadores que perpassam os diferentes domínios, de financeiro ao de
processo, por exemplo. A Figura 11.1 ilustra o conceito de BI de primeira geração, com
os elementos já definidos. A fronteira à esquerda representa os elementos (sistemas e da-
dos) associados com clientes. A fronteira à direita enfatiza os pontos de contatos com os
fornecedores e parceiros da empresa. Na parte de baixo aparecem os sistemas transacio-
nais, na forma de legados, ERP etc. A oval do meio representa as camadas de integração
entre os diversos sistemas e fontes, numa espécie de cola mágica que conecta aplicações
e estabelece um corredor de dados e informações entre as várias regiões organizacionais.
Na parte de cima aparecem os elementos de BI, com os cubos representando os depó-
sitos informacionais (DW e DMart), frutos da transformação dos dados transacionais,
além dos conceitos colaterais associados, como mining, BSC, CI e BAM.
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 11.1
Ambientação BI tradicional.

BI2 – NOVOS CONCEITOS


O BI2, como chamamos essa nova fase do BI, deverá trazer algumas novidades,
que da mesma forma são evoluções ou transformações de outras que por aqui já estive-
ram ou estão sendo praticadas ainda em estágio inicial. As ferramentas do BI2 serão mais
integradas, automatizadas e com maior facilidade de tratamento, oferecendo interfaces
mais intuitivas, que serão via Web 2.0, BI-Mobile etc. até que movimentos mais desen-
volvidos, como “speech I/O” se transformem em realidade, conforme discussão sobre o
Watson, mais adiante. Num primeiro momento espere pelo B-IPhone, B-IPad e outros,
já saindo das pranchetas. O ciclo de vida das aplicações do BI2 tenderá a ser mais auto-
matizado, a começar pelo descobrimento e identificação das fontes de dados, hoje um
processo manual e exaustivo. O crescimento dos conceitos de governança, de qualidade
de dados e metadados ajudará nesse ponto, dando ao dado um status proporcional à sua
importância. Com o processo de extrema “comoditização” das tecnologias acontecen-
do nas empresas, a informação se transformará no grande diferencial competitivo dos
próximos anos e a importância desse insumo crescerá. O BI2 tenderá a ser mais difuso,
ubíquo (pervasive), no sentido de estar mais próximo dos processos da empresa. As em-
presas vivem num mundo caracteristicamente process driven, e o BI tem uma personali-
dade data-driven. Assim, a aproximação dos dois conceitos deverá ser uma tendência, e o
BI será obrigatoriamente pensado quando se pensar o processo de negócio. Conforme
a Figura 11.2, além das estruturas originais do BI inicial, outros conceitos estarão pre-

302
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

sentes. Algumas dessas novas tendências já estão acontecendo e poderão se consolidar no


futuro. Outras poderão somente chegar e não cumprir a sua trajetória. Algumas, como
a já presente análise preditiva, deverão se consolidar, além de extensões em tecnologias
e arquiteturas para o que chamamos da era dos zettabytes ou Big Data. O conceito de
zettadados é uma figura de linguagem para a expressão dos volumes cada vez maiores
de dados e informações que acontecerão nos próximos anos.

Figura 11.2
Ambientação BI2.

Novas aplicações de BI em campos mais amplos, como comportamento, blogs


e dados não estruturados, surgirão por força das redes sociais e de novas necessidades
de negócios. Assim deverão crescer o Geo-BI, para tratamentos de dados georreferen-
ciados, e o BI aplicado à Gerência de Projetos. Além disso, a fusão dos conceitos de
modelagem ágil e Scrum aplicados ao BI deverá aparecer como uma abordagem a ser
praticada na confecção mais rápida de projetos de BI2. Também a camada integradora
deverá acolher os conceitos de BPM (Business Process Modeling), SOA (Service Oriented
Architecture) com SaaS, levando o BI ao patamar de serviços, e conceitos de Cloud Com-
puting. A Figura 11.3 mostra um mapa mental contendo alguns dos principais conceitos
que enquadramos no espectro difuso do BI2. Alguns conceitos foram discutidos no
Capítulo 10, quando falamos sobre tecnologias e arquiteturas voltadas para o BI2, com
focos em maior rapidez, disponibilidade e desempenho, como nas tendências de BI em
tempo real, in-memory analytics e nos grandes depósitos de informação (Big Data) que se
avizinham na era dos zettabytes.

303
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Figura 11.3
Mapa mental síntese – principais conceitos do BI2.

Uma das grandes diferenças do BI2 deverá ser a maior aproximação de BI


com os aspectos de governança e qualidade de dados. Isso significa que a grande
mudança do BI se dará no melhor entendimento da sua quintessência. Para tanto,
deverá ser observado, com mais rigor, o conceito fundamental do BI, que se baseia
na transformação dos dados transacionais, externos ou internos da empresa, em
informações limpas, próprias para análises e tomadas de decisão. Um dos pontos
pouco relevados desde o nascimento das técnicas de BI foi a qualidade dos dados.
Embora seja de importância capital manter o acervo dos dados em estado de qua-
lidade que permita a perfeita transformação em informação, esse ponto sempre foi
tocado, digamos, com certa parcimônia no mundo de BI. Os aspectos de qualidade
dos dados sempre foram considerados mais no meio do caminho do que no seu
nascedouro. Os dados sempre foram analisados com mais acuidade, quando se pre-
paravam para transpor a fronteira entre o transacional e o informacional. Ali, nos
domínios das rotinas de ETC, eles eram avaliados no seu conteúdo sintático e se-
mântico, passando adiante ou submetidos a uma limpeza (cleansing) que lhes permi-
tiria retornar no ciclo seguinte. Entendemos que isso é pouco. A ideia é mudar essa
rota. O que se pretende é voltar e reafirmar o conceito de que os dados são ativos
fundamentais da empresa e criar condições para que eles sejam produzidos, já no
seu nascedouro, com o grau de qualidade que lhes permita a geração de informação
correta, ao longo do seu ciclo de vida. No lugar de se preocupar com dados somen-

304
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

te numa fase transitória do processo de BI, o importante é juntar esforços para que
esses conceitos de qualidade passem a fazer parte de todo o ciclo de vida do dado
e da informação. Ou seja, os dados deverão ser considerados como um ativo, com
ciclo de vida definido e gerenciado.

GOVERNANÇA DE DADOS, QUALIDADE E MDM


Como discutido em capítulos anteriores, os aspectos de qualidade de dados,
bem como os de governança de dados, deverão aparecer, nos próximos anos, com
mais intensidade, visto serem elementos cada vez mais necessários para que se produ-
zam essas condições de qualidade no nascedouro dos dados. Terão, por consequência,
influência direta nos aspectos relacionados a BI. Acoplados a esses conceitos apare-
ce a também já discutida abordagem MDM (Master Data Management), ou seja, os
tratamentos dos dados mestres, fundamentais no sistema circulatório da empresa e
que também são insumos fundamentais do mundo do BI, formando um arco de
dimensões presentes em quase todos os repositórios informacionais da empresa. O
conceito de MDM se interliga com o de BI por motivos óbvios. Os MD (dados
mestres) são diretamente associados às dimensões fundamentais no mundo dos DW
e DMarts, e se fortaleceram em função da onda de fusão por que passam as empresas
e a ebulição dos negócios. As fusões de grupos trouxeram à tona essa necessidade,
devido ao aparecimento de bases duplicadas de cadastros estratégicos, como cadastros
de clientes e de produtos. Dessa forma, os conceitos de MDM podem se interligar
com aplicações de modelagem de processos (BPM), além de influir na área de BI,
na qual são dimensões fundamentais dos esquemas em estrela ou flocos de neve. As
tendências em governança de dados mostram que num futuro próximo as empresas
deverão pensar em algo como um DGPG, central da governança de dados, grupo
que deverá conduzir, com o apoio do alto board da empresa, a implementação dos
processos derivados das ações de governança de dados. Além disso, as tendências de
BI sugerem que, no futuro, as empresas evoluirão na conceituação do BICC, cen-
tro de competência em BI, com funções de BI especializadas, reunidas num núcleo
responsável pelo processo de desenvolvimento mais formal das estruturas concei-
tuais de dados e informações. Esses núcleos deverão trabalhar em conjunto, no sen-
tido de resgatar o hiato proporcionado pelo desaparecimento da AD (administração
de dados), grupo funcional que existiu nos anos 1980 e que tinha missão parecida.
Esses grupos terão em comum, dentre outras coisas, a missão de criar e manter as de-
finições de metadados. Os metadados continuarão sendo vistos como grande desafio,
agora dentro do escopo da governança de dados e apoiado pelo BICC, que volta a se
preocupar com eles. A definição formal de forças-tarefas para levantamento de me-
tadados ainda é vista com certa restrição, chegando a sugerir excesso de purismo. A
baixa popularidade dos metadados é um desses fenômenos ainda não explicados da TI:
o porquê de os dados, ativos vitais de uma empresa, não terem o tratamento na devida
proporção de sua importância. Aos dados é conferido um senso de alta importância,
mas aos metadados são dedicados poucos esforços.

305
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

Resumo
Além dos aspectos imperiosos de governança e qualidade de dados aplicados a
essa nova era do BI2, também os estratosféricos volumes de dados e informações produ-
zidos dentro do conceito de universo digital sugerem cuidados e mecanismos diferentes
daqueles que o BI tradicional se ocupou em implementar. O BI2 se defrontará com a
era dos zettabytes.

A ERA DOS ZETTABYTES – O TAMANHO DO UNIVERSO DIGITAL


A era do zettabytes, como chamamos o futuro em que seremos informações co-
dificadas e transformados de human being em human bits, pode ser imaginada pelo volu-
me de informação produzido nesses últimos anos. Os pesquisadores Martin Hilbert, da
USC (University of Southern California), e Priscila López, da OUC (Universidade
Aberta da Catalunha), fizeram um estudo que estima o acervo de informações existente
de 1986 até 2007. Caso fosse armazenado de forma otimizada, o volume de informação
existente em 2007, presente nas diversas formas de suporte, analógicos ou digitais, che-
garia a um volume de 295 trilhões de megabytes ou 295 exabytes (295 EB). Exabytes
é a unidade que representa 1.024 petabytes, que, por sua vez, vem a ser 1.024 terabytes.
Se esses dados fossem armazenados em CD com capacidade de 730 megabytes, com
1,2 mm de espessura, teríamos 404 bilhões de CDs, que empilhados chegariam além
da região orbital da Lua. Até o ano 2000, os meios analógicos guardavam cerca de 75%
de toda a informação da humanidade. Em 2007, segundo o estudo, mais de 94% dessas
informações estaria em meios digitais, invertendo fortemente as posições, com relação
ao início deste século. Claro que o crescimento da internet banda larga e da telefonia
móvel tem contribuído significativamente para essa produção maciça de informações.
Esse aumento teve como contrapartida a suportá-lo o crescimento da capacidade dos
processadores. Segundo a mesma pesquisa, o somatório de todos os processadores em
computadores pessoais alcançava a capacidade de 6,4 trilhões de MIPS (milhões de
instruções por segundo) e mostravam tendência de dobrar a cada 18 meses, alavancado
pela capacidade de processamento embutida, cada vez maior, nos diferentes devices hoje
consumidos, como os celulares e os consoles de videogames. Os números mostrados
na pesquisa, embora gigantescos, ganham tom de certo mistério quando comparados
com os de outra natureza. Por exemplo, citam os autores que a quantidade de cálculos
que todos os computadores do mundo podem fazer está no mesmo nível do núme-
ro de impulsos nervosos executados pelo cérebro humano por segundo, e a infor-
mação acumulada no período estudado é ainda menor do que a codificada no DNA
de um ser humano, que gravita na ordem de 10 zettabytes. Isso nos dá uma sensação
esquisita de que a tecnologia insinuante e espetacular que produzimos tem servido
também ao propósito de nos mostrar o quanto somos menores do que imaginamos.
Outra pesquisa, patrocinada pelo grupo EMC, grande fabricante de sistemas de Storage
– que tive oportunidade de visitar perto de Boston, em dezembro de 1998 –, realizada
pelo IDC, que durante anos publicou o ComputerWorld, no qual escrevi muitas colunas
desde 1988, revela o crescimento impressionante sobre o chamado universo digital. O
conceito de universo digital seria a tradução, em bytes, de toda a produção de informa-

306
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

ção capaz de ficar registrada em meio digital. Segundo a pesquisa, o volume em 2009
cresceu 62% com relação ao ano anterior e alcançou o estratosférico valor de 800 mil
petabytes, ou o esquisito 0,8 zettabyte. Isso é equivalente a toda informação que poderia
ser armazenada em 75 bilhões de IPads, ou o total de informações “twitado” por todos
os habitantes do planeta, durante um século.
Para 2010, o conteúdo digital do planeta deverá ter alcançado 1,2Z B (zetta-
bytes), que, comparado, seria 500 mil vezes maior do que todas as bibliotecas acadê-
micas dos Estados Unidos. Quando essa mesma pesquisa foi realizada pelo IDC-EMC,
em 2007, os números apontavam o universo digital em 264 EB (exabytes), um pouco
abaixo do valor apontado pelo estudo da USC e da UAC. Naquele momento houve a
previsão de que, em 2010, o valor alcançaria 988 exabytes, pouco (?) abaixo do 1,2 ZB
que deverá ter efetivamente alcançado.
Outra pesquisa, da Universidade da Califórnia, em San Diego, garimpou o flu-
xo de dados que um domicílio americano recebe. Encontraram que, em 2008, os lares
americanos foram inundados por aproximadamente 3,6 ZB (zettabytes) de informação,
ou 34 GB por pessoa, por dia. O grande volume vem de TV e videogame, sendo que
a palavra escrita está bem em baixa (menos de 1% do total). Entretanto, o número de
pessoas leitoras (que leem textos), que havia declinado significativamente após o cres-
cimento da TV, voltou a crescer, triplicando a partir dos anos 1980 devido à internet.
Os pesquisadores apontam que as informações criadas por máquinas e lidas por outras
máquinas crescerão muito rapidamente, mais do que qualquer outra forma. Também
percebem que apenas 5% das informações criadas são “estruturadas”, ou seja, vêm em
formato de números e letras/palavras que podem ser lidas por computador. A grande
massa é “não estruturada”, como fotos, imagens, sons etc., o que ainda torna mais desa-
fiadora a sua automatização visando ao pleno acesso e uso. Com os conteúdos cada vez
mais rotulados (no sentido de terem labels com seus significados, ou seja, os metadados)
e o crescimento de tecnologias e dispositivos para reconhecimentos faciais e de vozes,
essas restrições começam a ser minimizadas, transformando os DNE (dados não estru-
turados) em estruturados.
Você deve estar perguntando qual é a importância desses números siderúrgicos
que são levantados. A resposta mais lúcida e inteligente que antevejo é: não sei! Esse
papo “abobrinha”, que Shakespeare traduziria para zucchini’s subject, serve somente para
quantificar em métricas, que nunca poderão ser comprovadas, o que percebemos a
olho nu. O que esses números produzem é exatamente um sentimento interessante:
grande parte dessas informações está sendo produzida por nós, indivíduos, mas deverão
ser armazenadas pelas organizações. Hoje os nossos “twittes” ficam no Twitter, que, na
primavera de 2010, gerou 60 milhões de posts/dia; os nossos registros de celulares, que
já alcançam 4,6 bilhões de unidades no planeta, vão para os BDs das operadoras; as foto-
grafias que colocamos na internet ficam no Flickr ou no Facebook, que têm 40 bilhões
delas, e os vídeos despejados pelo mundo afora vão para o YouTube, na proporção de 24
horas de vídeos colocados por minuto. Assim, é de nossa lavra o conteúdo digital pro-
duzido, mas entregamos aos outros a sua estocagem. O livro Total Recall, de Gordon Bell
e Jim Gemmell, publicado pela Dutton, em 2009, aponta para a nova era que dá nome
ao livro, ou seja, a era da “lembrança total”. O conceito desenvolvido pelos autores é de

307
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

que num futuro próximo teremos toda a nossa memória registrada na forma digital. To-
dos os elementos que nos cercam, sejam sons, imagens, fotos, textos, dados biométricos,
chamadas telefônicas, exames laboratoriais etc., serão registrados formando uma espécie
de log da nossa vida. Tudo sobre cada um de nós estará registrado em arquivos logs, do
tipo imagem antes e depois, como existentes nos bancos de dados. Não haverá nenhuma
forma de restrição nos campos da gravação, do armazenamento e da pesquisa, nos per-
mitindo, dessa forma, traduzir todos os instantes da nossa vida em bits facilmente ma-
nipuláveis. O sistema de computação em nuvem seria disponibilizado da mesma forma
como a corrente elétrica nos chega hoje. Bastará plugar em algum proxy doméstico para
que tenhamos tudo registrado e acessível. O armazenamento será ridiculamente barato.
Em 1970, um disco de 20 MB custava US$20 mil e era do tamanho de uma máquina de
lavar pratos. Hoje, um HD externo de 2 TB custa menos de US$400 e ocupa o espaço
de um livro pequeno. Em 2020, segundo o Total Recall, um TB custará o equivalente a
uma xícara de café e teremos alguns TB nos nossos celulares. Por US$100 será possível
comprar 250 TB, o suficiente para armazenarmos 10 mil horas de vídeo e 10 milhões
de fotos. Essas informações, em grande parte dentro da classificação de DNE (dados não
estruturados), exigirão do BI um alcance maior no sentido de suas indexações e buscas.
Mas uma das grandes preocupações é com a nossa capacidade de armazenar o mundo
digital. Terá a indústria de sistemas de storage a capacidade para atender a tal demanda?

Armazenamento na era dos zettabytes


Veja o que dizem os grandes observadores de tecnologia no mundo (Gartner e
IDC), conforme retratado no site TI Inside-OnLine (www.tiinside.com.br), acessado
em 16/8/2010: o mercado global de sistemas externos de storage movimentou US$4,5
bilhões no primeiro trimestre de 2010, o que representa um crescimento de 18,3% em
relação ao mesmo período de 2009, quando gerou US$3,8 bilhões, segundo o Gart-
ner. Na disputa pelo mercado, a EMC manteve a liderança, com participação de 27,2%
sobre a receita total, seguida pela IBM, com 11,7%. A NetApp ultrapassou Hitachi, HP
e Dell, e assumiu o terceiro lugar com market share de 10,4%. Apesar de ter perdido o
posto para a NetApp, a Dell também superou a Hitachi e a HP, e fechou o período com
participação de 9,7%.
A HP, com 9,3% de representatividade, terminou o primeiro trimestre do ano
na quinta colocação, queda de uma posição em relação ao mesmo período de 2009.
O destaque negativo foi a Hitachi, que caiu da terceira para a sexta colocação, respon-
dendo por 9,1% do total entre janeiro e março desse ano. Completa a lista a Oracle
(Sun), que alcançou uma participação de 3,4%, ultrapassando a Fujitsu, que concluiu o
período com 3,2%. A Cisco, grande fabricante de equipamentos de telecomunicação,
prevê que em 2013 a quantidade de dados fluindo pela internet anualmente será de 667
EB (exabytes) e a quantidade de dados continuará a crescer mais rapidamente do que a
habilidade da rede de transportá-la.

A capacidade dos novos chips na era dos zettabytes


No final de agosto de 2010, a Rice University e a HP anunciaram (NYTimes,
30/8/2011) que acabavam de vencer as últimas barreiras que estavam limitando a rapi-

308
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

dez com que o processo de miniaturização eletrônica se apresentava há algum tempo e


que foi submetida a certas restrições de natureza físico-química. Os pesquisadores en-
volvidos publicaram na Nano Letters, um jornal da Sociedade Química Americana, que
houve êxito na construção de switches digitais, componentes essenciais na construção
das memórias dos computadores, o que poderá mudar a escala de miniaturização, com
relação aos métodos existentes hoje. Os novos elementos, feitos de óxido de silício, têm
todos os facilitadores para desenvolvimento, fabricação e comercialização em alta escala.
O processo sugere que chips nos quais hoje cabem mil bits terão, em cinco anos, capa-
cidade de armazenar o que hoje se guarda nos HDs mais robustos do mercado.
Se essas métricas de volumes astronômicos não servem para algo mais relevante,
pelo menos indicam que a humanidade cada vez menos se “analogiza” e cada vez mais
se “digitaliza”. Como a saudade e a paixão podem ser consideradas elementos analógi-
cos, pois emitem sinais contínuos ao longo do tempo, vamos logo desaguar na digitali-
zação dos sentimentos, quando se poderá “attachar” num e-mail a saudade que se sente
de alguém. Mas, se for paixão, muito provavelmente se deverá “zipar” para atender aos
limites de Mbytes do provedor. Adiante.

OS GRANDES DEPÓSITOS DE INFORMAÇÕES DO PLANETA


Quando comecei a escrever sobre BI, nos idos dos anos 1980, o conceito de
grandes volumes de dados era medido em alguns milhões de registros e empacotados
em alguns megabytes ou, talvez, gigabytes. Hoje, à medida que os dados são produzidos
na velocidade de coelho de desenho animado, alavancados por novas mídias, novas es-
calas estão surgindo: gigabytes é marca trivial encontrada nos HDs de mesa, e a escala
terabytes também se prepara para sair em definitivo do mundo das corporações e se
deslocar para o tampo das escrivaninhas dos nossos escritórios. Hoje você compra HD
de mesa de alguns TB nos shoppings populares pelo Brasil. Estamos subindo um degrau.
A fronteira dos petabytes (PB), alcançada há muitos meses, já aparece na mídia e há
desfile aberto de alguns representantes do “petaconsumo”, embora sejam dados ainda
sem confirmação. Alguns deles estão no mundo científico. Um dos maiores volumes
armazenados de dados, de que se tinha registro, é o do World Data Centre for Clima-
te, na Alemanha. Pertencente ao Instituto Max Planck de Meteorologia, o seu acervo
gravita em torno de 220 TB e mais 110 TB de espaço para simulações meteorológicas.
Estima-se cerca de 6 PB de dados armazenados em meios secundários. Outro segmento
potencial de armazenamento peta são os telescópios. Quando, no ano 2000, o programa
Sloan Digital Sky Survey foi iniciado, com o seu telescópio instalado no Novo México,
os dados coletados durante as primeiras semanas foram maiores do que todos os dados
recolhidos desde o início da história da astronomia. Hoje, passados 10 anos, seus arqui-
vos contêm 140 TB de informações. O seu sucessor, o Large Synoptic Survey Telescope,
a ser instalado no Chile em 2016, coletará essa quantidade de dado a cada cinco dias,
prometendo ser um dos maiores “petaconsumidores” da próxima década.
Outro que ultrapassou a “petabarreira” foi o Google, embora mantenha os seus
indicadores de volumes sob sigilo de confessionário. O seu volume é estimado em tor-
no de 4 PB, considerando-se a incrível taxa de 35 mil consultas/segundo. Se todas essas
entradas forem armazenadas, como parece que são, em um ano o BD do Google teria

309
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

33 trilhões de linhas, com muitos petabytes de armazenamento. Outro instituto que


possui grande acervo de dados é o National Energy Research Scientific Computing
Center, Califórnia. Estima-se em 2,8 PB o seu volume.
Um gigante conhecido, o WalMart, famoso pela sua estrutura de tecnologia, a
maior do segmento do varejo, deve ter hoje o BD na faixa de 2,5 PB, processando 1
milhão de transações de clientes por hora. O WalMart continua crescendo e rendendo
folclores no mundo do BI, como um dos DW mais conhecidos do planeta.
Por outro lado, um gigante desconhecido chamado Catalina Marketing, res-
ponsável por marketing direto, acessível no endereço http://www.catalinamarketing.
com/, possui 2,5 petabytes, armazenando três anos de história de compra de cerca de
quase 200 milhões de compradores que têm programas de fidelidade com supermer-
cados, farmácias e outros varejistas. Uma única tabela possui 600 bilhões de linhas. O
interessante nessa empresa, relativamente desconhecida nos cenários de BI, é que o seu
DW é acessado em 44 mil pontos de consumo, com mais de 250 milhões de transações
por semana, o que equivale a cerca de 30-40 milhões de transações por dia, que equi-
valem a cerca de 1,5 milhão de transações por hora, ou 25 mil por minuto ou cerca
de 500 por segundo. Com uma taxa dessa natureza e a necessidade de definição de
modelos para análise preditiva de seus clientes, a empresa teve de repensar as soluções
tecnológicas adotadas.
A fronteira dos terabytes, o espaço mais comum neste início de 2011, tem vá-
rios representantes significativos. Um gigante da área de comunicações, a Sprint, tem
tamanhos não revelados, porém estimado em função do seu volume de três trilhões de
linhas de tabelas, nas quais armazena todas as chamadas telefônicas. Outro gigante, a
ATT, tem volumes na faixa de 320 TB, com armazenamento de 1,9 trilhão de chamadas
telefônicas.
Mas outra grande representante dos “teraconsumidores” é a livraria Barnes and
Noble. Maior cadeia de livraria física dos Estados Unidos, e, acho eu, do mundo, a BN
passou por um processo de consolidação dos seus nove data warehouses diferentes, cen-
trados em Oracle, para a formação de um único DW corporativo. Os diversos DW eram
dedicados a negócios diferentes, tendo um para o controle das lojas, outro para as lojas
exclusivas que ficam nas universidades e faculdades americanas etc. Com o crescimento
dos e-readers e da venda dos livros digitais, essa nova linha de consumidores passou a ser
integrada com os consumidores das lojas de mortar and bricks (cimento e tijolo), como
são denominadas as lojas físicas no mundo virtual. Assim, um dos pontos que alavanca-
ram essa consolidação foi a necessidade de ter uma visão mais integrada dos hábitos dos
seus consumidores, independentemente de serem alunos, clientes digitais ou público
em geral. Uma das primeiras ações da BN foi oferecer um aplicativo para os portadores
de leitores digitais de documentos. O aplicativo pode ser baixado da web, e com ele os
clientes podem, estando em uma loja da BN, fotografar uma capa de livro na estante e
receber imediatamente um conjunto de informações a respeito dele. Todas as lojas têm
Wi-Fi gratuito. Se o cliente se apresentar numa das cafeterias do Starbucks, integrada
fisicamente às lojas da BN, com o seu aparelho leitor (que pode ser Ipod, Ipad, Android
etc.), comprovando o uso do aplicativo BN, ganha um café grátis. Esses pequenos gra-
cejos de marketing na realidade demonstram a estratégia da gigante em se aproximar

310
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

dos portadores de leitores digitais para se insinuar com o seu produto próprio (NOOK),
ainda distante da preferência do público, quando comparado com IPAD e outros. Para
não falar dos milhares de títulos digitais já disponíveis, que eles, claro, desejam que sejam
lidos no seu Nook. O nome do produto, aliás, se lido em duas sílabas, significa “não
OK”, em inglês. Vá entender um produto que sugere, pelo nome, algo assim...
Uma empresa também pouco conhecida dos brasileiros é a Acxion. Ela gerencia
cerca de 20 bilhões de registros sobre consumidores, com um acervo de aproximada-
mente 850 TB. Juntamente com a ChoicePoint, atua no ramo de coleta, integração e
armazenamento de dados de consumidores num nicho de negócios denominado in-
teligência privada, que suporta diversos projetos de empresas particulares e de agências
do governo. Recentemente adquirida pela gigante Reed Elsevier, a ChoicePoint tem
algo estimado em 250 TB, nos quais armazena informações sobre mais de 200 milhões
de residentes nos Estados Unidos. Ambas (Acxion e ChoicePoint) são as empresas mais
“desconhecidas” do planeta, mas englobam um oceano de informações.
O YouTube, com o maior banco de vídeos do planeta, em que 65 mil vídeos no-
vos são colocados por dia, deve ter na faixa de mais de 100 TB, com previsão de dobrar a
cada cinco meses. O site Amazon, maior vendedor do varejo on-line do planeta, tem 60
milhões de registros de clientes, com volume aproximado de 50 TB. Embora a camada
dos petabytes ainda não esteja densamente preenchida, a perspectiva de crescimento é
que assusta. Em pesquisas do TDWI (The DataWarehouse Institute), 46% das empresas
respondentes disseram que vão substituir as suas plataformas de DW, esperando por
maiores crescimentos.
Essas unidades padrão, na realidade, são definidas pelo The International Bureau
of Weights and Measures. Os prefixos definidos dentro do padrão são mostrados na
Tabela 11.1.

TABELA 11.1

UNIDADE TAMANHO (*) SIGNIFICADO


Binary digit. Tem valor 1 ou 0 e é
o código usado para representar a
Bit Menor unidade digital
menor unidade de armazenamento
digital
Suficiente para armazenar uma letra
Byte 8 bits nos alfabetos (single-character) ou
um número
O nome se origina de thousand, em
grego. Uma página de texto normal-
Kilobyte (KB) 1.024 ou 2**10 bytes
mente tem 2 KB

O nome se origina de large, em


grego. Todo o trabalho de William
Megabyte (MB) 1.024 KB ou 2**20 Shakeaspeare totaliza 5 MB e uma
canção pop típica tem 4 MB

311
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

O nome se origina de giant, em gre-


go. Um filme de duas horas pode ser
Gigabyte (GB) 1.024 MB ou 2**30
armazenado de forma comprimida
em 1-2 GB
O nome se origina de monster, em
grego. Todos os livros catalogados
Terabyte (TB) 1.024 GB ou 2**40
na Biblioteca do Congresso america-
no totalizam 15 TB
Todas as cartas que circularão pelo
serviço postal dos Estados Unidos
Petabyte (PB) 1.024 TB ou 2**50 em 2010 totalizarão 5 PB. O Google
processa cerca de 1 PB por hora de
informação
Equivale a 10 bilhões de cópias do
Exabyte (EB) 1.024 PB ou 2**60
The Economist
A quantidade total de informação
existente até este ano está previs-
Zettabyte (ZB) 1.024 EB ou 2**70
ta em torno de 1,2 ZB (definido em
1991)
Impossível de imaginar (definido em
Yottabyte (YB) 1.024 ZB ou 2**80
1991)

Fonte: The Economist: All too much. Monstrous amount of data (25/2/10). Disponível em:
http://www.economist.com. Acesso em: 9 ago. 2010.

(*)Existem dois padrões atualmente relacionados com os valores acima citados: O SIU
(Sistema Internacional de Unidades, que usa a base decimal) e o definido pela CEI
(Comissão Eletrotécnica Internacional, que usa a base binária). A expressão dessas uni-
dades em bases diferentes produz certa imprecisão, pois pela CEI, 1TB=1.024GB, e
para o SIU 1TB=1.000GB. Objetivando uma compatibilização há uma proposta de novos
nomes para as unidades em base binária: Mebibytes(MiB)-Gibibytes(GiB)-Tebibytes(TiB)-
Pebibytes(PiB)-Exbibytes(EiX)-Zebibytes(ZiB)-Yobibytes(YiB). Assim teríamos o Terabyte bi-
nário, por exemplo, que se chamaria Tebibyte(TiB), diferenciado do Terabyte decimal. No
entanto, ambos continuam plenamente aceitos e entendidos de forma intercambiada, até a
consolidação total dos conceitos.

ALGUMAS RELAÇÕES DE CAUSA E EFEITO DOS ZETTABYTES


SOBRE A SOCIEDADE
Com o crescente volume de dados, obtido de formas variadas através das quais
uma pessoa tangencia a sociedade digital, certos aspectos deverão ser pensados.
Privacidade: é um dos fatores que mais geram apreensão na sociedade digital,
à medida que as empresas acumulam, cada vez mais, informações a nosso respeito.
Estamos presentes em diversos cadastros de empresas com as quais nos relacionamos,
e rastreadores digitais sabem muito das nossas pegadas nas trilhas virtuais pela internet,
por onde circulamos. Se, por um lado, estamos com preocupação crescente com os
nossos dados e a sua integridade e privacidade, por outro lado, num rebote paradoxal,
estamos cada vez mais nos expondo através das redes sociais, nas quais expressamos
nossas opiniões, nossos sentimentos, apreensões e preferências, algumas na fronteira
da indiscrição. As redes sociais se transformaram numa espécie de grandes vitrines da

312
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

nossa alma. Enquanto esse ponto pode ser visto como estando sob nossa gerência, à
medida que controlamos nossa exposição via mecanismos de maior discrição, a massa
de informação imperceptível que produzem a nosso respeito é algo bem mais sério.
Até porque pouco se pode fazer diretamente sobre isso. Em todo ato de compra, no
mundo físico ou digital, em cadastramentos, buscando uma newsletter que nos interessa
ou na conversão de créditos em milhagem, sempre somos instados a prover certos
dados do nosso domínio pessoal. E para isso existe pouco espaço para manobras a
nosso favor. A menos que sejam reconhecidos os direitos de propriedade sobre os
nossos dados e que nos seja dado o direito de sabermos sobre eles e de podermos
definir sobre sua utilização, seu compartilhamento, sua manutenção e eliminação.
Essa tendência, ainda incipiente, poderá ser mudada através de legislações mais rigo-
rosas a respeito de propriedade de dados. Há espaço ainda para o amadurecimento
disso na sociedade digital. Enquanto as leis não são criadas ou não vinguem quando
forem, mecanismos de tecnologia podem ser desenvolvidos para tal. Recentemente
foi lançada uma empresa norte-americana cujo objetivo é a criação de um plug-in
de browser que toca nesse domínio de privacidade, jogando a favor do internauta. A
empresa, com o sugestivo nome de Bynamite, intenciona criar mecanismos para que
você saiba como os diversos rastreadores digitais acompanham seus passos, coletando
informações sobre as formas pelas quais você está sendo observado. Por exemplo, se
você navega no Google, colocando na caixa de pesquisa as palavras-chave “bateria
para Ipod”, está gerando algum valor para algumas empresas que poderão lucrar com
aquela informação. As empresas de marketing digital, de certa forma, capturam isso
e ficam sabendo do seu interesse pelo tocador de músicas da Apple. Isso associado
ao seu cookie vai para um BD dessas empresas. A ideia do Bynamite é coletar essas
percepções e deixar disponível para você aquilo que sabem a seu respeito, de forma
que você poderá transformar essa informação em ativos de sua propriedade. Ou seja:
essas informações sobre suas andanças pela internet são suas e lhe pertencem. Em
resumo, se você circula pela internet e os sites por onde passa estão sob a mira de um
desses ad networks, como Doubleclick (hoje do Google, por US$3,1 bilhões), os seus
passos serão registrados sob a identificação de um cookie, por exemplo. Dessa forma,
você estará fornecendo informações a esses observadores digitais sobre o seu hábito.
De posse dessas informações que são suas, essas empresas comercializam os outdoors
digitais. São empresas que colocam ads (propagandas digitais) nas páginas e, quando
você abre determinado site, alcançam diretamente você. Aqueles ads são colocados ali
exatamente pela probabilidade de seu interesse pelo assunto, capturado pelos seus mo-
vimentos anteriores. Esses outdoors digitais serão remunerados caso você clique nele
e entre num site que venda aquilo ou, mais ainda, caso uma venda seja concretizada.
Resumindo: alguém usou as suas informações de hábitos de circulação na internet e
as vendeu, ganhando algum dinheiro.
O site Bynamite tem a perspectiva inicial de dar a você o conhecimento desse
ativo que é seu (ou seja, as informações sobre por onde você passou) e espera que, com
a maturidade da sociedade digital, você possa negociar esse ativo com alguém que
ganha algum dinheiro com ele. Em última análise, caso você não bloqueie os cookies
ou os ads de sua máquina, o que causa inconveniência na navegação, pelo menos terá

313
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

uma moeda de troca, podendo negociar um ativo que é seu. A propósito, um estudo
denominado “What is privacy worth?” (“Quanto vale a privacidade?”), de um grupo
de pesquisadores da Universidade de Carnegie Mellon, apresenta experimentos sobre
a tentativa de medir a valoração que damos à privacidade dos nossos dados. Nele, há
um relato de experimento realizado num shopping center, sendo que dois grupos de
pessoas foram selecionados para participar. A um dos grupos foi oferecido um con-
junto de cartões de US$12 (gift cards) que poderiam ser usados na compra de qualquer
coisa, desde que os compradores fossem identificados e as compras fossem associadas a
eles. A outro grupo separado foi dado um conjunto de cartões de US$10 que pode-
riam ser usados de qualquer forma e sem nenhuma identificação do comprador nem
dos produtos comprados. Ou seja: um grupo ganha mais, porém tem de revelar as
suas compras, e outro ganha menos, mas permanece anônimo. Ao grupo que recebeu
os cartões de US12 e que teria de se expor nas compras foi oferecida a troca pelos
cartões de US$10 anônimos. Somente 10% dos participantes do grupo aceitaram sair
da exposição remunerada. O grupo que recebera os cartões anônimos de US$10,
quando feita a proposta de troca, aceitou em 50%, preferindo a metade permanecer
no anonimato. A conclusão a que se chegou nesse experimento é que tudo depende
da condição inicial em que nos encontramos. Se estamos numa condição psicológica
em que entendemos que há uma inevitável exposição dos nossos dados, a tendência é
que permaneçamos nessa zona de desconforto, em que todos se encontram também,
ancorados no sentimento de que o mal é para todos. Caso estejamos envoltos numa
condição psicológica que nos sugere conforto e proteção dos nossos dados, tendemos
a mantê-la. Os detalhes estão no artigo de Alessandro Acquisti, Leslie John e Ge-
orge Lowenstein que pode ser acessado em www.heinz.cmu.edu/~acquisti/papers/
acquisti-privacy-worth.pdf.
Esse conceito de propriedade de dados, ou de que os dados recolhidos pelo
“business” pertencem aos clientes e que devem ser disponibilizados, tem produzido
movimentos interessantes. Em março de 2011, na Inglaterra, o governo anunciou uma
iniciativa denominada “Mydata”, que exigirá que os dados já providos pelas compa-
nhias a respeito de seus consumidores e consumos também o sejam na forma digital.
O Governo Britânico já discute com vários bancos, operadoras de cartão de crédito,
de celulares etc. para darem início ao programa. Estudos provam, por exemplo, que a
mudança de plano usado hoje por clientes de celulares pode produzir, na média, uma
economia de US$300. Para tal, seria importante que se conhecesse o detalhe de seus
itens de consumo, o que nem sempre está claro nas faturas. Isso poderia estar associado
a um alerta sobre a adequação do seu perfil ao plano escolhido, caso a empresa fosse
mais sensível aos aspectos de “reciprocidade”. Caso contrário, com os dados passados na
forma digital, você poderia, por exemplo, usar certos sites, como BillShrink.com, cujo
objetivo é justamente analisar e sugerir os melhores planos para você.
Segurança: enquanto a privacidade está, de certa forma, nos domínios do
nosso arbítrio, os aspectos de segurança tocam em pontos relativos a invasões ou va-
zamentos de sites e de cadastros por pessoas interessadas em utilizar para o mal suas
informações sensíveis, como cartões de créditos, CPF etc. Nesse caso, a responsabili-
dade muda de lado e é transferida para a empresa que mantém suas informações sob

314
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

guarda. Os movimentos aqui também passam por legislações específicas, além dos
óbvios embates jurídicos de direito à privacidade e de eventuais ressarcimentos por
perdas originadas por mau uso de suas informações. Como as ameaças de quebra de
segurança e suas ocorrências são normalmente mantidas sob certo segredo, na medida
em que revelam fragilidades estruturais de sistemas, alguns estados e países estão defi-
nindo leis que obrigam que esses eventos sejam trazidos a público. Por exemplo, existe
uma lei pioneira na Califórnia, criada em 2003, que obriga que todas as invasões ou
quebras de segurança sejam notificadas a todos os que, de certa forma, poderiam ser
prejudicados pelo potencial dano oriundo daquele fato. Essa mesma lei está sendo
aplicada em outros estados americanos. Além disso, há ideias sobre extensões à lei que
obrigariam as empresas a realizar auditorias de seguranças periódicas, feitas por tercei-
ros credenciados. Isso serviria como elemento de mitigação desses riscos. No Brasil, o
vazamento de informações privadas durante períodos eleitorais tem se tornado uma
prática preocupante que fragiliza as instituições responsáveis por sua guarda. Em 2006
foi vazado o sigilo bancário da CEF de um caseiro de Brasília e, em 2010, foram va-
zados os dados da SRF de um político da oposição e da filha de um candidato. Além
disso, o jornal O Globo, de 23/8/2010, traz em sua página principal uma manchete
preocupante: “Dados pessoais sigilosos são vendidos nas ruas de São Paulo.” A repor-
tagem conseguiu comprar, na rua Santa Ifigênia, reduto do comércio eletrônico de
São Paulo, dois CDs contendo informações completas sobre veículos e proprietários
oriundas do Denatran (Departamento Nacional de Trânsito) e dados bancários de
pensionistas do INSS (Instituto Nacional de Seguridade Social). Os dados dos pen-
sionistas continham CPF, número do benefício, endereço e telefone. Também foram
oferecidos ao repórter os dados bancários de correntistas das regiões Sul e Sudeste de
um dos maiores bancos privados do Brasil. Na mesma semana, no dia 26/8/2010, a
Superintendência da Receita Federal, órgão que retém informações de alta privaci-
dade, vem a público e reconhece as suas fragilidades, sugerindo a existência de uma
“rede interna” entre seus colaboradores visando à compra e à venda de informações
sobre contribuintes. No dia 1/9/2010, a Folha de S. Paulo divulgou, na página A7,
uma notícia sobre a prisão de um camelô, nas imediações da rua Santa Ifigênia, que
vendia CD com dados sigilosos da Receita Federal. Por R$1 mil era possível adquirir
o CD, que continha os dados fiscais dos contribuintes e a sua restituição. Os dados
fiscais somente eram abertos com uma senha de 12 dígitos, que era fornecida junta-
mente com o CD. O vendedor também oferecia CD com informações da Infoseg,
rede do Ministério da Justiça, com informações criminais do Brasil, como mandados
de prisão e do Detran (Departamento Estadual de Trânsito). Como se não bastasse,
no dia 21/12/2010, o site do Estado de S. Paulo (Estadão.com.br) divulgou matéria
sobre hackers que fizeram empréstimos junto ao Banco Panamericano, em nome do
presidente Luiz Inácio Lula da Silva, com dados obtidos ilegalmente do sistema de
informática da Previdência Social. Outro ponto importante que deverá ser também
discutido definirá o tempo de retenção dos nossos dados nos diversos arquivos nos
quais somos registros ou tuplas. Esse ponto, de certa forma, tenta mitigar a janela de
exposição dos nossos dados. Em países como Estados Unidos e em alguns da Europa,
esses assuntos já estão bem mais maduros. Em maio de 2010, conforme noticiou o

315
BI2 – B USINESS I NTELLIGENCE : MODELAGEM E QUALIDADE I C ARLOS B ARBIERI

IDC, as maiores empresas de buscadores (Google, Microsoft e Yahoo) foram notifica-


das sobre as regras que definem o tempo máximo de retenção das informações co-
letadas pelos buscadores. Segundo a notificação, feita pelo Corpo de Conselho sobre
proteção de dados da União Europeia (European Union’s Data Protection Advisory
Body), pelo artigo 29, as empresas estavam retendo tais informações por mais de seis
meses, com algumas delas retendo por mais de 18 meses. As informações retidas con-
tinham detalhes de termos pesquisados, estampa de tempo, o endereço IP do cliente,
o browser, além do sistema operacional e da linguagem adotada. O Google, naquele
momento, mantinha os dados por nove meses e depois obscurecia o último octeto do
endereço IP. Também os cookies eram mantidos por 18 meses. A legislação da União
Europeia não define explicitamente o tempo de retenção dos dados, mas deixa para
que cada país, através dos seus conselhos de proteção à privacidade dos dados, o defi-
na. Por outro lado, a legislação americana (Electronic Communications Privacy Act of
1986 – ECPA) não foca o mesmo aspecto de limitar a retenção dos dados, até porque
os dados mantidos nesses volumes podem ajudar na detecção de terroristas e outras
ameaças, da forma como aconteceu após o 11 de setembro. Os americanos somente
dispõem de regulações a respeito de dados mantidos pelo governo e suas agências,
não sendo estendidos às empresas privadas, com o mesmo rigor. Esse assunto sobre
retenção de dados e outros aspectos sobre os cuidados com a memória infinita da in-
ternet é discutido com maior profundidade no livro Delete, the virtue of forgetting in the
digital age, de Viktor Mayer-Schonberger, publicado pela Princeton University Press.
No livro, Schonenberger cita exemplos como o de Stacy Snyder, de 25 anos, mãe
solteira, que embora tenha ganho todos os créditos suficientes e passado por todas as
etapas de seleção de uma escola, não foi aprovada como professora. Explicação: seu
comportamento, digamos digital, era incompatível com o papel de uma professora. O
seu retrato publicado na internet, anos atrás, fantasiada de pirata, estava no MySpace e
inocentemente rotulado como “pirata bêbada” pelos seus amigos. A argumentação da
comissão que analisou a sua inscrição era que sua foto era incompatível com a posição
que pleiteava. Stacy havia caído na armadilha inconsciente da internet, que tudo vê
e tudo grava, principalmente quando você não se preocupa com seus rastros digitais.
Aquilo havia sido catalogado pelas máquinas de buscas e descoberto por alguém. Ela
havia se esquecido de deletar algo que a internet se lembrou, com a sua memória
infinita.
Além dela, Andrew Feldmar, um psicoterapeuta canadense, na faixa de 60 anos,
morador de Vancouver, também pagou caro pelo esquecimento de deletar. Em 2006,
ele ia buscar um amigo no aeroporto de Seatle-Tacoma e teve de atravessar a fronteira
CanadáEstados Unidos, como já havia feito inúmeras vezes. Dessa vez, um guarda de
fronteira resolveu verificar a internet, além dos documentos tradicionais. De repente,
apareceu um artigo que ele havia escrito em 1961, contando sua experiência com
LSD, em 1960. Ficou preso por 4 horas, impressões digitais tiradas, e depois de assinar
um documento que declarava a sua experiência com droga naquele episódio, ficou
sem permissão de entrar novamente nos EUA, ou seja, um ato distante e relativamente
pequeno, nos anos 60, registrado na memória eterna da internet, mudou a sua vida.
Um artigo antigo, escrito num obscuro newspaper, havia ficado retido nas memórias

316
ELSEVIER
C APÍTULO 11 I BI2 – N OVAS TENDÊNCIAS NA APLICAÇÃO DE INTELIGÊNCIA DE NEGÓCIOS

da rede, apontando que a pegada digital que você deixa nela pode ficar para sempre.
Na cidade alemã de Eisenach fica MAD, uma megadiscoteca com espaço para quatro
mil pessoas. Quando alguém entra no seu ambiente, tem de mostrar o passaporte ou o
cartão de identificação emitido pelo governo alemão.Todos são colocados num banco
de dados, com uma foto. Além disso, os convidados recebem um cartão especial para
pagar os drinques e comidas no MAD. Cada transação dessas é registrada no mesmo
banco de dados, associada ao registro digital do convidado. Em 2007, o BD do MAD
continha informações sobre mais de 13 mil indíviduos e milhões de transações de
consumo. Além disso, 60 câmeras digitais continuamente monitoram todo o ambien-
te, acumulando uma memória digital estimada, hoje, em 8 mil GB. A informação em
tempo real, dos consumidores e de seus hábitos de consumo noturno, é mostrada
numa sala de controle, sendo que a polícia tem acesso direto a todo os rastros digitais
dos clientes.

Human bits
Se não percebeu ainda, você está sendo observado e transformado em bits:
de agora em diante, cada vez mais o nosso cotidiano estará sendo codificado nessas
simples unidades binárias. Câmeras de vigilâncias em aeroportos, metrôs, ruas e boates
estão registrando os bits que traduzem nossos gestos, movimentos e feições.Tudo com
a velha máxima de saborear as vantagens e lamentar as desvantagens. Na Califórnia,
no início de 2011, foi inaugurado um estacionamento que monitora, via câmera, cada
carro em cada vaga. Através disso, as placas são transformadas em informações que vão
para um sistema de banco de dados, que facilita a localização do seu carro, além de
permitir um analytics sobre o movimento do estacionamento. Ao lado do quiosque
de pagamento, existe um monitor onde você digita a placa e recebe a localização
perfeita da vaga onde estacionou, evitando a memorização de cores, números, letras
etc. Assim, as táticas furtivas de deixar carros em estacionamento de shopping com
fins inconfessáveis podem estar com seus dias contados. O berçário onde meu neto
fica, em Santo André, tem câmeras que me permitem vê-lo, via Web, nos intervalos
das minhas consultorias, acessando o site da escolinha. Pontos para a tecnologia dos
baby bits. Quando sair de casa, você poderá ser flagrado pelas câ