Modèle de données dimensionnel

FONTE ZOOM:
Mettre en place un entrepôt de données a pour effet que d'un point de vue technique doit être considéré différemment. L'architecture de base de données est donc soumis aux besoins spécifiques de l'entreprise, qui crée un nouveau modèle de données: le modèle de données dimensionnel.

Dimensional

Avec l'intégration de l'entrepôt de données est une toute nouvelle façon de penser. Le principe de relationnelle anneau de modèle de données, ce qui est la règle générale dans OLTP, se est avéré répondre évaluations analytiques. Une nouvelle forme de modèle de données a émergé, le modèle de données dimensionnel. Il ne est pas dans le champ d'application de cet article de fournir une explication technique détaillée concernant la construction d'un entrepôt de données. Cependant, toujours être en mesure de garder l'idée principale de l'entreposage de données à l'esprit et parce que la classification d'une telle structure grandement différents de ceux dans un environnement transactionnel, il sera brièvement discuté les principes généraux.

L'idée de base derrière un modèle de données dimensionnel est basée sur l'approche des données, ce qui ne est pas seulement dans un groupe de données de détail, mais ici, nous partons du point de vue des attributs. Ces attributs ont été donnés les dimensions de nom appropriés. L'approche dimensionnelle a des conséquences techniques très spécifiques. Donc, ce est essentiellement la modélisation maître-détail, qui est un anneau standard sur une base de données relationnelle, supplanté par un amalgame de données en fonction du niveau le plus bas. Les données du maître doit être envisagé dans un entrepôt de données comme des attributs d'information des détails.

De relationnelle dimensionnelle

Figure 1 montre comment les en-têtes de factures de tables OLTP et les lignes de détail de la facture d'un progiciel de comptabilité peuvent être fusionnés dans une table globale de la facture. Nous supposons pour le moment qu'il n'y a aucune lisibilité ODS et que l'entrepôt de données est directement chargée du système OLTP.

Les tables de faits et tables de dimension

Une telle fusion a bien sûr des conséquences importantes. Se il n'y a pas de regroupement a lieu lors de la remise de la nouvelle table contient le même niveau de détail, tels que celui de la table de détails sur le système OLTP. Par conséquent, toutes les données seront répétées dans chacun des la fiche de la table détail. Une telle structure de table est appelée une table de faits. Très rudimentaire, nous pouvons dire que d'une table de fait est la table qui contient l'information numérique qui sera rapporté. Ils seront abordés du point de vue des tableaux dits dimension.

Comme mentionné précédemment, la position d'une dimension qui est rapporté. Un exemple d'une dimension est le numéro de client dans l'illustration ci-dessus. Outre un numéro unique au sein de la société a un client bien sûr d'autres attributs. Nous pensons que de l'adresse, un ou plusieurs numéros de téléphone, les contacts, etc. Maintenant, il est impossible d'enregistrer toutes ces données dans la table de faits. Une telle table ?? en fonction de la taille de l'entreprise ?? contenir des centaines de milliers à des millions de dossiers. En tant que client à tout moment de domicile ou de numéro de téléphone peut modifier, ou peut être contacté par d'autres contacts, ce est une tâche impossible de travailler chaque fois que ces données au niveau de chaque ligne de la facture. Ainsi une coordonnées du client se séparer dans un tableau distinct, une table de dimension. Via la touche technique qui est conservé dans l'entrepôt de données, ce tableau sera lié dans le modèle de données dimensionnel à la table de faits. Pour permettre un tel couplage, la table de faits doit bien entendu contenir la même clé technique. Par conséquent, ce sera recherché dans la table de fait lors de la création chaque enregistrement dans la table de dimension. Cette technique est appelée une recherche.

La figure 2 illustre les principes mentionnés ci-dessus. Nous remarquons que le numéro de client que nous remplaçons vu précédemment dans la table de faits par un champ de séquence technique. Les données réelles du client, y compris le numéro de client, sont dans une nouvelle table de dimension. En plus de la table des clients ont également été illustrant certains tableaux de dimensions similaires incluses dans le modèle, par rapport aux codes de produit et les unités d'affaires.

Snowflaking

Quand une table de dimension dans le même modèle sera associé à un autre table de dimension, par exemple, quand un client peut avoir plusieurs numéros de téléphone, et quand on ne souhaite pas fournir des champs séparés dans la table des clients, puis un soi-disant flocons de neige modèles ?? ou le modèle snowflaking ?? survenir. Snowflaking est très intéressant pour la génération de requêtes de haute performance, mais apporte un degré dangereux de risque. Lors d'une table de dimension en utilisant le moût de table de fait en principe avoir un enregistrement par dimension trouvé. Dans le cas de snowflaking le lien entre la table de faits et par l'exemple, la table des clients ira là où il a été renvoyé pour retourner un seul enregistrement, mais le supplément de joindre la table contenant les numéros mènera à plusieurs enregistrements. Et si nous prenons à l'esprit que la table de faits contient l'information numérique, ce sera inévitablement duplications se produire. Il est donc très concentré à traiter avec elle. Une forme de snowflaking lequel la table de dimension supplémentaire a une relation 1 à 1 avec la table de dimension principale ne est pas un problème, bien que les situations où le besoin se fait sentir d'une telle structure rare. La figure 3 montre le principe de snowflaking.

Pour chaque dimension dont les attributs peuvent subir de nombreux changements, appelés évolution rapide des dimensions ou des dimensions clés, donc il y aura une table de dimension pour être créé. L'application de cette technique conduit à la création d'un schéma en étoile, ce est pourquoi le modèle de données dimensionnel est souvent appelé simplement le modèle en étoile ou schéma en étoile.

Certaines dimensions, comme dans l'exemple ci-dessus, le numéro de facture ou de la date de la facture, seront que de façon sporadique ou jamais été modifiées. Ces dimensions qui ont été nommés lente modification des dimensions ou des dimensions dégénérées, continuent à faire partie de la table de faits. Toute modification de ces dimensions apporteront un effet secondaire des données de fait lui-même est un processus afin d'éviter autant que possible. Le choix entre ou non de la dégénérescence de dimensions est donc un facteur important dans la construction d'un entrepôt de données.
VOIR AUSSI:
  1.  
  2.  
  3.  
Sans commentaires

Laisser un commentaire

Code De Sécurité