Particiones (Servicios de Análisis - Datos Multidimensionales)

Una partición es un contenedor para una parte de los datos del grupo de medida. Las particiones no se ven a partir de consultas MDX; todas las consultas reflejan todo el contenido del grupo de medida, independientemente de cuántas particiones se definan para el grupo de medida. El contenido de datos de una partición se define mediante los enlaces de consulta de la partición y mediante la expresión de segmentación.

Un objeto simple Partition se compone de: información básica, definición de segmentación, diseño de agregaciones y otros. La información básica incluye el nombre de la partición, el modo de almacenamiento, el modo de procesamiento y otros. La definición de segmentación es una expresión MDX que especifica una tupla o un conjunto. La definición de segmentación tiene las mismas restricciones que la función MDX StrToSet. Junto con el parámetro CONSTRAINED, la definición de segmentación puede usar nombres de dimensión, jerarquía, nivel y miembro, claves, nombres únicos u otros objetos con nombre en el cubo, pero no puede usar funciones MDX. El diseño de agregaciones es una colección de definiciones de agregación que se pueden compartir entre varias particiones. El valor predeterminado se toma del diseño de agregación del cubo primario.

Microsoft SQL Server Analysis Services usa particiones para administrar y almacenar datos y agregaciones para un grupo de medida en un cubo. Cada grupo de medida tiene al menos una partición; esta partición se crea cuando se define el grupo de medida. Al crear una nueva partición para un grupo de medida, la nueva partición se agrega al conjunto de particiones que ya existen para el grupo de medida. El grupo de medida refleja los datos combinados contenidos en todas sus particiones. Esto significa que debe asegurarse de que los datos de una partición de un grupo de medida son exclusivos de los datos de cualquier otra partición del grupo de medida para asegurarse de que los datos no se reflejan en el grupo de medida más de una vez. La partición original de un grupo de medida se basa en una sola tabla de hechos en la vista del origen de datos del cubo. Cuando hay varias particiones para un grupo de medida, cada partición puede hacer referencia a una tabla diferente en la vista del origen de datos o en el origen de datos relacional subyacente para el cubo. Más de una partición de un grupo de medida puede hacer referencia a la misma tabla, si cada partición está restringida a filas diferentes de la tabla.

Las particiones son un medio eficaz y flexible de administrar cubos, especialmente cubos grandes. Por ejemplo, un cubo que contiene información de ventas puede contener una partición para los datos de cada año pasado y también particiones para cada trimestre del año actual. Solo es necesario procesar la partición del trimestre actual cuando se agrega información actual al cubo; el procesamiento de una cantidad menor de datos mejorará el rendimiento del procesamiento al reducir el tiempo de procesamiento. Al final del año, las cuatro particiones trimestrales se pueden combinar en una sola partición para el año y una nueva partición creada para el primer trimestre del año nuevo. Además, este nuevo proceso de creación de particiones se puede automatizar como parte de los procedimientos de carga y procesamiento de cubos del almacenamiento de datos.

Las particiones no son visibles para los usuarios empresariales del cubo. Sin embargo, los administradores pueden configurar, agregar o quitar particiones. Cada partición se almacena en un conjunto independiente de archivos. Los datos agregados de cada partición se pueden almacenar en la instancia de Analysis Services donde se define la partición, en otra instancia de Analysis Services o en el origen de datos que se usa para proporcionar los datos de origen de la partición. Las particiones permiten que los datos de origen y los datos agregados de un cubo se distribuyan entre varias unidades de disco duro y entre varios equipos servidor. Para un cubo de tamaño moderado a grande, las particiones pueden mejorar considerablemente el rendimiento de las consultas, el rendimiento de la carga y la facilidad de mantenimiento de cubos. Para obtener más información sobre las particiones remotas, consulte Particiones remotas.

El modo de almacenamiento de cada partición se puede configurar independientemente de otras particiones del grupo de medida. Las particiones se pueden almacenar mediante cualquier combinación de opciones para la ubicación de datos de origen, el modo de almacenamiento, el almacenamiento en caché proactivo y el diseño de agregaciones. Las opciones de OLAP en tiempo real y el almacenamiento en caché proactivo permiten equilibrar la velocidad de las consultas frente a la latencia al diseñar una partición. Las opciones de almacenamiento también se pueden aplicar a dimensiones relacionadas y a hechos de un grupo de medida. Esta flexibilidad le permite diseñar estrategias de almacenamiento de cubos adecuadas a sus necesidades. Para obtener más información, vea Partition Storage Modes and Processing, Aggregations and Aggregation Designs and Aggregation Designs and Proactive Caching (Partitions) (Modos de almacenamiento de particiones y procesamiento de particiones de particiones), agregaciones y diseños de agregaciones y almacenamiento en caché proactivo (particiones).

