1 SAP AG 2003, Norberto Harada/ 1Modelagem Multidimensional com BWParte 1 modelo lgicoNorberto HaradaSAP ConsultingBusiness Intelligence / Netweaver ConsultantSetembro/2003Verso do documento:5.0Verso BW: 3.0B2 SAP AG 2003, Norberto Harada/ 2Objetivos do modelo multidimensionalModelagem um assunto controverso pois a competio por diferentes interesses surgem durante a fase de design. Isto explica porque algumas recomendaes de design contradizem-se.PerformanceAspectos deAnliseAspectos deAspectosGlobais deDesign do Data WarehouseObjetivos do modelo multidimensionaln 1 - Oferecer informaes para o usurio final de uma maneira que corresponda a maneira como ele v o negcioDisponibilizar informaes estruturadas que permitem o usurio final navegar facilmente, utilizando qualquer combinao possvel de termos de negcio para ilustrar o comportamento dos KPIsn 2 - Oferecer a base para a implementao fsica que seja compreensvel pelo software ( OLAP Engine ) permitindo a este fcil acesso PerformanceConsistncia / Integridade SemnticaDurante todo o processo de modelagem, procure sempre atingir estes dois objetivos. Em primeiro lugar: criar um modelo compreensvel pelo usurio, e isto no pode ser feito em detrimento do segundo objetivo, que criar um modelo compreensvel pelo software - que faa com que o modelo tenha um tempo de resposta , uma performance, excelente. Um bom tempo de resposta nos padres atuais pode ser algo menor do que 7 segundos. Mas h casos em que 30 segundos um grande avano, se comparados com relatrios que levam horas para rodar.Por outro lado, criar um modelo pensando apenas em performance pode reduzir a usabilidade do modelo, e a utilidade deste para o usurio final.A SAP afirma que h uma controvrsia entre recomendaes de modelagem devido competio entre trs grandes grupos de interesses. Um usurio final trar uma srie de demandas que tendero a priorizar os aspectos de anlise, e embora num primeiro momento alguns usurios no dem a devida ateno a aspectos de performance e aspectos globais de design do Data Warehouse, num outro momento estes outros itens afetaro o desempenho da empresa como um todo. Performance ruim tambm significa mais demora na anlise, na prospeco de fatos, na criao de hipteses e investigao dos dados, e esta demora provoca reduo no desempenho do processo decisrio. Um usurio tambm tende a resolver os problemas de seu departamento isoladamente, deixando de lado aspectos globais de design do Data Warehouse, tais como integridade semntica do banco de dados - como por exemplo - normalizao de conceitos de dados mestre, tais como Clientes, Produtos. Cabe ao modelador balancear estes grupos de interesses, negociar com o usurio final e com o DBA e se responsabilizar pelas decises de modelagem. No h uma frmula mgica pronta para tomar decises sobre todas as situaes. Por exemplo: como modelador, qual caminho a tomar na seguinte situao: num modelo contendo os campos faturamento bruto e descontos + impostos, qual a melhor opo - criar um campo no banco de dados, uma key figure contendo o preo lquido, ou deixar para calcular o preo lquido na query ? Diferentes autores do diferentes solues para este problema - mas nenhum tem a frmula mgica.3 SAP AG 2003, Norberto Harada/ 3Passos bsicos de modelagem 1. Focalizar na estrutura da informao Desenvolver compreenso dos processos de negcio Para fontes no R/3 - criar ou obter o MER da aplicao Levantamento de necessidades de informao2. Focalizar nas necessidades analticas Anlise de gap entre BCT e necessidades Traduzir o MER e as necessidades de informao para Star Schema Criar o Modelo Lgico - Star Schema3. Construir a soluo Traduzir o Star Schema para InfoCubos Criar e implementar o Modelo Fsico Para a SAP estes so os trs passos bsicos de modelagem. O primeiro passo ser detalhado mais frente.O segundo passo, que criar o modelo lgico, todo o assunto deste workshop.O terceiro passo, a criao do modelo fsico, no abordada neste workshop.4 SAP AG 2003, Norberto Harada/ 4Sistema Legado Um sistema operativo atravs do qual realizada a entrada de dados referentes s operaes da empresa. Pode no ser um sistema transacional ou relacional. Geralmente reside em um mainframe. ( Ralph Kimball, The Data Warehouse Toolkit , 1996 ) Sistemas Herdados Sistemas antigos que precisam ser mantidos durante algum tempo at que possam ser gradualmente refeitos e substitudos. A maior parte deles est baseada em mainframes. Os sistemas herdados se parecem com os aeroportos herdados, seria maravilhoso poder reconstru-los do zero, mas essa no uma alternativa vivel. ( Peter G.W. Keen, Guia Gerencial para a Tecnologia da Informao , Ed. Campus, 1996 )O mundo do Data Warehouse um mundo novo, e tem seus prprios conceitos e seu prprio vocabulrio. O termo Legado para algumas pessoas tem o significado que atribui Peter Keen. Para outras, tudo o que no R/3 chamado de legado. Mas para Ralph Kimball,Legado um sistema que pode no ser relacional ou transacional e geralmente reside em um mainframe.5 SAP AG 2003, Norberto Harada/ 5Como Criar ou obter o MER da aplicaoPara fontes no R/3 Entrevista com o Data Architect / Modelador da aplicao ERWin funo Reverse - Engineering Ateno com o tamanho da aplicao ( qtd tabelas ) Aplicaes muito grandes ( ex:ERP ) inviabilizam um MER completo. Focalize apenas nas entidades pertinentes ao escopo.Para fontes R/3 O R/3 uma aplicao muito grande e complexa, inviabilizando um MER completo. Focalize nas principais entidades pertinentes ao escopo.Este primeiro passo agilizar os workshops de requerimentos, o levantamento de necessidades de informao.O primeiro passo da modelagem segundo Kimball:O primeiro passo no design decidir quais processos de negcio a modelar, combinando o conhecimento do negcio com o conhecimento dos dados disponveisObter o MER da aplicao fundamental para o conhecimento dos dados disponveis, importante obt-lo antes de comear a modelagem e mesmo antes de iniciar os workshops de requerimentos. A afirmao de Kimball combinando o conhecimento do negcio com o conhecimento dos dados disponveis pode ser interpretada como: durante os workshops de requerimentos no adianta deixar o usurio divagar sobre quais as informaes que ele quer, se no h de onde obt-las. Exceto se o escopo do projeto prever as alteraes nos sistemas fonte e nos procedimentos do usurio, necessrios obteno das informaes.6 SAP AG 2003, Norberto Harada/ 6CONCEITUAL LGICO FSICO IMPLEMENTAODiferentes aspectos da modelagemNaeem HashmiConceptual ModelEntity Relationship ModelStar Schema ModelAnalytical Data Model Document ModelMultidimensional DatabaseRelational DatabaseDocument DatabaseOLAP MartsODSDataWarehouseData MartsO Modelo Conceitual delineia o fluxo de informao permeando todos os processos de negcio. Descreve como as decises so tomadas para dirigir os processos de negcioO Modelo Lgico define agrupamentos e relacionamentos entre objetos de informao lgicamente similares, em termos de entidades e relacionamentos.O Modelo Fsico descreve definies de estrutura de dados. Depende ostensivamente da tecnologia mais apropriada para necessidades especficas de anlise.O modelo conceitual o desenho do processo. Para o Data Warehouse, o modelo conceitual o desenho do processo decisrio. O fluxo de informao representa a definio dos indicadores que so utilizados para a tomada de decises que afetam o dia a dia, a ttica e a estratgia da organizao. O modelo lgico o design , que planifica e que orienta a implementao da arquitetura tecnolgica necessria construo do Data Warehouse.O modelo fsico, que se funde com o modelo de implementao o planejamento da tarefa de implementao do modelo, que envolve definies de nomes tcnicos, configuraes e parametrizaes do sistema.A tarefa de implementao a atividade de colocar o modelo para dentro da mquina.7 SAP AG 2003, Norberto Harada/ 7Modelo Conceitual um rascunho do modelo lgico, antes de passar pelos 9 decision points utilizado para validao com o usurio final, durante os workshops de requerimentos Por ser um rascunho sem detalhes tcnicos, pode ser utilizado para validao final com o gerente de projeto Pode definir as funes (roles) e tarefas (tasks) que mapeiam o processo decisrio.Durante os workshops de requerimentos, o modelador ao criar um desenho do modelo conceitual, facilita a comunicao com o usurio final e com o DA ou Modelador do sistema fonte.O rascunho basicamente um desenho da tabela de fatos central, contendo os indicadores, kpis, ou key figures - rodeada pelas tabelas de dimenses contendo a descrio resumida de como o usurio necessita analisar os indicadores.O modelo conceitual ainda no o modelo lgico pois ainda no foi submetido aos 9 decision points de Kimball, que so o tema deste workshop.8 SAP AG 2003, Norberto Harada/ 8Modelo Lgico o resultado do: levantamento de necessidades de informaes ( obtido atravs dos workshops de requerimentos ) submetido aos 9 decision points de Kimball com o foco nos objetivos do modelo dimensional e balanceados pelos 3 grupos de interesses. sem detalhes de implementao fsica utilizado: na fase final dos workshops de requerimentos para propor questes para o Modelador BW , que podem gerar novas perguntas nos workshops para a validao com o usurio final e com o gerente do projeto9 SAP AG 2003, Norberto Harada/ 9{ Centro de CustoDiviso }Dim. Centro CustosCliente~ endereo- cidade- estado~ cep- faixa de idade- faixa de renda- estado civil- sexoDim. ClienteFaturamentoQuantidade FaturadaValor PISValor COFINSValor ICMSValor IPIDespesas FinanceirasPreo FOBValor de DescontosNumero de Notas Fiscais Emitidas Preo Mdio a Vista com PIS e COFINSPreo Mdio a Vista sem PIS e COFINSPreo Mdio sem PIS e COFINSPreo Mdio BrutoAnoMes / AnoDiaDim. TempoMaterialGrupo de MaterialDim. MaterialModelo LgicoEste um exemplo padronizao de desenho de modelo lgico. O captulo final contm o Padro de documentao de modelo lgico, descrevendo os detalhes das convenes aqui adotadas.Por hora, apenas observe:- tabela de fatos central, notaes para descrever key figures armazenadas e calculadas- tabelas de fatos rodeada de tabelas dimensionais- considera limitao de qtd. de dimenses do BW- notaes para descrever atributos navegacionais ou no navegacionais- notaes para identificar presena de hierarquias- notaes para identificar chaves compostas- ausncia de nomes tcnicos e tamanhos de campos- desenho do resultado das principais decises de modelagem10 SAP AG 2003, Norberto Harada/ 10Como criar o modelo lgicoO Input para a modelagem o documento gerado nos Workshops de requerimentos com o usurioBW Schema & Star Schema x Snowflake SchemaA metodologia de modelagem de referncia do BW o Star Schema de Ralph Kimball , e no o Snowflake Schema. No BW, como designer voc deve utilizar o Star Schema para criar o modelo lgico.O BW totalmente aderente ao Star Schema.A modelagem do BW referenciada como BW Schema.Ao observar a modelagem fsica interna do BW pela primeira vez, alguns pensam se tratar de um modelo Snowflake. Na verdade a modelagem interna no um Snowflake, isto ser explicado com detalhes no Workshop de Modelagem Fsica do BW.A modelagem de referncia o Star Schema , de Ralph Kimball. Este trabalho uma interpretao da metodologia de Ralph Kimball, adaptada para o BW Schema. Um modelador que j tem conhecimento na modelagem Star Schema do Kimball, aproveitar todo o conhecimento para modelagem no BW.A modelagem Star Schemavoltada principalmente para ROLAP e no se aplica na ntegra para MOLAP. Sendo o BW um servidor ROLAP, grande parte do Star Schema pode ser aplicado no BW Schema.O Star Schema puro mais adequado para modelagem e implementao direta no RDBMS. Algumas tcnicas descritas por Kimball, tais como a maneira de implementar o Slowly Changing Dimension, mudam totalmente no BW. Kimball expe apenas 3 tipos de tratamento para Slowly Changing Dimension, enquanto no BW h 6. Portanto modeladores experientes em Star Schema devem reaprender alguns conceitos.Modeladores experientes em bancos de dados multidimensionais, tais como Essbase, tem um caminho maior a trilhar no reaprendizado.11 SAP AG 2003, Norberto Harada/ 11 A SAP recomenda que o Business Content seja utilizado como template na modelagem A SAP no tem como saber qual ser o volume de registros e os requisitos de anlise do cliente, portanto no se deve utilizar o modelo standard diretamente, sem um processo de modelagem contando que por ser standard, o modelo deveratender a performance e aos requisitos de anlise12 SAP AG 2003, Norberto Harada/ 12Kimballs9 decision points&ASAP for BW( Ralph Kimball, The Data Warehouse Toolkit, 1996 SAP AG, Multi-Dimensional Modeling With BW - ASAP for BW, 2000 )1. Os processos e por conseguinte as tabelas de Fatos2. A granularidade das tabelas de Fatos3. As dimenses das tabelas de Fatos4. Os Fatos incluindo fatos pr-calculados5. Os atributos das dimenses com descrio completa e terminologia apropriada6. Como rastrear Slowly Changing Dimensions7. Os agregados, dimenses heterogneas, minidimensions, query modes e outras decises de armazenamento fsico8. A durao histrica do banco de dados9. A urgncia com a qual os dados so extraidos e carregados no Data WarehouseCriar o modelo lgico, o processo de submeter o InfoNeed - o levantamento de necessidade de informaes - e o desenho do modelo conceitual aos 9 decision points do Kimball.Modelar tomar decises, e segundo Kimball, os pontos acima so nove passos pelos quais o modelador ter que passar. A cada passo, decises devem ser tomadas. Neste trabalho o modelador encontrar alguns critrios atravs dos quais poder embasar suas decises. Estes critrios foram extrados da metodologia da SAP, da metodologia de Ralph Kimball e de outros autores como Frank Mc Guff e a prpria experincia de consultores BW.Mas lembre-se que no h frmula mgica, devendo o modelador manter em mente os objetivos do modelo dimensional e os trs grupos de interesse: aspectos de anlise, aspectos de performance e aspectos globais de design do data warehouse.13 SAP AG 2003, Norberto Harada/ 13Ns recomendamos que estas nove decises sejam feitas nesta ordem determinada Ralph Kimball chapter 12 importante citar que Kimball recomenda que estes nove passos sejam trilhados nesta ordem determinada.s vezes tendenciamos a iniciar pelo lado mais fcil , iniciando pelo passo sobre o qual temos mais informao ou sobre o qual nos sentimos mais confortveis.14 SAP AG 2003, Norberto Harada/ 141. Os processos e por conseguinte as tabelas de FatosO primeiro passo no design decidir quais processos de negcio a modelar, combinando o conhecimento do negcio com o conhecimento dos dados disponveis Conhecer os dados disponveis , significa: Criar ou obter o MERda fonte de dados ou Conhecer a parametrizao do R/3 Lembre-se de priorizar as entidades do MER, pertinentes ao escopoAps o desenho do modelo conceitual, temos um rascunho do modelo lgico voltado principalmente para atender aos requisitos de anlise do usurio.Neste primeiro passo, o modelo pode ser desmembrado em mais de um Neste passo o modelador estar desenhando a tabela de fatos, que o elemento central do InfoProvider.15 SAP AG 2003, Norberto Harada/ 15 Tabela de fatos armazena informaes em nivel atmico e agregado sobre transaes, como valor de vendas. Estas informaes so chamadas Fatos, no BW so chamadas Key Figures ( em portugus : Indices ) A tabela de Fatos faz parte do InfoCubo InfoCubo = tabela de fatos + dimenses + master data + textos + atributos + hierarquias + agregados + algoritmosPara efeito de conveno, neste trabalho adotaremos Key Figure para denominar os Indicadores, PI , KPIs, ou Indices. No BW em portugus, as Key Figures foram traduzidas por Indices. No adotamos Indice para evitar confuso com a definio de Indices de Banco de Dados, utilizado no jargo de RDBMS.Indicadores ou KPIs ( Key Performance Indicator ) tem o mesmo significado.Indicadores so formados por key figures. Uma key figure nem sempre um Indicador por si s. Um indicador geralmente o composto de key figures.16 SAP AG 2003, Norberto Harada/ 16Decidir se os indicadores levantados , sero modelados em uma ou mais tabelas de fatos Separe astabelas de fatos por processos( assuntos ) Utilize o BCT como template , ex: no BCT h 3 cubos para a rea comercial: cubo de Clientes, cubo de Vendas, cubo de Remessas criar a KPI Matrix pode dar indicao das tabelas de fatosFatos de VendasFatos de ClientesNeste primeiro passo, Kimball recomenda separar as tabelas de fatos por processos - ou assuntos.A SAP recomenda que o Business Content seja utilizado como template, uma vez que seus InfoCubos foram modelados por especialistas altamente capacitados,que estudaram a realidade em diversas empresas world-class.Metodologia de Data Warehouse de Ralph Kimball descreve uma tcnica chamada KPI Matrix - que no abordaremos aqui. Em resumo KPI Matrix uma matriz de KPIs versus Dimenses.O nvel de detalhe das informaes um critrio para decidir se a tabela de fatos ser separada, este tpico ser abordado mais adiante no prximo passo: A granularidade das tabelas de fatos.17 SAP AG 2003, Norberto Harada/ 170NUH 6U8 PR00 00AT 8ALP 00AT 0ELP 0AT |LP 00TY 0PR| 00TY 0PR| 0TY PR|1 C1 P1 1998 31 5 100 0 0 0 02 C2 P1 1998 32 10 200 0 0 0 03 C1 P2 199Z 33 1 130 0 0 0 01 C2 P2 199Z 32 8 150 0 0 0 01 C2 P2 1998 32 -2 -10 0 0 0 01 C1 P1 1998 02 0 0 5 100 0 02 C2 P1 1999 01 0 0 Z 120 0 02 C2 P1 1999 02 0 0 3 80 0 03 C1 P2 1998 01 0 0 2 0 0 01 C2 P2 1998 02 0 0 110 0 01 C1 P1 1999 81 0 0 0 0 5 1002 C2 P1 1999 81 0 0 0 0 10 2003 C1 P2 1998 82 0 0 0 0 1 130Order - Delivery - Billing CubeCommonCharsSalesCharsDeliveryCharsBillingCharsSalesKeyfsDeliveryKeyfsBillingKeyfsEvite modelar Key Figures que s so preenchidas para determinados valores de uma dimenso.Isto pode indicar a necessidade de uma outra tabela de fatos. 12Neste exemplo, as colunas representam as caractersticas (1) e key figures (2), as linhas representam registros de movimento.Observe que as caractersticas 0DAT e SALP s so preenchidas para informaes de vendas (sales char) , assim como as key figures 0QTY, 0PRI. Quando as caractersticas de vendas esto preenchidas, as key figures de vendas tambm esto preenchidas mas no h informaes de remessa (delivery chars) , ou faturamento (billing chars).Deste modo, em cada registro,as key figures s esto preenchidas para suas respectivas caractersticase as demais permanecem zeradas.Esta ocorrncia pode indicar a necessidade de criar outras tabelas de fatos. Neste exemplo, o modelador poderia criar uma tabela de fatos - um InfoCubo - para vendas, outro para remessas e outro para faturamento.Entretanto os requisitos de anlise podem demandar anlises com cruzamento de informaes de vendas, faturamento e remessa. A soluo para este requisito de anlise a criao de umMultiCubo. 18 SAP AG 2003, Norberto Harada/ 18SalesCubeBillingCubeSalesDeliveryBillingMulti-CubeMulti-Cube QueriesBasic-Cube Queries Basic-Cube QueriesDelivery CubeBasic-Cube QueriesUma abordagem seria criar tabelas de fatos separadas, e utilizar o recurso MultiProvider do BW para fazer queries cruzando dados entre os cubos.Utilizar um MultiProvider uma abordagem com mais performance, mais economia de espao em disco e mais transparente.O MultiProvider resulta em enviar queries em paralelo para os BasicCubes. Um UNION subsequente cria o result set.A SAP afirma que Utilizar um Multicubo uma abordagem com mais performance, mais economia de espao em disco e mais transparente. O multicubo ganha em performance pois utiliza o recurso de paralelizao de queries, executando diversas queries - uma para cada BasicCube que o compe - ao mesmo tempo. A transparncia se deve pois o Multicubo apresenta-se parao usurio final como um InfoCubo convencional. Para o usurio final no h distino entre um MultiCubo ou um BasicCubo.A economia de espao ocorre pois o MultiCubo no armazena dados, ele resultado de um UNION entre result sets dos BasicCubes que o compe.19 SAP AG 2003, Norberto Harada/ 19Espao desperdiado pela key figure em brancoTabela de FatosDim_1 Dim_2 Dim_3 KF_1 KF_2 KF_3Espao ocupado por um novo Infocubo criado especificamente para a key figure em brancoEspao economizado ao criar um novo Infocubo especificamente para a key figure em brancoCriar um novo cubo para economizar espao, deve ser bem calculado para evitar consumo de mais espao do que o economizado.Considere o espao ocupado pelas chaves da dim table e das dim tables em si, criadas para o novo cubo.Os critrio para decidir pela separao de key figures que so preenchidas somente para determinados valores de uma dimenso, o ganho em performance decorrente da reduo da esparsividade da tabela. Como benefcio adicional h a economia de espao em disco. As key figures no preenchidas continuam a ocupar espao, mesmo sendo comprimidas.O espao do novo Infocubo deve ser bem calculado para evitar que este consuma mais espao que o economizado. O modelador pode fazer o clculo abaixo para auxiliar em sua deciso. O clculo simplificado e no considera o tamanho das dim tables do novo InfoCubo.Cada chave de dimenso na fact table ( na ilustrao identificados por Dim_1, Dim_2, Dim_3 ) ocupa 10 bytes.Key figures (na ilustrao identificado por KF_1 , KF_2, KF_3 ) ocupam em torno de 16 bytes (dependendo do tipo de dado).Eo = qtreg_o * ( ( qtdim * 10 ) + (qtkf * 16 ) ).Ec =qtreg_c * ( qtkf * 16 ).Onde:Eo => Espao ocupado pelo novo InfoCuboEc => Espaoeconomizadoqtreg_c => estimativa da quantidade de registros na fact tableorigemqtreg_o => estimativa da quantidade de registros na nova fact tbqtkf => quantidade de key figures a serem separadasqtdim => quantidade de dimensesResultado: Eo / Ec deve ser < 120 SAP AG 2003, Norberto Harada/ 20Dados RecentesDados HistricosMulticuboCubo Particao 1Cubo BsicoCom agregadosCubos Particao nCubo BsicoCom agregadosCubo Particao 2Cubo BsicoCom agregadosCubo de CargaCubo BsicoSem agregadosDataSource, ODS, PSA etc...Filtra criterio nExtrao, rollup e excluso de dados do cubo de carga (periodo noturno ou semanal)Sugesto de Modelagem para modelos com grande volume de registrosFiltra criterio 2Filtra criterio 11) Registros distribudos entre os Cubos: Cubo Particao 1, Cubo particao 2, Cubos Particao 'n'.2) Distribuir os registros de forma a aproveitar o paralelismo dasqueries.3) O ideal seria se os "Cubos Partio" se tornassem estticos com otempo.4) O Cubo de Carga, sem agregados, recebe os dados da carga5) A carga poderia ser carga noturna, ou em casos extremamente necessrios at por hora.6) O processo de extrao / excluso de registros do Cubo de Carga podeser implementado por archiving por questes de integridade7) O rollup poderia ser noturno ou semanal, no necessrio que rodeLogo aps a carga8) Haveria independncia entre a carga e o rollup9) A ausncia de agregados no Cubo de Carga evitaria dados indisponveis por falta de rollup21 SAP AG 2003, Norberto Harada/ 21Kimballs9 decision points&ASAP for BW( Ralph Kimball, The Data Warehouse Toolkit, 1996 SAP AG, Multi-Dimensional Modeling With BW - ASAP for BW, 2000 )1. Os processos e por conseguinte as tabelas de Fatos2. A granularidade das tabelas de Fatos3. As dimenses das tabelas de Fatos4. Os Fatos incluindo fatos pr-calculados5. Os atributos das dimenses com descrio completa e terminologia apropriada6. Como rastrear Slowly Changing Dimensions7. Os agregados, dimenses heterogneas, minidimensions, query modes e outras decises de armazenamento fsico8. A durao histrica do banco de dados9. A urgncia com a qual os dados so extraidos e carregados no Data Warehouse22 SAP AG 2003, Norberto Harada/ 222. A granularidade das tabelas de FatosO segundo passo no design decidir pela granularidade da tabela de fatos em cada processo de negcio. R. Kimball A granularidade diz respeito ao nvel de detalhe ou de resumo contido nas unidades de dados existentes no data warehouse. Quanto mais detalhe, mais baixo o nvel de granularidade. Quanto menos detalhe, mais alto o nvel de granularidade Como Construir o Data Warehouse -W.H.Inmon - 1997 - Campus - pg. 45Alto nvel de detalhe=Baixo nvel de granularidadeBaixo nvel de detalhe=Alto nvel degranularidadeO segundo passo escolher a granularidade. Este termo ainda tem provocado um pouco de confuso entre os profissionais de Data Warehousing, pois alguns interpretam granularidade como nvel de detalhe. Interpretando assim, alta granularidade seria compreendido como alto nvel de detalhe, quando o conceito oficial dita exatamente o oposto. fcil memorizar o conceito, substituindo mentalmente a palavra granularidade pela palavra consolidao. Alta consolidao algo muito resumido, baixa consolidao algo detalhado.23 SAP AG 2003, Norberto Harada/ 23Escolher a granulao do processo de negcio. The grain is the fundamental atomic level of data to be represented in the fact table for this process.grain: s. gro , semente, partcula, ncleo, granulaoA granulao o nivel atomico fundamental dos dados a serem representados na tabela de fatos. Granulaes tpicas so transaes individuais, instantneos dirios, instantneos mensais. impossvel prosseguir para o passo 3 sem definir a granulao.R. Kimball chapter 2Parte desta confuso ocorre devido definio do Kimball, que diz que a granulao o nvel atmico dos dados.Para encerrar este assunto, o trecho abaixo do documento BW Operational Data Store.doc mostra que a SAP est alinhada com o conceito de mercado.With respect to mySAP.com source systems, the strategic objective of SAP BW is to incorporate the lowest level of granularity (document level, line item) and to allow reporting on this level. importante ressaltar a observao de Kimball, que impossvel passar para o passo 3 sem decidir sobre a granularidade.24 SAP AG 2003, Norberto Harada/ 24 Decidir a granularidade significa: Definir qual o nvel de detalhe das dimenses do Cubo, avaliando o impacto no tamanho das tabelas de Fatos e Dimenses e consequentemente, o impacto na performance O mais atmico atributo das dimenses define a granularidade da informao. A deciso pela granularidade deve pesar: Anlise dos dados (necessidades de informao ) Performance Espao em disco ( considere o histrico ) Tempo de CargaPor exemplo,o cadastro de clientes chega a 200 mil registros. Negociando requisitos de anlise com o usurio, o modelador pode chegar a um acordo que define que apenas anlises por grupo de clientes so essenciais.Outra alternativa poderia ser trazer somente clientes A, por exemplo: uma empresa possui clientes que vo desde grandes distribuidores at pequenas lojinhas de esquina. Negociando a granularidade com o usurio, o modelador poderia chegar a um acordo em que apenas os clientes Aseriam carregados no Data Warehouse. A rotina de extrao poderia utilizar algum campo que classifique o cliente, existente no OLTP , ou o critrio Top n poderia ser utilizado. OTop n seria a gerao de uma curva ABC, mensalmente no OLTP por sua vez geraria uma tabela de cdigos de clientes a levar ao Data Warehouse.25 SAP AG 2003, Norberto Harada/ 25Fonte de dados20.000 registros por diaTabela de Fatos comdados em nvel de detalhe dirio dos ltimos 3 anosDuas Tabelas de FatosNvel de detalhediriodados do ms correnteNvel de detalhemensaldados ltimos 3 anos

