Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

Transcription

1 Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 1a Conceptual Design Hello in today session we would be looking at an important concept in the design of databases namely what is called as the conceptual design of databases using model called the entity relationship or the ER model. (Refer Slide Time: 00:01:24) Now you might have heard somewhere that databases today are based around the relational model where the fundamental aspect of the building block of a database are tables. So where does this ER model come in to the picture and what is its relevants and why do we need something like an ER modeling for databases? So in order to answer that question let us begin with looking at a small description of what a typical database design process looks like. This is just a simplified representation of what a database design process looks like.

2 (Refer Slide Time: 00:01:57) However this captures the gist of most database design process. Whenever we talk about databases, we should always remember that databases are always embedded within some kind of an application context and this is called the information system within which the database is embedded. So databases could be embedded within for example for a banking solution, the databases could be embedded within railway reservation solution, there could be embedded within a university setup, a company whatever. Now whatever this setup is, this context or the information system context is what is called as a UoD or the universe of discourse. The universe of discourse basically tells us what are the building blocks that make up this context within which this database is going to be run. Now generally when we talk about designing a database system, we first talk about looking in to the UoD and collecting requirements from the UoD. We have to make an analysis of the UoD saying for example, suppose you want to build databases for a bank, we have to first identify or we have to first understand how does the bank conduct its operations, what kinds of operations do they have and what are their rules, what are their norms and what identifies a correct operations from an incorrect operation and so on and that is going to give us two kinds of requirements. The first is what is called as database requirements or you might also term it as data requirements and the second is what is called a functional requirement. Now as you might have imagined that database requirements are handled by DBMS or the database management system. However a DBMS by itself is not a complete solution. To give you an analogy DBMS is something like an engine. Now we can t just have an engine, we have to build a car around it or we have to build a bus or whatever it is around it. So this layering around the database system is what is called as the application programming or the information system.

3 So the functional requirements go to design in the application program or the larger information system with in which the database is going to be. (Refer Slide Time: 00:04:24) Now continuing with this process, we take the database requirements and come out with a first level or what we called as a high-level conceptual design. We have to first understand how this database requirements look like, what are the different data elements and how are they related? We need to first understand in a way or rather represent it in a way that is understandable by human beings rather than computers. We have to first understand the problems first before we give it to the computer. So database requirements go into what is called as the conceptual design and the output of the conceptual design is what is called as the conceptual schema. Now this conceptual schema is what we are going to be taking up today in more detail but going on with the process itself, let us see what happens with the functional requirements. So functional requirements also go through a similar process where you do functional analysis, you analyze what are the different functions. If it is a bank, what are the different functions? Opening an account is a function or making a bank transfer is a function. Now what are the constraints that holdup these functions what is a correct function, what is an incorrect function and so on. So once these functional analyses are made, we get what are called as high-level transaction specifications. In fact we will be revisiting this topic called transactions as a separate module where we will see that many times, we need to club different operations of the database into one logical unit or what we called as a transaction. Now transactions are what are going are the building blocks of the functional requirements or the functional analysis of the information system. Now you can also see down here that all of these, until now all of these are DBMS independent process.

4 So what is meant by DBMS independent process? It means that doesn t matter whether you are using an oracle database or an IBM db 2 database or a MYSQL or postgres or whatever it is. You will have to look at the UoD, you will have to understand your UoD, you have to come out with a conceptual design which has in no way relevant to the actual implementation which the DBMS does and you have to do a functional analysis which is completely independent of the DBMS that we are using. Next comes the DBMS dependent processes. So we ended up with the conceptual schema previously in the database stream. You can say that there are two different streams of a processes happening. One is the database stream and the other is the functional stream or the application stream. (Refer Slide Time: 00:06:50) So in the database stream, we had ended up with the conceptual schema. Now the conceptual schema in turn should be transferred in to what is called as a physical design. Now what is physical design? The physical design actually tells you how the data itself resides on the database, on the computer. So obviously this is a DBMS dependent process. So the way, even though there are many standards that exists now the way that let us say oracle stores its data would be different from the way db 2 stores its data. Even though there due to some standards there are going to be slight variations. So this physical design results in what is called as an internal schema or the schema which actually should goes into the DBMS and similarly the high-level transactions specifications that we are talked about are also going to impact the physical design of the database. I mean suppose certain kinds of operation have to be performed together. It makes sense to design them near to one another so to say. Let me just use the word in slightly lose fashion here to one another so that it becomes easier to handle transactions on. So you get

5 inputs both from the conceptual schema and from the high-level transaction specs in order to make your physical design of the database. Similarly the application stream goes off into application program design and transaction implementation, finally the application software. So under, from all this now we are going concern ourselves in this session with just one aspect of this entire process that we looked at namely the conceptual schema. Now what is a conceptual schema and why is it important for database design? (Refer Slide Time: 00:09:06) So let us have some observations about what is a conceptual schema. We just now saw that the conceptual schema is an outcome of the high-level conceptual design of a database. So this is one of the first things we are going to do. We are going to understand our UoD or the universe of discourse. It tells us what kinds of data that the UoD is going to handle and based on this, we are going to come out with a high-level design. So it s a very concise description of the data requirements, what kinds of requirements do users need and how are the data related between one another and so on. Again let me take a brief example. Suppose you are building banking solution. One of the first things that you are going to note is that in a bank there should be accounts, there should be customers, there should be customers or account holders or whatever you call them and there should be of course monitory transactions and there should be some kinds of logs and ledgers and account books and so on. So all of these represent some kinds of data elements and a very high-level conceptual design would identify each of these data elements and say this is how they are related. So it includes the description of what you called as entity types. These are the entities that makeup the UoD. In a bank the customer is an entity, an account is an entity and a ledger is an entity. Similarly in any other UoDs, there would be

6 several different entities like that whether it is a railway reservation system or a university or whatever, they re going to be different kinds of entity types and there are relationships across the entity types. So customer holds an account, an account transfers to another account and so on and so far. So there are relationships between different entity types and there may also be certain constraints that are imposed either by physics or by the UoD itself. In a bank for example one might say that in a SBI account, balance may not go below 50 rupees or whatever that s a constraints that is imposed by the UoD that says you cannot have less than 50 rupees in your account in order to make a term, in order to make a term working. On the other hand there could be other constraints that are imposed by physics itself, the physical reality. For example if you are modeling a railway reservation, you can t obviously have two trains starting at the same time from the same place, from the same platform. So it is simply because those two cannot exit at the same time. So there are different kinds of constraints that exist among data elements and this is what we are going to capture during the conceptual design. And another thing to note here is a conceptual design has no implementation details. Here note that it earlier we had noted that a conceptual design is a DBMS independent process. So that means we are not really worried here about how this conceptual schema is going to be implemented within a database systems and the main idea of a conceptual schema is ease of understanding. We should be able to say to your end user this is what we have understood from your description, this is what we have understood of your needs and your end user should be able to understand your understanding so to say. So he should be able to understand your understanding, even though the end user may be a nontechnical user. So the main idea for behind the conceptual schema is ease of understanding and it is used mainly for communication with end users who are of non-technical nature.

7 (Refer Slide Time: 00:13:08) So here is a small example. An example, company database. So suppose we look at a company, what are some of the first things that we can identify. First some of the first things we identify are a company of course has employees, we can see them. Then company has departments, each employee works in different departments and so on. Then once we start speaking to employees, we find that there are also different projects and each department has some one or more projects and a project may span different departments and so on. And once we start to the HR, talk to the HR department, we note that each employee also has some dependence and there are also covered in some way or supported in some way from the company and so on. Now if you look at this slide carefully, here we see that there are two different kinds of things that we are noting here. All these things before the colon, we see the things like departments, projects, employee, dependence and so on and after the colon you have a terms like name, department id, manager or name, project id, location or name, pan number, address and so on. So what this says is that all this names before the colon like departments, projects are entity types. They are different entities say department is an entity, project is an entity, employee is an entity and so on but once after the colon like name or manager or location and so on are what are called as attributes of this entity that means they belong to this entity. For example the name occurring after department here belongs to this department, the department id belongs to this department. Similarly the project id belongs to project and address belongs to employee, date of birth belongs to employee and so on. So it not only belongs to employee, it also tells us or it describes something about the employee. So if there is an employee, an employee has a name, an employee has a pan number, if he is paying income taxes regularly that is he has an address, he has a salary, he has well, he or she has a gender and date of birth and

