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

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "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.

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University Data Analysis 1 SET08104 Database Systems Copyright @ Napier University Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship?

More information

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University Data Analysis 1 Unit 2.1 Data Analysis 1 - V2.0 1 Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship? Entities, attributes,

More information

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage Database Design Process there are six stages in the design of a database: 1. requirement analysis 2. conceptual database design 3. choice of the DBMS 4. data model mapping 5. physical design 6. implementation

More information

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E)

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) 2 LECTURE OUTLINE Using High-Level, Conceptual Data Models for Database Design Entity-Relationship (ER) model Popular high-level conceptual

More information

HNDIT 1105 Database Management Systems

HNDIT 1105 Database Management Systems HNDIT 1105 Database Management Systems Lesson 02: Database Design Process & ER Diagrams By S. Sabraz Nawaz M.Sc. In IS (SLIIT), PGD in IS (SLIIT), BBA (Hons.) Spl. in IS (SEUSL), MIEEE, MAIS Senior Lecturer

More information

Entity-Relationship Model. Modeling. Entity-Relationship Model. How do we design the database for an application?

Entity-Relationship Model. Modeling. Entity-Relationship Model. How do we design the database for an application? How do we design the database for an application? Entity-Relationship Model Dr. McNamara CSCI 371 Databases Fall 2006 1. Conceptual Design: Analyze the problem. Identify the entities, relationships, and

More information

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Outline Using High-Level Conceptual Data Models for

More information

D.Hemavathi,R.Venkatalakshmi Assistant Professor, SRM University, Kattankulathur

D.Hemavathi,R.Venkatalakshmi Assistant Professor, SRM University, Kattankulathur DATABASE SYSTEMS IT 0303 5 TH Semester D.Hemavathi,R.Venkatalakshmi Assistant Professor, SRM University, Kattankulathur School of Computing, Department of IT Unit 2:Entity Relationship Model Disclaimer

More information

Constraints in ER Models. Types of Constraints. Keys. CS 317, Fall 2007

Constraints in ER Models. Types of Constraints. Keys. CS 317, Fall 2007 Constraints in ER Models CS 317, Fall 2007 Types of Constraints Keys are attributes or sets of attributes that uniquely identify an entity within its entity set. Single-value constraints require that a

More information

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model The entity-relationship (E-R) model is a a data model in which information stored

More information

Chapter 5: Logical Database Design and the Relational Model Part 1: Transforming EER Diagrams into Relations Modern Database Management 6 th Edition

Chapter 5: Logical Database Design and the Relational Model Part 1: Transforming EER Diagrams into Relations Modern Database Management 6 th Edition Chapter 5: Logical Database Design and the Relational Model Part 1: into Relations Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Robert C. Nickerson ISYS

More information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model 221 After completing this chapter, you should be able to explain the three phases of database design, Why are multiple phases useful? evaluate the significance of the Entity-Relationship

More information

DATABASE SCHEMA DESIGN ENTITY-RELATIONSHIP MODEL. CS121: Introduction to Relational Database Systems Fall 2015 Lecture 14

DATABASE SCHEMA DESIGN ENTITY-RELATIONSHIP MODEL. CS121: Introduction to Relational Database Systems Fall 2015 Lecture 14 DATABASE SCHEMA DESIGN ENTITY-RELATIONSHIP MODEL CS121: Introduction to Relational Database Systems Fall 2015 Lecture 14 Designing Database Applications 2 Database applications are large and complex A

More information

Project and Production Management Prof. Arun Kanda Department of Mechanical Engineering Indian Institute of Technology, Delhi

Project and Production Management Prof. Arun Kanda Department of Mechanical Engineering Indian Institute of Technology, Delhi Project and Production Management Prof. Arun Kanda Department of Mechanical Engineering Indian Institute of Technology, Delhi Lecture - 15 Limited Resource Allocation Today we are going to be talking about

More information

CSCD43: Database Systems Technology. Lecture 2

CSCD43: Database Systems Technology. Lecture 2 Lecture 2 Wael Aboulsaadat Acknowledgment: these slides are based on Prof. Garcia-Molina & Prof. Ullman slides accompanying the course s textbook. Steps in Database Design Conceptual Design Logical Design

