Comment éviter les jointures complexes dans le schéma en étoile?

Question

Ma table de faits contient un score utilisateur dans un cours qu'il a suivi. Certains des détails du cours, que je dois montrer sur le rapport, proviennent de plus d'une table (dans la base de données OLTP réelle). Est-ce que je crée une version non normalisée de cette entrée de cours dans une table de dimension?
Ou est-ce que je rejoins la table des faits directement à la table de cours rejoindre les autres tables qui décrivent ce cours (type_cours, faculté qui a créé ce cours etc)

Answer 1

Peut-être que je ne comprends pas votre question, mais une table de faits dans un schéma en étoile est supposé être joint aux tables de dimension qui l'entourent. Si vous n'avez pas envie de créer des jointures, créez simplement une vue et utilisez la vue pour générer des rapports.

Si vous deviez poster un modèle (schéma), il serait plus facile de commenter/aider.

Answer 2

Les flocon de neige ou les tables de bridge rendent les jointures plus compliquées, et pas seulement du point de vue du codage, elles simplifient également les choses pour les utilisateurs BI.

Dans la plupart des cas, je les mettrais directement dans des tables de dimensions existantes ou supplémentaires. Par exemple, vous avez une table de faits sur les scores, qui contient les détails de l'utilisateur dans une dimension qui peut ou non contenir des données démographiques sur l'utilisateur (peut-être seulement un pont). Parfois, il est préférable de séparer les informations démographiques. Ainsi, même si le genre et l'âge peuvent être associés à une entité utilisateur, dans le modèle dimensionnel, il peut s'agir de dimensions individuelles ou regroupées en une seule dimension, selon les scénarios d'utilisation. Peut-être que vos scores sont attachés à un état et que les états ont des régions (flocon de neige). Il pourrait être beaucoup plus efficace pour l'analyse de faire directement correspondre la dimension de la région au lieu de passer par la dimension de l'État.

Je pense que vous trouverez que le modèle dimensionnel est une approche de dénormalisation très pragmatique. Les principales choses qui ne sont pas négociables sont les faits - après cela le choix des dimensions est très influencé par le comportement des données, votre prévoyance pour les scénarios d'utilisation courants - et évitant de tomber dans les trop petites dimensions et trop de problèmes de dimensions.

Answer 3

Il est courant de consolider plusieurs dimensions ensemble, en sacrifiant la normalisation au profit de la performance. Cela est généralement effectué lorsque votre requête type nécessite toutes les dimensions ensemble (par opposition à l'utilisation de bits différents pour différents cas d'utilisation).

Rappelez-vous aussi que si vous recevez une réduction de joindre les frais généraux, il y a quelques inconvénients:

• perte de flexibilité, ce qui pourrait entraver le développement que l'entrepôt se développe
• scans de table complets prennent plus de temps (en traditionnel SGBDR basée sur les lignes telles que SQL Server)
• de consommation d'espace disque

Vous devrez examiner chaque cas séparément.

Il peut être utile d'envisager également la possibilité de créer une vue matérialisée, si cette possibilité est offerte par votre SGBDR.

Answer 4

Nous avons généralement un schéma de flocon de neige en tant que conception physique DWH, mais nous ajoutons une couche de vue de rapport qui aplatit le schéma de flocon de neige dans un schéma en étoile.De cette façon, votre cube OLAP devient beaucoup plus simple et facile à gérer.