Changes between Version 17 and Version 18 of Conceptual Design – ER Diagram and Data Requirements


Ignore:
Timestamp:
08/28/25 18:31:11 (5 days ago)
Author:
221531
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Conceptual Design – ER Diagram and Data Requirements

    v17 v18  
    147147* Address → Restaurant  \\
    148148    **''is_located_at''** – a relation which indicates that a restaurant is located at one location, and a location can have only 1 restaurant.
     149
     150* Admin → App User  \\
     151    **''manages''** – a relation which indicates that an admin is responsible for management of many users and a user is managed by a single admin.
    149152=== 1:M ===
    150153
    … …  
    164167    **''receives''** – a relation which indicates that a restaurant can have multiple earnings, and an earning belongs to one restaurant.
    165168\\
    166 * Menu → Item  \\
    167     **''contains''** – a relation which indicates that a menu can have multiple items, and an item can belong to one menu.
    168 
     169* Restaurant → Order\\
     170    **''resaturant_order''** – a relation which indicates that a restaurant can have multiple orders, and an order belongs to one restaurant.
     171\\
     172* Delivery Man → Order\\
     173    **''resaturant_order''** – a relation which indicates that a delivery man can have multiple orders, and an order belongs to one delivery man.
     174\\
    169175=== M:N ===
    170 * User ↔ User Adresses ↔ Address  \\
    171     **Junction: ** User Adresses solves M:N relation of User and Address, by storing the composite key (user_id, address_id)\\
    172 
    173     **''has''** – relation between User and User Addresses where a user can have multiple addresses.\\
    174 
    175     **''belongs''** – relation between Address and User Addresses where an address can belong to multiple users.\\
     176* User ↔ User Addresses ↔ Address  \\
     177    **Junction: ** User Addresses solves M:N relation of User and Address, by storing the composite key (user_id, address_id)\\
     178
     179    **''has''** – relation between User and Address where a user can have multiple addresses and an address can belong to multiple users.\\
    176180\\
    177181* Order ↔ Order Items ↔ Item  \\
    178182    **Junction: ** Order Items solves M:N relation of Order and Item, by storing the composite key (order_id, item_id)\\
    179183
    180     **''has''** – relation between Order and Order Items where an order can have multiple items.\\
    181 
    182     **''belongs''** – relation between Item and Order Items where an item can belong to multiple orders.\\
     184    **''has''** – relation between Order and Item where an order can have multiple items and an item can belong to multiple orders.\\
    183185\\
    184186* Delivery Man ↔ Delivery Assignment ↔ Delivery Firm \\
    185187    **Junction: ** Delivery Assignment solves M:N relation of Delivery Man and Delivery Firm, by storing the composite key (deliveryman_id, deliveryfirm_id)\\
    186188
    187     **''assigned''** – relation between Delivery Man and Delivery Assignment where a delivery man can be assigned to multiple firms.\\
    188 
    189     **''contracts''** – relation between Delivery Firm and Delivery Assignment, where a delivery firm can contract multiple delivery mans.\\
     189    **''assigned''** – relation between Delivery Man and Delivery Firm where a delivery man can be assigned to multiple firms and a firm can have multiple delivery men.\\
     190
    190191\\
    191192* Restaurant Owner ↔ Restaurant Owners ↔ Restaurant \\
    192193    **Junction: ** Restaurant Owners solves M:N relation of Restaurant Owner and Restaurant, by storing the composite key (user_id, restaurant_id)\\
    193194
    194     **''owns''** – relation between Restaurant Owner and Restaurant Owners where a user can be own multiple restaurants.\\
    195 
    196     **''has''** – relation between Restaurant and Restaurant Owners, where a restaurant can have multiple owners.\\
     195    **''owns''** – relation between Restaurant Owner and Restaurant where a restaurant owner can own multiple restaurants and a restaurant can have multiple owners.\\
     196
    197197\\
    198198* Item ↔ Item Ingredient ↔ Ingredient\\
    199199    **Junction: ** Item Ingredient solves M:N relation of Item and Ingredient, by storing the composite key (item_id, ingredient_id)\\
    200200
    201     **''contains''** – relation between Item and Item Ingredient where an item can have multiple ingredients.\\
    202 
    203     **''is_part_of''** – relation between Ingredient and Item Ingredient, where an ingredient can belong to multiple items.\\
     201    **''contains''** – relation between Item and Ingredient where an item can have multiple ingredients and an ingredient can belong to multiple items.\\
    204202\\
    205203* Item ↔ Item Category ↔ Category\\
    206204    **Junction: ** Item Category solves M:N relation of Item and Category, by storing the composite key (category_id, item_id)\\
    207205
    208     **''belongs''** – relation between Item and Item Category where an item can belong to multiple categories.\\
    209 
    210     **''has''** – relation between Category and Item Category, where a category can have multiple items.\\
     206    **''has''** – relation between Item and Category, where a category can have multiple items and an item can belong to multiple categories.\\
    211207\\
    212208* Restaurant ↔ Restaurant Category ↔ Category\\
    213209    **Junction: ** Restaurant Category solves M:N relation of Restaurant and Category, by storing the composite key (category_id, restaurant_id)\\
    214210
    215     **''belongs''** – relation between Restaurant and Restaurant Category where a restaurant can belong to multiple categories.\\
    216 
    217     **''has''** – relation between Category and Restaurant Category, where a category can have multiple restaurants.\\
    218 \\
    219 * Order ↔ Delivery Man ↔ Restaurant \\
    220     **Junction**: A ternary relationship exists because an Order links the Restaurant where it was placed and a Delivery Man who delivers it.\\
    221     **''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.
     211    **''has''** – relation between Category and Restaurant Category, where a category can have multiple restaurants, and a restaurant can belong to mutliple categories.\\
     212\\
     213* Menu ↔ Menu Item ↔ Item\\
     214    **Junction: ** Menu Item solves M:N relation of Menu and Item, by storing the composite key (menu_id, item_id)\\
     215
     216    **''contains''** – relation between Menu and Item where an item can belong to many menu's and a menu can have many items.\\
     217