La réponse est: oui, mais.
Une dimension dans SSAS a des relations entre les attributs qui peuvent être utilisés une série de champs à filtrer par tranche. Ces relations peuvent être hiérarchiques (plus d'un niveau - un attribut peut avoir un parent et des enfants.) Vous pouvez également établir des chemins d'accès (appelés hiérarchies dans SSAS) qui agissent comme des attributs mais avec une exploration guidée. pour ce faire, vous devez avoir des clés disponibles dans la base de données qui vivent dans une relation strictement hiérarchique (ie les clés ne peuvent pas avoir de relations floues où un enfant peut avoir plus d'un parent) Notez que ce n'est pas toute l'histoire
Ces hiérarchies peuvent être construites à partir d'une structure de données plane par le système ou présentées à travers un flocon de neige avec des relations balisées dans la vue de source de données sous-jacente (les DSV font partie des métadonnées du cube). et peut être utilisé pour masser les données d'une manière similaire aux vues de base de données). Un flocon de neige est un schéma 3NF-ish (il ne doit pas nécessairement être 3NF - vous pouvez en aplatir des parties) qui n'a que des relations 1: M. SSAS peut prendre en charge d'autres structures de dimension telles que parent-enfant (relation parent-enfant avec une auto-jointure récursive) et M: M dimensions (relations M: M - exactement à quoi elles ressemblent). Les dimensions de ce type sont plus délicates mais peuvent vous être utiles. Si vous avez des clés dans vos données source qui peuvent avoir une sémantique de données équivalente à un flocon de neige, alors vous pouvez remplir votre cube via une série de vues de base de données sur votre système source qui présentent les données sous-jacentes dans un flocon de neige suffisant. comme le format à utiliser pour les dimensions de cube (j'ai déjà fait cela à quelques reprises). Les schémas qui font un usage intensif des clés synthétiques sont plus susceptibles de bien fonctionner pour cela.
Si votre fournisseur ou d'autres parties ne vous permettent pas d'ajouter des vues à votre base de données source, vous pouvez utiliser une vue de source de données à la place. DSV peut avoir des tables virtuelles appelées «requêtes nommées» qui sont remplies à partir d'une requête de base de données.
Les tables de faits se joignent aux dimensions. Dans SSAS2005 +, vous pouvez joindre différentes tables de faits à différents grains dans une dimension. Normalement, je n'en aurais pas beaucoup besoin dans un entrepôt de données, mais cette fonctionnalité pourrait être utile si vous essayez d'utiliser les données source sans avoir à les masser trop fortement.
Si cela ne fonctionne pas, vous devrez peut-être écrire un processus ETL pour remplir un schéma en étoile ou en flocon de neige.
Quelques: réserves
cubes peuvent être faits pour fonctionner en mode temps réel où ils émettent juste une requête aux données sous-jacentes. Cela risque de créer des requêtes inefficaces sur vos données sources. Il n'est donc pas recommandé, sauf si vous êtes vraiment sûr de savoir ce que vous faites. À propos de (i), vous ne pourrez probablement pas utiliser les cubes comme source de données pour les écrans de votre application. Si vous devez calculer des moyennes pour quelque chose que l'utilisateur veut voir sur un écran, vous devrez probablement le calculer dans une procédure stockée derrière l'écran. Si vous faites cela, configurez une base de données répliquée et remplissez le cube à partir de cette base de données. Faites régulièrement actualiser cette base de données pour que votre processus ETL puisse s'exécuter à partir d'un ensemble de données cohérent en interne. Si vous exécutez à partir d'une base de données active, vous risquez de remplir ultérieurement certains éléments qui dépendent des enregistrements créés après l'exécution du processus correspondant.
Vous pouvez avoir la situation où vous exécutez un chargement de dimension, puis de nouvelles données sont entrées dans le système. Lorsque le chargement de la table des faits est exécuté, il contient désormais des données dépendantes des données de dimension qui n'ont pas été chargées. Cela va casser le cube et provoquer l'échec du processus de chargement. L'actualisation par lots d'une base de données répliquée pour exécuter les chargements ETL ou de cube atténuera ce problème.
Si vous ne disposez pas de l'option d'une base de données répliquée, vous pouvez configurer davantage de stratégies de relâchement pour les données manquantes.
Si vos données de production sous-jacentes présentent des problèmes significatifs de qualité des données, elles apparaîtront dans les cubes. GIGO.