Manual Business Intelligence

7/27/2019 Manual Business Intelligence

1/160

Business Intelligence


2/160

F I C H A T C N I C A

T t u l oBUSINESS INTELLIGENCE

A u t o r e sCarlos Sezes, Jos Oliveira e Miguel Baptista

E d i t o r SPI Sociedade Portuguesa de Inovao

Consultadoria Empresarial e Fomento da Inovao, S.A.

Edifcio Les Palaces, Rua Jlio Dinis, 242,

Piso 2 208, 4050 PORTO

Tel.: 226 076 400, Fax: 226 099 164

[email protected]; www.spi.pt

Porto 2006

P r o d u o E d i t o r i a lPrincpia

Av. Marques Leal, 21

2775-495 S. Joo do Estoril

Tel.: +351 214 678 710; Fax: +351 214 678 719

[email protected]

www.principia.pt

P r o j e c t o G r f i c o e D e s i g n Mnica Dias

I m p r e s s oRolo e Filhos, Artes Grficas, Lda.

I S B N 972-8589-66-2

D e p s i t o L e g a l 249614/06

Pro jecto apo iado pe lo Programa Operaciona l P lur i fundos da

Regio Autnoma da Madeira (POPRAMIII), co-financiado pelo

Estado Portugus, e pela Unio Europeia, atravs do Fundo

Social Europeu.


3/160

NEGCIO ELECTRNICO

Business Intelligence

Carlos Sezes | Jos Oliveira | Miguel Baptista


4/160


5/160

I N T R O D U O

BUSINESS INTELLIGENCE

R

Realizar um manual didctico sobre as tecnologias de business intelligence , na

actualidade, um desafio motivador mas, inequivocamente, difcil e complexo. Com efeito, a

diversidade de reas abrangidas pelo conceito de business intelligence aliada intensida-

de das mutaes e dos aperfeioamentos tecnolgicos que, no passado recente e no pre-

sente, caracterizam esta temtica tornam extremamente difcil produzir algo completo e

definitivo. Terminado este manual, ficar inevitavelmente a sensao de que algo ficou

esquecido ou de que alguma matria concreta j estar desactualizada relativamente a

novas prticas e novos modelos, que emergem continuamente no mercado internacional.

Convm, no entanto, como introduo e sem entrar em pormenores desenvolvidos

mais adiante, focar um pouco as caractersticas e especificidades deste conceito.Em primeiro lugar, business intelligence refere-se simbiose entre gesto e tecnolo-

gia. No existe como tecnologia isolada dos processos estratgicos que se desenvolvem

no seio de qualquer organizao. Como tal, foi nossa preocupao, ao longo de todo o

manual, no focar apenas os sistemas de informao, suas arquitecturas e seu modus

operandi, mas referir tambm os contextos de negcio, as metodologias e os modelos de

gesto em que a tecnologia est inserida e que, supostamente, ir apoiar. Assim, no

querendo entrar num nvel de complexidade tcnica desajustado dos objectivos e dimen-

ses deste manual, preferimos enfatizar o contributo destes sistemas de informao espe-

cficos para as diversas necessidades de gesto.

Em segundo lugar, business intelligence um processo produtivo cuja matria-prima

a informao e o produto final o conhecimento. Tudo se baseia, portanto, em planear,

gerir e controlar a informao de forma a criar e a distribuir conhecimento de forma

optimizada. No mundo actual (empresarial e no s), em que a informao um recursoquase ilimitado, esta tarefa assume-se como essencial. E a presso para a obteno deste

conhecimento oportuno e fivel j no apenas endgena, mas tambm exgena, alarga-


6/160

da ao meio envolvente da empresa. De facto, as exigncias dos designadosstakeholders

(os interessados clientes, fornecedores, investidores, media, pblico em geral) esto a

atingir nveis inusitados, obrigando as organizaes modernizao dos seus processos

esta realidade visvel nas modernas abordagens de corporate governance, perfor-

mance management e risk management.

Por ltimo, de sublinhar que a implementao de um projecto de business intelligen-

ce hoje uma deciso crtica e complexa, que deve ser gerida com o mximo rigor. Desde

o momento em que se estudam as necessidades e a justificao de implementao, pas-sando pela avaliao previsional da sua rendibilidade, at ao processo de implementao

no terreno, so necessrias competncias significativas de gesto de projectos, gesto

do risco e gesto da mudana para que o resultado seja, de facto, o esperado. A partir

desta premissa, compreende-se facilmente o destaque dado neste manual ao estudo, im-

plementao e controlo de projectos, com dois captulos consagrados a estas questes.

Em sntese, o presente manual de business intelligence pretende ser uma iniciao

para todos os interessados nesta temtica, baseada numa anlise generalista, abarcando

os contedos tericos essenciais, mas no se inibindo de perspectivar novas tendncias

que o futuro prximo, em nossa opinio, se encarregar de validar.

CARLOS SEZES, JOS OLIVEIRA E MIGUEL BAPTISTA


7/160

Apresentaoe Conceito

Compreender o conceito de business intelligence e a sua importnciano contexto da gesto empresarial actual

Assimilar os principais objectivos e vantagens competitivas dabusiness intelligence como ferramenta de suporte tomada dedeciso

O B J E C T I V O S

1C A P T U L O


8/160

8


ENQUADRAMENTO

O conceito de business intelligence um conceito lato e generalis-

ta (cuja definio propomos mais adiante), hoje relacionado com umadeterminada categoria de processos de negcio, aplicaes desoftwa-re e tecnologias especficas. As suas metas fundamentais so, generi-camente, recolher dados, transform-los em informao (atravs dedescoberta de padres e tendncias) e, sequencialmente, informaoem conhecimento til e oportuno para a tomada de deciso.

Se quisermos fazer uma pequena resenha histrica deste tema, te-remos de recuar s origens e passar pelas diversas evolues do con-ceito de estratgia. Com efeito, intelligence remete imediatamente

para a noo de informao privilegiada enquanto vantagem competi-tiva sobre um oponente e determinante para o sucesso de qualquerestratgia.

Desde as primeiras linhas escritas sobre estratgia, de Sun Tzu (AArte da Guerra, h 2500 anos), passando por Maquiavel (sculosXV-XVI) at Clawsewitz (sculo XIX), patente a preocupao de,em face de determinado contexto de conflito, conhecermos da formamais exacta possvel os nossos pontos fortes e fracos, bem como os

dos nossos adversrios (no caso empresarial, concorrentes), e, empormenor, as vrias especificidades do terreno em que nos movemos(por analogia, o mercado e sua envolvente). As vrias abordagensmodernas de anlise estratgica surgidas no meio empresarial (a an-lise SWOT strenghts, weaknesses, opportunities, threats ou aanlise da indstria as cinco foras de Michael Porter) so evo-lues naturais das mais antigas concepes nesta rea. Em suma,num contexto concorrencial, conhecimento vantagem.

Antes do advento da automatizao e informatizao do processa-mento, a informao era tratada de forma avulsa e no estruturada,pelo que as decises tomadas a jusante tinham sempre um elevadocomponente de intuio. Com os primeiros computadores (os enor-mes e clebres mainframes, na dcada de 1960), iniciaram-se as pri-meiras tarefas a nvel de automatizao e armazenamento. Contudo,

para alm das naturais velocidades baixas de processamento, haviaproblemas notrios a nvel da falta de infra-estruturas de conexo paratroca de dados ou da incompatibilidade entre sistemas. Simples re-

portings baseados nesses dados poderiam demorar semanas ou mes-mo meses a ser elaborados.

No entanto, como do conhecimento de todos, os desafios coloca-dos s empresas nos ltimos anos elevaram a fasquia no que diz res-


9/160

CAPTULO 1 APRESENTAO E CONCEITO

9

peito aos sistemas e competncias de gesto. Vrias tendncias tmsido evidentes:

Grande intensidade concorrencial da maior parte dos merca-

dos; Exigncia de padres de qualidade cada vez mais elevados dos

produtos/servios de cada oferta;

Necessidade de conhecer mercados e clientes cada vez maissegmentados e especficos;

Necessidade de racionalizar processos internos e reduzir cus-tos operacionais;

Imperativo de avaliar, em tempo real, aperformance das orga-nizaes, de forma a ter capacidade de decidir em tempo til;

Necessidade de conhecer, controlar e minorar os riscos de ne-gcio associados a cada actividade.

A exigncia e a complexidade tecnolgica acompanharam estesnovos imperativos e tendncias. As informaes produzidas e as ba-ses de dados dos negcios/actividades esto a crescer a ritmo expo-nencial. Os sistemas ERP (enterprise resource planning), CRM(customer relationship management), SCM (supply chain mana-

gement), data warehouses e Internet esto constantemente a ofere-cer informaes aos gestores; , pois, necessrio transformar dadosem conhecimento.

Por ltimo, hoje notrio que as empresas se tornaram mais hori-zontais, menos hierarquizadas; as tendncias de downsizinge o cor-respondente empowerment (mais autonomia de deciso nos nveisoperacionais) pressupem a disseminao da informao crtica juntode mais colaboradores/decisores.

Todas estas contingncias obrigam a prestar uma ateno redo-brada ao processo de controlo interno, de gesto daperformance (depreferncia, em tempo real) e aos sistemas de informao para su-porte deciso; em sntese, torna-se fundamental aprimorar a ligaoda estratgia execuo, facilitando assim o ciclo de gesto (planear

dirigir monitorizar avaliar reportar), atravs do alinhamento da

organizao na prossecuo dos seus objectivos e de uma maior trans-parncia dos seus processos de negcio.

Os sistemas de business intelligence so, na actualidade, os cata-lisadores da mudana, permitindo concretizar na prtica estas novas


10/160

10


abordagens de boa gesto e de bom governo das empresas. Deuma forma eficaz, pelo diagnstico, anlise, acessibilidade, partilha ereportingde dados, possvel aos gestores perceber o que essencialno seu negcio e transformar os enormes mananciais de informao

em conhecimento til, oportuno e fivel. E, como natural, transformaresse conhecimento em resultados, para que as empresas possam pas-sar da eficincia operacional eficcia corporativa. Podemos entoavanar com uma proposta de definio do conceito:

Business intelligence conceito que engloba um vastoconjunto de aplicaes de apoio tomada de deciso quepossibilitam um acesso rpido, partilhado e interactivo dasinformaes, bem com a sua anlise e manipulao; atra-

