Data Modelling!!
Task 3.1) Data Modelling
Welcome back readers!! We have reached the 3rd week of internship which is a very important week in context of the App as we are going to build the database required for our app. In the last week we covered up the Setup of the Development Environment(i.e Linux Mint 18.1), Git basics and Setting up the Hasura/Local Development.This blog covers the Data Modelling part of week 3.Lets Begin ;-)
Talking about Data,as stated by Tim Berners-Lee,
“ Data is a precious thing and will last longer than the systems themselves”.
Whichever industry you have heard of, or whatever your interests, you will almost certainly have come across a story about how “data” is changing the face of our world. It might be helping to cure a disease, boost a company’s revenue, make a building more efficient or be responsible for those targeted ads you keep seeing.In general data is another word for information.
Managing such loads of Data is not a simple job.Every bit of data is important in some or the other way. Losing or Misplacing data could certainly cause mishaps. To avoid such things , managing data is important. This task was simplified by the invention of Databases and Data Warehouses.
Talking about our topic, we have to maintain a database for securely storing each users calorie intake in a well defined and organized way so that it will be easy for us to fetch all details as and when required.
Schema Diagram
For creating the schema we were recommended to use PonyORM software. Without any ambiguity about the choice of the tool(as it was suggested by ‘Hasura’ :D),we started to get to know more about PonyORM. It basically involves drag and drop operation for the structure of the schema and simple buttons to create entities and attributes. There are options to specify the type of attribute(eg. Primary Key) and even the relationships(eg. many to one) between different entities.
For maintaining the data of our users in an organized way, after a brief discussion between me and my partner,Sayali Jawre(not a brief one actually :D)we came to a conclusion that we would be requiring 3 tables viz. the user table, the intake table and the category table.
The user table stores personal information about the user such as weight and height of the user apart from user_id which is the primary key. The remaining attributes such as bmi,req_cal will be calculated from weight and height and will be filled accordingly. The category consists of 2 attributes which are category_id and category_name which consists of 4 values viz Breakfast,Lunch,Snacks and Dinner. The Intake table stores all the calories related details. It stores the food item name , its quantity along with the date when it was consumed and the amount of calories related to it accordingly.
For a better functioning of the app we decided to include two views namely Intake_info_view and Total_intake_view.The Intake_info_view consists of overall details of users related to the calorie intake per day along with the maximum amount of calories for the user and the excess calories he had for the given day. The Total_intake_view is used for calculating the total calories of a user per day.
That’s it for this blog.Stay tuned for the next blog on Hasura API’s and Postman Collection. Till then Ciao!!
Changes for Screen 2:
For screen 2 i.e ‘Add Intake’ screen , there was a need to store a selected number of food items . For that we added a new table, i.e Meal table. Also, the need of the Category table was to identify the type of meal and store it in intake. But it was getting a bit complicated, so we decided to delete that table and instead add a column in the Intake table for storing the meal type. Also halfway through we got to know that there was no need for the views and we deleted it. The Edited schema is as follows:
