Task 3.1 — Data Modelling

Shubhashish
2 min readJun 25, 2017

--

For the first task in third week, we had to first build the Entity Relationship (ER) Diagram for our web app. Lets revisit the app idea and prototype first:

Now, here’s the schema/ER Diagram for the web app (Expense Calculator) which we modelled:

ER Diagram for Expense Calculator (Made using PonyORM Online Editor)

To explain the above diagram, we need to observe the app prototype and the idea in which we described how things work in our app. This helped to come up with the required entities which would lay foundation for table creation. So, the entities are userinfo, group, userdata, groupadmin, and usergroupmap.

As we know, task is to calculate expense for each group member, each group will have 1 group admin, and every user can be admin of more than one groups. The entity usergroupmap links entities userinfo and group together containing information regarding which user is a member of which group.

The groupadmin entity has information about which user is the group admin. The userid is inherited from the userinfo entity which contains information such as userid and name. The group entity contains information of group names and their corresponding group ids.

The userdata entity contains information regarding the expenses which need to be calculated consisting of amount, description (optional) and date of expense.

Now to explain the relations among entities, we can understand that 1 group can be mapped with many users, and 1 user can be mapped with many groups, hence, user and usergroupmap & group and usergroupmap entities can be a many-to-many relationship each.

Similarly, between group and groupadmin, each group can have only 1 admin but each admin user can be admin of many groups. Hence, a many-to-1 relationship.

Also, between userinfo and groupadmin, each user can be admin for many groups but each admin corresponds to a single user, hence, a 1-to-many relationship.

Similarly, each user can have multiple data records for different groups on different dates, where as each userdata record will correspond to a single user who has made the expense, hence a 1-to-many relationship.

Thus, we’ve discussed how our schema will be able to capture all the information required to power our 3-screen app. This seems to be a workable schema for the app requirements.

All thanks to hasura for providing this opprotunity to develop our app :

--

--