數據庫設計中的循環和陷阱

Question

我已經開始致力於在公司MariaDB中設計數據庫。這是我第一次爲此工作。 （以前我曾經工作的企業在Datawarehousing對象）

但是我已經創建的表和也加入其中按要求。

我在創建的佈局中遇到了循環，裂縫陷阱和扇形陷阱。我在處理數據庫之前需要解決它們嗎？

所有我在這些問題在互聯網做搜索抓取結果這是關於使用別名和上下文在Universe設計（在業務對象的工具）解決這些問題。因此，如果我需要爲一個設計好的數據庫解決這些問題，或者在您使用Universe Designer時需要解決這些問題，我會感到困惑。

請讓我知道如何解決他們如何在數據庫中解決。請儘可能提供一些參考資料。

Answer 1

鴻溝和風扇「陷阱」不是設計的屬性。它們是通過基於設計的某些屬性（即約束）而不是正確地（即表格的含義）盲目地寫（錯誤的）查詢來不正確地使用數據庫的方式。在您的設計中擁有這些屬性並不意味着有任何問題。當然，你仍然可能沒有選擇好的基本表。

每個基地臺都有相應的謂詞又名填空題-the-描述的應用情況[named-]空白聲明。謂詞中的空白名稱是表格的列。基表包含了構成真實語句的行。每個查詢表達式通過JOIN，UNION，SELECT，EXCEPT，WHERE條件等組合基表名，並且具有通過（分別）AND，OR，EXISTS，AND NOT和AND條件等組合基表謂詞的相應謂詞。查詢結果保存了做出真實陳述的行。

表和它的謂詞都表示應用程序關係。 （Aka關係，因此是關係模型和實體關係建模。）該表保存滿足謂詞的行。在不知道謂詞的情況下，您無法更新或解釋表格。許多設計方法和產品並沒有使這一切都清楚。

但是，它們會在ERM和ORM（較差的演示文稿）所謂的「關係」的箭頭/線表示沒有應用程序的關係，但約束。通過設置謂詞的基表，可以知道數據庫狀態的限制。他們與編寫查詢無關。 （雖然對基本表值的限制自然會反映爲查詢結果中的限制。）所以沒有什麼可以「解決」。

「循環」又名這些箭頭次/線只是反映某些多表的約束並沒有什麼不妥本身。但是對應於外鍵約束的箭頭/行也被SQL DBMS用於級聯，因爲這種多表約束通常需要多表更新。它是級聯必須是非循環的。恰巧一些DBMS將約束的表達限制爲限制級聯的副產品。所以你可能不得不「解決」它們來滿足這樣一個DBMS。

見this answer和this one。