Análisis y planificación de la aplicación de Essbase

Para asegurarse de que la aplicación de Essbase analice la información de su negocio de forma eficaz, formule un plan detallado que describa los orígenes de datos, las necesidades del usuario y los posibles elementos de la base de datos. La atención a esta fase de diseño puede ahorrarle tiempo de desarrollo e implantación.

La fase de planificación y análisis implica las siguientes tareas:

• Analizar datos de origen

• Identificar requisitos de usuario

• Plan de Seguridad en un Entorno de Varios Usuarios

• Crear modelos de base de datos

Al diseñar una aplicación multidimensional, tenga en cuenta los siguientes factores:

• Cómo fluye la información dentro de la empresa, quién utiliza qué datos para qué fines

• Los tipos de informes que realiza la compañía: qué tipos de datos se deben incluir en el esquema para satisfacer las necesidades de informes de los usuarios

  Note:

  La definición de una sola base de datos por aplicación mejora el uso de la memoria y facilita la administración de la base de datos.

Analizar datos de origen

Evalúe los datos que se van a incluir en la base de datos de Essbase. Considere de dónde viene y la frecuencia y el tamaño necesarios de las actualizaciones. Debe cargar en Essbase solo lo necesario para la generación de informes dinámicos y la obtención de detalles. El resto puede permanecer en un origen relacional, al que se puede acceder mediante partición o obtención de detalles.

Determinar el alcance de la base a datos. Si una organización tiene numerosas familias de productos que contienen un gran número de productos, puede que desee almacenar valores de datos solo para familias de productos. Entrevistar a los miembros de cada departamento de usuarios para averiguar qué datos procesan, cómo calculan e informan datos hoy y cómo quieren hacerlo en el futuro.

Definir cuidadosamente las necesidades de informes y análisis.

• ¿Cómo desean los usuarios ver y analizar los datos?

• ¿Cuántos detalles debe contener la base de datos?

• ¿Los datos admiten los objetivos de análisis e informes deseados?

• Si no es así, ¿qué datos adicionales necesita y dónde puede encontrarlos?

Determine la ubicación de los datos actuales.

• ¿Dónde almacena actualmente cada departamento los datos?

• ¿Los datos están en un formulario que Essbase puede utilizar?

• ¿Los departamentos almacenan datos en bases de datos relacionales en servidores Windows o UNIX, o en hojas de cálculo de Excel?

• ¿Quién actualiza la base de datos y con qué frecuencia?

• ¿Tienen acceso a ella quienes necesitan actualizar los datos?

Asegúrese de que los datos estén listos para cargarse en Essbase.

• ¿Los datos provienen de un único origen o de varios orígenes?

• ¿Los datos tienen un formato que Essbase puede utilizar? Para obtener una lista de orígenes de datos válidos que puede cargar en Essbase, consulte Orígenes de datos.

• ¿Todos los datos que desea utilizar están disponibles?

Identificar requisitos de usuario

A medida que planifique la base de datos de Essbase, analice las necesidades de información con los usuarios actuales de los datos y solicite informes de muestra de ellos. Revise la información que utilizan y los informes que deben generar para que otros la revisen.

Determine los siguientes requisitos:

• ¿Qué tipos de análisis necesitan los usuarios?

• ¿Los usuarios necesitan informes ad hoc (estilo dinámico) e informes estructurados?

• ¿Qué niveles de resumen y detalle de información necesitan los usuarios?

• ¿Algunos usuarios necesitan acceso a información que otros usuarios no deben ver?

Plan de Seguridad en un Entorno de Varios Usuarios

Identifique diferentes niveles de necesidades de información de usuario como parte de la planificación de cómo configurar permisos de seguridad de Essbase. Al final del análisis, debe tener una lista de usuarios y los permisos necesarios.

Utilice esta lista de control para planificar la seguridad:

• ¿Quiénes son los usuarios y qué permisos deben tener para leer o escribir datos en la base de datos?

• ¿Quién debería tener permisos de carga de datos?

• ¿Quién debe tener permiso para ejecutar cálculos?

• ¿Qué usuarios se pueden agrupar y asignar permisos similares?

Consulte también Gestión de usuarios y roles.

Crear modelos de base de datos

