Arquivo por tag: Modelagem

out 04 2011

Modelagem de Universos – Uma visão geral (Parte 02)

No artigo anterior vimos conceitos ligados à modelagem de universos no SAP BO como Contexto e Apelidos (Alias). Hoje vamos falar conceitualmente sobre tabelas derivadas e Hierarquias, conceitos extremamente importantes para que possamos fazer um universo bem modelado.

TABELAS DERIVADAS

Nem sempre é possível deixar o universo resolver os relacionamentos entre as entidades. Algumas vezes é necessário realizar consultas usando a linguagem do SGBD para ganhar performance.

Para manter o universo simples de dar manutenção, podemos utilizar recursos que abstraiam uma grande quantidade de  relacionamentos por uma visão (views), porém, não temos a possibilidade de alterar diretamente o banco de dados.

Tabelas derivadas são artifícios semelhantes a visões (views), porém, definidas no nível de universo.

Problemas Resolvidos com Tabelas Derivadas:

1-  Consultas mais performática, por utilizar instruções de baixo nível para acesso aos dados.

2-  Entidades identificadas mais facilmente.

3- Relacionamentos complexos abstraídos em uma estrutura similar a uma tabela.

Problemas Gerados pelas Tabelas Derivadas:

1- Consultas muito complexas são difíceis de manter, diferente de relacionamentos representados graficamente.

2- O desempenho de tabelas derivadas são inferiores a visões simples (views) ou visões materializadas (materialized views) no banco de dados, pois a consulta será validada e compilada sempre que for necessário.

3- Podem trazer problemas, pois, tratam-se de consultas que serão associadas a outras consultas montadas pelo próprio Business Objects.

HIERARQUIAS

1-  São definidas automaticamente pelo SAP BO, através da ordem em que as dimensões aparecem em uma classe.

2- Nem sempre todos os níveis da hierarquia estão presentes na mesma classe.

3- A hierarquia definida por padrão pelo SAP BO pode conter níveis incorretos.

Benefício do Uso de Hierarquias:

1 – Flexibilidade na definição de hierarquias lógicas.

2- Remoção de níveis indevidos.

3- Possibilidade de definir hierarquias que não estão materializadas em uma dimensão do Data Warehouse.

Problemas no Uso de Hierarquias:

1- Hierarquias definidas nas classes são mais intuitivas.

2- Hierarquias customizadas demandam tempo de manutenção.

Independente do negócio a ser modelado é sempre recomendável conhecermos os recursos que o Universo possui para que tenhamos melhores condições de determinar qual a melhor estratégia para se modelar um DW.

Com isso finalizamos essa parte conceitual sobre modelagem de Universos, espero que tenham gostado.

Até a próxima.

 

out 02 2011

Modelagem de Universos – Uma visão geral (Parte 01)

O objetivo desse artigo é mostrar os principais conceitos ligados à modelagem de um universo, como contexto, Apelido (alias), tabelas derivadas e Hierarquias.
Esses conceitos são importantes, pois através do conhecimento do negócio em que se está modelando, poderemos adotar um ou mais desses recursos disponíveis na ferramenta Universe Designer da SAP BO. Uma boa modelagem é fundamental para que se tenha um projeto de BI consistente, performático e que atenda de forma adequada os requerimentos de uma determinada área de negócio.

Com o Data Warehouse modelado, precisamos construir o universo, com a preocupação de
manter as qualidades, e agregar maiores benefícios onde possível.

Ao longo desse artigo serão apresentados os seguintes conceitos:

1-     Ferramentas para garantir a semântica das consultas: Contexto.

Benefícios: Impedir que o usuário realize consultas fora da semântica do negócio e  casos como produtos cartesianos.

2-     Ferramentas para possibilitar o reuso de entidades: Apelido (Alias).

          Benefícios: Utilizar mais de uma instância da mesma entidade no mesmo universo,  diminuindo o trabalho de modelagem e
manutenção.

3-    Ferramentas para possibilitar a abstração do modelo: Tabelas Derivadas.

        Benefícios: Permitir que consultas sejam realizadas utilizando SQL para prover maior desempenho e flexibilidade.

4-     Ferramentas para possibilitar a customização do modelo: Hierarquias.

       Benefícios: Possibilitar a definição de hierarquias não materializadas.

CONTEXTOS

