In this chapter I introduce the concepts of entity-relationship (ER) modelling. At the end of this chapter you should be able to explain and apply these concepts.
Data bases, and the data base management systems that lord over them, are the core information systems technology. They are used---and will be used---to store corporate data, web pages, on-line movies, work flow information, document databases---absolutely everything that is of interest to business. After taking this class you will clearly understand and be able to explain why this is a good thing. This understanding will allow you to see opportunities for exploiting this technology in innovative ways.
Both of the above will be useful for a student (and eventual businessperson) whether they be interested in accounting, marketing, human resources, or finance. Business process reengineering (BPR) (by whatever name) virtually demands that data bases take a more central role in a corporations life. By its very definition BPR demands that people from throughout an organisation apply information technology solutions to broad problems. Data bases are one of the more frequently applied solutions. Thus, I propose that a great percentage of students interested in business should be knowledgeable about data bases.
The whole purpose of ER modelling is to create an accurate reflection of the real world in a database. The ER model doesnt actually give us a database description. It gives us an intermediate step from which it is easy to define a database. Lets look at an example. (You will see much more detail on these concepts in the rest of this chapter. For now just try to understand the overall process.)
Suppose you are presented with the following situation and are told to create a database for it:
Every department within our company is in only one division. Each division has more than one department in it. We dont have an upper limit on the number of departments that a division can have. For example, the New Business Development---the one managed by Mackenzie---and Higher Education departments are both in the Marketing division.
This is a fairly clear description of a situation. Many things are left unsaid that we understand about the situation. For example: each division has a name, and that name is unique within the company. For now, though, lets focus on the description as it is given.
The first step is to figure out the items of interest in this situation. (In this document you will come across Problems. You should attempt to perform these before continuing the reading. Simply reading the problem and then reading the answer is not sufficient---you should attempt the problem yourself before you continue reading. Understanding these problems are integral to understanding the text. The answer to the problem appears in the text immediately after the problem.)
It seems here that the situation is concerned with divisions, departments, and employees or managers. It gives some details about which contains which, how they are related to each other, and provides some examples of each, but basically the situation is concerned with these three entity types. Heres a formal, if somewhat ambiguous, definition.
An entity type is a collection of entities that share a common definition. An entity is a person, place, concept, or thing about which the business needs data.
So, Department is the name of one entity type. One instance of this entity type is the New Business Development department. The Marketing division is an instance of the Division entity type. Mackenzie is one instance of the Employee entity type. Instances of entity types are referred to as entities. Put more simply: You can touch an entity but an entity type is simply an idea. Person is an idea (entity type) while Scott, Nancy, Lindsey, and Mackenzie are touchable (entities). Entity types provide us with a means for making generalisations about entities. For example, instead of saying Every department within our company is in only one division, we could have gone down the list of all departments (that is, all entities with entity type Department) and asserted that each one is, indeed, in one division:
The New Business Development department is in one division. The Higher Education department is in one division. ... And so on until weve noted that each is on only one division.
But we know more than the facts about each individual department being in one division. We know that all new departments will also be in just one division. And if there is a new division, it, too, will have departments that are unique to the division. So, instead of providing information in the form of statements about specific entities, we use a more powerful and concise format and provide information in the form of statements about relationships among entity types.
Thus, in ER modelling we look for relationships among entity types because it is easier and more concise to speak of relationships among general entity types rather than the touchable entities themselves.
The municipal bond is an entity; bond is a possible entity type. Ford is an entity; manufacturer is a possible entity type. Clothes could be either: 1) a type if the entities are pants, shirts, etc.; 2) an entity if the type is product. Employee is an entity type; Angela and Natalie are example entities.
Back to our example: we have identified three entity types and four entities. From the description we can assume that there are more entities for each entity type. Go back and read the situation description if you do not think this is immediately obvious.
From the description there is some sort of relationship between Department and Division and another sort of relationship between Department and Employee. The first relationship is one of containment: each division has one or more departments, but any one department can only be in one division. (Think about an NCAA conference such as the Big 10 (the bucket) having many teams (a bunch of balls). On the other hand, each team (one ball) can only be in one bucket (a conference). In this instance the bucket is the division and the balls are the departments.) The second relationship tells us that an employee has a certain relationship relative to a certain Department, namely, that the employee manages the department. Determining the relationships among entity types is another important step in the process of ER modelling.
A relationship is an association between entity types.
The defining characteristic of a relationship is that several entity types are involved. So something like a name or birth date would not be a relationship since only one entity is involved.
Now we have identified three entity types (Employee, Department, Division) and two relationships among these entity types (manages, contains). Now we can begin to represent the problem in the language of ER modelling.
ER models are usually represented graphically. The language we are going to use represents entity types as rectangles and relationships as diamonds. Below is the representation of the situation we are working with.
Notice that the contains relationship is drawn between the two entities that it is associated with. Similarly for the manages relationship. This (simplified) ER model tells us that:
Certainly we know more about the problem than this. Consider the relationship between divisions and departments. We know that divisions have multiple departments and departments can only be contained within one division. Or, for every one division there can be many departments. In the language of ER modelling this is called a 1:M (read: one to many) relationship.
The relationship between department and a managing employee is different. It doesnt say so but we can assume that a department has only one manager. (Certainly you can imagine an instance in which a department has co-managers. That possibility is just as viable as the possibility I have assumed. This is part of the attraction of this type of work. The database professional has to read descriptions for what is said and then imagine what isnt said. If you were actually creating a database in this example, you would have to ask someone what the situation actually is. But since you are just given this description, you have to come up with some assumption. For this situation well make the above assumption.) Well also assume that an employee can also be the manager of, at most, one department. In other words, for every one department there can be, at most, one managing employee. In the language of ER modelling this is called a 1:1 (read: one to one) relationship. This information can also be represented in the ER diagram:
As you might have determined, the M part of a relationship is represented by putting an M next to the appropriate entity type in the relationship while the 1 part is represented by a 1. The ER diagram now represents much more information than it did above:
If you are a bit confused about all this 1:M and 1:1 stuff, never fear. Youll see a lot more clarifying detail later.
Several other questions remain about this situation that are not addressed in the description:
These questions would have to be answered before we complete the ER model. And we will answer these questions later. For now we are going to stop this part of the analysis since the purpose of this example is to demonstrate what ER modelling is all about.
The ER modelling process is not something for which a set of steps can be given and then performed. The process contains almost as much art as science. Some steps are performed many times and many decisions are re-visited and revised. Given these conditions, a broad outline can be given:
Understand now that there are several methods for representing ER models graphically. Some dont use the diamonds for the relationship---they might just put the word above the line. Its not really important how the entity types and relationships are represented; its just important that they are represented.
Notice what has happened with this situation. Initially we had a text description of the problem. After analysing it and making some necessary assumptions, we created an ER diagram that reflects the situation accurately and makes explicit the relationship among the entity types. This is why we perform ER modelling. We dont know any more than we used to about the problem---we just have made explicit what we do know. It is quite a straight-forward step to go from this ER model to an implemented database. Remember why we are doing all this: We are finding out all we need to know to create a database that will hold our data. And a well-defined database can be a very useful tool for solving business problems---and it is also in high demand by recruiters. You will learn how to perform the steps necessary to create such a database in later chapters.
In this previous section I used an example to present an overview of how and why ER modelling is performed. In this section I present more detail on some of the basic concepts.
Relationships define which entity types are directly associated with which other entity types. In the example in an earlier section, we saw that divisions are directly associated with departments and departments are directly associated with employees. No direct association between division and employee was given. This does not mean that there is no relationship between division and employee. In fact, the ER diagram tells us that there is a relationship between the two:
Given any one division, there can be many employees managing departments within that division.
Certainly, this is not earth shattering news. But it is in the ER diagram. The above fact is not represented as a separate relationship between division and employee because it can be inferred from existing relationships. An ER diagram should contain the minimum number of relationships necessary to reflect the situation.
Once a relationship between entity types has been established, the analyst should determine its cardinality.
A relationships cardinality defines the maximum number of entities of one type that can be associated with an entity of another type.
For relationships between two entity types, there are three basic cardinalities. Each of the following descriptions are given in terms of a relationship between entity type X and entity type Y.
An example: the relationship between car and steering wheel. A car has only one steering wheel and a steering wheel can only be installed in one car.
An example: the relationship between building and rooms. A building can have many rooms but a room can be in, at most, one building.
Answering these two questions gives you the answer to the following questions. For example, if you answered M to the first question and 1 for the second question, then this relationship between entity types X and Y is of cardinality M:1. This is read as for every X there can be only one Y and for every Y there can be many X. Realize that you will have to make assumptions about the situations below to clarify some of these relationships.
It would seem that at any particular time a patient can only have one primary care physician and that any physician can have many patients (M:1). One physician can perform many operations and one operation can be performed by many physicians (M:M). One doctor can have specialities in many diseases and one disease can be the speciality of many doctors (M:M). One needle can be injected into one patient and one patient can have many needles injected into him/her (M:1).
In the previous section we were concerned with the maximum number of entities of one type that can be associated with an entity of another type. In this section we examine the minimum number of entities in a relationship.
A relationships existence defines what we know about the existence of any entity on the other side of a relationship from a given entity. Existence is given as optional, mandatory, or unknown.
This is best clarified with an example. Consider again the example discussed in Section 2. Specifically, focus on the manage relationship between department and employee. We know the cardinality is 1:1. This tells us that at most one department is managed by an employee and an employee can manage, at most, one department. (Be sure you understand the distinction between these two phrases.) The existence of this relationship tells us the fewest number of departments that can be managed by an employee and the fewest number of employees that can manage a department. Only one of the following can be true:
Similarly, only one of the following may be true:
It is not entirely clear from the situation description which of the above are true. I make the relatively standard assumptions that a department must have at least one manager and that an employee need not be the manager of any department. Thus, the existence of this relationship is mandatory in one direction and optional in the other.
Going back to the definition of existence, we can also look at this situation in this way:
I assume that the contains relationship is mandatory in both directions. Given this information, the ER diagram is modified in the following manner:
This diagram is beginning to look a little complicated but remember the following pieces of information and it gets a little easier:
Lets practice this. Look at the manages relationship again.
Entity types are things for which it is important that your company capture data. If it is not important, it should not be in the database. In an accounting database you would expect to find entity types for expenses, assets, liabilities, expenditures, deposits, etc. You would not expect to find entity types for colour of check, quality of dollar bills received, etc. The database is supposed to reflect reality---but only the part of reality that is important to the company.
Entity types are entities that share a common definition. This allows us to make generalisations about that type. This is a powerful capability; however, sometimes we want to make a generalisation only about a certain subset of those entities and another generalisation about the rest of the entities. Consider a simple example. Suppose you have an accounting database which keeps track of accounts receivable and accounts payable. Of course the database keeps track of the companies to which you owe money and the companies that owe you money. For all these companies, you keep track of their mailing address and a contact person. For the companies that owe you money you keep track of how much they owe you. For the companies that you owe money you keep track of how much you owe them. What to do? Should we have three entity types: one for the whole set and one for each subset? That would be a mess. That is why the concept of entity subtypes was created.
An entity subtype is a collection of entities of the same type to which a narrower definition and additional attributes and/or relationships apply.
In this database you should define a company entity type with two subtypes: AR_co and AP_co. The company entity type stores all facts that are common attributes---in this case, the address and contact person. The AR_co entity subtype tracks the balance owed from this company while the AP_co entity subtype tracks the balance owed to this company.
There are many situations in which subtypes can be created but should not be. Only create subtypes
If one of these two requirements is not met, then do not create the subtype.
On the other hand, there are some situations that are not so clear cut. Consider the following figure.
Many students would first suggest the diagram on the right---divide customers into investors and attendees and show that investors buy stocks and attendees register for seminars. I suggest that the figure on the left is better. Heres my thought process:
What is it that makes an investor an investor? She buys stocks. And what is it that makes an attendee an attendee? She registers for seminars. Is there anything about an investor that keeps her from being an attendee? No. Vice versa? No. Do you want to prevent investors from being classified as attendees or vice versa? No and no. So, define relationships buy and register for the customer entity. Investors can be listed by choosing only those customers that are in the buy relationship. Attendees can be listed by choosing only those customers that are in the register relationship.
Thus, if a relationship defines the members of a proposed subtype, then use the relationship instead of the subtype.
For some people this can one of the more difficult concepts to understand, so read carefully. What we are trying to discern here is the difference between a type of a thing and an actual thing. This is a pretty easy concept when comparing people and Joe. People is the type and Joe is the instance. However, modellers generally dont make the type/instance distinction between an entity type and an entity---they generally make it between two entities. For example, think about CT481 and section 2 of CT481 in Winter 1962. The second is an instance of the first. The section is an actual class that meets at an actual time with an actual teacher and actual students. CT481 is a type of thing that is an idea that only becomes real when you come into contact with one of its instances (e.g., section 2 of CT481 in Winter 1962).
Realize that this is a different distinction than that between entity types and entities. In this example, CT481 is one specific instance of the entity type Course and section 2 of CT481 in Winter 1962 is one specific instance of the entity type Section. Thus, both are entities and neither one is an entity type.
Boeing 747 is a type of plane and a specific Boeing 747 that flies through the air with passengers in it is an instance of this type. Boeing 747 is a specific instance of the entity type plane type and a flying Boeing 747 with passengers is a specific instance of an entity type plane.
To this point we have focused on entity types and relationships among them. We have mentioned, in passing, facts about entity types and attributes of entity types. In this section I hope to make these ideas a little more clear.
Attributes are the characteristics of an entity type that we are interested in.
An attribute is a descriptor whose values are associated with individual entities of a specific type.
The attribute value for any single entity can have only one value at a given time. This value can change over time. An attribute of an employee might be salary. At any one time if you asked for the salary level of a certain employee, then you should get one answer. And if someone else asked the same question about that employee at the exact same time, they would expect to get the same answer. Of course, if you asked this question at a later time you might expect to get a different answer.
Think back to the example in Section 2. Few attributes are mentioned in the description but a few can be inferred. The department entity type has a name attribute, as do the division and employee entity types. Possible attributes for the employee entity type that arent mentioned include date of hire, home mailing address, work phone, and work address.
Every entity type has an identifier. This identifier uniquely identifies a single (at least one, and no more than one) entity. If you know the value of the identifier, then you know exactly which entity you are dealing with. Further, the identifiers value will never change over time. Thus, if you know the identifier now, then you can be confident that at any time in the future the identifier for that entity will not have changed.
Consider the two choices:
The concepts in the previous two sections of this chapter will allow you to model many business situations. The following concepts are needed to round out your repertoire so that you will be ready for almost any situation that comes your way.
Relationships can be classified by the number of entity types involved. This is referred to as the degree of a relationship. To this point we have concerned ourselves with relationships between two entity types. This is, by far, the most common type of relationships. The most common degrees of relationships are as follows:
I will not spend any time on binary relationships now because we have discussed them at length already.
In the real world there are relationships other than those involving two things. For example, suppose that we want to capture which employees use which skills on which project. We might try to represent this data in a database as three binary relationships between skills and project, project and employee, and employee and skill.
The applies relationship indicates which employee applies which skill. The used on relationship indicates which skill is used on which project. The works on relationship indicates which employee works on which project. But this is not enough to specify which employee uses which skill on which project. Suppose you know the following:
Given this information, it is impossible to figure out on which projects Lindsey used which skills. She could have used interface design on project B and database design on project A---or the other way around. Or she might have used both skills on both projects. The database simply does not give us enough information.
In order to capture the necessary information the database needs a ternary relationship. In this case the database needs a relationship, called used- on, among employee, skill, and project.
The used on relationship captures information three pieces at a time. It stores facts such as:
Notice that this ternary relationship captures the information represented in the three binary relationships:
Implementing ternary relationships does not mean that you have to get rid of the binary relationships. You only get rid of the binary relationships if they capture a subset of the information captured by the ternary relationship. If a binary relationship captures information that differs from the ternary relationship, then the binary relationship should be retained if the information is important to your company. For example, consider the following:
The used on relationship stays the same as in the previous ER diagram. The binary relationships are different.
Question: Using this data, who sold Sam the Cobra?
Question: Using this data, who sold Sam the Cobra?
In situation #1 you can see from the first line that Don sold Sam the Cobra. In situation #2, looking at buys you can see that Sam did actually buy a Cobra (second line). Looking at buys from you can see that both Don and Sharon sold Sam cars. Looking at sells you can see that both Don and Sharon have sold Cobras. So the answer is either Don or Sharon sold Sam the Cobra. This is not good enough. This demonstrates that having three binary relationships does not capture the same information that one ternary relationship does.
It might be asserted (and has been by a former student) that the ambiguity in the problem is a result of the data base keeping information about car types (Cobra, Mustang, etc.)\ instead of actual cars (Cobra VIN=32, Cobra VIN=33, etc.). This is the case and Id like to demonstrate why here.
Suppose that the four cars in this data base are numbered 1, 2, 3, 4. Were going to try to answer the same question, Who sold Sam the Cobra?, using just the binary relationships but with information about numbered cars rather than the car types that is used above. The Buys relationship shows that Sam bought cars 1 and 2. The Sells relationship will show which sales person sold car #2 (the Cobra). It does not say to whom, but we already know that Sam bought car #2. So without even consulting the Buys from relationship, we know who sold Sam the Cobra.
This is a good observation but does not change the essential point. Breaking down a ternary relationship into its component binary relationships will sometimes result in a loss of information. It will always result in a loss of data if at least one of the entity types is a type of thing (e.g., a car or skill) as opposed to a specific thing (e.g., an actual car).
The question also remains: Why break up a ternary relationship into its component binary relationships if the ternary relationship captures whats really going on in the world. A customer does buy a car from a salesperson. Thats really how we think about it and how it really occurs. Its not: a customer buys a car, a car is sold by a sales person, and a customer buys from a sales person. The real world event involves three entities. Why not construct the data base to reflect this reality?
Thus far in this section the ER diagrams have not represented the cardinality of ternary relationships. There is a different method for determining cardinalities of higher order relationships:
To determine the cardinality for this relationship, I had to make several assumptions. Other assumptions are possible but I thought these seemed reasonable.
Given these assumptions, the cardinality for each entity type is M. So this is a M:M:M relationship.
The final, and possibly the most difficult, relationship is the recursive relationship. This is a relationship that an entity has with itself. But it really doesnt have to be difficult if you think about it as you would any ordinary binary relationship. Lets look at an example.
Think of an employee who is the manager of other employees.
A manager manages many employees and an employee has exactly one direct manager. This is pretty straightforward. But, now, realize that a manager is really just another name for an employee. So, replace managers with employees in this diagram.
Now this diagram has the entity type employees represented twice. To remedy this situation, pull the relationship diamond down and slide the two employee rectangles so that they are lying on top of each other. Now the diagram looks like the following:
This diagram represents what we want:
Not everyone in the company has a manager. The president will not have a direct manager. This is handled in the data in the table by indicating that the presidents manager is the president. A little trick.
When we examined attributes earlier, the attributes were exclusively attached to entity types. However, it is also possible for a relationship to have attributes. Consider the is member relationship below.
A person can be a member of many clubs and a club can have many members. A natural piece of information to want to store is the date the person joined the club. If the attribute is of the person entity, then this would indicate when the person joined a club but we would not know which club. If the attribute is of the club entity, then this would indicate (possibly) when the club was founded or (possibly) when the most recent member joined the club but we would not know the dates on which each person joined. The solution is to make join date an attribute of the is member relationship.
This section describes two different ways in which subtypes of an entity can be related to one another and to the super-type.
Assume there is an entity type called person, and entity subtypes called customer and employee. When a person is created, the designer of the database has two options:
Neither one is preferable to the other. The proper one to choose depends on the business situation.
Mandatory sub-typing is represented by creating a double line from the super-type (person in the following ER diagram) to the circle. Optional sub-typing is represented by leaving a single line from the super-type to the circle.
So, what does this figure tell you? Since it is a mandatory subtype partitioning (you know this from the double line), whenever data for a new person is entered into the database, it must be classified as either a customer or an employee. The database user cannot simply add information about a generic person---she must know whether this person is a customer or an employee. If this had been an optional subtype partitioning, then when that user was entering data about an employee, she had the option of classifying the person as an employee or as a customer---but did not have to classify the person as either.
Consider now the company super-type and the subtypes AR_co and AP_co. As a designer you can specify whether or not an entity of subtype AR_co can also be an entity of type AP_co. Certainly it is not abnormal to think that you can do business with companies that do business with you. Think of being a consultant for Ameritech or IBM.
The following are the two possibilities:
Disjoint subtypes are represented by putting a d in the circle. Overlapping subtypes are represented by putting a o in the circle.
The above figure tells us that this is a disjoint entity sub-typing. This means that whenever data for a new company is entered into the database, the company can be classified as either AR_co or AP_co but not both. If this had been an overlapping entity sub-typing, then when that user was entering data about a company, she would have had the option of classifying the company as both AR_co and AP_co.
Suppose I didnt tell you that this should be an entity subtype problem. Would you represent it this way? What else would you do?
I would think that these would be optional, overlapping entity subtypes. But if I were not going to represent it this way, I may consider having a M:M relationship between student and major.
Certainly, entity subtypes should be classified along both dimensions---that is, you should identify whether the subtype is mandatory or optional and whether it is disjoint or overlapping. All four combinations are possible and each is appropriate at different times.
Subtypes are generally thought of in terms of X is a Y (which is why these are commonly referred to as is-a relationships). Another type of relationship that needs to be represented in a database is the part of relationship, more formally called aggregation. When an entity is made up of several different types of other entities, an aggregation relationship may be called for.
Consider the relationship between a car and its engine and body. The engine and body are both part of the car. The relationship is represented as follows in an ER diagram.
Two entities can have more than one type of relationship. This is not surprising; further, it is not difficult to represent in a database or in an ER diagram. Consider the entity types person and insurance policy and the relationships between them of pays for and is insured under.
Look at these relationships one at a time.
These are two distinct relationships. They mean two different things---that is why they are represented as two separate relationships in the ER diagram.
Weak entities are entities, but with a difference---weak entities only exist because some other entity exists. For example, if you were to define two entities employee and salary-history, then the second would be a weak entity because the record of an employees salary history could only exist if a record of an employee also exists. Joe Smiths salary history wouldnt make much sense if Joe Smith doesnt exist in the data base. A weak entity is represented by a double border as shown below.
Sometimes it is instructive to classify an attribute by the means in which the value is determined. Here are the three possibilities.
Not all entities have a value for every attribute; however, some attributes must have a value for all entities.
For example, assume the employee entity type has attributes hire date and termination date. Hire date would certainly be classified as a mandatory attribute; if the employee didnt have a hire date, then the person couldnt very well be an employee.
Termination date is an optional attribute. You would expect that many people in the database would not have a termination date while others, who are obviously ex-employees, do have a value associated with the termination date attribute.
The optionality of an attribute depends highly on the business situation, how the information is gathered, and how the business updates its database. One company might classify an attribute of an entity type as optional while another company might classify the same attribute of the same type as mandatory. Consider the following example:
Consider the attribute sale price of the catalog item entity type for a computer mail order company. Company A has a policy that they do not put an item into the catalog until it has a price; thus, they do not create a catalog item entity until they can assign a value to the attribute sale price. For this company the sale price attribute is mandatory.
On the other hand, Company B has a policy that they put an item into their catalog as soon as they decide to stock it. This way they can make their product line look as broad as possible. They put Call us for latest quote in the catalog instead of a price. Thus, they do create catalog items even before they have assigned a value to the attribute sale price. For this company the sale price attribute is optional.
Again, in order to classify an attribute as optional or mandatory, you must understand the business situation and practices.
The database designer should also determine miscellaneous other information about each attribute:
address = 202 Crest Avenue, Ann Arbor, MI 48103
An alternative to this would be to store these pieces of data in separate fields in the table. For example, the above information might be stored as
street = 202 Crest Avenue
city = Ann Arbor
state = MI
zip = 48103
Separating the attributes in this way allows database users to refer to each field independently. For example, under the second scheme a user could easily and quickly determine the employees who live in Michigan. Under the first scheme this would not be nearly as fast.
ER diagram for interpretation exercise
The point of this section is to give you some examples of how ER diagrams are interpreted. I try to give you some of the variations but I certainly do not give you all of them. If your reading of a relation is not below, then it is not necessarily wrong. Try to determine if they mean the same thing. If they dont and you cannot figure out the problem, then come by and talk with me during office hours.
Notice that the other two entity types are held constant; that is, for the project arm (the first one) you are determining how many projects can be associated with any single pairing of employees and skills. You can think of it the following way: I have an employee named Fred. He is skilled in woodworking. How many projects can Fred be a woodworker on? If its many, then put an m on the project arm; if its one, then put a 1 on it.
What is the cardinality and existence of each of the following relationships in just the direction given? State any assumptions you have to make.
For each of the following pairs of rules, identify two entity types and one relationship. State the cardinality and existence of the relationship in each case. If you dont think enough information is available to define either of these, then state an assumption that makes it clear. Draw the ER diagram.
Draw an ER diagram for the following. Be sure to indicate the existence and cardinality for each relationship.
Draw an ER diagram for each of the following situations. On the diagram be sure to identify the cardinality, existence, and optionality (for subtypes) of each relationship.
Draw an ER diagram to represent the following entity types and the natural relationships among them: Vehicle, Land-vehicle, Air-vehicle, Water-vehicle, Ocean-vessel, River-raft, Helicopter, Rail-vehicle, Road-vehicle, Car, Airplane, Bicycle.
Draw an ER diagram that best represents the following situation. There are three types of accounts in a bank, with these attributes:
Consider the following diagram:
The following facts make up all of the leads relation between person and project:
You do not know whether or not there are any other people or any other projects. Which diagram(s) that is (are) consistent with this set of three facts. For example, you might answer 1, 4 if both 1 and 4 are consistent with the above facts.
For each of the following sets of sentences, draw the corresponding ER diagram.
The following descriptions all have to do with a holding company for food service companies. You should answer each one separately from the others.
Scott A. Moore, all rights reserved.