If you have not checked out the initial blog post for this challenge, please do so and get your development environment set up as outlined in the post.
We are working on creating test(s) for a particular course/subject. We need to have a pool of questions (related to the course/subject) that we can pick from to make up a test. A single test can be associated with several questions, but each question belongs to only one test. Through the relationship between tests and questions, one should be able to access all questions related to a specific test and easily access the specific test to which a question belongs (hint: backlink).
Additionally, we need to have a right answer for every question and a question can only have one right answer. An answer cannot exist without a question. If a question is deleted, so should the linked answer be deleted.
We will get started with database modeling using SAP CAP. We delve into the architecture, carefully defining two core entities and an aspect respectively: "Tests," "Questions," and "Answers".
Tests Entity – serves as a container for organizing different test cycles. Each entry within the Tests entity represents a unique object with attributes such as test ID, title, description, createdAt, createdBy, modifiedAt, modifiedBy and any other vital information relating to tests. A single test can have many questions. This entity allows us to categorize and manage tests efficiently, facilitating easy retrieval and presentation of tests data.
Questions Entity – serves as a repository for individual questions comprising the intellectual content of our tests. Each entry in the Questions entity comprises attributes such as ID, text, and any other vital information relating to questions. Many questions can be associated with a single test, but each question belongs to only one test (that is, two different tests cannot have the same question). Centralizing questions in this entity allows us to create a cohesive reservoir of knowledge that can be easily linked to a Test instance.
Answers Aspect– records the correct answer to a particular question. Each record in this aspect corresponds to a correct answer linked to a specific question. Each entry in the Answers aspect comprises attributes such as ID, and text. The separation of answers from questions reinforces data integrity.
Why an Aspect instead of Entity for the Answers?
Aspects are well suited for representing data that does not have a distinct identity of their own. In our schema design, the answers cannot exist without a question. For example, if a question record is deleted, we would want an answer associated with it to be deleted as well. Using an aspect in this case allows us to associate answers data directly with questions without creating a separate entity.
Our goal is to perform entity-relationship modeling based on the above entities' description and then populate initial data in csv files to be used in the next tasks. Below is a visual representation providing details (entity properties and data types) to help with the modeling.
Here are some resources to guide you through this task:
Run the application (cds watch). Note that the initial errors displayed in the terminal after our development environment setup should have disappeared.
Click on the URL that the server is listening on to access the page displayed below:
Under Service Endpoints, click on $metadata and post a screenshot into this discussion thread. Collapse other sections and focus on the <EntityType Name=”...”> tags as shown below.
Some pieces are not accurately represented in your model: