ER圖中的基數

Question

我做了一個基本上是在線書店的項目，其中可以購買書籍並下訂單。

我的數據庫中包含像各種表格：

• user
• user_shipping_address
• user_payment_mode
• user_order
• order_shipping_address
• order_billing_address
• order_payment_details

我試圖構建這個EERD圖，但我感到困惑的一兩件事：一個user_order只能有一個送貨地址。我在order_shipping_address表中創建了一個引用主鍵order.id的外鍵order_id。我在表order中還有一個shipping_address_id外鍵，其引用order_shipping_address.id。

當我嘗試生成ER圖時，它給了我兩種不同的關係。 order與送貨地址和送貨地址與訂單之間的1：M關係之間的1：1關係。我不知道如何構造外鍵約束，因爲我覺得訂單表應該包含shipping_address_id，並且送貨地址應該包含order_id，對吧？這使得一切都變得更加混亂。

請幫我解決這個問題。

這裏是我的EERD：

Answer 1

這是因爲當前的設計意味着它會出現多user_order行引用相同的單排shipping_address。

您需要更改設計，以便多行user_order行不可能引用同一行shipping_address行。

至少有兩個不同的可能的解決方案：

1. 添加上user_order.shipping_address_id
2. 一個UNIQUE約束或：反轉的關係（這是我的，因爲它消除了不必要的代理鍵優先選擇）：
   1. 刪除user_order.shipping_address_id列。
   2. 變化shipping_address.id到shipping_address.order_id，以便它的user_order.id
   3. 外鍵讓shipping_address.order_id的shipping_address新的主鍵。

注意，這兩個選項是一個非規範化因爲它可以防止不同的訂單之間的送貨地址共享（例如，如果同一客戶作出了同樣的重複訂單很多），雖然這可能是故意的 - 所以如果用戶未來的地址發生變化，它不會無意中追溯更新舊訂單運送記錄。

一些其他提示：

• 考慮使用int，而不是bigint爲您的身份 - 我懷疑你會在每個表超過2十億行。
• 不要盲目使用varchar(255)所有文本列 - 用它來執行數據長度合理的約束，例如state如果你存儲的縮寫並不需要超過2個字符，同上zipcode它可以是varchar(10)如果你使用的是ZIP + 4。
• 請勿在您的數據庫中存儲完整的信用卡號碼！（如您的payment表所示） - 這違反了PCI規則，這是一項巨大的責任，可能是您所在轄區的非法過失。您的付款處理器將爲您提供一個替代不透明標記值（或類似物）作爲識別充值卡和將未來費用應用於存儲的付款詳細信息的方式 - 您可合理存儲的最多4位數字。無論您是否對數據進行加密都無關緊要。