More information

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology Madras

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology Madras Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology Madras Lecture - 41 Value of Information In this lecture, we look at the Value

More information

Theory of Computation Prof. Kamala Krithivasan Department of Computer Science and Engineering Indian Institute of Technology, Madras

Theory of Computation Prof. Kamala Krithivasan Department of Computer Science and Engineering Indian Institute of Technology, Madras Theory of Computation Prof. Kamala Krithivasan Department of Computer Science and Engineering Indian Institute of Technology, Madras Lecture No. # 31 Recursive Sets, Recursively Innumerable Sets, Encoding

More information

CSC 742 Database Management Systems

CSC 742 Database Management Systems CSC 742 Database Management Systems Topic #4: Data Modeling Spring 2002 CSC 742: DBMS by Dr. Peng Ning 1 Phases of Database Design Requirement Collection/Analysis Functional Requirements Functional Analysis

More information

Entity Relationship Diagram

Entity Relationship Diagram Yufei Tao Department of Computer Science and Engineering Chinese University of Hong Kong A primary goal of database design is to decide what tables to create. Usually, there are two principles: 1 Capture

More information

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Chapter 2: Entity-Relationship Model. Entity Sets.  Example: specific person, company, event, plant Chapter 2: Entity-Relationship Model! Entity Sets! Relationship Sets! Design Issues! Mapping Constraints! Keys! E-R Diagram! Extended E-R Features! Design of an E-R Database Schema! Reduction of an E-R

More information

Basic Database Concepts

Basic Database Concepts Tore Risch Uppsala University, Sweden UDBL Basic Database Concepts What is a database? A database is a collection of related data stored in a computer managed by a DBMS. What is a DBMS, Database Management

More information

Foundations of Information Management

Foundations of Information Management Foundations of Information Management - WS 2012/13 - Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Data & Databases Data: Simple information Database:

More information

XV. The Entity-Relationship Model

XV. The Entity-Relationship Model XV. The Entity-Relationship Model The Entity-Relationship Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of E-R Diagrams and Business Rules The

More information

ETEC 2601 Database Systems

ETEC 2601 Database Systems ETEC 2601 Database Systems Chapter 5: Data Modeling With The Entity-Relationship Model Copyright 2004-2010 J. B. Gallaher The Data Model The design of a database Is the way the user conceives the information

More information

CPSC 304 Introduction to Database Systems

CPSC 304 Introduction to Database Systems CPSC 304 Introduction to Database Systems Conceptual Database Design The Entity-Relationship Model Textbook Reference Database Management Systems: Chapter 2 Hassan Khosravi Borrowing many slides from Rachel

More information

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model Chapter Outline Overview of Database Design Process Example Database Application (COMPANY) ER Model Concepts Entities and Attributes Entity

More information

Formal Languages and Automata Theory - Regular Expressions and Finite Automata -

Formal Languages and Automata Theory - Regular Expressions and Finite Automata - Formal Languages and Automata Theory - Regular Expressions and Finite Automata - Samarjit Chakraborty Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology (ETH) Zürich March

More information

Industrial Engineering Prof. Inderdeep Singh Department of Mechanical and Industrial Engineering Indian Institute of Technology, Roorkee

Industrial Engineering Prof. Inderdeep Singh Department of Mechanical and Industrial Engineering Indian Institute of Technology, Roorkee Industrial Engineering Prof. Inderdeep Singh Department of Mechanical and Industrial Engineering Indian Institute of Technology, Roorkee Module - 04 Lecture - 03 Materials Requirement Planning A very warm

More information

Digital Image Processing. Prof. P.K. Biswas. Department of Electronics & Electrical Communication Engineering

Digital Image Processing. Prof. P.K. Biswas. Department of Electronics & Electrical Communication Engineering Digital Image Processing Prof. P.K. Biswas Department of Electronics & Electrical Communication Engineering Indian Institute of Technology, Kharagpur Lecture - 27 Colour Image Processing II Hello, welcome

More information

Entity-Relationship Model

Entity-Relationship Model UNIT -2 Entity-Relationship Model Introduction to ER Model ER model is represents real world situations using concepts, which are commonly used by people. It allows defining a representation of the real

More information

