Analisar e Planejar o Aplicativo Essbase

Para garantir que seu aplicativo Essbase analise suas informações de negócios com eficiência, formule um plano detalhado que descreva origens de dados, necessidades do usuário e elementos de banco de dados em potencial. A atenção a essa fase de design pode economizar tempo de desenvolvimento e implementação.

A fase de planejamento e análise envolve estas tarefas:

• Analisar Dados de Origem

• Identificar Requisitos do Usuário

• Plano de Segurança em um Ambiente de Vários Usuários

• Criar Modelos de Banco de Dados

Ao projetar uma aplicação multidimensional, considere estes fatores:

• Como as informações fluem dentro da empresa — quem usa quais dados para quais finalidades

• Os tipos de relatórios que a empresa faz — quais tipos de dados devem ser incluídos na estrutura para atender às necessidades de relatórios do usuário

  Observação:

  A definição de apenas um banco de dados por aplicativo melhora o uso da memória e a facilidade de administração do banco de dados.

Analisar Dados de Origem

Avalie os dados a serem incluídos no banco de dados do Essbase. Considere de onde vem e a frequência e o tamanho necessários das atualizações. Você deve carregar no Essbase somente o que é necessário para relatórios dinâmicos e drill-through. O restante pode permanecer em uma origem relacional, acessível por partição ou drill-through.

Determine o escopo do banco de dados. Se uma organização tiver várias famílias de produtos contendo um grande número de produtos, talvez você queira armazenar valores de dados apenas para famílias de produtos. Entreviste os membros de cada departamento de usuário para descobrir quais dados eles processam, como eles calculam e relatam dados hoje e como eles querem fazer isso no futuro.

Defina cuidadosamente as necessidades de relatórios e análises.

• Como os usuários desejam exibir e analisar dados?

• Quanto detalhe o banco de dados deve conter?

• Os dados suportam as metas de análise e relatório desejadas?

• Caso contrário, quais dados adicionais você precisa e onde você pode encontrá-los?

Determine a localização dos dados atuais.

• Onde cada departamento armazena dados atualmente?

• Os dados estão em um formato que o Essbase pode usar?

• Os departamentos armazenam dados em bancos de dados relacionais em servidores Windows ou UNIX ou em planilhas do Excel?

• Quem atualiza o banco de dados e com que frequência?

• Quem precisa atualizar os dados tem acesso a eles?

Verifique se os dados estão prontos para serem carregados no Essbase.

• Os dados vêm de uma única fonte ou de várias fontes?

• Os dados estão em um formato que o Essbase pode usar? Para obter uma lista de origens de dados válidas que você pode carregar no Essbase, consulte Origens de Dados.

• Todos os dados que você deseja usar estão prontamente disponíveis?

Identificar Requisitos do Usuário

À medida que você planeja o banco de dados do Essbase, discuta as necessidades de informações com os usuários atuais dos dados e solicite relatórios de amostra deles. Revise as informações que eles usam e os relatórios que devem gerar para revisão por outras pessoas.

Determine os seguintes requisitos:

• Quais tipos de análise os usuários exigem?

• Os usuários precisam de relatórios ad-hoc (estilo dinâmico) e de relatórios estruturados?

• Quais níveis de resumo e detalhes de informações os usuários precisam?

• Alguns usuários precisam de acesso a informações que outros usuários não devem ver?

Plano de Segurança em um Ambiente de Vários Usuários

Identifique diferentes níveis de necessidades de informações do usuário como parte do planejamento de como configurar as permissões de segurança do Essbase. No final da sua análise, você deverá ter uma lista de usuários e suas permissões necessárias.

Use esta checklist para planejar a segurança:

• Quem são os usuários e quais permissões eles devem ter para ler ou gravar dados no banco de dados?

• Quem deve ter permissões de carregamento de dados?

• Quem deve ter permissão para executar cálculos?

• Quais usuários podem ser agrupados e receber permissões semelhantes?

Consulte também Gerenciar Usuários e Atribuições.

Criar Modelos de Banco de Dados

Crie um modelo do banco de dados do Essbase. Para construir o modelo, você precisará identificar as perspectivas e as visualizações que são importantes para o seu negócio. Essas views são convertidas nas dimensões do modelo de banco de dados.