vs destas ferramentas, os utilizadores podem descobrirrelaes e tendncias e transformar grandesquantidadesde informao em conhecimento til.

Como se percebe pelo que foi aqui referido, a existncia de siste-mas de BI justificada pela sua adequao s vrias realidades davida das empresas e de outras organizaes. Existe hoje um conjuntode processos de negcio e actividades crticas no modelo de cadaempresa e na sua respectiva cadeia de valor, em que a obteno deconhecimento especfico essencial para os processos de deciso.As realidades funcionais mais relevantes neste contexto, que depoisso materializadas em diversos processos de negcio, esto elenca-das no quadro abaixo:

Comercial

Anlise do comportamento do consumidor Anlise da rendibilidade de consumidores/segmentos

Anlise de cross-selling

Anlise da fora de vendas

Anlise dos canais de distribuio

Marketing

Penetrao no mercado/segmentos

Eficcia das campanhas de marketing(anlise de meios)

Anlise do ciclo de vida do produto/servio

Finanas

Previso, planeamento e oramentao

Anlise de performance

VALOR ACRESCENTADO DA TECNOLOGIA BUSINESS INTELLIGENCE APLICAES FUNCIONAIS NAS EMPRESAS

Consolidao financeira

Reporting financeiro

Operaes/Logstica

Eficincia operacional

Planeamento da produo

Controlo de qualidade

Anlise da cadeia logstica

Recursos Humanos

Planeamento da afectao de recursos

Avaliao de performance

Anlise da compensao

Avaliao de competncias


11/160


11

Numa primeira sntese, os sistemas de business intelligence tmem comum um conjunto de importantes objectivos fundamentais:

Acesso a dados fiveis a fiabilidade dos dados, a sua fcil inte-

grao e compreenso entre reas essencial para um exerccioconsciente da gesto;

Aumento da transparncia e compreenso do negcio a disponibi-lizao de conhecimento em tempo real (o qu, o quanto, o quan-do, o onde e o como) permite aos gestores e decisores ter uma

perspectiva das reas que devem controlar com total transparncia eaumentar a sua capacidade de compreenso (o porqu);

Suporte para a tomada de deciso s uma compreenso oportuna

da realidade pode permitir tomadas de deciso eficazes; como tal, oconhecimento produzido pelos sistemas de BI, potenciados pelas tec-nologias de comunicao actuais, deve suportar e justificar as medi-das tomadas pelos vrios intervenientes no processo de gesto.

ARQUITECTURAE CARACTERSTICASDE UM SISTEMADE BI

Um sistema de business intelligence, encarado na perspectiva dasua vertente tecnolgica, deve ser enquadrado na infra-estrutura glo-

bal dos sistemas de informao da organizao.Por um lado, devemos ter sempre em mente que um sistema de BI

no subsiste por si prprio est ligado, de forma umbilical, s fontes

de dados subjacentes, sejam elas os sistemas transaccionais ou osficheiros de suporte; enfim, tudo o que se possa considerar um reposi-trio primrio de informao resultante dos processos de negcioda organizao.

Por outro lado, a jusante, necessrio perceber a interaco entreo conhecimento produzido e os seus destinatrios (utilizadores finais),que, atravs dos vrios interfaces e ferramentas de visualizao, ti-ram partido do que foi produzido, filtrado e sintetizado.


12/160

12


Figura 1.1Estrutura tpica esimplificada de umsistematecnolgico debusiness

intelligence

Um sistema-padro de business intelligence, portanto,composto pelos seguintes elementos:

Mdulo de ETL (extraction, transformation and loading) Componente dedicado extraco, ao carregamento e

transformao de dados. a parte responsvel pela recolhadas informaes nas mais diversas fontes (sistemas ERP, ar-quivos TXT ou ficheiros Excel);

Data warehouse/Data marts Locais onde ficam concen-trados todos os dados extrados dos sistemas operacionais.A grande vantagem de ter um repositrio de dados separadoconsiste na possibilidade de armazenar informaes histri-cas e agregadas, construindo assim um melhor suporte paraas anlises efectuadas a posteriori;

Front-end Parte de um projecto de BI visvel ao usurio.

Pode consubstanciar-se em forma de relatrios padronizadose ad hoc, portal de intranet/Internet/Extranet, anlise OLAP efunes diversas como data miningou forecasting(projecesde cenrios futuros baseados em determinadas premissas).

Todos estes componentes e respectivos subcomponentes seroanalisados, em pormenor, mais adiante.

PROPOSTAS DE VALOR E VANTAGENS COMPETITIVASDE UM PROJECTO DE BI

Implementar um projecto de business intelligence constitui, paraa organizao que o promove, um investimento consubstanciado em


13/160


13

fortes vantagens competitivas e diversas na forma de gerir a informa-o de base e o conhecimento. Estas vantagens devem ser objecto deuma viso incremental: devem ser aprimoradas gradualmente com vistaa conceder aos decisores novas capacidades de anlise e um valor

crescente em termos da obteno de matria-prima de suporte tomada de deciso. Em sntese, cumprir a promessa essencial dasimplementaes de business intelligence: entregar a informao certa, pessoa certa, no tempo certo potenciando as melhores decisescom a melhor relao custo-benefcio. As suas propostas de valor

podem sintetizar-se nas seguintes evidncias:

Primeira evidncia Um projecto de BI permite a aquisio de

competncias distintivas ao nvel da modelizao da informao.Os projectos de business intelligence permitem a definio de

modelos e princpios de definio, inventrio, converso e distribuioda informao, com vista a assegurar a coerncia e a pertinncia doconhecimento criado. Este processo de modelizao prossegue numciclo de etapas variadas, em que a identificao dos factores funda-mentais para o sucesso acompanhada pelo necessrio feedback

proveniente da perspectiva conjunta dos profissionais das tecnologias

de informao e dos utilizadores finais, orientados ao negcio.Poder-se- assim assegurar que cada etapa do processo de mode-

lizao da produo de informao decorre com nveis mximos deeficincia, tendo em conta a infra-estrutura subjacente.

Figura 1.2O processo demodelizao dainformao


14/160

14


Segunda evidncia Os projectos de BI graduais constituembenchmarks para optimizar a informao organizacional.

medida que avanamos na busca de um conhecimento organizacio-

nal, multidimensional e optimizado, os projectos de BI permitem um melhoraperfeioamento dos processos de trabalho e originam uma maior exi-gncia por parte das comunidades de utilizadores. Cada patamar oubenchmarkreflecte um valor bsico (core value) e um valor avanado(advanced value) relativamente ao valor acrescentado para o negciode cada projecto implementado. Tendo em conta as vrias fontes dedados subjacentes, frequentemente possvel extrair informao adicionalque permita novas anlises e um enquadramento mais completo.

Figura 1.3Valor bsicoe valor avanadode umaimplementao

Terceira evidncia Um projecto de BI por clusters (nichos)assegura uma simbiose integrada e duradoura entre a viso de neg-

cio e a viso tecnolgica da organizao.

Uma organizao necessita de ter as suas funes (marketing,produo, RH, finanas, logstica, entre outras) e as inerentes respon-sabilidades hierrquicas (e. g., por departamentos) bem definidas.Contudo, no existem fronteiras estanques que delimitem estas rease os respectivos factores crticos de deciso. Por exemplo, num neg-cio em que o custo total (aquisio e aprovisionamento) da matria--prima seja um factor muito relevante, as anlises de vendas, compras,

logstica e marketingtero de estar inter-relacionadas. Como tal, aotrabalhar as aplicaes de BI por clusters (temporrios ou perma-nentes), possvel fazer decises enquadradas e com uma perspecti-va completa de todas as variveis que tenham impacto na deciso.


15/160


15

Figura 1.4Clusterdebusiness

intelligence

para a decisode preos

T E S T E O S S E U S C O N H E C I M E N T O S

1. Quais as principais vantagens competitivas que um projecto de business intelligen-cepode trazer a uma organizao?2. Enumere quatro aplicaes funcionais a nvel da gesto das ferramentas de busi-

ness intelligence.3. Descreva e caracterize os principais componentes de um sistema de business

intelligence.


16/160

16



17/160


17

Panorama Actualdos Sistemas

de Informaoe da Gesto

Conhecer a infra-estrutura tecnolgica anterior introduo dastecnologias de business intelligence

Conhecer os principais processos estratgicos de decisoempresarial

Compreender o impacto dos projectos de business intelligence naeficincia e eficcia desses processos

O B J E C T I V O S

2C A P T U L O


18/160

18


OS SISTEMASDE INFORMAOPARA GESTO:LEGACYSYSTEMSVS. INTELLIGENCESYSTEMS

J remontam dcada de 70 os primeiros sistemas integrados einformatizados de gesto, os designados MIS (management informa-tion systems), que tiveram o mrito de integrarem a informao origi-nria dos vrios processos de negcio da organizao. Contudo, estafase inicial debateu-se com as muitas limitaes das infra-estruturastecnolgicas subjacentes (linguagens de programao, sistemas ope-rativos, hardware, tecnologias de comunicao, entre outros), semdvida bastante rudimentares, quando comparadas com os padres

actuais.A inovao tecnolgica permitiu, contudo, que estas dificuldadesiniciais fossem superadas. O advento dos PC (personal computers)veio trazer uma maior massificao e democratizao, de uma formatransversal aos vrios degraus hierrquicos das organizaes, utili-zao das ferramentas informticas.

Passadas as primeiras etapas de informatizao, as grandes e m-dias empresas passaram a ltima dcada envolvidas em projectos des-tinados a melhorar a sua eficincia operacional:

A implementao de sistemas operacionais integrados (ERP) per-mitiu s organizaes optimizarem a sua componente transaccio-nal, racionalizando processos e formatando a informao de modoeficaz, e ainda integrar reas que anteriormente careciam de siste-matizao;

O desenvolvimento de projectos de cariz funcional, como CRM(customer relationship management) gesto da relao com

os clientes , SCM (supply chain management) gesto dacadeia de fornecimento e DMS (document management solu-tions) solues de gesto da documentao produzida (cadaum com as suas propostas de valor especficas em termos deeficincia), foi essencial para conferir nveis superiores de quali-dade s vrias etapas da cadeia de valor.

Estes investimentos em legacy systems, foram, basicamente,

aperfeioamentos feitos aos processos de back-office das organi-zaes: compras, aprovisionamentos e gesto de stocks, gestodocumental, gesto de equipamentos, pessoal, vendas e factura-o, entre muitos outros.


