1.

Match the Terms on the Left with the Definitions on the Right
14 17 30 11 28 29 13 25 20 04 21 31 02 09 03 12 05 15 23 06 16 07 08 18 10 12 01 02 27 26 19 1:1 Relationships 1:M Relationships Associative Entity Attribute Binary Relationships Cardinality Cardinality Constraint Composite Attribute Concatenated Key Degree of Relationship Derived Attribute Entity Entity Type Equifinality Foreign Key Identifier Interdependent Relationships M:M Relationships Mandatory Cardinality Multivalued Attribute N-Ary Relationsihps Optional Cardinality Primary Key Relationship Relationship Constraints Simple Attribute Strong Entity Table Unary Relationship Weak Entity Ternary Relationship 01. 02. 03. 04. 05. 06. 07. 08. 09. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24 25. 26. 27. 28. 29. 30. 31. An entity which can exist independently of other entities Collection of similar entity instances A key that is associated to a key in a different table How many entities are involved in a relationship A situation where all, or some, entities depend on others for their existence A field where multiple values are possible A relationship which may or may not have a specified number of instances Uniquely Identifies entity instances Being able to reach the same point from a variety of directions An association between entities Property of an entity A well-defined field Restrictions between how entities are related A relationship where one instance is related to only one other instance A relationship where many instance is related to many other instances A relationship which can contain n entities A relationship where one instance is related to only one other instance Association between entity types Relationship of degree three Logically, putting together multiple keys as an identifier A field which is calculated A relationship where 1 instance is related to many other instances A must relationship No. of participating entity types in a relationship Can be broken into component parts Depends on the existence of another entity A relationship where only 1 table is involved A relationship of degree two Specifies Min.& Max. Number of instances Relationship modeled as entity type Person, Place, Object, Concept, Event

2. List three uses of an ERD 1. 2. 3. 4. Data Modeling (the most common Data modeling tool) Organization Planning Shows the structure, requirements and constraints of the intended system, independent of software (DBMS), at a higher level of abstraction Tool for communications between database designers and users

3. Draw each of the Basic ERD Symbols and explain What each one is. Anything About which we wish to keep Information: A Person A Place A Thing A Concept An Object An Event

Entity

An Entity which Exists Only as the result of another Entity

An Association Between Entity Types

An Association Between Entity Types with attributes of its own

Fields within a record (Entity Instances)

Fields within a record That are either Multivalued OR can be decomposed into separate fields (Composite Attributes)

Connectors between other elements

3a.

Explain what strong and weak entities are and give at least one example of each.

Entity Type
Strong

Description
An entity which does not depend on other entities for their existence An entity which would not exist were it not for its relationship to another entity

Examples
Customers Inventory Physician Orders Invoices Transactions

Weak

3b.

Draw and describe the major attribute types.

Non-Key Attributes which can be stored as a single key

The Primary key for the entity

A foreign key which refers to a field in another entity (NOTE: The underline should be dashed; HTML does not support dashed underlines)

An attribute which is calculated

An attribute which contains multiple values (see differences between the two in a later question)

4. Explain What Cardinality is, why it is important, and what basic symbols are used to represent it.

Cardinality Indicates how Entity Instances are related to each other. Without cardinality, we would not know where to place the foreign keys necessary to relate tables together Explain what cardinality constraints are and how they impact on database design.

4a.

Cardinality Constraints indicate whether the types of relationships between entities are either mandatory or optional. Mandatory Relationships indicate that the relationship MUST be maintained (e.g., a Mandatory 1:M relationship indicates that there must be one and only one on the side of the one and that there must be many on the side of the many). With respect to

database design, it may indicate that certain fields may either be left null (no data need be entered)or should be designated as NOT NULL (Data must be entered).
5. Explain What the degree of a relationship is, and give some examples of different degrees of relationships.

Degree of Relationship refers to the Number of entities participating in the relationship.

1:M Unary Relationship

M:M Unary Relationship

