Sources de données et liaisons (SSAS multidimensionnel)

Les cubes, dimensions et autres objets Analysis Services peuvent être liés à une source de données. Une source de données peut être l’un des objets suivants :

• Source de données relationnelle.

• Un pipeline de services d'analyse qui génère un ensemble de lignes (ou des ensembles de lignes chapitrées).

Les moyens d’exprimer la source de données varient selon le type de source de données. Par exemple, une source de données relationnelle est distinguée par la chaîne de connexion. Pour plus d’informations sur les sources de données, consultez Sources de données dans les modèles multidimensionnels.

Quelle que soit la source de données utilisée, la vue de source de données (DSV) contient les métadonnées de la source de données. Ainsi, les liaisons d'un cube ou d'autres objets Analysis Services sont définies par les liaisons au DSV. Ces liaisons peuvent inclure des liaisons à des objets logiques tels que des vues, des colonnes calculées et des relations qui n’existent pas physiquement dans la source de données. Analysis Services ajoute une colonne calculée qui encapsule l’expression à la vue DSV, puis lie la mesure OLAP correspondante à cette colonne dans la vue DSV. Pour plus d’informations sur les vues de source de données, consultez Vues de source de données dans les modèles multidimensionnels.

Chaque objet Analysis Services est lié à la source de données de sa propre manière. En outre, les liaisons de données pour ces objets et la définition de la source de données peuvent être fournies inline avec la définition de l’objet de trafic de données (par exemple, la dimension) ou hors ligne sous la forme d’un ensemble distinct de définitions.

Types de données des Analysis Services

Les types de données utilisés dans les liaisons doivent correspondre aux types de données pris en charge par Analysis Services. Les types de données suivants sont définis dans Analysis Services :

Toutes les données reçues de la source de données sont converties en type SSAS spécifié dans la liaison (généralement pendant le traitement). Une erreur est générée si la conversion ne peut pas être effectuée (par exemple, String to Int). SQL Server Data Tools (SSDT) définit généralement le type de données dans la liaison à celui qui correspond le mieux au type source dans la source de données. Par exemple, les types SQL Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset sont mappés à SSAS Date et l’heure du type SQL est mappée à String.

Liaisons pour les dimensions

Chaque attribut d’une dimension est lié à une colonne dans une vue DSV. Tous les attributs d’une dimension doivent provenir d’une seule source de données. Toutefois, les attributs peuvent être liés à des colonnes dans différentes tables. Les relations entre les tables sont définies dans la vue DSV. Dans le cas où plusieurs ensembles de relations existent dans la même table, il peut être nécessaire d’introduire une requête nommée dans la DSV pour agir en tant que table « alias ». Les expressions et les filtres sont définis dans la vue DSV à l’aide de calculs nommés et de requêtes nommées.

Liaisons pour les groupes de mesures, les mesures et les partitions

Chaque groupe de mesures a les liaisons par défaut suivantes :

• Le groupe de mesures est lié à une table dans un DSV (par exemple, MeasureGroup.Source).

• Chaque mesure est liée à une colonne de cette table (par exemple, Measure.ValueColumn.Source).

• Chaque dimension de groupe de mesures a un ensemble d’attributs de granularité qui définissent la granularité du groupe de mesures. Chacun de ces attributs doit être lié à la colonne ou aux colonnes de la table de faits qui contiennent la clé d’attribut. (Pour plus d’informations sur les attributs de granularité, consultez Attributs de granularité MeasureGroup plus loin dans cette rubrique.)

Ces liaisons par défaut peuvent être remplacées de manière sélective par partition. Chaque partition peut spécifier une source de données, une table ou un nom de requête différent ou une expression de filtre. La stratégie de partitionnement la plus courante consiste à remplacer la table par partition, à l’aide de la même source de données. Les alternatives incluent l’application d’un filtre différent par partition ou la modification de la source de données.

La source de données par défaut doit être définie dans la vue DSV, fournissant ainsi les informations de schéma, y compris les détails des relations. Les tables ou requêtes supplémentaires spécifiées au niveau de la partition n’ont pas besoin d’être répertoriées dans la vue DSV, mais elles doivent avoir le même schéma que la table par défaut définie pour le groupe de mesures, ou au moins elles doivent contenir toutes les colonnes utilisées par les mesures ou les attributs de granularité. Les liaisons détaillées par mesure et attribut de granularité ne peuvent pas être substituées au niveau de la partition, et elles sont supposées correspondre aux mêmes colonnes que celles définies pour le groupe de mesures. Par conséquent, si la partition utilise une source de données qui a en fait un schéma différent, la TableDefinition requête définie pour la partition doit entraîner le même schéma que le schéma utilisé par le groupe de mesures.