19/160

CAPTULO 2 PANORAMA ACTUAL DO S SISTEMAS DE INFORMAO E DA GESTO

19

OS INTELLIGENCE SYSTEMSE O SEU VALOR ACRESCENTADO

Apesar de tudo, as empresas tm ficado, progressivamente, cada

vez mais niveladas e equiparadas no que diz respeito sua eficincia.Como tal, por todos reconhecido que j no basta as empresas seremcompetitivas a nvel operacional e transaccional: tm de ser eficazes anvel corporativo. O foco est agora no acesso, na partilha e na anlisedas informaes e na sua transformao em conhecimento til para o

processo de tomada de deciso. Esta uma abordagem, uma perspec-tiva integrada que visa os processos estratgicos de um organizao,

balizados no seu ciclo de gesto anlise e gesto estratgica, planea-mento e oramentao, previso, consolidao financeira, reportingeanlise daperformance, e gesto dos resultados e das compensaes.

Para esta abordagem so necessrios intelligence systems, paraos quais as ferramentas de business intelligence so a matria-pri-ma tecnolgica.

Em resumo, as ferramentas de business intelligence tm trs com-petncias fundamentais:

acesso pertinente informao;

capacidade de anlise;

capacidade de reporting.

PROCESSOS OPERACIONAISE PROCESSOS ESTRATGICOS:EFICINCIA OPERACIONALVS. EFICCIANA DECISO

Como j vimos, a eficincia operacional foi (e tem sido ainda nosltimos tempos) o grande foco de preocupao dos gestores. Os pro-

jectos sucederam-se na perspectiva da automatizao e integrao dosfluxos de informao transaccional, com vista a optimizar os processosde negcio em termos de tempo, custo e qualidade final dos outputs.

Em termos de processos operacionais, h que elencar os proces-sos de logstica, produo, transao comercial, os processos finan-ceiros e os de gesto de recursos humanos no fundo procedimentos

rotineiros, de grande regularidade, que constituem o sistema circula-trio e sustentam assim a actividade da empresa.

J os processos estratgicos prendem-se com um conjunto de acti-vidades essenciais organizao como um todo: analisar o contexto


20/160

20


estratgico, planificar, estabelecer objectivos concretos, implementar(disseminando a informao), monitorizar, efectuar uma correcta ac-countability e consolidar informao (para fins internos ou externos).

Os primeiros beneficiaram de todo um esforo de modernizao e

integrao. J os segundos, no obstante a sua importncia, s nosltimos anos comearam a preocupar os proprietrios e gestores deempresas. Tal no indiferente ao facto de apenas recentemente oaperfeioamento das tecnologias de apoio tomada de deciso per-mitir elevar o patamar qualitativo destes processos.

ASBUSINESSPAINS:FORECASTING, PLANEAMENTOEORAMENTAO, CONTROLO INTERNO, ANLISEDAINFORMAO, IMPLEMENTAO ESTRATGICAE GESTODAPERFORMANCEGAPSELACUNASPARAA GESTO

PLANEAR, ORAMENTAR, PREVER

Na complexidade e dimenso das organizaes actuais, a primeirabusiness pain (que, de forma aproximada, podemos designar comodor de gesto de negcios) responder seguinte questo:

Depois de definir a estratgia empresarial, como se elabora todo oprocesso de planeamento operacional e financeiro e respectiva ora-mentao de forma a tornar estas operaes em instrumentos teis paraa nossa gesto?

Figura 2.1O ciclo deplaneamento


21/160


21

Por simples que possa parecer, esta uma questo bsica e essen-cial para compreender as razes que concorrem para a ausncia deuma verdadeira gesto estratgica nas empresas.

O que est em causa , de forma sinttica, o processo (os mto-

dos), o suporte (a tecnologia) e os objectivos da funo de planea-mento. A perspectiva sistmica mais no do que o resultado dosconstantes interaces/constrangimentos entre estas trs variveis,que se influenciam e condicionam mutuamente.

Em primeiro lugar, o processo adoptado. Em muitas organizaes,o planeamento e a oramentao so ainda operaes morosas, cen-tralizadas e extremamente inflexveis. A separao, bastante vulgar,entre as funes de planeamento e oramentao implica muitas vezes

o divrcio entre os departamentos operacionais/funcionais e o depar-tamento financeiro e o afastamento e desinteresse por parte da orga-nizao pelo processo em si. O processo exige um perodo de recolhade dados, respectiva consolidao e relatrios finais em formatos-pa-dro: os oramentos (budgets) propriamente ditos, discriminados porcentros de custos, demonstrao de resultados (profit & loss e inco-me statement), balano (balance sheet) e mapas de cash-flows.

A natureza dinmica de maior parte dos negcios, na actualidade, jexige aquilo que de designa como rolling forecastings (previses din-micas), isto , actualizaes constantes das previses iniciais em fun-o de novos inputs de informao endgena ou exgena exignciaque dificilmente se torna prtica com os processos tradicionais.

O suporte , frequentemente, a pedra-de-toque de todo o sistema.As tecnologias tradicionais mais utilizadas so as folhas de clculo(spreadsheets, i. e., os tpicos ficheiros de Excel), agrupadas atravsde um conjunto complexo de ligaes. Este suporte origina cenriosem que a criao, distribuio, recolha e consolidao dos modelos

dos ficheiros se arrasta por semanas, acompanhadas muitas vezespor uma legio de analistas encarregues de assegurar a fiabilidade doprocesso. Acontece frequentemente, neste contexto, mudanas daspremissas iniciais, erros nas frmulas ou nas ligaes das folhas ealteraes no autorizadas ou novos dados, o que desencadeia a ne-cessidade de encontrar e corrigir os erros.

Para terminar, os objectivos destas operaes so naturalmenteinfluenciados pelo binmio processo-tecnologia adoptado. Com efeito,

em organizaes que utilizem os cenrios tradicionais aqui descritos, difcil transformar o planeamento da base e a monitorizao da ges-to estratgica em tempo real, como seria de esperar. As pessoasenvolvidas passam mais tempo no processo de recolha e composioda informao do que na sua anlise e preparao para a tomada de


22/160

22


decises. Torna-se tambm difcil o desenvolvimento de um sistemade custeio que permita atribuir a cada actividade/produto/estrutura oseu exacto nvel de rentabilidade, essencial para uma gesto eficaz da

performance. Os objectivos da funo de planeamento ficam assim

constrangidos criao de um cenrio indicativo que discipline razoa-velmente o comportamento das vrias clulas da organizao, mas

perdero, inevitavelmente, o seu valor acrescentado num curto espa-o de tempo.

Fazendo agora um caminho inverso, importante explicitar quaisdevero ser os objectivos e as propostas teis de um sistema optimi-zado tecnologia-processo:

Capacidade de planear com rapidez e flexibilidade;

Envolvimento de toda a organizao no processo, de forma trans-parente e em tempo real;

Introduo de capacidades de previso ao longo do ano, sem revertodo o processo;

Promoo da avaliao e accountability de todas as reas e res-pectivos responsveis, atravs de um sistema de custeios baseadonas sua tarefas operacionais;

Promoo da fiabilidade e preciso dos dados oramentados comvista sua utilizao pelos decisores internos.

Boa parte destas necessidades so preenchidas na actualidade porferramentas informticas de planeamento que utilizam tecnologiasstateof the artde business intelligence, que, como veremos em pormenorna descrio dos sistemas de corporate performance management,

podero e devero ser integradas com as outras aplicaes de anlise

e reporting.

IMPLEMENTAR A ESTRATGIA E GERIR APERFORMANCE

A segunda business pain , por sua vez, responder seguinte ques-to:

Como se dissemina por toda a organizao a informao sobreos objectivos estratgicos, respectivos indicadores e metas e como segere a performance em tempo real?

Importa, em primeiro lugar, tentar compreender a forma como asorganizaes gerem as suas actividades. Definida a estratgia e efec-tuado um correcto planeamento, a empresa necessita de divulgar as


23/160


23

linhas gerais de actuao que se esperam das vrias unidades opera-cionais e funcionais ou at individualmente, de cada colaborador.De uma forma integrada, necessrio: definir a viso, e em seguida aestratgia, elencar os respectivos factores fundamentais para o seu

sucesso e explicitar os key performance indicators (indicadores--chave). De uma forma esquemtica:

Figura 2.2A pirmideestratgica:

da viso aosindicadores

Ora, os indicadores fundamentais precisam de ser inicialmente dis-seminados (para clarificar o conhecimento de todos) e posteriormentecontrolados.

Algumas regras que importam ter em conta:

Comunicar e avaliar os indicadores atravs de mtricas (medi-das) que traduzam de facto a actividade de cada um no dia-a--dia (peas produzidas, quantidades ou valores vendidos, nmerode servios prestados) e a qualidade esperada dessa actividade(graus de satisfao/de sucesso apurados, etc.);

Apurar os indicadores em tempo til, de forma a que o cicloplanificar executar controlar analisar corrigir seja rpi-do e fluido (esbatendo os latency times);

Reforar o empowerment, dotando cada responsvel de capa-cidades de interaco com as suas respectivas reas de influn-cia, de forma a que a aco executiva seja verdadeiramenteoperacional;


24/160

24


Permitir uma rpida compreenso daperformanceao longo do tempo,avaliando a evoluo e as relaes causa-efeito entre as variveis.

Tudo isto implica a gesto, num road-map integrado, a definio

de um modelo de gesto daperformance e, no menos importante, asua implementao atravs meios tecnologicamente adequados.A grande dificuldade, neste contexto, o apuramento, transforma-

o e acessibilidade da informao. Com efeito, muitos dos indicado-res (valores absolutos, razes, entre outros) no so simples nmerosapurados a partir de um nico sistema. Pelo contrrio, so frequente-mente fruto da informao composta, agrupada em vrios sistemas Como podemos ento ter todo o conhecimento necessrio agrupadonum nico quadro de mtricas e relatrios?

ANALISAR A INFORMAO

A diversidade de factos e as dimenses de anlise (geogrfica,comercial, de produto) das empresas actuais tornam extremamentemorosa e complexa a tarefa dos analistas de gesto e decisores. Nes-te ponto, a questo decisiva :

Como se sabem, em tempo real, os principais factos e tendncias

do negcio, de forma a retirar a partir deles concluses e decises denatureza correctiva?