8 so on. So all of these attributes define what is an entity type and what are the characteristics of that entity type. (Refer Slide Time: 00:15:35) So let us formulate things a little bit now. In the ER model or the entity relationship model, we have standards notation of representing entity types and their attributes. As you can see in the slide here, entity types are represented by rectangles. So department is an entity and attributes of the department like department name, department identifier, manager of the department and so on are represented in the form of ovals or something like balloons hanging over this entity types. So there are some definition here. So if you review this, an entity represents an object of the real world that has an independent existence. Note that term independent existence that is you should be able to identify an entity independent of every other entity in the system. Address is not an entity because address belongs to some entity called employee or department or whatever. However the employee itself is an entity because it is an independently occurring object in the UoD and an entity has attributes or which are properties that describe the characteristic of this entity.

9 (Refer Slide Time: 00:16:53) Now what are the kinds of attributes or what are the different kinds of attributes that could exist? We saw name and age and date of birth and so on but can we classify this attributes into different kinds of attributes and it can tell us something about characteristic of the entities. So there are several different classifications of attributes, we are going to look at small number of such classification. One of the first classifications of attributes is simple versus composite. So what is a simple attribute? A simple attribute is let us say something like age. You are 30 years old, 30 age equal to 30. So that s a simple attribute that is just one value associated with an attribute. So when you say age, you get back one value called 30. On the other hand suppose you say name, in some countries we say name is name, you just talk about one name for an employee but in several different places when you talk about name, you have to specify a first name and middle name and last name and title and nick names or whatever so. So basically a name is composed of several other attributes within it, so that is what is called as a composite attribute versus a simple attribute which has just one value and there could be a something like a single-valued attribute or a multi-valued attribute. Now what is a single-valued attribute? Again age is a single-valued attribute. At any point in time at least you have just one age that is at this point in time let us say you are 30 years old or 35 years old or whatever. On the other hand at any given point in time, an attribute may actually have multiple values. Now take the color of a peacock for example. No matter when you are going to measure this, no matter at what time you are going to take a snap shot of a peacock, you are always going to find many colors. So this is a multi-valued attribute, that is the attribute itself is defined by multiple values. How is this different from a composite attribute? Let me pass here for a little while so that you can ask this question to yourself again. How is

10 a multi-valued attribute different from a composite attribute? Now composite attribute if you saw, if you notice closely is made up of different sub attributes. For example name is made up of first name, middle name, last name and so on and initials for example or title and so on. All of these need not be of the same type. I can say title can be either mister, doctor, misses, whatever and so on only these three types. On the other hand name could be anything, any string and so on. On the other hand when we look at multi-valued attributes, all the different values that it takes, color of a peacock for example it might have different attributes, many attributes but all of them denote color blue, green, red, white, whatever all of them are color, all of them are of the same types. So multi-valued attribute are different values of the same attribute type but a composite attribute is a collection of different smaller attributes in itself. (Refer Slide Time: 00:20:19) And then there, what are called as stored attributes versus derived attributes. Now stored attributes is something which you just store in the database, your date of birth for example. So when you ask what is your date of birth, you just give some date and then store it in the database. However suppose you were to ask what is the age of an employee. Now suppose you know today's date and you know the date of birth of the employee, you can always derive the age of the employee. So age in a sense is a derived attribute, a good database design would put age as a derived attribute because a database hopefully is going to be used for a long time. It s not just today, today an employee might be 30 years old but 5 years later he still won t be 30 years old, he would be 35 years old. So it s always best to have age as a derived attribute because you always know what is the current date and you always know the stored attribute called the date of the birth. Similarly there are what are called as null attributes or null values for attributes. Sometimes an attribute may not have any associated value for a particular case and let me give an example. Suppose a student can take at most two elective courses in a semester

11 and at least one elective course and at most two elective courses. Now let us say there is a student who has taken just one elective course. Now because he can take at most two elective courses there are four different, there are two different slots, elective one and elective two. Now let us say after, at the end of the course is give a grade for each of the courses, that each of the courses he has taken up. Now he gets a grade for the first course but he doesn t get a grade for the second course because he didn t take the second course at all, elective two has no grade. But this grade is not we can t say that he has scored zero in elective two. So a null value is different from zero or unknown or missing value. This is not a missing value this is not a, this not zero or this is not an unknown value, this is a null value. That means that something like when you say n a, when you write in application forms this is a null attribute. So let us come back to entities and define a few more terms here with respect to entity types. So we saw that an entity type, I have been using the word entity type but have never really formally defined this term. So an entity type is a definition or defines a collection of different entities of the same type. (Refer Slide Time: 00:22:47) For example in this slide, we give this example of department. So a company could have different departments but when you say an entity type department it means that it represents all departments in the company. So it is a definition of a real world object type. So it s not this department or that department, it is just department. It is a type that the entity is going to define. Now any specific collection of entities of a particular type is what is called as an entity set. For example if you take supplies departments plus accounting department. Now suppose we take both of them in some collection. We call this as an entity set, these are two different departments of the same entity type. So we also say that an entity type as

12 opposed to an entity set. So an entity type is set to describe the schema or the intension of an entity set. What is that mean? It basically says that how should the structure of this entity or entities of this type look like. So suppose we say that department should contain a department id, it should have an address, it should have a manager, it should have several other attributes that means that no matter whether it is the supplies department or the accounting department or the systems programming department or whichever department it is, they should be defined by these attributes. That is they should have a department identifier, they should have a clearly defined address, they should have one % designated as manager and so on. So an entity type describes what is called as an intension or the schema for an entity set or different entities of the same type. So here are again a review of the representations entities types are defined by boxes and attributes are defined by ovals and different kinds of attributes have different kinds of ovals may be its not completely visible here. The multi-valued attributes are defined by an oval having a double line. (Refer Slide Time: 00:25:03) And similarly derived attributes are those which can be derived from other attributes are defined by a dotted line instead of a solid line.

13 (Refer Slide Time: 00:25:38) And we now come to another key issue when we are talking about entity types and namely this is about key attributes. Now what is a key attribute? Now if you notice carefully when you said that each department has to have a department identifier and manager and address and so on. Now why do we need a department identifier for each department? This is to be able to identify each department uniquely. Now if I say department number 10, it means just one department no matter what its name is. Department name could be ambiguous, it could mean supplies and accounts and suppose we might have a department called administration, it might mean both supplies and accounts or whatever so. A name could be ambiguous but when we say an id or an identifier, it s a something like what you have a pin code in post letters. It uniquely identifies each entity of this entity set. So the department id attribute is unique for each department that belonging to this entity set. So such attributes which can uniquely identify entities are what are called as key attributes or keys. So the key attribute as you can see here is specified by an underlined definition. So the department id is underlined here to denote that it is a key attribute.

14 (Refer Slide Time: 00:27:14) Now in some cases it need not always be just one and that is the key attribute. There could be more than one attributes which are key attributes in which case all attributes which form part of the key are all showed underlined. Now what is meant by a key attribute? So an attribute or a set of attributes that uniquely identify entities in an entity set. So is what is called as a key attribute? Now like I said it need not be just one attribute that is a key attribute, there could be more than one attributes which is a key so in which case the key attribute is called a composite key. So the key is made by combining two or more attributes together. A composite key should be minimal what is it mean to say a composite key is minimal. Let me first give you the definition of what is mean by minimal and then we can see an example. So no subset of a composite key should be a key itself. For example let me take the attributes department id and department name. Is it key attribute? Of course it s a key attribute because if I take department id, department number 10 supplies, it uniquely identifies one particular department. However the second attribute here, the name called supplies is redundant. We don t need to have this attribute here in order to uniquely identify a department. It s sufficient enough if you say department number 10. So that s what is meant by a composite key that is department id and name is not a composite key because it is not minimal in nature. No subset of a key attribute should be a key attribute in itself in which case this is not so. So, key attributes are shown underlined in the ER diagram.