Attributs de granularité du groupe de mesure

Lorsque la granularité d’un groupe de mesures correspond à la granularité connue dans la base de données et qu’il existe une relation directe entre la table de faits et la table de dimensions, l’attribut de granularité doit uniquement être lié à la colonne ou colonnes de clé étrangère appropriée sur la table de faits. Par exemple, tenez compte des tables de faits et de dimension suivantes :

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

Si vous analysez par le produit commandé, pour le rôle de dimension Produit sur Ventes, l'attribut de granularité de produit est lié à Sales.OrderedProductID.

Toutefois, il peut arriver que l’GranularityAttributes ne soit pas présent en tant que colonnes dans la table de faits. Par exemple, les colonnes GranularityAttributes peuvent ne pas exister dans les circonstances suivantes :

• La granularité OLAP est plus grossière que la granularité dans la source.

• Une table intermédiaire interpose entre la table de faits et la table de dimension.

• La clé de dimension n’est pas la même que la clé primaire dans la table de dimension.

Dans tous ces cas, la DSV doit être définie afin que les Attributs de Granularité existent sur la table de faits. Par exemple, une requête nommée ou une colonne calculée peut être introduite.

Par exemple, dans les mêmes exemples de tables que ci-dessus, si la granularité était par Catégorie, une vue des ventes peut être introduite :

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

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

Dans ce cas, la catégorie GranularityAttribute est liée à SalesWithCategory.OrderedProductCategory.

Migration à partir d’objets de prise de décision

Decision Support Objects (DSO) 8.0 permet PartitionMeasures de rebondir. Par conséquent, la stratégie de migration dans ces cas consiste à construire la requête appropriée.

De même, il n’est pas possible de rebiner les attributs de dimension dans une partition, bien que DSO 8.0 autorise également cette liaison. Dans ces cas, la stratégie de migration consiste à définir les requêtes nommées nécessaires dans la vue DSV afin que les mêmes tables et colonnes existent dans la DSV pour la partition que les tables et colonnes utilisées pour la dimension. Ces cas peuvent nécessiter l’adoption de la migration simple, dans laquelle la clause From/Join/Filter est mappée à une requête nommée unique plutôt qu’à un ensemble structuré de tables associées. Comme DSO 8.0 permet de réassigner PartitionDimensions même lorsque la partition utilise la même source de données, la migration peut également nécessiter plusieurs DSV pour la même source de données.

Dans DSO 8.0, les liaisons correspondantes peuvent être exprimées de deux façons différentes, selon que les schémas optimisés sont utilisés, en liant la clé primaire de la table de dimension ou la clé étrangère de la table de faits. Dans ASSL, les deux formes différentes ne sont pas distinguées.

La même approche des liaisons s’applique même pour une partition à l’aide d’une source de données qui ne contient pas les tables de dimension, car la liaison est faite à la colonne clé étrangère de la table de faits, et non à la colonne clé primaire de la table de dimension.

Liaisons pour les modèles d’exploration de données

Un modèle d’exploration de données est relationnel ou OLAP. Les liaisons de données pour un modèle d’exploration de données relationnelle sont considérablement différentes des liaisons d’un modèle d’exploration de données OLAP.

Liaisons pour un modèle d’exploration de données relationnelle

Un modèle d’exploration de données relationnelle s’appuie sur les relations définies dans la vue DSV pour résoudre toute ambiguïté concernant les colonnes liées aux sources de données. Dans un modèle d’exploration de données relationnelle, les liaisons de données suivent les règles suivantes :

• Chaque colonne de table non imbriquée est liée à une colonne dans la table des cas ou une table liée à la table des cas, selon une relation de plusieurs-à-un ou d'un-à-un. Le DSV définit les relations entre les tables.

• Chaque colonne de table imbriquée est liée à une table source. Les colonnes appartenant à la colonne de table imbriquée sont ensuite liées à des colonnes de cette table source ou à une table liée à la table source. (Là encore, la liaison suit une relation plusieurs-à-un ou un-à-un.) Les liaisons de modèle d’exploration des données ne fournissent pas le chemin de jointure à la table imbriquée. Au lieu de cela, les relations définies dans le DSV fournissent ces informations.

Liaisons pour un modèle d’exploration de données OLAP

Les modèles d’exploration de données OLAP n’ont pas l’équivalent d’une DSV. Par conséquent, les liaisons de données doivent fournir une clarification entre les colonnes et les sources de données. Par exemple, un modèle d’exploration de données peut être basé sur le cube Sales, et les colonnes peuvent être basées sur Qty, Amount et Product Name. Par ailleurs, un modèle d’exploration de données peut être basé sur Product, et les colonnes peuvent être basées sur Product Name, Product Color et une table imbriquée avec Sales Qty.

