Tables imbriquées (Analysis Services - Exploration de données)

Dans SQL Server Analysis Services, les données doivent être transmises à un algorithme d’exploration de données sous la forme d’une série de cas contenus dans une table de cas. Toutefois, tous les cas ne peuvent pas être décrits par une seule ligne de données. Par exemple, un cas peut être dérivé de deux tables : une table qui contient des informations client et une autre table qui contient des achats client. Un client unique dans la table d’informations client peut avoir plusieurs éléments dans la table des achats client, ce qui rend difficile la description des données à l’aide d’une seule ligne. Analysis Services fournit une méthode unique pour gérer ces cas à l’aide de tables imbriquées. Le concept d’une table imbriquée est illustré dans l’illustration suivante.

Dans ce diagramme, la première table, qui est la table parente, contient des informations sur les clients et associe un identificateur unique pour chaque client. La deuxième table, la table enfant, contient les achats pour chaque client. Les achats dans la table enfant sont liés à la table parente par l’identificateur unique, la colonne CustomerKey . Le troisième tableau du diagramme montre les deux tables combinées.

Une table imbriquée est représentée dans la table de cas sous la forme d’une colonne spéciale qui a un type de données TABLE. Pour toute ligne de cas spécifique, ce type de colonne contient les lignes sélectionnées de la table enfant qui s'appliquent à la table parente.

Les données d’une table imbriquée peuvent être utilisées pour la prédiction ou pour l’entrée, ou pour les deux. Par exemple, vous pouvez avoir deux colonnes de table imbriquées dans un modèle : une colonne de table imbriquée peut contenir une liste des produits qu’un client a achetés, tandis que l’autre colonne de table imbriquée contient des informations sur les loisirs et les intérêts du client, éventuellement obtenues à partir d’une enquête. Dans ce scénario, vous pouvez utiliser les loisirs et les intérêts du client comme entrée pour analyser le comportement d’achat et prédire les achats probables.

Fusion de tables de cas et tables imbriquées

Pour créer une table imbriquée, les deux tables sources doivent contenir une relation définie afin que les éléments d’une table puissent être liés à l’autre table. Dans SQL Server Data Tools (SSDT), vous pouvez définir cette relation dans la vue de source de données.

Vous pouvez créer des tables imbriquées par programmation à l’aide d’extensions d’exploration de données (DMX) ou d’objets AMO (Analysis Management Objects), ou utiliser l’Assistant Exploration de données et le Concepteur d’exploration de données dans SQL Server Data Tools (SSDT).

Utilisation de colonnes de table imbriquées dans un modèle d’exploration de données

Dans la table de cas, la clé est souvent un ID client, un nom de produit ou une date dans une série : données qui identifient de manière unique une ligne dans la table. . Toutefois, dans les tables imbriquées, la clé n’est généralement pas la clé relationnelle (ou clé étrangère), mais plutôt la colonne qui représente l’attribut que vous modélisez.

Par exemple, si la table de cas contient des commandes et que la table imbriquée contient des éléments dans l’ordre, vous souhaitez modéliser la relation entre les éléments stockés dans la table imbriquée sur plusieurs commandes, qui sont stockées dans la table de cas. Par conséquent, bien que la table Items imbriquée soit jointe à la table des cas Orders par la clé relationnelle OrderID, vous ne devez pas utiliser OrderID comme clé de table imbriquée. Au lieu de cela, vous devez sélectionner la colonne Éléments comme clé de table imbriquée, car cette colonne contient les données que vous souhaitez modéliser. Dans la plupart des cas, vous pouvez ignorer en toute sécurité OrderID dans le modèle d’exploration de données, car la relation entre la table de cas et la table imbriquée a déjà été établie par la définition de la vue de source de données.

