Now we have introduced this notion of entities that is what we started of with right entities. And entity is something which we are concerned about it is an important thing that we wouldlike to model in the information system. And then entities had attributes and then they participatein relationships etc. Now, in practice we also encounter slightly different kinds of entities. So,these are called weak entities. The difference between this.And the entities that we have been discussing so far which now can we actually call a strongentities is that the existence as far as this information system is concerned, the existence of theseentities in this weak entity set you know depends on the existence of some other entity unlessthat entity exists, there is no point talking about this entity which we are calling it as a weakentity.So, these weak entities are not have independent existence, their existence is owed to theexistence of some other entity possibly in a strong entity set okay. So each of these weak entitiesis associated with some entity of we call them as a owner entity through a special relationship,okay. Now when we discuss examples it will become very clear.But basically what we are saying is that there are certain kinds of entities whose existence insome sense depends on the existence of other entities and we call them call the other entities asthe owner entity, because the owner entity exists, this other entity, which we are calling as weakentity becomes important for us.Now, let me give you an example. We will see couple of examples. So, the weak entity said mayactually not have a key attribute at all. It may have what is called a partial key, we will talk aboutit and the owner entity might itself be a weak entity okay. It is possible that the owner entity,what is the owner entity, a owner entity is something you know, which kind of owns this weakentity, that itself can be weak in which case there is a chain of these weak entities.And so ultimately of course, it has to be owned by some strong entity. Now, okay here is thediagrammatic notation for that. So, the weak entity is shown with a double wall box we used touse normal rectangular boxes earlier for entities, now weak entity will be shown with a doublewall box and the name of the weak entity will be written here and it is there is always a specialrelationship that connects this weak entity to the owner entity okay.So, this kind of this relationship is also called the identifying relationship and this weak entityyou know always participates totally in this identifying relationship, because this weak entitycannot exist unless it is related to some strong entity owner entity. So, this kind of situationsarise and in order to capture their you know meaning in the form in the domain. We like to Imean we use this notion or concept of weak entities. So, let me give you an example, let us say a popular courses there. Nowadays, one of the popularcourses is machine learning, right. So, you offer multiple sections of the machine learning peoplewill enroll for that, I hear that enrollment for machine learning, you know crosses 100 orsomething like that okay. So let us say there is some popular course. And so we decided to havesections for the course.So what is the section, a section is an offering of that course. And that is where actually studentsenroll into these sections, each section is taught by a professor, maybe a different professors, wehave multiple sections, A B C D, A B C sections, each of them is taught by a different professorand each of its has its own classroom and meeting times right. So it has all these things.And it is students enroll for these sections. Right now, but you can see that why section is a weakentity is that unless the course exists the question of having a section does not arise right. So wehave a course and it is popular and so we would like to you know and even otherwise, wheneveryou know, a course is being offered in multiple, you know, years and things like that, we canalways call it an edition of the course right.So, for the 2019 database systems course your read, you all kind of enrolled it, enrolled into. So,this edition exists because the course exists right, course is a strong entity and section is a weakentity sometimes. So there will be multiple sections associated with this, the course and so, wemodel this as a weak entity, mainly because it is also said existence, to the existence of the strongentity called this database systems courses, and whatever course it is.And we call this has section relation as the identifying relation and this is called a weak entityand this is called its corresponding owner entity and we show the arrangement like this. Now, thesections, all sections corresponding to one particular course, you know, like CS 1100 like theintroduction to computing, there are usually 4 sections for that course, right.So, we have to identify those sections is this section A, section B, section C and sections D. So,we give some section number 1 2 3 or some letter A B C D and that will be identifying the actualknow the sections of that particular course. So, such a thing in attribute like section number, orsection name, a section letter or something like that which has this property that it will identifythe exact section.Among the sections that are associated with a particular course, is what we are calling as partialkey. It is not a key, because if you just consider all possible sections being offered by thedepartment, and then say that, okay, this student is enrolled in section A, and it does not makesense, right. What section A are you talking about, CS 110 has section A, mission learning alsohas a section A and something else also has a section A.So what section A are you talking about. So this section A by itself, you know, does not identifyany particular section. And so that is why it is called a partial key. So the course whatever thecourse ID along with this section number together only actually identifies the section uniquelyokay because all these sections are associated with that course. So, the course ID or whatever isthe key for that particular strong in the owner entity.Along with this partial entity will uniquely identify this particular section. In general, that is howit is. So it might have a some attribute, you know, which might act like a key, but it is notnecessary that weak entities have a key, that is the point we are trying to make. In the in the bookby Elmasri and Navathe they give an example of dependence of an employee. So, theorganization is interested in keeping track of the information about the dependence of employeesas long as the employee exists in their organization.If that particular person leaves the organization then there is no point keeping track of theinformation about his or her dependents. So, the dependence of a particular employee or bestmodel as weak entities in the organization, because they are basically interested in thosedependents, because they have hired that particular employee right. So, those are dependents willbecome weak entities owned by the corresponding employee.So, in this case you can see that those dependents or anyway a person's. And so, they mightactually have some identifying attribute like social security number or aadhar number orsomething like that, which is an identifying attribute right and it is a key attribute. It identifiesthe person uniquely. But that is besides the point that as far as the information system isconcerned it is not necessary that all these weak entities that we are we may be interested in mayhave a key.So, but what we have guaranteed is that we should introduce some attribute which can uniquelyidentify the all the sections or all the weak entities associated with it strong entity and usually wecan find such a attribute and that is what is what we call a partial key okay. So, is this idea of aweak entity clear. Essentially it is a we are saying that there are situations where we like to keeptrack of certain entities.But only thing is that those the existence of those entities depends on the existence of some otherentities which we are interested in. Now, let me give you another example. The institute has many pieces of you know equipment which are used for scientificexperimentation and things like that. And we would like to keep track of their utilization, how,who is using them and when they are using it and things like that. So, usage of a particularequipment, you know is best model as a weak entity. Unless the equipment exists there is nopoint talking about the usage of that equipment, right.The usage is modeled as a weak entity, and it is connected to the equipment strong entity, ownerentity through this identifying relationship called utility. And then it has its own attributes, whatis the usage number, something which uniquely identifies the usages of a particular equipmentand then who has used it and which department that particular person belongs to, when was itused date, time and what are the charges that you may have.We may internally have some arrangement of charging the person for using that equipment. Andyou know things like that. So, again this is best model as a as a weak entity and usage numberserves as the some partial key here which will identify the usages of a particular equipment.Typically this kind of information will be maintained in a small register you know associatedwith that.So, you go to a photocopier then they will say okay, you write your name and then you know useit and they at least know that okay, it has been used some so many pages have been copied andthings like that right okay. So with this the principal constructs that, that are available theconceptual tools that are available in entity relationship, model have you actually covered. So, letme summarize that.Basically, the entity relationship model is a data model that means it is a collection of conceptualtools to describe the database at the conceptual level. And it has these notions of entities,attributes for entities and various kinds of attributes, you are seeing them and relationships,relationship types, and various kinds of you know, one to one, one to many, different kinds ofrelationships and then the notion of weak entities.All these things together give us a bunch of tools to kind of capture the domain information andrepresented in a diagram. So I will, what I will do next is to look at you know, typical collection, how do we write downthe specifications, you know, in plain English and then later actually translate that into a biggerdiagram entity, ER model. So this particular example is what I am going to use in later on alsowhen we discuss relational data models, etc. So let us go through that.So, some of many of these concepts have actually been introducing as examples as well, as I amdiscussing these various notions. So let us capture all of them together and put them at one placeas a complete example. So education institution, there are several departments and each of andeach student belongs to one of them. And the department has a unique department number, aname and a location, phone number and is carried by a professor.Professors have a unique employer and name and phone number and professor works for exactlyone department. This is how we can jot down the domain information and so that we can latertranslate that into an ER diagram. Later on in an assignment, I would actually like you to do thiskind of an exercise where you know you, you choose a domain and then jot down the main factsthat you want to reflect in the domain model.And then actually translate that into an ER model and submit that. So we like to keep track of thefollowing details regarding students name, the roll number, unique roll number, sex, phonenumber, date of birth, age, and one or more email addresses. Students have a local addressconsisting of hostel name and room number. They also have a home address consisting of homenumber, city , street pin, it is assumed that all students resides in hostels.Now you actually wonder if a particular attribute is not applicable for a particular entity, whatshould it be its value okay. We typically use what is called a null value for that okay. We will meet that again later on also okay, a courses taught in a semester of the year, and it iscalled a section okay. So whatever courses are not directly taught, it is a section of the coursesthat are taught. So when it is a taught in a semester of the year, it is called a section. There can beseveral sections of the same course in a semester. These are identified by the section number.And each section is taught by a professor and has its own timings and a room to meet.Students enroll for several sections in a semester, in a given semester students enroll for severalsections. And each course has a name, number of credits and the department that offers it. Thereis a owner department for it. A course may have other courses as prerequisites, that is the coursesto be completed before this particular course can be enrolling. And then professors alsoundertake research projects.And these are, you know, sponsored by the funding agencies and have a specific start date, enddate and amount of money given to them. And then more than one professor can be involved in aproject. Also, professor maybe simultaneously working on several projects, a project has aunique project ID. So, this is how we gather together all the facts that we want to model and thenstart putting them all together in a diagrammatic notation the ER model notation. And then havediscussions with the end users. So here is how student entities model, so we have seen it already. So let us just see that the nameis just you know as per the writing there, we ignored that name has any other components, wejust named it as name, roll number is unique. So we underline the key attribute because it isvalue can we use to uniquely identify the student identity. There are one or more email id so it isa double this one ellipse.Then we have address, addresses has is a composite attribute because it has house number streetcity and pin and the local address is also a composite attribute because it has a hostile name androom, we are interested in date of birth and age is a derived attribute and we are interested in thegender of the student. So, these are the various attributes. So, we typically draw like this. Then we have the department, department has a department number which serves as the keyattribute and it is headed by a professor, so we call it, so we capture that way HOD attribute andthen name of the department location and phone number. Course entity course ID, credits andname. To recall that courses are offered by department. So, we intend to capture that as arelationship because each of these things is a entity department entity exists and course entityexists. So later we will capture that the departments offer courses through a relationship. And then professor a name or name Id, phone number, and maybe email address things likeokay, I am trying to strictly follow what was there in given in the English text section is a weakentity, section ID, classroom and timings. Timing is multiple timing so, it captures basically as toat what times of the week the section needs. We have project which is having a sponsor, and anamount of money given and what is the start date and date and what is the idea of the project.Now, let us put all these things together into one diagram. This is how that now only I want to remind you that because I am using slides and the slides willget cluttered if I write all the attributes around this, I have not written here, but normally whatyou do is you do not show this ER diagram like this, when you show the entity you also show allthe attributes around it. Likewise, if any relationships also have attributes, we have show all ofthem.So just because the slide will get cluttered. I have shown these entities separately, and I am nowshowing the relationships alone. So your diagram showing relationships alone, but normally aresidence will have all the attributes also written here okay, now let us focus on the variousrelationships that we have here. The student belongs to a department. So it is a many to one thisone relationship, many students belong to one department.And department offers several courses, so the one to many relationship and professors work fordepartment. My relationship between professors and department works for and many professorswork for a single department. And each professor was for exactly one department. So that is whyit is one to many and then professors work on projects. So, this we have already discussed.This is a typical many to many relationship because professors work on many projects and eachproject can have several professors associated with that. So it is a natural many to manyrelationship. So that is why it is shown as m and n and professors okay. So now courses havesections. So, courses are not directly you know taught is the sections that are taught. So sectionwe have introduced as a weak entity earlier.So that section has section ID classroom and timing right. So and it is a weak entity owned bycourse. And this is the identifying relationship. So professors teach sections and students enrollinto sections okay. So there is an enrollment relationship, which is a many to many relationshipbecause many students enroll for into one section. And a student typically enrolls for manysections, and the professor teaches more than one course of a section so.So it is one too many. So, all these are relationships and perquisites of is a relationship that existsbetween courses. So, we should ideally right the role name here, I have not written the role namecourse participants as a course and as a prerequisite. So participates as in what role does itparticipate as a participants as a prerequisite, participate as a as a course. So that is theprerequisite of relationship, it is we call this as recursively relationship in database pallets okay.So, I hope it is now clear to you as to how you can construct this ER diagrams and then takethem for discussions with the stakeholders, so that you can understand and the entirerequirements and we can also convey to them as to what we have understood about the domain,what we are going to represent in the domain later on, they should not ask for something whichwe have not discussed, right and then finally.Because all these design decisions are best made, data model requirements are best made at thedesign stages and later on if they start asking for additional things, it becomes a little bit messy tohandle the database system in creating the database system okay. Now let me take you through ina tutorial what we will do is to. So, I want you to have you know develop the skill of reading ERdiagram and understanding that okay.And then write down in plain text about a particular domain and translate that into an ER modelor given any you know, as situational description, translate that into an ER model. So, these 2things are what you should aim for. So, I will devise a few exercise like that and then we willhave a tutorial session sometime next week okay. So, let us come to a few questions, which we will encounter as we are trying to develop thisdesigns. One of them is attribute versus relationship. To give a concrete example this dilemmabetween attribute versus relationship, should offering the department be an attribute of a courseor should we create a relationship between course and department entities and call it offers, thisis what actually we have done in the previous figure.But why should it be like that, why cannot we simply you know, create an attribute for the courseand call it offering department and it will have a value right. So, then it indicates what is theoffering department. So, we will be done with that, why should we go for a relationship. Now,whenever the other entity see for example, so, what we are now talking about is for a particularentity like course, should some piece of information be modeled as an attribute or as arelationship.So, this is you know again this is a design choice, if the if that information is actually you know,corresponding to a particular entity that already exists then the approach of creating arelationship is to be chosen. And if it does not then you can go within attribute. So, that is thekind of choice that we have. So, it is preferable if the for example, in this case department existsas in other independent entity.So, in this case, it makes sense for us to create that relationship like offers and then put it ratherthan making offering department as an attribute of course, instead we can actually show that theassociation between course and department through a relationship okay. If it is some otherinformation, which cannot, you know, naturally get linked up with any of these existing entities,then you choose the option of modeling it as an attribute basically.Now, another kind of choice should classroom be at is related situation is should classroom be anattribute of a section or should we create an entity called classrooms and then you know make arelationship saying needs in and then connect them to, this also we can do actually, we can createan entity called classroom which is an entity set consisting of all classrooms and then say thatthis particular section meets in a particular classroom.So, you can create a meets in relationship and then connect these 2 entities. That option exists,what we have done in this case, if you go back to the picture is simply we made a classroom asan attribute. We did not model classrooms as entities, we simply captured that information as anattribute of section. Again, this is a design choice. And in our information system, we are notkeen on you know, keeping track of lot of other information about classroom as to, you know,what is the equipment that is there in that particular classroom.Who is in charge you know for upkeep of the classroom, and know who has the keys where thekeys have been issued. Let us say we have our information system actually is supposed to keeptrack of that information also, if that is the case, then it kind of makes sense to model theclassroom as an entity because we have a lot more other information to keep track of and oncethat classroom becomes an entity, we can then create a meets in kind of relationship and connectup this section with the classroom entity.But since we do not want to, but in this particular you know specifications that we have, we arenot keeping track of a lot of other information about classroom and so we have chosen the routeof modeling it just as an attribute okay. So these are the some of the design choices that we willhave to make. When we construct the model, it all again depends on the domain knowledge thatwe are supposed to capture okay and the usage of that information.So, in this case, the option of making classroom as an attribute is better as we do not want to givea lot of importance to the classroom and kind of make it as an entity because we do not haveadditional we are not required to keep track of additional information about classroom okay asper our specifications okay. So, this is one interesting point. Then let us look at this other situation, weak entity versus composite multivalued attributesremember that we have attributes and multivalued attributes, multivalued attributes or attributesthat can take multiple values right a set of values and then composite that means they havecomponents in that. So, for example, a section actually could also be modeled as a compositemultivalued attribute of course.Do you realize that I can model a section multiple sections. So basically, it is multivalued. Andsince while I am keeping track of some information about section I will make it composite. Sousing a composite multivalued attribute called section, I can attach it to the course, and thenmake this action as a composite multivalued attribute of course, is that a good design choiceokay.If you do that then they call that attributes do not participate in relationships. So, this section, youknow, becomes a multivalued attribute the need cannot participate in so what about enrolls andthen what about teacher and teaching that relationship and all that it becomes difficult to modelthose things now. So, it all again depends. So, if that particular entity is that information isrequired for other things like relationships and all that it is best model as a weak entity.Otherwise you could even go ahead with modeling it as a composite multivalued attribute okay.For example email address could be model as a composite multivalued attribute multivaluedbecause it has user ID and domain name and multivalued because it has typically person hasmultiple email address okay, I mean just you could also think about some other examples likethat. So, in general, if a thing even though not of independent existence part is debates and otherrelationships on its own like our section late it is best captured as a weak entity okay.If this is not the case then you can go ahead and moderate as a composite multivalued attribute.So, it all depends on the domain which we are modeling and the usage of this information in thedomain and based on that we are to make all this design choices okay. Now, finally, to kind ofwrap up this module, we have will spend a small amount of time on what are called temporaryrelationships. Often the kind of relationships that we encounter in modeling or frequently binary kind ofrelationship. But occasionally we do you know have to make use of n-ary relationship. So, hereis an example of a ternary relationship this example is from Elmasri and Navathe fundamentaldatabase systems book. So basically what we are seeing here is that there is a relationship calledsupply okay.And that has 3 entities participating in it the company, project and a component and we have alsothrown in the corresponding binary there are certain binary relationships also we can bring intopicture like okay like when example okay, so a company can supply a particular component. Sowe want to capture that binary relationship and a project is some activity and a project uses acomponent. If the component is used in the project then we have this binary relationship called project userscomponent and if a company is serving is you know supplying some component to a particularproject then we call that as company serves the project okay. So, that is a binary relationshipbetween company and project, if it is supplying some component to the project, then we call itcompany service the project.So, these are the familiar binary relationships, here is a supply relationship where the instance c pj in supply basically indicates that the company c supplies a component p that is made use of bya project j okay, it is the all the 3 things are associated together is what is captured by the supplyokay. So, if you want to capture this particular situation we need a ternary relationship. Now, if atuple like this c p j exists in the supply, ternary relationship.Then in some sense it should be obvious to you saying that this c p you know could exist and cansupply c supplies component p c p would exist in sub can supply and then you know p j couldexist in sorry j p j p would exist in project users the component, j is the project, p is thecomponent. So, j p exists incompetent and in a similar way c p c p exists in company sorry c j c jcould exist in source. So, the corresponding entities like this. So, the presence of c p j would imply the presence ofcertain things here in the binary relationships, but the other way around may not always be true.So, supposing we have c p in can supply and j p in users and c j in source may not togetheractually imply that c p j is in supply okay. So, this kind of illustrates that the having the 3 binaryrelationships is not a replacement for having the ternary relationship.