In this section we will discuss domain modelling of the application. In the previous post we had a basic overview about the business requirement of the application which is not enough of course. So, we will try to discuss each domain of the project. For a clear understanding you can always refer the below ER diagram. I think the diagram is enough to give you what we will try to achieve in the application.
- Each region consists of many locations. Each region is identified by the region_id primary key.
- Each location again is identified by the location_id and there can be several locations belong to a single region.
- Then we have the university entity . Each university entity is uniquely identified by university_id and there is a foreign key relationship to location entity through location_id.
- Then we have the college. There can be several college under a single university and each college also has a foreign key relationship to location entity through location_id.
- Then we have department, student and faculty entities.
- The important thing to consider here is the join table. The join table between student and faculty says that there is a M-N mapping between these two types. Means any faculty can have multiple students and a single student can be trained under multiple faculties.
So, this join table maintains the mapping.
This was all about our domain modelling. This is enough to kick start our application.
- Spring Boot – University Book Keeping App , Part – 2 - January 14, 2017
- Spring Boot – University Book Keeping App , Part – 1 - January 14, 2017
- Spring Boot – University Book Keeping App - January 14, 2017
- A Shoot at Permgen & Metaspace - January 14, 2017
- Spark – Shell - January 2, 2017
- Spark – Concepts - January 2, 2017
- Spark – Sample Application in Windows - December 31, 2016
- MyBatis – Components - June 17, 2016
- Castor – Default Mapping - June 17, 2016