2010-05-23 2 views
2

Je comprends que les cubes sont des structures de données optimisées pour agréger et "découper" de grandes quantités de données. Je ne sais pas comment ils sont implémentés.Quelles structures de données et quels algorithmes sont appliqués dans les cubes d'entrepôt de données?

Je peux imaginer qu'une grande partie de cette technologie est propriétaire, mais y a-t-il des ressources que je pourrais utiliser pour commencer à implémenter ma propre technologie de cube?

La théorie des ensembles et beaucoup de maths sont probablement impliqués (et bienvenus comme suggestions!), Mais je m'intéresse principalement aux implémentations: les structures de données et les algorithmes de requête.

Merci!

+0

Ceci est assez limité, mais peut vous orienter dans la bonne direction http: // msdn.microsoft.com/en-us/library/bb219339%28CS.70%29.aspx – R0MANARMY

Répondre

0

Généralement, un entrepôt de données utilise une base de données relationnelle, mais les tables ne sont pas normalisées comme une base de données relationnelle opérationnelle.

Un entrepôt de données est orienté sur le sujet. Les tables de matières des entrepôts de données ont généralement les caractéristiques suivantes:

  • De nombreux index.

  • Aucune jointure, sauf pour rechercher des tables.

  • Données dupliquées, la table objet est fortement dénormalisée.

  • Contient des informations dérivées et agrégées.

Les tables de base de données dans un entrepôt de données sont organisées dans un schéma en étoile. Un schéma en étoile est essentiellement une table de sujet avec un tableau de tables de recherche. Les clés des tables de recherche sont des clés étrangères dans la table objet. Si vous dessinez un diagramme de relation d'entité de la table objet, les tables de recherche entourent la table en question comme des points étoiles.

En ce qui concerne les requêtes, cela dépend des tables sujet et du nombre de lignes. Généralement, attendez que les requêtes prennent beaucoup de temps (plusieurs minutes, parfois plusieurs heures).

Voici un article général pour vous aider à démarrer: Developing a Data Warehouse Architecture

Voici un aperçu de haut niveau de la conception d'un schéma en étoile: Designing the Star Schema Database

+0

Merci Gilbert - pouvez-vous entrer plus de détails sur la manière dont les données dupliquées, dérivées et/ou agrégées sont stockées et consultées? C'est à dire. tables de hachage sur les clés dimensionnelles? peut-être contenir une collection d'agrégats, etc.? –

+0

Bonjour Jeff. Jetez un oeil à la figure 10 du lien du schéma en étoile. WalMart, pour prendre un détaillant, aurait des trillions de lignes SalesFact. Les requêtes contre SalesFact ne se termineraient jamais si ce n'était pas pour les tables récapitulatives TimeDimension et StoreDimension. Les tableaux récapitulatifs répondent à la plupart des requêtes courantes. Le stockage de données réel n'a pas autant d'importance que la conception de l'entrepôt de données, de sorte que la plupart des requêtes sont traitées par les tables récapitulatives. Maintenant construire et maintenir les tableaux récapitulatifs, qui prend un traitement par lots en cours d'exécution périodiquement. –

+0

Les faits récapitulatifs ne sont pas stockés dans les dimensions. Ce sont des faits qui sont simplement agrégés à un grain différent (et peut-être avec des dimensions différentes), mais ils sont toujours stockés dans des tables de faits. –

1

Dans une base de données étoile schéma, les faits sont généralement acquis et conservés à le grain le plus fin.

Prenons donc l'exemple SalesFact de la figure 10 dans http://www.ciobriefings.com/Publications/WhitePapers/DesigningtheStarSchemaDatabase/tabid/101/Default.aspx

En ce moment, le grain est produit, temps (à une granularité de jour), magasin. Supposons que vous vouliez que cela soit agrégé par mois, pré-agrégé (cet exemple particulier ne nécessite probablement pas de pré-agrégation, mais si les ventes ont été détaillées par client, par minute, une pré-agrégation peut être nécessaire).

Alors vous auriez un SalesFactMonthly (ou ajouteriez une discrimination de grain à la table de faits existante puisque les dimensions sont identiques - parfois dans l'agrégation, vous pourriez réellement perdre des dimensions juste comme vous pouvez perdre le grain par magasin et non par produit).

ProductID 
TimeID (only linking to DayOfMonth = 1) 
StoredID 
SalesDollars 

Et vous obtiendrez ceci en faisant:

INSERT INTO SalesFactMonthly (ProductID, TimeID, StoreID, SalesDollars) 
SELECT sf.ProductID 
    ,(SELECT TimeID FROM TimeDimension WHERE Year = td.Year AND Month = td.Month AND DayOfMonth = 1) -- One way to find the single month dimension row 
    ,sf.StoreID 
    ,SUM(sf.SalesDollars) 
FROM SalesFact AS sf 
INNER JOIN TimeDimension AS td 
    ON td.TimeID = sf.TimeID 
GROUP BY td.Year, td.Month 

Qu'est-ce qui se passe en cubes est que vous avez essentiellement étoiles à grains fins et pré-agrégats ensemble - mais chaque mise en œuvre est la propriété - parfois vous ne pourriez pas même avoir les données les plus fines dans le cube, donc il ne peut pas être signalé. Mais chaque façon dont vous pourriez vouloir découper les données doit être stockée à ce grain, sinon vous ne pouvez pas produire d'analyse de cette façon.

Questions connexes