1:1 Binary Relationship

1:M Binary Relationship

M:M Binary Relationship

1:1:M Ternary Relationship

M:M:M Ternary Relationship

1:1:M:M relationship of Degree 4

5a.

Explain what a composite attribute is. Explain what multi-valued attribute is. Give at least one example of each.

Attribute Type
Composite

Description
An Attribute which consists of a fixed number of fields which can be broken down into individual fields (Separating the fields need not result in a separate table)

Example
Address (Street, City, State, Zip) Invoice (Order Number, Date)

Multi-Valued

An attribute which consists of a variable number of fields which when broken down will result repeating groups (Separating the attributes generally results in a separate table)

Skills Agents Patients (all may have a variable number of components)

5.b. Refer to the ERD Below to answer the following questions:

5.b1. Use the following business rules to write all appropriate connectivities in the E-R diagram:

a. A department employs many employees, but each employee is employed by one department. b. Some employees, known as "rovers," are not assigned to any department. c. A division operates many departments, but each department is operated by one division d. An employee may be assigned to many projects and a project may have many employees assigned to it. e. A project must have at least one employee assigned to it. f. One of the employees manages each department. g. One of the employees runs each division.
5.b.2. Write all the cardinalities into the model. 5.b.3. Modify the E-R model by splitting the M:N relationship into two 1:M relationships that are connected through a composite entity, then rewrite the connectivities and cardinalities to match the changes you have made.

answer

Additional Multiple Choice Questions: The questions which follow refer to this ERD:

MC1a. _B__ a. b. unary binary

This is a __ relationship. d. e. simple complex

c.

ternary

MC1b. _B__ This is a __ relationship. a. b. c. 1:1 1:M M:M d. e. 1:1:M M:M:M

MC1c. _A__ a. employee_ID b. employee_name c. address

Which of the following is a primary key? d. e. depart_id skill

MC1d. _D__ a. employee_ID b. employee_name c. address

Which of the following is a foreign key? d. e. depart_id skill

MC1e. _B__ Which of the following is a composite attribute? a. employee_ID b. address c. depart_id d. e. yrs_employeed skill

MC1f. _E__ Which of the following is a multivalued attribute? a. employee_ID b. address c. depart_id MC1g. _D__ a. employee_ID b. address c. depart_id d. e. yrs_employeed skill

Which of the following is a derived attribute? d. e. yrs_employeed skill

6.

Draw the ERD for the following situations. Show the needed attributes.

6.a. A college course may have one or more scheduled sections, or may not have a scheduled section. Attributes of COURSE include Course_ID (identifier), name, and Credits. Attributes of SECTION include Section_ID (identifier), and Semester_ID (A composite attribute consisting of Semester and Year).

6.a.

A college course may have one or more scheduled sections, or may not have a scheduled section. Attributes of COURSE include Course_ID (identifier), name, and Credits. Attributes of SECTION include Section_ID (identifier), and Semester_ID (A composite attribute consisting of Semester and Year).

NOTE: The foreign key (Course_ID) In Table SECTION Should have a dashed Underline

6.a2. I noted that this class is the relationship between you and I (which is true). However, that was kind of a simplification. For instance, at the end of the semester, you will be given a grade for this class. How do we keep track of that grade? This class is different from this course (a course can have many classes).How do we associate the two? A class is also associated with a room, and is conducted related to a specific room and semester. How?

Complete the (partially filled) ERD below. Make sure you fill indicate all of the relationship cardinalities, primary keys and foreign keys. There are also some necessary non-keys (i.e. your grade) that need to be shown.

In response to your requests, I've added some solutions to the above question:

The Data would now appears as:

The results are unchanged

6.b. A company has a number of employees. The attributes of EMPLOYEE include Employee_ID (identifier), Name, Address (A composite attribute), and birthdate. The company also has several projects. Attributes of PROJECT include Project_ID (identifier), Project_name, and Start_Date. Each employee may be assigned to one or more projects, or may not be assigned to a project. A project must have at least one employee assigned to it, and may have many employees assigned to it. An employees billing rate may vary by project, and the company wishes to record the applicable billing rate (Billing_Rate) for each employee when assigned to a particular project.

