Orígenes de datos y vinculaciones (SSAS multidimensional)

Los cubos, dimensiones y otros objetos de Analysis Services se pueden enlazar a un origen de datos. Un origen de datos puede ser uno de los siguientes objetos:

• Origen de datos relacional.

• Una canalización de Analysis Services que genera un conjunto de filas (o conjuntos de filas divididos).

Los medios de expresar el origen de datos varían según el tipo de origen de datos. Por ejemplo, un origen de datos relacional se distingue por la cadena de conexión. Para obtener más información sobre los orígenes de datos, vea Orígenes de datos en modelos multidimensionales.

Independientemente del origen de datos usado, la vista del origen de datos (DSV) contiene los metadatos del origen de datos. Por lo tanto, los enlaces de un cubo u otros objetos de Analysis Services se expresan como enlaces a DSV. Estos enlaces pueden incluir enlaces a objetos lógicos, como vistas, columnas calculadas y relaciones que no existen físicamente en el origen de datos. Analysis Services agrega una columna calculada que encapsula la expresión a DSV y, a continuación, enlaza la medida OLAP correspondiente a esa columna en la DSV. Para obtener más información sobre DSV, vea Vistas del origen de datos en modelos multidimensionales.

Cada objeto de Analysis Services se enlaza al origen de datos de su propia manera. Además, los enlaces de datos para estos objetos y la definición del origen de datos se pueden proporcionar en línea con la definición del objeto de entrada de datos (por ejemplo, la dimensión) o fuera de línea como un conjunto independiente de definiciones.

Tipos de datos de Analysis Services

Los tipos de datos que se usan en enlaces deben coincidir con los tipos de datos admitidos por Analysis Services. Los siguientes tipos de datos se definen en Analysis Services:

Todos los datos recibidos del origen de datos se convierten al tipo SSAS especificado en el enlace (normalmente durante el procesamiento). Se produce un error si no se puede realizar la conversión (por ejemplo, String a Int). SQL Server Data Tools (SSDT) suele establecer el tipo de datos en el enlace que mejor coincida con el tipo de la fuente de datos. Por ejemplo, los tipos SQL Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset se asignan a SSAS Date y el tipo sql Time se asigna a String.

Vinculaciones para dimensiones

Cada atributo de una dimensión está enlazado a una columna de un DSV. Todos los atributos de una dimensión deben proceder de un único origen de datos. Sin embargo, los atributos se pueden enlazar a columnas de tablas diferentes. Las relaciones entre las tablas se definen en DSV. En el caso de que exista más de un conjunto de relaciones en la misma tabla, podría ser necesario introducir una consulta con nombre en el DSV para que actúe como una tabla "alias". Las expresiones y filtros se definen en DSV mediante cálculos con nombre y consultas con nombre.

Enlaces para Grupos de Medida, Medidas y Particiones

Cada grupo de medida tiene las siguientes vinculaciones predeterminadas.

• El grupo de medida se enlaza a una tabla de un DSV (por ejemplo, MeasureGroup.Source).

• Cada medida está enlazada a una columna de esa tabla (por ejemplo, Measure.ValueColumn.Source).

• Cada dimensión de grupo de medida tiene un conjunto de atributos de granularidad que definen la granularidad del grupo de medida. Cada uno de estos atributos debe enlazarse a la columna o columnas de la tabla de hechos que contienen la clave de atributo. (Para obtener más información sobre los atributos de granularidad, vea Atributos de granularidad de MeasureGroup más adelante en este tema).

Estos enlaces predeterminados se pueden invalidar selectivamente por partición. Cada partición puede especificar un origen de datos diferente, una tabla o un nombre de consulta o una expresión de filtro. La estrategia de creación de particiones más común es invalidar la tabla por partición mediante el mismo origen de datos. Las alternativas incluyen aplicar un filtro diferente por partición o cambiar el origen de datos.

El origen de datos predeterminado debe definirse en DSV, proporcionando así la información del esquema, incluidos los detalles de las relaciones. No es necesario que las tablas o consultas adicionales especificadas en el nivel de partición aparezcan en el DSV, pero deben tener el mismo esquema que la tabla predeterminada definida para el grupo de medida, o al menos deben contener todas las columnas utilizadas por las medidas o atributos de granularidad. Los vínculos detallados por medida y atributo de granularidad no se pueden invalidar en el nivel de partición, y se asume que son las mismas columnas que se definen para el grupo de medidas. Por lo tanto, si la partición usa un origen de datos que tiene un esquema diferente, la TableDefinition consulta definida para la partición debe dar lugar al mismo esquema que el esquema usado por el grupo de medida.