Contextos permitem definir um conjunto de relacionamentos válidos, refletindo assim a semântica envolvida na análise do negócio e evitando que consultas inválidas e prejudiciais sejam executadas.

Ele também é indicado para modelos onde existem fatos com níveis de detalhes distintos. Isso porque impedirá o relacionamento de métricas com dimensões não relacionadas.

Sem ele, ao gerar uma consulta com dimensões que não se relacionam com as métricas, obteríamos um produto cartesiano.

Problemas Resolvidos com Contextos:

1-     Eliminam-se erros de relacionamentos cíclicos (loop relationships), pois, as entidades do contexto relacionam-se apenas dentro dos limites do contexto.

2-     Eliminam-se problemas de consultas arbitrárias a regras de negócio, orientando o usuário sobre como e o que explorar no modelo.

Não será possível realizar produto cartesiano com entidades de contextos diferentes, no entanto, essa possibilidade ainda existe em entidades do mesmo contexto. Veremos no Short Joins como eliminar essa possibilidade.

APELIDOS (Alias):

Eventualmente precisamos adicionar mais de uma referência à mesma entidade em um modelo,  porém, não podem existir duas entidades com o mesmo nome no universo.

Eventualmente nos deparamos com modelos onde os nomes são complexos e pouco semânticos.

O apelido (alias) é a ferramenta que permite atribuir um novo nome a referência de uma entidade, possibilitando maior clareza no seu nome ou que haja mais de uma referência sua dentro do mesmo universo.

No próximo artigo falaremos conceitualmente sobre tabelas derivadas e Hierarquias.

Até a próxima.

ago 08 2011

Modelagem Dimensional (Parte 03)

Pessoal, para terminarmos essa série de artigos sobre modelagem gostaria de deixar aqui algumas dicas valiosas que devemos considerar antes de começarmos a desenhar o modelo. Antes de mais nada é bom deixar claro que o objetivo desses artigos não é ensinar a modelar e sim a identificarmos pontos críticos em nossos projetos a fim de que possamos ter uma boa base para tomar a melhor decisão em relação a projetos de BI.

Devemos considerar no processo de modelagem, o negócio a ser modelado, aspectos da modelagem conceitual e modelagem lógica.

1 – O negócio

• Definir Área(s) de Negócio.

– Prioridades? Mercado? …

• Quais processos na área de negócio vai ser contemplado no modelo.

• Decidir Granularidades.

– Volume? Performance?

• Definir Dimensões, Atributos e Hierarquias.

• Definir métricas dos Fatos
– Valores Aditivos? Semi-Aditivos? Não-Aditivos?

2 -Modelagem Conceitual

– Esboce um modelo dimensional antes de efetivamente construir um modelo em alguma ferramenta de mercado, para nos auxiliar nessa atividade vale fazer uso de um modelo ER, caso o mesmo exista.

– Analisando o modelo ER poderemos identificar alguns Candidatos a Dimensões se observarmos essas regras simples:

• Entidades, relacionamentos 1:n.

– Candidatos a Fatos:

• Entidades que expressam documentos: NF, OC..

• Relacionamentos n:m com atributos numéricos.

– Atributos de dimensões com hierarquias ou relacionamento n:m entre eles sugerem agregados.

– Métricas de Fatos devem ser aditivas…

3 -Modelagem no Nível Lógico

No modelo logico devemos considerar as seguintes dicas:

– Tabelas fato são (em geral) normalizadas.

– Tabelas dimensão são desnormalizadas (ou
eventuamente normalizadas em Snowflakes).

– A granularidade do DW é em geral maior que a dos
DMs, portanto devemos ter cuidado de não transgredir essa regra.

Observando essas regras poderemos construir modelos de melhor qualidade e que atendam aos requisitos de negócio.

Espero que tenham gostado.

jul 26 2011

Lista de Valores (List of Values – LOV)

Olá pessoal,

hoje vamos aprofundar no quesito modelagem de universos e o post de hoje é Lista de Valores, o famoso LOV (do inglês, List Of Values).