15 (Refer Slide Time: 00:29:14) There are also certain other properties of keys which we are going to revisit again when we are going to look into the enhanced ER model. What is called as the retention of key attributes in all extensions? So let me not take this property right now and we will come back to this again that the key attribute should be retained for all extensions of a particular entity type. Now it may so happen that a key attribute should uniquely identify an element but an element need not have just one key attribute. Of course I can have two keys to my house, key from the front door and the key from the back door. Now it is fine but the only thing is this key should open only my house door not somebody else s house door. So that s the idea that is a key should uniquely identify a house but a house could be identified by more than one key, you could either enter through the front door or the back door. Similarly I can have a let us say on a computer network, you can uniquely identify a machine by its ip address or so to say an ethernet address on a lan and so on but a machine could have more than one ethernet cards in which case both of them uniquely identify the machine. So there is no restriction on how many keys that you are going to have but usually we are going to use one key, so what is called as a default key. Usually we are going to enter through the front door not always through the back door. So usually we are going to use just one key but you may have more than one keys that define a particular entity type. And there could be some entity types which have no key attributes. We are going to take a look at one such example little later on and it may not be possible to define any kind of a key attribute for such entity types and such entity types are called weak entity types or entities of such type are called weak entities. So they have to what we called as totally participate in some relationship in order to define themselves.

16 Now we come to the next definition of, definition in the ER model what is called as a domain, what is meant by domain of attributes. Now a domain to put it in a very informal fashion is going to show you the space in which an attribute is going to be defined. (Refer Slide Time: 00:31:25) For example if I say age of an employee and there are some set of rules that you cannot have employees lesser than 18 years and greater than 65 years. The domain is basically a number between 18 and 65. Obviously it can be, there are also some physical limitations in the sense that the domain of an age can never be negative so that s the nature imposed restriction but there could be other restrictions and which basically defines the space within which any value of this attribute can reside. Now if a composite attribute has different sub attributes or like we saw name has different sub attributes first name, middle name, last name and so on. And each of them have the room domains let us say D 1 D 2 D n. So we see that the domain of the composite attribute is Cartesian product of the domains of individual attributes. So the first attribute can take a value between 18 and 65 and the second attribute can take a value between 0 and 10 and so on. So the domain of the entire attribute is just a Cartesian product of all of these terms.

17 (Refer Slide Time: 00:33:01) So let us briefly come back to this company example and see likewise whatever we have seen until now. So we can think of different kinds of entity types like department, project, employee and so on and there are different kinds of attributes for each kind, each of these entity types and there are certain key attributes here which are underlined and then there are certain composite attributes which are shown like this that is name is composed of first name, middle name, last name and so on and like that and several other entity types that we can identify during our analysis. The next concept that important concept that we are going to be looking at in ER modeling is the notion of relationships like the modeling itself says it s about entities and relationships. So we just until now we looked into what are called as entity types. So we defined as an entity type, an entity set, attributes, different kinds of attributes and keys and domains and so on. Now let us see how can we relate entities of different types. So a relationship are to be precise relationship type defines a relationship between two or more entity types. So the slide here shows a relationship type between an entity type department and an entity type employee and it says managed by.

18 (Refer Slide Time: 34:35) So it basically says a relationship type specifies that any department or any entity of type department should be managed by some employee or some entity of type employee. (Refer Slide Time: 00:34:54) So let us go further and make some definitions. First of all, let us first defined what is meant by relationship type. So relationship type R is an association among different entity types, it need not be just two entities it can be any number of entities. So there could be n number of entities and defines, it basically defines a set of associations, what is called as a relationship type.

19 So if you look at it a little bit carefully, a relationship type is just a subset of the Cartesian product of all of the entity types. So that means an entity instance or entity or entity of this type could be related to some entity of this type and some other entity of the next type and some other of the next type and so on and all of this define one instance of this relationship. (Refer Slide Time: 00:35:49) So let us dwell deeper into what are meant by relationships and what are some of the characteristics that define relationships. Firstly, the notion of the degree of a relationship type. So what is a degree of a relationship type? It s simply the number of entities or that are involved in this relation, it is how many, between how many relations is this relationship going to establish an association. We saw earlier a relationship type of degree two that is a department is managed by an employee. So there are two entities that participate in this managed by relationship. Such kinds of relationships are called binary relationship, binary basically because there are two entity types involved. Similarly there could be unary relationships, there could be ternary relationships and so on and there could be n array relationships, n different types of relationships.