Cree un modelo de la base de datos de Essbase. Para crear el modelo, deberá identificar las perspectivas y puntos de vista que son importantes para su negocio. Estas vistas se traducen en las dimensiones del modelo de base de datos.

Muchas empresas analizan las siguientes vistas:

• Períodos

• Medidas

• Casos

• Products

• Customers

• Regiones geográficas

• Unidades de negocio

A continuación, para ayudarle a recopilar información y tomar decisiones, deberá identificar los objetivos de análisis de datos, determinar las dimensiones y los miembros de la base de datos y analizar el diseño de la base de datos.

Identificar objetivos de análisis

Después de identificar las principales vistas de información de un negocio, el siguiente paso para diseñar una base de datos de Essbase es decidir cómo activa la base de datos el análisis de datos. Por ejemplo, puede que necesite ver los datos por período de tiempo, por geografía o por tipo de producto.

• Si se analiza por tiempo, ¿qué períodos de tiempo se necesitan? ¿Debería el análisis incluir solo el año actual o varios años? ¿Debería el análisis incluir datos trimestrales y mensuales? ¿Debería incluir datos por temporada?

• Si se analiza por región geográfica, ¿cómo se definen las regiones? ¿Define regiones por territorios de ventas? ¿Define regiones por límites geográficos, como estados y ciudades?

• Si analiza por línea de productos, ¿debe revisar los datos de cada producto? ¿Puede resumir los datos en clases de productos?

Independientemente de las vistas de negocio, debe determinar la perspectiva y los detalles necesarios en el análisis. Cada área de negocio que se analiza proporciona una vista diferente de los datos.

Determinar dimensiones y miembros

Las dimensiones de Essbase que elija determinan qué tipos de análisis puede realizar. Dentro de cada dimensión, las jerarquías de miembros representan aspectos del negocio. Por ejemplo, una jerarquía de tiempo puede incluir trimestres y meses. Una jerarquía de productos clasifica los productos. Una jerarquía regional se basa en los mercados geográficos.

Puede representar cada vista de negocio como una dimensión estándar independiente en la base de datos. Es posible que escuche a los analistas de negocios referirse a los "bys" de su negocio, como por producto, por geografía y por período de tiempo. Si necesita analizar una vista de negocio por clasificación o atributo, por ejemplo, por tamaño o color de productos, puede utilizar dimensiones o propiedades de atributo para representar las vistas de clasificación.

Puede utilizar tantas dimensiones como necesite para el análisis. Cuando sepa aproximadamente qué dimensiones y miembros necesita, desarrolle un diseño de base de datos provisional.

Después de determinar las dimensiones del modelo de base de datos, seleccione los elementos o elementos de cada dimensión. Estos elementos se convierten en las jerarquías y miembros de sus respectivas dimensiones. Por ejemplo, una jerarquía de tiempo puede incluir los periodos de tiempo que desea analizar, como trimestres y dentro de trimestres, meses. Cada trimestre y mes se convierte en un miembro de la dimensión que crea para el tiempo. Los trimestres y meses representan una jerarquía de dos niveles de miembros y sus hijos. Los meses de un trimestre se pueden consolidar a un total para cada trimestre.

Relaciones entre dimensiones

Considere las relaciones entre las dimensiones. La estructura de una base de datos de Essbase facilita a los usuarios el análisis de la información desde muchas perspectivas. Un analista financiero, por ejemplo, puede hacer las siguientes preguntas:

• ¿Cuáles son los resultados de ventas de un mes concreto? ¿Cómo se compara esta cifra con las ventas en el mismo mes en los últimos cinco años?

• ¿En qué porcentaje aumenta el margen de beneficio?

• ¿Qué tan cerca están los valores reales de los valores presupuestados?

En otras palabras, puede que el analista desee examinar la información de tres dimensiones: tiempo, cuenta y escenario. La base de datos de ejemplo que se muestra a continuación representa estas tres dimensiones, con una dimensión representada a lo largo de cada uno de los tres ejes:

• Una dimensión de tiempo, que comprende Jan, Feb, Mar y el total para Qtr1, se muestra a lo largo del eje X.

• Una dimensión de cuentas, que consta de cifras contables como Ventas, COGS, Margen y Margen %, se muestra en el eje Y.

