Vue d'ensemble de l'architecture logique (Analysis Services - données multidimensionnelles)

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Analysis Services s'exécute en mode de déploiement du serveur qui détermine l'architecture de la mémoire et l'environnement d'exécution utilisés par différents types de modèles Analysis Services. Le mode serveur est déterminé lors de l'installation. Le mode multidimensionnel et d’exploration de données prend en charge olAP traditionnel et l’exploration de données. Le mode tabulaire prend en charge les modèles tabulaires. Le mode intégré SharePoint fait référence à un instance d’Analysis Services qui a été installé en tant que Power Pivot pour SharePoint, utilisé pour charger et interroger des modèles de données Excel ou Power Pivot à l’intérieur d’un classeur.

Cette rubrique explique l'architecture de base d'Analysis Services lors de l'exploitation en mode multidimensionnel et d'exploration de données. Pour plus d’informations sur les autres modes, consultez Modélisation tabulaire et comparaison des solutions tabulaires et multidimensionnelles.

Architecture de base

Une instance de SQL Server Analysis Services peut contenir plusieurs bases de données, et une base de données peut avoir des objets OLAP et des objets d’exploration de données en même temps. Les applications se connectent à une instance spécifiée de SQL Server Analysis Services et à une base de données spécifiée. Un ordinateur serveur peut héberger plusieurs instances de SQL Server Analysis Services. Les instances de SQL Server Analysis Services sont nommées «< ServerName>\<InstanceName> ». L’illustration suivante montre toutes les relations mentionnées entre les objets SQL Server Analysis Services.

Les classes Basic sont le jeu minimum d'objets requis pour générer un cube. Ce jeu minimum d'objets est une dimension, un groupe de mesures et une partition. L'agrégation est facultative.

Les dimensions sont construites à partir d'attributs et de hiérarchies. Les hiérarchies sont formées par un jeu ordonné d'attributs, où chaque attribut du jeu correspond à un niveau dans la hiérarchie.

Les cubes sont construits à partir de dimensions et de groupes de mesures. Les dimensions dans la collection de dimensions d'un cube appartiennent à la collection de dimensions de la base de données. Les groupes de mesures sont des collections de mesures qui ont la même vue de source de données et ont le même sous-ensemble de dimensions du cube. Un groupe de mesures dispose d'une ou de plusieurs partitions pour gérer les données physiques. Un groupe de mesures peut avoir une conception d'agrégation par défaut. La conception d'agrégation par défaut peut être utilisée par toutes les partitions dans le groupe de mesures ; de plus, chaque partition peut avoir sa propre conception d'agrégation.

Objets Server
Chaque instance de SQL Server Analysis Services est considéré comme un objet serveur différent dans AMO ; chaque instance est connecté à un Server objet par une connexion différente. Chaque objet serveur contient une ou plusieurs sources de données, vues de source de données et objets de base de données, ainsi qu'assemblys et rôles de sécurité.

Objets Dimension
Chaque objet de base de données contient plusieurs objets de dimension. Chaque objet de dimension contient un ou plusieurs attributs, organisés en hiérarchies.

Objets de cube
Chaque objet de base de données contient un ou plusieurs objets de cube. Un cube est défini par ses mesures et ses dimensions. Les mesures et les dimensions d'un cube sont dérivées des tables et des vues de la vue de source de données sur laquelle est basé le cube ou qui est générée à partir des définitions des mesures et des dimensions.

Héritage d'objet

Le modèle objet ASSL contient de nombreux groupes d'éléments répétés. Par exemple, le groupe d’éléments « Les dimensions contiennent des hiérarchies » définit la hiérarchie de dimension d’un élément. Cubes et MeasureGroups contiennent le groupe d’éléments « Les dimensions contiennent des hiérarchies ».

Sauf en cas de remplacement explicite, un élément hérite les détails de ces groupes d'éléments répétés du niveau supérieur. Par exemple, les traductions pour un CubeDimension sont les mêmes que les traductions de son élément ancêtre, Cube.

Pour remplacer explicitement des propriétés héritées d'un objet de niveau supérieur, un objet n'a pas besoin de répéter explicitement la totalité de la structure et des propriétés de l'objet de niveau supérieur. Les seules propriétés qu'un objet doit déclarer explicitement sont les propriétés que l'objet souhaite remplacer. Par exemple, un CubeDimension peut répertorier uniquement les hiérarchies qui doivent être désactivées dans le cube, ou pour lesquelles la visibilité doit être modifiée, ou pour lesquelles certains détails de niveau n’ont pas été fournis au niveau dimension .

Quelques propriétés spécifiées sur un objet fournissent des valeurs par défaut pour la même propriété sur un objet enfant ou descendant. Par exemple, Cube.StorageMode fournit la valeur par défaut pour Partition.StorageMode. Pour les valeurs par défaut héritées, ASSL applique les règles suivantes :

• Lorsque la propriété de l'objet enfant est NULL dans XML, la valeur de la propriété a comme valeur par défaut la valeur héritée. Toutefois, si vous interrogez le serveur à propos de la valeur, le serveur renvoie la valeur NULL de l'élément XML.

• Il n'est pas possible de déterminer par programme si la propriété d'un objet enfant a été définie directement sur l'objet enfant ou héritée.

Exemple

