Tabelas aninhadas (Analysis Services – Mineração de Dados)

No SQL Server Analysis Services, os dados devem ser alimentados para um algoritmo de mineração de dados como uma série de casos contidos em uma tabela de casos. No entanto, nem todos os casos podem ser descritos por uma única linha de dados. Por exemplo, um caso pode ser derivado de duas tabelas: uma tabela que contém informações do cliente e outra tabela que contém compras de clientes. Um único cliente na tabela de informações do cliente pode ter vários itens na tabela de compras do cliente, o que dificulta a descrição dos dados usando uma única linha. O Analysis Services fornece um método exclusivo para lidar com esses casos usando tabelas aninhadas. O conceito de uma tabela aninhada é demonstrado na ilustração a seguir.

Neste diagrama, a primeira tabela, que é a tabela pai, contém informações sobre clientes e associa um identificador exclusivo para cada cliente. A segunda tabela, a tabela filho, contém as compras para cada cliente. As compras na tabela filha estão relacionadas à tabela mãe por meio do identificador único, que é a coluna CustomerKey. A terceira tabela no diagrama mostra as duas tabelas combinadas.

Uma tabela aninhada é representada na tabela de casos como uma coluna especial que tem um tipo de dados table. Para qualquer linha de caso específica, esse tipo de coluna contém linhas selecionadas da tabela filho que pertencem à tabela pai.

Os dados em uma tabela aninhada podem ser usados para previsão ou para entrada ou para ambos. Por exemplo, você pode ter duas colunas de tabela aninhadas em um modelo: uma coluna de tabela aninhada pode conter uma lista dos produtos que um cliente comprou, enquanto a outra coluna de tabela aninhada contém informações sobre os hobbies e interesses do cliente, possivelmente obtidos de uma pesquisa. Nesse cenário, você pode usar os hobbies e interesses do cliente como entrada para analisar o comportamento de compra e prever compras prováveis.

Junção de tabelas de casos e tabelas aninhadas

Para criar uma tabela aninhada, as duas tabelas de origem devem conter uma relação definida para que os itens em uma tabela possam estar relacionados à outra tabela. No SSDT (SQL Server Data Tools), você pode definir essa relação na exibição da fonte de dados.

Observação

O campo CustomerKey é a chave relacional usada para vincular a tabela de maiúsculas e minúsculas e a tabela aninhada dentro da definição de exibição da fonte de dados e estabelecer a relação das colunas dentro da estrutura de mineração. No entanto, normalmente, você não deve usar essa chave relacional em modelos de mineração criados nessa estrutura. Normalmente, é melhor omitir a coluna de chave relacional do modelo de mineração se ela servir apenas para unir as tabelas e não fornecer informações interessantes para análise.

Você pode criar tabelas aninhadas programaticamente usando DMX (Extensões de Mineração de Dados) ou AMO (Objetos de Gerenciamento de Análise) ou pode usar o Assistente de Mineração de Dados e o Designer de Mineração de Dados no SSDT (SQL Server Data Tools).

Usando colunas de tabela aninhadas em um modelo de mineração

Na tabela de casos, a chave geralmente é uma ID do cliente, um nome de produto ou uma data em uma série: dados que identificam exclusivamente uma linha na tabela. . No entanto, em tabelas aninhadas, a chave normalmente não é a chave relacional (ou chave estrangeira), mas sim a coluna que representa o atributo que você está modelando.

Por exemplo, se a tabela de maiúsculas e minúsculas contiver pedidos e a tabela aninhada contiver itens na ordem, você estará interessado em modelar a relação entre os itens armazenados na tabela aninhada em vários pedidos, que são armazenados na tabela de casos. Portanto, embora a tabela aninhada Itens seja ligada à tabela de casos Orders pela chave relacional OrderID, você não deve usar OrderID como a chave da tabela aninhada. Em vez disso, você selecionaria a coluna Itens como a chave de tabela aninhada, pois essa coluna contém os dados que você deseja modelar. Na maioria das vezes, você pode ignorar OrderID com segurança no modelo de mineração, pois a relação entre a tabela de casos e a tabela aninhada já foi estabelecida pela definição da visão da fonte de dados.

