Fontes de dados e associações (Multidimensional do SSAS)

Cubos, dimensões e outros objetos do Analysis Services podem ser associados a uma fonte de dados. Uma fonte de dados pode ser um dos seguintes objetos:

• Uma fonte de dados relacional.

• Um pipeline do Analysis Services que produz um conjunto de linhas (ou conjuntos de linhas organizados em capítulos).

O meio de expressar a fonte de dados varia de acordo com o tipo de fonte de dados. Por exemplo, uma fonte de dados relacional é distinguida pela cadeia de conexão. Para obter mais informações sobre fontes de dados, consulte Fontes de Dados em Modelos Multidimensionais.

Independentemente da fonte de dados usada, a exibição da fonte de dados (DSV) contém os metadados da fonte de dados. Assim, as associações para um cubo ou outros objetos do Analysis Services são expressas como associações ao DSV. Essas associações podem incluir associações a objetos lógicos, como exibições, colunas calculadas e relações que não existem fisicamente na fonte de dados. O Analysis Services adiciona uma coluna calculada que encapsula a expressão ao DSV e associa a medida OLAP correspondente a essa coluna no DSV. Para obter mais informações sobre DSVs, consulte Exibições da fonte de dados em modelos multidimensionais.

Cada objeto do Analysis Services é associado à fonte de dados à sua maneira. Além disso, as associações de dados para esses objetos e a definição da fonte de dados podem ser fornecidas embutidas com a definição do objeto de saída de dados (por exemplo, a dimensão) ou fora de linha como um conjunto separado de definições.

Tipos de dados do Analysis Services

Os tipos de dados usados em associações devem corresponder aos tipos de dados compatíveis com o Analysis Services. Os seguintes tipos de dados são definidos no Analysis Services:

Todos os dados recebidos da fonte de dados são convertidos no tipo SSAS especificado na associação (geralmente durante o processamento). Um erro será gerado se a conversão não puder ser executada (por exemplo, String to Int). O SSDT (SQL Server Data Tools) geralmente define o tipo de dados na associação para aquele que melhor corresponde ao tipo de origem na fonte de dados. Por exemplo, os tipos SQL Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset são mapeados para o tipo Data no SSAS, e o tipo SQL Time é mapeado para String.

Vinculações de dimensões

Cada atributo de uma dimensão é associado a uma coluna em um DSV. Todos os atributos de uma dimensão devem vir de uma única fonte de dados. No entanto, os atributos podem ser associados a colunas em tabelas diferentes. As relações entre as tabelas são definidas no DSV. No caso em que mais de um conjunto de relações existe para a mesma tabela, talvez seja necessário introduzir uma consulta nomeada no DSV para atuar como uma tabela de 'alias'. Expressões e filtros são definidos no DSV usando cálculos nomeados e consultas nomeadas.

Associações para Grupos de Medidas, Medidas e Partições

Cada grupo de medidas tem as seguintes associações padrão:

• O grupo de medidas é associado a uma tabela em um DSV (por exemplo, MeasureGroup.Source).

• Cada medida é associada a uma coluna nessa tabela (por exemplo, Measure.ValueColumn.Source).

• Cada dimensão do grupo de medidas tem um conjunto de atributos de granularidade que definem a granularidade do grupo de medidas. Cada um desses atributos deve ser associado à coluna ou colunas na tabela de fatos que contêm a chave de atributo. (Para obter mais informações sobre atributos de granularidade, consulte Atributos de granularidade MeasureGroup mais adiante neste tópico.)

Essas associações padrão podem ser substituídas seletivamente por partição. Cada partição pode especificar uma fonte de dados, uma tabela ou um nome de consulta ou uma expressão de filtro diferente. A estratégia de particionamento mais comum é sobrescrever a tabela por partição usando a mesma fonte de dados. As alternativas incluem aplicar um filtro diferente por partição ou alterar a fonte de dados.

A fonte de dados padrão deve ser definida no DSV, fornecendo assim as informações de esquema, incluindo os detalhes das relações. Quaisquer tabelas ou consultas adicionais especificadas no nível de partição não precisam ser listadas no DSV, mas devem ter o mesmo esquema que a tabela padrão definida para o grupo de medidas, ou pelo menos devem conter todas as colunas usadas pelas medidas ou atributos de granularidade. As vinculações detalhadas por medida e atributo de granularidade não podem ser substituídas no nível de partição, e são pressupostas como conectadas às mesmas colunas definidas para o grupo de medidas. Portanto, se a partição usar uma fonte de dados que de fato tenha um esquema diferente, a TableDefinition consulta definida para a partição deverá resultar no mesmo esquema que o esquema usado pelo grupo de medidas.