• Otra dimensión, que proporciona un punto de vista diferente, como Presupuesto para valores de presupuesto y Real para valores reales, se muestra en el eje Z.

Figura 1-1 Cubo que Representa Tres Dimensiones de Base de Datos

Las celdas del cubo, donde los miembros se cruzan, contienen los datos relevantes para los tres miembros que se cruzan; por ejemplo, las ventas reales en enero.

Ejemplo de estructura de miembro y dimensión

En la siguiente tabla se muestra un resumen de las dimensiones TBC. El diseñador de aplicaciones ha creado tres columnas, con las dimensiones de la columna izquierda y los miembros de las dos columnas de la derecha. Los miembros de la columna 3 son subcategorías de los miembros de la columna 2. En algunos casos, los miembros de la columna 3 se dividen en otro nivel de subcategorías; por ejemplo, la dimensión Margen de las medidas se divide en Ventas y COGS.

Tabla 1-1 Dimensiones de muestra de TBC

Dimensiones	Miembros	Miembros secundarios
Year	Trim1	Ene, Feb, Mar
Year	Trim 2	abr, may, jun
Year	Trim 3	Jul, ago, sep
Year	Trim 4	Oct, Nov, Dic
Medidas	Beneficio	Margen: Ventas, CPV Gastos totales: marketing, nómina, varios
Medidas	Inventario	Apertura de Inventario, Altas, Inventario Final
Medidas	Ratios	Porcentaje de margen % de beneficio % de beneficio por onza
Product	Colas (100)	Cola (100‑10), Diet Cola (100‑20), Cola sin cafeína (100‑30)
Product	Cerveza Raíz (200)	Old Fashioned (200-10), Diet Root Beer (200-20), Sarsaparilla (200-30), Birch Beer (200-40)
Product	Soda Crema (300)	Crema Oscura (300‑10), Crema de Vainilla (300‑20), Diet Cream Soda (300‑30)
Product	Soda de frutas (400)	Uva (400‑10), Naranja (400‑20), Fresa (400‑30)
Market	Este	Connecticut, Florida, Massachusetts, Nuevo Hampshire, Nueva York
Market	Región del Oeste	California, Nevada, Oregón, Utah, Washington
Market	Sur	Louisiana, Nuevo México, Oklahoma, Texas
Market	Central	Colorado, Illinois, Iowa, Missouri, Ohio, Wisconsin
Escenario	Real	No disponible
Escenario	Presupuesto	No disponible
Escenario	Varianza	No disponible
Escenario	% de Varianza	No disponible

Además, el diseñador de aplicaciones ha agregado las siguientes dimensiones de atributo para permitir el análisis de productos en función del tamaño y el empaquetado:

Tabla 1-2 Dimensiones de atributo de muestra de TBC

Dimensiones	Miembros	Miembros secundarios
Onzas	Grande Pequeño	64, 32, 20 16, 12
Tipo de empaquetado	Botella Puede	No disponible

Lista de comprobación para determinar dimensiones y miembros

Utilice la siguiente lista de comprobación al determinar las dimensiones y los miembros de la base de datos del modelo:

• ¿Cuáles son los candidatos para las dimensiones?

• ¿Alguna de las dimensiones clasifica o describe otras dimensiones? Estas dimensiones son candidatas para las dimensiones de atributo.

• ¿Los usuarios desean cualificar su vista de una dimensión? Las categorías por las que califican una dimensión son candidatas para dimensiones de atributo.

• ¿Cuáles son los candidatos para los miembros?

• ¿Cuántos niveles necesitan los datos?

• ¿Cómo se consolidan los datos?

Analizar diseño de base de datos

Revise el diseño dimensional inicial de Essbase según estas directrices en torno al número de dimensiones, su valor analítico combinado y la evitación de la repetición. La realización de este análisis inicial le ayudará a lograr un diseño de base de datos eficiente que cumpla con sus objetivos de consolidación y cálculo de datos.

El número de miembros necesarios para describir un punto de datos potencial debe determinar el número de dimensiones. Si no está seguro de si debe suprimir una dimensión, consérvela y aplique más reglas de análisis hasta que se sienta seguro de suprimirla o mantenerla.

Dimensiones densas y ligeros

Las dimensiones que son dispersas y las que son densas afectan al rendimiento. Consulte:

• Dimensiones ligeras y densas

• Diseñar un esquema para optimizar el rendimiento

Dimensiones de atributo y estándar

Por simplicidad, los ejemplos de este tema muestran arreglos alternativos para lo que inicialmente se diseñó como dos dimensiones. Puede aplicar la misma lógica a todas las combinaciones de dimensiones.

Considere el diseño de una empresa que vende productos a varios clientes en varios mercados; los mercados son únicos 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 es sólo en Nueva York, Cust B es sólo en Illinois, y Cust C es sólo en California. La compañía puede definir los datos en una dimensión estándar:

Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C

Sin embargo, si observa un muestreo más grande de datos, puede ver que muchos clientes pueden estar en cada mercado. El cliente A y el cliente E están en Nueva York; el cliente B, el cliente M y el cliente P están en Illinois; el cliente C y el cliente F están en California. En esta situación, la compañía normalmente define la dimensión grande, Cliente, como una dimensión estándar y la dimensión más pequeña, Mercado, como una dimensión de atributo. La compañía asocia los miembros de la dimensión Mercado como atributos de los miembros de la dimensión Cliente. Los miembros de la dimensión Mercado describen las ubicaciones de los clientes: cada cliente tiene exactamente un 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 otra situación. Una vez más, la empresa vende productos a múltiples clientes en múltiples mercados, pero la empresa puede vender a un cliente que tiene ubicaciones en 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 se encuentra en Nueva York y California. Cust B se encuentra en Nueva York e Illinois. Cust C sólo está en California. El uso de una dimensión de atributo no funciona en esta situación; un miembro de cliente no puede tener varios miembros de atributo. Por lo tanto, la empresa diseña los datos en dos dimensiones estándar:

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

Combinaciones de dimensiones

Divida cada combinación de dos dimensiones en una matriz bidimensional. Por ejemplo, las dimensiones propuestas en TBC incluyen las siguientes combinaciones:

• Año tras medidas

• Año según producto

• Año en el mercado

• Año tras escenario

• Medidas en producto

• Medidas en el mercado

• Medidas en el escenario

• Mercado según producto

• Mercado según escenario

• Escenario en producto

• Onzas en tipo de paquete

Las onzas y el tipo de paquete, como dimensiones de atributo asociadas a la dimensión Product, se pueden considerar con la dimensión Product.

Para ayudar a visualizar cada dimensión, dibuje una matriz e incluya algunos de los miembros de primera generación. La siguiente imagen muestra un conjunto simplificado de matrices para tres dimensiones.

Figura 1-2 Análisis de Relaciones Dimensionales

Para cada combinación de dimensiones, haga tres preguntas:

• ¿Añade valor analítico?

• ¿Añade utilidad para la generación de informes?

• ¿Evita un exceso de combinaciones no utilizadas?

Para cada combinación, las respuestas a las preguntas ayudan a determinar si la combinación es válida para la base de datos. Lo ideal es que la respuesta a cada pregunta sea sí. De lo contrario, considere la posibilidad de reorganizar los datos en dimensiones más significativas. A medida que trabaje en este proceso, analice las necesidades de información con los usuarios.

Repetición en esquemas

La repetición de elementos en un esquema a menudo indica la necesidad de dividir dimensiones. Los siguientes ejemplos muestran cómo evitar la repetición.

En este ejemplo, la columna de la izquierda, con la etiqueta "Repetición", muestra Profit, Margin, Sales, COGS y Expenses repetidos en la dimensión Budget y Actual en la dimensión Accounts. La columna derecha, con la etiqueta "Sin repetición", separa Budget y Actual en otra dimensión (Scenario), dejando solo un juego de miembros Profit, Margin, Sales, COGS y Expenses en la dimensión Accounts. Este enfoque simplifica el esquema y proporciona una visión más sencilla del presupuesto y las cifras reales de las otras dimensiones de la base de datos.

Figura 1-3 Ejemplo de Eliminación de la Repetición Creando una Dimensión de Escenario

