An ER diagram in DBMS (database management systems) is a lot like a storyboard for an animated TV show – it’s a collection of diagrams that show how everything fits together. Where a storyboard demonstrates the flow from one scene to the next, an ER diagram highlights the components of your databases and the relationships they share.
Understanding the ER model in DBMS is the first step to getting to grips with basic database software (like Microsoft Access) and more complex database-centric programming languages, such as SQL. This article explores ER diagrams in detail.
ER Model in DBMS
An ER diagram in DBMS is a tangible representation of the tables in a database, the relationships between each of those tables, and the attributes of each table. These diagrams feature three core components:
- Entities – Represented by rectangles in the diagram, entities are objects or concepts used throughout your database.
- Attributes – These are the properties that each entity possesses. ER diagrams use ellipses to represent attributes, with the attributes themselves tending to be the fields in a table. For example, an entity for students in a school’s internal database may have attributes for student names, birthdays, and unique identification numbers.
- Relationships – No entity in an ER diagram is an island, as each is linked to at least one other. These relationships can take multiple forms, with said relationships dictating the flow of information through the database.
Mapping out your proposed database using the ER model is essential because it gives you a visual representation of how the database works before you start coding or creating. Think of it like the blueprint you’d use to build a house, with that blueprint telling you where you need to lay every brick and fit every door.
Entities in DBMS
An Entity in DBMS tends to represent a real-life thing (like the students mentioned previously) that you can identify with certain types of data. Each entity is distinguishable from the others in your database, meaning you won’t have multiple entities listing student details.
Entities come in two flavors:
- Tangible Entities – These are physical things that exist in the real world, such as a person, vehicle, or building.
- Intangible Entities – If you can see and feel an entity, it’s intangible. Bank accounts are good examples. We know they exist (and have data attributed to them) but we can’t physically touch them.
There are also different entity strengths to consider:
- Strong Entities – A strong entity is represented using a rectangle and will have at least one key attribute attached to it that allows you to identify it uniquely. In the student example we’ve already shared, a student’s ID number could be a unique identifier, creating a key attribute that leads to the “Student” entity being strong.
- Weak Entities – Weak entities have no unique identifiers, meaning you can’t use them alone. Represented using double-outlined rectangles, these entities rely on the existence of strong entities to exist themselves. Think of it like the relationship between parent and child. A child can’t exist without a parent, in the same way that a weak entity can’t exist without a strong entity.
Once you’ve established what your entities are, you’ll gather each specific type of entity into an entity set. This set is like a table that contains the data for each entity in a uniform manner. Returning to the student example, any entity that has a student ID number, name, and birthdate, may be placed into an overarching “Student” entity set. They’re basically containers for specific entity types.
Check out OPIT degrees
-
Career aligned
-
Fully Online
-
EU-accredited institution
Attributes in DBMS
Every entity you establish has attributes attached to it, as you’ve already seen with the student example used previously. These attributes offer details about various aspects of the entity and come in four types:
- Simple Attributes – A simple attribute is any attribute that you can’t break down into further categories. A student ID number is a good example, as this isn’t something you can expand upon.
- Composite Attributes – Composite attributes are those that may have other attributes attached to them. If “Name” is one of your attributes, its composites could be “First Name,” “Surname,” “Maiden Name,” and “Nickname.”
- Derived Attributes – If you can derive an attribute from another attribute, it falls into this category. For instance, you can use a student’s date of birth to derive their age and grade level. These attributes have dotted ellipses surrounding them.
- Multi-valued Attributes – Represented by dual-ellipses, these attributes cover anything that can have multiple values. Phone numbers are good examples, as people can have several cell phone or landline numbers.
Attributes are important when creating an ER model in DBMS because they show you what types of data you’ll use to populate your entities.
Relationships in DBMS
As your database becomes more complex, you’ll create several entities and entity sets, with each having relationships with others. You represent these relationships using lines, creating a network of entities with line-based descriptions telling you how information flows between them.
There are three types of relationships for an ER diagram in DBMS:
- One-to-One Relationships – You’ll use this relationship when one entity can only have one of another entity. For example, if a school issues ID cards to its students, it’s likely that each student can only have one card. Thus, you have a one-to-one relationship between the student and ID card entities.
- One-to-Many Relationships – This relationship type is for when one entity can have several of another entity, but the relationship doesn’t work in reverse. Bank accounts are a good example, as a customer can have several bank accounts, but each account is only accessible to one customer.
- Many-to-Many Relationships – You use these relationships to denote when two entities can have several of each other. Returning to the student example, a student will have multiple classes, with each class containing several students, creating a many-to-many relationship.
These relationships are further broken down into “relationship sets,” which bring together all of the entities that participate in the same type of relationship. These sets have three varieties:
- Unary – Only one entity participates in the relationship.
- Binary – Two entities are in the relationship, such as the student and course example mentioned earlier.
- n-ary – Multiple entities participate in the relationship, with “n” being the number of entities.
Your ER diagram in DBMS needs relationships to show how each entity set relates to (and interacts with) the others in your diagram.
ER Diagram Notations
You’ll use various forms of notation to denote the entities, attributes, relationships, and the cardinality of those relationships in your ER diagram.
Entity Notations
Entities are denoted using rectangles around a word or phrase, with a solid rectangle meaning a strong entity and a double-outlined rectangle denoting a weak entity.
Attribute Notations
Ellipses are the shapes of choice for attributes, with the following uses for each attribute type:
- Simple and Composite Attribute – Solid line ellipses
- Derived Attribute – Dotted line ellipses
- Multi-Valued Attribute – Double-lined ellipses
Relationship Notations
Relationship notation uses diamonds, with a solid line diamond depicting a relationship between two attributes. You may also find double-lined diamonds, which signify the relationship between a weak entity and the strong entity that owns it.
Cardinality and Modality Notations
These lines show you the maximum times an instance in one entity set can relate to the instances of another set, making them crucial for denoting the relationships inside your database.
The endpoint of the line tells you everything you need to know about cardinality and ordinality. For example, a line that ends with three lines (two going diagonally) signifies a “many” cardinality, while a line that concludes with a small vertical line signifies a “one” cardinality. Modality comes into play if there’s a minimum number of instances for an entity type. For example, a person can have many phone numbers but must have at least one.
Steps to Create an ER Diagram in DBMS
With the various notations for an ER diagram in DBMS explained, you can follow these steps to draw your own diagram:
- Identify Entities – Every tangible and intangible object that relates to your database is an entity that you need to identify and define.
- Identify Attributes – Each entity has a set of attributes (students have names, ID numbers, birthdates, etc.) that you must define.
- Identify Relationships – Ask yourself how each entity set fits together to identify the relationships that exist between them.
- Assign Cardinality and Modality – If you have an instance from Entity A, how many instances does it relate to in Entity B? Is there a minimum to consider? Assign cardinalities and modalities to offer the answers.
- Finalize Your Diagram – Take a final pass over the diagram to ensure all required entities are present, they have the appropriate attributes, and that all relationships are defined.
Examples of ER Diagrams in DBMS
Once you understand the basics of the ER model in DBMS, you’ll see how they can apply to multiple scenarios:
- University Databases – A university database will have entities such as “Student,” “Teacher,” “Course,” and “Class.” Attributes depend on the entity, with the people-based entities having attributes including names, dates of birth, and ID numbers. Relationships vary (i.e., a student may only have one teacher but a single teacher may have several students).
- Hospital Management Databases – Entities for this type of database include people (“Patients,” “Doctors,” and “Nurses”), as well as other tangibles, such as different hospital buildings and inventory. These databases can get very complex, with multiple relationships linking the various people involved to different buildings, treatment areas, and inventory.
- E-Commerce Databases – People play an important role in the entities for e-commerce sites, too, because every site needs a list of customers. Those customers have payment details and order histories, which are potential entities or attributes. Product lists and available inventory are also factors.
Check out OPIT degrees
-
Career aligned
-
Fully Online
-
EU-accredited institution
Master the ER Model in DBMS
An ER diagram in DBMS can look like a complicated mass of shapes and lines at first, making them feel impenetrable to those new to databases. But once you get to grips with what each type of shape and line represents, they become crucial tools to help you outline your databases before you start developing them.
Application of what you’ve learned is the key to success with ER diagrams (and any other topic), so take what you’ve learned here and start experimenting. Consider real-world scenarios (such as those introduced above) and draw diagrams based on the entities you believe apply to those scenarios. Build up from there to figure out the attributes and relationships between entity sets and you’re well on your way to a good ER diagram.