Esta questo mais pertinente quando se tem, por exemplo, cente-nas ou milhares de referncias de produtos ou servios (logo, tipolo-gias diferentes), dezenas de unidades de negcio distribudasgeograficamente, diversos fornecedores alinhados numa cadeia de abas-tecimentos a montante e diferentes segmentos de clientes/consumi-dores a jusante das nossas operaes. Em suma, quanto maior for a

complexidade maior ser a necessidade de obter e analisar a informa-o, para ter uma perspectiva que seja ampla, mas, de forma comple-mentar, capaz de descer ao pormenor.

Figura 2.3Representaoda visode negciodos gestores


25/160


25

EFECTUAR O CONTROLO INTERNO E GERIR O RISCO

A gesto de risco e os sistemas de auditoria e controlo so impera-tivos das modernas normas de governo das empresas. Com efeito,

fundamental assegurar a informao em tempo real acerca dos prin-cipais riscos do nosso negcio e criar as condies de segurana es-senciais definio da sua fiabilidade prticas asseguradas pelosdesignados sistemas de controlo interno.

Aqui a questo pode ser formulada da seguinte forma: Como se identificam claramente os riscos do negcio e formaliza

um sistema de controlo interno capaz de monitorizar os eventos/ten-dncias indesejveis para o cumprimento dos nossos objectivos?

Os riscos que, de forma generalizada, so hoje o alvo de maioresatenes e preocupaes por parte dos gestores so os relacionadoscom a fiabilidade e integridade da informao financeira; so aque-les riscos que podem colocar em causa a eficincia e eficcia dasoperaes e os que podem impedir, de algum modo, a conformidadecom a legislao e os regulamentos aplicveis. De facto, o Sarba-nes-Oxley Act (legislao norte-americana que prope uma exign-cia extremamente rigorosa em termos dos sistemas de controlo internodas empresas cotadas), o Basel II (acordo internacional do sector

bancrio que visa o estabelecimento de padres para calcular requi-sitos mnimos de capital e novos modelos de clculo de risco de cr-dito e risco operacional) e outras normas impem hoje, a nvelinternacional, novas formas de controlar e monitorizar, de forma sis-tmica e integrada, estas questes.

Outras organizaes, com um grau de maturidade superior, bus-cam j o desenvolvimento de modelos que lhes permitam gerir asvrias categorias de riscos financeiros, estratgicos, ambientais, etc.,

utilizando modelos matemticos sofisticados de anlise de impactode cenrios.Como tal, a existncia de sistemas de workflow management,

business process management e gesto documental que monitori-zem as vrias etapas dos processos e avaliem as interaces realiza-das encarada como essencial. Por exemplo, dada a complexidadeda dimenso, a disseminao e necessria consolidao da informa-o financeira, essencial a existncia de capacidades de audit trailque possam registar o histrico e detectar todas as alteraes efectu-adas a um determinado registo.


26/160

26


T E S T E O S S E U S C O N H E C I M E N T O S

1. De que forma podem as ferramentas de business intelligenceoptimizar o ciclo deplaneamento da empresa?

2. Que dificuldades de anlise tornam pertinente a introduo de ferramentas deanlise multidimensional?

3. Quais as dificuldades com que se deparam os gestores que pretendam operacio-nalizar um sistema de gesto da performance?


27/160


27

Bases de Dadose DataWarehousing

Conhecer os conceitos bsicos de bases de dados e datawarehousing, pilares bsicos dos projectos de business intelligence

Compreender a importncia dos metadados e da qualidade dos dadospara o sucesso dos projectos

Adquirir noes bsicas sobre o processo de construo de umdata warehouse

O B J E C T I V O S

3C A P T U L O


28/160

28


CONCEITODE BASESDE DADOS

Uma base de dados no mais do que uma coleco de dados orga-

nizada de uma determinada forma sistematizada. No obrigatrio quea base de dados esteja registada num computador, mas nos dias de hojea grande maioria das bases de dados est em formato electrnico.Existem diversos tipos (ou modelos) de bases de dados, sendo os maisconhecidos o relacional e o dimensional. Este ltimo predominante-mente utilizado em data warehousing. No modelo dimensional os da-dos so organizados em tabelas divididas em linhas e colunas. Cadacoluna contm um valor discreto (embora noutro tipo de bases de dados

possa no ser exactamente assim). Os valores das colunas podem ser

inmeros, dependendo do sistema de gesto de base de dados que gerea informao. Os valores mais comuns so geralmente nmeros ou tex-to, podendo ser nulos e vazios. A diferena entre nulo e vazio impor-tante salientar, pois o nulo (ou null) deve ser lido como valordesconhecido, enquanto o vazio deve ser lido como sem valor.A nomenclatura das linhas e colunas pode ser, em linguagem de base dedados, tambm denominada tuplo e atributo ou, mais correntemen-te, registo e campo. Utilizaremos, de ora em diante, esta ltimadenominao, para maior clareza de conceitos.

A consulta de dados numa base de dados em formato electrnico faz--se, normalmente, pela utilizao de uma linguagem-padro designadacomo SQL (structured query language). Esta linguagem foi definidacomo padro pelo ANSI (American National Standards Institute), masexistem vrias verses, dependendo do fabricante dosoftware de gestode base de dados. A grande maioria das verses cumpre os padres doANSI, suportando as palavras essenciais definidas pela instituio (porexemplo,select, update, delete, inserte where). Consultando uma tabe-

la de clientes podemos dar um exemplo desta linguagem:

Tabela 3.1

Tabelade clientes

COD_CLIENTE NOME_CLIENTE MORADA1 LOCALIDADE MORADA2 LOCALIDADE

1 Ramalho e filhos Praa da Alegria Lisboa Av. Roma Lisboa

2 Castro e Marim Lda. Rua do Girassol Lisboa Av. Repblica Lisboa

3 Alfarrobas e Cia Praa de Repblica Porto Rua do Amial Porto

Em SQL, poderamos consultar os nomes dos clientes e moradas

cuja localidade fosse Lisboa da seguinte maneira:

SELECT C.NOME_CLIENTE, C.MORADA1FROM CLIENTES CWHERE C.LOCALIDADE1 = Lisboa


29/160

CAPTULO 3 BASES DE DADOS EDATA WAREHOUSING

29

Para manipular e consultar as bases de dados normalmente neces-sria uma aplicao designada como sistema de gesto de bases dedados (SGBD ou, em ingls, DBMS database management sys-tem). Este sistema ou aplicao especializado em gerir os ficheiros de

base de dados. Se for uma aplicao do tipo servidor (como SQL Ser-ver ou Oracle), a sua funo aceitar pedidos de aplicaes clientes

para gerir os dados existentes nas bases de dados. As aplicaes clien-tes nunca manipulam as bases de dados directamente, apenas enviam

pedidos ao SGBD para que este faa a manipulao e a consulta dosdados numa arquitectura designada cliente/servidor. Em linguagem cor-rente, a designao base de dados inclui a base de dados propria-mente dita e osoftware SGBD. No entanto, importante saber distinguir

os dois conceitos. Fazendo uma analogia, e para melhor compreenso,a base de dados para o SGBD aquilo que o livro para o bibliotecrio.Os SGBD mais completos possuem outras funcionalidades alm da sim-

ples gesto e consulta das bases de dados. Tambm fazem o processa-mento de transaces, salvaguarda, recuperao de dados, controlo deacessos, evitam a corrupo dos ficheiros, entre outras funcionalida-des. Outra das vantagens deste tipo de arquitecturas cliente/servidor o facto de reduzirem drasticamente a utilizao de largura de banda narede, uma vez que todas as operaes so realizadas no servidor dedi-cado com o SGBD e apenas devolvida aplicao cliente a informa-o relevante que foi solicitada.

RELAES ENTRE TABELAS

Numa tabela como a definida anteriormente, temos apenas paracada registo o mesmo conjunto de campos. Mas isto no quer dizerque, para introduzir ou consultar informaes, todos os campos com

a informao necessria tenham que estar na mesma tabela. A in-formao pode estar disseminada por vrias tabelas, porque todas

podem ser consultadas ao mesmo tempo atravs da SQL. No entan-to, as vrias tabelas devem possuir um ou vrios campos comuns,

para que se possam relacionar e para que seja possvel consultar osdados de uma forma coerente e estruturada. Como ilustrao, ob-servemos uma tabela de clientes e outra de moradas:

COD_CLIENTE NOME_CLIENTE

1 Ramalho e filhos

2 Castro e Marim Lda.

3 Alfarrobas e Cia

Tabela 3.2Tabelade clientes


30/160

30


COD_MORADA COD_CLIENTE MORADA LOCALIDADE

1 1 Praa da Alegria Lisboa

2 1 Av. Roma Lisboa

3 2 Rua do Girassol Lisboa

4 2 Av. Repblica Lisboa

5 3 Praa de Repblica Porto

6 3 Rua do Amial Porto

Tabela 3.3Tabelade moradas

Em SQL poderamos fazer uma consulta dos nomes e moradascom localidade em Lisboa, como na consulta anterior, utilizando a se-guinte sintaxe:

SELECT C.NOME, M.MORADA, M.LOCALIDADEFROM CLIENTES CINNER JOIN MORADAS MON C.COD_CLIENTE = M.COD_CLIENTEWHERE M.LOCALIDADE = Lisboa

Neste ltimo exemplo, recorremos a uma relao entre as duastabelas, representada na consulta por uma juno (join) entre umcampo comum s duas tabelas. nesta lgica de junes entre tabe-las que assenta o modelo relacional.

A criao de duas tabelas clientes e moradas com a mesmainformao que a contida na tabela inicial clientes designadanormalizao. Existem mtodos formais para classificar o quonormalizada est uma base de dados, as chamadas formas nor-mais. Habitualmente, quanto mais normalizada uma base de dadosestiver, mais rpidas sero as actualizaes das tabelas (uma vezque so eliminadas as duplicaes, as tabelas so menores e, logo,

a busca do registo especfico a actualizar mais rpida). No entan-to, para consultas complexas a vrias tabelas, como o caso dossistemas de OLAP (online analytical processing) com o modelodimensional, a consulta ser tanto mais rpida quanto mais desnor-malizada estiver a base de dados.

AS FORMAS NORMAIS

As formas normais mais utilizadas so a primeira forma nor-mal (1FN), segunda forma normal (2FN) e terceira forma normal(3FN). A 1FN o primeiro passo para a organizao dos dadosque existem dentro de uma (ou mais) tabela (ou tabelas), de acordo


