Question

这是我的示例类图

cls_Invoice = {InvoiceID：int，InvoiceDate：Date，InvoiceProduct： cls_Products };

cls_Products = {ProductID：int，StockQuantity：double，Price：double};

数据库表

Invoice = {InvoiceID，InvoiceDate};产品= {ProductID，StockQuantity，Price};

1发票有很多产品 1个产品可以在多个发票中所以最终ER设计中会有一个链接，如下所示

Invoice_Products = {InvoiceID，ProductID，Qty，Price}

但现在还有另外两个属性Qty和Price，我不知道在绘制类图时请咨询一下吗？

Answer 1

在UML类图中，您有两个类：Invoice和Product。 Invoice有两个属性：InvoiceID和InvoiceDate，Product有三个属性：ProductID，StockQuantity和Price。在这两个类之间，你需要一个关联，两端都有1 .. *的多重性。

Answer 2

虽然我对购物应用程序不是很熟悉，但是当我想到它时，我会想到这些点：

销售商品/产品应该有另一个概念，而不是商品/产品。因为，“产品概念”应该独立于“可以对产品做什么”。例如，销售产品与产品本身的概念不同。因此，您可能有另一个类，如orderItem。

class product {
    Long productId
    String productName
    ...
} 

class orderItem{
      Product soldProduct;
      Invoice itsInvoice;

      public Invoice getItsInvoice();

}

class Invoice {
    Long invoiceNumber;
    List<OrderItem> orderItem;

}

如果您这样做，那么每个订单商品只属于一个发票，而发票可能有许多订单商品。因此，ivoice和订单项之间存在一对多的关系，以及oreritem和product之间的一对一关系。

即便如此，如果您仍然只使用两个实体，发票和产品，这意味着您将“产品”和“销售产品”的概念结合在一个实体中，那么发票和产品之间的关系仍然是一对一 - 不是多对多。因为，两者之间的关系是通过“销售产品”。在这种情况下，“已售出的产品”仅属于一张发票。

但是，第一种方法对我来说似乎更好。

Answer 3

这是一对多的方案，而不是多对多的方案。同一产品不能成为许多发票的一部分。

UML混淆了很多场景

3 个答案: