可以在逻辑 ER 图中表示多对一关系吗？

Question

I have a particular problem from my assignment which goes like this:

"Each product making up a set is supplied by a single supplier and is given a unique ID,. Products are always sold as part of a set, never on their own."

So based on this is assumed Many Products creates One Package(aka set), but i don't know if i'm right, if so how can I visually show a Many to One relationship as an ER diagram.

I have constructed my own Conceptual and Logical ER diagram, I just need to know if i'm right or wrong so that i can continue with the rest.

Answer 1

According to your description your schema will have one to many relation ie your single package comprises many products.

You can also find out your ERD diagram

Answer 2

Here's a breakdown of the assignment and what I get from it:

Each product making up a set is supplied by a single supplier and is given a unique ID,. Products are always sold as part of a set, never on their own.

From this I get that we have these entities:

1. Product
2. Supplier
3. Package (Set)

You should know that each Entity needs its own primary key. Pros will either call this id, or product_id. There are ORM's that tend to work best out of the box, if you name the pk for each table 'id', especially when it is a simple sequence number.

It's also better not to do what you are doing with attribute names. In sql people stick with either all uppercase or all lowercase naming rather than camelcase. Also I'd suggest that you don't name the price attribute pPrice just because it's in the Package table. Just name it price, because it can be referred to as Package.price if you need to tell it apart from some other table that also contains a price column.

The important thing to understand is that the relationship between Package and Product is Many to Many

1. One Product can be part of Many Packages.
2. One Package can contain Many Products

In order to create entities for a Many to Many relationship, you need a table that sits between the 2 tables and will have foreign keys to both tables in it. Typically people will pick whatever they consider the dominant side -- I would probably use Package, and name the table "PackageProduct" to reinforce the idea that this table lets me package products together and sell or distribute them.

PackageProduct
--------------
id (pk)
package_id (foreign key to Package table)
product_id (foreign key to Product table)

You also need a supplier table, but you were informed that the relationship between Package and supplier is that a Package can have one and only one Supplier.

This is code for: create a one to many relationship between Supplier and Package. In doing this, Package will have a foreign key in it that stores the Supplier.id (or supplier_id)

So to conclude you should have these entities (tables):

1. Package
2. Product
3. Supplier
4. PackageProduct

ERD

Here's an ERD rendered with "Relational" format which I find a bit more descriptive, as the many sides of the connections use the crowsfoot, so it's very obvious.