Quelle est la meilleure approche pour passer de la base de données OLTP relationnelle au cube OLAP?

Question

J'ai une base de données normalisée OLTP assez standard et je me suis rendu compte que je devais faire des requêtes complexes, des moyennes, des écarts types sur différentes dimensions des données.

Je me suis donc tourné vers SSAS et la création de cubes OLAP.

Cependant, pour créer les cubes, je pense que ma structure de source de données doit être dans une configuration "étoile" ou "flocon de neige" (ce qui, à mon avis, ne l’est pas maintenant).

La procédure normale consiste-t-elle à utiliser SSIS pour effectuer une sorte de processus ETL sur ma base de données OLTP principale dans une autre base de données relationnelle présentant la configuration "étoile" appropriée avec les faits et les dimensions, puis utiliser cette base de données comme source de données pour le Cubes OLAP?

Merci

Answer 1

Oui, c'est l'idée de base. Vous prenez votre base de données OLTP hautement normalisée et vous la dé-normalisez en cubes afin de découper et de découper en dés les données, puis de présenter des rapports à ce sujet. La technique de conception logique est appelée modélisation dimensionnelle. Il existe une tonne d'informations intéressantes sur la modélisation dimensionnelle au Groupe Kimball . livres sur le sujet de Ralph Kimball sont également excellents. Si vous souhaitez en savoir plus sur les outils de BI, consultez les laboratoires virtuels . sur SSIS, les services d’analyse et plus encore.

Answer 2

La réponse est: oui, mais.

Une dimension dans SSAS a des relations entre attributs qui peuvent être utilisés avec une série de champs pour filtrer les tranches. Ces relations peuvent être hiérarchiques (plusieurs niveaux de profondeur - un attribut peut avoir un parent et des enfants. Vous pouvez également établir des chemins d’exploration (appelés hiérarchies dans SSAS) qui agissent comme des attributs, mais qui ont une exploration guidée.

Pour ce faire, vous devez disposer de clés dans la base de données qui vivent dans une relation strictement hiérarchique (c’est-à-dire que les clés ne peuvent pas avoir de relations floues dans lesquelles un enfant peut avoir plusieurs parents). Notez que ce n’est pas toute l’histoire, mais qu’elle est assez proche de la réalité pour le moment.

Ces hiérarchies peuvent être construites à partir d’une structure de données plate par le système ou présentées dans un flocon de neige avec des relations marquées dans la vue de la source de données sous-jacente (les DSV font partie des métadonnées du cube et peuvent être utilisées pour traiter les données de manière plus transparente. similaire aux vues de base de données).

Un flocon de neige est un schéma 3NF-ish (il n’est pas obligatoire que ce soit 3NF - vous pouvez en aplatir certaines parties) qui n’a que des relations 1: M. SSAS peut prendre en charge quelques autres structures de dimension telles que les dimensions parent-enfant (relation parent-enfant avec une auto-jointure récursive) et M: M (relations M: M - exactement comme elles ressemblent). Les dimensions de ce type sont plus délicates mais peuvent vous être utiles.

Si vos données source contiennent des clés pouvant avoir une sémantique équivalente à celle d'un flocon, vous pourrez peut-être remplir votre cube par le biais d'une série de vues de base de données sur votre système source présentant les données sous-jacentes sous forme de flocon de neige suffisamment format à utiliser pour les dimensions de cube (je l’ai déjà fait à quelques reprises). Les schémas qui utilisent beaucoup de clés synthétiques sont plus susceptibles de fonctionner correctement pour cela.

Si votre fournisseur ou d'autres parties ne vous permettent pas d'ajouter des vues à votre base de données source, vous pourrez peut-être utiliser une vue de source de données. Les DSV peuvent 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 sont reliées à des dimensions. Dans SSAS2005 +, vous pouvez joindre différentes tables de faits à différents grains d’une dimension. Je n’aurais normalement pas beaucoup recours à cela dans un entrepôt de données, mais cette fonctionnalité pourrait être utile si vous essayez d’utiliser les données source sans trop les manipuler.

Si cela ne fonctionne pas, vous devrez peut-être écrire un processus ETL pour renseigner un schéma en étoile ou en flocon de neige.

Quelques réserves:

1. Les cubes peuvent être configurés pour s'exécuter en mode temps réel, en émettant simplement une requête sur les données sous-jacentes. Cela risquerait de créer des requêtes inefficaces sur vos données source. Il est donc déconseillé de le faire, à moins que vous ne soyez vraiment sûr de savoir ce que vous faites.

2. À 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 un élément que l'utilisateur souhaite voir sur un écran, vous devrez probablement le calculer dans une procédure stockée derrière l'écran.

3. Si vous procédez ainsi, configurez une base de données répliquée et renseignez le cube. Cette base de données doit être actualisée régulièrement afin 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 dynamique, vous risquez de voir certains des éléments ultérieurement renseignés qui dépendent des enregistrements créés après l'exécution du processus correspondant.
   
   Vous pouvez avoir le cas 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 de faits est exécuté, il contient désormais des données qui dépendent des données de dimension non chargées. Cela cassera le cube et entraînera l'échec du processus de chargement. L'actualisation par lots d'une base de données répliquée pour qu'elle exécute l'ETL ou atténue ce problème.
   
   Si vous n'avez pas l'option d'une base de données répliquée, vous pouvez configurer davantage de stratégies de jeu pour les données manquantes.

4. Si vos données de production sous-jacentes présentent des problèmes importants de qualité des données, elles seront reflétées dans les cubes. GIGO.