Lorsque vous choisissez une colonne à utiliser comme clé de table imbriquée, vous devez vous assurer que les valeurs de cette colonne sont uniques pour chaque cas. Par exemple, si la table de cas représente les clients et que la table imbriquée représente les éléments achetés par le client, vous devez vous assurer qu’aucun élément n’est répertorié plusieurs fois par client. Si un client a acheté le même article plusieurs fois, vous pouvez créer une vue différente qui a une colonne qui agrège le nombre d’achats pour chaque produit unique.

La façon dont vous décidez de gérer les valeurs en double dans une table imbriquée dépend du modèle d’exploration de données que vous créez et du problème métier que vous résolvez. Dans certains scénarios, vous pouvez ne pas vous soucier du nombre de fois où un client a acheté un produit particulier, mais vous souhaitez vérifier l’existence d’au moins un achat. Dans d’autres scénarios, la quantité et la séquence d’achats peuvent être très importantes.

Si l’ordre des éléments est important, vous devrez peut-être une colonne supplémentaire qui indique la séquence. Lorsque vous utilisez l’algorithme de clustering de séquence pour créer un modèle, vous devez choisir une colonne de séquence clé supplémentaire pour représenter l’ordre des éléments. La colonne de séquence de clés est un type spécial de clé imbriquée qui est utilisée uniquement dans les modèles de clustering de séquences et nécessite un type de données numérique unique. Par exemple, les entiers et les dates peuvent être utilisés comme colonne de séquence clé, mais toutes les valeurs de séquence doivent être uniques. En plus de la colonne de séquence de clés, un modèle de clustering de séquences a également une clé de table imbriquée qui représente l’attribut qui est modélisé, tel que les produits achetés.

Utilisation de colonnes imbriquées non clés à partir d’une table imbriquée

Une fois que vous avez défini la jointure entre la table de cas et la table imbriquée et que vous avez choisi une colonne qui contient des attributs intéressants et uniques à utiliser comme clé de table imbriquée, vous pouvez inclure d’autres colonnes de la table imbriquée à utiliser comme entrée dans le modèle. Toutes les colonnes de la table imbriquée peuvent être utilisées pour l’entrée et la prédiction, ou uniquement pour la prédiction.

Par exemple, si la table imbriquée contient les colonnes Product, ProductQuantity et ProductPrice, vous pouvez choisir Product comme clé de table imbriquée, mais ajoutez ProductQuantity à la structure d’exploration de données à utiliser comme entrée.

Filtrage des données de table imbriquées

Dans SQL Server 2014, vous pouvez créer des filtres sur les données utilisées pour entraîner ou tester un modèle d’exploration de données. Un filer peut être utilisé pour affecter la composition du modèle ou pour tester le modèle sur un sous-ensemble de cas. Les filtres peuvent également être appliqués aux tables imbriquées. Toutefois, il existe des limitations sur la syntaxe qui peut être utilisée avec des tables imbriquées.

Souvent, lorsque vous appliquez un filtre à une table imbriquée, vous testez l’existence ou l’absence d’un attribut. Par exemple, vous pouvez appliquer un filtre qui limite les cas utilisés dans le modèle uniquement aux cas qui ont une valeur spécifiée dans la table imbriquée. Vous pouvez également limiter les cas utilisés dans le modèle aux clients qui n’ont pas acheté d’article particulier.

Lorsque vous créez des filtres sur une table imbriquée, vous pouvez également utiliser des opérateurs tels que supérieurs ou inférieurs à. Par exemple, vous pouvez limiter les cas utilisés dans le modèle aux clients ayant acheté au moins n unités du produit cible. La possibilité de filtrer sur les attributs de table imbriqués offre une grande flexibilité pour la personnalisation des modèles.

Pour plus d’informations sur la création et l’utilisation de filtres de modèle, consultez Filtres pour les modèles d’exploration de données (Analysis Services - Exploration de données).

Voir aussi

Algorithmes d’exploration de données (Analysis Services - Exploration de données)
Structures d’exploration de données (Analysis Services - Exploration de données)