ER modelling, Weak Entities, Class Hierarchies, Aggregation

ER modelling, Weak Entities, Class Hierarchies, Aggregation CS344 Database Management Systems ER modelling, Weak Entities, Class Hierarchies, Aggregation Aug 2 nd - Lecture Notes (Summary) Submitted by - N. Vishnu Teja Saurabh Saxena 09010125 09010145 (Most the

More information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions

The Relational Model. Why Study the Relational Model? Relational Database: Definitions The Relational Model Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Microsoft, Oracle, Sybase, etc. Legacy systems in

More information

Data Modeling: Part 1. Entity Relationship (ER) Model

Data Modeling: Part 1. Entity Relationship (ER) Model Data Modeling: Part 1 Entity Relationship (ER) Model MBA 8473 1 Cognitive Objectives (Module 2) 32. Explain the three-step process of data-driven information system (IS) development 33. Examine the purpose

More information

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations 1 Topics for this week: 1. Good Design 2. Functional Dependencies 3. Normalization Readings for this week: 1. E&N, Ch. 10.1-10.6; 12.2 2. Quickstart, Ch. 3 3. Complete the tutorial at http://sqlcourse2.com/

More information

CAD/ CAM Prof. P. V. Madhusudhan Rao Department of Mechanical Engineering Indian Institute of Technology, Delhi Lecture No. # 03 What is CAD/ CAM

CAD/ CAM Prof. P. V. Madhusudhan Rao Department of Mechanical Engineering Indian Institute of Technology, Delhi Lecture No. # 03 What is CAD/ CAM CAD/ CAM Prof. P. V. Madhusudhan Rao Department of Mechanical Engineering Indian Institute of Technology, Delhi Lecture No. # 03 What is CAD/ CAM Now this lecture is in a way we can say an introduction

More information

Digital System Design Prof. D Roychoudhry Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur

Digital System Design Prof. D Roychoudhry Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Digital System Design Prof. D Roychoudhry Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture - 04 Digital Logic II May, I before starting the today s lecture

More information

[Refer Slide Time: 05:10]

[Refer Slide Time: 05:10] Principles of Programming Languages Prof: S. Arun Kumar Department of Computer Science and Engineering Indian Institute of Technology Delhi Lecture no 7 Lecture Title: Syntactic Classes Welcome to lecture

More information

Chapter 2: Entity-Relationship Model. E-R R Diagrams

Chapter 2: Entity-Relationship Model. E-R R Diagrams Chapter 2: Entity-Relationship Model What s the use of the E-R model? Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E-R Diagram Extended E-R Features Design of an E-R Database Schema

More information

We know how to query a database using SQL. A set of tables and their schemas are given Data are properly loaded

We know how to query a database using SQL. A set of tables and their schemas are given Data are properly loaded E-R Diagram Database Development We know how to query a database using SQL A set of tables and their schemas are given Data are properly loaded But, how can we develop appropriate tables and their schema

More information

1 the relational data model The relational model of data was introduced by E.F. Codd (1970). 1.1 relational model concepts The relational model repres

1 the relational data model The relational model of data was introduced by E.F. Codd (1970). 1.1 relational model concepts The relational model repres database systems formal definitions of the relational data model [03] s. yurttaοs 1 1 the relational data model The relational model of data was introduced by E.F. Codd (1970). 1.1 relational model concepts

More information

Binary Adders: Half Adders and Full Adders

Binary Adders: Half Adders and Full Adders Binary Adders: Half Adders and Full Adders In this set of slides, we present the two basic types of adders: 1. Half adders, and 2. Full adders. Each type of adder functions to add two binary bits. In order

More information

Physical Design. Meeting the needs of the users is the gold standard against which we measure our success in creating a database.

Physical Design. Meeting the needs of the users is the gold standard against which we measure our success in creating a database. Physical Design Physical Database Design (Defined): Process of producing a description of the implementation of the database on secondary storage; it describes the base relations, file organizations, and

More information

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER three Entity-Relationship Modeling CHAPTER chapter OVERVIEW 3.1 Introduction 3.2 The Entity-Relationship Model 3.3 Entity 3.4 Attributes 3.5 Relationships 3.6 Degree of a Relationship 3.7 Cardinality of

More information

Social Return on Investment

Social Return on Investment Social Return on Investment Valuing what you do Guidance on understanding and completing the Social Return on Investment toolkit for your organisation 60838 SROI v2.indd 1 07/03/2013 16:50 60838 SROI v2.indd

More information

(Refer Slide Time 00:56)

(Refer Slide Time 00:56) Software Engineering Prof.N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-12 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue

More information

Database Design and the ER model

Database Design and the ER model Database Design and the ER model 1. Database design Database design: Description of the data environment An abstraction, driven by anticipated applications Database model: A formalism for specifying database

More information

Database Design. October 24, 2008. Database Design

Database Design. October 24, 2008. Database Design October 24, 2008 Outline E-R diagrams Represent logical structure simply, clearly Rectangles: entity sets Ellipses: attributes Diamonds: relationship sets Lines: linking elements Double ellipse: multi-valued

More information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3 The Relational Model Chapter 3 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase,

More information

Chapter 3. Data Analysis and Diagramming

Chapter 3. Data Analysis and Diagramming Chapter 3 Data Analysis and Diagramming Introduction This chapter introduces data analysis and data diagramming. These make one of core skills taught in this course. A big part of any skill is practical

More information

The Structure of an MXF File:

The Structure of an MXF File: The Structure of an MXF File: The Physical view Paper supplied courtesey of Omneon, Inc. There are 2 ways of looking at an MXF file: the Physical View, which examines exactly how and where the bits and

More information

Mathematics for Computer Science

Mathematics for Computer Science Mathematics for Computer Science Lecture 2: Functions and equinumerous sets Areces, Blackburn and Figueira TALARIS team INRIA Nancy Grand Est Contact: patrick.blackburn@loria.fr Course website: http://www.loria.fr/~blackbur/courses/math

More information

SQL DDL. Applied Databases. Inclusion Constraints. Key Constraints

SQL DDL. Applied Databases. Inclusion Constraints. Key Constraints Applied Databases Handout 2. Database Design. 5 October 2010 SQL DDL In its simplest use, SQL s Data Definition Language (DDL) provides a name and a type for each column of a table. CREATE TABLE Hikers

More information

(Refer Slide Time: 02:17)

(Refer Slide Time: 02:17) Internet Technology Prof. Indranil Sengupta Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture No #06 IP Subnetting and Addressing (Not audible: (00:46)) Now,

More information

Relational model. Relational model - practice. Relational Database Definitions 9/27/11. Relational model. Relational Database: Terminology

Relational model. Relational model - practice. Relational Database Definitions 9/27/11. Relational model. Relational Database: Terminology COS 597A: Principles of Database and Information Systems elational model elational model A formal (mathematical) model to represent objects (data/information), relationships between objects Constraints

More information

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps. DATABASE DESIGN - The ability to design databases and associated applications is critical to the success of the modern enterprise. - Database design requires understanding both the operational and business

More information

EXTENDED LEARNING MODULE A

EXTENDED LEARNING MODULE A EXTENDED LEARNING MODULE A DESIGNING DATABASES AND ENTITY- RELATIONSHIP DIAGRAMMING Student Learning Outcomes 1. Identify how databases and spreadsheets are both similar and different. 2. List and describe

More information

Computer Graphics Prof. Sukhendu Das Dept. of Computer Science and Engineering Indian Institute of Technology, Madras Lecture 7 Transformations in 2-D

Computer Graphics Prof. Sukhendu Das Dept. of Computer Science and Engineering Indian Institute of Technology, Madras Lecture 7 Transformations in 2-D Computer Graphics Prof. Sukhendu Das Dept. of Computer Science and Engineering Indian Institute of Technology, Madras Lecture 7 Transformations in 2-D Welcome everybody. We continue the discussion on 2D

More information

(Refer Slide Time: 2:03)

(Refer Slide Time: 2:03) Control Engineering Prof. Madan Gopal Department of Electrical Engineering Indian Institute of Technology, Delhi Lecture - 11 Models of Industrial Control Devices and Systems (Contd.) Last time we were

More information

Data Communications Prof. Ajit Pal Department of Computer Science & Engineering Indian Institute of Technology, Kharagpur Lecture # 03 Data and Signal

Data Communications Prof. Ajit Pal Department of Computer Science & Engineering Indian Institute of Technology, Kharagpur Lecture # 03 Data and Signal (Refer Slide Time: 00:01:23) Data Communications Prof. Ajit Pal Department of Computer Science & Engineering Indian Institute of Technology, Kharagpur Lecture # 03 Data and Signal Hello viewers welcome

More information

Lecture 12: Entity Relationship Modelling

Lecture 12: Entity Relationship Modelling Lecture 12: Entity Relationship Modelling The Entity-Relationship Model Entities Relationships Attributes Constraining the instances Cardinalities Identifiers Generalization 2004-5 Steve Easterbrook. This

More information

Multi-Valued Relationship Attributes in Extended Entity Relationship Model and Their Mapping to Relational Schema

Multi-Valued Relationship Attributes in Extended Entity Relationship Model and Their Mapping to Relational Schema ulti-valued Relationship Attributes in Extended Entity Relationship odel Their apping to Relational Schema Tauqeer Hussain*, Shafay Shamail, ian. Awais Department of Computer Science Lahore University

More information

The Entity-Relationship Model. Steps in Database Design

The Entity-Relationship Model. Steps in Database Design The Entity-Relationship Model Steps in Database Design 1) Requirement Analysis Identify the data that needs to be stored data requirements Identify the operations that need to be executed on the data functional

