Planeación del data mart para soluciones y escenarios de planeación de BI

Artículo
03/03/2017

Se aplica a: SharePoint Server 2010 Enterprise

Última modificación del tema: 2016-11-30

En este artículo:

Esquema y diseño
Modelos para la solución
Creación de tablas de dimensiones
Creación de tablas de jerarquía
Creación de tablas de hechos

Esquema y diseño

Se creará el data mart mediante el uso del servidor relacional de SQL Server 2008 R2 para que actúe como el único punto de registro para los trabajadores de la información, con un estricto control de todos los datos que entran en el data mart. El servidor SSAS usará el data mart como origen de datos central para todos los cubos, dimensiones y jerarquías. Se necesitarán tres tipos de tablas para admitir el modelo de datos SSAS e incluir dimensiones, jerarquías y hechos.

Nota

Es posible que un cubo use más de una tabla de hechos. Esto puede lograrse mediante la creación de particiones en el grupo de medida y también mediante el uso de más de un grupo de medida dentro del cubo.

Crearemos los siguientes modelos para admitir los modelos de datos necesarios para el proceso de planeación. Estos modelos determinarán el número de tablas que existirán en nuestro data mart.

Modelos para la solución

Previsión: este modelo se usará principalmente para capturar la entrada de datos para las previsiones de ingresos y gastos operacionales para los períodos futuros.
Cuenta: la dimensión de cuenta contendrá el plan contable, que muestra los elementos para la previsión de ingresos y gastos
Escenario: la dimensión de escenario creará una partición y dividirá los datos en "Reales" y "Previsión"
Tiempo: la dimensión de tiempo determinará los períodos fiscales para la previsión.
Geografía: la dimensión de geografía se usará para controlar el proceso de entrada de datos por cada trabajador de la información. Los trabajadores de la información de cada zona geográfica realizarán la entrada de datos en su moneda local.
Producto: la dimensión de producto se usa para representar la lista completa de los productos activos y disponibles. La previsión de los ingresos se realizará por producto.
Presupuesto de Recursos Humanos: los administradores de línea usarán este modelo para presupuestar la plantilla prevista para el año fiscal. Los trabajadores de la información interactuarán con este modelo especificando las horas trabajadas estimadas y la clasificación de nivel de remuneración de cada recurso. Se ejecutará un análisis de hipótesis para determinar qué presupuesto se requerirá para la nómina según los cambios en las hipótesis.
Métrica: esta dimensión almacenará miembros como, por ejemplo, "Horas trabajadas", "Nivel de remuneración", "Remuneración total", etc.
Geografía: la ubicación que recibirá el recurso.
Tiempo: el presupuesto de plantilla se realiza en el nivel de año.
Empleado: una lista de los recursos existentes y nuevos marcadores de posición TBH.
Tasas de pago: este modelo se usa para establecer las tasas de pago de base para el año. La información de las tasas de pago se especifica en el modelo presupuestario de Recursos Humanos como datos de hipótesis de base para su uso en los cálculos.
Tiempo: las tasas de pago se especifican en el nivel de año.
Nivel de remuneración: una lista de los niveles de remuneración que determinarán el salario básico.
Tipos de cambio: el modelo de tipo de cambio se usa para determinar los tipos de conversión de divisas para usar por mes cuando se convierten los datos del modelo de previsión en el modelo de consolidación financiera. Dado que los datos de cada zona geográfica se especifican en su moneda local, la tabla de tipos de cambio se usará para las reglas de conversión de divisas y los paquetes de flujos de datos.
Tiempo: los tipos de cambio se especifican por mes.
Moneda de origen: la moneda de origen de una conversión.
Moneda de destino: la moneda de destino de una conversión.
Consolidación financiera: el modelo de consolidación financiera se usa para el informe financiero con una misma moneda para todas las regiones geográficas.
Cuenta: plan de cuentas consolidado.
Escenario: contendrá "Reales" y "Previsión"
Tiempo: el nivel de granularidad inferior será meses
Geografía: todas las regiones geográficas que tienen pérdidas y ganancias
Tipo de moneda: permite ver los datos en la divisa de notificación (EUR) o en la moneda local, según la región geográfica actualmente seleccionada en el filtro.

Con una buena comprensión de los modelos necesarios, podemos configurar el almacén de datos. Aquí tendremos cinco tablas de hechos y las tablas de dimensiones y jerarquía adecuadas. Estas tablas se organizarán según un esquema de estrella, con las tablas de hechos en el centro y las tablas de dimensiones y jerarquía en las puntas del esquema de estrella. Al definir relaciones mediante claves externas entre las tablas de hechos, dimensiones y jerarquía en el almacén de datos, podemos generar rápidamente la vista de origen de datos en SSAS cuando llega el momento de crear nuestros cubos y dimensiones.

Creación de tablas de dimensiones

Las dimensiones son los bloques de creación de cualquier base de datos multidimensional. Al agrupar un conjunto de dimensiones se conformará la base general del cubo. Las tablas de dimensiones almacenan juntos los datos de un tipo determinado. Por ejemplo, hay una tabla de dimensiones que almacena todos los miembros de la cuenta y donde cada fila de la tabla representa un miembro de cuenta único de la dimensión. Las tablas de dimensiones también pueden almacenar las propiedades relacionadas entre sí a través de las columnas de tabla. Por ejemplo, en la dimensión Cuenta, contamos con una columna denominada "AccountType" que almacena el tipo de cuenta específico del miembro de dimensión.

MemberId	MemberLabel	MemberName	SortOrder	AccountType	ExpenseType
1	3100	Ingresos de ventas	100	Ingresos	No aplicable
2	3200	Otros ingresos de explotación	200	Ingresos	No aplicable
3	8100	Ingresos de intereses	300	Ingresos	No aplicable

