star-schema

7熱度

1回答

OLAP數據庫由非規範化形式的數據組成。這意味着數據冗餘和此數據冗餘有助於通過更少的連接數來檢索數據，從而有助於更快地檢索。但是OLAP數據庫的流行設計是事實維度模型。事實表將存儲數字基於事實的條目（銷售數量等），而維度表將存儲與該事實相關的「描述性屬性」，即銷售所針對的客戶的詳細信息。我的問題是，在這個設計中，它看起來並不是非規格化的，因爲所有的維度表都有對事實表的外鍵引用。它與OLTP設計

0熱度

1回答

數據倉庫和挖掘中的模式設計

我在事實和維度表之間有點混淆，我無法清除我的疑問。事情是我必須設計一個模式，其中有一個關鍵字表。並且對應於每個關鍵字我們都有一個日期表和網站表（該關鍵字是爲哪個網站生成的）。現在有這種情況下工作我很困惑哪些表被分配爲事實和哪一個作爲維表。關鍵字表格包含key_id和關鍵字名稱。日期表格包含月份，年份和星期。網站表格包含關鍵字所屬網站的名稱。請向我建議此架構的架構。

0熱度

2回答

我是否應該將多個客戶拼合成一個維度行或使用橋接表

我是數據倉庫的新手，我有一個具有合同事實表的星型模式。它擁有開始日期，結束日期，金額等基本合同信息。我必須將這些事實鏈接到客戶維度。每份合約最多有4位顧客。所以我認爲，我有兩個選擇要麼我壓平4名顧客進一行例如： DimCutomers name1, lastName1, birthDate1, ... , name4, lastName4, birthDate4 從我所聽到的另一種選擇是

1熱度

1回答

如何在大型數據倉庫中爲發票創建數據模型？

我正在爲大型數據倉庫中的客戶發票創建數據模型。下面顯示了一個典型的發票中的字段：以下是數據模型我摸索出這麼遠的發票型號：傳統的觀點認爲，大型數據倉庫應該使用星型模式，這意味着一個事實表，但似乎是模擬一個inv oice我需要兩個事實表，如上所示。使用兩個事實表是否正確？

3熱度

3回答

這是MySQL JOIN嗎？

SELECT dim_date.date, dim_locations.city, fact_numbers.metric FROM dim_date, fact_numbers WHERE dim_date.id = fact_numbers.fk_dim_date_id AND dim_locations.city = "Toronto" AND

0熱度

1回答

星型模式的缺點是什麼？

在大數據的數據庫設計中使用星型模式有什麼缺點？是事實表的大尺寸出了問題？或者我們可以認爲磁盤空間很便宜，事實表的大小不是問題呢？

1熱度

1回答

用於確定唯一登錄的數據集市結構

背景：我有基於星型模式結構（即事實和維度表）的數據集市。我已經掌握了確定包括日期範圍，接口和區域在內的任何維度組合的用戶登錄次數正常計數的技巧。問題：當我嘗試確定唯一登錄的次數時，我陷入困境，例如，因爲任何天數的登錄次數不是每天唯一登錄次數的總和在那一套。我的可怕的解決方案：我完全沒有想法，除了存儲每個單一的登錄表與時間戳和用戶ID。

2熱度

1回答

數值屬性的維表中的空值

處理維表中缺失值的最佳方法是什麼？在文本列的情況下，很容易寫出「NA：Missing」，但是對於保留的特定值重要的數字列應該做些什麼。注意：我不希望使用綁定值的解決方案（例如，「0-50」，「50-100」，「NA：Missing」）的文本列。例如，客戶維度可能具有出生年份。應該如何處理遺失的出生年份？保留它爲空？添加一個任意數字作爲佔位符，例如1900？有時，可能很難找到佔位符號碼。例如，

3熱度

3回答

在星型模式中我的時間維度表的屬性

我正在用星型模式建模構建DW。我將用它與pentaho進行BI項目。我當然會有一個時間維度表。我將用不同的粒度（日，周，月，年或其他）來分析我的事實表我應該爲每個粒度在我的維度表中放置一個屬性（所以我有一天屬性，一個月屬性，一年的屬性...）或者我應該只寫日期，然後計算與此日期的所有內容（獲取日期的月份，日期的年份...）？ THKS很多關於你的幫助

0熱度

2回答

設計事實表以允許簡單的最近檢測事實類

我正在處理聯繫歷史事實表的數據倉庫事實表設計。我目前的架構看起來是這樣的： [FK] DateKey INT [FK] TimeKey INT [NK] CustomerNK INT [NK] CustomerPhoneNK INT [FK] ContactTypeKey INT [FK] ContactResultKey INT [BK] ContactRefBK INT