Dans un modèle d’exploration de données OLAP, les liaisons de données suivent les règles suivantes :

• Chaque colonne de table non imbriquée est liée à une mesure sur un cube multidimensionnel, à un attribut d'une dimension de ce cube (spécifiant la balise CubeDimension pour lever l’ambiguïté en cas de rôles de dimension) ou à un attribut d'une dimension.

• Chaque colonne de table imbriquée est liée à un CubeDimension. Autrement dit, il définit comment naviguer d’une dimension vers un cube associé ou (dans le cas moins courant des tables imbriquées) d’un cube à l’une de ses dimensions.

Liaisons hors ligne

Les liaisons hors ligne vous permettent de modifier temporairement les liaisons de données existantes pendant la durée d’une commande. Les liaisons hors ligne font référence à des liaisons incluses dans une commande et qui ne sont pas conservées. Les liaisons hors ligne s’appliquent uniquement lorsque cette commande particulière s’exécute. En revanche, les liaisons inline sont contenues dans la définition d’objet ASSL et persistent avec la définition d’objet dans les métadonnées du serveur.

ASSL permet aux liaisons hors ligne d’être spécifiées sur une Process commande, si elle n’est pas dans un lot ou sur une Batch commande. Si des liaisons hors ligne sont spécifiées sur la Batch commande, toutes les liaisons spécifiées dans la Batch commande créent un contexte de liaison dans lequel toutes les Process commandes du lot s’exécutent. Ce nouveau contexte de liaison inclut des objets qui sont indirectement traités en raison de la Process commande.

Lorsque des liaisons hors ligne sont spécifiées sur une commande, elles remplacent les liaisons inline contenues dans le DDL persistant pour les objets spécifiés. Ces objets traités peuvent inclure l’objet directement nommé dans la Process commande, ou ils peuvent inclure d’autres objets dont le traitement est lancé automatiquement dans le cadre du traitement.

Les liaisons hors ligne sont spécifiées en incluant l’objet de collection facultatif Bindings avec la commande de traitement. La collection facultative Bindings contient les éléments suivants.

Tous les éléments liés aux liaisons hors ligne sont facultatifs. Pour tous les éléments non spécifiés, ASSL utilise la spécification contenue dans la DDL de l’objet persistant. La spécification de DataSource ou de DataSourceView dans la commande Process est facultative. Si DataSource ou DataSourceView sont spécifiés, ils ne sont ni instanciés, ni conservés une fois la commande Process terminée.

Définition du type de liaison hors ligne

À l’intérieur de la collection hors ligne Bindings , ASSL permet une collection de liaisons pour plusieurs objets, chacune d’elles Binding. Chacun Binding possède une référence d’objet étendue, similaire à la référence d’objet, mais elle peut également faire référence à des objets mineurs (par exemple, attributs de dimension et attributs de groupe de mesures). Cet objet prend la forme plate typique de l’élément Object dans les commandes Process, sauf que les balises <Object></Object> ne sont pas présentes.

Chaque objet pour lequel la liaison est spécifiée est identifié par un élément XML de la forme <objet>ID (par exemple, DimensionID). Une fois que vous avez identifié l’objet aussi spécifiquement que possible avec le formulaire <objet> ID, vous identifiez l’élément pour lequel la liaison est spécifiée, qui est généralement Source. Un cas courant à noter est celui dans lequel Source est une propriété sur le DataItem, comme c'est le cas pour les liaisons de colonnes dans un attribut. Dans ce cas, vous ne spécifiez pas la DataItem balise ; au lieu de cela, vous spécifiez simplement la Source propriété, comme s’il était directement sur la colonne à lier.

KeyColumns sont identifiés par leur classement à l’intérieur de la KeyColumns collection. Il n’est pas possible de spécifier, par exemple, uniquement les premières et troisième colonnes clés d’un attribut, car il n’existe aucun moyen d’indiquer que la deuxième colonne clé doit être ignorée. Toutes les colonnes clés doivent être présentes dans la liaison hors ligne pour un attribut de dimension.

Translations, même s’ils n’ont pas d’ID, sont identifiés sémantiquement par leur langue. Par conséquent, le Translations à l'intérieur d'un Binding doit inclure son identificateur de langue.

Un élément supplémentaire autorisé dans un Binding qui n’existe pas directement dans la DDL est ParentColumnID, qui est utilisé pour les tables imbriquées dans l’exploration de données. Dans ce cas, il est nécessaire d’identifier la colonne parente dans la table imbriquée pour laquelle la liaison est fournie.