6.c.

A University has a large number of courses in its catalog. Attributes of COURSE include Course_ID (Identifier), Name, and Credits. Each course may have one or more different courses as a prerequisite, or may have no prerequisites. Similarly, a particular course may be a prerequisite for any number of courses, or may not be a prerequisite for any other course.

6 .d.

A Laboratory has several chemists who work on one or more projects. Chemists also may use certain kinds of equipment on each project. Attributes of CHEMIST include Employee_ID (Identifier), Name and PhoneNo. Attributes of PROJECT include Project_ID (Identifier), and Start_Date. Attributes of EQUIPMENT include Serial_No and Cost. The organization wishes to record Assign_Date, that is, the date when a given piece of equipment was assigned to a particular chemist on a particular project. A chemist must be assigned to at least one project and one equipment item. A given piece of equipment need not be assigned, and a given project need not be assigned either a chemist or equipment item.

NOTE: Course_ID AND PreReq_ID (in Associative Entity Prerequisite) Are BOTH Primary keys AND Foreign Keys (referencing attribute Course_ID in Table COURSE)

6.e.

Consider a simple purchase made with a credit card. Many BANKs issue a credit cards to many of its CUSTOMERs. Naturally, each CUSTOMER may have credit cards from any number of BANKs. Each BANK has a unique BankID and other characteristics. Information maintained about a CUSTOMER includes the CustID, CustName, CustAddress, CreditLimit, and AvailableBalance. The CreditLimit is the maximum amount of credit available, and the AvailableBalance is equal to the CreditLimit minus the amount of the outstanding (made but not yet paid for) purchases made by the CUSTOMER. Additionally, each credit card transaction involves the MERCHANT (the store where the customer made the purchase). Information maintained about the MERCHANT includes the MerchantID, and other information. Therefore, each credit card transaction must include information about the CUSTOMER who made the purchase, The BANK that issued the credit card, and the MERCHANT who sold the item(s). Transaction Information must also include the date of the transaction, as well as the amount of the transaction (if an item is returned, the amount of the transaction is negative). Draw the ERD to reflect this situation.

* Primary Key ** Primary AND Foreign Key

6.01 The other day I was at TGIFs, and I started wondering about the database they, and probably every other restaurant, used to keep track of their employees. So I asked my friend, the bartender. He told me that they did keep information on each employee, things like IDs, Names, Addresses, and so forth. It turns out that because TGIFs has a number of restaurants in the same city (each with their own Restaurant IDs), many employees could work a many of the restaurants. Naturally, each restaurant has many employees. Each employee can have many different titles, which surprised me. For example, an employee can be a waiter, a bartender, a cook, a gopher, and so forth it all depends on where they are needed. They keep track of things like position name, and title pay rate. It turns out that titles are filled in terms of the skills necessary for that title. A title may require many skills, and, of course, a skill may be used in many titles. For example, the waitress and bartender titles both require interpersonal skills and a good memory, as well as other skills. As it turns out, when an employee is hired, they are given a number of tests to determine their skills. Each employee generally has a number skills (interpersonal skills, cooking skills, cleaning skills), and of course, each skill is shared by a number of employees (this in spite of the fact that I have yet to find a bartender there that can get you a drink in less than 15 minutes; maybe they dont consider speed a skill). Draw the ERD for this situation. Make sure you show ALL of the primary and foreign keys necessary, the cardinality and cardinality constraints for each of the relationships. If additional fields are necessary, show them, but you need not show ALL of the fields you would add (a simple composite field called Others will suffice).