Muitas empresas analisam as seguintes visualizações:

• Períodos

• Medidas

• Cenários

• Produtos

• Customers

• Regiões geográficas

• Unidades de negócios

Em seguida, para ajudá-lo a coletar informações e tomar decisões, você precisará identificar objetivos de análise de dados, determinar as dimensões e os membros do banco de dados e analisar o design do banco de dados.

Identificar Objetivos da Análise

Depois de identificar as principais exibições de informações em uma empresa, a próxima etapa na criação de um banco de dados do Essbase é decidir como o banco de dados permite a análise de dados. Por exemplo, pode ser necessário exibir dados por período, por geografia ou por tipo de produto.

• Se analisar por tempo, quais períodos são necessários? A análise deve incluir apenas o ano atual ou vários anos? A análise deve incluir dados trimestrais e mensais? Deve incluir dados por temporada?

• Se analisar por região geográfica, como você define as regiões? Você define regiões por territórios de vendas? Você define regiões por fronteiras geográficas, como estados e cidades?

• Ao analisar por linha de produtos, você deve revisar os dados de cada produto? Você pode resumir dados em classes de produtos?

Independentemente das visualizações de negócios, você deve determinar a perspectiva e os detalhes necessários na análise. Cada área de negócios que você analisa fornece uma visão diferente dos dados.

Determinar Dimensões e Membros

As dimensões do Essbase que você escolhe determinam quais tipos de análise você pode executar. Em cada dimensão, as hierarquias de membros representam aspectos do negócio. Por exemplo, uma hierarquia de tempo pode incluir trimestres e meses. Uma hierarquia de produtos classifica produtos. Uma hierarquia regional é baseada em mercados geográficos.

Você pode representar cada view de negócios como uma dimensão padrão separada no banco de dados. Você pode ouvir analistas de negócios se referirem aos "bys" de seus negócios, como por produto, por geografia e por período. Se você precisar analisar uma view de negócios por classificação ou atributo, como pelo tamanho ou cor dos produtos, poderá usar dimensões ou propriedades de atributo para representar as views de classificação.

É possível usar quantas dimensões forem necessárias para análise. Quando souber aproximadamente quais dimensões e membros você precisa, desenvolva um design de banco de dados provisório.

Depois de determinar as dimensões do modelo de banco de dados, escolha os elementos ou itens dentro de cada dimensão. Esses elementos se tornam as hierarquias e membros de suas respectivas dimensões. Por exemplo, uma hierarquia de tempo pode incluir os períodos que você deseja analisar, como trimestres, e dentro de trimestres, meses. Cada trimestre e mês se torna um membro da dimensão que você cria para o tempo. Trimestres e meses representam uma hierarquia de dois níveis de membros e seus filhos. Meses dentro de um trimestre podem se consolidar em um total para cada trimestre.

Relacionamentos Entre Dimensões

Considere as relações entre as dimensões. A estrutura de um banco de dados do Essbase facilita para os usuários analisar informações de muitas perspectivas. Um analista financeiro, por exemplo, pode fazer as seguintes perguntas:

• O que são vendas de um determinado mês? Como esse número se compara às vendas no mesmo mês nos últimos cinco anos?

• Em que porcentagem a margem de lucro está aumentando?

• O quanto os valores reais estão próximos dos valores orçados?

Em outras palavras, o analista pode querer examinar informações de três dimensões: tempo, conta e cenário. O banco de dados de amostra ilustrado abaixo representa estas três dimensões, com uma dimensão representada ao longo de cada um dos três eixos:

• Uma dimensão de tempo, que compreende Jan, Fev, Mar e o total para Qtr1, é exibida ao longo do eixo X.

• Uma dimensão de contas, que consiste em números contábeis como Vendas, COGS, Margem e Margem%, é exibida ao longo do eixo Y.

• Outra dimensão, que fornece um ponto de vista diferente, como Orçamento para valores de orçamento e Real para valores reais, é exibida ao longo do eixo Z.

Figura 1-1 Cubo Representando Três Dimensões de Banco de Dados

As células dentro do cubo, onde os membros se cruzam, contêm os dados relevantes para todos os três membros que se cruzam; por exemplo, as vendas reais em janeiro.

