Comment concevoir une table de faits pour les données de livraison

Question

Je construis un entrepôt de données qui inclut des informations de livraison pour les restaurants. Les données sont stockées dans SQL Server 2005 et sont ensuite placées dans un cube SQL Server Analysis Services 2005.

Les informations livraisons comprend les tableaux suivants:

FactDeliveres

• BranchKey
• DeliveryDateKey
• ProductKey
• InvoiceNumber (DD: dimension dégénérée)
• Quantité
• UnitCosT
• Linecost

Note:

• La granularité de FactDeliveres est chaque ligne sur la facture
• La dimension de produit comprend des informations des fournisseurs

Et le problème: il n'y a pas de clé primaire pour la table de faits. La clé primaire doit être quelque chose qui identifie de manière unique chaque livraison plus le ProductKey. Mais je n'ai aucun moyen d'identifier de manière unique une livraison.

Dans la base de données OLTP source, il existe un ID de livraison unique pour chaque diffusion, mais il s'agit d'un ID interne qui n'a aucun sens pour les utilisateurs. L'InvoiceNumber est le numéro de facture des fournisseurs - il est tapé manuellement et nous obtenons donc des doublons.

Dans le cube, j'ai créé une dimension basée uniquement sur le champ InvoiceNumber dans FactDeliveres. Cela signifie que lorsque vous groupez par InvoiceNumber, vous pouvez obtenir 2 livraisons combinées uniquement parce qu'elles ont (par erreur) le même InvoiceNumber. Je pense que j'ai besoin d'inclure le DeliveryID (à être appelé DeliveryKey), mais je ne sais pas comment.

Alors, dois-je:

1. utiliser comme la clé sous-jacente de la dimension InvoiceNumber?
2. Créer un DimDelivery qui se développe chaque fois qu'il y a une nouvelle livraison? Cela pourrait signifier que certains attributs sortent de FactDeliveries et vont dans DimDelivery, comme DeliveryDate, Supplier, InvoiceNumber.

Après tout cela, je pourrais vous demander: comment puis-je créer un cube de livraisons quand j'ai les informations suivantes dans ma base de données source

DeliveryHeaders

• DeliveryID (PK)
• DeliveryDate
• SupplierID (FK)
• InvoiceNumb er (tapé manuellement)

DeliveryDetails

• DeliveryID (PK)
• ProductID (PK)
• Quantité
• UnitCosT

Answer 1

J'aurais Quantité , UnitCode, InvoiceNumber, DeliveryID tout en t Il fait la table. Les deux InvoiceNumber et DeliveryID sont des dimensions dégénérées, car ils vont changer avec tous les faits (ou très peu de faits). Il est possible que vous puissiez les mettre dans leur propre dimension si vous avez un grand nombre d'articles sur chaque commande. Le modèle ci-dessous peut ne pas être 100% correct si vous avez plusieurs livraisons sur une facture, mais il sera proche. Découvrez Kimball, il pourrait avoir un exemple d'un schéma en étoile pour ce scénario d'affaires.

Fact table: 
OrderDateID (not in your model, but probably should be, date dimension in a role) 
DeliveryDateID (date dimension in a role) 
SupplierID (supplier dimension surrogate key) 
InvoiceID (invoice dimension surrogate key) 
ProductID (product dimension surrogate key) 
Quantity (fact) 
UnitCost (fact) 
InvoiceNumber (optional) 
DeliveryID (optional) 

avec la table de dimension de date habituelle et les dimensions suivantes:

Supplier Dim: 
SupplierID (surrogate) 
SupplierCode and data 

Invoice Dim: 
InvoiceID (surrogate) 
InvoiceNumber (optional) 
DeliveryID (optional) 

Product Dim: 
ProductID (surrogate) 
ProductCode and Data 

Rappelez-vous toujours, votre (schéma en étoile) entrepôt de données ne va pas être structuré du tout comme vos données OLTP - il est tout à propos des faits et quelles dimensions les décrivent.

Answer 2

Les PK d'une table de faits sont presque toujours des clés de substitution. Chaque fait fait partie de plusieurs dimensions, donc le fait est FK aux dimensions, mais pas de vraies clés de son propre.

Un fait de livraison (une ligne) appartient à une succursale, il a un produit, il fait partie d'une plus grande livraison, il se produit sur une date particulière. Cela ressemble à 4 dimensions indépendantes.

La dimension de livraison a son propre PK et il a un attribut de dimension du numéro de facture. Plus, peut-être, d'autres attributs de la livraison dans son ensemble.

Chaque élément de ligne de livraison est associé à une livraison et au numéro de facture de cette livraison.