Orígenes de datos y enlaces (SSAS multidimensional)

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

• Un origen de datos relacional.

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

El medio de expresar el origen de datos varía según el tipo de origen de datos. Por ejemplo, un origen de datos relacional se distingue por una cadena de conexión. Para obtener más información acerca de los orígenes de datos, vea Orígenes de datos en modelos multidimensionales.

Sin tener en cuenta el origen de datos usado, la vista del origen de datos (DSV) contiene los metadatos para el origen de datos. Así, los enlaces para 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 en la DSV y, a continuación, enlaza la medida de OLAP correspondiente a dicha columna de la DSV. Para obtener más información acerca de DSVs, vea Vistas del origen de datos en modelos multidimensionales.

Cada objeto Analysis Services enlaza con el origen de datos a su manera. Además, los enlaces de datos para estos objetos y la definición del origen de datos se pueden proporcionar insertados con la definición del objeto enlazado a 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 utilizan en los enlaces deben coincidir con los tipos de datos admitidos por Analysis Services. Los tipos de datos siguientes están definidos en Analysis Services:

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

Enlaces para dimensiones

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

Enlaces para grupos de medidas, medidas y particiones

Cada grupo de medidas tiene los enlaces predeterminados siguientes:

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

• Cada medida se enlaza a una columna de dicha tabla (por ejemplo, Measure.ValueColumn.Source).

• Cada dimensión de grupo de medidas tiene un conjunto de atributos de granularidad que definen la granularidad del grupo de medidas. Cada uno de estos atributos se debe enlazar 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 grupo de medidas posteriormente en este tema.)

Estos enlaces predeterminados se pueden invalidar de manera selectiva por partición. Cada partición puede especificar un origen de datos, tabla o nombre de consulta, o expresión de filtro diferentes. La estrategia de partición más común es invalidar la tabla por partición, usando el mismo origen de datos. Las alternativas incluyen la aplicación de un filtro diferente por partición o el cambio del origen de datos.

El origen de datos predeterminado se debe definir en la DSV, proporcionando por tanto la información del esquema, incluyendo los detalles de las relaciones. Cualquier consulta o tabla adicional especificada en el nivel de partición no se tiene que mostrar en la DSV, pero deben tener el mismo esquema que la tabla predeterminada definida para el grupo de medidas o, al menos, deben contener todas las columnas usadas por las medidas o los atributos de granularidad. Los enlaces detallados por medida y atributo de granularidad no se pueden invalidar en el nivel de partición y se supone que son para las mismas columnas como se define para el grupo de medidas. Por consiguiente, si la partición usa un origen de datos que tiene de hecho un esquema diferente, la consulta TableDefinition definida para la partición debe producir el mismo esquema que el usado por el grupo de medidas.

Atributos de granularidad de grupo de medidas

Cuando la granularidad de un grupo de medidas coincide con la granularidad conocida en la base de datos, y hay una relación directa de la tabla de hechos a la tabla de dimensiones, el atributo de granularidad solamente tiene que enlazarse con la columna o columnas de clave externa adecuadas de la tabla de hechos. Por ejemplo, piense en el hecho siguiente y en las tablas de 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 pedido, para el producto pedido en el rol de dimensión de ventas, el atributo de granularidad de producto se enlazaría a Sales.OrderedProductID.

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

• La granularidad de OLAP es más amplia que la granularidad en el origen.

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

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

En todos estos casos, la DSV se debe definir para que existan 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 que las anteriores, si la granularidad era por Categoría, se podría introducir una vista de las 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 se enlaza a SalesWithCategory.OrderedProductCategory.

Migrar desde Objetos de ayuda para la toma de decisiones

Objetos de ayuda para la toma de decisiones (DSO) 8.0 permiten que PartitionMeasures se vuelvan a enlazar. Por consiguiente, la estrategia de migración en estos casos es construir la consulta adecuada.

De igual forma, no es posible volver a enlazar los atributos de dimensión dentro de una partición, aunque DSO 8.0 permite además este reenlace. La estrategia de migración en estos casos es definir las consultas con nombre necesarias en DSV de manera que existan las mismas tablas y columnas en la DSV para la partición, conforme se usan tablas y columnas para la dimensión. Estos casos pueden requerir la adopción de la migración simple, en la que la cláusula de/combinación/filtro está asignada a una consulta con nombre única en lugar de a un conjunto estructurado de tablas relacionadas. Al igual que DSO 8.0 permite a PartitionDimensions volverse a enlazar cuando la partición está usando el mismo origen de datos, la migración también puede requerir varias 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, enlazando a la clave principal de la tabla de dimensiones o a la clave externa de la tabla de hechos. En ASSL, no se distinguen los dos formularios diferentes.