6.10 Consider a chain of stores, such as Sears. Each store employs a number of employees, but an employee can only be employed by one store. At each store, there is one and only one employee who is the store manager. However, within each store, there are many Supervisors, all of whom are also employees. These Supervisors can supervise Many other employees. Each store sells many different items. Each item is generally sold at each store, although some stores sell unique items, and the quantity of items on hand typically varies from store to store. We also need to keep track of the cost of each each item, which is also the same at each store. The basic template (with many missing entries) is given below:

Fill in the template with appropriate table names and fields. Check your design by entering sample data for table. The link below will take you to a possible solution. CLICKING ON THE LIST BEFORE YOU TRY AND COME UP WITH YOUR OWN SOLUTION IS A COMPLETE WASTE OF YOUR TIME; YOU WILL NOT LEARN ANYTHING, AND PROBABLY WILL NOT BE ABLE TO ANSWER THIS PROBLEM ON THE TEST (should it be asked of you).

answer
6.10. Given The problem and the Template:

One Solution might be:

The data to illustrate the problem could be:

7.

Prepare an ERD for a real estate firm that lists property for sale. The following describes the organization (NOTE: For most of the information given, it is up to you to determine which are primary keys):

The firm has a number of sales offices in several states. Each office is identified by a Office_Number and its location. Each sales office is assigned one or more employees. Attributes of employee include Employee_ID and Employee_Name. An employee must be assigned to only one sales office. For each sales office, there is always one employee assigned to manage that office. An employee may manage only the sales office to which s/he is assigned. The firm lists property for sale. Some of the information they keep track of include Property_ID and location. Components of location include Street, City, State, and Zipcode. Each unit of property must be listed with one (and only one) of the sales offices. A sales office may have any number of properties listed, or may have no properties listed. Each unit of property has one or more owners, who are identified by Owner_ID and Name. An owner may own one or more units of property.

answer

8.

You have been asked to develop a preliminary ERD for a symphony Orchestra. So far, you have uncovered the following Entities: CONCERT SEASON. The Season during which a series of concerts will be performed. One of the attributes you have chosen is Opening_Day, which includes Month, Day, and Year. CONCERT. This is a given performance, which consists of one or more compositions. Some of the attributes decided upon include Concert_No and Concert_Date, which consists of Month, Day, Year and Time. Each Concert is generally, although not always, perfomed on more than one concert date. COMPOSITION. Each concert may have may compositions performed, although sometimes, only one composition is performed. Attributes decided upon include Composition_ID, Composer_Name, Composition_Name, and Movement_ID (Which is a composite attribute consisting of Movement_Number and Movement_Name). Many, but not all, compositions have multiple movements.

CONDUCTOR. Although there is a principal conductor, who generally conducts the symphony, there are frequent guest conductors. This entity includes Conductor_ID and Conductor_Name. SOLOIST. The symphony frequently, although not always, employs guest soloists. These are identified by Soloist_ID and Soloist_Name.

During further investigation, you discovered a number of additional considerations: During a concert season, there are one or more concerts scheduled. A particular concert is scheduled only once in a season. The Concert includes the performance of one or more compositions. However, A composition may be performed at one or more concerts, or may not be performed all season. For each concert, there is one and only one conductor. A conductor may conduct any number of compositions, or may not conduct that season. Each composition may require one or more soloists, or may not require a soloist. A soloist may perform one or more compositions at any given concert. The symphony wishes to record the date when a soloist last performed a given composition (Date_Last_Performed).

answer

9. 8.5. We know that the Treatment ERD we constructed was unrealistically simple. Here are some of the modifications we need to make:

1. 2.

A treatment can include multiple physicians A treatment can include multiple nurses (for simplicity, assume each nurse costs $100/hour).

3. A treatment can include multiple treatment procedures. Each of these procedures are associated with a cost. 4. A treatment can involve the administration of multiple drugs (during the treatment). Each of these drugs is associated with a cost. 5. Treatments can be performed in any number of locations. The costs for treatment also vary with the cost of the location.

As we know there are a number of additional considerations (In-patient v. out-patient treatments, hospital room costs, meals the list can be very long). Lets recognize them, but not include them here.

