大数据库系统基础教程(第二版)课后习题问题详解

Database Systems: The Complete
Book
Solutions for Chapter 2
Solutions for Section 2.1
Exercise 2.1.1
The E/R Diagram.
Exercise 2.1.8(a)
The E/R Diagram
Kobvxybz
Solutions for Section 2.2
Exercise 2.2.1
The Addresses entity set is nothing but a single address, so we would prefer to make address an attribute of Customers. Were the bank to record several addresses for a customer, then it might make sense to have an Addresses entity set and make Lives-at a many-many relationship.
The Acct-Sets entity set is useless. Each customer has a unique account set containing his or her accounts. However, relating customers directly to their accounts in a many-many relationship conveys the same information and eliminates the account-set concept altogether.
Solutions for Section 2.3
Exercise 2.3.1(a)
Keys ssNo and number are appropriate for Customers and Accounts, respectively.
Also,
we think it does not make sense for an account to be related to zero customers, so we should round the edge connecting Owns to Customers. It does not seem inappropriate to have a customer with 0 accounts; they might be a borrower, for example, so we put no constraint on the connection from Owns to Accounts. Here is the The E/R Diagram，
showing underlined keys and the numerocity constraint.
Exercise 2.3.2(b)
If R is many-one from E1 to E2, then two tuples (e1,e2) and (f1,f2) of the relationship set for R must be the same if they agree on the key attributes for E1. To see why, surely e1 and f1 are the same. Because R is many-one from E1 to E2, e2 and f2 must also be the same. Thus, the pairs are the same.
Solutions for Section 2.4
Exercise 2.4.1
Here is the The E/R Diagram.
We have omitted attributes other than our choice for the key attributes of Students and Courses. Also omitted are names for the relationships. Attribute grade is not part of the key for Enrollments. The key for Enrollements is studID from Students and dept and number from Courses.
Exercise 2.4.4b
Here is the The E/R Diagram Again, we have omitted relationship names and attributes other than our choice for the key attributes. The key for Leagues is its own name; this entity set is not weak. The key for Teams is its own name plus the name of the
league of which the team is a part, e.g., (Rangers, MLB) or (Rangers, NHL). The key for Players consists of the player's number and the key for the team on which he or she plays. Since the latter key is itself a pair consisting of team and league names, the key for players is the triple (number, teamName, leagueName). e.g., Jeff Garcia is (5, 49ers, NFL).
Database Systems: The Complete
Book
Solutions for Chapter 3
Solutions for Section 3.1
Exercise 3.1.2(a)
We can order the three tuples in any of 3! = 6 ways. Also, the columns can be ordered in any of 3! = 6 ways. Thus, the number of presentations is 6*6 = 36.
Solutions for Section 3.2
Exercise 3.2.1
Customers(ssNo, name, address, phone)
Flights(number, day, aircraft)
Bookings(ssNo, number, day, row, seat)
Being a weak entity set, Bookings' relation has the keys for Customers and Flights and Bookings' own attributes.
Notice that the relations obtained from the toCust and toFlt relationships are unnecessary. They are:
toCust(ssNo, ssNo1, number, day)
toFlt(ssNo, number, day, number1, day1)
That is, for toCust, the key of Customers is paired with the key for Bookings. Since both include ssNo, this attribute is repeated with two different names, ssNo and ssNo1. A similar situation exists for toFlt.
Exercise 3.2.3
Ships(name, yearLaunched)
SisterOf(name, sisterName)
Solutions for Section 3.3
Exercise 3.3.1
Since Courses is weak, its key is number and the name of its department. We do not have a relation for GivenBy. In part (a), there is a relation for Courses and a relation for LabCourses that has only the key and the computer-allocation attribute. It looks like:
Depts(name, chair)
Courses(number, deptName, room)
LabCourses(number, deptName, allocation)
For part (b), LabCourses gets all the attributes of Courses, as:
Depts(name, chair)
Courses(number, deptName, room)
LabCourses(number, deptName, room, allocation)
And for (c), Courses and LabCourses are combined, as:
Depts(name, chair)
Courses(number, deptName, room, allocation)
Exercise 3.3.4(a)
There is one relation for each entity set, so the number of relations is e. The relation for the root entity set has a attributes, while the other relations, which must include the key attributes, have a+k attributes.
Solutions for Section 3.4
Exercise 3.4.2
Surely ID is a key by itself. However, we think that the attributes x, y, and z together form another key. The reason is that at no time can two molecules occupy the same point.
Exercise 3.4.4
The key attributes are indicated by capitalization in the schema below:
Customers(SSNO, name, address, phone)
Flights(NUMBER, DAY, aircraft)
Bookings(SSNO, NUMBER, DAY, row, seat)
Exercise 3.4.6(a)
The superkeys are any subset that contains A1. Thus, there are 2^{n-1} such subsets, since each of the n-1 attributes A2 through An may independently be chosen in or out.
Solutions for Section 3.5
Exercise 3.5.1(a)
We could try inference rules to deduce new dependencies until we are satisfied we have them all. A more systematic way is to consider the closures of all 15 nonempty sets of attributes.
For the single attributes we have A+ = A, B+ = B, C+ = ACD, and D+ = AD. Thus, the only new dependency we get with a single attribute on the left is C->A.
Now consider pairs of attributes:
AB+ = ABCD, so we get new dependency AB->D. AC+ = ACD, and AC->D is nontrivial. AD+ = AD, so nothing new. BC+ = ABCD, so we get BC->A, and BC->D. BD+ = ABCD, giving us BD->A and BD->C. CD+ = ACD, giving CD->A.
For the triples of attributes, ACD+ = ACD, but the closures of the other sets are each ABCD. Thus, we get new dependencies ABC->D, ABD->C, and BCD->A.
Since ABCD+ = ABCD, we get no new dependencies.
The collection of 11 new dependencies mentioned above is: C->A, AB->D, AC->D, BC->A, BC->D, BD->A, BD->C, CD->A, ABC->D, ABD->C, and BCD->A.
Exercise 3.5.1(b)
From the analysis of closures above, we find that AB, BC, and BD are keys. All other sets either do not have ABCD as the closure or contain one of these three sets.
Exercise 3.5.1(c)
The superkeys are all those that contain one of those three keys. That is, a superkey that is not a key must contain B and more than one of A, C, and D. Thus, the (proper) superkeys are ABC, ABD, BCD, and ABCD.
Exercise 3.5.3(a)
We must compute the closure of A1A2...AnC. Since A1A2...An->B is a dependency, surely B is in this set, proving A1A2...AnC->B.
Exercise 3.5.4(a)
Consider the relation
This relation satisfies A->B but does not satisfy B->A.
Exercise 3.5.8(a)
If all sets of attributes are closed, then there cannot be any nontrivial functional dependencies. For suppose A1A2...An->B is a nontrivial dependency. Then A1A2...An+ contains B and thus A1A2...An is not closed.
Exercise 3.5.10(a)
We need to compute the closures of all subsets of {ABC}, although there is no need to think about the empty set or the set of all three attributes. Here are the calculations for the remaining six sets:
A+ = A
B+ = B
C+ = ACE
AB+ = ABCDE
AC+ = ACE
BC+ = ABCDE
We ignore D and E, so a basis for the resulting functional dependencies for ABC are: C->A and AB->C. Note that BC->A is true, but follows logically from C->A, and therefore may be omitted from our list.
Solutions for Section 3.6
Exercise 3.6.1(a)
In the solution to Exercise 3.5.1 we found that there are 14 nontrivial dependencies, including the three given ones and 11 derived dependencies. These are: C->A, C->D, D->A, AB->D, AB-> C, AC->D, BC->A, BC->D, BD->A, BD->C, CD->A, ABC->D, ABD->C, and BCD->A.
We also learned that the three keys were AB, BC, and BD. Thus, any dependency above that does not have one of these pairs on the left is a BCNF violation. These are: C->A, C->D, D->A, AC->D, and CD->A.
One choice is to decompose using C->D. That gives us ABC and CD as decomposed relations. CD is surely in BCNF, since any two-attribute relation is. ABC is not in BCNF, since AB and BC are its only keys, but C->A is a dependency that holds in ABCD and therefore holds in ABC. We must further decompose ABC into AC and BC. Thus, the three relations of the decomposition are AC, BC, and CD.
Since all attributes are in at least one key of ABCD, that relation is already in 3NF, and no decomposition is necessary.
Exercise 3.6.1(b)
(Revised 1/19/02) The only key is AB. Thus, B->C and B->D are both BCNF violations. The derived FD's BD->C and BC->D are also BCNF violations. However, any other nontrivial, derived FD will have A and B on the left, and therefore will contain a key.
One possible BCNF decomposition is AB and BCD. It is obtained starting with any of the four violations mentioned above. AB is the only key for AB, and B is the only key for BCD.
Since there is only one key for ABCD, the 3NF violations are the same, and so is the decomposition.
Solutions for Section 3.7
Exercise 3.7.1
Since A->->B, and all the tuples have the same value for attribute A, we can pair the B-value from any tuple with the value of the remaining attribute C from any other
tuple. Thus, we know that R must have at least the nine tuples of the form (a,b,c), where b is any of b1, b2, or b3, and c is any of c1, c2, or c3. That is, we can derive, using the definition of a multivalued dependency, that each of the tuples (a,b1,c2), (a,b1,c3), (a,b2,c1), (a,b2,c3), (a,b3,c1), and (a,b3,c2) are also in R.
Exercise 3.7.2(a)
First, people have unique Social Security numbers and unique birthdates. Thus, we expect the functional dependencies ssNo->name and ssNo->birthdate hold. The same applies to children, so we expect childSSNo->childname and childSSNo->childBirthdate. Finally, an automobile has a unique brand, so we expect autoSerialNo->autoMake.
There are two multivalued dependencies that do not follow from these functional dependencies. First, the information about one child of a person is independent of other information about that person. That is, if a person with social security number s has a tuple with cn,cs,cb, then if there is any other tuple t for the same person, there will also be another tuple that agrees with t except that it has cn,cs,cb in its components for the child name, Social Security number, and birthdate. That is the multivalued dependency
ssNo->->childSSNo childName childBirthdate
Similarly, an automobile serial number and make are independent of any of the other attributes, so we expect the multivalued dependency
ssNo->->autoSerialNo autoMake
The dependencies are summarized below:
ssNo -> name birthdate
childSSNo -> childName childBirthdate
autoSerialNo -> autoMake
ssNo ->-> childSSNo childName childBirthdate
ssNo ->-> autoSerialNo autoMake
Exercise 3.7.2(b)
We suggest the relation schemas
{ssNo, name, birthdate}
{ssNo, childSSNo}
{childSSNo, childName childBirthdate}
{ssNo, autoSerialNo}
{autoSerialNo, autoMake}
An initial decomposition based on the two multivalued dependencies would give us {ssNo, name, birthDate}
{ssNo, childSSNo, childName, childBirthdate}
{ssNo, autoSerialNo, autoMake}
Functional dependencies force us to decompose the second and third of these.
Exercise 3.7.3(a)
Since there are no functional dependencies, the only key is all four attributes,
ABCD. Thus, each of the nontrvial multivalued dependencies A->->B and A->->C violate 4NF. We must separate out the attributes of these dependencies, first decomposing into AB and ACD, and then decomposing the latter into AC and AD because A->->C is still a 4NF violation for ACD. The final set of relations are AB, AC, and AD.
Exercise 3.7.7(a)
Let W be the set of attributes not in X, Y, or Z. Consider two tuples xyzw and xy'z'w' in the relation R in question. Because X ->-> Y, we can swap the y's, so xy'zw and xyz'w' are in R. Because X ->-> Z, we can take the pair of tuples xyzw and xyz'w' and swap Z's to get xyz'w and xyzw'. Similarly, we can take the pair xy'z'w' and xy'zw and swap Z's to get xy'zw' and xy'z'w.
In conclusion, we started with tuples xyzw and xy'z'w' and showed that xyzw' and xy'z'w must also be in the relation. That is exactly the statement of the MVD X ->-> Y-union-Z. Note that the above statements all make sense even if there are attributes in common among X, Y, and Z.
Exercise 3.7.8(a)
Consider a relation R with schema ABCD and the instance with four tuples abcd, abcd', ab'c'd, and ab'c'd'. This instance satisfies the MVD A ->-> BC. However, it does not satisfy A ->-> B. For example, if it did satisfy A ->-> B, then because the instance contains the tuples abcd and ab'c'd, we would expect it to contain abc'd and ab'cd, neither of which is in the instance.
Database Systems: The Complete Array Book
Solutions for Chapter 4
Solutions for Section 4.2
Exercise 4.2.1
class Customer {
attribute string name;
attribute string addr;
attribute string phone;
attribute integer ssNo;
relationship Set<Account> ownsAccts
inverse Account::ownedBy;
}
class Account {
attribute integer number;
attribute string type;
attribute real balance;
relationship Set<Customer> ownedBy
inverse Customer::ownsAccts
}
Exercise 4.2.4
class Person {
attribute string name;
relationship Person motherOf
inverse Person::childrenOfFemale
relationship Person fatherOf
inverse Person::childrenOfMale
relationship Set<Person> children
inverse Person::parentsOf
relationship Set<Person> childrenOfFemale
inverse Person::motherOf
relationship Set<Person> childrenOfMale
inverse Person::fatherOf
relationship Set<Person> parentsOf
inverse Person::children
}
Notice that there are six different relationships here. For example, the inverse of the relationship that connects a person to their (unique) mother is a relationship that connects a mother (i.e., a female person) to the set of her children. That relationship, which we call childrenOfFemale, is different from the children relationship, which connects anyone -- male or female -- to their children.
Exercise 4.2.7
A relationship R is its own inverse if and only if for every pair (a,b) in R, the pair (b,a) is also in R. In the terminology of set theory, the relation R is ``symmetric.''
Solutions for Section 4.3
Exercise 4.3.1
We think that Social Security number should me the key for Customer, and account number should be the key for Account. Here is the ODL solution with key and extent declarations.
class Customer
(extent Customers key ssNo)
{
attribute string name;
attribute string addr;
attribute string phone;
attribute integer ssNo;
relationship Set<Account> ownsAccts
inverse Account::ownedBy;
}
class Account
(extent Accounts key number)
{
attribute integer number;
attribute string type;
attribute real balance;
relationship Set<Customer> ownedBy
inverse Customer::ownsAccts
}
Solutions for Section 4.4
Exercise 4.4.1(a)
Since the relationship between customers and accounts is many-many, we should create a separate relation from that relationship-pair.
Customers(ssNo, name, address, phone)
Accounts(number, type, balance)
CustAcct(ssNo, number)
Exercise 4.4.1(d)
Ther is only one attribute, but three pairs of relationships from Person to itself. Since motherOf and fatherOf are many-one, we can store their inverses in the relation for Person. That is, for each person, childrenOfMale and childrenOfFemale will indicate that persons's father and mother. The children relationship is many-many, and requires its own relation. This relation actually turns out to be redundant, in the sense that its tuples can be deduced from the relationships stored with Person. The schema:
Persons(name, childrenOfFemale, childrenOfMale)
Parent-Child(parent, child)
Exercise 4.4.4
You get a schema like:
Studios(name, address, ownedMovie)
Since name -> address is the only FD, the key is {name, ownedMovie}, and the FD has a left side that is not a superkey.
Exercise 4.4.5(a,b,c)
(a) Struct Card { string rank, string suit };
(b) class Hand {
attribute Set theHand;
};
For part (c) we have:
Hands(handId, rank, suit)
Notice that the class Hand has no key, so we need to create one: handID. Each hand has, in the relation Hands, one tuple for each card in the hand.
Exercise 4.4.5(e)
Struct PlayerHand { string Player, Hand theHand };
class Deal {
attribute Set theDeal;
}
Alternatively, PlayerHand can be defined directly within the declaration of attribute theDeal.
Exercise 4.4.5(h)
Since keys for Hand and Deal are lacking, a mechanical way to design the database schema is to have one relation connecting deals and player-hand pairs, and another to specify the contents of hands. That is:
Deals(dealID, player, handID)
Hands(handID, rank, suit)
However, if we think about it, we can get rid of handID and connect the deal and the player directly to the player's cards, as:
Deals(dealID, player, rank, suit)
Exercise 4.4.5(i)
First, card is really a pair consisting of a suit and a rank, so we need two attributes in a relation schema to represent cards. However, much more important is the fact that the proposed schema does not distinguish which card is in which hand. Thus, we need another attribute that indicates which hand within the deal a card belongs to, something like:
Deals(dealID, handID, rank, suit)
Exercise 4.4.6(c)
Attribute b is really a bag of (f,g) pairs. Thus, associated with each a-value will be zero or more (f,g) pairs, each of which can occur several times. We shall use an attribute count to indicate the number of occurrences, although if relations allow duplicate tuples we could simply allow duplicate (a,f,g) triples in the relation. The proposed schema is:
C(a, f, g, count)
Solutions for Section 4.5
Exercise 4.5.1(b)
Studios(name, address, movies{(title, year, inColor, length,
stars{(name, address, birthdate)})})
Since the information about a star is repeated once for each of their movies, there is redundancy. To eliminate it, we have to use a separate relation for stars and
use pointers from studios. That is:
Stars(name, address, birthdate)
Studios(name, address, movies{(title, year, inColor, length,
stars{*Stars})})
Since each movie is owned by one studio, the information about a movie appears in only one tuple of Studios, and there is no redundancy.
Exercise 4.5.2
Customers(name, address, phone, ssNo, accts{*Accounts})
Accounts(number, type, balance, owners{*Customers})
Solutions for Section 4.6
Exercise 4.6.1(a)
We need to add new nodes labeled George Lucas and Gary Kurtz. Then, from the node sw (which represents the movie Star Wars), we add arcs to these two new nodes, labeled directedBy and producedBy, respectively.
Exercise 4.6.2
Create nodes for each account and each customer. From each customer node is an arc to a node representing the attributes of the customer, e.g., an arc labeled name to the customer's name. Likewise, there is an arc from each account node to each attribute of that account, e.g., an arc labeled balance to the value of the balance. To represent ownership of accounts by customers, we place an arc labeled owns from each customer node to the node of each account that customer holds (possibly jointly). Also, we place an arc labeled ownedBy from each account node to the customer node for each owner of that account.
Exercise 4.6.5
In the semistructured model, nodes represent data elements, i.e., entities rather than entity sets. In the E/R model, nodes of all types represent schema elements, and the data is not represented at all.
Solutions for Section 4.7
Exercise 4.7.1(a)
<STARS-MOVIES>
<STAR starId = "cf" starredIn = "sw, esb, rj">
<NAME>Carrie Fisher</NAME>
<ADDRESS><STREET>123 Maple St.</STREET>
<CITY>Hollywood</CITY></ADDRESS>
<ADDRESS><STREET>5 Locust Ln.</STREET>
<CITY>Malibu</CITY></ADDRESS>
</STAR>
<STAR starId = "mh" starredIn = "sw, esb, rj">
<NAME>Mark Hamill</NAME>
<ADDRESS><STREET>456 Oak Rd.<STREET>
<CITY>Brentwood</CITY></ADDRESS>
</STAR>
<STAR starId = "hf" starredIn = "sw, esb, rj, wit"> <NAME>Harrison Ford</NAME>
<ADDRESS><STREET>whatever</STREET>
<CITY>whatever</CITY></ADDRESS>
</STAR>
<MOVIE movieId = "sw" starsOf = "cf, mh">
<TITLE>Star Wars</TITLE>
<YEAR>1977</YEAR>
</MOVIE>
<MOVIE movieId = "esb" starsOf = "cf, mh">
<TITLE>Empire Strikes Back</TITLE>
<YEAR>1980</YEAR>
</MOVIE>
<MOVIE movieId = "rj" starsOf = "cf, mh">
<TITLE>Return of the Jedi</TITLE>
<YEAR>1983</YEAR>
</MOVIE>
<MOVIE movieID = "wit" starsOf = "hf">
<TITLE>Witness</TITLE>
<YEAR>1985</YEAR>
</MOVIE>
</STARS-MOVIES>
Exercise 4.7.2
<!DOCTYPE Bank [
<!ELEMENT BANK (CUSTOMER* ACCOUNT*)>
<!ELEMENT CUSTOMER (NAME, ADDRESS, PHONE, SSNO)> <!ATTLIST CUSTOMER
custId ID
owns IDREFS>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT ADDRESS (#PCDATA)>
<!ELEMENT PHONE (#PCDATA)>
<!ELEMENT SSNO (#PCDATA)>
<!ELEMENT ACCOUNT (NUMBER, TYPE, BALANCE)>
<!ATTLIST ACCOUNT
acctId ID
ownedBy IDREFS>
<!ELEMENT NUMBER (#PCDATA)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT BALANCE (#PCDATA)>
]>
Database Systems: The Complete Array Book
Solutions for Chapter 5
Solutions for Section 5.2
Exercise 5.2.1(a)
PI_model( SIGMA_{speed >= 1000} ) (PC)
Exercise 5.2.1(f)
The trick is to theta-join PC with itself on the condition that the hard disk sizes are equal. That gives us tuples that have two PC model numbers with the same value of hd. However, these two PC's could in fact be the same, so we must also require in the theta-join that the model numbers be unequal. Finally, we want the hard disk sizes, so we project onto hd. The expression is easiest to see if we write it using some temporary values. We start by renaming PC twice so we can talk about two occurrences of the same attributes.
R1 = RHO_{PC1} (PC)
R2 = RHO_{PC2} (PC)
R3 = R1 JOIN_{PC1.hd = PC2.hd AND PC1.model <> PC2.model} R2
R4 = PI_{PC1.hd} (R3)
Exercise 5.2.1(h)
First, we find R1, the model-speed pairs from both PC and Laptop. Then, we find from R1 those computers that are ``fast,'' at least 133Mh. At the same time, we join R1 with Product to connect model numbers to their manufacturers and we project out the speed to get R2. Then we join R2 with itself (after renaming) to find pairs of different models by the same maker. Finally, we get our answer, R5, by projecting onto one of the maker attributes. A sequence of steps giving the desired expression is:
R1 = PI_{model,speed} (PC) UNION PI_{model,speed} (Laptop)
R2 = PI_{maker,model} (SIGMA_{speed>=700} (R1) JOIN Product)
R3 = RHO_{T(maker2, model2)} (R2)
R4 = R2 JOIN_{maker = maker2 AND model <> model2} (R3)
R5 = PI_{maker} (R4)
Exercise 5.2.2
Here are figures for the expression trees of Exercise 5.2.1 Part (a)Part (f)Part (h). Note that the third figure is not really a tree, since it uses a common subexpression. We could duplicate the nodes to make it a tree, but using common subexpressions is a valuable form of query optimization. One of the benefits one gets from constructing ``trees'' for queries is the ability to combine nodes that represent common subexpressions.
Exercise 5.2.7
The relation that results from the natural join has only one attribute from each pair of equated attributes. The theta-join has attributes for both, and their columns are identical.
Exercise 5.2.9(a)
If all the tuples of R and S are different, then the union has n+m tuples, and this number is the maximum possible.
The minimum number of tuples that can appear in the result occurs if every tuple of one relation also appears in the other. Surely the union has at least as many tuples as the larger of R and that is, max(n,m) tuples. However, it is possible for every tuple of the smaller to appear in the other, so it is possible that there are as few as max(n,m) tuples in the union.
Exercise 5.2.10
In the following we use the name of a relation both as its instance (set of tuples) and as its schema (set of attributes). The context determines uniquely which is meant.
PI_R(R JOIN S) Note, however, that this expression works only for sets; it does not preserve the multipicity of tuples in R. The next two expressions work for bags.
R JOIN DELTA(PI_{R INTERSECT S}(S)) In this expression, each projection of a tuple from S onto the attributes that are also in R appears exactly once in the second argument of the join, so it preserves multiplicity of tuples in R, except for those that do not join with S, which disappear. The DELTA operator removes duplicates, as described in Section 5.4. R - [R - PI_R(R JOIN S)] Here, the strategy is to find the dangling tuples of R and remove them.
Solutions for Section 5.3
Exercise 5.3.1
As a bag, the value is {700, 1500, 866, 866, 1000, 1300, 1400, 700, 1200, 750, 1100, 350, 733}. The order is unimportant, of course. The average is 959.
As a set, the value is {700, 1500, 866, 1000, 1300, 1400, 1200, 750, 1100, 350, 733}, and the average is 967. H3>Exercise 5.3.4(a)
As sets, an element x is in the left-side expression
(R UNION S) UNION T
if and only if it is in at least one of R, S, and T. Likewise, it is in the right-side expression
R UNION (S UNION T)
under exactly the same conditions. Thus, the two expressions have exactly the same members, and the sets are equal.
As bags, an element x is in the left-side expression as many times as the sum of the number of times it is in R, S, and T. The same holds for the right side. Thus, as bags the expressions also have the same value.
Exercise 5.3.4(h)
As sets, element x is in the left side
R UNION (S INTERSECT T)
if and only if x is either in R or in both S and T. Element x is in the right side
(R UNION S) INTERSECT (R UNION T)
if and only if it is in both R UNION S and R UNION T. If x is in R, then it is in both unions. If x is in both S and T, then it is in both union. However, if x is neither in R nor in both of S and T, then it cannot be in both unions. For example, suppose x is not in R and not in S. Then x is not in R UNION S. Thus, the statement of when x is in the right side is exactly the same as when it is in the left side: x is either in R or in both of S and T.
Now, consider the expression for bags. Element x is in the left side the sum of the number of times it is in R plus the smaller of the number of times x is in S and the number of times x is in T. Likewise, the number of times x is in the right side is the smaller of
The sum of the number of times x is in R and in S.
The sum of the number of times x is in R and in T.
A moment's reflection tells us that this minimum is the sum of the number of times x is in R plus the smaller of the number of times x is in S and in T, exactly as for the left side.
Exercise 5.3.5(a)
For sets, we observe that element x is in the left side
(R INTERSECT S) - T
if and only if it is in both R and S and not in T. The same holds for the right side
R INTERSECT (S-T)
so as sets, the equivalence holds.
Now suppose we have bags. Let R = {x}, S = {x,x}, and T = {x}. Then R INTERSECT S = {x}, and the left side is {x}-{x}, or EMPTYSET. However, on the right, S-T = {x}, so the right side is {x} INTERSECT {x}, which is {x}.
Solutions for Section 5.4
Exercise 5.4.1(a)
{(1,0,1), (5,4,9), (1,0,1), (6,4,16), (7,9,16)}.
Exercise 5.4.1(c)。