Fontes de Dados e Ligações (SSAS Multidimensional)

Aplica-se a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

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

• Uma fonte de dados relacional.

• Um processo de Serviços de Análise do SQL Server que gera um conjunto de linhas (ou conjuntos de linhas segmentados).

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

Independentemente da fonte de dados utilizada, a vista da fonte de dados (DSV) contém os metadados da fonte de dados. Assim, as ligações para um cubo ou outros objetos do SQL Server Analysis Services são expressas como ligações ao DSV. Estas ligações podem incluir ligações a objetos lógicos — objetos como vistas, colunas calculadas e relações que não existem fisicamente na fonte de dados. O SQL Server Analysis Services adiciona uma coluna calculada que encapsula a expressão no DSV, e depois liga a correspondente medida OLAP a essa coluna no DSV. Para mais informações sobre DSVs, consulte Vistas de Fonte de Dados em Modelos Multidimensionais.

Cada objeto SQL Server Analysis Services associa-se à fonte de dados à sua maneira. Além disso, as ligações de dados para estes objetos e a definição da fonte de dados podem ser fornecidas em linha com a definição do objeto databound (por exemplo, a dimensão), ou fora de linha como um conjunto separado de definições.

Serviços de Análise Tipos de Dados

Os tipos de dados usados em bindings devem corresponder aos tipos de dados suportados pelos SQL Server Analysis Services. Os seguintes tipos de dados são definidos no SQL Server Analysis Services:

Todos os dados recebidos da fonte de dados são convertidos para o tipo SSAS especificado na ligação (normalmente durante o processamento). Um erro é gerado se a conversão não puder ser realizada (por exemplo, String para Int). O SQL Server Data Tools normalmente define o tipo de dado na ligaçã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 Data SSAS, e o tipo SQL Time é mapeado para String.

Encadernações para Dimensões

Cada atributo de uma dimensão está ligado a uma coluna numa DSV. Todos os atributos de uma dimensão devem vir de uma única fonte de dados. No entanto, os atributos podem ser atribuídos a colunas em diferentes tabelas. As relações entre as tabelas são definidas no DSV. No caso de existir mais do que um conjunto de relações para a mesma tabela, pode ser necessário introduzir uma consulta nomeada na DSV para atuar como uma tabela 'alias'. Expressões e filtros são definidos na DSV através de cálculos nomeados e consultas nomeadas.

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

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

• O grupo de medidas está ligado a uma tabela num DSV (por exemplo, MeasureGroup.Source).

• Cada medida está vinculada a uma coluna nessa tabela (por exemplo, Measure.ValueColumn.Source).

• Cada dimensão de grupo de medida tem um conjunto de atributos de granularidade que definem a granularidade do grupo de medidas. Cada um destes atributos deve estar vinculado à coluna ou colunas na tabela de factos que contêm a chave de atributos. (Para mais informações sobre atributos de granularidade, veja MeasureGroup Granularity Attributes mais adiante neste tópico.)

Estas associações por defeito podem ser seletivamente substituídas por partição. Cada partição pode especificar uma fonte de dados diferente, nome de tabela ou consulta, ou expressão de filtro. A estratégia de particionamento mais comum é sobrepor a tabela por partição, usando a mesma fonte de dados. 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 a informação do esquema, incluindo os detalhes das relações. Quaisquer tabelas ou consultas adicionais especificadas ao nível da partição não precisam de ser listadas na DSV, mas devem ter o mesmo esquema da tabela padrão definida para o grupo de medidas, ou pelo menos devem conter todas as colunas usadas pelos atributos de medidas ou granularidade. As ligações detalhadas por medida e atributo de granularidade não podem ser alteradas ao nível da partição, e supõe-se que estão nas mesmas colunas definidas para o grupo de medidas. Portanto, se a partição usar uma fonte de dados que de facto tem um esquema diferente, a consulta TableDefinition definida para a partição deve resultar no mesmo esquema usado pelo grupo de medidas.

Atributos de granularidade do MeasureGroup

Quando a granularidade de um grupo de medidas corresponde à granularidade conhecida na base de dados, e existe uma relação direta da tabela de factos para a tabela de dimensões, o atributo de granularidade só precisa de ser ligado à coluna ou colunas de chave estrangeira apropriadas na tabela de factos. Por exemplo, considere as seguintes tabelas de factos e dimensões:

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

Se analisares pelo produto encomendado, para a função de Produto Encomendado na dimensão de Vendas, o atributo de granularidade do Produto estaria ligado a Sales.OrderedProductID.

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

• A granularidade OLAP é mais grosseira do que a granularidade na fonte.

• Uma tabela intermédia interpõe-se entre a tabela de factos 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, a DSV deve ser definida de modo a que os GranularityAttributes existam na tabela de factos. Por exemplo, pode ser introduzida uma consulta nomeada ou uma coluna calculada.

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

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

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

Neste caso, a Categoria GranularityAttribute está vinculada a SalesWithCategory.OrderedProductCategory.

Migração a partir de Objetos de Apoio à Decisão

O Decision Support Objects (DSO) 8.0 permite que as PartitionMeasures sejam rebound. Portanto, a estratégia de migração nestes casos é construir a consulta apropriada.

De forma semelhante, não é possível reassociar os atributos dimensionais dentro de uma partição, embora o DSO 8.0 permita também esta reassociação. A estratégia de migração nestes casos é definir as consultas nomeadas necessárias no DSV para que as mesmas tabelas e colunas existam no DSV para a partição, assim como as tabelas e colunas que são usadas para a dimensão. Estes 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 as PartitionDimensions sejam rebound mesmo quando a partição utiliza a mesma fonte de dados, a migração pode também exigir múltiplos DSVs para a mesma fonte de dados.

