Utilisation de vues dans un entrepôt de données

J'ai récemment hérité d'un entrepôt qui utilise des vues pour résumer des données, ma question est la suivante: les vues sont-elles une bonne pratique, ou la meilleure approche? J'avais l'intention d'utiliser des cubes pour agréger les requêtes multidimensionnelles.

Désolé si cela pose une question de base, je ne suis pas expérimenté avec les services d'entrepôt et d'parsing

Merci

Analysis Services et Views ont la différence fondamentale qu'ils seront utilisés par différents outils de reporting ou d'parsing.

Si vous avez des rapports basés sur SQL (par exemple, via Reporting Services ou Crystal Reports), les vues peuvent être utiles pour ceux-ci. Les vues peuvent également être matérialisées (elles sont appelées vues indexées sur SQL Server). Dans ce cas, ils sont conservés sur le disque et peuvent être utilisés pour réduire les E / S nécessaires pour effectuer une requête sur la vue. Une requête sur une vue non matérialisée continuera à toucher les tables sous-jacentes.

Souvent, les vues sont utilisées à des fins de security ou de simplicité (c'est-à-dire pour encapsuler la logique métier ou les calculs dans quelque chose de simple à interroger). Pour des raisons de security, ils peuvent restreindre l'access aux données sensibles en filtrant (en restreignant les lignes disponibles) ou en masquant les champs sensibles de la table sous-jacente.

Analysis Services utilise différents outils de génération de requêtes et de génération de rapports et pré-calcule et stocke datatables agrégées. L'interface avec le server étant différente de SQL Server, les outils de création de rapports ou de requête pour un cube (par exemple ProClarity) sont différents des outils de reporting d'une database (bien que certains systèmes aient la possibilité d'interroger).

Les cubes constituent une bien meilleure approche pour résumer datatables et effectuer une parsing multidimensionnelle.

Le problème avec les vues est double: mauvaises performances (toutes ces jointures et tous les byets de groupe), et impossibilité de découper et de découper datatables par l'user.

Dans mes projets, j'utilise des vues «stupides» comme une couche supplémentaire entre le datawarehouse et les cubes (mes dimensions et groupes de mesures sont basés sur des vues), car cela me permet une plus grande flexibilité.

Les vues sont utiles à des fins de security telles que restreindre / contrôler / normaliser l'access aux données.

Ils peuvent également être utilisés pour implémenter des implémentations de partitionnement de table personnalisées et des deployments de database fédérée.

Si la fonction des vues dans votre database est de faciliter le calcul des mésortingques ou des statistics, alors vous bénéficierez certainement d'une implémentation plus appropriée, telle que celle disponible via une solution d'entrepôt de données.

J'étais dans le même bateau il y a quelques années. Dans mon cas, j'avais access à un autre server SQL. Sur le second server, j'ai créé un server de liens vers l'entrepôt, puis créé mes vues et mes vues matérialisées sur le second server. Dans un sens, j'avais un entrepôt de données et un entrepôt de rapports. Pour le projet, cette approche a été la plus efficace car nous étions tenus de donner access aux données à d'autres départements et à certains fournisseurs. La division des servers en deux instances distinctes, l'une pour l'entreposage et l'autre pour les rapports, a également atténué certains des risques liés à l'access sécurisé.