More information

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys Database Design Overview Conceptual Design. The Entity-Relationship (ER) Model CS430/630 Lecture 12 Conceptual design The Entity-Relationship (ER) Model, UML High-level, close to human thinking Semantic

More information

Database Design and the Entity-Relationship Model

Database Design and the Entity-Relationship Model Database Design and the Entity-Relationship Model Computer Science 460/660 Boston University Fall 2013 David G. Sullivan, Ph.D. Database Design In database design, we determine: which data fields to include

More information

Take-Home Exercise. z y x. Erik Jonsson School of Engineering and Computer Science. The University of Texas at Dallas

Take-Home Exercise. z y x. Erik Jonsson School of Engineering and Computer Science. The University of Texas at Dallas Take-Home Exercise Assume you want the counter below to count mod-6 backward. That is, it would count 0-5-4-3-2-1-0, etc. Assume it is reset on startup, and design the wiring to make the counter count

More information

One of the most important topics in any discussion of TCP/IP is IP. IP Addressing

One of the most important topics in any discussion of TCP/IP is IP. IP Addressing IP Addressing 125 machine, called a RARP server, responds with the answer, and the identity crisis is over. RARP uses the information it does know about the machine s MAC address to learn its IP address

More information

Entity-Relationship Model. E/R Diagrams Weak Entity Sets Converting E/R Diagrams to Relations