No DSO 8.0, as ligações correspondentes podem ser expressas de duas formas diferentes, dependendo se são usados esquemas otimizados, ligando à chave primária na tabela de dimensões ou à chave estrangeira na tabela de factos. Na ASSL, as duas formas diferentes não são distinguidas.

A mesma abordagem aplica-se às ligações mesmo para uma partição que utiliza uma fonte de dados que não contém as tabelas de dimensões, porque a ligação é feita à coluna da chave estrangeira na tabela de factos, e não à coluna principal da tabela de dimensões.

Fixações para Modelos de Mineração

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

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

Um modelo de mineração relacional baseia-se nas relações definidas na DSV para resolver qualquer ambiguidade quanto a quais colunas estão ligadas a que fontes de dados. Num modelo de mineração relacional, as ligações de dados seguem estas regras:

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

• Cada coluna de tabela aninhada está associada a uma tabela de origem. As colunas pertencentes à coluna da tabela aninhada são então atribuídas a colunas dessa tabela de origem ou a uma tabela relacionada com a tabela de origem. (Mais uma vez, a associação segue uma relação muitos-para-um ou um-para-um.) As associações do modelo de mineração não fornecem o caminho de junção para a tabela aninhada. Em vez disso, as relações definidas na DSV fornecem esta informação.

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 ligações de dados devem fornecer qualquer desambiguação entre colunas e fontes de dados. Por exemplo, um modelo de mineração pode basear-se no Cubo de Vendas, e as colunas podem ser baseadas em Qty, Quantia e Nome do Produto. Alternativamente, um modelo de mineração pode basear-se no Produto, e as colunas podem basear-se no Nome do Produto, Cor do Produto e numa tabela aninhada com Quantia de Vendas.

Num modelo de mineração OLAP, as ligações de dados seguem estas regras:

• Cada coluna de tabela não aninhada está associada a uma medida de um cubo, a um atributo de uma dimensão desse cubo (especificando a Dimensão do Cubo para desambiguar em caso de papéis dimensionais), ou a um atributo de uma dimensão.

• Cada coluna de tabela aninhada está ligada a uma Dimensão do Cubo. 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 das suas dimensões.

Fixações fora de linha

As ligações fora de linha permitem-lhe alterar temporariamente as ligações de dados existentes durante a duração de um comando. Associações fora de linha referem-se a ligações que estão incluídas num comando e que não são persistidas. As ligações fora de linha aplicam-se apenas enquanto esse comando específico é executado. Em contraste, as ligações inline estão contidas na definição do objeto ASSL e persistem com a definição do objeto dentro dos metadados do servidor.

O ASSL permite que ligações fora da linha sejam especificadas num comando Process , se não estiver num batch, ou num comando Batch . Se as ligações fora da linha forem especificadas no comando Batch , todas as ligações especificadas no comando Batch criam um novo contexto de binding no qual todos os comandos Process do batch são executados. Este novo contexto de ligação inclui objetos que são processados indiretamente devido ao comando Processar .

Quando ligações fora de linha são especificadas num comando, elas sobrepõem as ligações inline contidas no DDL persistente para os objetos especificados. Estes objetos processados podem incluir o objeto diretamente nomeado no comando Processar , ou podem incluir outros objetos cujo processamento é automaticamente iniciado como parte do processamento.

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

Todos os elementos relacionados com ligações fora de linha são opcionais. Para quaisquer elementos não especificados, o ASSL utiliza a especificação contida no DDL do objeto persistido. A especificação de DataSource ou DataSourceView no comando Process é opcional. Se DataSource ou DataSourceView forem especificados, eles não são instanciados nem persistem após o comando Process ser concluído.

Definição do Tipo de Ligação Fora de Linha

Dentro da coleção de Bindings fora de linha, o ASSL permite uma coleção de bindings para múltiplos objetos, cada um um Binding. Cada Binding tem uma referência de objeto estendida, que é semelhante à referência de objeto, mas também pode referir-se a objetos menores (por exemplo, atributos de dimensão e atributos de grupo de medida). Este objeto assume a forma plana típica do elemento Objeto nos comandos Processo, exceto que as < etiquetas Objecto></Objeto> não estão presentes.

Cada objeto para o qual a ligaçã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 forma <ID do objeto>, em seguida, identifica o elemento para o qual a ligação está a ser especificada, que normalmente é Fonte. Um caso comum a notar é aquele em que Source é uma propriedade no DataItem, o que acontece com associações de colunas num atributo. Neste caso, não especifica o DataItem tag; em vez disso, simplesmente especifica a propriedade Source, como se estivesse diretamente na coluna a ser vinculada.

As KeyColumns são identificadas pela sua ordem dentro da coleção KeyColumns . Aí não é possível especificar, por exemplo, apenas a primeira e terceira colunas-chave de um atributo, porque não há forma de indicar que a segunda coluna chave deve ser ignorada. Todas as colunas-chave devem estar presentes na ligação fora de linha para um atributo de dimensão.

As traduções, embora não tenham identificação, são identificadas semanticamente pela sua língua. Por isso, as Traduções dentro de uma Ligação precisam de incluir o seu identificador linguístico.

Um elemento adicional permitido numa Binding, que não existe diretamente na DDL, é ParentColumnID, que é usado para tabelas aninhadas na mineração de dados. Neste caso, é necessário identificar a coluna principal na tabela aninhada para a qual a ligação está a ser fornecida.