Quando criamos um objeto do tipo dimensão ou detalhe em um universo, o BO atribui uma lista de valores. Essa lista de valores é uma seleção distinta dos valores da(s) coluna(s) a qual o objeto faz referência e é atribuída na criação do objetos, porém, somente será criada quando este for utilizado em algum critério de seleção pela primeira vez.
Os valores então serão lidos do banco e armazenados em um arquivo .LOV no servidor na mesma pasta do universo.
Uma vez atribuído LOV a objetos que estão agrupados em uma hierarquia, você irá criar uma consulta que transforma um dos objetos em um filtro de consulta.
Prática:
Acesse na barra de ferramentas do Universo do BO a seguinte opção: Ferramentas > Lista de valores > Criar lista de valores em cascata.

Mova os objetos na seqüência hierárquica que você gostaria de apresentar para seu usuário. Não se esqueça de marcar a opção “Exibição Hierárquica”. Após isso, clique em Gerar LOVs.
Salve e exporte o Universo. Teste no WebIntelligence executando qualquer consulta usando esta dimensão em questão.

Construa uma consulta e crie um “prompt” em um dos objetos da LOV em cascata. Por exemplo, no mais inferior na hierarquia, selecione um nome de cliente.

No Web Intelligence aparecerá o “prompt” para selecionar a dimensão em cascata.
• Benefícios:
–Flexibilidade na definição de valores customizáveis para um objeto do universo.
–Melhor desempenho, pois permite que a lista de valores seja carregada apenas uma vez e armazenada em um arquivo para posteriores consultas, diminuindo o acesso ao banco de dados.
 
 
• Problemas:
–Ocupa espaço em disco no servidor.
–Difícil de manter e atualizar, precisando da interação do usuário.
–Pode gerar a falsa impressão de falta de atualização no DW (Data Warehouse).

 

Até a próxima!

jul 21 2011

Modelagem de Universos (Index)

Hoje vamos discutir aqui uma forma eficiente de se otimizar consultas em um relatório construído no Infoview a partir de um Universo já criado apenas fazendo o uso de índices para as dimensões que são utilizadas como critério de seleção.

Observem os exemplos abaixo:

Para a construção do relatório acima foi utilizado o universo (Island Resorts Marketing), nele utilizamos a dimensão Country como filtro, esse mesmo filtro está trazendo uma string na sua cláusula o que torna o desempenho do relatório ruim como ilustra a figura abaixo.

A primeira grande tarefa para resolvermos esse problema é analisarmos o universo criado e verificar se no mesmo existe algum índice criado para a dimensão em questão. Devemos também analisar a consulta criada para o relatório em questão, observando o que poderá ser otimizado e melhorado.

Acessando o universo através do Designer analisamos o objeto que está sendo usado como filtro na consulta do relatório e criamos um índice para o mesmo conforme sequência abaixo:

1 – Análise do objeto no Universo

2 – Edite o objetivo e vá para a aba chaves conforme as figuras abaixo.

3 – Inclua a chave correspondente à descrição do objeto conforme a sequencia abaixo.

Recomendamos como boa prática sempre após a criação de um índice clicar no botão Analisar com o objetivo de encontrarmos algum problema. Estando tudo OK, salvamos as alterações feitas no Universo e exportamos o mesmo para o repositório do servidor. Voltamos no nosso relatório que está sendo otimizado e refazemos a consulta do mesmo utilizando o objeto já devidamente alterado. Ao analisarmos a nova query gerada observamos que na mesma já não constam as descrições em Country e sim  os códigos correspondentes aos países utilizados como filtro.

Benefícios dessa estratégia:

  •   Melhora a performance pois utilizará a chave da tabela como critério de seleção.
  • A chave primária de toda tabela é necessariamente um índice. Como vimos na modelagem multidimensional, a estratégia de definir uma chave numérica sequencial torna ainda mais eficiente a consulta.
  • Podemos economizar espaço em banco, evitando criar índices desnecessários e aproveitando melhor os já existentes.

 Problemas dessa estratégia:

  • Funciona quando as chaves são definidas corretamente e quando o usuário seleciona o valor na lista de valores.
  • Não funciona quando o usuário digita o valor do filtro manualmente ou responde a um prompt.
  • Apenas campos com valores únicos são beneficiados.
  • Funciona melhor com modelos em snowflake.

Espero que esse artigo tenham gostado desse artigo.

Até a próxima.

jul 19 2011

Modelagem Dimensional (Parte 02)

Junk Dimensions

Continuando nosso estudo sobre modelagem, hoje falaremos sobre uma dimensão em particular chamada de Junk Dimensions.

