Путаница UML в сценарии «многие ко многим»

Это моя примерная диаграмма классов

cls_Invoice = {InvoiceID:int, InvoiceDate:Date, InvoiceProduct:cls_Products};

cls_Products = { ProductID:int, StockQuantity:double , Price:double};

Таблицы БД

Счет-фактура = {InvoiceID, InvoiceDate}; Товары = {Код продукта, Количество на складе, Цена};

1 В счете-фактуре много продуктов 1 Продукты могут быть во многих счетах-фактурах, поэтому в конце концов в дизайне ER будет ссылка, как показано ниже

Invoice_Products = {InvoiceID, ProductID, Кол-во, Цена}

но теперь есть еще два свойства Qty и Price, о которых я понятия не имею, как рисовать диаграмму классов, пожалуйста, посоветуйте?


database er-diagrams uml class-diagram
person f4r4    schedule 01.02.2012    source источник
comment
Это выглядит неправильно: ваша диаграмма классов говорит, что в счете есть ОДИН продукт. Какой язык вы используете? Лучше нарисуйте диаграмму, используя ваш любимый инструмент UML, или используйте, например. Ява. Я также не понимаю связи между cls_* и таблицами БД.   -  person Volker Stolz    schedule 01.02.2012
comment
Я использовал C#, но я перешел на FLEX! Я упоминаю cls, чтобы указать, что это классы, но я не понимаю, как отобразить сущность ER «многие ко многим» в диаграмму классов; Я знаю, что это наоборот диаграмма первого класса, а затем ER, но все же я пытаюсь понять, как это работает?   -  person f4r4    schedule 01.02.2012

Ответы (3)


arrow_upward
3
arrow_downward

На диаграмме классов UML у вас будет два класса: Invoice и Product. Invoice имеет два атрибута: InvoiceID и InvoiceDate, Product — три атрибута: ProductID, StockQuantity и Price. Между двумя классами вам нужна ассоциация с кратностью 1..* на обоих концах.

person gefei    schedule 02.02.2012

arrow_upward
1
arrow_downward

Хотя я не очень хорошо знаком с приложениями для покупок, но когда я думаю об этом, мне приходят в голову следующие моменты:

Для проданного предмета/продукта должна быть другая концепция, чем предмет/продукт. Потому что «концепция продукта» не должна зависеть от того, «что можно сделать с продуктом». Например, продажа продукта — это не то же самое понятие, что и сам продукт. Поэтому у вас может быть другой класс, например 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 и продуктом.

Даже если вы по-прежнему делаете это только с двумя объектами, счетом-фактурой и продуктом, что подразумевает, что вы объединяете понятия «продукт» и «продажа продукта» в одном объекте, связь между счетом-фактурой и продуктом все равно не является отношением «один ко многим». многие ко многим. Потому что отношения между ними строятся через «продажу продукта». В этом случае «проданный продукт» относится только к одному счету.

Но первый подход мне кажется лучше.

person Nazar Merza    schedule 03.02.2012

arrow_upward
-1
arrow_downward

Это сценарий «один ко многим», а не сценарий «многие ко многим». Один и тот же продукт не может быть частью нескольких счетов-фактур.

person jith912    schedule 13.09.2018