31/160


31

com as regras de normalizao. Para colocar os dados de umatabela na 1FN necessrio colocar os dados em tabelas separa-das, em que os dados dentro de cada uma das tabelas sejam domesmo tipo, e atribuindo a cada uma das tabelas uma chave pri-

mria. Uma chave primria o conjunto de uma ou mais colunascujos valores identifiquem unicamente um registo. Assim, com a1FN, so eliminados grupos repetidos de dados como, por exem-

plo, as moradas existentes na Tabela 3.1, obtendo assim comoresultado as tabelas 3.2 e 3.3. Deste modo, a chave primria databela de clientes (Tabela 3.2) o campo cod_cliente e a chave

primria da tabela de moradas (Tabela 3.3) o conjunto dos cam-pos cod_cliente e cod_morada. A coluna cod_cl iente na tabela

das moradas denominada chave estrangeira, uma vez que cor-responde chave primria da tabela de clientes. Para normalizaras tabelas reduzindo-as 2FN, devem remover-se todos os cam-

pos que dependam apenas de uma parte da chave primria, como o caso da localidade na tabela de moradas, que depende apenasdo campo cod_morada e no do cod_cliente. Assim, obtm-se oseguinte resultado (Tabela 3.4 e Tabela 3.5):

COD_MORADA COD_CLIENTE MORADA LOCALIDADE1 1 Praa da Alegria 1

2 1 Av. Roma 1

3 2 Rua do Girassol 1

4 2 Av. Repblica 1

5 3 Praa de Repblica 2

6 3 Rua do Amial 2

Tabela 3.4

COD_LOCALIDADE LOCALIDADE

1 Lisboa

2 Porto

Tabela 3.5

Agora, a chave primria da tabela das localidades apenas o cam-po cod_localidade e os valores do campo localidade deixaram de es-tar repetidos. Assim, podem existir na base de dados localidades queainda no esto atribudas a nenhum cliente. O passo que falta para

chegar 3FN retirar todos os campos das tabelas que no depen-dam exclusivamente da chave primria. Isto faz com que o campomorada, na Tabela 3.4 seja excludo, para gerar o seguinte resultado(Tabela 3.6, Tabela 3.7 e Tabela 3.8):


32/160

32


COD_CLIENTE COD_MORADA

1 1

1 2

2 3

2 4

3 5

3 6

Tabela 3.6

COD_MORADA MORADA

1 Praa da Alegria

2 Av de Roma

3 Rua do Girassol

4 Av da Repblica5 Praa da Repblica

6 Rua do Amial

Tabela 3.7

COD_MORADA LOCALIDADE

1 1

2 1

3 1

4 1

5 26 2

Tabela 3.8

Depois da 3FN existem outras (mais quatro) formas normais, que, naprtica, no so geralmente utilizadas na concepo de bases de dados.

CONCEITODEDATA WAREHOUSE

Para definir o conceito de data warehouse (DW) ou armazm dedados necessrio, em primeiro lugar esclarecer alguns termos impor-tantes para a sua compreenso. O primeiro o termo dados. Os da-dos de um DW so compostos por factos individuais e discretos quecongregam valores descritivos, qualitativos e quantitativos de interessee relevncia para o negcio. O campo de data warehousingenvolvedois tipos de dados: os dados operacionais, que descrevem as transac-es e os acontecimentos dirios, e os dados informativos, que so

reconciliados, integrados, limpos e que constituem a matria-prima apartir da qual a informao construda.

O segundo termo informao. A informao definida comouma coleco de dados organizada e apresentada num contexto espe-


33/160


33

cfico e com significado para o negcio. O objectivo da informao denegcio informar pessoas e processos, ou seja, fornecer factos emtricas vitais para os processos e teis para as pessoas que os de-senvolvem. Assim, a informao adiciona dados ao conjunto de co-

nhecimentos que est disponvel para os sujeitos do negcio e para osprocessos de negcio.

O conceito que se segue de extrema importncia para a criaoe o desenvolvimento de qualquer projecto que envolva um DW oconhecimento. O conhecimento uma caracterstica pessoal e indivi-dual; tem essencialmente a ver com a familiaridade, compreenso e

percepo que as pessoas possuem em relao a um determinadoassunto e no com informao contida em computadores ou softwa-

re. O conhecimento pode ser adquirido de diversos modos, como porexemplo o estudo, a experincia, o instinto e a crena. Uma vez queestes factores so diferentes de indivduo para indivduo, o conheci-mento de cada um , inevitavelmente, nico.

Existem muitas definies de data warehouse provenientes devrios autores conceituados na matria, como William Inmon ou RalphKimball. A definio mais consensual aquela que descreve o datawarehouse como uma coleco de dados que:

so integrados o data warehouse dever ser uma fonte nica eabrangente de informao para e sobre o negcio. Assim, com umDW no necessrio aceder a mltiplas fontes de dados para res-

ponder a questes levantadas pelos utilizadores;

so organizados por assuntos os dados e a informao deveroser apresentados compartimentados por assuntos, de acordo comas necessidades dos utilizadores finais;

variam no tempo o data warehouse contm o histrico da infor-mao, assim como a informao actual, sobre o negcio, possibili-tando desta forma anlises de evoluo histrica;

no so volteis o data warehouse contm informao estvel.Os dados, uma vez chegados ao DW, no so apagados. Assim, osdados so sempre adicionados de formas regular, de modo a forne-cer registos histricos correctos e credveis;

so acessveis uma das funes primrias de um datawarehouse proporcionar o acesso informao de uma forma fcil e rpida.

Assim, o data warehouse desenvolvido para responder s ne-cessidades do negcio no que diz respeito obteno e anlise de


34/160

34


informao, transformando dados de vrias fontes em informaesrelevantes para o negcio.

Um data warehouse um repositrio de informao que

congrega os dados histricos de cariz operacional e transac-cional de uma organizao agrupados numa base de dados.Este armazenamento implica o favorecimento e a facilitaode tarefas como a anlise e o reporting.

A criao de um data warehouse justifica-se por dois motivosfundamentais:

A necessidade de integrao de dados distribudos por diferentes

estruturas de bases de dados, tendo em vista uma anlise global; A necessidade de separao dos dados utilizados nas operaes

correntes dos utilizados na anlise e no reporting, tendo como fima tomada de decises.

Um data warehouse agrupa frequentemente um vasto manancialde informao, que muitas vezes dividida em conjuntos mais peque-nos e agrupados de forma lgica em pequenas unidades designadascomo data marts.

ARQUITECTURAS DE DATA WAREHOUSE

A modelizao (desenho) da estrutura de um sistema de informa-o como um data warehouse um passo essencial. De facto, im-

porta ter um conceito alicerado em entidades lgicas (coerentes coma estrutura da organizao e com os processos de negcio) e na des-

crio das dependncias entre si.A criao do DW tem o seu incio na concepo do modelo, que irser carregado com os dados provenientes de diversas fontes atravsdo denominado processo de ETL (extraction, transformation eloading extraco, transformao e carregamento).

Qualquer ambiente de data warehousing, para estar completo,tem de desempenhar cinco funes fundamentais. Diferentes reposi-trios de dados (do ingls datastores) podem corresponder a funes

diferentes dentro do data warehouse, conforme a arquitectura esco-lhida. As funes so as seguintes:

Recepo Os repositrios com esta funo acolhem os dados dasvrias fontes para dentro do ambiente do data warehouse. As fon-


35/160


35

tes podem ser dispersas e possuir diferentes tecnologias, e a aqui-sio de dados ser feita em frequncias temporais distintas. Habi-tualmente, durante este processo feita a limpeza dos dados, paraque estes se apresentem o mais correctos e completos possvel

dentro do data warehouse;

Integrao Os repositrios com esta funo conjugam dados devrias fontes uns com os outros. Como exemplo, podemos ter ocaso de, num determinado sistema operacional de introduo deencomendas, um produto possuir o cdigox e no sistema operacio-nal de gesto de stocks e armazm o mesmo produto possuir ocdigoy. A indicao de correspondncia entre os diversos dados feita nestes casos. Pode ser necessrio fazer outra limpeza de da-

dos alm da j efectuada durante a recepo de dados;

Distribuio Os repositrios com esta responsabilidade represen-tam activos de informao a longo prazo e com mbito alargado.A distribuio consiste no processo de transferir os dados destetipo de repositrio para repositrios concebidos para responder anecessidades de negcio mais especficas (como os data marts);

Entrega Os repositrios com esta funo combinam os dados de

acordo com o contexto que uma determinada unidade de negcioou conjunto de utilizadores necessita, dentro da organizao. A en-trega feita transferindo os dados para um manancial de tecnolo-gias, como data marts, cubos multidimensionais, dashboards, etc.;

Acesso Os repositrios com responsabilidade de acesso so osque permitem a consulta de informao de dados integrados e ge-ralmente os alvos do processo de distribuio.

Figura 3.1Representaogrfica deum data warehouseno modelo starschema


36/160

36


STAR SCHEMA

Ostar schema (esquema em estrela) talvez o modelo mais utiliza-do na concepo de um data warehouse. O conceito pressupe a cria-

o de tabelas dimensionais (e. g., dimenso tempo, dimenso clientes,dimenso geogrfica), que ficam ligadas entre si atravs de uma tabelade factos. A sua interligao baseia-se num esquema lgico e simples:as tabelas dimensionais contm as definies das caractersticas doseventos, enquanto as tabelas de factos, por sua vez, armazenam os fac-tos decorridos e as chaves estrangeiras para as caractersticas respec-tivas que se encontram nas tabelas dimensionais.

Este modelo apresenta vantagens bvias, como por exemplo a exis-

tncia de uma nica tabela de factos contendo toda a informao semredundncias, a definio de apenas uma chave primria por dimen-so, a reduo do nmero de interligaes e a consequente poucanecessidade de manuteno.

TABELA DE FACTOS

A tabela de factos o centro do esquema em estrela, armazenan-

do enormes quantidades de informao, historicamente definida, obti-da a partir da interseco da restante. Assim, cada registo de umatabela de factos possui uma coluna, ou um conjunto de colunas, quecorresponde s chaves primrias de cada uma das tabelas dimensio-nais do esquema em estrela. Alm destas colunas com as chaves es-trangeiras, a tabela de factos contm tambm colunas que descrevemo volume, frequncia, valor ou quaisquer outras medidas numricasque possam ser agregadas (atravs de somas, contagens, mdias, etc.)num query de SQL. Isto significa que a tabela de factos altamente