Exemplo de Estrutura de Membros de Dimensão

A tabela abaixo mostra um resumo das dimensões do TBC. O designer de aplicativos criou três colunas, com as dimensões na coluna da esquerda e os membros nas duas colunas da direita. Os membros da coluna 3 são subcategorias dos membros da coluna 2. Em alguns casos, os membros da coluna 3 são divididos em outro nível de subcategorias; por exemplo, a dimensão Margem das Medidas é dividida em Vendas e COGS.

Tabela 1-1 Dimensões de Amostra TBC

Dimensões	Membros	Membros Filhos
Year	Trim1	Jan, Fev, Mar
Year	Trim2	Abr, Maio, Junho
Year	Trim3	Jul, Ago, Set
Year	Trim4	Out, Nov, Dez
Medidas	Lucro	Margem: Vendas, COGS Total de Despesas: Marketing, Folha de Pagamento, Diversos
Medidas	Inventário	Abrindo Inventário, Adições, Inventário Final
Medidas	Proporções	% Margem % Lucro % Lucro por Onça
Produto	Colas (100)	Cola (100‑10), Diet Cola (100‑20), Caffeine Free Cola (100‑30)
Produto	Cerveja Raiz (200)	Old Fashioned (200‑10), Diet Root Beer (200‑20), Sarsaparilla (200‑30), Birch Beer (200‑40)
Produto	refrigerante de creme (300)	Creme escuro (300‑10), creme de baunilha (300‑20), refrigerante diet (300‑30)
Produto	Soda De Frutas (400)	Uva (400‑10), laranja (400‑20), morango (400‑30)
Mercado	Leste	Connecticut, Flórida, Massachusetts, New Hampshire, Nova York
Mercado	Oeste	Califórnia, Nevada, Oregon, Utah, Washington
Mercado	Líbano Meridional	Louisiana, Novo México, Oklahoma, Texas
Mercado	Central	Colorado, Illinois, Iowa, Missouri, Ohio, Wisconsin
Cenário	Atual	N/D
Cenário	Orçamento	N/D
Cenário	Variação	N/D
Cenário	% de variação	N/D

Além disso, o designer de aplicativos adicionou as seguintes dimensões de atributo para permitir a análise do produto com base no tamanho e na embalagem:

Tabela 1-2 Dimensões de Atributo de Amostra TBC

Dimensões	Membros	Membros Filhos
Onças	Grande Pequeno	64, 32, 20 16, 12
Tipo de Embalagem	Garrafa É possível	N/D

Lista de Verificação para Determinar Dimensões e Membros

Use a seguinte lista de verificação ao determinar as dimensões e os membros do seu banco de dados de modelo:

• Quais são os candidatos às dimensões?

• Alguma das dimensões classifica ou descreve outras dimensões? Essas dimensões são candidatas a dimensões de atributo.

• Os usuários desejam qualificar sua view de uma dimensão? As categorias pelas quais qualificam uma dimensão são candidatas a dimensões de atributo.

• Quais são os candidatos aos membros?

• Quantos níveis os dados exigem?

• Como os dados se consolidam?

Analisar Design do Banco de Dados

Revise o design dimensional inicial do Essbase de acordo com essas diretrizes em torno do número de dimensões, do valor analítico combinado e da evitação de repetição. A execução dessa análise inicial ajudará você a obter um design de banco de dados eficiente que atenda às suas metas de consolidação e cálculo de dados.

O número de membros necessários para descrever um ponto de dados potencial deve determinar o número de dimensões. Se você não tiver certeza se deve excluir uma dimensão, mantenha-a e aplique mais regras de análise até se sentir confiante sobre como excluí-la ou mantê-la.

Dimensões Densas e Disparadas

Quais dimensões são escassas, e quais são densas, afetam o desempenho. Consulte:

• Dimensões Esparsas e Densas

• Projetar um Esquema de Tópicos para Otimizar o Desempenho

Dimensões Padrão e de Atributo

Para simplificar, os exemplos deste tópico mostram arranjos alternativos para o que foi inicialmente concebido como duas dimensões. É possível aplicar a mesma lógica a todas as combinações de dimensões.

Considere o design de uma empresa que vende produtos para vários clientes em vários mercados; os mercados são exclusivos para cada cliente:

             Cust A  Cust B  Cust C
New York     100     N/A     N/A
Illinois     N/A     150     N/A
California   N/A     N/A     30

Cust A é apenas em Nova York, Cust B é apenas em Illinois, e Cust C é apenas na Califórnia. A empresa pode definir os dados em uma dimensão padrão:

Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C

No entanto, se você observar uma amostra maior de dados, poderá ver que muitos clientes podem estar em cada mercado. Cust A e Cust E estão em Nova York; Cust B, Cust M e Cust P estão em Illinois; Cust C e Cust F estão na Califórnia. Nessa situação, a empresa normalmente define a dimensão grande, Cliente, como uma dimensão padrão e a dimensão menor, Mercado, como uma dimensão de atributo. A empresa associa os membros da dimensão Mercado como atributos dos membros da dimensão Cliente. Os membros da dimensão Mercado descrevem os locais dos clientes – cada cliente tem exatamente um mercado.

Customer (Standard dimension)
  Cust A (Attribute:New York)
  Cust B (Attribute:Illinois)
  Cust C (Attribute:California)
  Cust E (Attribute:New York)
  Cust F (Attribute:California)
  Cust M (Attribute:Illinois)
  Cust P (Attribute:Illinois)
Market (Attribute dimension)
  New York
  Illinois
  California

Considere outra situação. Mais uma vez, a empresa vende produtos para vários clientes em vários mercados, mas a empresa pode vender para um cliente que tem locais em diferentes mercados:

             Cust A  Cust B  Cust C
New York     100      75     N/A
Illinois     N/A     150     N/A
California   150     N/A      30

Cust A está em Nova York e Califórnia. Cust B está em Nova York e Illinois. Cust C é apenas na Califórnia. O uso de uma dimensão de atributo não funciona nessa situação; um membro do cliente não pode ter vários membros de atributo. Portanto, a empresa projeta os dados em duas dimensões padrão:

Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California

Combinações de Dimensão

Divida cada combinação de duas dimensões em uma matriz bidimensional. Por exemplo, as dimensões propostas no TBC incluem as seguintes combinações:

• Ano entre Medidas

• Ano do produto

• Ano no Mercado

• Ano após Cenário

• Medidas entre Produtos

• Medidas no Mercado

• Medidas no Cenário

• Mercado no Produto

• Mercado no Cenário

• Cenário no Produto

• Onças no Tipo de Pacote

Onças e Tipo de Pacote, como dimensões de atributo associadas à dimensão Produto, podem ser consideradas com a dimensão Produto.

Para ajudar a visualizar cada dimensão, desenhe uma matriz e inclua alguns dos membros de primeira geração. A imagem a seguir mostra um conjunto simplificado de matrizes para três dimensões.

Figura 1-2 Analisando Relacionamentos Dimensionais

Para cada combinação de dimensões, faça três perguntas:

• Acrescenta valor analítico?

• Ele adiciona utilidade para relatórios?

• Isso evita o excesso de combinações não utilizadas?

Para cada combinação, as respostas às perguntas ajudam a determinar se a combinação é válida para o banco de dados. O ideal é que a resposta a cada pergunta seja sim. Caso contrário, considere reorganizar os dados em dimensões mais significativas. À medida que você trabalha nesse processo, discuta as necessidades de informação com os usuários.

Repetição em Outlines

A repetição de elementos em um contorno geralmente indica a necessidade de dividir dimensões. Os exemplos a seguir mostram como evitar a repetição.

Neste exemplo, a coluna esquerda, denominada "Repetição", mostra Lucro, Margem, Vendas, COGS e Despesas repetidas em Orçamento e Real na dimensão Contas. A coluna direita, rotulada "Sem Repetição", separa Orçamento e Real em outra dimensão (Cenário), deixando apenas um conjunto de membros de Lucro, Margem, Vendas, COGS e Despesas na dimensão Contas. Essa abordagem simplifica o esboço e fornece uma visão mais simples do orçamento e dos números reais das outras dimensões no banco de dados.

Figura 1-3 Exemplo de Eliminação de Repetição Criando uma Dimensão de Cenário

