I have a lot of experience in jumping to developing an application without thinking thoroughly about structure of database. Of course, this doesn’t end well. Whenever I have to make spontaneous changes in the database, it’s nearly impossible to remember which is related to which. After few months, I almost forgot what the schema of the database looks like. But…
Entity relationship model comes to rescue!
This model essentially summarise and visualise what tables we have, what attributes those tables have, and how those tables are referenced/related to each other. It’s helpful for concretely modelling data rather than with just documentation. It also helps developers (either application and database ones) understand the schema of the entire database, which is not always easy because these people often work in different workflow. It’s also helpful to come back in after few months and still understand what how the database is structured and then understand the models and controllers in a typical applications. This is also useful for testing because there’re so many times I misspelled attribute and only find that out when the application crashes few days after. Very few tutorials, however, mention models and jump directly to coding, which is okay for a small projects but sometimes the instructors themselves lose sense of how the database looks like!
How does entity relationship model look like?
There’re a lot of technicalities about this ER modelling. But here are three things you should get stated with:
Entity (name of tables)
Relationship (semantic labels of how entities are associated)
Multiplicity (restrictions for relationships - the number of possible rows in one table can be associated with ONE row in another table)
Pretty simple, isn’t it? I find it really easy to learn about database via a typical example. I have been thinking about a tag-only note-taking system, so let’s start from there.