6 Replies - 711 Views - Last Post: 26 July 2014 - 04:03 PM Rate Topic: -----

#1 abdul rahman sharifi  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 4
  • Joined: 24-July 14

ERD for supermarket

Posted 24 July 2014 - 08:34 AM

I am sucked how to create an effective ERD any idea how to create ERD for a supermarket that has 5 entity, [Employee],[Customer],[Purchase],[Product],[Sale]
Is This A Good Question/Topic? 0
  • +

Replies To: ERD for supermarket

#2 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 9497
  • View blog
  • Posts: 35,844
  • Joined: 12-June 08

Re: ERD for supermarket

Posted 24 July 2014 - 08:37 AM

What have you tried, thought about, or sketched out?

Please be cognizant of our policy on doing the work for you.
Was This Post Helpful? 0
  • +
  • -

#3 abdul rahman sharifi  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 4
  • Joined: 24-July 14

Re: ERD for supermarket

Posted 25 July 2014 - 01:10 AM

i did like this

Attached File(s)

  • Attached File  ERD.pdf (87.68K)
    Number of downloads: 78

Was This Post Helpful? 0
  • +
  • -

#4 nullReference  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 12
  • Joined: 23-July 14

Re: ERD for supermarket

Posted 25 July 2014 - 01:51 PM

You've got a decent start. I believe the file provided is what you are looking for. This is a model for many different supermarkets which reads as follows:

> One supermarket can have many employees
> One supermarket can have many products
> One supermarket can have many customers
> One customer can have many purchases
> One product can be purchased many times

I believe where you were running into an issue was with the many-to-many relationship between customers and products since in reality many customers can purchase many products. To solve this we use what is called a junction table which transforms the disgusting M:M relationship into a series of 1:M relationships in a seprate table. This allows for nice, clean, normalized data that is easily accessible.

Attached File(s)


Was This Post Helpful? 0
  • +
  • -

#5 abdul rahman sharifi  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 4
  • Joined: 24-July 14

Re: ERD for supermarket

Posted 26 July 2014 - 08:28 AM

Dear NullReference,
thanks for helping should i go true your sent help.pdf or it need more edition.
we do not need for sale table?
Was This Post Helpful? 0
  • +
  • -

#6 nullReference  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 12
  • Joined: 23-July 14

Re: ERD for supermarket

Posted 26 July 2014 - 09:10 AM

I see no reason to have a sale table. This being due to the fact that you can obtain
sale information from the purchase table for each customer or product. Then if you needed
to find all purchases for any given supermarket you would use a join such as

SELECT prod.pname
FROM supermarket as super
JOIN product as prod
ON super.SuperMarketID = prod.SuperMarketID
JOIN purchase as purch
ON prod.product_id = purch.product_id
JOIN customer as cust
ON purch.customer_id = cust.customer_id
WHERE super.SuperMarketID = 'SOME ID'



This would give you all sale information for any given SuperMarketID

I believe the information you were wanting to store in the "Sale" table is what
is being represented by the purchase junction table. If you want to track cost/tax/date etc
you could place this data in the purchase table. If your not worried about logging cost at a
specific time you could even place cost in product table and eliminate some duplicate data as
I'm sure you'll want to have a price column in the product table.
Was This Post Helpful? 0
  • +
  • -

#7 abdul rahman sharifi  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 4
  • Joined: 24-July 14

Re: ERD for supermarket

Posted 26 July 2014 - 04:03 PM

thanks
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1