Considérations relatives à l'entrepôt de données: quand et pourquoi?

Question

Un peu d'histoire ici:

Je sais ce qu'est un entrepôt de données, plus ou moins. J'ai lu plusieurs dizaines de guides sur l'entreposage de données, j'ai joué avec SSAS, je sais ce qu'est un schéma en étoile et une dimension et une table de faits est, je sais ce que ETL est et comment le faire. Ce n'est pas un "comment" de la question ou d'une demande de tutoriels.

Mon problème est que tout le matériel que j'ai lu sur d'entreposage de données semble brillant sur la justification pour la construction d'un entrepôt de données. Ils ont tous figuré, ou, dans certains cas, littéralement commencer avec la phrase "si vous avez décidé de construire un entrepôt de données..." Sauf que je n'ai pas pris cette décision encore.

Donc je suis en espérant que les membres peuvent m'indiquer, ou de l'aider à venir avec, une sorte de semi-test objectif. Quelque chose que je peux m'adapter à un système particulier et à la fin, avec "oui, nous avons besoin d'un entrepôt de données" ou "non, le gain serait aujourd'hui trop petit." Je pense que les questions spécifiques que je devrais être en mesure de répondre sont les suivantes:

1. A quel point en est la construction d'un entrepôt de données d'une option à considérer? En d'autres termes, quels signes révélateurs, des mesures, ou d'autres critères dois-je être à la recherche pour qui peut indiquer qu'un standard de l'environnement transactionnel n'est plus suffisant?

2. Quelles sont les alternatives à un entrepôt de données? La dénormalisation dans la base de données transactionnelle et de la tourbière-standard répliqué "serveur de rapports" sont les deux qui me viennent à l'esprit, s'il y a tous les autres que je devrais explorer avant de s'engager à la DW?

3. Pourquoi est-ce qu'un entrepôt de données meilleures que dit alternatives? Si la réponse est "ça dépend", alors à quoi cela dépend-il?

4. Quand ne faut pas essayer de créer un entrepôt de données? Je suis sceptique de quoi que ce soit déclarée comme "meilleure pratique" quel que soit le contexte. Il doit sûrement y avoir certains scénarios où un DW est le mauvais choix - que sont-ils?

5. Existe-il des pratiques des exemples que j'ai pu regarder de systèmes qui ont été améliorées par l'introduction d'un entrepôt de données? Quelque chose qui pourrait m'expliquer, de bout en bout, quelles sortes de décisions ou d'analyse, ils avaient besoin de l'entrepôt, de la façon dont ils ont décidé quoi mettre et comment l'entrepôt fini le montage dans l'environnement de plus? Je ne veux pas artificiel, "nous allons faire un cube à partir de la base de données AdventureWorks" - la mise en œuvre est sans importance pour moi, je suis intéressé par les spécifications et les dessins et modèles et de l'ensemble du processus de pensée qui ont été impliqués.