Atributos de granularidad de MeasureGroup

Cuando la granularidad de un grupo de medida coincide con la granularidad conocida en la base de datos y hay una relación directa entre la tabla de hechos y la tabla de dimensiones, el atributo de granularidad solo debe enlazarse a la columna o columnas de clave externa adecuadas de la tabla de hechos. Por ejemplo, considere las siguientes tablas de hechos y dimensiones:

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

Si analiza por el Producto ordenado (Ordered Product), para el rol de dimensión del Producto ordenado en Ventas, el atributo de granularidad del Producto se vincularía a Sales.OrderedProductID.

Sin embargo, puede haber ocasiones en las que GranularityAttributes podría no existir como columnas en la tabla de hechos. Por ejemplo, GranularityAttributes podría no existir como columnas en las siguientes circunstancias:

• La granularidad OLAP es más gruesa que la granularidad del origen.

• Una tabla intermedia interpone entre la tabla de hechos y la tabla de dimensiones.

• La clave de dimensión no es la misma que la clave principal de la tabla de dimensiones.

En todos estos casos, se debe definir el DSV para que exista GranularityAttributes en la tabla de hechos. Por ejemplo, se puede introducir una consulta con nombre o una columna calculada.

Por ejemplo, en las mismas tablas de ejemplo anteriores, si la granularidad fuera por Categoría, se podría introducir una vista de ventas:

SalesWithCategory(RequestedDate, OrderedProductID, ReplacementProductID, Qty, OrderedProductCategory)

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

En este caso, la categoría GranularityAttribute está enlazada a SalesWithCategory.OrderedProductCategory.

Migración desde objetos de apoyo a la toma de decisiones

Los objetos de soporte de decisión (DSO) 8.0 permiten PartitionMeasures recuperarse. Por lo tanto, la estrategia de migración en estos casos es construir la consulta adecuada.

Del mismo modo, no es posible volver a enlazar los atributos de dimensión dentro de una partición, aunque DSO 8.0 también permite este reenlace. La estrategia de migración en estos casos es definir las consultas con nombre necesarias en el DSV para que las mismas tablas y columnas existan en el DSV para la partición, tal como las tablas y columnas que se usan para la dimensión. Estos casos pueden requerir la adopción de la migración simple, en la que la cláusula From/Join/Filter se asigna a una sola consulta con nombre en lugar de a un conjunto estructurado de tablas relacionadas. Dado que DSO 8.0 permite que PartitionDimensions se rebote incluso cuando la partición usa el mismo origen de datos, la migración también puede requerir varios DSV para el mismo origen de datos.

En DSO 8.0, los enlaces correspondientes se pueden expresar de dos maneras diferentes, dependiendo de si se emplean esquemas optimizados, mediante el enlace a la clave principal de la tabla de dimensiones o la clave externa de la tabla de hechos. En ASSL, las dos formas diferentes no se distinguen.

El mismo enfoque para los enlaces se aplica incluso para una partición mediante un origen de datos que no contiene las tablas de dimensiones, ya que el enlace se realiza a la columna de clave externa de la tabla de hechos, no a la columna de clave principal de la tabla de dimensiones.

Vinculaciones para modelos de minería de datos

Un modelo de minería de datos es relacional o OLAP. Los enlaces de datos de un modelo de minería de datos relacionales son considerablemente diferentes de los enlaces de un modelo de minería de datos OLAP.

Enlaces para un modelo relacional de minería de datos

Un modelo de minería de datos relacional se basa en las relaciones definidas en el DSV para resolver cualquier ambigüedad con respecto a qué columnas están enlazadas a los orígenes de datos. En un modelo de minería de datos relacional, los enlaces de datos siguen estas reglas:

• Cada columna de tabla no anidada está enlazada a una columna en la tabla de casos o en una tabla relacionada con la tabla de casos (siguiendo una relación de muchos a uno o uno a uno). El DSV define las relaciones entre las tablas.

• Cada columna de tabla anidada está enlazada a una tabla de origen. Las columnas que pertenecen a la columna de tabla anidada se enlazan a columnas de esa tabla de origen o una tabla relacionada con la tabla de origen. (De nuevo, el enlace sigue una relación de varios a uno o uno a uno). Los enlaces del modelo de minería de datos no proporcionan el camino de unión a la tabla anidada. En su lugar, las relaciones definidas en DSV proporcionan esta información.

Enlaces para un modelo de minería de datos OLAP