Le cube Imports contient deux mesures, Packages et Last, ainsi que trois dimensions connexes, Route, Source et Time.

Les petites valeurs alphanumériques autour du cube représentent les membres des dimensions. Les membres sont par exemple ground (membre de la dimension Route), Africa (membre de la dimension Source) et 1st quarter (membre de la dimension Time).

Mesures

Les valeurs dans les cellules de cube représentent les deux mesures, Packages et Last. La mesure Packages représente le nombre de packages importés et la fonction Somme est utilisée pour agréger les faits. La dernière mesure représente la date de réception, et la fonction Max est utilisée pour agréger les faits.

Dimensions

La dimension Route représente le mode de transport par lequel les importations arrivent à destination. Les membres de cette dimension sont notamment ground, nonground, air, sea, road ou rail. La dimension Source représente les lieux de production des biens importés, par exemple Africa ou Asia. La dimension Time représente les trimestres et les semestres d'une année.

Agrégats

Les utilisateurs professionnels d’un cube peuvent déterminer la valeur de n’importe quelle mesure pour chaque membre de chaque dimension, quel que soit le niveau du membre dans la dimension, car SQL Server Analysis Services agrège les valeurs aux niveaux supérieurs si nécessaire. Par exemple, les valeurs de mesure de l’illustration précédente peuvent être agrégées en fonction d’une hiérarchie de calendrier standard à l’aide de la hiérarchie d’heure du calendrier dans la dimension Time, comme illustré dans le diagramme suivant.

Outre l'agrégation au sein d'une même dimension, les mesures peuvent faire l'objet d'une agrégation combinant un nombre de membres appartenant à différentes dimensions. Cela permet aux utilisateurs professionnels d'évaluer les mesures dans plusieurs dimensions en même temps. Par exemple, si un utilisateur professionnel souhaite analyser les importations trimestrielles arrivées par voie aérienne en provenance des hémisphères Est (Eastern Hemisphere) et Ouest (Western Hemisphere), il peut exécuter une requête sur le cube pour extraire le dataset suivant.

Packages | Délai | Toutes les sources | Hémisphère Est | Hémisphère Occidental | | ---------- | ----------- | ------------------ | ------------------ |
|Toutes les heures|25110|6547|18563|
|1er semestre|11173|2977|8196|
|1er trimestre|5108|1452|3656|
|2e trimestre|6065|1525|4540|28-99 juin |20-99 juin |28-99 juin |
|2e moitié|13937|3570|10367|Déc-29-99|Déc-22-99|Déc-29-99|
|3ème trimestre|6119|1444|4675|Sept-30-99|Sept-18-99|Sept-30-99|
|4e trimestre|7818|2126|5692|Déc-29-99|Déc-22-99|Déc-29-99|

Dernier | Délai | Toutes les sources | Hémisphère Est | Hémisphère Occidental | | ---------- | ----------- | ------------------ | ------------------ | |Tout le temps|Déc-29-99|Déc-22-99|Déc-29-99|
|1er semestre|28-99 juin |20-99 juin |28-99 juin |
|1er trimestre|30-99 mars |19-99 mars |30-99 mars |
|2ème trimestre|28-99 juin |20-99 juin |28-99 juin |
|2e moitié|Déc-29-99|Déc-22-99|Déc-29-99|
|3ème trimestre|Sept-30-99|Sept-18-99|Sept-30-99|
|4ème trimestre|Déc-29-99|Déc-22-99|Déc-29-99|

Après la création d'un cube, il est possible de définir de nouvelles agrégations ou de modifier les agrégations existantes pour définir des options qui déterminent si les agrégations sont précalculées durant le traitement ou calculées lors de l'exécution des requêtes. Rubrique connexe :Agrégations et conceptions d’agrégation.

Mappage de mesures, d'attributs et de hiérarchies

Les mesures, les attributs et les hiérarchies dans l'exemple de cube sont dérivés des colonnes suivantes des tables de faits et de dimension du cube.

Les données d'une cellule de cube proviennent généralement de plusieurs lignes de la table de faits. Par exemple, la cellule de cube à l’intersection du membre air, du membre Afrique et du membre du 1er trimestre contient une valeur dérivée en agrégeant les lignes suivantes dans la table de faits ImportsFactTable .

Dans le tableau précédent, chaque ligne a les mêmes valeurs pour les colonnes RouteKey, SourceKey et TimeKey , ce qui indique que ces lignes contribuent à la même cellule de cube.

L'exemple présenté ici concerne un cube très simple, qui n'a qu'un seul groupe de mesures et auquel toutes les tables de dimension sont jointes à la table de faits dans un schéma en étoile. Dans un autre schéma commun, appelé schéma en flocons, une ou plusieurs tables de dimension sont jointes à une autre table de dimension au lieu d'être jointes directement à la table de faits. Rubrique connexe :Dimensions (Analysis Services - Données multidimensionnelles).

L'exemple présenté ici ne contient qu'une seule table de faits. Quand un cube a plusieurs tables de faits, les mesures de chaque table de faits sont organisées en groupes de mesures et un groupe de mesures est lié à un jeu de dimensions spécifique par des relations de dimension définies. Ces relations sont définies en spécifiant les tables participantes dans la vue de source de données et la granularité de la relation. Rubrique connexe :Relations de dimension.

Voir aussi

Bases de données de modèle multidimensionnel