wiki:Conceptual Design – ER Diagram and Data Requirements

Version 7 (modified by 221531, 7 days ago) ( diff )

--

ER Diagram

Data Requirements

Entities

1. User - Entity for all users in the system

  • user_id – primary key, numeric, required
  • first_name – text type, required
  • last_name - text type, required
  • phone- text type, required
  • email- text type, required
  • password - text type, required

2. Customer

  • (No extra attributes, inherits from User)

3. Delivery Man

  • (No extra attributes, inherits from User)

4. Restaurant Owner

  • (No extra attributes, inherits from User)

5. Order

  • order_id – primary key, numeric, required
  • order_date – date, required
  • status - text type, required
  • comment- text type, required

6. Order Items

  • order_id - foreign key, required
  • item_id - foreign key, required
  • quantity - numeric type, required
  • total_price- numeric type, required

7. Item

  • item_id - primary key, numeric, required
  • name- text type, required
  • description - text type, required
  • price - numeric type, required
  • image_url - text type, optional

8. Menu

  • menu_id- primary key, numeric, required
  • name- text type, required
  • created_at - date, required
  • updated_at- date, required

9. Restaurant

  • restaurant_id - primary key, numeric, required
  • name - text type, required
  • email - text type, required
  • phone_number - text type, required
  • website_url - text type, required
  • opening_time - time, required
  • closing_time - time, required

10. Restaurant Owners

  • restaurantowner_id - foreign key, required
  • restaurant_id - foreign key, required

11. Delivery Assignment

  • deliveryfirm_id - foreign key, required
  • deliveryman_id - foreign key, required
  • start_date - date, required
  • end_date - date, required

12. Delivery Firm

  • firm_id - primary key, numeric, required
  • name - text type, required

13. Earnings

  • earning_id - primary key, numeric, required
  • date - date, required
  • source - text type, required
  • amount- numeric type, required

14. Costs

  • cost_id- primary key, numeric, required
  • date - date, required
  • type - text type, required
  • amount- numeric type, required

15. Item Ingredient

  • item_id - foreign key, required
  • ingredient_id - foreign key, required
  • quantity - numeric type, required

16. Ingredient

  • ingredient_id - primary key, numeric, required
  • name - text type, required

Relations

1:1

  • Restaurant → Menu

has – a relation which indicates that a restaurant has one menu and a menu belongs to only one restaurant.

  • Address → Restaurant

is_located_at – a relation which indicates that a restaurant is located at one location, and a location can have only 1 restaurant.

1:M

  • Customer → Order

places – a relation which indicates that a user can have place many orders, and an order can belong to one user.


  • Address → Order

is_delivered_to – a relation which indicates that an address can have multiple orders, and an order can be delivered to one address.


  • Restaurant → Costs

spends_on – a relation which indicates that a restaurant can have multiple costs, and a cost belongs to one restaurant.


  • Restaurant → Earnings

receives – a relation which indicates that a restaurant can have multiple earnings, and an earning belongs to one restaurant.


  • Menu → Item

contains – a relation which indicates that a menu can have multiple items, and an item can belong to one menu.

M:N

  • User ↔ User Adresses ↔ Address

Junction: User Adresses solves M:N relation of User and Address, by storing the composite key (user_id, address_id)

has – relation between User and User Addresses where a user can have multiple addresses.

belongs – relation between Address and User Addresses where an address can belong to multiple users.


  • Order ↔ Order Items ↔ Item

Junction: Order Items solves M:N relation of Order and Item, by storing the composite key (order_id, item_id)

has – relation between Order and Order Items where an order can have multiple items.

belongs – relation between Item and Order Items where an item can belong to multiple orders.


  • Delivery Man ↔ Delivery Assignment ↔ Delivery Firm

Junction: Delivery Assignment solves M:N relation of Delivery Man and Delivery Firm, by storing the composite key (deliveryman_id, deliveryfirm_id)

assigned – relation between Delivery Man and Delivery Assignment where a delivery man can be assigned to multiple firms.

contracts – relation between Delivery Firm and Delivery Assignment, where a delivery firm can contract multiple delivery mans.


  • Restaurant Owner ↔ Restaurant Owners ↔ Restaurant

Junction: Restaurant Owners solves M:N relation of Restaurant Owner and Restaurant, by storing the composite key (user_id, restaurant_id)

owns – relation between Restaurant Owner and Restaurant Owners where a user can be own multiple restaurants.

has – relation between Restaurant and Restaurant Owners, where a restaurant can have multiple owners.


  • Item ↔ Item Ingredient ↔ Ingredient

Junction: Item Ingredient solves M:N relation of Item and Ingredient, by storing the composite key (item_id, ingredient_id)

contains – relation between Item and Item Ingredient where an item can have multiple ingredients.

is_part_of – relation between Ingredient and Item Ingredient, where an ingredient can belong to multiple items.

Attachments (1)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.