Atributos de Granularidade de MeasureGroup

Quando a granularidade de um grupo de medidas corresponde à granularidade conhecida no banco de dados e há uma relação direta da tabela de fatos com a tabela de dimensões, o atributo de granularidade só precisa ser associado à coluna ou colunas de chave estrangeira apropriadas na tabela de fatos. Por exemplo, considere as seguintes tabelas de fatos e dimensões:

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

Se você analisar pelo produto ordenado, para a função de dimensão Produto Ordenado em Vendas, o atributo granularidade do produto será associado a Sales.OrderedProductID.

No entanto, pode haver momentos em que o GranularityAttributes pode não existir como colunas na tabela de fatos. Por exemplo, pode GranularityAttributes não existir como colunas nas seguintes circunstâncias:

• A granularidade OLAP é mais grosseira que a granularidade na origem.

• Uma tabela intermediária interpõe entre a tabela de fatos e a tabela de dimensões.

• A chave de dimensão não é a mesma que a chave primária na tabela de dimensões.

Em todos esses casos, o DSV deve ser definido para que os GranularityAttributes existam na tabela de fatos. Por exemplo, uma consulta nomeada ou uma coluna calculada pode ser introduzida.

Por exemplo, nas mesmas tabelas de exemplo que acima, se a granularidade fosse por Categoria, uma exibição das Vendas poderia ser introduzida:

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

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

Nesse caso, a categoria GranularityAttribute está associada a SalesWithCategory.OrderedProductCategory.

Migrando de objetos de suporte à decisão

O DSO (Decision Support Objects) 8.0 permite PartitionMeasures a recuperação. Portanto, a estratégia de migração nesses casos é construir a consulta apropriada.

Da mesma forma, não é possível associar novamente os atributos de dimensão em uma partição, embora o DSO 8.0 também permita essa vinculação. A estratégia de migração nesses casos é definir as consultas nomeadas necessárias no DSV para que as mesmas tabelas e colunas existam no DSV para a partição como as tabelas e colunas usadas para a dimensão. Esses casos podem exigir a adoção da migração simples, na qual a cláusula From/Join/Filter é mapeada para uma única consulta nomeada em vez de para um conjunto estruturado de tabelas relacionadas. Como o DSO 8.0 permite que PartitionDimensions seja recuperado mesmo quando a partição estiver usando a mesma fonte de dados, a migração também pode exigir vários DSVs para a mesma fonte de dados.

No DSO 8.0, as associações correspondentes podem ser expressas de duas maneiras diferentes, dependendo se os esquemas otimizados são empregados, associando-se à chave primária na tabela de dimensões ou à chave estrangeira na tabela de fatos. No ASSL, as duas formas diferentes não são distinguidas.

A mesma abordagem para associações aplica-se até mesmo a uma partição usando uma fonte de dados que não contém as tabelas de dimensão, pois a associação é feita à coluna de chave estrangeira na tabela de fatos, não à coluna de chave primária na tabela de dimensões.

Vinculações para modelos de mineração

Um modelo de mineração é relacional ou OLAP. As associações de dados para um modelo de mineração relacional são consideravelmente diferentes das associações para um modelo de mineração OLAP.

Vinculações para um modelo de mineração relacional

Um modelo de mineração relacional depende das relações definidas no DSV para resolver qualquer ambiguidade em relação a quais colunas estão associadas a quais fontes de dados. Em um modelo de mineração relacional, as associações de dados seguem estas regras:

• Cada coluna de tabela não aninhada está vinculada a uma coluna na tabela de casos ou a uma tabela relacionada à tabela de casos (seguindo uma relação muitos-para-um ou um-para-um). O DSV define as relações entre as tabelas.

• Cada coluna em tabela aninhada está associada a uma tabela de origem. As colunas que pertencem à coluna de tabela hierárquica são então vinculadas a colunas dessa tabela de origem ou de uma tabela relacionada à tabela de origem. (Novamente, a vinculação segue uma relação muitos para um ou um para um.) As vinculações de modelos de mineração não fornecem o caminho de junção para a tabela aninhada. Em vez disso, as relações definidas no DSV fornecem essas informações.

Vinculações para um Modelo de Mineração OLAP