Los modelos de minería de datos OLAP no tienen el equivalente de un DSV. Por lo tanto, los enlaces de datos deben proporcionar cualquier desambiguación entre columnas y orígenes de datos. Por ejemplo, un modelo de minería se puede basar en el cubo de Ventas y las columnas se pueden basar en Cant, Importe y Nombre del Producto. Como alternativa, un modelo de minería de datos se puede basar en Product y las columnas se pueden basar en Product Name, Product Color y en una tabla anidada con Sales Qty.

En un modelo de minería de datos OLAP, los enlaces de datos siguen estas reglas:

• Cada columna de la tabla no anidada está vinculada a una medida de un cubo, a un atributo de una dimensión de ese cubo (especificando el CubeDimension para desambiguar en el caso de los roles de dimensión) o a un atributo de una dimensión.

• Cada columna de tabla anidada está enlazada a un CubeDimension. Es decir, define cómo navegar desde una dimensión a un cubo relacionado o (en el caso menos común de las tablas anidadas) de un cubo a una de sus dimensiones.

Enlaces fuera de línea

Los enlaces fuera de línea permiten cambiar temporalmente los enlaces de datos existentes mientras dure un comando. Los enlaces fuera de línea hacen referencia a los enlaces que se incluyen en un comando y no se conservan. Los enlaces fuera de línea solo se aplican mientras se ejecuta ese comando en particular. Por el contrario, las vinculaciones en línea están contenidas en la definición del objeto ASSL y persisten con la definición del objeto dentro de los metadatos del servidor.

ASSL permite especificar enlaces fuera de línea en un comando Process, bien si no está en un lote, o en un comando Batch. Si se especifican vínculos fuera de línea en el comando Batch, todos los vínculos especificados en el comando Batch crean un nuevo contexto de vinculación en el cual se ejecutan todos los comandos Process del lote. Este nuevo contexto de enlace incluye objetos que se procesan indirectamente debido al Process comando .

Cuando se especifican enlaces fuera de línea en un comando, invalidan los enlaces insertados contenidos en el DDL persistente para los objetos especificados. Estos objetos procesados pueden incluir el objeto denominado directamente en el Process comando o pueden incluir otros objetos cuyo procesamiento se inicia automáticamente como parte del procesamiento.

Los enlaces fuera de línea se especifican mediante la inclusión del objeto de colección opcional Bindings con el comando de procesamiento. La colección opcional Bindings contiene los siguientes elementos.

Todos los elementos relacionados con enlaces fuera de línea son opcionales. Para los elementos no especificados, ASSL usa la especificación contenida en el DDL del objeto persistente. La especificación de DataSource o DataSourceView en el Process comando es opcional. Si se especifica DataSource o DataSourceView, no se crean instancias y no persisten después de que el comando Process se haya completado.

Definición del tipo de vinculación fuera de línea

Dentro de la colección fuera de línea Bindings, ASSL permite una colección de enlaces para varios objetos, cada uno representado como Binding. Cada Binding tiene una referencia de objeto extendida, que es similar a la referencia de objeto, pero también puede hacer referencia a objetos secundarios (por ejemplo, atributos de dimensión y atributos de grupo de medida). Este objeto toma la forma plana típica del elemento Object en los comandos Process, excepto que las etiquetas <Object></Object> no están presentes.

Cada objeto para el que se especifica el enlace se identifica mediante un elemento XML de la forma <objeto>ID (por ejemplo, DimensionID). Una vez que haya identificado el objeto lo más específicamente posible con el ID de <objeto>, identifique el elemento para el cual se está especificando el enlace, que suele ser Source. Un caso común a tener en cuenta es aquel en el que Source es una propiedad sobre DataItem, lo cual ocurre en los vínculos de columnas en un atributo. En este caso, no se especifica la DataItem etiqueta; en su lugar, simplemente se especifica la Source propiedad , como si estuviera directamente en la columna que se va a enlazar.

KeyColumns se identifican mediante su ordenación dentro de la colección KeyColumns. No es posible especificar, por ejemplo, solo las columnas de clave primera y tercera de un atributo, porque no hay ninguna manera de indicar que se va a omitir la segunda columna de clave. Todas las columnas de claves deben estar presentes en la vinculación fuera de línea para un atributo de dimensión.

Translations, aunque no tienen ningún identificador, se identifican semánticamente por su idioma. Por lo tanto, el Translations dentro de un Binding necesita incluir su identificador de idioma.

Un elemento adicional permitido dentro de un Binding que no existe directamente en el DDL es ParentColumnID, que se usa para las tablas anidadas para la minería de datos. En este caso, es necesario identificar la columna primaria de la tabla anidada para la que se proporciona el enlace.