== ER Diagram
[[Image(ticket:3:FFFINAL.jpg​)]]

== 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

**17. Address**\\
* address_id - primary key, numeric, required
* city - text type, required
* street - text type, required
* postal_code - text type, required

**18. User Addresses**\\
* address_id - foreign key, required
* user_id- foreign key, 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.\\
\\
* Item ↔ Item Category ↔ Category\\
    **Junction: ** Item Category solves M:N relation of Item and Category, by storing the composite key (category_id, item_id)\\

    **''belongs''** – relation between Item and Item Category where an item can belong to multiple categories.\\

    **''has''** – relation between Category and Item Category, where a category can have multiple items.\\
\\
* Restaurant ↔ Restaurant Category ↔ Category\\
    **Junction: ** Restaurant Category solves M:N relation of Restaurant and Category, by storing the composite key (category_id, restaurant_id)\\

    **''belongs''** – relation between Restaurant and Restaurant Category where a restaurant can belong to multiple categories.\\

    **''has''** – relation between Category and Restaurant Category, where a category can have multiple restaurants.\\
\\
* Order ↔ Delivery Man ↔ Restaurant \\
    **Junction**: A ternary relationship exists because an Order links the Restaurant where it was placed and a Delivery Man who delivers it.\\
    **''places''** – relation where an Order is prepared by one restaurant but can be delivered by multiple delivery men. A Delivery Man delivers multiple orders from potentially different restaurants. Restaurant produces multiple orders that get delivered by different delivery men.