Star/Snowflake 數據庫設計是否適合應用程序？什麼是替代方案？

我需要為一家製藥公司解決一個練習，他們要求我根據一些資訊從頭開始創建一個數據庫結構。

因為我希望它具有可擴展性且“面向未來”，所以我決定遵循該star/snowflake結構。現在它看起來比雪花更像明星，但想法就在那裡。我有一個關於主事實表（研究）以及如何表示維度表狀態的特定問題。

我想出了2個選項：

• 選項 1：事實表研究> 外鍵 > 維度表契約> 外鍵 > 維度表狀態。

所以我們通過兩個維度表來表示事實表上的**狀態。**我將通過 a JOINin aview或其他方式做到這一點…

• 選項 2：事實表研究> 外鍵 > 維度表狀態。

這樣，我們將事實表（研究）直接連結到維度表狀態。

我應該選擇選項 1還是選項 2？

我害怕將太多維度錶鍊接到事實表。這是我第一次嘗試創建數據庫結構。

歡迎任何建議，歡迎任何建議，尤其是來自經驗豐富的數據庫架構師和業餘愛好者的建議。

謝謝

編輯：添加更多資訊

謝謝@AntC 的提問。事實上，這根本不是一個數據倉庫場景，而是一家製藥公司需要一個新軟體來跟踪他們的臨床試驗的場景。

但當然，最著名的模式是 Star/Snowflake，我不想使用任何分層模式。同時我想避免三角形、菱形、圓形之類的形狀，因為即使現在只有 100 個使用者知道這個數據庫在 10 年後會是什麼樣子。這個想法是長期塑造一些東西，據我所知，我認為星形/雪花形狀也適合正常應用。

在選項 2Status_Code中，在兩個表中顯示為非鍵：Study, Contract. 但它屬於哪些實體？這些實體的相對基數是什麼？

查看選項 1，Status_Code屬於Contract; Study給定的 s可以有多個Contract。

因此，如果您要採用選項 2，您會讓 OLTP 頭疼：​​每當 a 發生變化時Status，Contract事務處理都需要將該變化複製到所有Studys，從而存在明顯不同步的風險。這稱為更新異常。

像選項 2 這樣的非規範化模型在數據倉庫中是合法的，因為我們想要快速報告。由於處理成本和維護數據同步的風險，在面向事務處理的數據模型中是不明智的。

因此，對於專注於事務處理的應用程序，指示選項 1。是的，您將創建一個Join視圖Study> Contract> Status。

引用自：https://dba.stackexchange.com/questions/285323