Applied Mathematics for Database Professionals phần 7 pot

If—in the course of rewriting expressions—you end up querying employees who don’t h ave a salary of less than 5 000 , it might be better to query the employees who have a salary equal to or more than 5000 instead. The following rewrite rule applies (e represents an employee tuple): ¬(e(MSAL) < 5000) ⇔ e(MSAL) ≥ 5000 Our brains dislike negations. Try to avoid negations by rewriting expressions into expres- sions containing fewer negations. This is not only true for query specifications, but also for constraint specifications (in previous chapters), and data manipulation specifications (in the next chapter). Chapter Summary This section provides a summary of this chapter, formatted as a bulleted list. You can use it to check your understanding of the various concepts introduced in this chapter before continu- ing with the exercises in the next section. • Queries constitute a crucial application of a database; they enable you to extract infor- mation from a database that is relevant for you. • You can formally represent a query as a function over a database universe. For every database state that you supply as the argument, the function returns the query result. • Because you supply a database state, the function can reference every table available in the database state to determine the query result. • To specify a query, you can use all formal concepts introduced in Part 1 of this book. You usually specify the result set of a query as a set of tuples (a table) using the hybrid method. The given set from which you start such a specification is typically one of the tables, or a join of some of the tables available in the database state; you can also use any of the set operators introduced in this book. The predicates inside the query speci- fication are typically compound predicates (they use the various logical connectives), and often employ the universal and existential quantifiers. • In practice (certainly when you use SQL), the result of a query will always be a table. However, our formal model does not require this. • When you use SQL as your query language, you should be aware of various limitations. Following are the most notable ones: • SQL is not set oriented; you sometimes have to use the distinct keyword. • SQL lacks the implication oper ator ; y ou must r ewrite these into disjunctions. • Or acle ’s version of SQL lacks universal quantification; you must rewrite this into existential quantification. • SQL lacks the subset operator; you must rewrite this using the other available set operators (union, intersect, and minus). CHAPTER 9 ■ DATA RETRIEVAL218 7451CH09.qxd 5/7/07 11:28 AM Page 218 • Our brains dislike negations. Whenever you specify a query, try to minimize the num- b er of negations in such a specification. Most of the time, you can use the rewrite rules introduced in Part 1 of this book to achieve this. Sometimes you can use simple arith- metic rewrite rules. On occasion, you can achieve this by using constraint knowledge of the database design that you query. Exercises Develop both formal and SQL expressions for these queries. ■Note In the following exercises, there may be queries that cannot be answered with the given database. In these cases, you should give arguments why the answer cannot be given. 1. Give the number and name of employees who belong to department 10. 2. Give the number and name of employees who do not belong to department 10, 11, 12, or 15. 3. Give the number and name of employees who belong to departments 10 and 11. 4. Give the number and name of employees who belong to a department that is a subde- partment of department 10. 5. Ascertain that the constraint of there being at most one president is not violated. 6. Give the number and name of administrators older than 35 who have a monthly salary of more than 2000. 7. Give the number and name of managers who earn the maximum of their grade. 8. G ive the number and name of the trainers who actually worked as such in at least one course in 2004. 9. Give the number and name of the trainers who did not work as such in any course in 2004. 10. G iv e the number, name , and salar y of every manager who earns less than any of his employees. 11. Find a query with answer “yes” if COURSE is uniquely identifying in OFFR and “no” if otherwise. Does the answer “yes” imply that COURSE is a key of OFFR? 12. Give of every manager: his or her number, name, and salary of every one of his or her subordinate employees. 13. Give for every employee whose manager is managed by another employee (super- manager): number and name of the emplo yee and of his or her super-manager. CHAPTER 9 ■ DATA RETRIEVAL 219 7451CH09.qxd 5/7/07 11:28 AM Page 219 14. Give of every manager and of every one of his or her direct subordinates who is a m anager: number, name, and date hired. 15. Give of every manager and of every one of his or her subordinates who is a manager: number, name, and date when they got the manager’s job. 16. Give the number and name of employees who left in 2006 and came back in that same year. 17. Give the number and name of employees who left in 2006 and did not come back. 18. Give the number of persons that left and the number that entered department 10 in 2006. 19. Give the number of persons in department 10 at the end of 2006. 20. List the following for the course “Designing Databases” that started on March 4, 2006: for every registered student, username, name, job, and evaluation. 21. Give for every one of the courses (with CODE) DB1, DB2, DB3, the duration, and for every offering (with a begin date) in 2006: begin date, status, and number of registered students. 22. Give per department (DEPTNO and DNAME) the number of administrators, trainers, sales representatives, and managers. 23. Give all data of salary grades where every employee (that is, employee who is assigned to this grade) is earning more than the salary grade’s upper limit minus 500 dollars. 24. Give all (managed) employees who are assigned to a higher salary grade than their boss’s salary grade. 25. Give the courses for which every canceled offering in 2006 had at least one student reg- istered for that offering. 26. Give the employees (EMPNO and ENAME) who attended (at least) one offering for all design courses (course category equals 'DSG') in 2006. 27. List all employees who have received a raise of more than 20 percent in the year 2006. CHAPTER 9 ■ DATA RETRIEVAL220 7451CH09.qxd 5/7/07 11:28 AM Page 220 Data Manipulation Through executing transactions, you can manipulate the data in a database. In this chapter we’ll demonstrate how you can specify a transaction in a formal way. We won’t formally intro- duce any new concepts; we’ve already presented all the ingredients for specifying transactions. The section “Formally Specifying Transactions” gradually develops how you can specify a transaction. You’ll learn that you can specify a transaction as a function over the database universe at hand. For every database state, this function returns another database state that reflects the intended changes of the transaction. In this section, we’ll also give two examples to familiarize you with this formal concept of a transaction. The section “Example Transactions Over DB_UEX” provides example transactions for the database universe that was introduced in Chapter 7. For the second time in this book, you’ll see the use of SQL. Every example transaction will be accompanied by one or more equivalent SQL data manipulation language (DML) statements; that is, INSERT, UPDATE, and DELETE state- ments. You’ll learn that expressing certain transactions in SQL requires executing more than one DML statement. ■Note We assume you have a working knowledge of SQL DML statements. It is not the goal of this book to teach SQL. In preparation for the next chapter (11) where you’ll be introduced to the challenges of implementing data integr ity constr aints using an SQL DBMS, we’ll also (somewhat) discuss which data integrity constraints a given transaction might violate. It is up to the DBMS to vali- date these involved data integrity constraints for the given transaction. The DBMS should r eject the intended changes of the transaction if the resulting database state violates any of the involved constraints. As usual, you’ll find a “Chapter Summary” at the end, followed by an “Exercises” section. Formally Specifying Transactions Next to data retrieval, transaction execution is the second most important application of a database. By executing transactions, you can maintain the database and ensure that its state remains a valid representation of the (changing) real world. In this section, we’ll demonstrate how you can formally specify transactions. 221 CHAPTER 10 7451CH10.qxd 5/7/07 11:36 AM Page 221 Let’s start with a simple example using the database design that was introduced in C hapter 7. Take a look at tuple t crs1 . It represents a new course than needs to be inserted into the database: tcrs1 := { (CODE;'AM4DP') , (DESC;'Applied Mathematics for Database Professionals') , (CAT;'DSG') , (DUR;5) } For your convenience, we repeat the definitions of characterization chr_CRS, tuple uni- verse tup_CRS, and table universe tab_CRS in Listing 10-1. All involved attribute, tuple, and table constraints with regards to the CRS table structure are in this listing. Listing 10-1. Definitions of chr_CRS, tup_CRS,and tab_CRS chr_CRS := { ( CODE; CRSCODE–TYP ) , ( DESCR; varchar(40) ) , ( CAT; { s | s∈varchar(3) ∧ s∈{'DSG','GEN','BLD'} } ) , ( DUR; { n | n ∈number(2,0) ∧ 1 ≤ n ≤ 15 } ) } tup_CRS := { c | c ∈Π(chr_CRS) ∧ c(CAT) = 'BLD' ⇒ t(DUR) ≤ 5 } tab_CRS := { C | C ∈℘(tup_CRS) ∧ (∀c1,c2∈C: c1(CODE) = c2(CODE) ⇒ c1 = c2) } ■Note tcrs1 does not viola te any attribute or tuple constraints for the CRS table structure; or put differ - ently, tcrs1 is an element of tuple universe tup_CRS. H ere is a first attempt to for mally specify the transaction of inserting tcrs1 into the CRS table structure. We could specify this transaction as a function, say Tx1a, over DB_UEX. For a given database state in DB_UEX, say dbs, function Tx1a returns a database state that reflects the inser tion of tcrs1 into the CRS table str ucture . Tx1a(dbs) := { (EMP; dbs(EMP) ) , (SREP; dbs(SREP)) , (MEMP; dbs(MEMP)) , (TERM; dbs(TERM)) , (DEPT; dbs(DEPT)) , (GRD; dbs(GRD) ) CHAPTER 10 ■ DATA MANIPULATION222 7451CH10.qxd 5/7/07 11:36 AM Page 222 , (CRS; dbs(CRS) ∪ {tcrs1} ) , (OFFR; dbs(OFFR)) , (REG; dbs(REG) ) , (HIST; dbs(HIST)) } A s you can see, function T x1a y ields another database state that holds the same ten table structures as dbs. This resulting database state differs from dbs only for the CRS table structure; tuple tcrs1 has been added. For all other table structures, the resulting database state holds the corresponding tables that dbs holds. Let’s apply Tx1a to the “empty database state” (that is, the database state in which all table structures hold the empty table). Here is the empty database state, which we’ll name db_empty. We introduced you to this database state in Exercise 12 in Chapter 7. db_empty := { (EMP; ∅) , (SREP; ∅) , (MEMP; ∅) , (TERM; ∅) , (DEPT; ∅) , (GRD; ∅) , (CRS; ∅) , (OFFR; ∅) , (REG; ∅) , (HIST; ∅) } In Exercise 12 in Chapter 7, you established that db_empty is an element of DB_UEX. There- fore, you can apply function Tx1a to it. Applying function Tx1a to db_empty, denoted by Tx1a(db_empty), results in the following database state: Tx1a(db_empty) = { (EMP; ∅) , (SREP; ∅) , (MEMP; ∅) , (TERM; ∅) , (DEPT; ∅) , (GRD; ∅) , (CRS; {tcrs1} ) , (OFFR; ∅) , (REG; ∅) , (HIST; ∅) } Note that the application of Tx1a to db_empty results in a database state that is (again) an element of DB_UEX; the r esulting database state confor ms to all static constraints that were specified as part of the definition of DB_UEX. However, this isn’t true in general. Let’s take a look at applying Tx1a to the follo wing database state ( dbs1): dbs1 := { (EMP; ∅) , (SREP; ∅) , (MEMP; ∅) , (TERM; ∅) , (DEPT; ∅) CHAPTER 10 ■ DATA MANIPULATION 223 7451CH10.qxd 5/7/07 11:36 AM Page 223 , (GRD; ∅) , (CRS; { { (CODE;'AM4DP'), (DESC;'AM4DP workshop') , (CAT;'DSG'), (DUR;1) } }) , (OFFR; ∅) , (REG; ∅) , (HIST; ∅) } Applying transaction Tx1a to database state dbs1 results in a database state that holds the following CRS table: { { (CODE;'AM4DP'), (DESC;'AM4DP workshop'), (CAT;'DSG'), (DUR;1) } , { (CODE;'AM4DP'), (DESC;'Applied Mathematics for Database Professionals'), (CAT;'DSG'), (DUR;5) } } This table clearly violates the table constraint that is specified as part of the definition of tab_CRS, and is therefore not an admissible table for the CRS table structure. Consequently, in this case, Tx1a(dbs1) is not an element of DB_UEX. Clearly the current definition of this transac- tion is flawed, for we don’t want a transaction to have the database end up in a state that violates any of the data integrity constraints. A more proper definition of the transaction that inserts tcrs1 to the database would be this one, named Tx1b. Note that in this definition we are reusing function Tx1a, which was specified earlier in this section. Tx1b(dbs) := dbs , if Tx1a(dbs)∉DB_UEX := Tx1a(dbs), otherwise Transaction Tx1b describes an insertion attempt. If the insertion of tcrs1 results in a data- base state that violates any of the data integrity constraints—that is, the resulting database state is not an element of DB_UEX—then the insertion is refused (also referred to as rolled back), and the database state remains the same. Otherwise, the insertion of tcrs1 is allowed (the transaction executes successfully, or commits). In this particular example, given a database state dbs, the insertion attempt successfully executes only if the CRS table in dbs does not already contain a tuple where the code attribute value equals 'AM4DP'. However, if that tuple is in fact tcrs1, the insertion attempt succeeds, but in this case does not add a tuple at all. Adding a tuple (through set union) to a table that already contains this tuple does not introduce a new element (tuple) to the table. Thus far, we are only focusing on attribute, tuple, and table constraints in this discussion. When checking whether Tx1a(dbs) is an element of DB_UEX, y ou should also consider the data- base constraints that involve the CRS table structure. ■Note You can determine the involved database constraints for a transaction that inserts a tuple in CRS by simply scanning for the string 'CRS' in the formal specifications of the database constraints. H er e ar e the inv olv ed database constr aints (using the shor t names intr oduced in Listing 7-39): PSSR6, PTIJ9, PTIJ10, PTIJ12, PTIJ14, PTIJ15, and PODC3. I n this particular exam- ple , inser ting a new CRS tuple into a v alid database state—a database state in DB_UEX—will CHAPTER 10 ■ DATA MANIPULATION224 7451CH10.qxd 5/7/07 11:36 AM Page 224 never violate one of these database constraints (you might want to verify this for yourself). T herefore, we need not consider these involved database constraints in the discussion of this example. ■Note The definition of Tx1b does cover all static constraints: attribute, tuple, table, and database. Last—this should not surprise you—the state transition constraints should be involved in the formal definition of a transaction. Take a look at tuple toffr1. It represents an offering for the AM4DP course that needs to be inserted into the database. toffr1 := { (COURSE; 'AM4DP') , (STARTS; '01-FEB-2007') , (STATUS; 'CONF') , (MAXCAP; 20) , (TRAINER; 1126) , (LOC; 'UTRECHT') } This tuple conforms to all attribute and tuple constraints that are specified for the OFFR table structure (see the definitions of chr_OFFR and tup_OFFR in Chapter 7). Let’s assume you’d like to attempt to insert the offr1 tuple into the database whose begin state currently conforms to all static constraints specified in the definition of DB_UEX. We’ll further assume that the begin database state for this transaction conforms to the following additional characteristics. In parentheses, we list involved constraints that cause us to list the characteristic. • CRS holds a tuple that represents the AM4DP course (PSSR6). • No offerings are in OFFR yet; this is the first one to be inserted (tab_OFFR constraints PTIJ13, PTIJ14, PTIJ15). • EMP holds a tuple that represents a trainer with employee number 1126, who was hired before February 1, 200 6. This trainer is still working for us; that is, he or she has not been terminated ( PSSR8, PTIJ11, PTIJ12, PODC7). • DEPT holds a tuple that r epresents a depar tment located in Utrecht. The aforemen- tioned trainer is wor king in this department ( PSSR7, PODC3). Thr ee other static constraints inv olve OFFR: PTIJ10, PODC4, and PODC5. H o w ever, these three cannot be violated by a transaction that inserts a new CRS tuple. They all involve the REG table structure too. The second characteristic in the preceding bulleted list, together with the fact that the begin state must be a v alid one (that is , contained in DB_UEX), imply that ther e ar e no tuples in REG. This in turn means that the database state conforms (and remains conformed after the insertion of offr1) to PTIJ10, PODC4, and PODC5. G iv en the pr eceding characteristics, the transaction of inserting tuple toffr1 would suc - cessfully execute. However, note that toffr1 represents a confirmed offering. The definition of our state transition universe ( ST_UEX from Chapter 8) contains the specification of a state CHAPTER 10 ■ DATA MANIPULATION 225 7451CH10.qxd 5/7/07 11:36 AM Page 225 transition constraint stating that new offerings must start with status scheduled (constraint S TC2 , in Listing 8-8). Clearly this transaction violates constraint S TC2 . A correct definition of the transaction that attempts to insert offr1, say Tx2, would be as follows. For a database state dbs in DB_UEX, let Tx2a(dbs) := { (EMP; dbs(EMP) ) , (SREP; dbs(SREP)) , (MEMP; dbs(MEMP)) , (TERM; dbs(TERM)) , (DEPT; dbs(DEPT)) , (GRD; dbs(GRD) ) , (CRS; dbs(CRS) ) , (OFFR; dbs(OFFR) ∪ {toffr1} ) , (REG; dbs(REG) ) , (HIST; dbs(HIST)) } and let Tx2b(dbs) := dbs , if Tx2a(dbs)∉DB_UEX := Tx2a(dbs), otherwise then, Tx2(dbs) := Tx2b(dbs), if (dbs,Tx2b(dbs))∈ST_UEX := dbs , otherwise The definition of Tx2a describes the insertion of toffr1. Tx2b ensures that this conforms to all static constraints. The definition of Tx2 ensures that the transaction conforms to all state transition constraints too. It does so by adding the condition that the ordered pair consisting of the begin state and the end state for the transaction is an element of the state transition universe. Often a transaction modifies only a few of the table structures involved in a database design; many table structures remain unchanged. An alternative (and somewhat shorter) way of specifying Tx2a, that more explicitly shows this fact, is as follows: Tx2a(dbs) := dbs↓{EMP,SREP,MEMP,TERM,DEPT,GRD,CRS,REG,HIST} ∪ { (OFFR; dbs(OFFR) ∪ {toffr1}) } Here we use function limitation (↓) to add all unchanged table structures to the end state, and thr ough union ( ∪) w e add the table structure(s) that the transaction modifies. The next section will present some mor e example tr ansactions o v er DB_UEX to familiariz e you further with formally specifying transactions. Example Transactions Over DB_UEX This section will provide example transactions. For every transaction, we’ll present you with the following: CHAPTER 10 ■ DATA MANIPULATION226 7451CH10.qxd 5/7/07 11:36 AM Page 226 • An informal description for the transaction • One or more formal expressions to specify the transaction • One or more SQL specifications that implement the transaction in an SQL DBMS Along the way, you’ll see that SQL has limitations that cause you to execute more than one DML statement to implement a given transaction. Listings 10-1 through 10-7 introduce the example transactions. All transactions will be named ETXi (example transaction i), where i represents a sequence number. In the formal specifications given for each transaction, dbs will represent the begin state for the transaction (an element of DB_UEX). The various alternative formal expressions will be named FEc (formal expression c), where c represents a character (a, b, c, and so on). In the SQL specifications, we’ll use the table structure names introduced by database characterization DB_CHREX (see Listing 7-38) as the table names available for INSERT, UPDATE, and DELETE statements. Alternative SQL specifications will be named SEr (SQL expression r), where r represents a Roman numeral (I, II, III, and so on). In the following formal expressions, we’ll specify a transaction as a function similar to the way Tx1a and Tx2a (always resulting in a modified database state) were specified in the previ- ous section. However, we intend—as discussed in the previous section—that all static and dynamic constraints should remain satisfied; that is, that the transaction rolls back whenever either the resulting database state is not an element of DB_UEX, or the ordered pair represent- ing the transition from the begin state to the end state is not an element of ST_UEX. In the previous section, you saw two examples of a transaction that inserts a single tuple. Take a look at the example in Listing 10-2. It specifies a transaction that inserts (potentially) multiple tuples. Listing 10-2 registers all administrators that have been hired in the past quar- ter (91 days) for the offering of course AM4DP that starts on March 1, 2007. Listing 10-2. Transaction ETX1(dbs) FEa: dbs↓{EMP,SREP,MEMP,TERM,DEPT,GRD,CRS,OFFR,HIST} ∪ { (REG; dbs(REG) ∪ { { (COURSE;'AM4DP' ) ,(STARTS;'01-mar-2007') ,(STUD; e(EMPNO) ) ,(EVAL; -1 ) } | e ∈dbs(EMP) ∧ e(JOB)='ADMIN' ∧ e(HIRED) ≥ sysdate-91 ∧ e(HIRED) ≤ sysdate } ) } SEI: insert into REG(STUD,EVAL,COURSE,STARTS) select e.EMPNO, -1, 'AM4DP', '01-mar-2007' from EMP e where e.JOB = 'ADMIN' and e.HIRED between sysdate - 91 and sysdate CHAPTER 10 ■ DATA MANIPULATION 227 7451CH10.qxd 5/7/07 11:36 AM Page 227 [...]... this transaction encounter? 2 37 7451CH10.qxd 5 /7/ 07 11:36 AM Page 238 74 51CH11.qxd 5/15/ 07 2:26 PM PART Page 239 3 The Implementation La pratica deve basarsi su una valida teoria (Practice should always be based upon a sound knowledge of theory.) Leonardo da Vinci (1452–1519) 74 51CH11.qxd 5/15/ 07 2:26 PM Page 240 74 51CH11.qxd 5/15/ 07 2:26 PM CHAPTER Page 241 11 Implementing Database Designs in Oracle... cancels the offering for course J2EE that starts on February 14, 20 07 Listing 10-6 Transaction ETX5(dbs) FEa: dbs↓{SREP,MEMP,TERM,DEPT,GRD,CRS,EMP,HIST} ∪ { (REG; { r | r∈dbs(REG) ∧ (r(COURSE) ≠ 'J2EE' ∨ r(STARTS) ≠ '14-feb-20 07' ) } ) } 74 51CH10.qxd 5 /7/ 07 11:36 AM Page 233 CHAPTER 10 s DATA MANIPULATION ∪ { (OFFR; { o | o∈dbs(OFFR) ∧ ¬ (o(COURSE) = 'J2EE' ∧ o(STARTS) = '14-feb-20 07' ) } ∪ { o↓{COURSE,STARTS,MAXCAP,TRAINER,LOC}... '14-feb-20 07' } ) } SEI: delete from REG r where r.COURSE = 'J2EE' and r.STARTS = '14-feb-20 07' ; update OFFR o set o.STATUS = 'CANC' where o.COURSE = 'J2EE' and o.STARTS = '14-feb-20 07' SEII: update OFFR o set o.STATUS = 'CANC' where o.COURSE = 'J2EE' and o.STARTS = '14-feb-20 07' ; delete from REG r where r.COURSE = 'J2EE' and r.STARTS = '14-feb-20 07' Formal expression FEa should be straightforward by... for ETX2, such that as many as possible registrations for student 3124 are deleted, without violating constraint PODC4 74 51CH10.qxd 5 /7/ 07 11:36 AM Page 2 37 CHAPTER 10 s DATA MANIPULATION 3 Determine the static data integrity constraints that might get violated by the SQL UPDATE statement of transaction ETX4 4 Suppose transaction ETX7 creates a database state that indeed violates the discussed table... confirmed, and canceled), you can deduce that if there is a registration for an offering, then that offering will either have status scheduled or confirmed There is no need for you to specify this in the transaction 229 74 51CH10.qxd 230 5 /7/ 07 11:36 AM Page 230 CHAPTER 10 s DATA MANIPULATION Here are equivalent formal and SQL specifications for transaction ETX2: FEa: dbs↓{EMP,SREP,MEMP,TERM,DEPT,GRD,CRS,OFFR,HIST}... implementing a database design s Note This chapter will be quite different from the previous ones It contains far less mathematics, although, as you will see, mathematics can still be applied when implementing a database design We think that this chapter adds value to this book, because in our experience, the challenges investigated in this chapter are often overlooked 74 51CH11.qxd 5/15/ 07 2:26 PM Page... rolled back 235 74 51CH10.qxd 236 5 /7/ 07 11:36 AM Page 236 CHAPTER 10 s DATA MANIPULATION There is an exercise at the end of this chapter for you to specify an UPDATE statement that fixes such a violation Chapter Summary This section provides a summary of this chapter, formatted as a bulleted list You can use it to check your understanding of the various concepts introduced in this chapter before continuing... You can formally specify a transaction as a function over a database universe For every database state, this function returns another database state that reflects the modifications intended by the transaction • You can specify this function using the set theory and logic introduced in Part 1 in conjunction with the various table operators introduced in Part 2 • Transactions start out in a valid database. .. by far the most important part of a database design Of course, you want to do more than just specify a database design; you usually would like to implement it using some DBMS, and build business applications on top of it Unfortunately there are no true relational DBMSes available to us; we are forced to use an SQL DBMS to implement a database design Implementing a database design in an SQL DBMS, as... constraints for transaction ETX1 Also discuss the properties that the begin state should have for transaction ETX1 to execute successfully 2 Transaction ETX2 might violate constraint PODC4; if the removal of a registration for student 3124 brings the number of registrations for a confirmed offering below six, then this constraint is violated Amend the specification (both formal and SQL) for ETX2, such . of a database; they enable you to extract infor- mation from a database that is relevant for you. • You can formally represent a query as a function over a database universe. For every database. be inserted into the database: tcrs1 := { (CODE;'AM4DP') , (DESC;&apos ;Applied Mathematics for Database Professionals& apos;) , (CAT;'DSG') , (DUR;5) } For your convenience,. you can formally specify transactions. 221 CHAPTER 10 74 51CH10.qxd 5 /7/ 07 11:36 AM Page 221 Let’s start with a simple example using the database design that was introduced in C hapter 7. Take