事實表變更

Question

語境

我正在嘗試創建一個銷售情況表。 每行代表客戶訂單中的產品。 在其他領域中，我有以下3個具體領域：

• 采購價格
• selling_price
• 余量

問題

在我們公司中，當我們銷售產品時，我不知道確切的購買價格，因為我稍后會付款，並且購買價格將基於付款日期的匯率。 我通常知道訂購日期后1周到2個月之間的實際購買價格。 確實，我的公司已做出安排，使我們能夠從收到供應商產品之月起，在下個月的每個15日向供應商付款。 由於我們在不同國家/地區都有供應商，因此匯率帶來了一些問題。

等待結果

我必須生成2個月度報告和1個年度報告：-每個月1日的1個報告基於訂單日期的匯率-每個月15日的1個報告基於付款日期的匯率（其中是當前日期的匯率，因為我們會在每個月的15號向供應商付款。-1個基於付款日期匯率的年度報告（有時可能是訂購日期后的2個月）

例

1. 我在7月3日訂購了產品。
2. 該產品僅在8月7日交付
3. 然后，我將根據該日期的匯率在9月15日向產品付款。

解決方案

到目前為止，我僅找到3個解決方案：

1. a）在事實表中創建1行，並在2個字段中創建： real_purchasing_price （將等於0）和臨時 _purchasing_price （將根據訂單日期的匯率自動等於購買價格）。 b）一旦我付款了產品，我就知道正確的匯率，因此我可以更新該行，並根據付款的匯率用購買價格填寫real_purchasing_price字段。

2. a）根據訂單日期的匯率在事實表中使用purchase_price創建1行。 B）當我付的產品，我知道正確的匯率，因此我可以創建在幾乎相同的第一個事實表1個新行，但根據付款日期的匯率這次與purchasing_price。

3. 一）創建基於訂單日期B的匯率purchasing_price事實表中的行），一旦我支付的產品，我知道正確的匯率，因此我可以更新該行並通過基於一個更換purchasing_price正確的匯率。

第四個解決方案屬於您。

謝謝您的幫助。 不要猶豫，向我詢問更多詳細信息。

祝你有美好的一天，

Answer 1

我實際上選擇使用貨幣表並添加一個字段payment_date，該字段使我可以將事實表的每一行與貨幣表中的正確匯率進行匹配。

但是，我必須更新事實表的每一行以在我知道后添加payment_date。

到目前為止，我找不到更好的解決方案。

謝謝大家。

Answer 2

我假設對於購買價格，您有一個固定的組件，另一個是可變的，取決於匯率。 （例如p * x，其中x是匯率）

我建議創建一個新的事實表，說exchange_rates與不同國家的匯率和時間戳。 現在列purchasing_price在事實表，應該是一個結果，從加入exchange_rates表該國。

假設current_values列保存匯率。

    EXCHANGE_RATES
    +-------------+---------------+---------------+-----------+
    | EXCHANGE_ID | EXCHANGE_NAME | CURRENT_VALUE | TIMESTAMP |
    +-------------+---------------+---------------+-----------+
    |           1 | JAPAN         |           100 |  20151021 |
    +-------------+---------------+---------------+-----------+     

在填充購買價格時，請使用EXCHANGE_RATES該值來獲取正確的值。

    ORDER_DETAIL_FACT       
    +----------+---------+------------------+---------------+--------+
    | ORDER_ID | PRODUCT | PURCHASING_PRICE | SELLING_PRICE | MARGIN |
    +----------+---------+------------------+---------------+--------+
    |      101 |      11 | 50*100           |          6000 |   1000 |
    +----------+---------+------------------+---------------+--------+

讓我知道您是否需要有關其實施的幫助。

Answer 3

您的訂單似乎經歷了三個階段：

• 下令

• 已交付

• 購買價格已知

一種數據倉庫設計方法是不變性 （僅插入，不進行更新）。

這種方法將導致為您的訂單創建三個事實記錄

預定事件

具有屬性

 orderId, productId, orderDate  and sellingPrice

交付事件

 orderId, DeliveryDate, 

請注意，訂單和交貨記錄與OrderId唯一相關（簡化假設每個訂單只有一種產品）。

這兩個事件都存儲在單獨的事實表中或一個公共的事實表中，這取決於您所用的完整屬性定義。

購買價格存儲在具有屬性的單獨表中

productId, entryDate, validFromDate, ValidToDate, purchasingPrice

該表將根據您在下個月15號（entryDate）的規則以及上個月的有效期進行填充。

該表的關鍵作用是支持具有productId和validDate的查詢，並返回購買價格或未知價格。

基於此設計，您可以設置訪問視圖 （簡單視圖，具體化視圖或其他解決方案），以提供訂單的當前狀態

 orderId, productId, orderDate, sellingPrice,
 DeliveryDate, -- NULL if not delivered
 purchasingDate,
 purchasingStaus -- 1 purchased, 0 - not yet purchased
 purchasingPrice

purchasingDate日期是根據基於業務規則的交貨日期計算的。 purchasingStatus是報告日期和購買日期比較的結果。

purchasingPrice是產品的最后估計價格或適當的購買價格。

您可能還會問，為什么數據倉庫設計中的不變性很重要。 它類似於OLTP中的事務概念。 遇到麻煩時，您可以使用審核維度將數據回滾到過去的某個點，然后再次重新加載。 如果更新，則要復雜得多。

小例子

15.2。 您在一月份獲得產品A的購買價格

采購價格表

 entryDate = 15.2.
 validFrom = 1.1.
 validTo = 31.1.
 purchacingPrice = 100

產品A在1.3上的訂購。 在訂單事件表中創建一條記錄

 orderDate = 1.3.
 sellingPrice = 200
 ...

您可以使用“最后知道的購買價格”（當前為100）來報告此事件。（具有orderDate的購買價格表中的查找未提供有效結果，將返回最后存儲的值）

10.3。交貨 在傳遞事件表中創建一條記錄

 deliveryDate = 10.3.
 ....

確切的采購價格仍然未知（帶有deliveryDate的“采購價格表”中的查詢未提供有效結果，將返回最后的儲值）

在15.4。 3月的采購價格表中輸入了新的采購價格。 從這一點上來說，實際的購買價格是已知的。