MemberId	MemberLabel	MemberName	SortOrder	Input Currency	Target Currency
1	SEA	Seattle	100	USD	USD
2	OLY	Olympia	200	USD	USD
3	SPK	Spokane	300	USD	USD

Recomendación

Recomendamos crear los siguientes campos para una tabla de dimensiones:

Id.: recomendamos que las claves de dimensión sean de tipo entero (TinyInt, SmallInt, Int, BigInt) y no de otro tipo para obtener un rendimiento óptimo. Consulte la sección sobre rendimiento para leer más información. Además, use el tipo de datos más apropiado según el tamaño de la dimensión.

Etiqueta: use un código único para visualizar el título o nombre de un miembro de dimensión. Si usa un código único, podrá crear reglas basadas en el cubo usando MdxScript, que es legible para humanos, en lugar de la especificación por miembros usando notación de valor clave, como "&[clave]".

Nombre: con demasiada frecuencia, los usuarios finales desean ver miembros de una dimensión con un nombre descriptivo en lugar de la etiqueta de código. Por ejemplo, en nuestra solución tenemos códigos de cuenta que se usan en la etiqueta y que tienen sentido al crear las reglas de cálculo pero no cuando se muestran en una tabla dinámica. La creación de esta propiedad garantiza que se puedan actualizar fácilmente los nombres para mostrar sin afectar a ninguna lógica subyacente a las definiciones de regla.

Orden: es aconsejable tener una columna de ordenación que la dimensión pueda usar para determinar el orden de los miembros de dimensión.

Normalmente, las tablas de dimensiones para planear escenarios no exceden los 200.000 miembros. Si las dimensiones con las que está trabajando se han vuelto muy grandes, se recomienda recortar la dimensión. Cualquier dato asociado a los miembros de dimensión que se recorte puede agregarse y suministrarse a otros miembros de dimensión. Como norma, cuanto más pequeñas sean las dimensiones, mejor será el rendimiento de los cubos de planeación en general.

Nota

Las columnas de dimensión y las propiedades de miembro están estrechamente relacionadas.

Creación de tablas de jerarquía

Las tablas de jerarquía son necesarias cuando se usa la característica de jerarquía de elementos primarios y secundarios en SSAS. La jerarquía de elementos primarios y secundarios debe usar tres columnas: key (que representa un miembro de la dimensión de jerarquía), parent key (otro miembro de la misma dimensión) y la columna sort para ordenar los miembros en un nivel de la jerarquía. La mayoría de las jerarquías de elementos primarios y secundarios son compatibles con estas tres columnas, excepto cuando requiere la agregación de miembros personalizada. Por ejemplo, un plan de cuentas necesitará agregación personalizada para definirse. Las agregaciones de cuenta están determinadas por el tipo de cuenta del miembro de cada cuenta y sus miembros de la cuenta primaria respectiva. Para admitir las jerarquías que requieren agregación personalizada, debemos crear una cuarta columna. Esta columna, la columna Unary Operator, contendrá los siguientes valores: +, - y ~ , donde + significa sumar al elemento primario, - restar del objeto primario y ~ omitir agregación al elemento primario.

Id	Parent Id	Sort Order	Unary Operator	Label	Name
1	102	100	+	3100	Ingresos de ventas
2	102	200	+	3200	Otros ingresos de explotación
3	103	300	+	8100	Ingresos de intereses
4	103	400	+	9100	Ganancia en venta de activos

Id	Parent Id	Sort Order	Label	Name
1	4	500	SEA	Seattle
2	4	700	OLY	Olympia
3	4	600	SPK	Spokane

Las jerarquías basadas en niveles se crean basándose en las columnas definidas en una dimensión. Las columnas de una tabla relacional pueden crear jerarquías de atributos en SSAS. La definición de relaciones entre jerarquías de atributos permiten crear jerarquías basadas en niveles eficientes. Por el momento, será suficiente incluir todas las propiedades relacionadas de una dimensión como columnas en la tabla de dimensiones cuando llegue el momento de nivelar las jerarquías basadas en SSAS.

Para obtener más información, vea el tema sobre jerarquías y niveles.

Creación de tablas de hechos

Las tablas de hechos almacenan todos los datos numéricos de un cubo. El número de columnas en una tabla de hechos variará según la cantidad de dimensiones asociadas al cubo. Por ejemplo, el cubo de la previsión tiene 7 columnas, donde 6 columnas representan cada dimensión que se relaciona con el cubo de previsión y una es para almacenar el valor numérico. La columna que almacena el valor numérico se denomina "measure". En nuestra solución, se usa solo una medida para la tabla de hechos.

Cada columna distinta de la columna "measure" está relacionada con una dimensión a través de su clave. En el siguiente ejemplo, vemos que el modelo de presupuesto de Recursos Humanos tiene cinco dimensiones relacionadas con la tabla de hechos, y cada fila de la tabla de hechos representa un solo registro de hecho. Es recomendable evitar los valores duplicados en los registros de hechos de las claves de dimensión, por ejemplo, si tenemos el mismo valor en todas las claves de dimensión en varias filas de hechos. En estos casos, combine el valor en una sola fila.

Rowld	Metric ID	Geography ID	EmployeeID	TimeID	Value
1	2	15	1010	20100000	2000
2	2	15	1009	20100000	2000
3	2	15	1008	20100000	2000

Rowld	Account ID	TimeID	ScenarioID	Geography ID	ProductID	VersionID	Value
1151	1	20100200	1	1	232	1	1391
1153	1	20100400	2	1	232	1	1124
1155	1	20100600	2	1	232	1	1322

Share via