Getting started with database entity relationship:
If you are a Developer you noticed that while developing an application you forgot to include a certain field in your database or you noticed the relationship between tables was not correctly made.
Getting started with database entity-relationship is here to offer a solution.
In this article, we are going to explore and get started with the database entity relationship model, what it is all about, and how to design and interpret Entity Relationship.
This article is also going to learn how to create a basic ER model and why it is very important for a backend developer to learn it.
What’s a Database?
A database is a collection of data organized for rapid search and retrieval.
It is based on the Mathematical set theory and first-order predicate logic.
In a relational database, Data is stored in tables(relation) , rows (tuple), column(attribute).
What’s an ER model?
An Entity-Relationship Model is a Diagrammatic representation of your Database Schema (planning Phase).
It can be used to Describe Entities, Attributes of an Entity, and relationships between two or more Entities and their Cardinality.
The benefit of ER modeling
Relatively Easy to Understand: Using an ER model, You can easily Illustrate and explain the structure of a database Schema to a Client or a “non-tech inclined” person.
Maps to relational database Design: A good ER model can be easily converted to a database design.
This will prevent errors since it acts as a blueprint to guide the database designer, Database administrator, and Developer.
Aids Communication: Communication between Database Designer and Developers.
It will be easier since they have a mapped out blueprint and correction can be made even before the implementation of the database design.
Important Terminologies
Entity
An Entity is an Object, person, event, or abstraction that is relevant in the context of the data application.
It is the Object we want to model and store.
For example, if you are creating a school application, the Student table is the Entity.
They are usually represented with a plain Rectangle shape.
Attributes
An attribute is pieces of information about an Entity, the Student Entity (Table) will have attributes like name, class, etc.
The Attributes in a table are the fields of the table.
They are usually represented with an Oval shape.
Primary key
A primary key is a column that uniquely identifies a row of the table, they are usually an Oval shape with an Underlined text.
Composite Attribute
A composite attribute is an attribute that can be broken into sub-attributes.
In the diagram above the fname (first name) and lname (last name) are the sub-attributes of a name.
Multi-valued Attribute
Multi-valued Attribute are attributes that could have more than one value, for example, a student can be in more than one club,
Derived Attribute
A derived attribute is an attribute that its value will be derived from another attribute, for example, the age of a student can be derived from their date of birth.
In the student table, data of birth could be a required field from which the age field will derive its value from.
From the diagram, the has_honored attribute can be defined from the GPA attribute.
It is represented with Dotted borderlines Oval.
Total Participation
Total Participation simply implies that an Entity must be in relationship with another entity.
For example, every Class entity must be related to a Student, if a Class does not have any Student then it’s not relevant and there’s no reason to keep a record of it.
Partial Participation
Partial Participation simply implies that not all students will take all classes.
For example, a student could take only 5 classes out of 10 classes.
It is represented on an ER model with a Single line
Relationship Attribute
This is an attribute to the relationship.
In this case, a student taking a class, the relationship between the student and the class they taking is their grade.
The grade isn’t necessarily stored on the student Entity Neither is it stored on the class entity, it’s stored on the relationship.
Relationship Cardinality
It is the number of instances on an entity from a relation that can be associated with the relation.
In basic terms, it is the number of possible relationships entities can have with each other.
There can be :
- one to one relationship (1:1)
- one to many relationships (1:M)
- many to one relationship (N:1)
- many to many relationships (N: M)
- ‘M’ and “N” refers to the number of relationships
How ER can help Backend Developers.
Entity relationship is very important for a backend developer to deal with the structuring of the database to learn and understand properly.
It will aid in the understanding of the data and how it is structured even if the developer is not responsible for managing the database.
It also aids in faster application development as the data is already structured and modeled using the entity.
Applications can be developed faster and better when there is a proper database entity-relationship laid out.
Conclusion
Thanks for getting this far, you should have learned a lot about entity relationships and can be able to create an ER model and translate an ER model to a database design.