20 (Refer Slide Time: 00:36:49) Now we come to kind of a tricky problem here. Now have a look at this slide carefully. The first picture above shows the relationship type, it shows employee works for department and the second relationship and the second picture below shows employee as an entity and department in which the employee works in as an attribute of employee. So which is correct? Is department an attribute of employee that is does the department in which an employee works in describe the characteristics of an employee or is it that departments and employees have separate existences or separate entities and there is a relationship type between them. So let me confuse this problem even further, take a look at this slide here. So in the earlier slide, you could have probably said that no department cannot be an attribute because department has an independent existence. We already saw that each entity type should have an independent existence. So because departments have an independent existence they can't be an attribute.

21 (Refer Slide Time: 00:37:50) But have a look at this slide here. The first picture shows employee works for department as a relation and then department has a department id as one of its attributes. Now I am going to take this department id attribute and put it in to employee and say employee works in this department, so this employee is associated with this department id. So now which is correct or which is wrong? So is the first one correct or the second correct? The answer to this obviously is it depends on the particular situation in which you are looking into. Now the first one where we show that employee works for department as a separate relation depicts the relationship between employee and department and the second one just depicts what are all the different characteristic that describe or what are the different attributes that describe the characteristics of employee that means if I am talking about an employee entity and if I say that an employee is or in some sense an employee is very closely tighed to his department. So he has no identity without his department id in which case you have to say department id is a part of the attribute or is one of the attributes of the employee entity type.

22 (Refer Slide Time: 00:39:46) So relationships versus attributes, it s a slightly a tricky problem always, so in order to determine whether a particular thing is actually a relationship or it is an attributes. And in some kinds of data models like what are called as functional data models or in object databases, relationships are almost always refer to as in the form of attributes. For example in object databases, you talk about relationship by storing an object reference. Let us say you have a relationship between employee and department, so there is a reference to a department object within the entity object and vise versa and a reference to an employee object in the department object and so on. Similarly in relational databases which we are going to study much deeper, we see that relationships are established by what are called as foreign keys that is there is one table that describes one kind of an entity and a relationship between this table and the other table is described by a foreign key attribute which says that this entity of this type is related to some other entity of the other type. Now we come to another important issue in the when you are talking about relationship, this is the notion of constraints.

23 (Refer Slide Time: 00:40:59) So when we talk about relationships almost always relationships are defined by certain kinds of constraints. Take the examples of employee managing a department. One of the most simplest constraints that we can think of is department should be managed by at most just one employee. We can't have two mangers or two heads of a department, we should have a just one head of a department and you might also establish a constraint that one person can manage at most one department at a time. In some cases there could be allowed to manage more than one department at the same time. So that means in that case there is no constraints from employee to department but there is a constraint from department to employee. So when you are talking about constraints and relationship types, we are mainly concerned with two kinds of constraints what you call as cardinality ratios and participation constraints. So what are these cardinality ratios and participation constraints let s have a look at them.

24 (Refer Slide Time: 00:42:15) So take a look at this relationship again. Here now I have replaced this managed by with another relationship called works for. Now works for is slightly more general than managed by in which ways it more general then managed by. A department can have many employees working for it. However sometimes we might have to mandate a requirement that an employees can work for only one department not for multiple departments. So this is shown in one of two different ways either like this that is N : 1 which says that N employees to one department or something like this, so which says it could be N employees working in one department and so on. So on the other hand what happens if this were to be M:N something like 4 : 3 or 2:1 or 2:5 or something like that. So that means that let us say 4:3 so that means that a department can have at most 4 employees and an employee can work in at most 3 departments and so on. So basically you can represent a cardinality constraint or cardinality ratios in this case that says participations in this constraint is defined or constrained in this, by this cardinality or number of entity types. The second kind of constraints that s important is what are called as participation constraints. What is a participation constraint?

25 (Refer Slide Time: 00:43:49) Take a look at this slide here. Now this slide shows another relationship type which says department handles project. Now a department may handle several different projects. Suppose there is a restriction that a project has no existence unless it is associated with a department. Now suppose I have a project for developing some kind of software. Now this project does not exist if it is not associated with some department, if there is no department which is in charge of this project. Basically what this says is that if every project has to be associated with a department then the very existence of project depends on this relation. So only if an instance of this relationship exists only then can a project entity type exist or such kinds of constraints are what are called as participation constraints. They are defined by a double line here may be it s not fully visible but it is a double line here. So that means that the very existence of this project is dependent upon the existence of a relationship of this kind. Going on further in to participation constraints, we say that the entity type in this case project is said to totally participate in to this relationship because if it doesn t participate it doesn t exist anymore.