Outro critrio para decidir se os indicadores existiro em uma ou mais tabelas de fatos a granularidade associada durao histrica do banco de dados (passo 8).Quando a quantidade de registros na granularidade desejada e na durao histrica prevista provocar uma exploso na tabela de fatos, ou seja, fizer com que a quantidade de registros na tabela de fatos seja demasiado grande, deve-se negociar com o usurio diferentes duraes histricas para diferentes granularidades.No exemplo da ilustrao acima, a fonte de dados gera 20.000 registros por dia. Se esta quantidade de registros fosse armazenada em granularidade diria por 3 anos, a tabela de fatos conteria 15.840.000 registros.Pode-se negociar com o usurio qual a durao histrica para os dados para cada granularidade segundo a necessidade de negcio para a informao. O usurio pode definir que a granularidade diria s necessria para anlises dos dados do ms corrente, e que os dados do ms anterior e demais meses dos ltimos 3 anos podem ser armazenados em granularidade mensal. Esta soluo demandaria uma modelagem em que duas tabelas de fatos praticamente idnticas seriam desenhadas: uma com dados em nvel dirio armazenando somente o ms corrente e outra comos dados em nvel mensal armazenando os ltimos 3 anos.26 SAP AG 2003, Norberto Harada/ 26 Conceitualmente a tabela de Fatos pode aceitar numero de documento como granularidade Kimball define isto como Transaction Level Fact Table Para atender a esta necessidade o recurso de modelagem chama-se Degenerated Dimension que basicamente uma dimenso contendo apenas o nmero do documento Em linhas gerais, uma tabela de fatos com 2 milhes de registros por ano uma tabela leve para um modelo dimensional Porm se as queries possuem a caracterstica de varrer a tabela de fatos, 2 milhes passam a ser uma tabela mdiaAt meados do ano 2000 havia um paradigma ditando que o Data Warehouse no deveria ter dados no nvel atmico (documento, item ). Por outro lado, Kimball e Inmon aceitam dados em nvel atmico no data warehouse, sendo que este procedimento de certa forma recomendado por estes autores. Kimball denomina uma tabela de fatos criada no nvel documento, como uma : Transaction Level Fact Table.O recurso Degenerated Dimension suportado fisicamente pelo BW, atravs de um check-box na definio da dimenso, que indica que a dimenso Line Item Dimension. Detalhes sero discutidos no Workshop de Modelagem Fisica.Um dos critrios para se decidir por granularidade o tamanho da tabela de fatos. Para quem no est familiarizado com sistemas de gerenciamento de banco de dados pesados, como Oracle, bom saber que 2 milhes de registros por ano algo leve. Para o Oracle, quantidades de registros na casa dos 20 mil mais do que leve, no nada.27 SAP AG 2003, Norberto Harada/ 27 Decidir entre armazenar detalhes: No InfoCubo No ODS( vide exemplo mais adiante em passo 2 - modelos com mais de uma data ) No armazenar detalhes , obtendo-os por: Drill Through Remote CubePode-se armazenar detalhes, no nvel documento, no InfoCubo utilizando Degenerated Dimension.Tambm pode-se armazenar detalhes no ODS e fazer um Drill Down entre uma query ou cubo com mais granularidade, para uma query no ODS que pode conter os documentos.Pode se optar tambm por no armazenar detalhes.No caso de uma instalao BW extraindo dados do R/3, o BW possui recursos para fazer o Drill Through - que um Drill Down at a transao que gerou o documento. O BW tambm tem um recurso chamado Remote Cube, em que os dados so resgatados on-line do sistema operativo R/3. Este recurso poderia ser utilizado para obter os detalhes, mas deve ser utilizado com cuidado pois pode provocar degradao de performance no R/3.O uso desenfreado de Remote Cubes podefazer com que um dos objetivos tcnicos do Data Warehouse que disponibilizar um ambiente de anlise com alta performance sem impacto para o ambiente transacional, deixe de ser cumprido, fazendo com que o ambiente de Data Warehouse impacte diretamente no desempenho do ambiente transacional.28 SAP AG 2003, Norberto Harada/ 28odsDatawarehouseCorporate information factoryO BW aceita a arquitetura Inmon, ODS = enterprise data warehouse. Abordagens:1) arquitetura integrada do BW2) arquitetura compostaO BW aceita a arquitetura Inmon, ODS = enterprise data warehouse. Abordagens:1) arquitetura integrada do BW2) arquitetura compostaERPData WarehousedatastagingareaO BW aceita a arquitetura Kimball. A PSA e o ODS=data staging areaInfoCubos = data marts. O BW aceita a arquitetura Kimball. A PSA e o ODS=data staging areaInfoCubos = data marts. 29 SAP AG 2003, Norberto Harada/ 29Data flow modeling standards2design frameworkThere are a few myths floating around about dimensional modeling that deserve to be addressed.Myth # 1 is that implementing a dimensional data model will lead to stovepipe decision support systems.A source of this myth, in our opinion, is the designer struggling with fact tables that have been prematurely agregated.R. KimballData martsOLTPApplicationcustomerproductMkt segDay/month/yystoredocumentitemSales valuecustomer productMkt segmentMonth/YearstoreSales valueData mart Xcustomer productDay/month/yySales valueData mart YPRG 1PRG 230 SAP AG 2003, Norberto Harada/ 30financesalesAplicaoOLTPData MartBuilding the data mart directly from the applications first appears to be cheap, easy and fast.The interfaces shown in figure (above) shows that a program must be written, maintained and requires resources every time it is executed.The resources required by the interface become more relevant when it is considered that the environment depicted for the data mart and the data warehouse is hard realistic. The diagrams shown in figure (above) represent the world of DSS when the FIRST data mart is built, not the world when the LAST data mart is built.W.H.Inmon31 SAP AG 2003, Norberto Harada/ 31financesalesmarketinghrengineergactuarialaccountgauditingOLTPapplicationData MartFigure (left) shows that the interface between the applications and the data marts is a very complex one. There are MANY programs that interface the two environments that must be built and maintained. In addition, the amount of hardware required to move the data along all of the interfaces is considerable.W.H.Inmon32 SAP AG 2003, Norberto Harada/ 32financesalesmarketinghrengineergactuarialaccountgauditingOLTPapplicationData MartIt is recognized that alternate forms of data warehousing, where there are data marts but no central enterprise warehouse, are popular and are being built in many places. It is also recognized that this particular architecture has severe architectural limitations and is an unstable structure of the DSS environment for the long termW.H.InmonInmon position against data martenterprisedatawarehouseThe central data warehouse avoilds the stovepipingIsolated stovepipe data marts that cannot usefully be tied together are the bane of the data warehouse movement. They are much worse than a simple lost opportunity for analysis. Stovepipe data marts perpetuate incompatible views of the enterprise. Stovepipe data marts enshrine the reports that cannot be compared with one another. And stovepipe data marts become legacy implementations in their own right, where, by their very existence, they block the development of an integrated enterprise data warehouse.R. Kimball 33 SAP AG 2003, Norberto Harada/ 33Data flow modeling standards2design frameworkIf the designer had started with a fact table that had been aggregated up to weekly sales totals by store, then there would be all sorts of problems in adding new dimensions, new attributes and new facts. R. KimballExtratores que agregam dados provocam o stovepipingData martsOLTPApplicationcustomerproductMkt segDay/month/yystoredocumentitemcustomer productMkt segmentMonth/YearstoreSales valueData mart Xcustomer productDay/month/yySales valueData mart YPRG 1PRG 2Sales valueFor instance: the data mart X was created with following granularity: month/year, customer and product. The program PRG1 was coded to populate that data mart, extracting data directly from OLTP application, instead of extracting from a Inmons data warehouse.Later, the data mart Y is created at following granularity: day/month/year, customer, product, segment and store. As extractor program PRG1 cant delivery data on that granularity, a new program PRG2 have to be coded.34 SAP AG 2003, Norberto Harada/ 34Data flow modeling standards2design frameworkOLTPApplicationPRG Current level of detail(Inmons concept)Staging Area(Kimballs concept)enterprisedata warehouse(Inmons concept)InfoSources(BW concept)customer productMkt segmentMonth/YearstoreSales valueData mart Xcustomer productDay/month/yySales valueData mart YcustomerproductMkt segDay/month/yystoredocumentitemSales valuecustomerproductMkt segDay/month/yystoredocumentitemSales valueThe correct data flow modeling is like appears on the ilustration above: the data have to be brought from the OLTPon the lowest granularity as possible, preferably the current level of detail found at OLTP. The data is delivered to data marts from a central area, called Staging Area, enterprise data warehouse or InfoSources.35 SAP AG 2003, Norberto Harada/ 35Data flow modeling standards2design frameworkWith respect to mySAP.com source systems, the strategic objective of SAP BW is to incorporate the lowest level of granularity (document level, line item) and to allow reporting on this level. With BW 2.0 SAP provides the details for almost all of the application areas including MM and B2B procurement, SD and CRM, FI-AP/AR, FI-AA, FI-TV, CO-OM, CO-PA, PP, QM, PM, APO, HR-PA, HR-PE, PS.Whereas the level of granularity of data offered by legacy system is under the responsibility of the customer.SAP white paper BW Operational Data StoreThe BW Business content is already adherent to that data flow modeling standard.Every customer InfoSource / DataSource must be modeled to deliver data at current level of detail. The use or not of ODS layer is another topic of discussion.OLTPApplicationBCT Current level of detail(Inmons concept)Staging Area(Kimballs concept)enterprisedata warehouse(Inmons concept)InfoSources(BW concept)customerproductMkt segDay/month/yystoredocumentitemSales valuecustomerproductMkt segDay/month/yystoredocumentitemSales value36 SAP AG 2003, Norberto Harada/ 36odsDatawarehouseCorporate information factoryODS modelado com enterprise data warehouseODS modelado com enterprise data warehouseERPData WarehousedatastagingareaDataSource modelado como data staging area, sem persistencia de dadosDataSource modelado como data staging area, sem persistencia de dados37 SAP AG 2003, Norberto Harada/ 37Kimballs9 decision points&ASAP for BW( Ralph Kimball, The Data Warehouse Toolkit, 1996 SAP AG, Multi-Dimensional Modeling With BW - ASAP for BW, 2000 )1. Os processos e por conseguinte as tabelas de Fatos2. A granularidade das tabelas de Fatos3. As dimenses das tabelas de Fatos4. Os Fatos incluindo fatos pr-calculados5. Os atributos das dimenses com descrio completa e terminologia apropriada6. Como rastrear Slowly Changing Dimensions7. Os agregados, dimenses heterogneas, minidimensions, query modes e outras decises de armazenamento fsico8. A durao histrica do banco de dados9. A urgncia com a qual os dados so extraidos e carregados no Data Warehouse38 SAP AG 2003, Norberto Harada/ 38Tabela de FatosPacoteDim. PacoteMes/AnoAnoDiaDim. TempoResponsvelProprietrio- UFDim. ResponsvelUnidade / MoedaDim. Unidade No BW Schema, dimenses contm caractersticas, e caractersticas podem possuir atributos.3. As dimenses das tabelas de Fatos Limite de 16 dimenses 3 das quais so fixas: Tempo, Unidade e Pacote . Cada dimenso aceita at 248 caractersticas.Importante: No mercado comum entender que uma dimenso s aceita uma caracteristica, logo dizer que o BW s aceita 16 dimenses parece uma grande limitao. Na verdade o BW aceita 16 x 248 + atributos navegacionais como dimenses.Neste passo, o modelador aps ter definido se ir criar um cubo ou dois, e qual ser a granularidade, comear a definir as dimenses do InfoCubo. necessrio lidar com a limitao de quantidade de dimenses do BW. Porm, o modelador deve ter conhecimento que a dimenso no BW no tem a mesma conotao que a dimenso de um banco de dados multidimensional MOLAP, como o EssBase.39 SAP AG 2003, Norberto Harada/ 39odsDatawarehouseCorporate information factoryModelos MOLAP : mais restries de modelagem oferecem mais performance flexibilidade para queries ad-hocModelos MOLAP : mais restries de modelagem oferecem mais performance flexibilidade para queries ad-hocERPData WarehousedatastagingareaModelos ROLAP : Mais recursos de modelagem Menos performance do que MOLAP Mais opes para tuning de performance Flexibilidade para queries ad-hoc deve ser controladaModelos ROLAP : Mais recursos de modelagem Menos performance do que MOLAP Mais opes para tuning de performance Flexibilidade para queries ad-hoc deve ser controlada40 SAP AG 2003, Norberto Harada/ 40Tipos diferentes de usurios em ambiente OLAPaltabaixaConsumidor de informaesanalistaautor70%20%10%Necessidade de recursos analticos Definio de queries queries ad-hoc Anlise multidimensional Navegao pr-definida e auto-explicativa Colees de dados prdefinidas Relatrios estticosPower-userend-user41 SAP AG 2003, Norberto Harada/ 41Modelagem diferente para usurios diferentesaltabaixaConsumidor de informaesanalistaautor70%20%10%Necessidade de recursos analticosModelos para oferecer queries ad-hoc Uma caracterstica por dimenso Poucos atributos Acesso somente para usurios qualificadosModelos para consumidores de informao Modelos utilizando todos os recursos do BW Power user cria queries para disponibilizar para os consumidoresPower-userend-user42 SAP AG 2003, Norberto Harada/ 42PAA - CustosAtividadeDim. AtividadeMes/AnoAnoDiaDim. TempoDim. ProprietarioUnid. NegcioDim. Unid. NegcioOTDim. OTProprietrio?Decidir quais sero as dimenses. por exemplo :Como modelar Proprietrio da Unidade de Negcio, como uma caractersticana dimenso ou como atributoda caracterstica unidade de negcio ?Durante a elaborao do modelo conceitual, o modelador j tem delineado as dimenses. Entretanto o modelo ainda no est fechado.Neste passo o modelador tomar decises a respeito das dimenses, tais como no exemplo acima. Criar uma dimenso a mais para Proprietrio, ou colocar proprietrio na mesma dimenso que Unidade de Negcio?Adiante veremos alguns critrios para direcionar as decises quanto criao de dimenses e definio de suas caractersticas.43 SAP AG 2003, Norberto Harada/ 43Caractersticas com relacionamento 1:N deveriam ser modelados na mesma dimenso. Ex: grupo de material e materiais, unidade e proprietrio.Estes atributos podem ser definidos de duas formas:como caracteristicas de uma dimenso oucomo atributos navegacionaisPor enquanto no se preocupe onde colocar o atributo, pois ser tratado mais adiante no 5o. Decision PointUnid. Negcio ProprietarioDim. Unid. NegcioMaterialGrupo MaterialDim. MaterialClienteRegiaoPaisEstadoCidadeDim. ClienteUnid. NegcioProprietarioDim. Unid. Negcio?1 212O primeiro critrio para decidir se duas dimenses sero criadas, uma para cada caracterstica, ou se apenas uma dimenso ser criada contendo as duas caractersticas o relacionamento entre as informaes das caractersticas.Se o relacionamento for 1:N a primeira recomendao modelar as duas caractersticas na mesma dimenso.Duas ou mais caractersticas podem ser ser modeladas na mesma dimenso de duas maneiras: 1) como caractersticas de uma dimenso ou 2) como atributo navegacional de outra caracterstica.Na opo 1, a dimenso Unid. Negcio conteria os dois InfoObjects, Unid. Negcio e Proprietrio.Na opo 2, a dimenso Unid. Negcio conteria apenas o InfoObject Unid. Negcio e este por sua vez teria um atributo, o InfoObject Proprietrio.A deciso quanto s opes deve passar por critrios que sero descritos mais frente no 5o. Decision point, e principalmente pelo 6o. Decision point, que o tratamento do Slowly Changing Dimension.44 SAP AG 2003, Norberto Harada/ 44 No Star Schema convencional, Dimenses so denormalizadas e armazenam atributos sobre os dados armazenados na tabela de fatos, e dados textuais, no BW as DIM Tables contm somente cdigosC o d . C l i e n t e C l i e n t e R e g i a o S e g m e n t o0 0 0 0 0 0 0 0 0 1 A B C C o r p A S I A Q u i m i c o0 0 0 0 0 0 0 0 0 2 X Y Z C o r p E U R O P A O i l & G a s0 0 0 0 0 0 0 0 0 3 A C M E I n c . U S A T o d o sTabela de dimenso Star Schema, o browsing feito por textoCod.Cliente Data Valor Qtd0000000001 01/01/01 10 50000000002 01/01/01 20 60000000003 01/01/01 30 7Tabela de Fatos Star SchemaPara compreender alguns critrios de deciso que sero expostos adiante, necessrio revisar alguns conceitos bsicos do Star Schema convencional e da modelagem fsica interna do BW.No Star Schema convencional, o modelador define uma tabela de dimenses como uma tabela ligada diretamente tabela de fatos, atravs da chave natural ( por exemplo: o cdigo do cliente no sistema operativo ). A tabela de dimenses contm textos como a descrio do cliente, e textos dos atributos, como segmento de mercado, regio, pas. No Star Schema, a tabela de dimenso cliente, por exemplo, no tem uma chave estrangeira para uma outra tabela contendo as chaves e descries dos segmentos de mercado.No BW, a tabela de dimenses em si, contm apenas cdigos, no contm textos. O que implica , dentre vrias coisas, em que no h impacto de performance relacionada a tamanho de campos de texto.O layout da modelagem fsica interna do BW ser tratada no Workshop de modelagem fsica BW.45 SAP AG 2003, Norberto Harada/ 45Tabela de FatosProduto- LinhaCorDim. ProdutoSID ID Codigo Cor1 45534 Marinho2 56453 Preto3 24543 PinkSID ID Codigo Produto Linha1 XA01 Sapato Social Masc2 XA02 Sapato Esport Masc3 XA03 Bota Trekking FemSID IDProdutoSIDIDCorDIMID1 1 11 2 22 2 33 2 43 3 5Tabela de FatosDados Mestres Cor Dados Mestres ProdutoProduto Cor Qtd.Sapato Social Marinho 10Sapato Social Preto 20Sapato Esport Preto 30Bota Trekking Preto 40Bota Trekking Pink 50Sapato Social Marinho 5Sapato Social Preto 10Sapato Esport Preto 1Bota Trekking Preto 10Bota Trekking Pink 1Registros de MovimentoDIM TABLEDIM ID Qtd.1 102 203 304 405 501 52 103 14 105 1No BW Schemaa tabela de dimenses DIM TABLE contm apenas cdigos. No exemplo acima temos uma dimenso produto com as caractersticas Produto e Cor. Observe que a tabela de dados mestre de produtos contm 3 produtos e a tabela de dados mestres de cor contm 3 cores. A DIM Table contm as combinaes entre produto e cor, mas no todas as combinaes ( 3 x 3 ) somente as combinaes para as quais hregistros de movimento. Observe que Sapato Esport no registro demovimento aparece duas vezes, mas somente na cor preto. Na Dim Table na coluna SID ID Produto, o cdigo 2 que o SID ID do Sapato Esport aparece apenas uma vez para a cor cujo SID ID Cor 2.Cada combinao de produto e cor na Dim Tableser referenciada neste trabalho como instncia para efeito didtico. Na prxima transparncia huma recomendao sobre quantidade de instncias.Observe ainda que a tabela de fatos no contm foreign keys diretamente para as tabelas de dados mestres de produtos e cor, contm apenas foreign keys para a Dim Table. Esta por sua vez est ligada s tabelas de produtos e cor.A ilustrao acima apenas didtica, o formato das tabelas de Dados Mestres e SID so mais complexas e sero abordadas no Workshop de Modelagem Fsica BW.46 SAP AG 2003, Norberto Harada/ 46Dimenses devem ser modeladas de maneira que o numero de instncias seja pequena.Regra emprica 1: famahho da fabeTa de d1mehso* 1 famahho da acf fabTedeve ser menor que 15%* em qtd registrosRegra emprica 2:Uma dimenso com at 20.000 registros de tamanho mdio para um hardware leve. 200.000 registros seria um tamanho mdio para um hardware pesado. Acima deste nmero, tenha um cuidado maior com a performance da modelagem.A SAP prope esta regra emprica, na qual o tamanho da tabela de dimenso deve ser menor do que 15% em relao a tabela de fatos. Por exemplo, se a tabela de fatos possui 100.000 registros, a tabela de dimenso deveria ter menos do que 15.000 registros. Como regra emprica isto funciona para volumes mdios como o do exemplo acima. Mas em outro exemplo: para uma tabela de fatos com 2.700.000 registros, 15% disto resulta em 405.000 registros - o que um nmero muito grande para uma dimenso,mesmo para um RDBMS pesado como o Oracle.Por este motivo, a Regra emprica 2 deve ser considerada. O grande problema das dimenses a quantidade de joins que o banco de dados tem que realizar para resgatar os dados. Os joins so o principal vilo contra a performance. Por este motivo, apesar do nmero 2.000.000 figurar como um nmero leve para a tabela de fatos, o mesmo no ocorre com as dimenses pois estas geram os joins para se chegar na tabela de fatos e cortar a fatia do cubo. Uma query envolvendo duas dimenses com 20.000 registros cada comea a ficar pesada.A SAP, na Regra emprica 1, refere-se a tamanhos de tabelas de dimenso e fatos mas no explicita qual a unidade de medida deste tamanho: registros ou bytes. Como o grande causador da degradao de performance so os joins, e estes so realizados registro a registro - parece razovel interpretar que a Regra emprica se refere a tamanho em quantidade de registros.47 SAP AG 2003, Norberto Harada/ 47Caractersticas com relacionamento N:M NO*deveriam ser modelados na mesma dimenso. Ex: clientes e produtos , se a empresa tiver 5.000 clientes, que compram em mdia 50 produtos diferentes cada a dimenso ter 250.000 instncias na Dim Table. * H excees descritas a seguir...ClientesProdutosDim. Clientes e ProdutosN:M Fatos de VendasDim. Cliente Dim. ProdutoModelar caractersticas com relacionamento N:M na mesma dimenso, como no exemplo acima, causaria uma exploso na quantidade de registros da Dim Table. Como foi explicado anteriormente, a Dim Table contm as combinaes de Clientes e Produtos para os quais h registro de movimento. Deste modo, se a empresa tem 5.000 clientes ( ativos ), e tem 50.000 produtos - mas em mdia cada cliente compra 50 produtos a Dim Table conter 5.000 clientes x 50 produtos o que resultar em 250.000 registros nesta tabela.Esta situao melhor resolvida modelando caractersticas com relacionamento N:M em dimenses diferentes e deixando que a tabela de fatos descreva as combinaes.48 SAP AG 2003, Norberto Harada/ 48Exceo 1:se N e M forem pequenos ( de 2 a 4 registros - Ou seN * M< 10.000 ) Exceo 2: Relacionamentos N:M podem ocorrer na mesma dimenso em casos como Material e CorMaterial CorEste recurso uma melhoria da modelagem do BW em relao ao Star Schema convencional. No Star Schema convencional , no possvel ter relacionamento N:M entre duas caracteristicas em uma tabela de dimensoFatos de VendasMaterialCorDim. MaterialNovamente neste exemplo,N * M que aqui so representados por qtd de Materiais * qtd de Cores, referem-se no quantidade de registros da tabela de dados mestres de materiais multiplicado pela quantidade de registros da tabela de dados mestres de cores, mas sim os materiais e cores para os quais existem registros de movimento.A SAP afirma que o recurso de modelar N:M na mesma dimenso no pode ser realizada no Star Schema convencional, entretanto este recurso descrito por Kimball como Combined Single Dimension.Na prxima transparncia isto ser explicado em detalhes.49 SAP AG 2003, Norberto Harada/ 49No Star Schema convencional isto poderia ser resolvido de duas formas: Separando Cor e Material em dimenses diferentes, ou Utilizando o recurso Combined Single Dimension ( R. Kimball - The Data Warehouse ToolKit, Chapter 2- The Promotion Dimension )As DIM Tables do BW tem um formato anlogo tcnica de modelagem Combined Single Dimension , com a vantagem de ser gerada e administrada automaticamente pelo OLAP Engine do BW. A maneira do BW lidar com a Combined Single Dimensionelimina as desvantagens descritas por Kimball.No Star Schema convencional, o modelador seria forado a implementar manualmente - codificando Triggers e Stored Procedures - o Combined Single Dimension.Da maneira que Kimball descreve esta tcnica , podemos observar que se trata exatamente do formato da Dim Table, ou seja, uma tabela que contm as combinaes entre as caractersticas para as quais existem registros de movimento. As chaves da Dim Table no so as chaves naturais, mas sim Surrogate Key chaves sequenciais geradas pelo sistema.A implementao disto pelo Star Schema convencional envolve a criao de um controle infalvel de gerao de Surrogate Keys e gerao dos registros de combinao entre as caractersticas - as instncias como foram referidas anteriormente neste trabalho.No entanto o BW lida com o Combined Single Dimension de forma nativa e automtica. O modelador no precisa sequer especificar que quer uma Combined Single Dimension, pois todas as dimenses no BW so construdas por default neste formato ( exceto quando se quer implementar o Degenerated Dimension - utilizando o recurso de modelagem fsica: Line Item Dimension ).50 SAP AG 2003, Norberto Harada/ 50O BW no obriga que apenas caracteristicas correlatas sejam modeladas na mesma dimenso. Nem que caracteristicas com relacionamento 1:N (pai:filho) sejam modeladas na mesma dimenso.Estes so recursos adicionais que podem ser explorados na modelagem.Exemplos a seguir...At agora vimos dois critrios para decidir sobre as dimenses:Caractersticas segundo o relacionamento:1) 1:N deveria ficar na mesma dimenso2) N:M deveria ficar em dimenses separadas2.1. Exceto se N e M forem pequenos2.2. Exceto se N e M possuirem um relacionamentosemntico, como Material e CorMas o BW no obriga na implementao fsica que caractersticas com relacionamento 1:N sejam modelados na mesma dimenso , e isto pode ser utilizado como um recurso adicional na modelagem.51 SAP AG 2003, Norberto Harada/ 51Exemplo 1: Dimenso produto com 100.000 produtos e 2.000 grupos de produto. Pode ser modelada colocando o grupo de produtos em uma dimenso separada se houverem diversas queries por grupo de produtos.ValorQuantidadeFatos de VendasProduto Grupo de ProdutoDim. ProdutoValorQuantidadeFatos de VendasProdutoDim. ProdutoGrupo de ProdutoDim. Grupo ProdutoNeste exemplo, h 3 drivers para deciso por esta forma de modelagem:1) Necessidades de anlise: grande quantidade de queries pelo atributo da caracterstica em foco2) Performance3) Caracterstica com grande quantidade de registros, possuindo um atributo com pequena quantidade de registros. Sendo que este atributo possui grande quantidade de queries.52 SAP AG 2003, Norberto Harada/ 52Agente 1,2,3,4Condio de PagtoAgncia de VendasImportador FinalEmpresaAno/Mes/DiaIncotermsUnidade ProdutivaTransportadoraTipo de NecessidadeTerminal Brasil Tipo Ordem de VendaCliente EmitenteCliente RecebedorVendedorSetor de AtividadeCanal DistribuioAplicaoExemplo 2: Inflao de DimensesPode acontecer de sua modelagem apresentar diversas dimenses pequenas, com uma ou duas caracteristicas onde estas caracteristicas possuem apenas um pequeno numero de valores...ProdutoInfocubo de FaturamentoQuantidade FaturadaValor PISValor COFINSValor ICMSValor IPIDespesas FinanceirasPreo Mdio a Vista com PIS e COFINSPreo Mdio a Vista sem PIS e COFINSPreo Mdio sem PIS e COFINSPreo Mdio BrutoPreo FOBValor da Comisso do Agente 1,2,3,4Valor de Comisses de Representantes Valor de DescontosNumero de Notas Fiscais EmitidasNeste exemplo, Incoterms contem somente CIF e FOBTipo de necessidade contm 3 valores.Aplicao uma lista de 30 valores.Agncia de Vendas contm 10 agencias.Setor de Atividade contm 15 setores.Canal de Distribuio contm 5 canais.Condio de pagamento contm 20 condies.53 SAP AG 2003, Norberto Harada/ 53considere o seguinte: Limite de dimenses permitidas pelo BW Possvel overhead na execuo da query devido ao elevado numero de joins de diversas Dim Tables.Soluo : Combinar pequenas dimenses em uma DimensoComo o BW no obriga que apenas caracteristicas correlatas sejam modeladas na mesma dimenso, possvel criar uma dimenso coletando caractersticas no correlatas.IncotermsTipo de NecessidadeAplicaoSetor de AtividadeCanal DistribuioCondio de Pagto Dim. Modalidade VendaO nmero de combinaes no deveria ser um produto cartesiano !H 3 drivers para decidir por esta opo de modelagem:1) A quantidade de caractersticas ultrapassa a quantidade limite de dimenses do BW ( 16 - 3 fixas ).2) A quantidade de registros em cada uma das caractersticas pequeno ( menor do que 50 registros ).3) O nmero de combinaes , no pode ser um produto cartesiano !( produto cartesiano a combinao de todos os registros de cada caracteristica com todos os registros das outras caracteristicas )neste exemplo: Incoterms (3 registros) X Tipo de Necessidade (3 registros) X Aplicao (30 registros) X Agencia de Vendas (10 registros) X Setor de Atividade (15 registros) X Canal Distribuio (5 registros) X Condio de Pagto (20 registros) o produto cartesiano resultaria em 3 * 3* 30 * 10 * 15 * 5 * 20 =4.050.000 de instncias, o que seria uma quantidade de registros que inviabilizaria a adoo desta opo de modelagem.Porm isto s ocorreria se todas as agencias de vendas vendessem para todos os setores de atividade por todos os canais de distribuio etc, etcSe este no for o caso, e na vida real a quantidade de instncias permanecer dentro de um nvel tolervel ( menor do que 20.000 registros ) esta opo pode ser adotada.54 SAP AG 2003, Norberto Harada/ 54Partitioning Dimension: Frank Mc GuffSe durante a modelagem, atributos com nomes parecidos com:Valores Reais / Valores Planejados / Valores Oradosaparecerem, modele uma caracteristica chamada, por exemplo, Tipo de Valor em uma dimenso Cenrio.Ateno: Partitioning Dimensions devem estar presentes em toda Query e todo Agregado ! Valor OradoValor RealPAA CustosDim. AtividadeDim. ContaDim. TempoValor PAA CustosDim. AtividadeDim. ContaDim. TempoCenrioTipo ValorA SAP utiliza os termos Partitioning Dimension e Partitioning Characteristic em diferentes white papers. Adotamos o termo Partitioning Dimension por ser este o termo original do autor Frank Mc Guff, apesar de Partitioning Characteristic se apresentar como um termo mais prximo da maneira como o conceito implementado no BW.No BW o conceito Partitioning Dimension suportado em sua modelagem fsica , definindo o InfoObject como Unvoco para cada clula ( Na definio do InfoObject, pasta Business Explorer, campo Seleo ). recomendvel que este InfoObject seja modelado isolado em sua prpria dimenso. Da ento o termo Partitioning Dimension passa a fazer mais sentido.No exemplo da ilustrao, se o usurio esquecesse de citar a Partitioning Dimension na query, acabaria somando valores orados com realizados.Assinalando Unvoco para cada clula o BW forar que o InfoObject seja citado em toda query e em todo agregado.O principal driver para optar por Partitioning Dimension, ao invs de criar diversas key figures o ganho com a flexibilidade do modelo. Cada nova verso de valor orado pode ser implementado no modelo sem necessidade de criao de uma nova key figure. Por outro lado, h um consumo maior de espao em disco utilizando Partitioning Dimension, pois o valor orado e realizados sero armazenados em registros separados na fact table.55 SAP AG 2003, Norberto Harada/ 55Plan,Forecast.. DataCubeActual DataCubePlan JActualMulti-CubeMulti-Cube QueriesBasic-Cube Queries Basic-Cube QueriesUtilizar o recurso MultiCubo em conjunto com Partitioning Dimension oferece uma boa implementao.A SAP recomenda a utilizao de Partitioning Dimension combinada com o recurso MultiCubo.Como driver para decidir por esta forma de implementao: A granularidade do planejado difere da granularidade do realizado. Por exemplo: o planejado est na granularidade ano/ms, e o realizado est na granularidade diria.56 SAP AG 2003, Norberto Harada/ 56Degenerated Dimension*: surge quando a granularidade da tabela de fatos representa um documento tal como nmero do pedido ou nmero da fatura. Numa degenerated dimension, os atributos so definidos em outras dimenses. O BW suporta fsicamente degenerated dimensions atravs do recurso Line Item Dimension* Ralph Kimball57 SAP AG 2003, Norberto Harada/ 57Dimenso tempo:H uma nica dimenso de tempo, para modelar anlises por diferentes quebras de tempo. Para que o modelo permita consolidaes por diferentes quebras de datas (ex: Ano, Trimestre, Mes ) necessrio associar os InfoObjects tipo Data adequados a cada quebraPAA - CustosDim. Atividade0CALYEAR0CALQUARTER0CALMONTHDim. TempoDim. ResponsavelA dimenso tempo obrigatria em todo modelo. O modelador sempre terde decidir por alguma data no sistema fonte, para ser utilizada na dimenso tempo. Geralmente a data em que ocorreu o evento registrado na tabela de fatos a data indicada, mas h casos em que a escolha no assim to bvia.Por exemplo: em um modelo transacional com mais de uma data, tais como data de emisso, data de vencimento e data de fechamento. Uma das datas deve ser escolhida para preencher a dimenso tempo. recomendvel preencher a dimenso tempo com todos os InfoObjects do tipo Caracterstica de Tempo que sero necessrios nas queries/relatrios.O driver para decidir quais sero as caractersticas de tempo o levantamento de layout de queries/relatrios, executada durante os workshops de requerimentos.58 SAP AG 2003, Norberto Harada/ 58Lidando com mais de uma data no modelo:O BW no aceita: criao de uma segunda dimenso tempo, a associao de um InfoObject do tipo Tempo para outra dimenso que no seja a dimenso tempo fixa a criao de um InfoObject do tipo Tempo,o modelador deve utilizar os InfoObjects de Tempo do Business Content.PAA - CustosDim. Atividade0CALYEAR0CALQUARTER0CALMONTHDim. TempoDim. Resp0CALYEAR0CALQUARTER0CALMONTHDim. TempoCaractersticas de tempo disponveis no BCT at BW 3.0B SP13:0CALDAY Dia de Calendrio0CALMONTH Ano Civil / Ms0CALMONTH2 Ms Calendrio0CALQUART1 Trimestre0CALQUARTER Ano Civil / Trimestre0CALWEEK Ano Civil / Semana0CALYEAR Ano civil0FISCPER Exerccio/ Perodo0FISCPER3 Perodo Contbil0FISCVARNT Variante de exerccio0FISCYEAR Exerccio0HALFYEAR1 Semestre0WEEKDAY1 Dia da Semana59 SAP AG 2003, Norberto Harada/ 59O BW aceita: a criao de um InfoObject do tipo Caracterstica, tipo de dado DATS (equivalente a 0CALDAY ). a criao de um infoobjeto referenciado a um infoobjeto do tipo tempo (ex: infoobjeto referenciado a 0CALMONTH) a criao de uma dimenso contendo o InfoObject citado acima a criao de Key Figure com tipo de dado Data. Alterao na descrio da dimenso Tempo para cada infocuboData de EmissoValor Fatos de Contas a Pagar0CALDAYDim. Data AberturaDT_FECHDim. Data FechamentoDim. TempoPara colocar duas datas no modelo, possvel criar InfoObject do tipo Caracterstica tipo de dado DATS. Mas o tipo de dado DATS um armazena dados no formato dia/ms/ano. Para criar um infoobjeto contendo ms/ano pode-se criar um infoobjeto referenciado a 0CALMONTH. tambm possvel criar key figure do tipo de dado Data.Como decidir quando modelar a data como caracterstica ou como key figure:Para fazer selees, filtros, key figures restringidas e outros recursos do Bex Analyser , a data deve ser modelada como caracterstica.Para fazer clculos, como por exemplo - durao, tempo mdio em atraso, tempo aberto fora do prazo - a data deve ser modelada como key figure. possvel ter a data modelada nas duas formas no mesmo modelo, como caracterstica e como key figure.A key figure pode estar na tabela de fatos ou como atributo de uma caracterstica na dimenso. recomendvel alterar a descrio da dimenso Tempo. No BW a descrio desta dimenso est traduzida como Hora, mais adequando alterar a descrio para um texto que descreva o que est sendo preenchido na dimenso tempo. Por exemplo: num cubo de vendas, a descrio poderia ser Data da Venda. 60 SAP AG 2003, Norberto Harada/ 60Tabela de FatosDT_EMISSAODT_FECHMTODim. DatasColocar duas caractersticas de tempo na granularidade DIRIA da dimenso tempo pode estourar a dimenso. Entretanto,fazer o mesmo na granularidade MENSAL no provoca o mesmo efeito.365 dias x 365 dias= 133.255Tabela de FatosMES_EMISSMES_FECHMTODim. Tempo12 meses x 12 meses= 14412 meses x 5 anos = 60meses60 meses x 60 meses = 3.600O BW aceita a criao de um novo InfoObjeto tipo DATS, porm esta data s pode ser definida na granularidade dia/ms/ano. Caso o InfoObjeto receba dados na granularidade Ano_Mes, o modelador ter de definir uma Transfer Rule ou Update Routine que transforme mes_ano para dia_mes_ano.Criar uma dimenso contendo duas datas na granularidade dia_mes_ano, pode estourar a quantidade de instncias da dimenso. Ao passo que na granularidade mes_ano o mesmo no ocorre.61 SAP AG 2003, Norberto Harada/ 61Modelos com mais que uma data freqentemente remetem a granularidade prxima ao nvel transacional.DataAberturaDataFechamentoCliente Valor01/01/01 01/01/01 01 10,0101/01/01 02/01/01 01 10,0201/01/01 01/01/01 02 10,0302/01/01 02/01/01 02 10,0402/01/01 03/01/01 01 10,0503/01/01 05/01/01 01 10,0601/01/01 01/01/01 01 11,0004/01/01 06/01/01 02 10,07Neste exemplo: dificilmente haver uma situao em que a data de emisso, a data de vencimento e o cliente possam ser consolidados pois o conjunto de dados, na prtica, acaba sendo nica para cada documento. Quanto mais dimenses colocamos no modelo - tais como condio de pagamento, ou forma de cobrana - mais perto do nvel transacional o modelo se configura.Modelo Near Transactional vs. Modelo Snapshot Necessidade de anlises com perodos abertos Pequena quantidade de registros na fact table (menos que 500.000)Modelo Near Transactional: InfoCubo vs. ODS Utilizao de Key Figures e Caractersticas Virtuais Um modelo com mais de uma data pode ser resolvido atravs de um modelo snapshot ou atravs de um modelo NearTransacional.O modelo de Accounts Receivable do BCT, um modelo que por conter diversas datas, remete o infocubo ao nvel prximo do transacional, mas ainda assim o infocubo pode conter at 65% dos tamanho do ODS que contm os documentos.Como principais critrios para decidir por um modelo Near Transactional:1) imprescindvel para o negcio anlises por perodos abertos - ou seja, qualquer perodo de datas. O usurio pode fazer uma anlise dos dados entre 15/02/05 e 29/03/05 ou entre 13/06/05 e 18/06/05. Os perodos no seguem nenhuma regra fixa, podendo assumir qualquer data de inicio ou final aleatriamente, definidas por demanda ad-hoc do usurio. Este caso no pode ser resolvido por um modelo dimensional, de tal forma que s o modelo transacional seja a opo.2) Pequena qtd. de registros (menor que 500.000) em conjunto com a necessidade de anlise que demanda clculos entre datas (ex: Durao de documentos em aberto = data de abertura - data final do perodo informado pelo usurio). Se clculos entre datas forem necessrios, um full-scan na tabela de fatos ter que ser executado pelo RDBMS. Se a tabela de fatos contiver mais do que uma centena de milhares de registros, a performance tornar a usabilidade do modelo invivel, dependendo do hardware.O modelo transacional pode ser implementado no InfoCubo ou no ODS.Como critrio para decidir se o modelo com duas datas ser implementado no ODS ouInfoCubo: A necessidade de utilizar Key Figures e caractersticas virtuais, impe que o modelo seja implementado atravs de um InfoCubo ou Multicubo pois o ODS no aceita Key Figures e Caractersticas virtuais(na verso atual BW 3.0B SP13, sem previso para implementao por razes conceituais).Observao: Key Figures e Caractersticas virtuais sero discutidos com mais detalhes no 4o. Decision Point. Em resumo uma Key Figure virtual uma Key Figure cujo clculo derivado de um algoritmo codificado em ABAP, e a Caracterstica virtual uma caracterstica cujo resultado tambm derivado de um algoritmo codificado em ABAP. A complexidade dos algoritmos, inviabiliza a implementao atravs de Bex-frmulas e variveis. Nestes casos a soluo Key Figure e Caractersticas Virtuais melhora a usabilidade do modelo.62 SAP AG 2003, Norberto Harada/ 62SAC BRQuantidade de ManifestaesData AberturaData FechamentoData do PrazoDias Fora do PrazoDuraoDim. Cd. ManifestaoCdigo Manifestao1:1Dim. Data AberturaAnoMs/AnoDia/Ms/AnoDim. Data FechamentoAnoMs/AnoDia/Ms/AnoDim. Data PrazoAnoMs/AnoDia/Ms/AnoDim. Linha ProdutoLinha ProdutoDim. SolucionadorSolucionador- ChaveOrganizao Solucionador- Gerencia Solucionador- rgo SolucionadorDim. ManifestaoEspecialidade da Manifestao- Categoria Manifestao- Assunto Manifestao- Manifestao- Tipo ManifestaoOrigem ManifestaoCanal de ContatoDim. AtendimentoCadastrador- ChaveOrganizao Atendimento- Gerencia Atendimento- rgo AtendimentoDim. StatusManifestaoSituao no periodo selecionadoSituao atual ManifestaoAo ManifestaoDim. Local do EventoRegio do EventoEstado do EventoCidade do EventoBairro do Evento Dim. ClienteCliente11 12345Modelo Transacional com mais que uma dataOutros critrios para decidir por um modelo transacional:a) Mais simplicidade na extrao. Se o volume de dados for pequeno (menor que 100 mil), pode-se fazer extrao full e carga full no InfoCubo, com marcando a opo de apagar todo o contedo antes da carga (no InfoPackage ).b) As queries do modelo podem ser bem trabalhosas e complexas para serem criadas ( o que no ocorre no modelo dimensional ). No modelo transacional recomendvel utilizar key figures e caractersticas virtuais.Recomendaes para modelos com mais de uma data para um modelo transacional:1) Dimenses Data de Fechamento e Data Prazo criadas contendo InfoObjects tipo DATS. Dimenso tempo renomeada para Data Abertura. Atravs das dimenses, filtros e agrupamentos podem ser feitos.2) Key figures tipo Data criadas para as mesmas datas que so preenchidas nas dimenses citadas acima. Atravs das key figures Data, clculos entre datas podem ser realizados.3) Dias fora do prazo e durao so key figures virtuais, utilizam algoritmos que se baseiam no perodo que o usurio informa ao executar a query.4) Situao no perodo selecionado uma caracterstica virtual, seu valor gerado atravs de um algoritmo, retorna a situao ( aberto, fechado ) em que um documento estava no perodo que o usurio informa ao executar a query.5) O nmero do documento deve ser modelado numa Degenerated Dimension. J que o modelo com datas praticamente atinge o nvel transacional, a degenerated dimension facilita o funcionamento da key figure virtual*, o troubleshooting de carga, e a conferncia de dados. * devido a fatores tcnicos que sero abordados no Workshop de Key Figures e caractersticas virtuais63 SAP AG 2003, Norberto Harada/ 63Dim. AtendimentoQtd. Manif. por ClienteQtd. Manifestaes AbertasQtd. Manifestaes FechadasQtd. Manifestaes TratadasDim. TempoMs/AnoSemanaDim. Solucionador Dim. AtendimentoDim. ClienteClienteModelo Dimensional com mais que uma dataQtd. Manif. por ProdutoQtd. Manifestaes AbertasQtd. Manifestaes FechadasQtd. Manifestaes TratadasDim. TempoMs/AnoSemanaDim. SolucionadorDim. ProdutoProdutoPrazos e duraes p/ ClienteDias Fora do PrazoDuraoPrazo da respostaDim. TempoMs/AnoSemanaDim. Solucionador Dim. AtendimentoDim. ClienteClienteDim. Dias fora prazoDias fora do prazoDim. DuraoDuraoDim. Prazo da resp.Prazo da resposta1112 223334Como drivers para se decidir por um modelo dimensional:a) o volume de registros, na granularidade documento, maior do que 100.000 registros. Pode tornar invivel do ponto de vista de performance, a utilizao de um modelo transacional, fazendo com que o modelo dimensional seja a nica opo.b)A viabilidade de negociar com o usurio, a granularidade do modelo e a separao dos InfoCubos por tema de anlise. Vide item 2 abaixo.c)A viabilidade de negociar com o usurio, uma periodicidade fixa para as anlises. O modelo transacional permite anlises com periodicidade aberta, ou seja , qualquer perodo de datas. O modelo dimensional exige periodicidade fixa, ex: semanas fechadas, ms fechado. H tambm a necessidade de negociar a reteno de dados do modelo, e o aumento da granularidade temporal para o histrico -ex: armazenando dados semanalmente por dois meses, mensalmente os6 meses anteriores e por trimestre todo o histrico at 2 anos.d) A viabilidade de levantar junto com o usurio, todas as demandas de anlise que definiro as key figures. Como o contudo de key figures, como qtd. Manif. Abertas, durao fora do prazo tem que ser calculado por algoritmos na extrao ou na carga, necessrio que o usurio defina precisamente suas necessidades de anlise, pois modelo mais rgido.Recomendaes de modelagem com mais de uma datapara um modelo dimensional:1) Dimenso tempo contm a Data da foto, a fact table contm fotosextradas diriamente, o usurio teria a viso da semana corrente. A cada virada de semana o modelo reteria uma foto congelada da semana que passou. No recomendvel reteno diria.2) As dimenses do modelo no devem remeter o modelo granularidade transacional. Pode ser necessrio criar mais de um InfoCubo para anlises especficas, por exemplo: num InfoCubo a dimenso cliente seria suprimida, em outro InfoCubo, a dimenso Cliente apareceria mas outras dimenses seriam suprimidas. Um cubo complementaria o outro. 3) Haveria uma separao de cubos relacionada ao tipo de key figure. A key figure quantidade de documentos seria tratadas num cubo, clculos entre datas seriam tratados em outro cubo. As quantidades poderiam ser modeladas com key figures distintas, como ilustrado no exemplo, ou utilizando-se partitioning dimension .Multicubo pode ser utilizado para cruzar informaes.4) As key figures de clculos entre datas teriam tambm dimenses para agrupar seus valores. Estas dimenses teriam hierarquias para agrupar valores: ex: dias fora do prazo 1 a 10 dias, 11 a 20 dias etc.64 SAP AG 2003, Norberto Harada/ 64Dimenso Unidade:A utilizao da dimenso fixa Unidade definida pela maneira como as Key Figures sero definidas. Isto ser tratado no prximo tpico: o 4o. Decision Point.Caso o termo Unidade possua um forte contexto arraigado na cultura da organizao, altere a descrio da dimenso para Unid. Negcio e opcionalmente a descrio da dimenso fixa Unidade para Unidade de Medida / Moeda . Esta prtica melhora a usabilidade do modelo, do ponto de vista do usurio final.213No exemplo acima, temos parte da tela de definio de query de dois InfoCubos diferentes. Na cultura da organizao, o termo Unidade largamente utilizada para designar Unidade de Negcio. O caso (1) ilustra uma dimenso contendo Unidade, que em um InfoCubo aparece como Un. Negcio e em outro aparece como Unidade, contendo diversos atributos como Campo Bloco, Macro, Proprietrio. O modelador e o Data Architect devem estar atentos a dados mestres duplicados, como neste caso, e criar uma estratgia de normalizao de dados mestres.No caso (2) a dimenso tempo representada em um InfoCubo como Hora que a descrio default do BW, e em outro InfoCubo como Tempo. Como j foi dito, a situao recomendada neste caso alterar a descrio da dimenso tempo para um texto que descreva o contedo - a data - que est sendo preenchida nesta dimenso (ex: Data de Venda, Data de Faturamento)No caso (3) a dimenso fixa do BW Unidade aparece em um cubo com sua descrio default que Unidade e em outro cubo , sua descrio foi alterada para Moeda pois o InfoCubo no utiliza Unidades mas utiliza a dimenso fixa Unidade para armazenar os valores em diferentes moedas. Por no utilizar Unidades, descrever esta dimenso como Unidade / Moeda confundiria a interpretao de seu contedo. Manter o texto Unidade para a dimenso fixa, sendo este termo utilizado para denominar uma Unidade de Negcio tambm confunde o usurio final.65 SAP AG 2003, Norberto Harada/ 65Kimballs9 decision points&ASAP for BW( Ralph Kimball, The Data Warehouse Toolkit, 1996 SAP AG, Multi-Dimensional Modeling With BW - ASAP for BW, 2000 )1. Os processos e por conseguinte as tabelas de Fatos2. A granularidade das tabelas de Fatos3. As dimenses das tabelas de Fatos4. Os Fatos incluindo fatos pr-calculados5. Os atributos das dimenses com descrio completa e terminologia apropriada6. Como rastrear Slowly Changing Dimensions7. Os agregados, dimenses heterogneas, minidimensions, query modes e outras decises de armazenamento fsico8. A durao histrica do banco de dados9. A urgncia com a qual os dados so extraidos e carregados no Data Warehouse66 SAP AG 2003, Norberto Harada/ 664. Os Fatos incluindo fatos pr-calculadosOs melhores e mais teis fatos so numricos, so valores contnuos e so aditivos.O principal guia para o database designer decidir,se um nmero um fato ou um atributo dimensional , verificando se o nmero um valor contnuo.O fato nmero de dlares um bom exemplo pois ele pode assumir qualquer valor dentro de um amplo alcance de valores. R. KimballKey Figures podem tambm ser: mdias, campos de data auxiliares, valores no aditivos como preo unitrio. SAPApesar da afirmao de Kimball: Os melhores e mais teis fatos so : numricos, valores contnuos aditivosa SAP afirma que key figures ( fatos ) podem ser : no numricos, como Data e Hora no aditivos como mdias e preo unitrio67 SAP AG 2003, Norberto Harada/ 67Key Figure na Tabela de Fatos vs. CaractersticaData Fornecedor Qtd.(a)Preo(b)Critrio 1(a) * (b)Critrio 2( a) * (c)05.2001 AAA 10 10,00 100,00 10000,0005.2001 BBB 20 20,00 400,00 40000,0006.2001 AAA 1 100,00 100,00 1000,0006.2001 BBB 1 200,00 200,00 2000,0007.2001 AAA 2 1000,00 (c) 2000,00 2000,0007.2001 BBB 1 2000,00 (c) 2000,00 2000,00QuantidadePreoFatos de ComprasDim. FornecedorItem Preo (kf)Dim. ItemFornecedorTotalCritrio 1TotalCritrio 2AAA 2200,00 13000,00BBB 2600,00 44000,0012345Uma key figure como preo unitrio pode ser modelada na tabela de fatos ou na dimenso.Como critrio para decidir por modelar a key figure na tabela de fatos (1) : A necessidade de anlise requer totalizao pelo valor da key figure efetuada na poca. Neste exemplo, (2) total comprado do fornecedor pelo preo unitrio efetivo na poca da compra.Como critrio para decidir por modelar a key figure na dimenso (3): A necessidade de anlise requer totalizao pelo ltimo valor da key figure. Neste exemplo (4) total comprado do fornecedor ao preo atual.O BW suporta esta soluo da seguinte forma: crie a key figure Preonormalmente. Crie a caracterstica Item, aceitando atributos. Associe a key figure Preo como atributo de Item e como key figure do Infocubo.Na query para obter o preo necessrio a criao de uma varivel do tipo frmula.Na carga da tabela de fatos. Pode-se carregar antes os dados mestres e atributos de Item, atualizando o ltimo preo. Em seguida, na carga da tabela de fatos uma Update Rule (5) pode buscar o preo no Item e grav-lo na key figure.68 SAP AG 2003, Norberto Harada/ 68Key Figures armazenadas vs. Key Figures calculadas 1:Preo de lista estendidoTotal de concessesTotal de descontosPreo lquido estendidoFatos de VendasEste >>>Menos>>>Menos >>>Igual a >>>R. Kimball - DBMS vol. 1 no. 1Fatos pr-calculadosPreo lquido estendido o Preo de lista estendido -Total de concesses - Total de descontosDevemos armazen-lo ?SIM !Mantenha o nmero de Key Figures ao mnimo.Evite armazenar valores que podem ser calculados. Por exemplo: ao invs de armazenar preo mdio, armazene quantidade e faturamento. O preo mdio pode ser calculado na query (faturamento / quantidade).SAP - Sizing and Performance - ASAP Methodology Accelerators 1999Ralph Kimball recomenda que key figures derivadas de clculos a partir de outras key figures existentes na fact table, devam ser armazenadas. O critrio de deciso apresentado por Ralph Kimball para este caso a usabilidade do modelo. Uma key figure cujo clculo armazenado na fact table, facilita o trabalho do usurio final, evitando que este cometa erros ao definir o clculo em toda query.O BW possui no Bex Analyserrecursos denominados: key figures calculadas e estruturas de key figures. Uma key figure calculada no BW, to fcil de utilizar - para o usurio final - quanto uma key figure armazenada e ainda economiza espao em disco. Uma vez definida uma key figure calculada ou uma estrutura, estas podem ser utilizadas em vrias queries, evitando a possibilidade do usurio final errar a frmula do clculo a cada query.Portanto o argumento de usabilidade , para decidir pelo armazenamento de uma key figure, no se aplica ao BW (Se o InfoCubo estiver sendo acessado via Bex Analyser ou ODBO ).A SAP recomenda a utilizao de key figures calculadas.Do ponto de vista de performance, no h perda de desempenho utilizando key figures calculadas pois o clculo rodano OLAP Engine - que est no servidor BW - e no na workstation. O tempo para execuo dos clculos desprezvel.Por outro lado, a quantidade dekey figures na fact table afeta o tamanho em bytes da fact table e por consequncia afeta a velocidade de acesso. Em algum nvel do servidor BW (abaixo do Oracle), o registro inteiro tem que ser lido para que o contedo dos campos utilizados na query sejam extrados. Um registro maior leva mais tempo para ser lido, e este tempo pode se tornar relevante quando lidamos com volumes de registros na casa dos milhes ou mesmo das centenas se o registro for muito grande.69 SAP AG 2003, Norberto Harada/ 69Uma tabela de fatos malfeita, com fatos no-numricos, fatos no-cumulativos e periodicidade mistaTipo de VendedorStatusPreo UnitrioMargem brutaVendas diriasVendas do ano at o momentoVendas no ano anteriorFatos de VendasR. Kimball - DBMS vol. 1 no. 1Dim. TempoDim. ClienteDim. ProdutoDim. PromoaoNo-numricosno-cumulativosperiodicidade mistaNeste exemplo de Kimball, inserir na tabela de fatos Tipo de Vendedor e Status,com tipo de dado caracter incorreria-se num erro de modelagem por misturar dados no numricos na tabela de fatos.No BW no h como inserir key figures com tipo de dado caracter, portanto o modelador ser impedido de cometer este erro.De qualquer modo, uma key figure - mesmo numrica - no deve ser utilizada para armazenar informaes que deveriam ser caractersticas ou atributos, tais como Tipo de Vendedor e Status .Preo unitrio e Margem bruta so citados por Kimball como erro de modelagem, mas para a SAP - como j foi dito - valores no cumulativos, como Preo unitrio e at mdias , podem ser key figures.70 SAP AG 2003, Norberto Harada/ 70Outra tabela de fatos mal-feita . Neste exemplo, os fatos deveriam ser divididos por dimenses.Vendas JaneiroVendas FevereiroVendas MaroPopulao Masc. Acima 30 anosPopulao Fem. Acima 30 anosFatos de VendasDim. TempoDim. ClienteDim. ProdutoDim. Promoao comum encontrar em sistemas OLTP - at mesmo no R/3 - tabelas contendo campos para armazenar valores de cada perodo. Esta prtica que pode ser vlida para OLTP no recomendada para modelagem OLAP.No exemplo acima, ao invs de key figures: Vendas Janeiro, Vendas Fevereiro o correto seria modelar apenas uma key figure para Vendase deixar que a dimenso tempo descreva qual o perodo ao qual se refere as vendas.Do mesmo modo, ao invs de key figures: Populao Masc. Acima de 30 anos etc. o correto seria modelar apenas a key figure Populao e criar caractersticas para sexo e faixa de idade.71 SAP AG 2003, Norberto Harada/ 71No BW h 5 tipos de dado para Key Figures: Montante Quantidade Numero Data HoraMontante: key figure para armazenar valores expressos em moeda.Quantidade: key figure para armazenar volumes.Numero: key figure numrica para uso geral.Data: possvel fazer clculos entre datas, tais como somar e subtrair uma data a um nmero ou subtrair datas para obter a diferena em dias corridos. O formato da data sempre armazena dia, ms e ano, portanto no h como definir uma key figure tipo Data no formato ms / Ano. Fsicamente no RDBMS o BW armazena a data em um campo VARCHAR2 , que um campo com tipo de dado Caracter - no utilizando o formato do RDBMS para Data . H sistemas, tais como o Oracle que armazenam Data no formato dd/mm/aaaa hh:mm:ss, ou seja , armazenam data e hora no mesmo campo. Se a key figure tipo data proveniente de um sistema fontecomo o Oracle, o modelador deve investigar se a hora armazenada no camporelevante para anlise ou para regras de extrao. Caso a hora seja relevante para anlise, criar no BW uma key figure do tipo hora. Hora: armazena hora no formato hh:mm:ss72 SAP AG 2003, Norberto Harada/ 72Key Figure MontanteUma Key Figure do tipo Montante representa uma quantia em moeda. Utiliza automaticamente a dimenso Unidade para represent-la Pode-se modelar o uso da Key Figure montante de duas formas: Com Converso de Moeda. Multi Moeda ( sem converso )73 SAP AG 2003, Norberto Harada/ 73Com converso. Carrega-se a tabela de Fatos com uma moeda de referncia e utiliza-se os recursos do BW para converso de moedas.ValorPAA - CustosDim. AtividadeDim. Tempo Dim. OTFon1e de dados01.20000T.01 AT.0110,50 RL01.20000T.02 AT.01 5,50 RL02.20000T.01 AT.0111,50 RL02.20000T.02 AT.0220,00 RLNa ilustrao , Fonte de dados representa o registro de movimento, ou o FlatFile contendo os dados a serem carregados no BW. Ao se optar por utilizar uma key figure montante Com Converso, os dados so armazenados em uma moeda de referncia - neste exemplo: BRL ( Cdigo ISO da moeda Real ). A converso feita na execuo da query a partir de valores e parmetros de converso definidos em uma tabela de sistema do BW. Esta tabela s acessvel pelo Administrador BW.Esta opo consome menos espao em disco, mas pode provocar uma pequena diferena de valores devido aos clculos de converso.74 SAP AG 2003, Norberto Harada/ 74Multi - Moeda - Sem converso. Carrega-se a tabela de Fatos com os valores j convertidos para as moedas que se deseja analisar.ValorPAA - CustosDim. AtividadeDim. Tempo Dim. OTFon1e de dados01.20000T.01 AT.0110,50 RL01.20000T.02 AT.01 5,50 RL61.26660T.61 AT.6121,66 561.26660T.62 AT.6111,66 502.20000T.01 AT.0111,50 RL02.20000T.02 AT.0220,00 RL62.26660T.61 AT.6123,66 562.26660T.62 AT.6246,66 5No recurso Multi Moeda sem converso, os dados devem ser carregados na tabela de fatos j na moeda que se deseja analisar.No exemplo da ilustrao, os registros carregados em BRL tambm so replicados, com o valor convertido para USD e carregados fisicamente na tabela de fatos nas duas moedas.No h converso durante a query, portanto no h diferena de valores. Por outro lado o recurso Multi Moeda consome mais espao em disco.O recurso de converso de moeda continua disponvel na query mesmo que o cubo esteja utilizando o recurso Multi Moeda.Os recurso multi-unidade, que anlogo ao multi-moeda, tambm estdisponvelpara unidades de medida. O recurso de converso de unidades no est disponvel at a verso atual(BW2.1C SP5 ).75 SAP AG 2003, Norberto Harada/ 75Se voc no pretende utilizar os recursos multi-moeda do BW, ou recursos de converso de moedas ou de unidade, voc pode definir as Key Figures como Number e descrever a moeda ou unidade pela descrio : Valor em R$.Valor em R$PAA - CustosDim. AtividadeDim. Tempo Dim. OTFon1e de dados01.20000T.01 AT.0110,50 01.20000T.02 AT.01 1,5002.20000T.01 AT.0111,5002.20000T.02 AT.0220,00Se h um certo grau de certeza que a key figure no necessitar de converso, desnecessrio model-la como montante ou quantidade. Pode-se modelar a key figure como tipo de dado Number que no possui vnculo com a dimenso fixa Unidade. Key figures que representam quantidades, geralmente so fixas em todo o processo de anlise, dispensando converses. Com moedas mais comum que a necessidade de anlise requeira converses.76 SAP AG 2003, Norberto Harada/ 76 Existem Key Figures semi-aditivas, que no so aditivas atravs de uma dimenso. Por exemplo: Qtd de Funcionrios pode no ser aditiva atravs da dimenso tempo. Toda Key Figure numa modelagem do tipo Inventory Snapshot semi-aditivaQuantity_on_handInventory FactProduct DimensionWarehouse DimensionTime Dimension77 SAP AG 2003, Norberto Harada/ 77Em promooCobertura da PromooDim. Ponto de VendaDim. TempoDimenso Produto Dim. PromooData Produto Ponto de Venda Promoo Em Promoo01.2001 AAA PV01 PG2LV3 101.2001 BBB PV01 PG2LV3 102.2001 AAA PV01 PG3LV4 102.2001 BBB PV01 PG3LV4 102.2001 CCC PV02 PG3LV4 1Factless Fact Table 1Coverage TablesH um contexto em que Factless Fact Table aparecem mais como a descrio de algo que no aconteceu do que como a descrio de algo que aconteceu.Observe que a modelo abaixo contm informaes sobre quais produtos estavam em promoo.Factless Fact tables - tabela de fatos sem fatos - tem este nome pois sua key figure, neste exemplo Em Promoo no registra um fato , algo que foi medido, mas sim algo que existe ou existiu.A key figure Em promoo preenchida com o valor fixo 1 , e a tabela de fatos apenas registra quais produtos estavam em promoo, em que pontos de venda , data e sob qual promoo.O valor fixo 1 preenchido na key figure Em Promoo um fato artificial, pois no foi medido. Key figures, como Valor Faturado, Quantidade Vendida , quantidade de entrada e sada de estoques, so fatos medidos no processo operativo.78 SAP AG 2003, Norberto Harada/ 78Qtd_ClientesFatos Qtd ClientesFilialEmpresaAreaTipo_FilialDim. FilialAno/MesMesAnoDim. TempoCanal VendaQtd PessoasQtd Veic PropriosQtd Veic TerceirosDim. Canal VendaDivisoSubDivisoOrdemDim. ProdutoFactless Fact Tables2Frequentemente faz sentido introduzir adicionalmente uma key figure artificial para facilitar a contagemFactless Fact Tables tambm podem ser utilizadas com key figures contendo contadores. No exemplo anterior a key figure continha o valor fixo 1. Neste exemplo a tabela de Fatos Qtd Clientes contm apenas akey figure Qtd_Clientes. O valor da key figure Qtd_Clientes extrada da Fatos de Vendas atravs de um SQL: count( distinct cliente ), com group by pelas dimenses.A tabela de Fatos de vendas,pode conter milhes de registros, enquanto a tabela de Fatos de Qtd Clientes contm apenas alguns milhares de registros possibilitando alto desempenho no rotacionamento do cubo.79 SAP AG 2003, Norberto Harada/ 79Factless Fact Tables 3A tabela de fatos normalmente responde a respeito de coisas que aconteceram.No h uma maneira fcil de criar um modelo que responda a respeito de coisas que no aconteceram. Por exemplo: quais produtos no venderam durante uma promoo ? Quais produtos no foram vendidos em quais lojas durante uma promoo ? Considere que apenas determinados produtos podem estar em promoode loja para loja, e que os produtos podem estar em promoes em perodos diferentes.A SAP afirma que a tabela de fatos normalmente responde a respeito de coisas que aconteceram, e no sobre coisas que no aconteceram tal como produtos que no venderam durante uma promoo.Por outro lado, o Star Schema convencional possui tcnicas dar este tipo de resposta.80 SAP AG 2003, Norberto Harada/ 80Observe que neste modelo, se no houve atividade em um determinado dia em um mercado, ns deixamos o registro fora do banco de dados. muito importante que ns no tentemos preencher a tabela de fatos com zeros representando que nada aconteceu. Por esta razo , tabelas de fatos so sempre espaadas (sparse). Algumas so extremamente espaadas.Valor vendidoQtd. VendidaFatos de VendasLoja- Tipo de LojaDim. Ponto de VendaAnoMes/AnoTrimestreDim. TempoProduto- Famlia- LinhaDim. ProdutoDim. Promoo importante no preencher a tabela de fatos com zeros. Preencher com zeros causaria uma exploso na tabela de fatos, fazendo com sua quantidade de registros resultasse no cartesiano de todas as dimenses.81 SAP AG 2003, Norberto Harada/ 81O conjunto diferena entre as duas tabelas (Cobertura da Promoo e Fat