星型架構命名約定

Question

在星型架構中將表作爲維度還是事實表的前綴常見做法？列表名稱前面加上列名也是常見的做法嗎？

在我的正常OLTP數據庫中，我沒有這樣做，但是我在星型模式中看到了這種類型命名的例子。

對於數據倉庫模式與OLTP模式有一組不同的命名標準是否有意義？

感謝德懷特

Answer 1

的tablename_column名稱約定用於確保數據庫中的所有領域都是獨一無二的，雖然它是有點過度它可以用於當有獨特的命名標準/要求（其中一些客戶IT部門需求）。

Product.Name => Product.Product_Name 
Part.Name => Part.Part_Name 

它消除了名稱來自何處的任何歧義。

我更喜歡不用根據名稱命名錶（假設它不會破壞公司的本地標準），因爲雖然它今天可能是一個表，但它可以重新實現爲視圖或分區視圖明天但暴露相同的模式，然後我不得不接受前綴不正確的對象或更新每個引用新名稱的對象/創建同義詞。

具有一致性雖然往往是勝利者，但如果每個DBA/Dev都實施它們自己的版本，那將是混亂的，所以我會傾向於找到公司標準並應用它們。

Answer 2

在DW中，通常使用「長名稱」來命名列，因爲這些列最終會成爲報表中的列標題（查詢結果），並且應該是業務用戶友好的。因此，代替Product.Name和Customer.Name，它們都會顯示爲「名稱」（除非使用別名），因此通常使用Product.ProductName和Customer.CustomerName，因此它們在報告的首行顯示爲「ProductName」和「CustomerName」 ）一旦星星通過連接變平。如果數據庫允許的話，經常使用下劃線而不是駝峯和空格。在模式中表的作用可能不明顯時，建議在大DW中使用前綴暗淡和事實;我其實很喜歡他們。

Answer 3

表名稱：

• 我喜歡這個約定：[式] [主題] [名稱]
• 其中類型是 '變暗' 或 '實際上'（或 '事實' 爲聚集體）
• 其中受試者是倉庫內的主題區域（「COMM」爲常見的，防火牆「FW」，「IDS」， 等）
• 其中名稱是理想的單個單詞的名稱，或在所述維度的縮寫例如 彙總博意門表
• 例如：dim_comm_org的組織方面
• 例如：fact_scan的掃描事實表
• 例如：facts_scan_org_sev_daily - 其實掃描彙總表在 分組的組織，SEV &天的水平

列名：

• 不與整個表名稱前綴 - 這是太長了
• 前綴只有一個有意義的部分 - 這在編寫或讀取查詢時有很大的幫助。

倉庫VS OLTP命名：

• 兩者有很大的不同。倉庫表&列名通常以元數據形式存在於報告中，由開發人員和用戶閱讀。與OLTP不太一樣。
• 我認爲表前綴在OLTP中仍然有用 - 但我認爲最好的方法是，如果它對模型子集有意義，而不是事實/維度的區別。

Answer 4

肯，我喜歡你的[類型] [主題] [名稱]約定，其中類型是'昏暗'或'事實'（或'事實'的聚合）問題是，當創建星型模式模型在Oracle商業智能存儲庫中，最佳做法建議我們應爲維和事實表創建別名，併爲維和事實表創建DIM_（或dim）和FACT（或fact_）前綴。 爲了避免讓別名維度和事實表讀取dim_dim [表名]或fact_fact_fact_ [表名]，最好使用_DM（或_dm）後綴命名維表，並將事實表與_FT（或_ft）後綴。