这是我的一门类(class)中关于绘制 ERD 的问题:
A local startup is contemplating launching Jungle, a new one stop online eCommerce site.
As they have very little experience designing and implementing databases, they have asked you to help them design a database for tracking their operations.
Jungle will sell a range of products, and they will need to track information such as the name and price for each. In order to sell as many products as possible, Jungle would like to display short reviews alongside item listings. To conserve space, Jungle will only keep track of the three most recent reviews for each product. Of course, if an item is new (or just unpopular), it may have less than three reviews stored.
Each time a customer buys something on Jungle, their details will be stored for future access. Details collected by Jungle include customer’s names, addresses, and phone numbers. Should a customer buy multiple items on Jungle, their details can then be reused in future transactions.
For maximum convenience, Jungle would also like to record credit card information for its users. Details stored include the account and BSB numbers. When a customer buys something on Jungle, the credit card used is then linked to the transaction. Each customer may be linked to one or more credit cards. However, as some users do not wish to have their credit card details recorded, a customer may also be linked to no credit cards. For such transactions, only the customer and product will be recorded.
这是解决方案:
问题是购买操作与其他 3 个实体相关联:产品、客户和卡片。我发现这很难阅读和理解。
涉及 2 个以上实体的 Action 在生产中是否常见？如果是，我应该如何理解和使用它？或者，如果不是，那么针对此问题的更好设计方法是什么？
最佳答案
虽然实践中的大部分关系都是二元关系，但三元和更高级的关系是实体关系模型的正常元素。一些示例是 supplies (supplier_id, product_id, region_id) 或 enrolled (student_id, course_id, semester_id)。但是，由于不喜欢复合键或与仅支持定向二元关系的网络数据模型混淆，它们经常通过引入代理标识符转换为实体集。
阅读非二元关系的基数指标是一个常见的混淆来源。请参阅我对 designing relationship between vehicle,customer and workshop in erd diagram 的回答有关我如何处理此问题的更多信息。
您的解决方案存在一些问题。首先，Buys 被表示为一个关联实体，但被用作具有可选角色的三元关系。我认为两者都不正确。请参阅我对 When to use Associative entities? 的回答用于解释 ER 模型中的关联实体。
将购买交易建模为关系通常是错误的，因为关系是由它们相关的实体(键)标识的。如果 (CustomerID, ProductID) 是身份识别，那么客户只能购买一次产品，并且每次交易只能购买一件产品。将日期/时间添加到关系的键中会更好，但仍然存在问题。添加代理标识符并将其转变为常规实体集几乎肯定是最佳做法。
其次，鱼尾纹基数指标不明确。看起来客户和产品在 Buys 关系中是可选的，甚至好像多个客户可能参与同一笔交易。这里涉及三个不同的概念——可选性、参与性和基数——最好用不同的方式来表示。请参阅我对 is optionality (mandatory, optional) and participation (total, partial) are same? 的回答有关该主题的更多信息。
对于购买交易，卡是可选的。从描述来看，卡似乎可以完全参与，这意味着我们不会存储有关卡的信息，除非它用于交易。此外，每笔交易只能关联一张卡。
购买交易需要客户，听起来客户可能会完全参与，这意味着我们不会存储有关客户的信息，除非他们购买了东西。每笔交易只能关联一个客户。
购买交易需要产品，由于我们会在购买前提供产品，因此产品将部分参与交易。但是，每笔交易可以关联多个产品。
我会用类似以下结构的东西表示这个问题的交易:
我并不是说将三元或更高级别的关系转换为实体集总是正确的做法，但在这种情况下是正确的。
在物理上，这需要两个表来表示(不包括客户、产品、卡或产品评论)，因为我们可以将 TransactionCustomer 和 TransactionCard 非规范化为 Transaction，但 TransactionProduct 是多对多关系并且需要它自己的表(如做三元和更高的关系)。
Transaction (TransactionID PK, TransactionDateTime, CustomerID, CardID nullable)
TransactionProduct (TransactionID PK, ProductID PK, Quantity, Price)
关于database - ERD 行动可以或应该涉及 2 个以上的实体吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47117349/