Estructura de particiones

La estructura de una partición debe coincidir con la estructura de su grupo de medida, lo que significa que las medidas que definen el grupo de medida también deben definirse en la partición, junto con todas las dimensiones relacionadas. Por lo tanto, cuando se crea una partición, hereda automáticamente el mismo conjunto de medidas y dimensiones relacionadas que se definieron para el grupo de medida.

Sin embargo, cada partición de un grupo de medida puede tener una tabla de hechos diferente y estas tablas de hechos pueden ser de orígenes de datos diferentes. Cuando las distintas particiones de un grupo de medida tienen tablas de hechos diferentes, las tablas deben ser lo suficientemente similares para mantener la estructura del grupo de medida, lo que significa que la consulta de procesamiento devuelve las mismas columnas y los mismos tipos de datos para todas las tablas de hechos para todas las particiones.

Cuando las tablas de hechos para distintas particiones proceden de orígenes de datos diferentes, las tablas de origen para cualquier dimensión relacionada y también las tablas de hechos intermedias también deben estar presentes en todos los orígenes de datos y deben tener la misma estructura en todas las bases de datos. Además, todas las columnas de tabla de dimensiones que se usan para definir atributos para dimensiones de cubo relacionadas con el grupo de medida deben estar presentes en todos los orígenes de datos. No es necesario definir todas las combinaciones entre la tabla de origen de una partición y una tabla de dimensiones relacionada si la tabla de origen de la partición tiene la estructura idéntica como la tabla de origen para el grupo de medida.

Las columnas que no se usan para definir medidas en el grupo de medida pueden estar presentes en algunas tablas de hechos, pero que no están presentes en otras. De forma similar, las columnas que no se usan para definir atributos en tablas de dimensiones relacionadas pueden estar presentes en algunas bases de datos, pero no en otras. Las tablas que no se usan para las tablas de hechos o las tablas de dimensiones relacionadas pueden estar presentes en algunas bases de datos, pero que no están presentes en otras.

Orígenes de datos y almacenamiento de particiones

Una partición se basa en una tabla o vista en un origen de datos, o en una tabla o consulta con nombre en una vista del origen de datos. La ubicación donde se almacenan los datos de partición se define mediante el enlace del origen de datos. Normalmente, puede crear particiones de un grupo de medida horizontal o verticalmente:

• En un grupo de medida con particiones horizontales, cada partición de un grupo de medida se basa en una tabla independiente. Este tipo de creación de particiones es adecuado cuando los datos se separan en varias tablas. Por ejemplo, algunas bases de datos relacionales tienen una tabla independiente para los datos de cada mes.

• En un grupo de medida con particiones verticales, un grupo de medida se basa en una sola tabla y cada partición se basa en una consulta del sistema de origen que filtra los datos de la partición. Por ejemplo, si una sola tabla contiene varios datos de meses, el grupo de medida podría seguir particionando por mes aplicando una cláusula WHERE de Transact-SQL que devuelve los datos de un mes independiente para cada partición.

Cada partición tiene la configuración de almacenamiento que determina si los datos y agregaciones de la partición se almacenan en la instancia local de Analysis Services o en una partición remota mediante otra instancia de Analysis Services. La configuración de almacenamiento también puede especificar el modo de almacenamiento y si el almacenamiento en caché proactivo se usa para controlar la latencia de una partición. Para obtener más información, vea Partition Storage Modes and Processing, Proactive Caching (Partitions) y Remote Partitions.

Actualizaciones incrementales

Al crear y administrar particiones en grupos de medida de varias particiones, debe tomar precauciones especiales para garantizar que los datos del cubo sean precisos. Aunque estas precauciones no suelen aplicarse a grupos de medida de partición única, se aplican al actualizar las particiones de forma incremental. Al actualizar incrementalmente una partición, se crea una nueva partición temporal que tiene una estructura idéntica a la de la partición de origen. La partición temporal se procesa y, a continuación, se combina con la partición de origen. Por lo tanto, debe asegurarse de que la consulta de procesamiento que rellena la partición temporal no duplica ningún dato ya presente en una partición existente.

Véase también

Configurar propiedades de medida
Cubos en modelos multidimensionales