Os modelos de mineração OLAP não têm o equivalente a um DSV. Portanto, as associações de dados devem fornecer qualquer desambiguação entre colunas e fontes de dados. Por exemplo, um modelo de mineração pode ser baseado no cubo Vendas e as colunas podem ser baseadas em Qty, Quantidade e Nome do Produto. Como alternativa, um modelo de mineração pode ser baseado no Produto, e as colunas podem ser baseadas no Nome do Produto, na Cor do Produto e em uma tabela aninhada com a Quantidade de Vendas.

Em um modelo de mineração OLAP, as associações de dados seguem estas regras:

• Cada coluna de tabela não aninhada é associada a uma medida em um cubo, a um atributo em uma dimensão desse cubo (especificando a CubeDimension desambiguação no caso de funções de dimensão) ou a um atributo em uma dimensão.

• Cada coluna de tabela aninhada está associada a um CubeDimension. Ou seja, define como navegar de uma dimensão para um cubo relacionado ou (no caso menos comum de tabelas aninhadas) de um cubo para uma de suas dimensões.

Vínculos fora de linha

As associações fora de linha permitem alterar temporariamente as associações de dados existentes durante a duração de um comando. Associações fora de linha referem-se a associações incluídas em um comando e que não são mantidas. As associações fora de linha se aplicam somente enquanto esse comando específico é executado. Por outro lado, as associações embutidas estão contidas na definição de objeto ASSL e persistem com a definição de objeto nos metadados do servidor.

ASSL permite que associações fora de linha sejam especificadas em um comando Process, caso não estejam em um lote, ou em um comando Batch. Se as associações fora de linha forem especificadas no Batch comando, todas as associações especificadas no Batch comando criarão um novo contexto de associação no qual todos os Process comandos do lote serão executados. Esse novo contexto de associação inclui objetos que são processados indiretamente por causa do Process comando.

Quando associações fora de linha são especificadas em um comando, elas substituem as associações embutidas contidas no DDL persistente para os objetos especificados. Esses objetos processados podem incluir o objeto diretamente nomeado no Process comando ou podem incluir outros objetos cujo processamento é iniciado automaticamente como parte do processamento.

As associações fora de linha são especificadas incluindo o objeto de coleção opcional Bindings com o comando de processamento. A coleção opcional Bindings contém os seguintes elementos.

Todos os elementos relacionados a associações fora de linha são opcionais. Para quaisquer elementos não especificados, o ASSL usa a especificação contida na DDL do objeto persistente. A especificação de DataSource ou DataSourceView no Process comando é opcional. Se DataSource ou DataSourceView forem especificados, eles não serão instanciados e não persistirão após a conclusão do Process comando.

Definição do tipo de vinculação fora de linha

Dentro da coleção fora de linha Bindings , o ASSL permite uma coleção de associações para vários objetos, cada um Binding. Cada Binding um tem uma referência de objeto estendido, que é semelhante à referência de objeto, mas também pode se referir a objetos menores (por exemplo, atributos de dimensão e atributos de grupo de medidas). Esse objeto assume a forma plana típica do elemento Object em comandos Process, exceto que as tags <Objeto></Objeto> não aparecem.

Cada objeto para o qual a associação é especificada é identificado por um elemento XML da forma <objeto>ID (por exemplo, DimensionID). Depois de identificar o objeto o mais especificamente possível com a ID do <objeto>, identifique o elemento para o qual a associação está sendo especificada, o que geralmente é Source. Um caso comum a ser observado é aquele em que Source é uma propriedade no DataItem, que é o caso de associações de coluna em um atributo. Nesse caso, você não especifica a DataItem tag; em vez disso, basta especificar a Source propriedade, como se estivesse diretamente na coluna a ser vinculada.

KeyColumns são identificados por sua ordenação na coleção de KeyColumns. Não é possível especificar, por exemplo, apenas a primeira e terceira colunas de chave de um atributo, pois não há como indicar que a segunda coluna de chave deve ser ignorada. Todas as colunas de chave devem estar presentes na associação fora de linha para um atributo de dimensão.

Translations, embora não tenham nenhuma ID, são identificados semanticamente por sua linguagem. Portanto, o Translations dentro de um Binding necessita incluir seu identificador de idioma.

Um elemento adicional permitido dentro de um Binding, que não existe diretamente no DDL, é o ParentColumnID, que é usado para tabelas aninhadas para mineração de dados. Nesse caso, é necessário identificar a coluna pai na tabela aninhada para a qual a vinculação está sendo feita.