El mismo enfoque a los enlaces se aplica incluso para una partición con un origen de datos que no contiene 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.

Enlaces para modelos de minería de datos

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

Enlaces para un modelo de minería de datos relacional

Un modelo de minería de datos relacional depende de las relaciones definidas en la DSV para resolver cualquier ambigüedad respecto a qué columnas se enlazan a determinados 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 se enlaza a una columna de la tabla de casos o a una tabla relacionada con la tabla de casos (siguiendo una relación de varios a uno o de uno a uno). La DSV define las relaciones entre las tablas.

• Cada columna de tabla anidada se enlaza a una tabla de origen. Las columnas que son propiedad de la columna de tabla anidada se enlazan a continuación a las columnas de dicha 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 de uno a uno.) Los enlaces del modelo de minería de datos no proporcionan la ruta de acceso de combinación a la tabla anidada. En su lugar, las relaciones definidas en la DSV proporcionan esta información.

Enlaces para un modelo de minería de datos OLAP

Los modelos de minería de datos de OLAP no tienen el equivalente de una DSV. Por consiguiente, los enlaces de datos deben proporcionar cualquier anulación de ambigüedad entre columnas y orígenes de datos. Por ejemplo, un modelo de minería de datos puede basarse en el cubo Ventas y las columnas se pueden basar en Qty, Amount y Product Name. Alternativamente, un modelo de minería de datos puede estar basado en producto y las columnas se pueden basar en nombre de producto, color de producto y una tabla anidada con cantidad de ventas.

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

• Cada columna de tabla no anidada se enlaza a una medida de un cubo, a un atributo de una dimensión de dicho cubo (especificando CubeDimension para eliminar la ambigüedad en el caso de roles de dimensión), o a un atributo de una dimensión.

• Cada columna de tabla anidada se enlaza a una CubeDimension. Es decir, define cómo navegar desde una dimensión a un cubo relacionado o, en el caso menos común de tablas anidadas, desde 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 dura un comando. Los enlaces fuera de línea hacen referencia a los enlaces incluidos en un comando y que no se conservan. Los enlaces fuera de línea solo se aplican mientras se ejecuta dicho comando concreto. En contraste, los enlaces insertados están contenidos en la definición de objeto de ASSL y se conservan con la definición de objeto dentro de los metadatos del servidor.

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

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

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

Todos los elementos que se relacionan con los enlaces fuera de línea son opcionales. Para cualquier elemento no especificado, ASSL usa la especificación contenida en el DDL del objeto almacenado. La especificación de DataSource o DataSourceView en el comando Process es opcional. Si se especifican DataSource o DataSourceView, no se crean instancias de los mismos y no se almacenan después de que el comando Process se haya completado.

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

Dentro de la colección Bindings fuera de línea, ASSL permite una colección de enlaces para varios objetos, cada uno de ellos Binding. Cada Binding tiene una referencia de objeto extendida, similar a la referencia a objeto, pero que también puede hacer referencia a objetos secundarios (por ejemplo, atributos de dimensión y atributos de grupo de medidas). Este objeto toma la forma plana típica del elemento Object en los comandos Process, excepto en 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 <object>ID (por ejemplo, DimensionID). Después de haber identificado el objeto de la manera más específica posible con la forma <object>ID, a continuación, debe identificar el elemento para el que se especifica el enlace, que suele ser Source. Un caso común para tener en cuenta es en qué Source es una propiedad del DataItem, que es el caso para enlaces de columna en un atributo. En este caso, no especifica la etiqueta DataItem; en su lugar, simplemente especifica la propiedad Source, como si estuviera directamente en la columna que se va a enlazar.

KeyColumns se identifican por su orden dentro de la colección KeyColumns. Allí no es posible especificar, por ejemplo, solo la primera y la tercera columna de clave de un atributo, porque no hay manera de indicar que se va a omitir la segunda columna de clave. Todas las columnas de clave deben encontrarse en el enlace fuera de línea para un atributo de dimensión.

Translations, aunque no tienen ningún Id., se identifican semánticamente por su idioma. Por consiguiente, Translations dentro de un enlace Binding tienen que 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 en la tabla anidada para la que se proporciona el enlace.