diff --git a/02_assignments/CustomerAddress(OverwriteVsRetain).png b/02_assignments/CustomerAddress(OverwriteVsRetain).png
new file mode 100644
index 000000000..b52557594
Binary files /dev/null and b/02_assignments/CustomerAddress(OverwriteVsRetain).png differ
diff --git a/02_assignments/EmployeeShifts.png b/02_assignments/EmployeeShifts.png
new file mode 100644
index 000000000..deff89d7c
Binary files /dev/null and b/02_assignments/EmployeeShifts.png differ
diff --git a/02_assignments/SmallBookstoreSQLAssignment_1.png b/02_assignments/SmallBookstoreSQLAssignment_1.png
new file mode 100644
index 000000000..720fa75f2
Binary files /dev/null and b/02_assignments/SmallBookstoreSQLAssignment_1.png differ
diff --git a/02_assignments/design_a_logical_model.md b/02_assignments/design_a_logical_model.md
index 054ea5c41..8059aeea0 100644
--- a/02_assignments/design_a_logical_model.md
+++ b/02_assignments/design_a_logical_model.md
@@ -5,17 +5,54 @@ Create a logical model for a small bookstore. 📚
 
 At the minimum it should have employee, order, sales, customer, and book entities (tables). Determine sensible column and table design based on what you know about these concepts. Keep it simple, but work out sensible relationships to keep tables reasonably sized. Include a date table. There are several tools online you can use, I'd recommend [_Draw.io_](https://www.drawio.com/) or [_LucidChart_](https://www.lucidchart.com/pages/).
 
+[Small_Bookstore_ERD](SmallBookstoreSQLAssignment_1.png)
+
 ## Question 2
 We want to create employee shifts, splitting up the day into morning and evening. Add this to the ERD.
 
+[EmployeeShifts](EmployeeShifts.png)
+
 ## Question 3
 The store wants to keep customer addresses. Propose two architectures for the CUSTOMER_ADDRESS table, one that will retain changes, and another that will overwrite. Which is type 1, which is type 2?
 
+[CustomerAddressesOverwriteVsRetain](CustomerAddress(OverwriteVsRetain).png)
+
+Architectures for CUSTOMER_ADDRESS Table
+Type 1: Overwrite Changes
+The following design overwrites the address whenever there is a change:
+
+CustomerAddress
+AddressID (Primary Key)
+CustomerID (Foreign Key)
+AddressLine1
+AddressLine2
+City
+State
+PostalCode
+Country
+
+
+Type 2: Retain Changes
+The following design retains the historical addresses by storing the start and end dates:
+
+CustomerAddress
+AddressID (Primary Key)
+CustomerID (Foreign Key)
+AddressLine1
+AddressLine2
+City
+State
+PostalCode
+Country
+StartDate
+EndDate (It indicates the current address when null)
+
 _Hint, search type 1 vs type 2 slowly changing dimensions._
 
 Bonus: Are there privacy implications to this, why or why not?
 ```
-Your answer...
+Yes, there are privacy implications. Storing historical addresses can lead to privacy concerns, especially if the data needs to be handled properly. It could expose customers' previous residences, which is sensitive information.
+
 ```
 
 ## Question 4
@@ -23,7 +60,14 @@ Review the AdventureWorks Schema [here](https://i.stack.imgur.com/LMu4W.gif)
 
 Highlight at least two differences between it and your ERD. Would you change anything in yours?
 ```
-Your answer...
+1. Complexity and Scope
+   - AdventureWorks schema is more complex with many more entities, including detailed tables for functions like 'Production', 'Sales', 'HumanResources', etc. The bookstore schema is much simpler, focusing on core entities like employees, orders, sales, customers, and books.
+
+2. Normalization
+   - AdventureWorks schema is highly normalized with many relationships and reference tables. The bookstore schema is relatively straightforward, with fewer tables and relationships, focusing on essential business functions.
+
+3. Reflection
+The differences highlight the varying needs and scales of businesses. AdventureWorks is designed for a larger, more complex organization, whereas the model for the bookstore is simpler and more suitable for a smaller company. If the bookstore grows, it may require additional tables and normalization similar to AdventureWorks to manage complexity effectively.
 ```
 
 # Criteria
@@ -44,9 +88,9 @@ Your answer...
     * Open a private window in your browser. Copy and paste the link to your pull request into the address bar. Make sure you can see your pull request properly. This helps the technical facilitator and learning support staff review your submission easily.
 
 Checklist:
-- [ ] Create a branch called `model-design`.
-- [ ] Ensure that the repository is public.
-- [ ] Review [the PR description guidelines](https://github.com/UofT-DSI/onboarding/blob/main/onboarding_documents/submissions.md#guidelines-for-pull-request-descriptions) and adhere to them.
-- [ ] Verify that the link is accessible in a private browser window.
+- [X] Create a branch called `model-design`.
+- [X] Ensure that the repository is public.
+- [X] Review [the PR description guidelines](https://github.com/UofT-DSI/onboarding/blob/main/onboarding_documents/submissions.md#guidelines-for-pull-request-descriptions) and adhere to them.
+- [X] Verify that the link is accessible in a private browser window.
 
 If you encounter any difficulties or have questions, please don't hesitate to reach out to our team via our Slack at `#cohort-3-help`. Our Technical Facilitators and Learning Support staff are here to help you navigate any challenges.