Entity-Relationship Model. E/R Diagrams Weak Entity Sets Converting E/R Diagrams to Relations Entity-Relationship Model E/R Diagrams Weak Entity Sets Converting E/R Diagrams to Relations 1 Purpose of E/R Model The E/R model allows us to sketch database schema designs. Includes some constraints,

More information

2. Basic Relational Data Model

2. Basic Relational Data Model 2. Basic Relational Data Model 2.1 Introduction Basic concepts of information models, their realisation in databases comprising data objects and object relationships, and their management by DBMS s that

More information

Chapter 11. Entity-Relationship Modelling

Chapter 11. Entity-Relationship Modelling Chapter 11. Entity-Relationship Modelling Table of Contents Objectives... 1 Introduction... 1 Context... 2 Entities, Attributes and Values... 2 Entities... 2 Attributes... 3 Values... 3 Primary Key Data

More information

7.1 The Information system

7.1 The Information system Chapter 7. Database Planning, Design and Administration Last few decades have seen proliferation of software applications, many requiring constant maintenance involving: correcting faults, implementing

More information

IV. The (Extended) Entity-Relationship Model

IV. The (Extended) Entity-Relationship Model IV. The (Extended) Entity-Relationship Model The Extended Entity-Relationship (EER) Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of EER Diagrams

More information

Mathematics Task Arcs

Mathematics Task Arcs Overview of Mathematics Task Arcs: Mathematics Task Arcs A task arc is a set of related lessons which consists of eight tasks and their associated lesson guides. The lessons are focused on a small number

