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位数字。无论您是否对数据进行加密都无关紧要。