 ER, Entity Relationship Modeling. Entity Relationship Modeling revolves around, it is developed around real world things. Those things can be innate or in-init, meaning living or non-living. A student is a living thing, a course is not something that is living. So we need to look at them, how they are related, how they work together. We will go into more details. So ER modeling, Entity Relationship Modeling. So what is an entity? Entity is a real world object. A course, a student, a university, a teacher and a set of related entities can be there, a student set. These students are the students of the same university, virtual university. They are students in the bachelor's program of a certain degree program or a master's student and so on. Similarly, the sets don't have to be disjoint. A student can be registered in a course, in a certain class and for another course, that student may be registered but using the same class. So these sets don't have to be disjoint. I think you understand or if it's a dual major, it's a dual major a student may be registered in two departments. So the sets don't have to be disjoint. Now these entities which are of real into the things they have attributes. They have the name of the student. They have the address of the student, the father name and these have domain and range. For example, the name cannot be a number and age cannot be negative phone number cannot be negative. And there are different five basic types. I will go into detail in the next slide. Let's go into the next slide. So we have these five different types of attributes over here. So we have the simple attributes, the simple attributes are atomic. They cannot be broken. For example, say it's the telephone number, mobile number, maybe it's 10 digits or it's 11 digits, but it cannot be broken. So that's the simple attribute composite attribute. I cannot identify a person based upon the first name or the last name. So I need I'm not talking with the primary composite attributes is the attribute consist of multiple attributes like the first name and the last name derived attributes. The data is not actually stored in the database. The date of birth is stored. But using the date of birth, I can calculate the age of the person with changes every day. Then I have single valued attributes. A student can have a single unique ID, right? And I can have multi value attributes. A single student can have multiple mobile phones registered in his or her name. And of course, I can have a combination of these attributes also to see that I have entities types of attributes and their combinations. That's going to more detail. So how do you identify the students or the entities based upon the keys? So I have the super key, I have the candidate key. The candidate key is a collection of attributes which uniquely identify an entry in a table. Right now, if I if I remove, if I change the attributes in the candidate key, the uniqueness is gone. And the primary key is that unique key which identify a record or entry in a table. Try to understand there's only one primary key, but there can be multiple candidate keys. These things will become clear when you look at the material. So I have this relationship, a student relationship with the course registered in that course. And of course, I have degree of relationship. The degree of relationship means that how many entities are involved in a relationship? How many entities are involved? So a student is registered in a course. So it's like a binary relationship. One course entity, student entity and the and the registration relationship. Now, cardinality is the size set size from the set theory, the different types of cardinality is one to one. So one entry entity in one set is uniquely linked with the with any other entity in the second set. For example, a person can have only one passport and a passport is assigned to one person. A country can have a single flag and a single flag is associated with only a single company, single country. I'm sorry. Then I have this one to many, one to many. So you see that over here, I have this entity, okay, which is associated with many entities over here, with many entities over here. Right. And of course, one to many can be an example that there is one address that is unique. Multiple people are living at that address. You understand? Because if the address is not unique, how would the delivery be made? Now many to one try to understand there is a slight difference between many to one. I will try to explain it using an example over here. So over here I can have one associated with many over here. A state can be in one region. A state can be in one region. A city can be in one province. There are many provinces, but a city cannot be in multiple provinces at the same time. And then finally is the many to many relationship is that for example, a doctor can have many patients and a patient can have many doctors. So we'll work on this. We'll use them as a basis for developing the ER modeling diagram when we go to the corresponding model. That's all for this model. Thank you.