Ao escolher uma coluna para usar como a chave de tabela aninhada, certifique-se de que os valores nessa coluna sejam únicos para cada caso. Por exemplo, se a tabela de casos representar clientes e a tabela aninhada representar itens comprados pelo cliente, você deverá assegurar que nenhum item seja listado mais de uma vez por cliente. Se um cliente tiver comprado o mesmo item mais de uma vez, talvez você queira criar uma exibição diferente que tenha uma coluna que agrega a contagem de compras para cada produto exclusivo.

A forma como você decide lidar com valores duplicados em uma tabela aninhada depende do modelo de mineração que você está criando e do problema de negócios que você está resolvendo. Em alguns cenários, talvez você não se importe com quantas vezes um cliente comprou um produto específico, mas deseja verificar a existência de pelo menos uma compra. Em outros cenários, a quantidade e a sequência de compras podem ser muito importantes.

Se a ordem dos itens for importante, talvez você precise de uma coluna adicional que indique a sequência. Ao usar o algoritmo de clustering de sequência para criar um modelo, você deve escolher uma coluna de sequência de chaves adicional para representar a ordem dos itens. A coluna de sequência de chaves é um tipo especial de chave aninhada que é utilizada exclusivamente em modelos de agrupamento sequencial e requer um tipo de dado numérico único. Por exemplo, inteiros e datas podem ser usados como uma coluna de sequência de chaves, mas todos os valores de sequência devem ser exclusivos. Além da coluna de sequência de chaves, um modelo de clustering de sequência também tem uma chave de tabela aninhada que representa o atributo que está sendo modelado, como os produtos que foram comprados.

Usando colunas aninhadas não chave de uma tabela aninhada

Depois de definir a junção entre a tabela de casos e a tabela aninhada, e escolher uma coluna que contenha atributos interessantes e exclusivos que a serem usada como a chave de tabela aninhada, você poderá incluir outras colunas da tabela aninhada a serem usadas como entrada para o modelo. Todas as colunas da tabela aninhada podem ser usadas para entrada e previsão ou apenas para previsão.

Por exemplo, se a tabela aninhada contiver as colunas Product, ProductQuantity e ProductPrice, você poderá escolher Product como a chave de tabela aninhada, mas adicionar ProductQuantity à estrutura de mineração a ser usada como entrada.

Filtrando dados de tabelas aninhadas

No SQL Server 2014, você pode criar filtros nos dados usados para treinar ou testar um modelo de mineração de dados. Um arquivador pode ser usado para afetar a composição do modelo ou testar o modelo em um subconjunto de casos. Os filtros também podem ser aplicados a tabelas aninhadas. No entanto, há limitações na sintaxe que podem ser usadas para tabelas aninhadas.

Geralmente, quando você aplica um filtro a uma tabela aninhada, você está testando a existência ou a não existência de um atributo. Por exemplo, você pode aplicar um filtro que restringe os casos usados no modelo somente aos casos que têm um valor especificado na tabela aninhada. Ou você pode restringir os casos usados no modelo a clientes que não compraram um item específico.

Ao criar filtros em uma tabela aninhada, você também pode usar operadores como maior que ou menor que. Por exemplo, você pode restringir os casos usados no modelo aos clientes que compraram pelo menos n unidades do produto de destino. A capacidade de filtrar por atributos de tabelas aninhadas oferece grande flexibilidade para personalizar modelos.

Para obter mais informações sobre como criar e usar filtros de modelo, consulte Filtros para Modelos de Mineração (Analysis Services – Mineração de Dados).

Consulte Também

Algoritmos de mineração de dados (Analysis Services – Mineração de Dados)
Estruturas de mineração (Analysis Services – Mineração de dados)