normalizada, pois a sua chave primria consiste na concatenao detodas as chaves estrangeiras das dimenses relevantes para os fac-tos, e os atributos so medidas numricas que se relacionam directa-mente com a chave primria.

TABELAS DIMENSIONAIS

As tabelas dimensionais contm, na esmagadora maioria das ve-

zes, muito menos registos do que as tabelas de factos. O seu tamanhovaria habitualmente entre as dezenas e os milhares de registos, en-quanto as tabelas de factos podero conter milhes ou mesmo biliesde registos. Este tipo de volume representa um problema quando que-


37/160


37

remos efectuar uma busca nas tabelas de factos. ento que o es-quema em estrela mostra a sua eficincia. Tomando como exemplouma tabela de factos que contm vendas de produtos a clientes emunidades e valores, com dez milhes de registos e trs dimenses (clien-

tes, tempo, produtos) de cem registos cada. Neste caso, e assumin-do uma distribuio uniforme dos dados na tabela de factos, uma con-sulta que seleccione um registo de cada uma das trs dimenses irter um retorno, da tabela de factos, de apenas dez registos. Esta con-sulta, utilizando o esquema em estrela e os ndices apropriados, serextremamente rpida. As tabelas dimensionais devero conter, almde todos os atributos descritivos como o nome do produto, o tipo de

produto, etc., os atributos numricos, que no faz sentido serem agre-

gados (e. g., preo do produto). Caso a tabela dimensional possuadados contnuos, devero ser criados intervalos para que os dadospossam ser agrupados de forma relevante. Podemos tomar como exem-plo o valor das encomendas. Em vez de existir um registo por cnti-mos na tabela (o que levaria a uma tabela dimensional com muitosregistos e provavelmente no muito relevante para o negcio), farsentido criar intervalos de zero a 100 euros, de 100 a 200 euros eassim sucessivamente, atribuindo a cada intervalo um valor para acategoria de preo (um para [0, 100], dois para ]100, 200], etc.), per-mitindo assim uma anlise mais relevante dos factos.

CHAVES SUBSTITUTAS

Habitualmente, no so utilizadas, num datawarehouse, as chavesprimrias e as chaves estrangeiras do sistema fonte. Tomemos comoexemplo uma tabela de clientes no sistema transaccional que tem 1como cdigo de cliente. Se este cliente mudar de nome, o que acontece

geralmente nestes sistemas que o nome do cliente alterado mas ocdigo mantm-se igual. Para que a informao do anterior nome docliente no se perca, no ambiente de data warehouse so utilizadaschaves substitutas (surrogate keys), que substituem a chave primriaoriginal, permitindo repeties da mesma. Tomemos como exemplo atabela de clientes como a Tabela 3.2, e o campo cod_cliente que cor-responde a 1. Se o cliente corresponente tivesse mudado de nome nodia 15 de Janeiro de 2006, no sistema transaccional teramos:

COD_CLIENTE NOME_CLIENTE

1 Ramalhete e Caramelo

Tabela 3.9


38/160

38


Enquanto no data warehouse, a tabela com a dimenso clientes,tipicamente, seria:

Tabela 3.10

ID_CLIENTE COD_CLIENTE NOME_CLIENTE INCIO_VAL FIM_VAL REG_ACTUAL

1 1 Ramalho e filhos 01/01/1970 14/01/2006 0

2 1 Ramalhete e Caramelo 15/01/2006 01/01/3000 1

Nesta tabela o id_ cliente a chave substituta para a chave primria databela original. Este identificador, que a chave primria da tabela dimen-sional, aquele que servir de chave estrangeira na tabela de factos.Assim, uma venda que tenha sido efectuada ao cliente com o cod_cliente 1

antes de 15 de Janeiro de 2006 ir constar da tabela de factos com oid_cliente 1, e uma venda que tenha sido efectuada ao mesmo cliente, apsesta data, ir ser registada na tabela de factos com o id_cliente 2, enquantono sistema transaccional de origem, a mudana de nome no detectada,

pois o nome do cliente foi actualizado. Isto permite que se possam olhar osdados (factos) por duas perspectivas distintas: vendas por nome de cliente(logo, no tendo em conta a mudana de nome), ou vendas por cliente real(com o campo de cod_cliente = 1).

SNOW-FLAKE SCHEMA

Na modelizao dos dados, o esquema snow-flake uma evolu-o mais complexa dostar schema. O seu objectivo normalizar asdimenses, agrupando os dados de cada uma em vrias tabelas (e noapenas numa nica grande tabela como no esquema em estrela), evi-tando assim redundncias.

Figura 3.2Representaogrfica de umdata warehouse

no esquemasnow-flake


39/160


39

CONCEITODEDATA MART

Podemos definir um data martcomo uma verso mais especializa-

da e especfica de um data warehouse. Sendo as suas caractersti-cas essenciais similares a este ltimo (conjunto de dados vindos daactividade operacional de uma organizao), a sua criao advm danecessidade de agrupar e configurar dados funcionalmente homog-neos (e. g., data martde vendas, de recursos humanos).

A criao de um data martprende-se frequentemente com impe-rativos de performance (separar um conjunto de dados do DW cor-

porativo com vista a uma maior eficincia no seu tratamento eprocessamento), segurana (separar informao autorizada para de-terminado grupo de utilizadores da informao confidencial) ou utili-dade (necessidade de um modelo de dados diferente do DW para umafinalidade de negcio diferente).

Importa, contudo, compreender que a construo abusiva de datamarts poder levar inconsistncia e/ou redundncia da informao(com duplicao de dados), pelo que estes projectos tero sempre deter uma boa justificao.

CONCEITOE IMPORTNCIADOS METADADOS

O significado literal de metadados (metadata) dados sobre osdados, isto , o termo refere-se informao que descreve as carac-tersticas de um conjunto de dados.

Duas analogias bastante utilizadas para simplificar este conceito

aplicado gesto das tecnologias de informao so a de um catlogocom a descrio de um conjunto de produtos e respectivos atributos, eainda, mais apropriadamente, a de um ndice de uma enciclopdia,com a enumerao de contedos.

Nas empresas, o armazenamento e gesto dos metadados da in-formao existente nos sistemas operacionais fundamental para auniformizao, fiabilidade e coerncia dessa mesma informao.

Na perspectiva da introduo de tecnologias de business intelli-gence, esta questo coloca-se sobretudo no desenvolvimento de uma

bases de dados e de um data warehouse.Por exemplo, numa base de dados relacional, a tarefa de encontrar

os metadados consistir frequentemente em ter uma tabela com a des-crio de todo o conjunto de tabelas da base de dados e seus atributos


40/160

40


(nome, nmeros de linhas, tamanho) ou tabelas com as colunas e otipo de dados a armazenado.

Ralph Kimball, estudioso e terico destas reas, apresentou umalista dos vrios tipos de metadados presentes num data warehouse:

Metadados do sistema fonte de dados Especificaes das fontes repositrios; Informao descritiva das fontes como, por exemplo, des-

crio das entidades detentoras da informao, frequnciada actualizao dos dados, limitaes legais, metodologias deacesso;

Informao sobre o processo caso da rotina das tarefas oudos cdigos de extraco;

Metadados do repositrio de recepo de dados Informao da aquisio da informao e. g., horrios e

resultados da transmisso de dados, utilizao dos ficheiros; Gesto das tabelas de dimenses definio das vrias di-

menses, funes das chaves substitutas; Transformao e agregao mapping e aperfeioamento

dos dados,scripts do modo de carregamento do DBMS, defi-

nies de agregao; Auditoria e registo (job logs) da informao;

Metadados do RDBMS (relational database management system) Tabela de contedos do RDBMS; Scripts de processamento;

Metadados dos repositrios com funo de entrega e acesso a dados Descrio das colunas;

Dados da segurana da rede.Tendo isto em considerao, poderemos agregar os metadados em

quatro tipos:

Metadados de negcio Descrevem o significado dos dados dodata warehouse e das ferramentas de businessintelligence. Guar-dam informaes como as definies e reas de negcio, a estrutu-ra e a hierarquia dos dados, as regras de agregao, a definio demtricas de negcio, etc.;

Metadados dos processos Descrevem a origem, o momento,frequncia e forma em que foram carregados os dados que estono data warehouse;


41/160


41

Metadados tcnicos Descrevem os locais fsicos, os formatos eos tipos de dados dos elementos de dados, estruturas de ficheiros etabelas, ndices, etc.;

Metadados aplicacionais Descrevem a forma como se ace-de e utiliza os dados. Podem ainda descrever os momentosem que os dados so acedidos, por quem, com que frequn-cia, etc.

Como facilmente perceptvel, todos os tipos de metadados soessenciais na gesto dos sistemas de informao das empresas ac-tuais, na tarefa sempre indispensvel de localizar os dados pretendi-dos (tracing) e conseguir monitorizar e controlar todo o processo de

transformao de dados, desde a fonte, aos interfaces de anlise ereporting, at sua validao final. A disseminao de enormessilos de informao, cuja integridade necessrio garantir, torna agesto dos metadados uma tarefa essencial para optimizar o conhe-cimento existente nos SI de uma organizao. Para isso, torna-sefundamental possuir um repositrio de metadados. O repositrio po-der ser adquirido a empresas especializadas, ou ser desenvolvidointernamente, dentro da organizao. Embora a primeira hiptese

seja uma soluo rpida, no do tipoplug & play, pois ter que serdesenvolvido o processo de extraco dos metadados das suas fon-tes e povoar o repositrio de metadados fornecidos pelo produtocomercial. No caso de se desenvolver um repositrio de metadadosinternamente, apesar de haver um esforo maior, controla-se total-mente a forma como os metadados so geridos. No entanto, im-

portante ressalvar que , tal como um projecto de data warehouse, orepositrio de metadados dever ser desenvolvido por meio de itera-

es e no de uma s vez.

IMPORTNCIADADATA QUALITY

O processo de carregamento do DW o designado ETL ,normalmente executado utilizando pequenas quantidades de dados

amostras relativamente restritas dos dados provenientes dos sis-