More information

Fundamentals of Database Design

Fundamentals of Database Design Fundamentals of Database Design Zornitsa Zaharieva CERN Data Management Section - Controls Group Accelerators and Beams Department /AB-CO-DM/ 23-FEB-2005 Contents : Introduction to Databases : Main Database

More information

SQL Simple Queries. Chapter 3.1 V3.0. Copyright @ Napier University Dr Gordon Russell

SQL Simple Queries. Chapter 3.1 V3.0. Copyright @ Napier University Dr Gordon Russell SQL Simple Queries Chapter 3.1 V3.0 Copyright @ Napier University Dr Gordon Russell Introduction SQL is the Structured Query Language It is used to interact with the DBMS SQL can Create Schemas in the

More information

Database Design. Adrienne Watt. Port Moody

Database Design. Adrienne Watt. Port Moody Database Design Database Design Adrienne Watt Port Moody Except for third party materials and otherwise stated, content on this site is made available under a Creative Commons Attribution 2.5 Canada License.

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Data Modeling. Relationships within the Relational Database:

Data Modeling. Relationships within the Relational Database: Data Modeling Relationships within the Relational Database: A relationship describes association among entities. For example, a relationship exists between customers and an agent, in that an agent can

More information

Appendix B Data Quality Dimensions

Appendix B Data Quality Dimensions Appendix B Data Quality Dimensions Purpose Dimensions of data quality are fundamental to understanding how to improve data. This appendix summarizes, in chronological order of publication, three foundational

More information

Managerial Economics Prof. Trupti Mishra S.J.M. School of Management Indian Institute of Technology, Bombay. Lecture - 13 Consumer Behaviour (Contd )

Managerial Economics Prof. Trupti Mishra S.J.M. School of Management Indian Institute of Technology, Bombay. Lecture - 13 Consumer Behaviour (Contd ) (Refer Slide Time: 00:28) Managerial Economics Prof. Trupti Mishra S.J.M. School of Management Indian Institute of Technology, Bombay Lecture - 13 Consumer Behaviour (Contd ) We will continue our discussion

More information

Gas Dynamics Prof. T. M. Muruganandam Department of Aerospace Engineering Indian Institute of Technology, Madras. Module No - 12 Lecture No - 25

Gas Dynamics Prof. T. M. Muruganandam Department of Aerospace Engineering Indian Institute of Technology, Madras. Module No - 12 Lecture No - 25 (Refer Slide Time: 00:22) Gas Dynamics Prof. T. M. Muruganandam Department of Aerospace Engineering Indian Institute of Technology, Madras Module No - 12 Lecture No - 25 Prandtl-Meyer Function, Numerical

More information

Data Modeling. Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4

Data Modeling. Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4 Data Modeling Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4 Data Modeling Schema: The structure of the data Structured Data: Relational, XML-DTD, etc Unstructured Data: CSV, JSON But where does

More information

LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen 2007-05-24

LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen 2007-05-24 LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen 2007-05-24 1. A database schema is a. the state of the db b. a description of the db using a

More information

Pre-Defense Presentation Guidelines

Pre-Defense Presentation Guidelines Pre-Defense Presentation Guidelines During your last semester of residency at Virginia Tech, you will be required to present your independent research to the faculty and your peers in a common pre-defense

More information

Exercise 1: Relational Model

Exercise 1: Relational Model Exercise 1: Relational Model 1. Consider the relational database of next relational schema with 3 relations. What are the best possible primary keys in each relation? employ(person_name, street, city)

More information

Management Information System Prof. B. Mahanty Department of Industrial Engineering & Management Indian Institute of Technology, Kharagpur

Management Information System Prof. B. Mahanty Department of Industrial Engineering & Management Indian Institute of Technology, Kharagpur (Refer Slide Time: 00:54) Management Information System Prof. B. Mahanty Department of Industrial Engineering & Management Indian Institute of Technology, Kharagpur Lecture - 18 Data Flow Diagrams - III

More information

Database Design Methodology

Database Design Methodology Database Design Methodology Three phases Database Design Methodology Logical database Physical database Constructing a model of the information used in an enterprise on a specific data model but independent

More information

Database Design Methodology