De manière générale, j'essaie de ne pas demander multi-partenaires, mais je pense que ces sont très étroitement liés. Je suis prêt à accepter toute réponse qui s'adresse au moins les 4 premières questions, bien que ce dernier serait vraiment aider à se cristalliser dans mon esprit. Les liens sont très bien si quelqu'un a déjà écrit sur ce sujet, tant qu'ils sont raisonnablement concis et précis (lien vers Ralph Kimball page d'accueil = pas utile).

J'espère que j'ai fait de la question claire merci d'avance pour vos réponses!

Answer 1

Je vais voir si je peux faire de mon mieux pour répondre à vos questions de manière succincte.

1.A quel point en est la construction d'un entrepôt de données d'une option à considérer? En d'autres termes, quels signes révélateurs, les statistiques ou d'autres critères dois-je être à la recherche d' une norme transactionnelle l'environnement n'est plus suffisant?

un. Si vous trouvez que les rapports et la surveillance sont compromettre la performance de votre système de production et/ou hors ligne magasin de données.

b. Si vous trouvez que l'obtention de réponses à vos questions d'affaires nécessite la construction d'un beaucoup de complexes SQL à chaque fois.

c. Si vous trouvez que chaque fois que vous apportez une modification à votre schéma transactionnel, vous devez revenir en arrière pour retravailler toutes vos requêtes de rapport.

d. Si vous souhaitez regrouper les données provenant de sources multiples.

2.Quelles sont les alternatives à un entrepôt de données? La dénormalisation dans la transaction base de données et le cdg-standard répliqué "serveur de rapports" sont deux qui viennent à l'esprit; il n'existe aucun les autres je doit l'explorer avant de s'engager pour l'DW?

3.Pourquoi est-ce qu'un entrepôt de données meilleures que dit alternatives? Si la réponse est, "ça dépend", alors à quoi faut-il dépendre sur?

Je vais répondre à ces ensemble. Je ne pense pas que d'un entrepôt de données comme un tout ou rien venture. C'est tout simplement une phrase concise qui signifie "le stockage de vos données, ce qui vous permet de facilement et rapidement répondre à des questions d'affaires."

Bases de données transactionnelles sont conçus pour efficacement l'interface avec les applications. Entrepôts de données, data marts, de magasins de données opérationnelles et les rapports des tables sont construites de manière efficace interface avec les gens, si cela fait sens.

4.Quand je ne devrais pas essayer de construire un entrepôt de données? Je suis sceptique rien déclaré comme "meilleure pratique" quel que soit le contexte. Il y a certainement doivent être certains scénarios où un DW est le mauvais choix - quels sont-ils?

Bonne question. Si votre système transactionnel vous fournit suffisamment d'information dans votre entreprise, vous n'avez probablement pas besoin pour l'entreposage.

Si vous avez seulement une source de données et de la performance n'est pas un problème, vous pouvez probablement obtenir un aperçu de la création de simples tableaux de présentation.

5.Existe-il des exemples pratiques, j'ai pu regarder de systèmes qui ont été améliorée par l'introduction de données l'entrepôt? Quelque chose qui pourrait expliquez-moi, de bout en bout, quelles sortes de décisions ou d'analyse, ils nécessaires l'entrepôt, de la façon dont ils ont décidé quoi mettre dans, et comment les entrepôt fini le montage dans l' environnement de plus? Je ne veux pas d'un artificiel "nous allons faire un cube de la base de données AdventureWorks" - le la mise en œuvre est sans importance pour moi, Je suis intéressé dans le cahier des charges et les dessins et modèles et de l'ensemble de la pensée processus qui ont été impliqués.

C'est une grande question qui serait beaucoup plus d'espace que je me suis attribué ici.

Sur ce point, je peux vous indiquer quelques endroits qui pourraient vous fournir des idées que vous cherchez.

• "La mise en œuvre d'Un Entrepôt de Données: Une Méthodologie qui a travaillé" par Bruce Ullrey est un livre sur un homme, sur le chemin vers la construction d'un entrepôt de données. Ce n'est pas très poli, ce qui lui donne plus de réalisme. Il se lit comme un journal avec beaucoup de modèles et autres éléments visuels qui illustrent ses efforts assez bien.
• "L'Intelligence d'affaires feuille de route" de Larissa de la Mousse. Le tarif. Vous guide à travers le processus de construction d'une BI pratique à un haut niveau.
• "L'Impact sur les Bénéfices de l'Intelligence d'Affaires" par Steve Williams donne un certain nombre d'études de cas qui montrent la valeur de la construction d'entrepôts de données.

Answer 2

1. Le but principal d'un DW est-à-speed-up (simplifier) de reporting et d'analyse. Il permet de découper en tranches et découper des données d'un utilisateur de l'entreprise peuvent penser.

2. Pour une première étape DW, vous pouvez simplement mettre en œuvre un Kimball schéma en étoile et d'exécuter des requêtes SQL. Si cela s'avère être encore trop lent, commencer à penser à la pré-calculé agrégations (cubes).

3. Le découper en tranches et découper de l'information contre un DW est plus simple, que contre un normalisée DB. Répliqué serveur de rapports permettra d'améliorer les performances, mais ne va pas simplifier le découpage en tranches et couper en dés. Aussi garder à l'esprit que le DW appartient aux utilisateurs métier, donc c'est à eux de venir avec divers tranche/dés idées à tout moment -- IL les gens doivent simplement fournir un environnement dans lequel quelque chose comme cela est possible.

4. Si vous venez d'exécuter quelques rapports de temps en temps sur votre système d'exploitation et que vous êtes satisfait de la performance, il n'est pas nécessaire pour DW.

5. Toute mon expérience avec les systèmes où les utilisateurs professionnels se plaignent sans cesse sur la lenteur de rapports et l'incapacité d'écrire des requêtes compliquées", tandis que la production de gens se plaignent que la base de données s'enlise à cause de la déclaration. Dans tous les cas, un simple Kimball étoiles et un serveur de rapports avec le cache et les clichés étaient assez bonnes.

Answer 3

1. Vous devriez envisager la construction d'un datawarehouse, lorsque deux des critères suivants match:

   • Énorme quantité de données
   • Beaucoup de grands complexes sélectionne (peut-être par rapport à quelques insertions, mises à jour et suppressions) qui prennent juste à temps pour s'exécuter (et sont complecated à écrire)
   • Les données provenant de différents systèmes pour obtenir des combinés

2. C'est vraiment la question de ce que vous considérez comme un entrepôt de données. Dans de nombreux cas, vous pouvez déplacer progressivement à partir de OLTPs Systèmes avec des rapports d'une pleine soufflé datawarehouse, aussi longtemps que vous pouvez coller à une base de données relationnelle système de gestion. La première pourrait être de construire une première table de faits, et de continuer à utiliser les tables normalisées pour la dimension. Ensuite, l'ajout de plus de faits, de plus les tables de faits ou de dédié tables de dimension au jeu. D'abord dans la même base de données (ou une des bases de données des systèmes concernés), éventuellement la déplacer vers une autre base de données plus tard.

3. Plein de datawarehouse (séparée de la base de données, schéma en étoile) offre les meilleures options pour le paramétrage des instructions select, appart de passer à un système spécialisé. Il est aussi proprement découplé du Système oLTP(s). Pensez à la conception de schémas, mais aussi de ressources comme le CPU, I/O et de la mémoire et de l'organisation, comme la planification de nouvelles versions. Bien sûr, il y a beaucoup de travail qui vous n'avez pas besoin.

4. C'est dans les réponses ci-dessus: juste parce que vous avez une poignée de requêtes complexes, ne signifie pas que vous devez construire un DWH, de même pour les autres critères, s'ils sont dans l'isolement.

5. Ne peut pas offrir beaucoup de choses ici, mais le conseil: allez agile. Les exigences pour un DWH dépendent extrêmement sur les possibilités, les utilisateurs de. Il y a pour les conditions sont susceptibles de changer. L'automatisation des tests avec des bases de données est une douleur, mais à faire les fous dans un système de production sans une bonne tests est de pire en pire.

Answer 4

A quel point en est la construction d'un entrepôt de données d'une option à considérer? En d'autres termes, quels signes révélateurs, des mesures, ou d'autres critères dois-je être à la recherche pour qui peut indiquer qu'un standard de l'environnement transactionnel n'est plus suffisant?

Je recommanderais un entrepôt de données lorsque vous avez observé que le fait d'effectuer le reporting et l'analyse des activités dans le transactionnel banque de données a été dangereux à la fois.

Quelles sont les alternatives à un entrepôt de données? La dénormalisation dans la base de données transactionnelle et de la tourbière-standard répliqué "serveur de rapports" sont les deux qui me viennent à l'esprit, s'il y a tous les autres que je devrais explorer avant de s'engager à la DW?

Je n'ai rien à offrir ici. Je dirais que le maintien de la transaction et de bases de données des rapports semble raisonnable pour moi, peu importe si vous appelez ça un entrepôt ou pas. L'exploration de données peut être très consommateur d'UC de l'activité.

Pourquoi est-ce qu'un entrepôt de données meilleures que dit alternatives? Si la réponse est "ça dépend", alors à quoi cela dépend-il?

Je n'ai rien à offrir ici.

Quand je ne devrais pas essayer de construire un entrepôt de données? Je suis sceptique de quoi que ce soit déclarée comme "meilleure pratique" quel que soit le contexte. Il doit sûrement y avoir certains scénarios où un DW est le mauvais choix - que sont-ils?

Je dirais que si vous n'avez pas besoin de garder une longue histoire, ne font pas une analyse approfondie des données et de vos besoins en matière de reporting sont limités à une requête ad hoc de temps à autre, alors peut-être un entrepôt de données n'est pas nécessaire.

Existe-il des exemples pratiques, j'ai pu regarder de systèmes qui ont été améliorées par l'introduction d'un entrepôt de données? Quelque chose qui pourrait m'expliquer, de bout en bout, quelles sortes de décisions ou d'analyse, ils avaient besoin de l'entrepôt, de la façon dont ils ont décidé quoi mettre et comment l'entrepôt fini le montage dans l'environnement de plus? Je ne veux pas artificiel, "nous allons faire un cube à partir de la base de données AdventureWorks" - la mise en œuvre est sans importance pour moi, je suis intéressé par le cahier des charges et les dessins et modèles et de l'ensemble de processus de pensée qui ont été impliqués.

Mes employeurs ont tous utilisé des entrepôts de données pour de nombreuses années avant mon arrivée, donc je ne peux pas parler de ce qu'étaient les choses avant que j'arrive.

Answer 5

De mon expérience, le premier signe pour commencer à penser au sujet de l'entreposage de données, c'est quand vous avez (ou sont en développement) une base de données transactionnelle et les utilisateurs de commencer à ajouter beaucoup de rapports et de données de l'histoire exigences. Qui est à peu près toujours. Il est toujours plus facile d'avoir un entrepôt de données ou base de données de rapports que de tenter de concevoir un système transactionnel qui gère les besoins de reporting que les utilisateurs finaux ont toujours. Le stockage de l'histoire (pour les entrepreneurs) dans un système transactionnel ajoute à la complexité et gonfle une base de données qui doit être aussi réactif que possible.

Sur le revers de la médaille, j'ai été dans les grandes entreprises où de nombreux groupes créés entrepôts de données, car les données d'intérêt a été répartie dans de nombreux systèmes et était donc difficile de requête. Le problème est que chaque groupe créé leur propre entrepôt de données parce que toutes les entrepôts de la société n'a pas le droit de sous-ensemble d'informations, ou avaient un modèle de données qui a été considéré comme non approprié ou incorrect. Cela a aggravé la situation en créant encore plus de données disparates des systèmes qui ont été difficiles à comparer.