Changes between Version 4 and Version 5 of Conceptual Design – ER Diagram and Data Requirements

Timestamp:

08/26/25 13:37:25 (7 days ago)

Author:

221531

Comment:

--

Conceptual Design – ER Diagram and Data Requirements

@@ -113 +113 @@
 * Customer → Order  \\
     **''has''** – a relation which indicates that a user can have multiple addresses, and an address 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 of User and Address, by storing the composite key (user_id, address_id)\\
+    **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.\\
@@ -121 +136 @@
     **''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 ↔ Delivery Assignment ↔ Delivery Firm \\
+    **Junction: ** Delivery Assignment solves M:N relation of Delivery and Delivery Firm, by storing the composite key (delivery_id, deliveryfirm_id)\\
+
+    **''assigned''** – relation between Delivery and Delivery Assignment where a delivery can be assigned to multiple firms.\\
+
+    **''contracts''** – relation between Delivery Firm and Delivery Assignment, where a delivery firm can contract multiple deliveries.\\
+\\
+* 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.\\