Você está na página 1de 150

1

SAP AG 2003, Norberto Harada/ 1


Modelagem Multidimensional com BW
Parte 1 modelo lgico
Norberto Harada
SAP Consulting
Business Intelligence / Netweaver Consultant
Setembro/2003
Verso do documento: 5.0
Verso BW: 3.0B
2
SAP AG 2003, Norberto Harada/ 2
Objetivos do modelo multidimensional
Modelagem um assunto
controverso pois a
competio por diferentes
interesses surgem durante
a fase de design. Isto
explica porque algumas
recomendaes de design
contradizem-se.
Performance
Aspectos de
Anlise
Aspectos de
Aspectos
Globais de
Design do
Data
Warehouse
Objetivos do modelo multidimensional
n 1 - Oferecer informaes para o usurio final de uma maneira que corresponda a maneira como ele
v o negcio
Disponibilizar informaes estruturadas que permitem o usurio final navegar facilmente,
utilizando qualquer combinao possvel de termos de negcio para ilustrar o
comportamento dos KPIs
n 2 - Oferecer a base para a implementao fsica que seja compreensvel pelo software ( OLAP
Engine ) permitindo a este fcil acesso
Performance
Consistncia / Integridade Semntica
Durante 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/ 3
Passos 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 informao
2. 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 Schema
3. 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/ 4
Sistema 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/ 5
Como Criar ou obter o MER da aplicao
Para 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 disponveis
Obter 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/ 6
CONCEITUAL LGICO FSICO IMPLEMENTAO
Diferentes aspectos da modelagem
Naeem Hashmi
Conceptual Model
Entity Relationship Model
Star Schema Model
Analytical Data Model
Document Model
Multidimensional
Database
Relational Database
Document
Database
OLAP Marts
ODS
Data
Warehouse
Data
Marts
O Modelo Conceitual
delineia o fluxo de
informao permeando
todos os processos de
negcio. Descreve como
as decises so tomadas
para dirigir os processos
de negcio
O 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/ 7
Modelo 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/ 8
Modelo 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 projeto
9
SAP AG 2003, Norberto Harada/ 9
{ Centro de Custo
Diviso }
Dim. Centro Custos
Cliente
~ endereo
- cidade
- estado
~ cep
- faixa de idade
- faixa de renda
- estado civil
- sexo
Dim. Cliente
Faturamento
Quantidade Faturada
Valor PIS
Valor COFINS
Valor ICMS
Valor IPI
Despesas Financeiras
Preo FOB
Valor de Descontos
Numero de Notas Fiscais Emitidas
Preo Mdio a Vista com PIS e COFINS
Preo Mdio a Vista sem PIS e COFINS
Preo Mdio sem PIS e COFINS
Preo Mdio Bruto
Ano
Mes / Ano
Dia
Dim. Tempo
Material
Grupo de Material
Dim. Material
Modelo Lgico
Este 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 modelagem
10
SAP AG 2003, Norberto Harada/ 10
Como criar o modelo lgico
O Input para a modelagem o documento gerado nos
Workshops de requerimentos com o usurio
BW Schema & Star Schema x Snowflake Schema
A 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 Schema voltada 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 dever
atender a performance e aos requisitos de anlise
12
SAP AG 2003, Norberto Harada/ 12
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
Criar 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/ 13
Ns 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/ 14
1. Os processos e por conseguinte as tabelas de Fatos
O 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 MER da fonte de dados ou
Conhecer a parametrizao do R/3
Lembre-se de priorizar as entidades do MER, pertinentes
ao escopo
Aps 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 + algoritmos
Para 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/ 16
Decidir se os indicadores levantados , sero
modelados em uma ou mais tabelas de fatos
Separe as tabelas 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 fatos
Fatos de Vendas
Fatos de Clientes
Neste 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/ 17
0NUH 6U8 PR00 00AT 8ALP 00AT 0ELP 0AT |LP 00TY 0PR| 00TY 0PR| 0TY PR|
1 C1 P1 1998 31 5 100 0 0 0 0
2 C2 P1 1998 32 10 200 0 0 0 0
3 C1 P2 199Z 33 1 130 0 0 0 0
1 C2 P2 199Z 32 8 150 0 0 0 0
1 C2 P2 1998 32 -2 -10 0 0 0 0
1 C1 P1 1998 02 0 0 5 100 0 0
2 C2 P1 1999 01 0 0 Z 120 0 0
2 C2 P1 1999 02 0 0 3 80 0 0
3 C1 P2 1998 01 0 0 2 0 0 0
1 C2 P2 1998 02 0 0 110 0 0
1 C1 P1 1999 81 0 0 0 0 5 100
2 C2 P1 1999 81 0 0 0 0 10 200
3 C1 P2 1998 82 0 0 0 0 1 130
Order - Delivery - Billing Cube
Common
Chars
Sales
Chars
Delivery
Chars
Billing
Chars
Sales
Keyfs
Delivery
Keyfs
Billing
Keyfs
Evite modelar Key Figures que s so preenchidas para determinados
valores de uma dimenso.
Isto pode indicar a necessidade de uma outra tabela de fatos.
1
2
Neste 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 caractersticas e 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 um MultiCubo.
18
SAP AG 2003, Norberto Harada/ 18
Sales
Cube
Billing
Cube
Sales
Delivery
Billing
Multi-Cube
Multi-Cube Queries
Basic-Cube Queries Basic-Cube Queries
Delivery
Cube
Basic-Cube Queries
Uma 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 para o 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/ 19
Espao desperdiado pela
key figure em branco
T
a
b
e
l
a

d
e