Draw the necessary ERD to reflect this situation.

9.

Consider a Hockey Game. A Game is really nothing more than a relationship between two Hockey Teams. For Example, the New York Rangers play the Buffalo Sabres many times in a season. Sometimes, The New York Rangers are the HomeTeam, and sometimes they are the VisitingTeam. For each game played, we need to keep track of who is the HomeTeam, who is the VisitingTeam, When they played (i.e., the DatePlayed), What the HomeTeamScore was, and What the VisitingTeamScore was. Each Team is identified by a TeamID. We need to also keep track of each TeamName, and other information. Each team also employs a number of players. Each player is identified by a PlayerID. We also keep track of each PlayerName, as well as other information. Unfortunately (for this problem), a player can play for a number of different teams during their careers. As a matter of fact, a player might play for one team, be traded to another, and then later be traded back to the team they played for previously. We must therefore also keep track of when a player started playing for a particular team, and when they stopped playing for a particular team (if they are still playing for a team, the value NULL is placed in the date they stopped playing for a particular team).
Draw the necessary ERD to reflect this situation.

answer

Consider a Hockey Game. A Game is really nothing more than a relationship between two Hockey Teams. For Example, the New York Rangers play the Buffalo Sabres many times in a season. Sometimes, The New York Rangers are the HomeTeam, and sometimes they are the VisitingTeam. For each game played, we need to keep track of who is the HomeTeam, who is the VisitingTeam, When they played (i.e., the DatePlayed), What the HomeTeamScore was, and What the VisitingTeamScore was. Each Team is identified by a TeamID. We need to also keep track of each TeamName, and other information. Each team also employs a number of players. Each player is identified by a PlayerID. We also keep track of each PlayerName, as well as other information. Unfortunately (for this problem), a player can play for a number of different teams during their careers. As a matter of fact, a player might play for one team, be traded to another, and then later be traded back to the team they played for previously. We must therefore also keep track of when a player started playing for a particular team, and when they stopped playing for a particular team (if they are still playing for a team, the value NULL is placed in the date they stopped playing for a particular team).
Draw the necessary ERD to reflect this situation.

I'm learning database this semester. The homework on e-r model really confuses me. The homework is drawing the e-r diagram about a vegetable market: A Vegetable Market has a collection of numbered stalls. Each stall has a name (unique) and sells at least one kind of vegetables (each kind of which has a name). Each stall sells each vegetable at its own particular price. Each farm grows some(at least one, but not all) of the vegetables, but a vegetable must be grown by at least one farm. Each farm has one name (unique) and address. Each stall buys each vegetable from only one farm at a particular price they have agreed. My question is that how to describe the constraint "(at least one, but not all)" in the requirement? Another question is that since vegetables don't have primary key or discriminator, should they be treated as entities? Or should they be treated as somethings else like attributes?

Here's my answer:

1 Answer
Ad.1 As far as I know it is impossible to place on a ERD diagram information like at least one, but not all, I would simply mark the relationship as one or more, which is possible. The only thing that comes to my mind is placing an appropriate comment, stating that requirement. Ad. 2 Yes, vegetable in my opinion should be represented as a separated entity. If you wanted to place it as an attribute, you coud do this as an attribute of entity "Farm_grows", but you will not be able to preserve uniqueness, you will have to have some key anywas, and finally the worst thing is that, it wouldn't be 3NF. My propositions is on the below diagram - unfortunatelly I do not have a tool that supports your notation (I know it would be possible to do it in Visio, but you shouldn't have any problems translating my notation to yours).

The difference in comparison to yours is that I have one relationship for SELL and BUY, which isSTALL_VEGETABLE. Why is that so? Because of this requirement: "Each stall buys each vegetable from only one farm at a particular price they have agreed." My model preserves that the Stall sells only those vegetables, that it bought, and also it becausestall_name and vegetable_name are withing PK, it is impossible for Stall to buy one vegetable from different farms - your model allows that.