In Part 1 for ERD Case Study University Management System we discussed how can you crack any case study and convert it into DBMS . We did that step by step and had a wonderful feedback . In another article on best practices for ERD , we discussed the pitfalls that we need to avoid. Time to implement them on our ERD .
This is our Current ERD .
- Entity Research Project and Faculty has Many-to-Many relationship.
- Faculty and Course has Many-to-Many relationship.
- Student and Course has Many-To-Many relationship
- Student has multi-varied attribute
- Change multi-varied attribute into a entity.
- Create a Associative Entity and reduce many-to-many into one-to-many and pass they keys from both.
See below ERD Now .
We have following new associative entities .
- Faculty Courses
- Student Enrolled.
ERDs can get very complex and at enterprise level they are very difficult to draw and almost impossible to understand as they get so big. Consider this diagram , even though we kept it simple still it became a difficult diagram to go through. Even with this issue , it is always considered best to have a sketch.
This ERD is now ready for data modelling and after that Database Developers can code them and prepare to connect them with applications to store and retrieve data.
If you have mastered this ERD practice , to write a SQL query will be a child’s play for you . As a matter of fact , you will have a great understanding of DBMS and you’ll eventually understand about flow and management of data.
Next articles , will cover about Normalization with examples and see how a DBMS is optimised and avoids anomalies . That will be the last practical article on designing DBMS with best practices . After that we will start moving towards Query Writing and how a database engine handles all operations. Some very exciting and logical stuff is in queue.
If you have enjoyed this article or learned anything , like the post and give us feedback so that we will know how else can these articles be improved!
Stay Tuned and Happy Learning!