F
a
t
o
s
Dim_1 Dim_2 Dim_3 KF_1 KF_2 KF_3
Espao ocupado por um
novo Infocubo criado
especificamente para a key
figure em branco
Espao economizado ao
criar um novo Infocubo
especificamente para a key
figure em branco
Criar 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 InfoCubo
Ec => Espao economizado
qtreg_c => estimativa da quantidade de registros na fact table
origem
qtreg_o => estimativa da quantidade de registros na nova fact
tb
qtkf => quantidade de key figures a serem separadas
qtdim => quantidade de dimenses
Resultado: Eo / Ec deve ser < 1
20
SAP AG 2003, Norberto Harada/ 20
Dados Recentes
Dados Histricos
Multicubo
Cubo Particao 1
Cubo Bsico
Com agregados
Cubos
Particao n
Cubo Bsico
Com agregados
Cubo
Particao 2
Cubo Bsico
Com agregados
Cubo de Carga
Cubo Bsico
Sem agregados
DataSource,
ODS, PSA etc...
Filtra criterio n
Extrao, rollup e excluso de dados do cubo de carga (periodo noturno ou semanal)
Sugesto de Modelagem para modelos com grande volume de registros
Filtra
criterio 2
Filtra
criterio 1
1) Registros distribudos entre os Cubos: Cubo Particao 1, Cubo
particao 2, Cubos Particao 'n'.
2) Distribuir os registros de forma a aproveitar o paralelismo das
queries.
3) O ideal seria se os "Cubos Partio" se tornassem estticos com o
tempo.
4) O Cubo de Carga, sem agregados, recebe os dados da carga
5) 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
pode
ser implementado por archiving por questes de integridade
7) O rollup poderia ser noturno ou semanal, no necessrio que
rode
Logo aps a carga
8) Haveria independncia entre a carga e o rollup
9) A ausncia de agregados no Cubo de Carga evitaria dados
indisponveis por falta de rollup
21
SAP AG 2003, Norberto Harada/ 21
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
22
SAP AG 2003, Norberto Harada/ 22
2. A granularidade das tabelas de Fatos
O 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. 45
Alto nvel de detalhe
=
Baixo nvel de
granularidade
Baixo nvel de detalhe
=
Alto nvel de
granularidade
O 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/ 23
Escolher 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, granulao
A 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 2
Parte 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 Carga
Por 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 A
seriam 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. O Top 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/ 25
Fonte de dados
20.000 registros por dia
Tabela de Fatos com
dados em nvel de detalhe dirio
dos ltimos 3 anos
Duas Tabelas de Fatos
Nvel de detalhe
dirio
dados do ms
corrente
Nvel de detalhe
mensal
dados 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 mdia
At 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 Cube
Pode-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/ 28
ods
Data
warehouse
Corporate information factory
O BW aceita a arquitetura Inmon,
ODS = enterprise data warehouse.
Abordagens:
1) arquitetura integrada do BW
2) arquitetura composta
O BW aceita a arquitetura Inmon,
ODS = enterprise data warehouse.
Abordagens:
1) arquitetura integrada do BW
2) arquitetura composta
ERP
Data Warehouse
data
staging
area
O BW aceita a arquitetura
Kimball. A PSA e o ODS = data
staging area
InfoCubos = data marts.
O BW aceita a arquitetura
Kimball. A PSA e o ODS = data
staging area
InfoCubos = data marts.
29
SAP AG 2003, Norberto Harada/ 29
Data flow modeling standards
2
design framework
There 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. Kimball
Data marts
OLTP
Application
customer
product
Mkt seg
Day/month/yy
store
document
item
Sales value
customer product
Mkt segment
Month/Year
store
Sales value
Data mart X
customer product
Day/month/yy
Sales value
Data mart Y
PRG 1
PRG 2
30
SAP AG 2003, Norberto Harada/ 30
finance
sales
Aplicao
OLTP
Data Mart
Building 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.Inmon
31
SAP AG 2003, Norberto Harada/ 31
finance
sales
marketing
hr
engineerg
actuarial
accountg
auditing
OLTP
application
Data Mart
Figure (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.Inmon
32
SAP AG 2003, Norberto Harada/ 32
finance
sales
marketing
hr
engineerg
actuarial
accountg
auditing
OLTP
application
Data Mart
It 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
term
W.H.Inmon
Inmon position against data mart
enterprise
data
warehouse
The central
data
warehouse
avoilds the
stovepiping
Isolated 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/ 33
Data flow modeling standards
2
design framework
If 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. Kimball
Extratores que agregam dados
provocam o stovepiping
Data marts
OLTP
Application
customer
product
Mkt seg
Day/month/yy
store
document
item
customer product
Mkt segment
Month/Year
store
Sales value
Data mart X
customer product
Day/month/yy
Sales value
Data mart Y
PRG 1
PRG 2
Sales value
For 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/ 34
Data flow modeling standards
2
design framework
OLTP
Application
PRG
C
u
r
r
e
n
t

l
e
v
e
l

o
f

d
e
t
a
i
l
(
I
n
m
o
n

s

c
o
n
c
e
p
t
)
Staging Area
(Kimballs concept)
enterprise
data warehouse
(Inmons concept)
InfoSources
(BW concept)
customer product
Mkt segment
Month/Year
store
Sales value
Data mart X
customer product
Day/month/yy
Sales value
Data mart Y
customer
product
Mkt seg
Day/month/yy
store
document
item
Sales value
customer
product
Mkt seg
Day/month/yy
store
document
item
Sales value
The correct data flow modeling is like appears
on the ilustration above: the data have to be
brought from the OLTP on 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/ 35
Data flow modeling standards
2
design framework
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. 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 Store
The 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.
OLTP
Application
BCT
C
u
r
r
e
n
t

l
e
v
e
l

o
f

d
e
t
a
i
l
(
I
n
m
o
n

s

c
o
n
c
e
p
t
)
Staging Area
(Kimballs concept)
enterprise
data warehouse
(Inmons concept)
InfoSources
(BW concept)
customer
product
Mkt seg
Day/month/yy
store
document
item
Sales value
customer
product
Mkt seg
Day/month/yy
store
document
item
Sales value
36
SAP AG 2003, Norberto Harada/ 36
ods
Data
warehouse
Corporate information factory
ODS modelado com enterprise
data warehouse
ODS modelado com enterprise
data warehouse
ERP
Data Warehouse
data
staging
area
DataSource modelado como
data staging area, sem
persistencia de dados
DataSource modelado como
data staging area, sem
persistencia de dados
37
SAP AG 2003, Norberto Harada/ 37
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
38
SAP AG 2003, Norberto Harada/ 38
Tabela de Fatos
Pacote
Dim. Pacote
Mes/Ano
Ano
Dia
Dim. Tempo
Responsvel
Proprietrio
- UF
Dim. Responsvel
Unidade / Moeda
Dim. 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/ 39
ods
Data
warehouse
Corporate information factory
Modelos MOLAP :
mais restries de modelagem
oferecem mais performance
flexibilidade para queries ad-hoc
Modelos MOLAP :
mais restries de modelagem
oferecem mais performance
flexibilidade para queries ad-hoc
ERP
Data Warehouse
data
staging
area
Modelos ROLAP :
Mais recursos de modelagem
Menos performance do que MOLAP
Mais opes para tuning de
performance
Flexibilidade para queries ad-hoc
deve ser controlada
Modelos ROLAP :
Mais recursos de modelagem
Menos performance do que MOLAP
Mais opes para tuning de
performance
Flexibilidade para queries ad-hoc
deve ser controlada
40
SAP AG 2003, Norberto Harada/ 40
Tipos diferentes de usurios em ambiente OLAP
alta
baixa
Consumidor de
informaes
analista
autor
70%
20%
10%
N
e
c
e
s
s
i
d
a
d
e

d
e

r
e
c
u
r
s
o
s

a
n
a
l

t
i
c
o
s
Definio de queries
queries ad-hoc
Anlise multidimensional
Navegao pr-definida e
auto-explicativa
Colees de dados pr
definidas
Relatrios estticos
P
o
w
e
r
-
u
s
e
r
e
n
d
-
u
s
e
r
41
SAP AG 2003, Norberto Harada/ 41
Modelagem diferente para usurios diferentes
alta
baixa
Consumidor de
informaes
analista
autor
70%
20%
10%
N
e
c
e
s
s
i
d
a
d
e

d
e

r
e
c
u
r
s
o
s

a
n
a
l

t
i
c
o
s
Modelos para oferecer queries
ad-hoc
Uma caracterstica por
dimenso
Poucos atributos
Acesso somente para
usurios qualificados
Modelos para consumidores de
informao
Modelos utilizando todos os
recursos do BW
Power user cria queries para
disponibilizar para os
consumidores
P
o
w
e
r
-
u
s
e
r
e
n
d
-
u
s
e
r
42
SAP AG 2003, Norberto Harada/ 42
PAA - Custos
Atividade
Dim. Atividade
Mes/Ano
Ano
Dia
Dim. Tempo
Dim. Proprietario
Unid. Negcio
Dim. Unid. Negcio
OT
Dim. OT
Proprietrio
?
Decidir quais sero as
dimenses. por
exemplo :
Como modelar
Proprietrio da
Unidade de Negcio,
como uma
caracterstica
na dimenso
ou como
atributo da
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/ 43
Caractersticas 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 ou
como atributos navegacionais
Por enquanto no se preocupe onde colocar o atributo, pois
ser tratado mais adiante no 5o. Decision Point
Unid. Negcio
Proprietario
Dim. Unid. Negcio
Material
Grupo Material
Dim. Material
Cliente
Regiao
Pais
Estado
Cidade
Dim. Cliente
Unid. Negcio
Proprietario
Dim. Unid. Negcio
?
1 2
1
2
O 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 cdigos
C 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 o
0 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 o
0 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 s
0 0 0 0 0 0 0 0 0 3 A C M E I n c . U S A T o d o s
Tabela de dimenso Star Schema, o browsing feito por texto
Cod.Cliente Data Valor Qtd
0000000001 01/01/01 10 5
0000000002 01/01/01 20 6
0000000003 01/01/01 30 7
Tabela de Fatos Star Schema
Para 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/ 45
Tabela de Fatos
Produto
- Linha
Cor
Dim. Produto
SID ID Codigo Cor
1 45534 Marinho
2 56453 Preto
3 24543 Pink
SID ID Codigo Produto Linha
1 XA01 Sapato Social Masc
2 XA02 Sapato Esport Masc
3 XA03 Bota Trekking Fem
SID ID
Produto
SID
ID
Cor
DIM
ID
1 1 1
1 2 2
2 2 3
3 2 4
3 3 5
Tabela de Fatos
Dados Mestres Cor Dados Mestres Produto
Produto Cor Qtd.
Sapato Social Marinho 10
Sapato Social Preto 20
Sapato Esport Preto 30
Bota Trekking Preto 40
Bota Trekking Pink 50
Sapato Social Marinho 5
Sapato Social Preto 10
Sapato Esport Preto 1
Bota Trekking Preto 10
Bota Trekking Pink 1
Registros de Movimento
DIM TABLE
DIM ID Qtd.
1 10
2 20
3 30
4 40
5 50
1 5
2 10
3 1
4 10
5 1
No BW Schema a 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 h
registros de movimento. Observe que Sapato Esport no registro de
movimento 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 Table ser referenciada neste
trabalho como instncia para efeito didtico. Na prxima transparncia h
uma 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/ 46
Dimenses devem ser modeladas de maneira que o numero
de instncias seja pequena.
Regra emprica 1:
famahho da fabeTa de d1mehso* 1 famahho da acf fabTe
deve ser menor que 15%
* em qtd registros
Regra 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/ 47
Caractersticas 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...
Clientes
Produtos
Dim. Clientes e Produtos
N:M Fatos de Vendas
Dim. Cliente Dim. Produto
Modelar 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/ 48
Exceo 1: se N e M forem pequenos
( de 2 a 4 registros - Ou se N * M < 10.000 )
Exceo 2: Relacionamentos N:M podem ocorrer na mesma
dimenso em casos como Material e Cor
Material Cor
Este 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 dimenso
Fatos de Vendas
Material
Cor
Dim. Material
Novamente 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/ 49
No 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 Dimension
elimina 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/ 50
O 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 dimenso
2) N:M deveria ficar em dimenses separadas
2.1. Exceto se N e M forem pequenos
2.2. Exceto se N e M possuirem um relacionamento
semntico, como Material e Cor
Mas 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/ 51
Exemplo 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.
Valor
Quantidade
Fatos de Vendas
Produto
Grupo de Produto
Dim. Produto
Valor
Quantidade
Fatos de Vendas
Produto
Dim. Produto
Grupo de Produto
Dim. Grupo Produto
Neste exemplo, h 3 drivers para deciso por esta forma de modelagem:
1) Necessidades de anlise: grande quantidade de queries pelo atributo da
caracterstica em foco
2) Performance
3) 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/ 52
Agente 1,2,3,4
Condio de Pagto
Agncia de Vendas
Importador Final
Empresa
Ano/Mes/Dia
Incoterms
Unidade Produtiva
Transportadora
Tipo de Necessidade
Terminal Brasil
Tipo Ordem de Venda
Cliente Emitente
Cliente Recebedor
Vendedor
Setor de Atividade
Canal Distribuio
Aplicao
Exemplo 2: Inflao de Dimenses
Pode acontecer de sua modelagem apresentar diversas
dimenses pequenas, com uma ou duas caracteristicas onde
estas caracteristicas possuem apenas um pequeno numero de
valores...
Produto
Infocubo de Faturamento
Quantidade Faturada
Valor PIS
Valor COFINS
Valor ICMS
Valor IPI
Despesas Financeiras
Preo Mdio a Vista com PIS e COFINS
Preo Mdio a Vista sem PIS e COFINS
Preo Mdio sem PIS e COFINS
Preo Mdio Bruto
Preo FOB
Valor da Comisso do Agente 1,2,3,4
Valor de Comisses de Representantes
Valor de Descontos
Numero de Notas Fiscais Emitidas
Neste exemplo, Incoterms contem somente CIF e FOB
Tipo 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/ 53
considere 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 Dimenso
Como o BW no obriga que apenas caracteristicas
correlatas sejam modeladas na mesma dimenso,
possvel criar uma dimenso coletando caractersticas
no correlatas.
Incoterms
Tipo de Necessidade
Aplicao
Setor de Atividade
Canal Distribuio
Condio de Pagto
Dim. Modalidade Venda
O 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, etc
Se 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/ 54
Partitioning Dimension: Frank Mc Guff
Se durante a modelagem, atributos com nomes parecidos
com: Valores Reais / Valores Planejados / Valores Orados
aparecerem, 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 Orado
Valor Real
PAA Custos
Dim. Atividade
Dim. Conta
Dim. Tempo
Valor
PAA Custos
Dim. Atividade
Dim. Conta
Dim. Tempo
Cenrio
Tipo Valor
A 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/ 55
Plan,
Forecast..
Data
Cube
Actual Data
Cube
Plan JActual
Multi-Cube
Multi-Cube Queries
Basic-Cube Queries Basic-Cube Queries
Utilizar 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/ 56
Degenerated 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 Kimball
57
SAP AG 2003, Norberto Harada/ 57
Dimenso 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 quebra
PAA - Custos
Dim. Atividade
0CALYEAR
0CALQUARTER
0CALMONTH
Dim. Tempo
Dim. Responsavel
A dimenso tempo obrigatria em todo modelo. O modelador sempre ter
de 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/ 58
Lidando 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 - Custos
Dim. Atividade
0CALYEAR
0CALQUARTER
0CALMONTH
Dim. Tempo
Dim. Resp
0CALYEAR
0CALQUARTER
0CALMONTH
Dim. Tempo
Caractersticas de tempo disponveis no BCT at BW 3.0B SP13:
0CALDAY Dia de Calendrio
0CALMONTH Ano Civil / Ms
0CALMONTH2 Ms Calendrio
0CALQUART1 Trimestre
0CALQUARTER Ano Civil / Trimestre
0CALWEEK Ano Civil / Semana
0CALYEAR Ano civil
0FISCPER Exerccio/ Perodo
0FISCPER3 Perodo Contbil
0FISCVARNT Variante de exerccio
0FISCYEAR Exerccio
0HALFYEAR1 Semestre
0WEEKDAY1 Dia da Semana
59
SAP AG 2003, Norberto Harada/ 59
O 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 infocubo
Data de Emisso
Valor
Fatos de Contas a Pagar
0CALDAY
Dim. Data Abertura
DT_FECH
Dim. Data Fechamento

D
im
. T
e
m
p
o

Para 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/ 60
Tabela de Fatos
DT_EMISSAO
DT_FECHMTO
Dim. Datas
Colocar 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.255
Tabela de Fatos
MES_EMISS
MES_FECHMTO
Dim. Tempo
12 meses x 12 meses
= 144
12 meses x 5
anos = 60 meses
60 meses x 60
meses
= 3.600
O 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/ 61
Modelos com mais que uma data freqentemente remetem a
granularidade prxima ao nvel transacional.
Data
Abertura
Data
Fechamento
Cliente Valor
01/01/01 01/01/01 01 10,01
01/01/01 02/01/01 01 10,02
01/01/01 01/01/01 02 10,03
02/01/01 02/01/01 02 10,04
02/01/01 03/01/01 01 10,05
03/01/01 05/01/01 01 10,06
01/01/01 01/01/01 01 11,00
04/01/01 06/01/01 02 10,07
Neste 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 ou
InfoCubo:
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/ 62
SAC BR
Quantidade de Manifestaes
Data Abertura
Data Fechamento
Data do Prazo
Dias Fora do Prazo
Durao
Dim. Cd. Manifestao
Cdigo Manifestao
1:1
Dim. Data Abertura
Ano
Ms/Ano
Dia/Ms/Ano
Dim. Data Fechamento
Ano
Ms/Ano
Dia/Ms/Ano
Dim. Data Prazo
Ano
Ms/Ano
Dia/Ms/Ano
Dim. Linha Produto
Linha Produto
Dim. Solucionador
Solucionador
- Chave
Organizao Solucionador
- Gerencia Solucionador
- rgo Solucionador
Dim. Manifestao
Especialidade da Manifestao
- Categoria Manifestao
- Assunto Manifestao
- Manifestao
- Tipo Manifestao
Origem Manifestao
Canal de Contato
Dim. Atendimento
Cadastrador
- Chave
Organizao Atendimento
- Gerencia Atendimento
- rgo Atendimento
Dim. Status Manifestao
Situao no periodo selecionado
Situao atual Manifestao
Ao Manifestao
Dim. Local do Evento
Regio do Evento
Estado do Evento
Cidade do Evento
Bairro do Evento
Dim. Cliente
Cliente
1
1 1
2
3
4
5
Modelo Transacional com mais que uma data
Outros 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 virtuais
63
SAP AG 2003, Norberto Harada/ 63
Dim. Atendimento
Qtd. Manif. por Cliente
Qtd. Manifestaes Abertas
Qtd. Manifestaes Fechadas
Qtd. Manifestaes Tratadas
Dim. Tempo
Ms/Ano
Semana
Dim. Solucionador Dim. Atendimento
Dim. Cliente
Cliente
Modelo Dimensional com mais que uma data
Qtd. Manif. por Produto
Qtd. Manifestaes Abertas
Qtd. Manifestaes Fechadas
Qtd. Manifestaes Tratadas
Dim. Tempo
Ms/Ano
Semana
Dim. Solucionador
Dim. Produto
Produto
Prazos e duraes p/ Cliente
Dias Fora do Prazo
Durao
Prazo da resposta
Dim. Tempo
Ms/Ano
Semana
Dim. Solucionador Dim. Atendimento
Dim. Cliente
Cliente
Dim. Dias fora prazo
Dias fora do prazo
Dim. Durao
Durao
Dim. Prazo da resp.
Prazo da resposta
1
1
1
2 2
2
3
3
3
4
Como 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 os 6 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 data para um modelo dimensional:
1) Dimenso tempo contm a Data da foto, a fact table contm fotos extradas 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/ 64
Dimenso 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.
2
1
3
No 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/ 65
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
66
SAP AG 2003, Norberto Harada/ 66
4. Os Fatos incluindo fatos pr-calculados
Os 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. Kimball
Key Figures podem tambm ser:
mdias,
campos de data auxiliares,
valores no aditivos como preo unitrio. SAP
Apesar da afirmao de Kimball:
Os melhores e mais teis fatos so :
numricos,
valores contnuos
aditivos
a SAP afirma que key figures ( fatos ) podem ser :
no numricos, como Data e Hora
no aditivos como mdias e preo unitrio
67
SAP AG 2003, Norberto Harada/ 67
Key Figure na Tabela de Fatos vs. Caracterstica
Data Fornecedor Qtd.
(a)
Preo
(b)
Critrio 1
(a) * (b)
Critrio 2
( a) * (c)
05.2001 AAA 10 10,00 100,00 10000,00
05.2001 BBB 20 20,00 400,00 40000,00
06.2001 AAA 1 100,00 100,00 1000,00
06.2001 BBB 1 200,00 200,00 2000,00
07.2001 AAA 2 1000,00 (c) 2000,00 2000,00
07.2001 BBB 1 2000,00 (c) 2000,00 2000,00
Quantidade
Preo
Fatos de Compras
Dim. Fornecedor
Item
Preo (kf)
Dim. Item
Fornece
dor
Total
Critrio 1
Total
Critrio 2
AAA 2200,00 13000,00
BBB 2600,00 44000,00
1
2
3
4
5
Uma 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 Preo
normalmente. 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/ 68
Key Figures armazenadas vs. Key Figures calculadas 1:
Preo de lista estendido
Total de concesses
Total de descontos
Preo lquido estendido
Fatos de Vendas
Este >>>
Menos >>>
Menos >>>
Igual a >>>
R. Kimball - DBMS vol. 1 no. 1
Fatos pr-calculados
Preo lquido
estendido o Preo
de lista estendido -
Total de concesses
- Total de descontos
Devemos
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 1999
Ralph 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 Analyser recursos 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 roda no OLAP Engine - que est no servidor BW - e no na
workstation. O tempo para execuo dos clculos desprezvel.
Por outro lado, a quantidade de key 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/ 69
Uma tabela de fatos malfeita, com fatos no-numricos,
fatos no-cumulativos e periodicidade mista
Tipo de Vendedor
Status
Preo Unitrio
Margem bruta
Vendas dirias
Vendas do ano at o momento
Vendas no ano anterior
Fatos de Vendas
R. Kimball - DBMS vol. 1 no. 1
Dim. Tempo
Dim. Cliente
Dim. Produto
Dim. Promoao
No-numricos
no-cumulativos
periodicidade mista
Neste 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/ 70
Outra tabela de fatos mal-feita . Neste exemplo, os fatos deveriam
ser divididos por dimenses.
Vendas Janeiro
Vendas Fevereiro
Vendas Maro

Populao Masc. Acima 30 anos


Populao Fem. Acima 30 anos
Fatos de Vendas
Dim. Tempo
Dim. Cliente
Dim. Produto
Dim. 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 Vendas
e 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/ 71
No BW h 5 tipos de dado para Key Figures:
Montante
Quantidade
Numero
Data
Hora
Montante: 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 fonte como o
Oracle, o modelador deve investigar se a hora armazenada no campo
relevante 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:ss
72
SAP AG 2003, Norberto Harada/ 72
Key Figure Montante
Uma 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/ 73
Com converso.
Carrega-se a tabela de Fatos com uma moeda de referncia e
utiliza-se os recursos do BW para converso de moedas.
Valor
PAA - Custos
Dim. Atividade
Dim. Tempo Dim. OT
Fon1e de dados
01.2000 0T.01 AT.01 10,50 RL
01.2000 0T.02 AT.01 5,50 RL
02.2000 0T.01 AT.01 11,50 RL
02.2000 0T.02 AT.02 20,00 RL
Na 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/ 74
Multi - Moeda - Sem converso.
Carrega-se a tabela de Fatos com os valores j convertidos
para as moedas que se deseja analisar.
Valor
PAA - Custos
Dim. Atividade
Dim. Tempo Dim. OT
Fon1e de dados
01.2000 0T.01 AT.01 10,50 RL
01.2000 0T.02 AT.01 5,50 RL
61.2666 0T.61 AT.61 21,66 5
61.2666 0T.62 AT.61 11,66 5
02.2000 0T.01 AT.01 11,50 RL
02.2000 0T.02 AT.02 20,00 RL
62.2666 0T.61 AT.61 23,66 5
62.2666 0T.62 AT.62 46,66 5
No 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 est
disponvel para 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/ 75
Se 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 - Custos
Dim. Atividade
Dim. Tempo Dim. OT
Fon1e de dados
01.2000 0T.01 AT.01 10,50
01.2000 0T.02 AT.01 1,50
02.2000 0T.01 AT.01 11,50
02.2000 0T.02 AT.02 20,00
Se 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-aditiva
Quantity_on_hand
Inventory Fact
Product Dimension
Warehouse Dimension
Time Dimension
77
SAP AG 2003, Norberto Harada/ 77
Em promoo
Cobertura da Promoo
Dim. Ponto de Venda
Dim. Tempo
Dimenso Produto Dim. Promoo
Data Produto Ponto de Venda Promoo Em Promoo
01.2001 AAA PV01 PG2LV3 1
01.2001 BBB PV01 PG2LV3 1
02.2001 AAA PV01 PG3LV4 1
02.2001 BBB PV01 PG3LV4 1
02.2001 CCC PV02 PG3LV4 1
Factless Fact Table 1
Coverage Tables
H 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/ 78
Qtd_Clientes
Fatos Qtd Clientes
Filial
Empresa
Area
Tipo_Filial
Dim. Filial
Ano/Mes
Mes
Ano
Dim. Tempo
Canal Venda
Qtd Pessoas
Qtd Veic Proprios
Qtd Veic Terceiros
Dim. Canal Venda
Diviso
SubDiviso
Ordem
Dim. Produto
Factless Fact Tables 2
Frequentemente faz sentido introduzir adicionalmente uma
key figure artificial para facilitar a contagem
Factless 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 a key 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/ 79
Factless Fact Tables 3
A 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 promoo de 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/ 80
Observe 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 vendido
Qtd. Vendida
Fatos de Vendas
Loja
- Tipo de Loja
Dim. Ponto de Venda
Ano
Mes/Ano
Trimestre
Dim. Tempo
Produto
- Famlia
- Linha
Dim. Produto
Dim. 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/ 81
O conjunto diferena entre as duas tabelas (Cobertura da
Promoo e Fatos de Vendas) seria ento, os produtos que
estavam em promoo e no venderam.
Em promoo
Cobertura da Promoo
Dim. Ponto de Venda
Dim. Tempo
Dim. Produto
Dim. Promoo
Valor vendido
Qtd. Vendida
Fatos de Vendas
Dim. Ponto de Venda
Dim. Tempo
Dim. Produto
Dim. Promoo
NOT IN
No Star Schema convencional, para se obter a resposta query: Produtos
que estavam em promoo e no venderam a Coverage Table cujo conceito
j foi exposto anteriormente ( em Factless Fact Table 1 ) seria utilizada em
conjunto com a tabela de Fatos de Vendas.
O conjunto diferena entre as duas tabelas traria o resultado desejado. Para
se estabelecer o conjunto diferena utilizando SQL ANSI a declarao NOT
IN da clusula WHERE seria utilizada.
SELECT PRODUTO
FROM COBERTURA_PROMOCAO
WHERE PRODUTO
NOT IN ( SELECT PRODUTO
FROM FATOS_DE_VENDAS)
82
SAP AG 2003, Norberto Harada/ 82
Nota:
A afirmao da SAP:
No h uma maneira fcil de criar um modelo que
responda a respeito de coisas que no aconteceram.
Indica que a implementao desta soluo pode ser complexa.
Possivelmente estabelecer o conjunto diferena entre a Coverage
Table e a Fatos de vendas pode ser difcil no BW.
83
SAP AG 2003, Norberto Harada/ 83
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
84
SAP AG 2003, Norberto Harada/ 84
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
Definir e descrever atributos das dimenses
atributos navegacionais ou no navegacionais das
dimenses
Hierarquias
Master Data
Chave Composta ( Dependencias )
Status pode ser uma dimenso
85
SAP AG 2003, Norberto Harada/ 85
Lembre-se que o termo Atributo descreve a posio de uma
caracterstica na modelagem.
Um atributo uma caracterstica associada diretamente a outra
caracterstica em um relacionamento 1:N ( uma associao atravs
de uma dimenso seria indireta ).
Atributos definem um agrupamento das caractersticas, e podem
descrever uma hierarquia.
Material
Grupo Material
Dim. Material
Cliente
Regiao
Pais
Estado
Cidade
Dim. Cliente
86
SAP AG 2003, Norberto Harada/ 86
Cliente
-Regiao
-Pais
-Estado
-Cidade
Dim. Cliente
O BW no permite a modelagem de atributos de atributos.
Embora um infoobjeto que contenha atributos possa ser
modelado como atributo de outro objeto, o infocubo
enxerga somente as caractersticas e seus atributos diretos,
omitindo os atributos dos atributos.
87
SAP AG 2003, Norberto Harada/ 87
Material
Material Dimension
Materialgroup
Material
Dimension table
As a Characteristic As a Characteristic ? ?
Material
Master table
As a Navigational As a Navigational / /
Display Display Attribute Attribute ? ?
Material
Hierarchy table
As a Hierarchy As a Hierarchy ? ?
O BW Schema oferece mais de uma localizao possvel
para atributos dependentes ( pais ) . Onde colocar estes
atributos uma das decises da modelagem.
88
SAP AG 2003, Norberto Harada/ 88
Dependendo da localizao dos atributos, o comportamento
nos relatrios muda.
Assim as necessidades de apresentao de relatrios
definem a localizao de um atributo.
A localizao do atributo pode ser decidida a partir dos
seguintes pontos de vista:
Performance
Aspectos Globais de Design do Data Warehouse
Carga de dados
89
SAP AG 2003, Norberto Harada/ 89
Performance e localizao dos atributos
H pouco ou nada a dizer quanto localizao dos
atributos do ponto de vista de performance.
Assim as necessidades de apresentao de relatrios
definem a localizao de um atributo.
Utilizar atributos navegacionais tem performance menor
comparados com utilizar caractersticas diretamente na
dimenso.
Aspectos Globais de Design do Data Warehouse
Atributos Pai devem ser colocados no master data ou em hierarquias
externas para minimizar redundncia e garantir integrao no Data
Warehouse.
Data Warehousing deveria significar redundncia controlada para
atingir alto grau de integrao.
Deste ponto de vista todos os atributos pai deveriam residir no
master data, o que significa num caso extremo que haveria somente
uma caracteristica em cada dimenso.
90
SAP AG 2003, Norberto Harada/ 90
Carga de dados e localizao dos atributos
Caractersticas provenientes dos dados de movimento so
normalmente localizadas em uma dimenso (regra emprica)
Colocar em uma dimenso uma caracterstica que no
proveniente dos dados de movimento, ( ex: atributo que indica
Operao ou Investimento, gerado a partir de algoritmo ) gera:
esforo adicional de implementao,
ex: Update Rule (ou Transfer Rule) para determinar
o valor da caracteristica
overhead durante a carga
Caractersticas provenientes dos dados mestres so
normalmente localizadas como atributos
91
SAP AG 2003, Norberto Harada/ 91
Atributos podem ser:
Navegacionais
atributos sobre os quais deseja-se fazer drill-up, drill
down, consolidaes , quebras, filtros
no navegacionais ( Somente Display )
Cliente
~endereo
cidade
estado
~cep
faixa de idade
faixa de renda
estado civil
sexo
Dim. Cliente
A ativao de um atributo
navegacional pode ser feita
posteriormente. A desativao no
possvel.
92
SAP AG 2003, Norberto Harada/ 92
Master Data
O termo Master Data utilizado
genericamente para descrever a existncia
de uma tabela que descreve os valores
Cliente
estado
~cep
Dim. Cliente
Cliente
Estado
Master Data
cep
93
SAP AG 2003, Norberto Harada/ 93
() Master Data
Master Data pode ser utilizado em diversos InfoCubos
Master Data pode ter textos descritivos e pode ser utilizado
com hierarquias
( o tema hierarquia ser detalhado em tpico a seguir)
cep
Cliente
estado
~cep
Dim. Cliente
x
94
SAP AG 2003, Norberto Harada/ 94
Fsicamente existe Master Data e Textos, o Master Data utilizado
para vincular atributos e os Textos para descrever os valores
Cliente
Estado
TEXTOS
cep
x
MASTER DATA
IMPORTANTE !
Para garantir a Integridade Referencial do Banco de Dados:
- marque a opo Com dados mestre na definio do InfoObject
- marque a opo No atualizar dados, quando no existem dados mestre
para uma caracterstica na pasta Parmetros de atualizao no
InfoPackage de carga de Movimento.
- marque a opo No atualizar dados, quando no existem dados mestre
para uma caracterstica na pasta Parmetros de atualizao no
InfoPackage de carga de Atributos.
Garantir a Integridade Referencial atravs deste procedimento
responsabilidade do modelador.
95
SAP AG 2003, Norberto Harada/ 95
() Master Data
Pode ser dependente de tempo e de idioma
Geralmente existe Master Data para cada caracteristica em
uma DIM Table.
Mas uma caracterstica pode no possuir Master Data
Para definir atributos de uma caracterstica, necessrio
indicar que esta possui Master Data
O Master Data pode ser definido por:
Carga de um sistema R/3
Carga de um sistema no R/3
Manualmente por digitao no BW
Master Data definido manualmente no uma prtica recomendvel, pois
para transportar o modelo para QA e PRD necessrio redigitar os dados
nestes ambientes. No h transporte de dados mestres no BW.
96
SAP AG 2003, Norberto Harada/ 96
Caractersticas sem Master Data e sem Textos
No h check table no sistema fonte
Domnio fixo garantido por software
S se considera garantido se for implementado pelo
dicionrio de dados da camada de database. No h garantia
se a implementao for feita via hard-code na camada
application.
Exportar valores do dominio criando os textos no BW
Domnio aberto
Campo de digitao livre
Alterar o sistema fonte para domnio fixo ou check table
Levar para o BW pode causar inconsistncia
97
SAP AG 2003, Norberto Harada/ 97
Hierarquias:
natural e comum, especialmente para dimenses
orientadas a cliente, que uma dimenso permita multiplas
hierarquias simultaneamente. Drill up e Drill down com estas
hierarquias deve ser suportado em um Data warehouse
O BW suporta multiplas hierarquias para uma caracterstica
H 3 possibilidades de modelar hierarquias:
1. Hierarquia por caracteristicas na dimenso
2. Hierarquia por atributos de caracteristica
3. Hierarquia externa
98
SAP AG 2003, Norberto Harada/ 98
Uma hierarquia pode ter at 98 nveis
Pode ser dependente de tempo
Pode ter intervalos
A hierarquia pode ser definida atravs de:
Carga de um sistema R/3
Carga de um sistema no R/3
Manualmente, por digitao no BW
Definio manual de hierarquia no recomendvel pois no h transporte
de hierarquia para QA e PRD.
99
SAP AG 2003, Norberto Harada/ 99
Aspecto de uma
hierarquia
modelada
atravs de
caracteristicas
numa dimenso
ou atravs de
atributos de
caractersticas
100
SAP AG 2003, Norberto Harada/ 100
Aspecto de uma
hierarquia
modelada
atravs de
hierarquia
externa
101
SAP AG 2003, Norberto Harada/ 101
1. Hierarquias por caracteristicas na dimenso
O nmero de nveis fixo, cada nivel representado por
um InfoObject
Exemplo: dimenso geogrfica com InfoObjects
600NTRY, 6RE6I0N, 60ITY
Cliente
0C0UhTRY
0RE0T0h
0CTTY
Dim. Cliente
102
SAP AG 2003, Norberto Harada/ 102
Aspectos de Performance modelando Hierarquias por
caracteristicas na dimenso
Queries com este tipo de modelagem tem mais
performance do que as outras duas tcnicas
O BW no conhece explicitamente as dependencias da
hierarquia
Agregados que sumarizam dados a respeito de regies
no so utilizados por queries que sumarizam por pas
Voc deve sempre incluir manualmente os nveis
hierrquicos nos agregados
103
SAP AG 2003, Norberto Harada/ 103
2. Hierarquias por atributos de caracterstica
O nmero de nveis tambm fixo, cada nivel tambm
representado por um InfoObject
Exemplo: dimenso geogrfica com InfoObjects
600NTRY, 6RE6I0N, 60ITY como atributos de 650L_T0
0S0L0_T0
-0C0UhTRY
-0RE0T0h
-0CTTY
Dim. Cliente
104
SAP AG 2003, Norberto Harada/ 104
Aspectos de Performance modelando Hierarquias por
atributos na caracterstica
Utilizar atributos navegacionais tem performance menor
comparados com utilizar caracteristicas diretamente na
dimenso
A performance frequentemente no melhor do que
modelar por hierarquias externas
105
SAP AG 2003, Norberto Harada/ 105
3. Hierarquias externas
O nmero de nveis no fixo
Um exemplo tpico a hierarquia de centro de custos
Atividade
Dim. Atividade
106
SAP AG 2003, Norberto Harada/ 106
O Drill-Down com hierarquia externa automtico :
107
SAP AG 2003, Norberto Harada/ 107
Aspectos de Performance modelando Hierarquias externas
Hierarquias externas tem performance pior do que
hierarquias por caractersticas nas dimenses
Performance melhor do que hierarquias por atributos na
caracterstica
Uma hierarquia no deveria conter mais do que 100.000
folhas.
Hierarquias externas contendo vrios milhares de ns e
folhas podem ter performance pior do que as outras duas
tcnicas. Neste caso considere utilizar as outras duas
alternativas.
108
SAP AG 2003, Norberto Harada/ 108
() performance
Voc pode definir agregados por nveis de hierarquias.
Queries que sumarizam dados em niveis mais altos podem
obter vantagem destes agregados.
Se utilizar uma caracterstica para restringir um n em uma
Query, o resultado ser uma performance pobre.
109
SAP AG 2003, Norberto Harada/ 109
Hierarquias dependentes de tempo.
Por questes de performance, a dependencia temporal foi
implementada de duas maneiras diferentes. No h
diferenas entre as duas opes no resultado da query.
Hierarquia Total dependente de tempo
Toda a hierarquia possui um perodo de validade
Aceita agregados
Estrutura dependente de tempo
Cada relacionamento pai-filho tem um perodo de
validade
No aceita agregados
110
SAP AG 2003, Norberto Harada/ 110
Modelagem de hierarquia externa:
No aceitando lanamentos ns permitidos
Master data SOMENTE DAS FOLHAS !
FlatFile: utilizar 0HIER_NODE
Aceitando lanamentos para ns
tratados automaticamente pelo BW
Master data / Textos devemconter ns
FlatFile: Ao invs de 0HIER_NODE colocar nome do
InfoObject
111
SAP AG 2003, Norberto Harada/ 111
Chaves Compostas
Uma caracteristica pode no ser nica, e necessitar de um
atributo para descrev-la.
Exemplo: o InfoObject 0COSTCENTER do BCT somente
nico em conjunto com o InfoObject 0CO_AREA ( Controlling
Area )
{ Centro de Custo
Diviso }
Dim. Centro Custos
Procure evitar chaves compostas !
Chaves compostas representam sempre
um overhead em:
relatrios, pois o usurio sempre ter que qualificar a chave
composta,
e performance
112
SAP AG 2003, Norberto Harada/ 112
Frequently Changing Attributes ( Atributos de Status )
Um atributo de status deveria ser definido como uma
caracterstica em uma dimenso separada
A performance seria otimizada pois Status
frequentemente usado como filtro
Colocar o Status na mesma dimenso que Produto, por
exemplo, poderia resultar em exploso da DIM Table.
Produto
Status
Dim. Produto Produto
Dim. Produto
Valor de Vendas
Fatos de Vendas
Status
Dim. Status
113
SAP AG 2003, Norberto Harada/ 113
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
114
SAP AG 2003, Norberto Harada/ 114
Possiveis demandas de anlise
Material group 09/98 10/98
X 100 100
Y 300 400
Anlise pela configurao atual
Material group 09/98 10/98
X 200 200
Y 200 200
Anlise pela configurao passada
Material group 09/98 10/98
X 200 100
Y 200 400
Anlise pela realidade histrica
Material group 09/98 10/98
X 100 100
Y 200 200
Anlise por resultados comparaveis
configurao em 09/1998
Material Material group
AAA X
BBB X
CCC Y
DDD Y
configurao em 10/1998
Material Material group
AAA X
BBB Y (alterado )
CCC Y
DDD Y
EEE Y (Novo )
Material Data Valor
AAA 09/1998 100
BBB 09/1998 100
CCC 09/1998 100
DDD 09/1998 100
AAA 10/1998 100
BBB 10/1998 100
CCC 10/1998 100
DDD 10/1998 100
EEE 10/1998 100
Tabela de Fatos
6. Como rastrear Slowly
Changing Dimensions
115
SAP AG 2003, Norberto Harada/ 115
Anlise por resultados comparveis
Permite anlise somente por grupos de materiais que
no mudaram historicamente.
Configurao09/98:
Material Material group
AAA X
BBB X
CCC Y
DDD Y
Configurao10/98:
Material Material group
AAA X
BBB Y (changed)
CCC Y
DDD Y
EEE Y (new)
Demanda de anlise Tabela de Fatos
Material group Rev 9/98 Rev 10/98
X 100 100
Y 200 200
Anlise por resultados comparveis
Material Date Revenue
AAA 09/1998 100
BBB 09/1998 100
CCC 09/1998 100
DDD 09/1998 100
AAA 10/1998 100
BBB 10/1998 100
CCC 10/1998 100
DDD 10/1998 100
EEE 10/1998 100
Os itens em branco no mudaram historicamente
116
SAP AG 2003, Norberto Harada/ 116
1. Anlise pela configurao atual
As mudanas so facilmente aplicadas aos fatos j carregados no cubo
Soluo 1
Modele o grupo de material como atributo navegacional da
caracterstica
Dollars_sold
units_sold
dollars_cost
Sales Fact
Store Dimension
Time Dimension
Promotion Dimension
Material
Material Group
Dim. Material
117
SAP AG 2003, Norberto Harada/ 117
() Anlise pela configurao atual
As mudanas so facilmente aplicadas nos fatos j
carregados no cubo
ANTES
Cli 01
Cli 02
SP
RJ
DEPOIS
Cli 01
Cli 02
RJ
RJ
118
SAP AG 2003, Norberto Harada/ 118
() Anlise pela configurao atual
Soluo 2
Modele atravs de hierarquia externa. O grupo de material
ser um n da hierarquia.
Dollars_sold
units_sold
dollars_cost
Sales Fact
Time Dimension
Promotion Dimension
Material
Dim. Material
119
SAP AG 2003, Norberto Harada/ 119
2. Anlise pela configurao passada
Permite anlise pela configurao atual ou passadas
Soluo 1
Modele o grupo de material como Atributo Navegacional
dependente de tempo.
As faixas de validade ( Data de-at ) no aparecem na
Query, so utilizadas automaticamente pela dimenso
tempo
120
SAP AG 2003, Norberto Harada/ 120
() Anlise pela configurao passada
Soluo 2
Defina o atributo como n de uma Hierarquia Total
dependente de tempo. O identificador da hierarquia ( nome,
verso ) extendido com o intervalo de validade.
Material HierachyTable
-1
(All)
-2
(X)
-3
(Y)
001
(AAA)
002
(BBB)
003
(CCC)
004
(DDD)
005
(EEE)
-1
(All)
-2
(X)
-3
(Y)
001
(AAA)
002
(BBB)
003
(CCC)
004
(DDD)
Ext Hierarchy : Mathier
Valid From : 01/1000
Valid To : 09/1998
Ext Hierarchy : Mathier
Valid From : 10/1998
Valid To : 12/9999
121
SAP AG 2003, Norberto Harada/ 121
3. Anlise pela realidade histrica
Soluo
Modele os atributos como caracteristicas na dimenso
A os dados no mudam ou as mudanas no se aplicam ao passado (por
exemplo, fatos que j foram carregados no InfoCubo )
Neste exemplo, o sub grupo de negcios 2A passou a pertencer ao grupo de
negcios 1 a partir de 03.2000, a alterao no afeta os fatos que j foram
carregados
ANTES
Grupo 1
Grupo 2
1A
2A
2B
Grupo 1
Grupo 2
1A
2A
2B
DEPOIS
122
SAP AG 2003, Norberto Harada/ 122
4. Anlise por resultados comparveis
Soluo
Defina o atributo grupo de material como dependente de
tempo.
Defina atributos Data de e Data at como atributos
navegacionais dependentes de tempo
Na query, filtre pelas datas Data de e Data at
123
SAP AG 2003, Norberto Harada/ 123
Impactos:
possvel modelar todos os cenrios de slowly changing
dimension no mesmo InfoCubo
compreensvel que o usurio possa querer ter todos os
cenrios no mesmo InfoCubo. Caso o usurio assim o
queira, sem que haja uma necessidade de negcio
claramente definida, o usurio dever ser avisado que este
recurso ter seu preo:
O usurio perder a simplicidade do modelo multi
dimensional
Ir produzir overhead durante a carga e durante as
queries
124
SAP AG 2003, Norberto Harada/ 124
() Impactos:
Para cada cenrio adicional no modelo, a complexidade
aumenta e deste modo, aumenta o potencial de queries
erroneas ou com resultado ilusrio
Treinamento adicional deve ser feito para usurios de
queries ad-hoc e para autores de queries para exclarecer
a diferena entre os cenrios e como e quando utiliz-los
125
SAP AG 2003, Norberto Harada/ 125
A experincia mostra que:
O valor da estrutura histrica diminui com o tempo,
especialmente com o cenrio Anlise pela configurao
passada
O cenrios: Anlise pela configurao atual e Anlise
pela realidade histrica so os mais frequentes cenrios
Se o usurio tiver real necessidade de anlise por cenrios
diferentes no mesmo cubo, h regras que sero abordadas em
modelagem fsica.
H um grande overhead ao criar agregados por atributos
ou hierarquias com estrutura dependentes de tempo,
necessrio que o usurio defina quais datas ele deseja
navegar.
126
SAP AG 2003, Norberto Harada/ 126
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions, query
modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
127
SAP AG 2003, Norberto Harada/ 127
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
Agregados:
do ponto de vista de funcionalidade o modelo no necessita
de agregados, mas sob o ponto de vista de performance isto
pode ser necessrio se houver muitos registros na Fatos ou
nas Dimenses
Os agregados NO so o primeiro passo para otimizao de performance. O
agregados so MAIS do que tabelas consolidadas a partir da tabela de fatos.
De fato, os agregados aliados dim_table do BW bem como toda a
modelagem fsica desenhada pela SAP para otimizao dos recursos
existentes na camada de database da arquitetura 3-tier, tal como
star_transformation, indices binrios, particionamento de tabelas entre
outros recursos, fazem dos agregados parte da modelagem fsica built-in
SAP delivery. Esta modelagem fsica interna um dos pontos que fazem
do BW um verdadeiro servidor ROLAP.
Para Kimball os agregados so um dos tpicos tratados no 7o. Decision
point, o que ento, torna os agregados parte do modelo lgico.
Os agregados, juntamente com os recursos do database server que j foram
citados, fazem parte do OLAP Engine do BW que reproduz em um banco de
dados relacional o mesmo efeito que um banco de dados multidimensional.
128
SAP AG 2003, Norberto Harada/ 128
Os agregados podem ser definidos no ambiente de produo, mas o
modelador deve pr-definir agregados que certamente sero
necessrios, durante o processo de tuning.
01/00 50,00
02/00 50,00
03/00 50,00
01/01/00 10,00
02/01/00 10,00
03/01/00 10,00
04/01/00 10,00
05/01/00 10,00
01/02/00 10,00
02/02/00 10,00
03/02/00 10,00
04/02/00 10,00
05/02/00 10,00
01/03/00 10,00
02/03/00 10,00
03/03/00 10,00
04/03/00 10,00
05/03/00 10,00
Fact table
dario
Agregado
Mensal
Por exemplo: criar agregados
mensais em cubo dirio, se
existem varias queries por
ms.
O modelo no entra em produo sem o set mnimo de agregados para
otimizar a performance das queries que esto sendo entregues na etapa de
entrada em produo ( Go Live ).
As queries Ad Hoc executadas em ambiente de produo iro demandar a
criao de novos agregados neste ambiente. Modelagem de agregados so
parte do Workshop de Performance Tunning de BW. A equipe que monitora
e otimiza a performance no ambiente produtivo necessita deste Know How.
129
SAP AG 2003, Norberto Harada/ 129
Agregados s podem ser criados para BasicCubes
Agregados podem ser construdos para atender a
necessidades de queries individuais ou grupos de queries de
uma maneira otimizada.
Podem ser construidos a partir de caracteristicas, atributos
navegacionais, agrupados por ns de hierarquias externas.
H um grande overhead em criar agregados por atributos
ou hierarquias com estrutura dependentes de tempo.
O BW facilita o trabalho de modelagem de agregados. O BW prope
agregados para serem disponibilizados para o ambiente produtivo, o
modelador pode indicar a construo de um agregado a partir de uma query
especfica ou a partir de um conjunto de queries.
O BW prov uma interface amigvel, atravs do qual o modelador pode
analisar a estrutura dos agregados propostos e fazer suas prprias
implementaes.
A utilizao de algumas opes de modelagem, restringe a utilizao de
agregados. Atributos ou hierarquias com estrutura* dependentes de tempo
no podem ser utilizadas na modelagem dos agregados. Dependendo da
maneira que key figures virtuais so construdas, podem ocorrer restries
para modelagem de agregados.
Um agregado deve ser consideravelmente menor que sua fonte, ou seja, o
InfoCubo ou o agregado a partir de qual foi construdo. Agregados que no so
frequentemente afetados por mudanas devem ser 10 vezes menores que sua
fonte.
O fator 10 apenas uma regra emprica, o valor exato depende do usuario, do
sistema e do banco de dados. Por exemplo, se o Optimizer do banco de dados tem
problemas para criar um execution plan til para um SQL com muitos Joins,
agregados com pequena sumarizao podem ser teis se joins forem
economizados. SAP.
* h hierarquias Total dependente de tempo e com estrutura dependente de tempo. A hierarquia Total
dependente de tempo aceita agregados, ao passo que a hierarquia com estrutura dependente de tempo
no aceita agregados.
130
SAP AG 2003, Norberto Harada/ 130
Heterogeneous Dimensions
Exemplo
( caractersticas.
N:M )
Quantidade
Valor
Fatos de Vendas
Produto
Variedade
Gramatura
Cor
Maquina
Acondicionamento
Sentido da Fibra
Largura
Comprimento
Folhas por pacote
Pacotes por caixa
Diametro
Furo
Metragem
Formato
Linha dagua
Beneficiamento
Marca Comercial
Produto Papel
Produto
Classificao
Teor Seco Padro
Tipo de Celulose
Produto Celulose
Produto
Linha
Filme
Formato
Classe
Produto Filme
produto
131
SAP AG 2003, Norberto Harada/ 131
() Heterogeneous Dimensions
Em um Data Warehouse em que a dimenso deve descrever
um grande nmero de itens heterogneos, a tcnica
recomendada criar uma tabela de fatos central e uma
tabela de dimenses central a fim de permitir s queries
cruzar os tipos diferentes e criar uma tabela de fatos
personalizada e uma tabela de dimenso personalizada para
queries de cada tipo individual em profundidade.
Se houverem 500 milhes de registros na tabela de fatos
central, ento dever haver exatamente 500 milhes de
registros na somatria das tabelas de fatos personalizadas.
Ralph Kimball chapter 7
132
SAP AG 2003, Norberto Harada/ 132
() Heterogeneous Dimensions
Soluo 1: Star Schema Convencional
Quantidade
Valor
Fatos de Vendas Central
Produto
Variedade
Gramatura
Cor
Maquina
Acondicionamento
Sentido da Fibra
Largura
Comprimento
Folhas por pacote
Pacotes por caixa
Diametro
Furo
Metragem
Formato
Linha dagua
Beneficiamento
Marca Comercial
Produto Papel
Produto
Classificao
Teor Seco Padro
Tipo de Celulose
Produto Celulose
Produto
Linha
Filme
Formato
Classe
Produto Filme
Produto
Grupo Produto ( Filme
/ Celulose / Papel )
Dim. Produto
Quantidade
Valor
Fatos de Vendas Papel
Quantidade
Valor
Fatos de Vendas Filme
Quantidade
Valor
Fatos Vendas Celulose
133
SAP AG 2003, Norberto Harada/ 133
() Heterogeneous Dimensions
Soluo 2: Utilizando o MultiCubo do BW
Quantidade
Valor
Multi Cubo
Produto
Variedade
Gramatura
Cor
Maquina
Acondicionamento
Sentido da Fibra
Largura
Comprimento
Folhas por pacote
Pacotes por caixa
Diametro
Furo
Metragem
Formato
Linha dagua
Beneficiamento
Marca Comercial
Produto Papel
Produto
Classificao
Teor Seco Padro
Tipo de Celulose
Produto Celulose
Produto
Linha
Filme
Formato
Classe
Produto Filme
Produto
Grupo Produto ( Filme
/ Celulose / Papel )
Dim. Produto
Quantidade
Valor
Fatos de Vendas Papel
Quantidade
Valor
Fatos de Vendas Filme
Quantidade
Valor
Fatos Vendas Celulose
134
SAP AG 2003, Norberto Harada/ 134
Big Dimensions
Como lidar, por exemplo, com uma dimenso Cliente com
centenas de milhes de registros ?
Dollars_sold
units_sold
dollars_cost
Sales Fact
Cliente
nome
sobrenome
endereo
cidade
estado
cep
faixa de idade
faixa de renda
estado civil
sexo
Dim. Cliente
Soluo 1:
crie agregados para
caracteristicas
demograficas na dimenso
cliente
+ tempo de carga
+ consumo disco
135
SAP AG 2003, Norberto Harada/ 135
Soluo 2: Demographic Mini Dimensions
Dollars_sold
units_sold
dollars_cost
Sales Fact
Cliente
nome
sobrenome
endereo
cidade
estado
cep
idade
renda
estado civil
sexo
Dim. Cliente
Crie uma dimenso
demogrfica menor
utilizando atributos
demograficos do cliente
dados disponiveis
imediatamente aps
carga
+ overhead durante a
carga
faixa de idade
faixa de renda
estado civil
sexo
Demographics Dimension
136
SAP AG 2003, Norberto Harada/ 136
Queries por substrings
Apesar de search por substring se tratar de um tema
relativamente irrelevante em Data Warehouse, o uso da
declarao LIKE frequentemente tratada como m idia
em Data Warehouse, pois a maioria dos optimizers foram
um full scan na tabela de dimenso.
Existe tecnologia de indexao rpida disponvel que faria
este tipo de search se tornar rpido ( PATRICIA trees definido
por Knuth em Art of Computer Programming - Vol 3 - Addison Wesley )
R. Kimball Chapter 17 (1996)
A tecnologia PATRICIA Trees, citada por Kimball, existe apenas
conceitualmente.
O RDBMS ORACLE 8 - por exemplo - no suporta PATRICIA Trees, logo
a existncia conceitual da tecnologia ainda no uma soluo.
137
SAP AG 2003, Norberto Harada/ 137
() Queries por substrings
Uma demanda de query por substring pode indicar a necessidade
de fazer navegao a partir de informaes contidas em um campo
no atomico.
Por exemplo: um campo que contm a estrutura de uma conta
contbil, que em seus dgitos descreve uma hierarquia.
Soluo : criar atributos ou caractersticas para descrever os nveis
da hierarquia.
Outro caso a necessidade de localizar um nome de cliente a partir
de um trecho do nome. O BW 3.0B suporta esta feature.
138
SAP AG 2003, Norberto Harada/ 138
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
139
SAP AG 2003, Norberto Harada/ 139
8. A durao histrica do banco de dados
Planejar a durao pretendida do banco de dados. Na
maioria dos casos, ns deixamos aberta a possibilidade de
mudar de idia e deixar o histrico acumular por mais do
que, digamos, trs anos que haviam sido inicialmente
planejados.
Considere aspectos de archiving
140
SAP AG 2003, Norberto Harada/ 140
Data Warehouse no uma soluo para archiving !
KPIs Operacionais
KPIS Cadeia
de Valor
Tipos de
Informao
Interna
Informaes para o Dia a Dia
O valor dos dados histricos diminui em funo do tipo de
informao.
141
SAP AG 2003, Norberto Harada/ 141
Considere a possibilidade de aumentar a granularidade temporal
para o histrico.
Ano Atual Ano Passado Anos Anteriores
Mes/Ano
Dia/Mes/Ano
Trimestre/
Ano
+ granularidade
142
SAP AG 2003, Norberto Harada/ 142
Kimballs 9 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 Fatos
2. A granularidade das tabelas de Fatos
3. As dimenses das tabelas de Fatos
4. Os Fatos incluindo fatos pr-calculados
5. Os atributos das dimenses com descrio completa e
terminologia apropriada
6. Como rastrear Slowly Changing Dimensions
7. Os agregados, dimenses heterogneas, minidimensions,
query modes e outras decises de armazenamento fsico
8. A durao histrica do banco de dados
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
143
SAP AG 2003, Norberto Harada/ 143
9. A urgncia com a qual os dados so extraidos e
carregados no Data Warehouse
Frequncia de atualizao relacionada com a frequncia de anlise
e no com a granularidade temporal
Considere o tempo de carga para definir a frequncia de atualizao
Datas de fechamentos ( dos sistemas fontes, ou de processos )
podem afetar a frequncia de atualizao desejada.
144
SAP AG 2003, Norberto Harada/ 144
Padro de documentao de Modelo Lgico
Ferramenta Padro:
PowerPoint
145
SAP AG 2003, Norberto Harada/ 145
Tabela de Fatos
sem nomes tcnicos
No ttulo, a descrio do cubo, como
aparecer na rvore do catlogo de
Infocubo
fonte Arial 10
Key Figures Armazenadas listadas do
topo para baixo, na ordem em que se
deseja que apaream no cubo
Key Figures calculadas, abrir linha
em branco e listar em Itlico, abaixo
das Key Figures Armazenadas
146
SAP AG 2003, Norberto Harada/ 146
Dimenses
sem nomes tcnicos
textos em maiculas ou minsculas
ttulo: utilizar texto Dimenso ou
Dim
Conector padro ER 1:N (terminando
com esfera)
atributos identados com 3 espaos
abaixo da caracterstica filho
atributos no navegacionais
representados pelo caracter ~
atributos navegacionais representados
pelo caracter -
147
SAP AG 2003, Norberto Harada/ 147
Dimenses
Chaves compostas (no concatenadas)
representadas por { }
Caractersticas na mesma dimenso
listadas sem identao
Hierarquias
existencia de hierarquia representada
por um triangulo
se relevante, inserir nmero no
triangulo e legenda no rodap
informando para qual caracterstica a
hierarquia se refere e outras informaes
(sem inform. tecnica )
148
SAP AG 2003, Norberto Harada/ 148
Dimenso Tempo
Listar descrio dos nveis de granularidade temporal
Representar hierarquia se houver
Dimenses Unit e Packet
no necessrio representar estas dimenses no modelo lgico
149
SAP AG 2003, Norberto Harada/ 149
150
SAP AG 2003, Norberto Harada/ 150