While your design makes sense from a business point of view, you may enhance it from a database point of view so that it will work better. Please see the following: - When joining entities, we have to specify where the joins occur. In other words, the joined entities must have a common attribute that is joined to each other. - There isn’t a common in your pairs of entities for the joins to occur. To join entities, we need to have a common field between them. This allows the query to pick up matching records. - You may elaborate further in your write up (see the description and rubric on the project document). Here, you’ll have to explain the relationships both ways, that is, the modality and cardinality on both sides of each relationship, as well as the implications of these relationships. This would be similar to the discussion on student parking in the walkthrough. Doing so can sometimes help us identify problems that we can address. Part 2: Good work overall. However, some of your queries can be enhanced. Please see comments. Just for information: In Q1, another way to get the top 5 is to simply enter the number of top records you want from the menu: Design → Return - In Q1: you have to only retrieve dairy products; and hence, records where Item_Type is “Dairy”. So you can add a criterion for Item_Type as “Dairy”. This will capture all “Dairy” Item_Type records. - For Q2: we are asked to sort the results by supplier and then product. Hence, we have to place the supplier field before the product, and then include sorting for both. The results will be sorted by supplier, and then within supplier, they will be sorted by product. Page 49 - 51 of the walkthrough shows how hierarchical sorting is done. Alternatively, you can also refer to the class demo where we sorted by instructor and then class. - For Q2 and Q3: you’ll need to join the tables in order for your query results to make sense. The joins allow you to pull the matching records from both tables. Otherwise, it will do permutations. Notice that you have more results than actually exist in the tables. Recall ERDs. There should be a join between entities linking the common field (it's supplier_number in this case). Adding the tables only adds them to the query. Joining the tables will allow you to pull the matching records. Let's think about what the company wants to do with the queries. The query should not result in more records than there are in the tables, as they cannot produce records that don't exist in the actual tables. Hypothetically, if there are 50 records in the tables, these queries should not result in 500 records, since they are subsets that fulfil certain criteria. Pages 70 - 72 of the walkthrough shows how to create joins. Alternatively, you can refer to the class demo database files to see how tables are joined in a query. - in Q3, your criterion is placed on the wrong field, resulting in no results. -Q4: This needs a little bit of thinking. Supplier number is a unique field that can identify supplier records in the other tables. This is better than using supplier name to join. Similar to the principles in an ERD, it’s not a good idea to have duplicated fields. So in your new table, only the telephone number is needed in addition to supplier number. Recall that a database should reduce redundancies. There is also no need to create a brand new PK, since supplier_number can serve as the PK, although it was not defined in the other 2 tables. As we emphasised, ideally, having a PK for every table is a good idea. In reality, that’s not always the case. While it may still work without the PK. things become less efficient especially when the database becomes large.