Entrepôt de données type Kimball Star-Schema - Vues de modèle réalisables? et comment coder gén

Question

J'ai un entrepôt de données contenant des schémas en étoile typiques, et tout un tas de code qui fait des choses comme ça (évidemment beaucoup plus gros, mais c'est illustratif):

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

Je songe à le remplacer par une vue ( MODEL_SYSTEM_1 , par exemple), de sorte qu'il devienne:

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

Mais la vue MODEL_SYSTEM_1 devrait contenir des noms de colonne uniques. Les performances de l'optimiseur me préoccupent également si je le fais, car je crains que tous les éléments Dans la clause WHERE, différents faits et dimensions sont optimisés, car la vue est visible sur toute une étoile et ne peut pas être paramétrée (garçon, ça ne serait pas cool!)

Mes questions sont donc -

1. Cette approche est-elle correcte ou s'agit-il simplement d'une abstraction qui nuit aux performances et qui ne me donne qu'une syntaxe beaucoup plus agréable?

2. Quel est le meilleur moyen de générer par code ces vues, en éliminant les noms de colonnes en double (même si la vue doit ensuite être modifiée manuellement), étant donné que tous les PK et FK appropriés sont en place? Dois-je simplement écrire du code SQL pour l'extraire du INFORMATION_SCHEMA ou existe-t-il un bon exemple déjà disponible?

Modifier: Je l'ai testé et les performances semblent identiques, même pour les processus les plus volumineux: vous avez même rejoint plusieurs étoiles qui utilisent chacune ces vues.

L’automatisation tient principalement au fait qu’il existe un certain nombre de ces étoiles dans l’entrepôt de données et que les concepteurs ont bien exécuté les FK / PK, mais je ne veux pas avoir à parcourir toutes les tables ou la documentation. . J'ai écrit un script pour générer la vue (il génère également des abréviations pour les tables) et il fonctionne bien pour générer le squelette automatiquement à partir de INFORMATION_SCHEMA . Il peut ensuite être modifié avant de valider la création de la vue. .

Si quelqu'un veut le code, je pourrais probablement le publier ici.

Answer 1

1. J'ai utilisé cette technique sur plusieurs entrepôts de données que je surveille. Je n’ai constaté aucune dégradation des performances lors de l’exécution de rapports basés sur une vue directe par rapport à une vue, mais n’ai jamais effectué d’analyse détaillée.

2. J'ai créé les vues à l'aide du concepteur de SQL Server Management Studio et n'ai utilisé aucune approche automatisée. Je ne peux pas imaginer que le schéma change assez souvent pour que son automatisation en vaille la peine. Vous pourriez passer aussi longtemps à peaufiner les résultats qu'il aurait fallu pour faire glisser toutes les tables sur la vue en premier lieu!

Pour lever toute ambiguïté, une bonne approche consiste à préfacer les noms de colonne avec le nom de la dimension à laquelle il appartient. Ceci est utile aux rédacteurs de rapports et à toute personne exécutant des requêtes ad hoc.

Answer 2

Transformez la ou les vues en une ou plusieurs tables de faits résumées et matérialisez-les. Celles-ci doivent uniquement être actualisées lors de l'actualisation de la table de faits principale. Les vues matérialisées seront plus rapides à interroger, ce qui peut être avantageux si vous avez beaucoup de requêtes pouvant être satisfaites par le résumé.

Vous pouvez utiliser le dictionnaire de données ou les vues de schéma d’informations pour générer du SQL afin de créer les tables si vous avez un grand nombre de ces résumés ou si vous souhaitez les modifier fréquemment.

Cependant, je suppose qu'il est peu probable que vous les modifiiez très souvent. Par conséquent, la génération automatique des définitions de vues pourrait ne pas en valoir la peine.

Answer 3

Si vous utilisez MS SQL Server, vous pouvez essayer une UDF en ligne qui est aussi proche d’un vue paramétrée au fur et à mesure de son obtention.