En este ejemplo, la columna de la izquierda, etiquetada como "Repetición", utiliza miembros compartidos en la dimensión Dieta para analizar las bebidas dietéticas. Los miembros 100-20, 200-20 y 300-20 se repiten: una vez bajo la Dieta, y una vez bajo sus respectivos padres. La columna derecha, con la etiqueta "Sin repetición", simplifica el esquema mediante la creación de una dimensión de atributo Diet de tipo booleano (verdadero o falso). Todos los miembros se muestran solo una vez, bajo sus respectivos padres, y se etiquetan con el atributo apropiado ("Dieta: Verdadero" o "Dieta: Falso").

Figura 1-4 Ejemplo de Eliminación de la Repetición Creando una Dimensión de Atributo

Las dimensiones de atributos también proporcionan capacidades analíticas adicionales. Consulte Ventajas de los atributos de Essbase.

Irrelevancia interdimensional

La irrelevancia interdimensional se produce cuando muchos miembros de una dimensión son irrelevantes en otras dimensiones. Essbase define los datos irrelevantes como datos que Essbase almacena solo en el nivel de resumen (dimensión). En tal caso, puede eliminar una dimensión de la base de datos y agregar sus miembros a otra dimensión o dividir el modelo en bases de datos independientes.

Por ejemplo, TBC consideró analizar los salarios como un miembro de la dimensión Measures. Sin embargo, la información salarial suele resultar irrelevante en el contexto de una base de datos corporativa. La mayoría de los salarios son confidenciales y se aplican a las personas. El individuo y el salario suelen representar una celda, sin motivo para cruzarse con ninguna otra dimensión.

TBC consideró separar a los empleados en una dimensión separada. En la siguiente tabla se muestra un ejemplo de cómo TBC analizó la dimensión Employee propuesta para la irrelevancia interdimensional. Los miembros de la dimensión Employee propuesta (representada en la fila de cabecera de la tabla) se comparan con los miembros de la dimensión Measures (representada en la columna situada más a la izquierda). Los miembros de la dimensión Medidas (como Ingresos) se aplican a Todos los empleados; solo la medida Salario es relevante para empleados individuales.

Tabla 1-3 Ejemplo de irrelevancia interdimensional

	Joe Smith	Mary Jones	Mike Garcia	Todos los empleados
Revenue	Irrelevancia	Irrelevancia	Irrelevancia	Relevancia
Costos variables	Irrelevancia	Irrelevancia	Irrelevancia	Relevancia
COGS	Irrelevancia	Irrelevancia	Irrelevancia	Relevancia
Anunciando	Irrelevancia	Irrelevancia	Irrelevancia	Relevancia
Salarios	Relevancia	Relevancia	Relevancia	Relevancia
Costos fijos	Irrelevancia	Irrelevancia	Irrelevancia	Relevancia
Expenses	Irrelevancia	Irrelevancia	Irrelevancia	Relevancia
Beneficio	Irrelevancia	Irrelevancia	Irrelevancia	Relevancia

Motivos para dividir bases de datos

Puesto que la información de cada empleado no es relevante para el resto de la información de la base de datos, y también porque la adición de una dimensión Employee aumentaría sustancialmente las necesidades de almacenamiento de la base de datos, TBC creó una base de datos de Recursos Humanos (RRR. HH.) independiente. La nueva base de datos de RR. HH. contiene un grupo de dimensiones relacionadas e incluye salarios, beneficios, seguros y planes 401(k).

Hay muchas razones para dividir una base de datos; por ejemplo, supongamos que una empresa mantiene una base de datos organizativa que contiene varias subsidiarias internacionales en varias zonas horarias. Cada subsidiaria se basa en cálculos financieros sensibles al tiempo. Puede dividir la base de datos para grupos de subsidiarias en la misma zona horaria para garantizar que los cálculos financieros sean oportunos. También puede usar una aplicación particionada para separar la información por subsidiaria.

Lista de Control para Analizar el Diseño de la Base de Datos

Utilice la siguiente lista de control para analizar el diseño de la base de datos:

• ¿Ha minimizado el número de dimensiones?

• Para cada combinación dimensional, ¿preguntó:

  • ¿Añade valor analítico?

  • ¿Añade utilidad para la generación de informes?

  • ¿Evita un exceso de combinaciones no utilizadas?

• ¿Ha evitado la repetición en el esquema?

• ¿Evitaste la irrelevancia interdimensional?

• ¿Dividió las bases de datos según fuera necesario?