View
78
Download
1
Category
Tags:
Preview:
DESCRIPTION
DATABASE
Citation preview
1. Match the Terms on the Left with the Definitions on the Right 14 1:1 Relationships 01. An entity which can exist independently of other entities17 1:M Relationships 02. Collection of similar entity instances30 Associative Entity 03. A key that is associated to a key in a different table11 Attribute 04. How many entities are involved in a relationship28 Binary Relationships 05. A situation where all, or some, entities depend on others for their existence29 Cardinality 06. A field where multiple values are possible13 Cardinality Constraint 07. A relationship which may or may not have a specified number of instances25 Composite Attribute 08. Uniquely Identifies entity instances20 Concatenated Key 09. Being able to reach the same point from a variety of directions04 Degree of Relationship 10. An association between entities21 Derived Attribute 11. Property of an entity31 Entity 12. A well-defined field02 Entity Type 13. Restrictions between how entities are related09 Equifinality 14. A relationship where one instance is related to only one other instance03 Foreign Key 15. A relationship where many instance is related to many other instances12 Identifier 16. A relationship which can contain n entities05 Interdependent Relationships 17. A relationship where one instance is related to only one other instance15 M:M Relationships 18. Association between entity types23 Mandatory Cardinality 19. Relationship of degree three06 Multivalued Attribute 20. Logically, putting together multiple keys as an identifier16 N-Ary Relationsihps 21. A field which is calculated07 Optional Cardinality 22. A relationship where 1 instance is related to many other instances08 Primary Key 23. A ‘must’ relationship18 Relationship 24 No. of participating entity types in a relationship10 Relationship Constraints 25. Can be broken into component parts12 Simple Attribute 26. Depends on the existence of another entity01 Strong Entity 27. A relationship where only 1 table is involved02 Table 28. A relationship of degree two27 Unary Relationship 29. Specifies Min.& Max. Number of instances26 Weak Entity 30. Relationship modeled as entity type19 Ternary Relationship 31. Person, Place, Object, Concept, Event
2. List three uses of an ERD 1. Data Modeling (the most common Data modeling tool)2. Organization Planning3. Shows the structure, requirements and constraints of the intended system, independent of software (DBMS), at
a higher level of abstraction4. Tool for communications between database designers and users
3. Draw each of the Basic ERD Symbols and explain What each one is.
Entity
Anything About which we wish to keep Information:
A Person A Place A Thing
A Concept An Object An Event
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 Description ExamplesStrong An entity which does not depend on
other entities for their existenceCustomersInventoryPhysician
Weak An entity which would not exist were it not for its relationship to another entity
OrdersInvoicesTransactions
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
4a. Explain what cardinality constraints are and how they impact on database design.
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
Description Example
Composite 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)
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
divisiond. 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__ This is a __ relationship. a. unary d. simpleb. binary e. complexc. ternary MC1b. _B__ This is a __ relationship. a. 1:1 d. 1:1:Mb. 1:M e. M:M:Mc. M:M MC1c. _A__ Which of the following is a primary key? a. employee_ID d. depart_idb. employee_name e. skillc. address MC1d. _D__ Which of the following is a foreign key? a. employee_ID d. depart_idb. employee_name e. skillc. address MC1e. _B__ Which of the following is a composite attribute? a. employee_ID d. yrs_employeedb. address e. skillc. depart_id MC1f. _E__ Which of the following is a multivalued attribute? a. employee_ID d. yrs_employeedb. address e. skillc. depart_id MC1g. _D__ Which of the following is a derived attribute? a. employee_ID d. yrs_employeedb. address e. skillc. depart_id
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 employee’s 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 TGIF’s, 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 TGIF’s 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 don’t 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).
answer6.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. A treatment can include multiple physicians
2. 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). Let’s 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 AnswerAd.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.
Recommended