Neste exemplo, a coluna esquerda, denominada "Repetição", usa membros compartilhados na dimensão Dieta para analisar bebidas dietéticas. Os membros 100–20, 200–20 e 300–20 são repetidos: uma vez sob a Dieta e outra sob seus respectivos pais. A coluna direita, rotulada "Sem Repetição", simplifica a estrutura criando uma dimensão de atributo Dieta do tipo Booliano (Verdadeiro ou Falso). Todos os membros são mostrados apenas uma vez, sob seus respectivos pais, e são marcados com o atributo apropriado ("Diet: True" ou "Diet: False").

Figura 1-4 Exemplo de Eliminação de Repetição Criando uma Dimensão de Atributo

As dimensões de atributo também fornecem recursos analíticos adicionais. Consulte Benefícios dos Atributos do Essbase.

Irrelevância Interdimensional

A irrelevância interdimensional ocorre quando muitos membros de uma dimensão são irrelevantes em outras dimensões. O Essbase define dados irrelevantes como dados que o Essbase armazena apenas no nível de resumo (dimensão). Em tal situação, você poderá remover uma dimensão do banco de dados e adicionar seus membros a outra dimensão ou dividir o modelo em bancos de dados separados.

Por exemplo, a TBC considerou analisar salários como um membro da dimensão Medidas. Mas as informações salariais muitas vezes se mostram irrelevantes no contexto de um banco de dados corporativo. A maioria dos salários é confidencial e se aplica a indivíduos. O indivíduo e o salário geralmente representam uma célula, sem motivo para fazer interseção com qualquer outra dimensão.

A TBC considerou separar os funcionários em uma dimensão separada. A tabela a seguir mostra um exemplo de como o TBC analisou a dimensão Employee proposta para obter irrelevância interdimensional. Os membros da dimensão Employee proposta (representados na linha do cabeçalho da tabela) são comparados com os membros da dimensão Measures (representados na coluna mais à esquerda). Os membros da dimensão Medidas (como Receita) se aplicam a Todos os Funcionários; somente a medida Salário é relevante para funcionários individuais.

Tabela 1-3 Exemplo de Irrelevância Interdimensional

	Joe Smith	Mary Jones	Mike Garcia	Todos os Funcionários
Revenue	Irrelevância	Irrelevância	Irrelevância	Relevância
Custos Variáveis	Irrelevância	Irrelevância	Irrelevância	Relevância
COGS	Irrelevância	Irrelevância	Irrelevância	Relevância
Publicidade	Irrelevância	Irrelevância	Irrelevância	Relevância
Salários	Relevância	Relevância	Relevância	Relevância
Custos Fixos	Irrelevância	Irrelevância	Irrelevância	Relevância
Expenses	Irrelevância	Irrelevância	Irrelevância	Relevância
Lucro	Irrelevância	Irrelevância	Irrelevância	Relevância

Motivos para Dividir Bancos de Dados

Como as informações individuais dos funcionários são irrelevantes para as outras informações no banco de dados, e também porque a adição de uma dimensão Funcionário aumentaria substancialmente as necessidades de armazenamento do banco de dados, o TBC criou um banco de dados separado de Recursos Humanos (RH). O novo banco de dados de RH contém um grupo de dimensões relacionadas e inclui salários, benefícios, seguros e planos 401(k).

Há muitas razões para dividir um banco de dados; por exemplo, suponha que uma empresa mantenha um banco de dados organizacional que contenha várias subsidiárias internacionais em vários fusos horários. Cada subsidiária depende de cálculos financeiros sensíveis ao tempo. Você pode dividir o banco de dados para grupos de subsidiárias no mesmo fuso horário para garantir que os cálculos financeiros sejam oportunos. Também é possível usar um aplicativo particionado para separar informações por subsidiária.

Lista de Verificação para Analisar o Design do Banco de Dados

Use a seguinte lista de verificação para analisar o design do banco de dados:

• Você minimizou o número de dimensões?

• Para cada combinação dimensional, você perguntou:

  • Acrescenta valor analítico?

  • Ele adiciona utilidade para relatórios?

  • Isso evita o excesso de combinações não utilizadas?

• Você evitou a repetição no contorno?

• Você evitou a irrelevância interdimensional?

• Você dividiu os bancos de dados conforme necessário?