Vale sempre lembrar que o tipo de tabela utilizada em uma modelagem dimensional vai depender do tipo de negócio que estaremos modelando, ou seja, o conhecimento do negócio é primordial para que se faça uma modelagem coerente.

Uma das principais razões para que se construa uma dimensão Lixo se dá ao fato de encontrarmos ambientes transacionais complexos com uma variedade grande de atributos e dados (textos e flags). Esses dados muita das vezes não estão organizados de forma coerente e seu significado é obscuro.

A criação dessa dimensão Lixo em um ambiente de BI deve ser feita com muito cuidado para evitarmos erros de projeto.

Abaixo apresentamos um exemplo de uma dimensão Lixo.

Soluções que devem ser evitadas:

  • Deixar os flags e os atributos inalterados na tabela fato, pois a mesmo pode crescer muito;
  • Criar uma dimensão para cada flag ou atributo, pois poderá existir um número muito grande de dimensões no modelo construído;
  • Excluir todos os flags e atributos da modelagem, pois poderemos excluir algum item importante para o negócio.

 

Ao se analisar o dado para se construir uma dimensão dessas, devemos levar em consideração todos os flags e atributos textuais com o objetivo de criarmos uma ou mais dimensões Lixo. Abaixo seguem algumas dicas do que se deve fazer na hora de modelar uma dimensão Junk.

Cuidados na hora da modelagem:

 

  • Retirar os vários indicadores sim/não da tabela fato e levar todos para uma dimensão única
  • Cada um dos indicadores pode não estar correlacionado com os outros ou com as outras dimensões.
  • Quando estamos analisando um negócio onde encontramos muitas flags, devemos ter em mente que a dimensão lixo é um ótimo lugar para se armazenar todos esses flags.

 

Resumidamente podemos definir uma Dimensão Lixo como sendo um agrupamento de flags e atributos randômicos retirados da tabela fato e inseridos em uma dimensão.

Uma boa prática em desenvolvimento de projetos BI é reavaliar sempre a modelagem escolhida. O ajuste faz parte da evolução do modelo e dos projetos em si.

jul 18 2011

Modelagem Dimensional (Parte 01)

Hoje vamos começar uma série de dicas sobre um aspecto de muita relevância em um projeto de BI, que é a modelagem dimensional.

Como uma boa prática em projetos de BI é de extrema importância se conhecer o negócio no qual se está propondo atender.  A partir do conhecimento do negócio, métricas utilizadas, como são usadas as informações, etc. Conseguiremos elaborar uma arquitetura de BI que atenda aos requisitos de negócio e proporcione um crescimento do BI de forma organizada e estruturada.

O objetivo desse artigo é trazer alguns conceitos de modelagem dimensional que proporcione ao leitor um rápido entendimento do conceito tratado e ajude no dia a dia profissional de todos.

Slowly Changing Dimensions

Começaremos a nossa série de estudos analisando características dessa dimensão tão peculiar.

Vejamos:

  • Dimensões que mudam lentamente ao longo do tempo.
  • Dimensões que mudam ocasionalmente e esporadicamente, como produto e cliente.
  • As chaves dessas dimensões não mudam, porém os atributos que o descrevem mudam.

Exemplo: descrição de um produto ou de um cliente.

Existem algumas formas de se tratar essa dimensão vejamos alguns tipos:

Forma 1: Sobrescrever o registro da dimensão com os novos valores, perdendo o histórico.

Adequado para os casos em que o valor antigo do atributo não tem importância ou pode ser descartado.

Forma 2: Criar um novo registro na dimensão, com uma nova chave de identificação.

  • Técnica básica para rastrear as mudanças de um atributo em uma dimensão.
  • É necessária uma chave surrogada. A chave da dimensão não pode ser alterada.
  • Avaliar o uso de atributos do tipo data de início e fim para documentar o período em que aquele registro permaneceu válido.

Existem algumas outras formas de se tratar uma dimensão Slow Change mas as duas formas principais são essas apresentadas.

Devemos ter muito cuidado ao adotar esse tipo de dimensão em nosso projetos  para não gerarmos confusão entre os usuários finais.

Espero que tenham gostado desse primeiro artigo, estaremos voltando com outros aspectos da modelagem dimensional que nos ajudará também tecnicamente a elaborar um Universo adequado quando utilizamos em nossos projetos a ferramenta SAP BO.