Arquivo por categoria: 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 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.