Database design and implementation - GoJamie/PWP GitHub Wiki
📑 Chapter summary
In this section students must design and implement the database structure (mainly the data model).In this section you must implement:
- The database table structure.
- The data models (ORM)
- Data models access methods (if needed)
- Populating the database using the models you have created
- A simple testing showing that your ORM works as expected
- Understand database basics
- Understand how to use ORM to create database schema and populate a database
- Setup and configure database
- Implement database backend
- Write tests
✔️ Chapter evaluation (max 10 points)
You can get a maximum of 10 points after completing this section. More detailed evaluation is provided after each heading.📑 Content that must be included in the section
Describe your database. The documentation must include:- A name and a short description of each database model. Describe in one or two sentences what the model represents.
- An enumeration of the attributes (columns) of each model. Each attribute must include:
- Its type and restrictions (values that can take)
- A short description of the attribute whenever the name is not explicit enough. E.g. If you are describing the users of a "forum", it is not necessary to explain the attributes "name", "surname" or "address" because their meanings are obvious.
- Characteristics of this attribute (e.g. if it is unique, if it contains default values)
- Connection with other models (primary keys and foreign keys)
- Other keys
For this section you can use a visual tool to generate a diagram. Be sure that the digram contains all the information provided in the models. Some tools you can use include: https://dbdesigner.net/, https://www.lucidchart.com/pages/tour/ER_diagram_tool, https://dbdiffo.com/
✔️ Evaluation criteria(max 3 points)
You can get a maximum of 3 points after completing this section.- Design of database is coherent: 1.0
- Each model and its attributes are named: 0.5
- Details for attributes are provided (datatype, default value, characteristics etc.): 0.5
- Foreign keys follow the relationship diagram from deadline 1: 1.0
✏️ The table can have the following structure
Table name: Event
Description: The Event table stores the event.id, creator_id, and other information related to the event. It includes event.id as primary key and event.creator_id as foregin key. The structure of this table is as follows.
Name | Type | Restrictions | Description | Characteristics | Links |
---|---|---|---|---|---|
Name of the attribute | Attribute type | Values that the type can take | Description of the attribute | Uniquenes, default... | keys and foreign keys |
id | Integer | Primary_key | Unique | ||
name | String | 32 | Not Null | ||
description | String | 256 | Information about this event | Not Null | |
place | String | 32 | |||
time | DataTime | ||||
creator_id | Integer | Foreign_key | User.id |
Table name: Joinedusers
Description: The Joinedusers table stores item_id, user_id and event_id. It includes user_id and event_id as primary and foregin keys. User_id is related to id in User table, and event_id is related to id in the Event table. The structure of this table is as follows.
Name | Type | Restrictions | Description | Characteristics | Links |
---|---|---|---|---|---|
Name of the attribute | Attribute type | Values that the type can take | Description of the attribute | Uniquenes, default... | keys and foreign keys |
user_id | Integer | Primary_key & Foreign_key | Unique & Not Null | User.id | |
event_id | Integer | Primary_key & Foreign_key | Unique & Not Null | Event.id |
Table name: User
Description: The User table stores the User.id, User.name, User.location and User.picture. The User.id is the primary key. The structure of this table is as follows.
Name | Type | Restrictions | Description | Characteristics | Links |
---|---|---|---|---|---|
Name of the attribute | Attribute type | Values that the type can take | Description of the attribute | Uniquenes, default... | keys and foreign keys |
id | Integer | primary_key | Unique & Not Null | ||
picture | String | 256 | |||
name | String | 32 | Not Null | ||
location | String | 32 |
Table name: LoginUser
Description: The LoginUser table stores the id, username and password_hash. The LoginUser.id is as primary key and foregin key. The password storage should be encrypted. The structure of this table is as follows.
Name | Type | Restrictions | Description | Characteristics | Links |
---|---|---|---|---|---|
Name of the attribute | Attribute type | Values that the type can take | Description of the attribute | Uniquenes, default... | keys and foreign keys |
id | Integer | primary_key & foreign_key | User.id | ||
username | String | 32 | Index | ||
password_hash | String | 128 |
✏️ Do not forget to include a diagram presenting the relations
💻 TODO: SOFTWARE TO DELIVER IN THIS SECTION
The code repository must contain:- The ORM models and functions
- A .sql dump of a database or the .db file (if you are using SQlite). You must provide a populated database in order to test your models.
- The scripts used to generate your database (if any)
- If you are using python, the requirements.txt file.
- A README.md file containing:
- All dependencies (external libraries) and how to install them
- Define database and version utilized
- Instructions how to setup the database framework and external libraries you might have used, or a link where it is clearly explained.
- Instructions on how to setup and populate the database.
- Instruction on how to run the tests of your database.
- If you are using python a `requirements.txt` with the dependencies
NOTE: Your code MUST be clearly documented. Check Exercise 1 for examples on how to document the code.
In addition, it should be clear which is the code you have implemented yourself and which is the code that you have borrowed from other sources.
✔️ Evaluation criteria(max 4.5 points)
- Instructions to set up the database and run the tests are provided in the README.md file: 0.5
- this means there should be no undocumented extra steps in running the code/tests!
- Table in the previous section covers all implemented models: 0.25
- All properties of the table in the previous section are implemented correctly in the model (using correct types...): 0.75
- The code has clear structure and naming for variables and methods: 1.0
- Each method's implemented in the model functionality and input parameters are described in its documentation: 0.5
- Return value(s) (name, type, description for each) are documented: 0.5
- Exceptions (type, what causes it) are documented: 0.5
- Code documentation uses a consistent and clear format: 0.5
- you can use an existing documenting format (e.g. Sphinx for Python) or simply come up with your own - as long as it's consistent
✏️ You do not need to write anything in this section, just complete the implementation.
💻 Software that must be included in the section
In this course, showing that your code works is primarily your responsibility. Therefore we expect test cases that show that all of your methods work not just with correct parameters, but that they also handle error situations correctly. Tests should always cover the most common error scenarios that are easy to predict (e.g. trying to edit something that doesn't exist, trying to create duplicate primary keys etc.) Each test case has to clearly show what it tests, what test parameters it uses and finally to show that result was as expected.
You should follow the testing methodologies shown in Exercise 1.
Some guidelines for the testing:
- The code of the test MUST be commented indicating what are you testing in each case.
- For each model the test script should, at least:
- Create a new instance of the model
- Retrieve an existing instance of the model (recommended trying with different filter options)
- Update an existing model instance (if update operation is supported by this model)
- Remove an existing model from the database
- Test possible errors conditions (e.g. breaking foreign keys relations)
✔️ Evaluation criteria(max 2.5 points)
In this section you can get a maximum of 2.5 points.- The test case cover all models in the database: 1.0 (0.5 if not all methods covered / 0 if just a few methods covered)
- For each model the script should, at least:
- Create a new instance of the model
- Retrieve an existing instance of the model (recommended trying with different filter options)
- Update an existing model instance (if update operation is supported by this model)
- Remove an existing model from the database
- You should try to force errors (for instance, try to break foreign keys relations)
- For each model the script should, at least:
- Test cases cover also errors scenarios: 0.5
- The model implementation do not have errors : 1.0
✏️ You do not need to write anything here. Just complete the implementation
Task | Student | Estimated time |
---|---|---|
All | Nechir Salimi | 7 hours |
All | Bangju Wang | 7 hours |
All | Hao Ban | 7 hours |