temas-fonte. Na fase final de um projecto que envolve o carrega-mento do DW, so utilizados volumes de dados prximos dos reaise habitualmente nesta fase que surgem os problemas relativos qualidade dos dados. Normalmente, este tipo de problemas deve-


42/160

42


-se a dados inconsistentes, como valores em falta, dados duplica-dos ou redundantes, etc. Como resultado, o analista tem de voltaratrs e resolver estes problemas e entra-se num processo iterativoque pode ser bastante moroso e dispendioso. Um problema detec-

tado durante a fase de testes poder custar cerca de 100 vezesmais do que se for detectado durante a fase de concepo e de-senvolvimento. Para que isto no acontea, torna-se essencial fa-zer o denominado perfil dos dados (data profiling). Este tipo deanlises dever ser feito recorrendo a tecnologia especfica, antesdo incio do processo de ETL. Algumas ferramentas de ETL j

possuem este tipo de funcionalidade.

ETAPASPARAA CONSTRUODE UMDATA WAREHOUSE

O essencial para o incio de um processo (e no projecto) de datawarehouse a necessidade de negcio. A empresa tem de sentir quenecessita de algo para consolidar, gerir, apresentar e permitir a anlisecompleta das informaes que possui. Essa necessidade ter de ser umobjectivo definido e encarado como estratgico. Aps o seu apareci-mento e a especificao do objectivo final, dever-se- estar presenteque um data warehouse no um projecto. antes um processo que constitudo por vrios projectos que acompanham o negcio e as mu-danas de mercado. Normalmente, apenas aps o primeiro projectoque os utilizadores finais vem o verdadeiro benefcio de um data wa-rehouse e s nessa altura, com as dificuldades iniciais e com a suaaprendizagem, que melhoram drasticamente a sua definio das suasreais necessidades perante o data warehouse.

Assim, poderemos resumir em alguns passos aquilo que impor-tante considerar quando uma empresa embarca num projecto de bu-

siness intelligence.Apesar de se apresentarem vrios passos, estes no tm de ser

todos executados em sequncia e obrigatoriamente. Devido a dife-rentes condicionantes, como a dimenso do projecto, as reas de ne-gcio envolvidas, etc., alguns passos podero ser eliminados oucombinados para melhor se adequarem a cada caso especfico.

O primeiro passo o desenvolvimento de um businesscase slidoque justifique, de forma indubitvel, o incio de um projecto desta di-menso, respondendo a questes como:

Quais sero as necessidades de negcio para esta iniciativa?


43/160


43

Como que o data warehouse vai ajudar a colmatar essas neces-sidades?

Quais sero os custos potenciais de desenvolvimento e operao/

/manuteno em termos de recursos humanos e infra-estruturas? Quem ser o patrocinador do negcio?

Qual o processo actual de obteno de informao?

A informao que obtida pelos processos actuais fivel?

Aumentaro o data warehouse e as aplicaes de BI a satisfaodos clientes? Aumentaro eles os lucros? Reduziro eles os custos?

Que riscos corremos ao implementar (ou no implementar) um pro-jecto de BI?

Estaremos preparados para esse projecto?

Qualquer empresa tem de encontrar as respostas a todas estasperguntas, antes de iniciar a aventura de data warehousing. A jus-tificao dos custos essencial, tal como a existncia de utilizado-res do negcio e no da informtica que patrocinem a aplicao,

que necessitem dela. O data warehouse transformar os dados eminformao e as aplicaes de BI fornecero essa informao aosutilizadores de negcio, que tomaro por sua vez decises com basenela. Tendo isto em conta, ainda essencial o apoio incondicional daadministrao da empresa, no s pelo facto de se estar a imple-mentar um sistema de apoio tomada de deciso, mas tambm por-que normalmente estes projectos possuem um custo elevado erequerem o envolvimento de todas as estruturas da empresa. Noque se refere ao retorno de investimento num projecto deste gnero,ele calculado, geralmente, tendo em conta nmeros reais de gas-tos correntes e que sero suprimidos, poupanas a nvel da eficin-cia de processos, e rapidez de deciso, tendo em vista, logicamente,um aumento global de lucro.

Quanto ao risco, geralmente esquecido na maioria dos projectos,existem alguns questes a ter em considerao:

A tecnologia a ser utilizada recente? Tem provas dadas no mer-

cado? Quo complexo o ambiente informtico? Os dados esto muito

dispersos? Quantos locais geograficamente separados tero queser suportados?


44/160

44


Existe muita redundncia nos dados? Os dados de diferentes fon-tes podem possuir uma correspondncia linear? Existem padresnos processos de negcio e na informtica?

A equipa que ir implementar o projecto possui a experincia ne-cessria?

Qual ser a rapidez do retorno do investimento?

Estas e muitas outras perguntas devero ser respondidas, pois dasrespostas se concluir, partida, o risco de o projecto ser bem ou malsucedido. Alm do risco, existe ainda a condicionante da preparaoda prpria empresa. Isto quer dizer que tem de existir um oramentoadequado, que os patrocinadores e utilizadores tm de estar prepara-dos para trabalhar horas-extra no projecto e de possuir algum grau deliteracia informticas. Apesar de dependerem cada vez mais da intui-o do utilizador, as ferramentas de BI so inerentemente informticase, como tal, para poder tirar delas o mximo partido, os utilizadorestero de possuir pelo menos um nvel mdio de contacto com aplica-es informticas.

O segundo passo para uma implementao de sucesso a avaliaodas infra-estruturas da empresa, quer a nvel tcnico (software, hard-

ware, rede), quer a nvel no tcnico (metodologias, padres nos pro-cessos, etc.). Aqui surge de novo uma srie de perguntas cujas respostasajudaro a avaliar o real custo da soluo e a percepcionar a verdadeiraabrangncia de um projecto de BI. Como exemplos temos:

necessrio novo hardware? Quanto custa?

So precisos mais recursos humanos para manter o novo hardware?

O novo hardware conseguir acomodar novas exigncias? Inte-gra-se na infra-estrutura existente?

A largura de banda da rede suficiente?

Qual a arquitectura dos sistemas-fonte? Em que formato poderofornecer os dados para consolidao? Ser necessrio middleware?

Ser necessrio adquirir um SGBD? Quanto custa?

Existe capacidade interna para gerir o SGBD?Em relao ao hardware, a sua escalabilidade (capacidade de

suportar um nmero crescente de aplicaes e utilizadores sem terde desperdiar o investimento inicial) e o seu custo so provavel-


45/160


45

mente os elementos mais importantes a referir. No que se refere infra-estrutura de rede, as consideraes mais importantes tm aver com o aumento de trfego e a diminuio de tempo de resposta

para o utilizador final. A escolha do SGBD de crucial importncia,

devendo ser tidos em conta o crescimento do volume de dados, osuporte por parte do vendedor e a facilidade de utilizao. A escolhatambm deve depender de factores como a capacidade de paralelis-mo e performance.

A infra-estrutura no tcnica , infelizmente mas habitualmente,esquecida. Este tipo de infra-estrutura envolve, como j foi referi-do, procedimentos, metodologias, modelos de negcio, linhas deorientao definidas dentro da organizao, etc. Tal como na infra-

estrutura tcnica, h questes especficas que devem ser respondi-das nesta fase:

H modelos lgicos definidos para os sistemas-fonte? Se no, quemser responsvel pela sua criao para este projecto de BI?

Quem far a validao do modelo?

Existe um repositrio de metadados? Se no existe, o que deve serfeito: desenvolver um internamente ou comprar?

Quem so os responsveis por recolher os diversos tipos de meta-dados?

Os padres que existem na organizao so demasiado restritos?Esto documentados?

Existe um programa para avaliar a qualidade e fazer a limpeza dosdados?

Os modelos lgicos representam a viso de negcio sobre os da-dos e as suas relaes no so os modelos das bases de dadosfonte. nestes modelos que se definem as regras de negcio e anormalizao de dados. Os metadados so, como j foi referido, ainformao contextual que transforma os dados em informao. Re-lembramos que importante recolher, registar e inter-relacionar me-tadados de todos os tipos e no apenas, como acontece muitas vezes,guardar os metadados de tipo tcnico.

O terceiro passo para a implementao de uma aplicao de DW essencial: planeamento e projecto. Esta fase envolve toda a equipa.Devido ao tamanho e complexidade das aplicaes em causa, extre-mamente importante dividir o projecto em miniprojectos com abran-


46/160

46


gncia limitada, para que se possa proporcionar algo aos utilizadoresno espao de poucos meses.

A fase de anlise de negcio constituda por quatro seces: adefinio de requisitos, a anlise de dados, a prototipagem e a anlise

do repositrio de metadados.Dependendo do tipo de projecto, a definio de requisitos poder

ser englobada juntamente com as outras trs seces ou enquadra-da antes ou mesmo durante o planeamento do projecto. No que serefere a requisitos, podemos dividi-los em: requisitos funcionais, re-quisitos de dados, requisitos sobre dados histricos, requisitos desegurana e requisitos de desempenho. Os primeiros esto relacio-nados com a entrega dos dados ao utilizador (relatrios, consultas,

cubos OLAP, etc.). Os requisitos de dados envolvem informaosobre que elementos de dados das fontes so necessrios no s

para a aplicao de BI mas tambm para a integrao e estandardi-zao dos dados. igualmente importante definir nesta fase qual aquantidade de histrico que ser necessrio carregar no data wa-rehouse (requisitos sobre dados histricos). De facto, se os dadosque se pretendam possuir se cingirem apenas ao presente e o hist-rico for guardado apenas a partir da, a construo do DW poder

ser mais simples do que se fosse necessrio carregar dados histri-cos j presentes nas fontes. Um outro tipo de requisitos j referidoso os requisitos de segurana, que tm em conta a proteco dosdados do acesso no autorizado. Deve notar-se que importanteque os parmetros de segurana para cada utilizador estejam sin-cronizados entre a aplicao de BI e a base de dados do DW, isto ,um utilizador no dever ter acesso a mais, a menos ou a diferentesdados na base de dados do DW do que tem atravs das ferramentas

de BI. Poder sim ter acesso a um nvel diferente de pormenor.O ltimo tipo de requisitos que dever ser tido em considerao pren-de-se com os requisitos de desempenho. Em relao a este tipo derequisitos, importante educar os utilizadores no sentido de sabe-rem que os tempos de resposta de um DW no so iguais aos de umsistema operacional. pois importante descobrir e registar o queno aceitvel em termos de desempenho, e planear a infra-estru-tura, para que ela seja suficientemente escalvel para enfrentar no-

vos requisitos e maiores quantidades de dados. Para conseguirrecolher todos estes tipos de requisitos, devemos ter em conta asseguintes questes:

De que tipo de informaes precisa o utilizador final?


47/160


47

A que tipo de questes so os utilizadores incapazes de responderhoje? Porqu?

De que dados precisam os utilizadores? Como que eles obtm

esses dados actualmente? Os dados nos sistemas actuais possuem qualidade e esto actuali-

zados?

Quantas e que pessoas necessitam desses dados?

Quantos anos de histrico so necessrios manter?

preciso carregar dados histricos das fontes de dados ou deve ohistrico comear apenas de agora em diante?

Quo seguros tm os dados de ser? Que segurana existe nos sis-temas-fonte?

Quem dever ter acesso aos dados?

Que tempo mximo de consulta a uma aplicao de BI esto osutilizadores dispostos a aceitar?

Haver relatrios susceptveis de serem executados de um dia para

o outro?

Qual a durao e frequncia de utilizao da aplicao de BI du-rante o dia?

Outro passo de importncia crucial num projecto de DW a an-lise dos dados. Por anlise dos dados entende-se a anlise aprofun-dada das fontes de dados para identificar redundncias e falhas dequalidade dos dados, e seleccionar quais sero as fontes mais fi-

veis para o DW e, finalmente, para cada aplicao de BI. fre-quente encontrar fontes heterogneas de dados que contm a mesmainformao sobre os grupos de informao (como os produtos daempresa, ou mesmo os clientes). importante escolher qual destasfontes ir servir melhor as necessidades das aplicaes de BI. Tudoisto, juntamente com a qualidade dos dados, cria um desafio na inte-grao de dados durante o processo de ETL. Assim, preciso fazera limpeza dos dados numa fase (preferencialmente) anterior ao

desenvolvimento do processo de ETL. Por limpeza entende-se acorreco de eventuais defeitos que os dados possam ter como, porexemplo, moradas de clientes incompletas, caractersticas em faltade produtos, etc.


48/160

48


importante ter em considerao que esta tarefa bastante dis-pendiosa e envolve muito trabalho. Assim, essencial estabelecer ummeio-termo entre a correco dos dados todos e a no-correco denenhum. Isto faz-se atravs da anlise cuidada dos dados-fonte e sua

classificao de acordo com um critrio de importncia iniciando oprocesso de correco pelos elementos mais crticos. A prtica mos-tra que o mais acertado no tentar fazer tudo de uma vez e deixarque os elementos menos importantes sejam corrigidos mais frenteno processo de implementao da aplicao de BI. Mais uma vez,

preciso responder a algumas perguntas:

Existem mltiplas fontes de dados potenciais para os mesmos dados?

At que ponto so os metadados de negcio existentes actuais efiveis?

Quem so os detentores da informao das fontes de dados?

A qualidade dos dados-fonte reconhecida?

Qual a qualidade mnima aceitvel para o representante do neg-cio? E para os utilizadores?

Quem ir elaborar o perfil dos dados? Como? Que dados so fundamentais e que dados so insignificantes para o

negcio, de forma a proceder sua correco?

importante criar e implementar um prottipo, de modo a que osstakeholders possam ter uma ideia de como ser a aplicao de BIdepois de instalada. Contudo, nem sempre ser razovel construir um

prottipo completo de uma aplicao de BI; consoante o objectivo final,existem vrios tipos de prottipos desde os que possuem apenas osecrs finais da aplicao, passando pelos que envolvem alguma progra-mao e funcionalidades mnimas, at aos prottipos operacionais, que

possuem todas as funcionalidades da aplicao de BI finalizada e quemuitas vezes servem mesmo de base para o desenvolvimento da aplica-o final. Esta fase dever ser desenvolvida no menor tempo possvel eter objectivos claros. A aproximao por um prottipo a maneira maiseficiente de fazer uma anlise funcional do sistema, uma vez que osutilizadores podero testar e modificar os seus requisitos enquanto ex-

perimentam o prottipo, numa fase do projecto em que o impacto dessetipo de alteraes (requisitos, mbito) no muito elevado. Para seefectuar um bom prottipo dever-se- ter em considerao os seguin-tes elementos:


49/160


49

Definir um mbito pequeno, isto , que no envolva demasiadasreas de negcio;

Escolher os dados-fonte de maior qualidade e apenas uma pequena

quantidade de dados; Testar bem as aplicaes de BI com relatrios que possuam um

esquema relativamente complexo;

Envolver ao mximo os utilizadores finais (sem no entanto seremdemasiados), com diversos nveis de experincia, quer a nvel infor-mtico, quer a nvel de negcio.

O ltimo passo na fase de anlise do negcio a anlise do repo-

sitrio de metadados. Nesta fase devero ser definidos que tipos demetadados devero ser capturados, guardados e entregues aos utili-zadores.

Apesar de j ter sido dada uma definio de metadados, impor-tante referir ainda que os metadados sempre estiveram presentesnos sistemas operacionais. Eles so parte integrante da documenta-o dos sistemas, catlogos das bases de dados, etc. No entanto, osmetadados eram apenas utilizados por pessoas com conhecimentos

eminentemente tcnicos, que mantinham os seus prprios sistemas.Mas, no mundo da BI, os metadados no so apenas para os tcni-cos; eles so importantssimos para os utilizadores finais, porque osauxiliam na localizao dos dados e na sua interpretao dentro doambiente de BI. Os metadados assumem actualmente um novo pa-

pel: o da navegao entre dados: eles devero auxiliar o utilizador aencontrar os dados que necessita dentro do data warehouse. O aces-so ao repositrio de metadados poder ser dado atravs de relat-rios de metadados, um tutor de ajuda online ou mesmo consultasdirectas ao repositrio. Para fazer uma anlise da forma como deveser desenvolvido o repositrio de metadados, devemos dar respostass seguintes perguntas:

Que tipos de metadados de negcios so necessrios?

Que tipos de metadados tcnicos so necessrios?

Quem ser responsvel pelo repositrio de metadados?

Quem ter acesso ao repositrio de metadados? E como?

Servir o repositrio de metadados apenas as aplicaes de BI e odata warehouse ou toda a organizao?


50/160

50


Chegamos agora fase de desenho. Esta fase envolve trs passosessenciais: desenho da base de dados do data warehouse, desenhodo processo de ETL e desenho do repositrio de metadados. No dese-nho da base de dados dever ser efectuada, previamente, a escolhado tipo de diagrama a seguir. Um exemplo o diagrama de relao deentidades (diagrama E-R), que utiliza as regras de normalizao jreferenciadas, permitindo chegar a um desenho de base de dados al-tamente normalizado e estruturado. No entanto, como tambm j foireferido, este tipo de modelo, embora muito utilizado em sistemas ope-racionais, no adequado para data warehouses ou data marts, queservem aplicaes de BI por questes deperformance. Ainda assim,se o objectivo desenvolver um datawarehouse empresarial (EDW

enterprise data warehouse), o modelo E-R, sendo o que permitemaior flexibilidade, o ideal, uma vez que servir de fonte para osdata marts que serviro as aplicaes de BI. Chegados a este ponto,devemos questionar-nos como vamos lidar com enormes volumes de

dados e, aps a definio da forma, os processos que pretendemosmodelizar. Caso o modelo escolhido seja o esquema em estrela ou oesquema snow-flake, deveremos:

construir uma tabela de factos para cada processo escolhido;

definir a granularidade de cada tabela de factos, para cada pro-cesso, especificando qual o nvel de pormenor a apresentar; istodever ser determinado conforme a necessidade de informao

dos utilizadores/decisores (e. g., em termos temporais diria,semanal, mensal ou em termos geogrficos por loja, por re-gio, por pas);

determinar as dimenses de cada tabela de factos;

Figura 3.3Processo deconstruo deum data warehouse


51/160


51

identificar os factos que devem figurar em concreto no modelo;

analisar os atributos das dimenses, de modo a serem estabeleci-das descries completas e uma terminologia adequada;

tomar as decises sobre o projecto fsico: agregaes, dimensesheterogneas, minidimenses;

preparar as dimenses para suportar evolues histricas.

Devemos ter obviamente em conta as respostas s seguintes per-guntas:

A que o nvel de agregao devem estar sujeitos os dados?

Qual o nmero de utilizadores concorrentes?

Qual a dimenso final das bases de dados que iro suportar asaplicaes de BI?

Qual a taxa de crescimento dessas bases de dados?

Que tabelas sero particionadas? Como?

Que tipos de ndices sero mais adequados? Que SGBD ser utilizado?

Os dados-fonte para as aplicaes de business intelligence provi-ro das mais variadas plataformas, que so geridas e mantidas por umavariedade relativamente grande de sistemas operativos e aplicaes.O objectivo do processo de ETL congregar dados destas plataformasheterogneas num formato estandardizado para a aplicao de BI final

e, ao mesmo tempo, integrar e estandardizar os dados. Assim sendo, oplaneamento deste passo bastante mais complicado e moroso do queas fases de desenho da base de dados e do repositrio dos metadados.

ETL um conjunto de processos que permite s organiza-es extrair dados de fontes de informao diversas e refor-mul-los e carreg-los para uma nova aplicao (base de dados,geralmente um data warehouse) para anlise.

O desenho e planeamento do processo de ETL ter de ser expan-

svel e facilmente altervel, uma vez que os requisitos podero sermodificados e novas reas podero ser acrescentadas ao data wa-rehouse. O desempenho do processo de ETL tambm dever ser tidoem considerao, j que o processo ter de se encaixar num intervalo


52/160

52


de tempo limitado o carregamento do data warehouse poder durarumas horas (durante a noite) ou uns dias (e. g., aos fins-de-semana).Assim, apesar de o processo de ETL ser eminentemente sequencial(no se podem carregar as vendas sem carregar os produtos e os

clientes as dimenses vm sempre antes dos factos), o seu desenhoter de ter em conta o mximo paralelismo possvel.

O ltimo passo da fase de desenho do projecto de datawarehou-se o desenho do repositrio de metadados. Existem vrias solu-es comerciais para repositrios de metadados, mas este tipo deaplicaes no geralmente muito popular e no segue um padro,apesar de ser, habitualmente bastante flexvel e expansvel. Os re-

Manual Business Intelligence

Documents

Transcript of Manual Business Intelligence