26 (Refer Slide Time: 00: 45:16) So a participation constraint in which an entity type existence is dependent upon the existence of this entity type of this relationship type is called as total participation. That is the entity type or participates completely or totally in this relationship. We can also think about attributes for relationships and not for entities themselves, just like we saw attributes could be associated with entities. We could also allocate attributes for relationships. Have a look at this figure. Here it shows department as an entity type and says that department handles certain projects and project totally participated in this relationship and then an attribute called budget is placed for this relationship. So what is this mean? It basically means that this budget or the budget that is specified here is allocated for this project associated with this department or is specifically allocated for this relationship type.

27 (Refer Slide Time: 00:45:50) So in cases where let us, the project is handled by more than one department that means that this budget is not allocated to the project. This is allocated only for this project for working on this department and so on. It is not allocated to the department as well that means the department cannot use this budget for anything else; it has to use it for this project only. So this budget actually is a constraint on the relationship type, so it belongs neither to department nor to the project in its entirety. However there is certain kind of relationships where we can actually move the attributes from the relationship type to one of the entities. What are those kinds of relationships? Take a look at this slide here. The first figure shows a 1: N relationship that is a project can be associated with at most one department and there is an attribute called budget that is allocated to this relationship.

28 (Refer Slide Time: 00:47:23) Now if you see carefully, we do not do correctness if we move this budget attribute from the relationship to the project site. So if I say that this budget is allocated to this project, it does not lose any semantics because a project can be associated with just one department. In the previous slide, a project could be associated with M different departments that is it could be associated with many departments. So here since project can be associated with only one department, it does not lose semantics if the budget is allocated to the project itself. So one of the last things definitions that we are going to be looking at today are is what is called as a identifying relationships. Have a look at this slide here, this slide here shows a figure where an employee is identified by pan number. So assuming that every employee is a tax payer and has received pan number from the government, an employee is uniquely identified by his pan number. Now let us say we prepare, the company prepare some kind of an insurance record for each employee.

29 (Refer Slide Time: 50:00) Now let us say this entity called insurance record which contains certain parameters or whatever is an entity by itself because it has an independent existence. You can see an insurance record and note that it s an entity by itself. However you see that an insurance record has no existence, has no meaning unless it is associated with somebody unless it is associated with some employee or some department you want or whatever. So this is an example of an entity type which is a weak entity type that means it has no keys. The key for the insurance record is of course the pan number itself or pan number of the employee. So the key of the employee which defines an insurance record forms the key for the insurance record as well and the relationship that defines this, such a kind of association is what is called as an identifying relationship. So this relationship here in this slide which is called as insurance details identifies insurance record with an employee. It basically ties in insurance records with employee so that an insurance record also gets independent existence by themselves. So as you can see insurance record totally participates in this relationship. Obviously it has to totally participate in this relationship but on the other hand not every total participation may mean an identifying relationship, we actually saw an example earlier where we saw two different entity types department and project in participation but which is not a weak entity type. So, identifying relationships are again defined by double lines on the relationship types itself. So let us briefly pursue a summary of the different notations we saw. The first thing that we saw was an entity type and defined by a box and a weak entity type which is defined by a dotted line which is not clearly visible here.

30 (Refer Slide Time: 00:51:10) Then relationships types are defined by rhombus and the identifying relationship types are defined by double lines. (Refer Slide Time: 00: 51:38) Similarly attributes are defined in different ways that is normal attribute is an oval, a key attribute has an underline there and a multi-valued attribute has double line and a derived attribute has a dotted line. So with this we come to the end of this session where we had a brief look at what is meant by conceptual design of a database.

31 So to briefly summarize that a conceptual design of a database is meant for non-technical users, it s a high-level design and mainly composed of diagrammatic notations like entities and attributes and so on. And within this diagrammatic notations, we saw that there are several different characteristic, there could be entities, entity type, entity sets attributes, multi-valued attributes and key attributes and relationships, an identifying relationships and weak entity types and so on. So one of the first step that we do in database design is to be able to identify this entity types and relationships and to be able to build this ER schema. So that brings to the end of this first secession on conceptual modeling of database systems. Thank you.