Data Modeling and Database Design 2nd Edition Umanath
Full download at:
Solution Manual:
https://testbankpack.com/p/solution-manual-for-data-modeling-and-database-design-2nd-editionby-umanath-scamell-isbn-1285085256-9781285085258/
Chapter 6 – The Relational Data Model
Chapter 6 Objectives
After completing this chapter, the student will understand:
• The characteristics of a relation
• Data integrity constraints that pertain to the relational data model
• Some basic relational algebra operations
• The role of views and materialized views in the relational data model
• Problems caused by the lack of information preservation in data model mapping
• Two basic (popular) approaches to map ER and EER constructs to a logical schema
• An information-preserving grammar to map ER and EER constructs to a logical schema
• Mapping complex ER models to logical schema
Chapter 6 Overview
This chapter introduces the relational data model and the process of mapping a conceptual schema that is technology-independent to a logical schema (in this case, a relational data model) that provides the transition to a technology-dependent database design. The chapter begins with a discussion of the characteristics of a relation and the data integrity constraints that accompany the relational data model. This is followed by a brief introduction to relational algebra as a means to specifythe logic for data retrieval from a series of relations. The rest of the chapter discusses mapping a conceptual schema to its logical counterpart in the context of several examples that employ both an information-reducing mapping grammar and an information-preserving mapping grammar.
Relational algebra
Relational data model
Relation
Tuple
Chapter 6 Key Terms
A series of data manipulation operations performed on relations.
The representation of a database as a collection of relations.
A two-dimensional table of values presented as rows and columns.
A row in a relation that contains a set of related data values.
Attribute Formal name for a column in a relation.
Relation schema (also known as a schema, scheme, or intension)
Relational schema
Extension
Degree of a relation
Relation state
Cardinalityof a relation
Declarative (or schema-based) constraint
Application-based constraint
State constraint
Transition constraint
A tuple that contains the attribute names comprising a relation.
A set of relation schemas in a relational data model.
The body of a relation.
The number of attributes in a relation schema.
A specific occurrence of a relation (or should we say relation schema)
The number of tuples in a relation state.
A constraint directlyexpressed in the schema of the data model.
A constraint that must be enforced through application programming code.
A restriction that everyvalid state of the database must satisfy.
A constraint that defines the legal transitions of database states. For example, the only valid states of transition from “married” are “divorced,” “widowed,” or “deceased.”
Superkey A set of one or more attributes, which taken collectively, uniquely identifies a tuple of a relation.
Superset A set S1 is a superset of another set S2 if every element in S2 is in S1. S1 mayhave elements that are not in S2
Subset A set S2 is a subset of another set S1 if every element in S2 is in S1. S1 mayhave exactlythe same elements as S2 If S2 is a subset of S1, S1 is a superset of S2.
Proper subset
A set S2 is a proper subset of another set S1 if every element in S2 is in S1 and S1 has some elements which are not in S2
Candidate key
Uniqueness property
Irreducibility property
Primary key
Entityintegrity constraint
Referential integrity constraint
Foreign key constraint
A superkey with no proper subsets that are superkeys.
The prohibition of the presence of identical values for the collection of attribute(s) that constitute a unique identifier.
The requirement that no proper subset of a candidate keyhave the uniqueness property
Chosen from among the candidate keys to serve the role of uniquely identifying tuples of a relation schema.
A constraint that requires the primarykey of a relation schema to not contain a missing (i.e., null) value
The requirement that a relation r2, that refers to another relation r1, refers to a tuple that exists in r1.
A type of referential integrity constraint where it is necessary that every value of an attribute A2, atomic or composite, in relation r2 must either occur as the value of the candidate key A1 in some tuple of the relation r1 that r2 refers to or, if allowed, be null.
Inclusion dependency
A condition requiring that all values of attribute A2 in relation to r2 appear in the set of values A1 in relation r1. Note that if the participation of r2 in its relationship with r1 is partial, then A2 can have null values.
Selection operation
A relational algebra operation used to create a second relation by extracting a horizontal subset of tuples from a relation that match specified search criteria.
Projection operation
Union compatibility
A relational algebra operation used to create a second relation by extracting a vertical subset of columns from a relation.
A requirement when forming the union, intersection, or difference of two relations that each relation be of the same degree and that corresponding attributes in the two relations come from (or share) the same domain.
Union operation
Difference operation
A relational algebra operation that adds the tuples of two union compatible relations together to create a third relation that consists of tuples that are in either the first relation or the second relation.
A relational algebra operation that involves two union compatible relations where the tuples of one relation are subtracted from tuples of the second relation to produce a third relation that contains the tuples from the second relation that are not in the first relation.
Intersection operation
A relational algebra operation that involves two union compatible relations that involves the creation of a third relation containing tuples common to the two relations.
Join operation
Natural join operation
View
Materialized view
A relational algebra operation that combines two relations into a third relation by matching values for attributes in the two relations that come from the same domain.
A relational algebra join operation where the third relation does not redundantly carry the joining attributes.
A named “virtual” relation schema constructed from one or more relation schemas through the use of one or more relational algebra operations that serves as a logical window to view selected data (attributes and tuples) from one or a set of relations.
Also known as a snapshot, a materialized view, unlike a view, is stored in the database and refreshed when updates occur to the relation schemas from which the materialized view is generated.
Referencing relation schema
Referenced relation schema
Foreign key design
In logical modeling, a relation schema that contains a foreign key attribute
In logical modeling, the relation schema referenced by the foreign key contained in the referencing relation schema.
A logical data modeling approach requiring all non-null foreign key values match some value of the referenced candidate key
Cross-referencing design
Mutual-referencing design
A logical data modeling approach used to avoid creating a relation schema with null values for the foreign key.
A logical data modeling approach where the two relation schemas directly reference each other by placing foreign keys in both.
Chapter 6 Solutions
1. Define the terms, tuple, attribute, and relation.
Answer. In a relation, a tuple represents a set (i.e., a row) of related data values. A column of a relation is referred to as an attribute. A relation is a two-dimensional table of values presented as rows and columns. Another way to say this is that the set of all tuples in a table is called a relation.
2. What is a relation schema? What is the difference between a relation, a relation schema, and a relational schema?
Answer. A relation schema represents the basic structure of a relation. It consists of a name along with a set of related attributes. When sets of values are assigned to the attributes that make up a relation schema, a relation is created. In other words, a relation is a relation schema with data. The terms “ relation” and “relation schema” are typically used interchangeably. A relational schema is a set of relation schemas. A relational schema is another name for a relational data model (see footnote 1 at the bottom of page 245).
3. What is the difference between a derived attribute and a stored attribute in terms of their representation in a relation schema?
Answer. Only stored attributes are captured in a relation schema.
4. What is a null value? What gives rise to null values in a relation?
Answer. A null value is missing value. Sometimes a null value arises because it is simply unknown. For example, a person ’s salary would be a null value if we simply did not know his or her salary. On the other hand, a null value might be assigned to the commission attribute of an employee with the job of accountant since typically only salespersons qualify for a commission.
5. Distinguish between a subset and a proper subset?
Answer. Every element in a set of values is included in a subset. Consider the set of numbers {1, 2, 3}. The subsets of {1, 2, 3} would be {1, 2, 3}, {1, 2}, {1, 3}, {2, 3}, {1}, {2}, and {3}. On the other hand, the proper subsets of {1, 2, 3} would include all of the above with the exception of the set itself.
6. What is a candidate key? How does a candidate key differ from a superkey?
Answer. A candidate key is defined as a superkey with no proper subsets that are superkeys. A candidate key has two properties: the uniqueness property and the irreducibility property, whereas a superkey possesses only the uniqueness property.
7. What is a primarykey? How do the properties of a primary keydiffer from those of a candidate key?
Answer. A primary key is a candidate key that in addition to having the uniqueness and irreducibility properties also satisfies the entity integrity constraint (i.e., a primary key cannot have a missing value).
8. Identify the superkeys, candidate key(s), and the primary key for the following relation instance of the STU-CLASS relation schema.
9. Define the term referential integrity constraint. Why is referential integrity important? How is the term foreign key used in the context of referential integrity?
Answer. Informally, a referential integrity constraint implies that a tuple in a relation, r2, that refers to another relation, r1, refers to a tuple that exists in r1. In order to establish a referential integrity constraint between the two relation schemas, R1 and R2, it is necessary that every value of an attribute A2, atomic or molecular, in relation to r2 must either be null or occur as the value of a candidate key in some tuple of the relation r1 that r2 refers to. The attribute in R2 that meets this condition is called a foreign key of R2. R2 is called the referencing relation schema and R1 is known as the referenced relation schema.
10. This exercise refers to the relations R1 and R2 given below. Show the relations created as a result of the following relational algebra operations.
10a. The union of R1 and R2 Relation
10b The difference of R1 and R2 Relation R3
10c. The difference of R2 and R1
10d. The intersectionof R1 and R2
There are no common tuples in R1 and R2 and thus the intersection does not exist.
10e. The natural join of R1 and R2. Assume that R1.a and R2.x are the joining attributes. Relation R3 – Result
11. Exercise 11 refers to the DRIVER, TICKET_TYPE, and TICKET relations given below.
DRIVER (Dr_license_no, Dr_name, Dr city, Dr state)
TICKET_TYPE (Ttp_offense, Ttp_fine)
TICKET (Tic_ticket_no, Tic_ticket_date, Tic dr_license, Tic_ttp_offense)
An instance of each of these relations follows. Use the data shown below to (a) write the answer to each question and (b) list the relational algebra operation(s) required to obtain the answer.
Answer.
11a. What are the names of all drivers?
Mills, R Brooks, L. Silva, R Lence, E Blair, H. Newman Requires a projection operation over the DRIVER relation on the Dr_name attribute.
DRIVER OVER DRIVER.Dr_name GIVING ANSWER
11b. What are the license numbers of all drivers who have been issued a ticket?
322, RVX 287, TGY 832, KEC 654
Requires a projection operation over the TICKET relation on the Tic dr license attribute. PROJECT TICKET OVER TICKET Tic_dr license_no GIVING ANSWER
11c. What are the license numbers of those drivers who have never been issued a ticket?
MQA 823, GRE 720
Requires taking the difference of projections the driver license number attribute in the DRIVER and TICKET relations
PROJECT DRIVER OVER DRIVER.Dr license_no MINUS
PROJECT TICKET OVER TICKET.Tic_dr license_no GIVING ANSWER
11d. What are the names of all drivers who have been issued a ticket?
E Mills, R Brooks, L. Silva, R Lence
Requires joining the DRIVER and TICKET relations over their common attribute driver license number and then following this with a projection operation that projects out the name of driver.
JOIN DRIVER AND TICKET OVER DRIVER.Dr license_no, TICKET Tic_dr license_no
GIVING ANSWER
PROJECT ANSWER OVER ANSWER.Dr_name GIVING FINAL_ANSWER
12. What would cause a relational schema for a database to contain more relation schemas than there are entity types?
Answer. This is somewhat of a trick question. A relational schema has the same number of relation schemas as there are entity types as long as the Fine-granular Design-Specific ER diagram serves as input.
13. Discuss the concept of information preservation in data model mapping
Answer. The fundamental issue is that the process of transforming a conceptual model (in our case a Fine-granular Design-Specific ER diagram supplemented by various semantic integrity constraints) into a logical model that is based on the relational data model is preserved in the information content of the business rules incorporated in the conceptual model.
14. What is required to map a base entitytype to a relation schema? Describe how this approach differs for a weak entity type.
Answer. Four activities are required: (1) create a relation schema for each base entity type in the Fine-granular Design-Specific ER diagram, (2) include the stored attributes associated with the entity type in the relation schema, (3) in the case of composite attributes record only the atomic components, and (4) underline the atomic attribute(s) that make up the primary key. A weak entity type is mapped in a like manner except that the primary key of the identifying parent of the weak entity type is added to the relation schema.
15. What is required to map a relationship type that exhibits a 1:n cardinality ratio?
Answer. Using the foreign key design, place the key (either the primary key or a candidate key) of the parent as a foreign key attribute of the child.
16. What is the difference between the referencing relation schema and the referenced relation schema? How are these terms incorporated into the foreign key design?
Answer. The parent is the referenced relation schema and the child is the referencing relation schema (i.e., it references the relation schema that contains the primary key)
17. What is the purpose of the cross-referencing design?
Answer. The cross-referencing design is an alternative modeling approach that guarantees the absence of null values in the foreign key It entails the creation of a relation schema to represent the relationship type.
18. What complicates the mapping of 1:1 cardinality ratios?
Answer. The fact that either one of the entity types engaged in the 1:1 relationship type can be the parent or the child is what complicates the mapping of the 1:1 relationship type
Three cases exist: (1) the participation constraint of one of the entity types participating in the relationship type is total, and the other is partial, (2) the participation constraints of both entity types in the relationship type are partial, or (3) the participation constraints of both entity types in the relationship type are total
19. Describe mutual referencing and the complexities that it introduces.
Answer. Mutual referencing (i.e., where a foreign key is added in both relation schemas engaged in the relationship) between two relation schemas entails the specification of additional constraints to ensure consistency maintenance. Such constraints can only be implemented procedurally. One required constraint is that both foreign keys be unique in order to maintain the cardinality ratio of 1:1. Total participation of both entity types in the relationship type is incorporated in the design by not allowing null values for the foreign keys. Two other complexities accompany the presence of foreign keys in both relation schemas. First, procedural intervention is necessary to make sure that the [primary/candidate key, foreign key] pairs in the two relations match. Second, the two relation schemas referencing each other create a cycle necessitating that enforcement of at least one of the referential integrity constraints be deferred to run time.
20. What information is lost by the use of the information-reducing grammar?
Answer. Use of the information-reducing grammar to transform a conceptual model to a logical model results in loss of the following information:
a. Failure to distinguish between 1:1 and 1:n cardinality ratios
b. Failure to map the participation constraints of a relationship type
c. Failure to retain the optional/mandatory property of an attribute
d. Failure to identify alternate keys
e Failure to recognize the composite nature of some collection of atomic attributes
f. Failure to carry forward derived attributes specified in the ER diagram
g. Failure to map deletion rules to the logical schema
h. Failure to carry forward the attribute type and size specified in the ER diagram
21. Describe how to map a specialization hierarchy, a specialization lattice, and a categorization.
Answer. Three different logical schema solutions are possible for mapping a specialization. The first solution is to create one logical scheme for each of the subclasses and superclass in the specialization. The second solution is the opposite of the first in that one logical scheme is used to represent the entire specialization. The third solution involves incorporating the attributes of the superclass in each of the individual logical schemes for the subclasses. It should be noted that this approach cannot be used if the completeness constraint is partial.
a. Specialization hierarchy. Add the primary key of the superclass entity type as a foreign key of the subclass entity type when mapping.
b. Specialization lattice. Add the primary key of each superclass entity type as a foreign key of the subclass entity type.
c Categorization. Add the primary key of the subclass entity type to each superclass entity type.
22. What do you think are the ultimate consequences of failure to “preserve information” in the data model mapping process?
Answer. Unless a complete mapping of all modeling constructs and constraints that are inherent, implicit, or explicit in the source (i.e., conceptual) data model occurs in the target (i.e., logical) data model, they will have to be handled in the logical design activity through application programs, or the ultimate consequences will be acceptance of an informationreducing transformation.
23. For the following excerpt from an ERD, specify the logical (relational) schema as per the foreign key design in the following ways:
a. using directed arcs
b. in terms of inclusion dependencies
Answer
a. Directed arc method:
From the answer to (b) given below, it is easy to draw the single directed arc
b. inclusion dependencies technique:
SALESPERSON (Sls empno, Sls fname, Sls minit, Sls lname, Sls pctcommission, Sls-basesalary, Sls gender, Sls datehired)
VEHICLE (Veh_vinnum, Veh_licplate#, Veh_msrp, Veh_model yr, Veh_sls fname, Veh sls minit, Veh_sls lname)
# VEHICLE [Veh_sls fname, Veh_sls minit, Veh sls_lname] ⊆ SALESPERSON [Sls fname, Sls minit, Sls_lname] or Ø
24. List (tabulate) the metadata available in the ER diagram in Exercise 23 on the next page (see page 301) and indicate the ones captured in the logical (relational) schema of design 23(a) and design 23(b)
Answer. The metadata available in the ER diagram in Exercise 23 includes the type and size of each attribute, whether the attribute is mandatory or optional, and whether the attribute is a simple or composite specification of all uniqueness constraints, participation constraints, and cardinality ratio constraints. On the other hand, considerable metadata is lost when mapping the ER diagram to either of the logical schemas. Metadata lost includes the type and size of each attribute, whether the attribute is mandatory or optional, all composite attributes, all alternate keys (e.g., Lic_plate#), the nature of the cardinality ratio, and in the case of the foreign key design using directed arcs, the nature of the participation constraints. In the case of the foreign key design using inclusion dependencies, the optional or total participation of the child is shown.
25. For the ER diagram in Exercise 23, specifythe logical (relational) schema as per the cross referencing design:
a. using directed arcs
b. in terms of inclusion dependencies
a. Directed arc method:
From the answer to (b) given below, it is easy to draw the two directed arcs.
b. inclusion dependencies technique:
SALESPERSON (Sls empno, Sls fname, Sls minit, Sls lname, Sls pctcommission, Sls-basesalary, Sls gender, Sls datehired)
VEHICLE (Veh_vinnum, Veh_licplate#, Veh_msrp, Veh_model yr)
SELLS (Sel_sls fname, Sel_sls minit, Sel sls lname, Sel veh vinnum)
# SELLS [Sel sls fname, Sel sls minit, Sel_sls_lname] ⊆ SALESPERSON [Sls fname, Sls minit, Sls lname]
# SELLS [Sel veh vinnum] ⊆ VEHICLE [Veh vinnum]
Also, explain the merits and demerits of this cross-referencing design over the foreign key design solution.
Answer. The cross-referencing design guarantees absence of null values that would otherwise appear in the VEHICLE relation had the foreign key design been used and vehicles not sold by a salesperson existed. Strict use of the cross-referencing design necessitates the creation of a separate relation in situations where partial participation exists, thus increasing the number of relations in the database
26. Consider the following excerpt from an ERD:
For the following three cases, specifythe logical (relational) schema using either directed arcs or in terms of inclusion dependencies according to the foreign key design, crossreferencing design and mutual-referencing design:
a. when x = 0 and y = 1
b. when x = 0 and y = 0
c when x = 1 and y = 1
In each case, offer a comparative discussion of the merits and demerits of the three design options.
Answer.
Exercise 26 - Part a.
Foreign Key Design
PROGRAMMER (Pr empno, Pr name, Pr gender, Pr_date hired, Pr_qualification, Pr salary)
SYSTEM (Sys sys_id, Sys sys_name, Sys size, Sys pr name)
# SYSTEM [Sys pr_name] ⊆ PROGRAMMER [Pr name]
Cross-referencingDesign
PROGRAMMER (Pr empno, Pr name, Pr gender, Pr_date hired, Pr_qualification, Pr salary)
RESIDENT EXPERT (Rex pr name, Rex_sys sys id) {Note primary key of RESIDENT EXPERT}
SYSTEM (Sys sys_id, Sys sys_name, Sys size)
# RESIDENT_EXPERT [Rex pr name] ⊆ PROGRAMMER [Pr_name]
# RESIDENT_EXPERT [Rex sys sys_id] ⊆ SYSTEM [Sys sys id]
Mutual-referencingDesign
PROGRAMMER (Pr empno, Pr name, Pr gender, Pr_date hired, Pr_qualification, Pr salary, Pr sys sys id)
SYSTEM (Sys sys_id, Sys sys_name, Sys size, Sys pr name)
# SYSTEM [Sys pr_name] ⊆ PROGRAMMER [Pr name]
# PROGRAMMER [Pr sys sys_id] ⊆ SYSTEM [Sys sys_id]
Exercise 26 - Part b
Foreign Key Design
PROGRAMMER (Pr empno, Pr name, Pr gender, Pr_date hired, Pr_qualification, Pr salary)
SYSTEM (Sys sys_id, Sys sys_name, Sys size, Sys pr name)
# SYSTEM [Sys pr_name] ⊆ PROGRAMMER [Pr name] or ∅
Cross-referencingDesign
PROGRAMMER (Pr empno, Pr name, Pr gender, Pr_date hired, Pr_qualification, Pr salary)
RESIDENT EXPERT (Rex pr name, Rex_sys sys id)
SYSTEM (Sys sys_id, Sys sys_name, Sys size)
# RESIDENT_EXPERT [Rex pr name] ⊆ PROGRAMMER [Pr_name]
# RESIDENT_EXPERT [Rex sys sys_id] ⊆ SYSTEM [Sys sys id]
Mutual-referencingDesign
PROGRAMMER (Pr empno, Pr name, Pr gender, Pr_date hired, Pr_qualification, Pr salary, Pr sys sys id)
SYSTEM (Sys sys_id, Sys sys_name, Sys size, Sys pr name)
# SYSTEM [Sys pr_name] ⊆ PROGRAMMER [Pr name]
# PROGRAMMER [Pr sys sys_id] ⊆ SYSTEM [Sys sys_id]
Exercise 26 - Part c
Mutual-referencingDesign
PROGRAMMER (Pr empno, Pr name, Pr gender, Pr_date hired, Pr_qualification, Pr salary, Pr sys sys id)
SYSTEM (Sys sys_id, Sys sys_name, Sys size, Sys pr name)
# SYSTEM [Sys pr_name] ⊆ PROGRAMMER [Pr name]
# PROGRAMMER [Pr sys sys_id] ⊆ SYSTEM [Sys sys_id]
27. Consider the following excerpt from an ERD:
Specify the logical (relational) schema (choosing a design without a need to use null values to indicate partial participation) in the following ways:
a. using directed arcs
b. in terms of inclusion dependencies
a. Directed arc method: From the answer to (b) given below, it is easy to draw the single directed arc
b. inclusion dependencies technique:
28. How can the design requirement in Exercise 27 above be satisfied if the “Supervisee” part of the relationship has the structural constraints (0, 1)? Again, show a design using both directed arcs and in terms of inclusion dependencies.
a. Directed arc method:
From the answer to (b) given below, it is easy to draw the two directed arcs.
b. inclusion dependencies technique:
NURSE (Nur empno, Nur name, Nur qualification, Nur salary, Nur gender, Nur_date_hired)
SUPERVISOR (Sup_Nur empno, Sup_nur_nur empno)
# SUPERVISOR [Sup nur_empno] ⊆ NURSE [Nur_empno]
# SUPERVISOR [Sup nur nur_empno] ⊆ NURSE [Nur_empno]
29. Specify the logical schema for the ER diagram shown in Exercise 23 using the informationpreserving grammar, and indicate the metadata present in the ER diagram (Exercise 24) captured by this logical schema. Answer.
L1: SALESPERSON (Sls empno , [Sls fname, Sls minit, Sls lname], Sls pctcommission, Sls-basesalary , Sls gender , Sls datehired )
L2: VEHICLE (Veh_vinnum, Q[Veh licplate# ], Veh msrp , Veh model_yr , Veh_make , [Veh sls fname, Veh sls minit, Veh sls lname])
30. Specify the logical schema for the ER diagram shown in Exercise 27 using the informationpreserving grammar Answer.
L1: NURSE (Nur empno, Nur name , Nur_qualification, Nur salary , Nur gender , Nur_date hired , Nur nur empno)
Since attribute type and size are not provided in the ER diagram, those given are assumed values. Likewise, since every nurse must have a supervisor, the Set Default deletion rule was assumed to apply should the supervisor of a nurse be deleted
31. Consider the following ERD:
e
Using the foreign key design, specify the logical schema for this diagram in the following ways:
a. with a directed arc
b. in terms of an inclusion dependency
c. using the information-preserving grammar.
a. Directed arc method:
From the answer to (b) given below, it is easy to draw the single directed arc
b. inclusion dependencies technique:
MEDICATION (Med_med code, Med_med name, Med list_price)
PRESCRIPTION ORDER (Pod med med_code, Pod prescription#, Pod date)
# PRESCRIPTION ORDER [Pod med med code] ⊆ MEDICATION [Med med_code]
c using the information-preserving grammar:
32. Consider the following Presentation-Layer ERD:
Using the foreign key design, specify the logical schema in the following ways:
a) with directed arcs
b) in terms of inclusion dependencies
c) using the information-preserving grammar.
Also, list the metadata present in the ER diagram and indicate the ones captured by each of the three designs of the logical schema.
a. Directed arc method:
From the answer to (b) given below, it is easy to draw the two directed arcs.
b. inclusion dependencies technique:
COMPANY (Cmp name, Cmp size, Cmp_headquarters)
STUDENT (Stu name, Stu major, Stu_status)
INTERNSHIP (Int_cmp_name, Int_stu_name, Int_location, Int_stipend, Int_year, Int_quarter)
# INTERNSHIP [Int_cmp name] ⊆ COMPANY [Cmp name]
# INTERNSHIP [Int stu name] ⊆ STUDENT [Stu name]
c. using the information-preserving grammar:
L1: COMPANY (Cmp name, Cmp_size, Cmp_headquarters)
(A,30) (N,6) (A,30)
L2: STUDENT (Stu name, Stu_major, Stu status)
(A,30) (A,20) (A,10)
1< L1 m> 0 -L2 n>
L3: INTERNSHIP (Int_cmp_name, Int stu name, Int_location, Int_stipend, [Int_year, Int_quarter]) (A,30) (A,30) (A,20) (N,5) (N,4) (A,2)
1< C -1> 0 C 1>
33. Specify the logical (relational) schema for the ER diagram shown in Figure 5-61 in Chapter 5 for the Cougar Medical Associates as per the foreign key design:
a using directed arcs
b. in terms of inclusion dependencies
Answer.
a. Directed arc method:
The very purpose this question is to demonstrate how impractical it is to use the directed arc technique for specifying the logical schema for a real-world type of a large ER model.
b. inclusion dependencies technique:
PERSON (Per_ssno, Per_name, Per gender, Per_address, Per_phone)
CLINIC PERSONNEL (Clp per ssno,Clp_emp#)
CLINIC PERSONNEL {Clp_per_ssno} ⊆ PERSON {Per ssno}
NURSE (Nur clp_emp#,Nur salary, Nur_grade, Nur yrs experience)
NURSE {Nur.clp_emp#} ⊆ CLINIC PERSONNEL {Clp_emp#}
SURGEON (Sur clp_emp#,Sur_speciality,Sur_con type, Sur_con years)
SURGEON {Sur_clp_emp#} ⊆ CLINIC PERSONNEL {Clp_emp#}
PHYSICIAN (Phy clp_emp#,Phy speciality,Phy salary)
PHYSICIAN {Phy clp_emp#} ⊆ CLINIC PERSONNEL{Clp_emp#}
MEDICAL CORPORATION (Mco_corp_name,Mco_headquarters)
CLINIC OWNER(Clo_owner#, Clo_phy clp_emp#,Clo_percent own, Clo_mco_corp_name)
SUPPORT STAFF(Sst clp_per ssno,Sst salary)
SUPPORT STAFF{Sst clp per_ssno} ⊆ CLINIC PERSONNEL {Clp_emp#}
SURGERY SKILL(Ssk skill code,Ssk_description)
NURSE_SKILL(Nsk_nur clp_emp#, Nsk ssk skill code)
NURSE_SKILL{Nsk_nur_clp_emp#} ⊆ NURSE {Nur_clp_emp#}
NURSE_SKILL{Nsk ssk skill code} ⊆ SURGERY SKILL{Ssk skill code}
SURGERY TYPE(Stp s code, Stp_name, Stp_special needs,Stp_category, Stp_anat location)
ASSIGNMENT (Asg_nur clp emp#, Asg_stp s code, Asg nsk_nur clp_emp#, Asg nsk_ssk skill code, Asg_req_stp_s code, Asg_req ssk skill code)
ASSIGNMENT {Asg nur_clp_emp#} ⊆ NURSE {Nur_clp_emp#}
ASSIGNMENT {Asg stp_s code} ⊆ SURGERY TYPE{Stp_s code}
ASSIGNMENT {Asg nsk_nur_clp_emp#,Asg_nsk ssk skill code} ⊆ NURSE_SKILL {Nsk nur_clp_emp#,Nsk ssk_skill code}
ASSIGNMENT {Asg_req_stp_s code,Asg_req_ssk skill code} ⊆ REQ SKILL{Req_stp_s code, Req_ssk skill code}
PATIENT (Pat_per_ssno)
IN PATIENT (Inp_pat_per ssno,Inp_admit_date,Inp_nursing unit,Inp_bed#, Inp room#, Inp_wing, Inp nur clp_emp#)
IN PATIENT {Inp_pat_per_ssno} ⊆ PATIENT {Pat per_ssno}
IN PATIENT {Inp_nur_clp_emp#} ⊆ NURSE {Nur_clp_emp#}
PERSONAL_INFO(Pif_pat per ssno,Pif Patient#, Pif_birthdate)
PERSONAL_INFO{Pif_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
MEDICAL_INFO(Mif_pat_per ssno,Mif_blood_sugar,Mif_blood_type,Mif heart_risk, Mif hdl, Mif ldl, Mif triglyceride)
MEDICAL_INFO{Mif_pat_per_ssno} ⊆ PATIENT {Pat_per_ssno}
ALLERGY (All mif_pat_per ssno,All code, All_description)
ALLERGY {All mif_pat_per ssno} ⊆ MEDICAL_INFO {Mif_pat_per_ssno}
ILLNESS (Ill code, Ill_description)
SUFFERING (Suf_pat per ssno, Suf ill code)
SUFFERING {Suf_pat_per_ssno} ⊆ PATIENT {Pat per_ssno}
SUFFERING {Suf ill code} ⊆ ILLNESS {Ill code}
MEDICATION(Med_Med code,Med name, Med ytd_usage,Med_q_on_order,Med_q_on hand, Med_unit cost)
INTERACTION(Int med med_code sourceof, Int med_med_code subjectto)
INTERACTION{Int med med_code sourceof} ⊆ MEDICATION{Med_med_code}
INTERACTION{Int med med_code subjectto} ⊆ MEDICATION{Med_med_code}
PRESCRIPTION(Pre phy clp_emp#, Pre_pat per ssno, Pre med_med_code, Pre frequency, Pre_dosage)
PRESCRIPTION{Pre_phy clp_emp#} ⊆ PHYSICIAN {Phy clp_emp#}
PRESCRIPTION{Pre_pat per_ssno} ⊆ PATIENT {Pat_per_ssno}
PRESCRIPTION{Pre med_med_code} ⊆ MEDICATION{Med_med_code}
MED TAKEN (Met_pat_per ssno, Med_pre phy clp_emp#, Med_pre pat_per ssno, Med_pre med_med_code, Met med_med_code)
MED TAKEN {Met_pat_per ssno} ⊆ PATIENT {Pat per_ssno}
MED TAKEN (Met med med_code} ⊆ MEDICATION{Med_med_code}
MED TAKEN {Med_pre phy clp_emp#, Med pre_pat_per ssno, Med pre med_med_code} ⊆ PRESCRIPTION {Pre phy clp_emp#, Pre_pat_per ssno, Pre med_med_code}
SURG SCH (Sch_pat_per ssno, Sch_stp_s code, Sch_sur_clp_emp#, Sch surg_date,Sur theatres)
SURG SCH {Sch_pat_per_ssno} ⊆ PATIENT {Pat_per ssno}
SURG SCH {Sch stp_s code} ⊆ SURGERY TYPE{Stp_s code}
SURG SCH {Sch sur_clp_emp#} ⊆ SURGEON {Sur_clp_emp#}
REQ SKILL(Req_stp_s code, Req_ssk skill code)
REQ SKILL{Req_stp_s code} ⊆ SURGERY TYPE{Stp_s code}
REQ SKILL{Req_ssk skill code} ⊆ SURGERY SKILL{Ssk skill code}
The miscellaneousbusiness rule:
• a surgery type must have at least two nurses assigned to it must be carried forward as a semantic integrityconstraint to physical database design