Database Design Methodology Topic 7 Database Design Methodology LEARNING OUTCOMES When you have completed this Topic you should be able to: 1. Discuss the purpose of a design methodology. 2. Explain three main phases of design methodology.

More information

7 Relations and Functions

7 Relations and Functions 7 Relations and Functions In this section, we introduce the concept of relations and functions. Relations A relation R from a set A to a set B is a set of ordered pairs (a, b), where a is a member of A,

More information

2. Conceptual Modeling using the Entity-Relationship Model

2. Conceptual Modeling using the Entity-Relationship Model ECS-165A WQ 11 15 Contents 2. Conceptual Modeling using the Entity-Relationship Model Basic concepts: entities and entity types, attributes and keys, relationships and relationship types Entity-Relationship

More information

Database Design Process

Database Design Process Entity-Relationship Model Chapter 3, Part 1 Database Design Process Requirements analysis Conceptual design data model Logical design Schema refinement: Normalization Physical tuning 1 Problem: University

More information

Online Courses: During the Course

Online Courses: During the Course Online Courses: During the Course Keep up Keeping up is essential to your success in an online course. Without weekly lectures, online courses can easily be put on the back burner. It is critical to stay

More information

RELATIONSHIP STRENGTH

RELATIONSHIP STRENGTH Connectivity and Cardinality The term connectivity is used to describe the relationship classification. Cardinality expresses the minimum and maximum number of entity occurrences associated with one occurrence

More information

The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and

The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and CMPT-354-Han-95.3 Lecture Notes September 20, 1995 Chapter 2 The Entity-Relationship Model The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and relationships

More information

Basic numerical skills: FRACTIONS, DECIMALS, PROPORTIONS, RATIOS AND PERCENTAGES

Basic numerical skills: FRACTIONS, DECIMALS, PROPORTIONS, RATIOS AND PERCENTAGES Basic numerical skills: FRACTIONS, DECIMALS, PROPORTIONS, RATIOS AND PERCENTAGES. Introduction (simple) This helpsheet is concerned with the ways that we express quantities that are not whole numbers,

More information

OPERATIONAL SCENARIOS USING THE MICROSOFT DATA PLATFORM

OPERATIONAL SCENARIOS USING THE MICROSOFT DATA PLATFORM David Chappell OPERATIONAL SCENARIOS USING THE MICROSOFT DATA PLATFORM A GUIDE FOR IT LEADERS Sponsored by Microsoft Corporation Copyright 2016 Chappell & Associates Contents Microsoft s Data Platform:

More information

Architecture Artifacts Vs Application Development Artifacts

Architecture Artifacts Vs Application Development Artifacts Architecture Artifacts Vs Application Development Artifacts By John A. Zachman Copyright 2000 Zachman International All of a sudden, I have been encountering a lot of confusion between Enterprise Architecture

More information

Foundations of Information Management

Foundations of Information Management Foundations of Information Management - WS 2009/10 Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Alexander Markowetz Born 1976 in Brussels, Belgium

More information

Infrastructure Finance Prof. A. Thillai Rajan Department of Management Studies Indian Institute of Technology, Madras

Infrastructure Finance Prof. A. Thillai Rajan Department of Management Studies Indian Institute of Technology, Madras Infrastructure Finance Prof. A. Thillai Rajan Department of Management Studies Indian Institute of Technology, Madras Lecture - 6 Basic Financial Management - Part IV Hi welcome back to this course on

More information

Lecture 1. Basic Concepts of Set Theory, Functions and Relations

Lecture 1. Basic Concepts of Set Theory, Functions and Relations September 7, 2005 p. 1 Lecture 1. Basic Concepts of Set Theory, Functions and Relations 0. Preliminaries...1 1. Basic Concepts of Set Theory...1 1.1. Sets and elements...1 1.2. Specification of sets...2

More information

Collated Food Requirements. Received orders. Resolved orders. 4 Check for discrepancies * Unmatched orders

Collated Food Requirements. Received orders. Resolved orders. 4 Check for discrepancies * Unmatched orders Introduction to Data Flow Diagrams What are Data Flow Diagrams? Data Flow Diagrams (DFDs) model that perspective of the system that is most readily understood by users the flow of information around the

More information