Applied Mathematics for Database Professionals phần 4 docx

Definition 5-1 describes the concept of a table in a formal way. It uses the concept of “a f unction over a given set” (see Definition 4-2). ■Definition 5-1: Table If T and H are sets, then “T is a table over H” ⇔ ( ∀t∈T: t is a function over H ). This definition is generic in the sense that no restrictions are imposed upon the elements of set H. However, in practice we’ll only be interested in those cases where H is a set of names representing attributes. Table T1 can be considered a parts table. It is a table over {partno,name,instock,price}, consisting of six tuples, each representing information about a different part. It holds for each such part the part number, its name, how many items of the part are in stock, and the price of the part. Here are a few more examples: T2 := { { (X;2), (Y;1) }, { (Y;8), (X;0) }, { (Y;10), (X;5) } } T3 := { { (partno;3), (name;'hammer') }, { (pno;4), (pname;'nail') } } T4 := { { (empno;105), (ename;'Mrs. Sparks'), (born;'03-apr-1970') } ,{ (empno;202), (ename;'Mr. Tedesco') } } T2 is indeed a table. It holds three functions, all of which share the domain {X,Y}. It is a table over {X,Y}. Note that the order of the pairs (inside the functions) doesn’t matter. T3 is not a table. It is a set of functions; however, the domain of the first function is {partno,name}, which differs from the domain of the second function: {pno,pname}. Likewise, T4 is also not a table. It is a set of functions; however, the domain of the first function is {empno, ename, born} , which differs from the domain of the second function: {empno,ename}. An element of a table is a function, and each such function is referred to specifically as a tuple. In Chapter 4 you were introduced to this term when we introduced the generalized product of a characterization (see the section “The Generalized Product of a Set Function”). The generalized product of a characterization is in fact a table; it holds functions, all of which share the same domain. A table is a set, and the elements of this set are tuples. By the definition of a set, this implies that ever y tuple is unique within that set; no tuple can appear more than once in the same table. I f T is a table o v er H, then ev ery proper, non-empty subset of T (containing few er tuples than T) is of course also a table ov er H. Even the empty set ( ∅) is a table. In fact, under Definition 5-1 (which quantifies over the elements in the table), the empty set is a table o v er any set . Y ou might want to revisit the r ewr ite r ules in T able 3-2 for this. ■Note The empty set is often used as the initial sta te for a given table structure. CHAPTER 5 ■ TABLES AND DATABASE STATES 95 7451CH05.qxd 5/4/07 3:57 PM Page 95 Shorthand Notation Writing down a table using the formal enumerative method as introduced in Listing 5-1 is quite elaborate. For every tuple that’s an element of the table, you’re essentially repeating the ( shared) domain as the first coordinates of the ordered pairs. To avoid this repetition, it’s com- mon to draw a picture of a table. In this picture you list the names of the attributes of the tuples only once (as column headers) and under those you then list the attribute values for every tuple (one per row). Figure 5-1 shows this shorthand notation of a table. It does so for table T1 introduced in Listing 5-1. Figure 5-1. Shorthand notation for table T1 As you can see, this looks like a table in the common language sense (a two-dimensional picture of columns and rows). But remember, a table—in this book—is a set of functions. This has two important implications. First, this means that the order in which functions are enu- merated is arbitrary; it does not matter. And second, the order in which the ordered pairs are enumerated (within a tuple) does not matter either. Therefore, in the preceding shorthand notation, the order of the column headers (left to right) and the order of the rows (top to bot- tom) don’t matter. ■Note In the shorthand notation, an ordering to the attributes has been introduced because the order of attribute values in each tuple now has to correspond to the ordering of the column headings. The shorthand notation demonstrates some other terminology that is often used when dealing with tables. As you can see, table T1 is a table over {partno,name,instock,price}. This shared domain of the tuples in T1 is referred to as the heading of table T1 (see Definition 5-2). ■Definition 5-2: Heading of a Table If “T is a table over H” then H is referred to as the heading of T. CHAPTER 5 ■ TABLES AND DATABASE STATES96 7451CH05.qxd 5/4/07 3:57 PM Page 96 We’ll often use the shorthand notation in the remainder of this book to illustrate a partic- u lar table. However, you should never forget that it is only a shorthand notation. In this book, a table is formally defined as a set of functions, all of which share the same domain. This formal definition of a table enables you to deal with operations on tables (later in this chapter) and data integrity predicates (discussed in the next chapter) in a clear and formal way too. Table Construction You can construct a table from a given set function by applying the generalized product to it. Let’s demonstrate this with an example. Listing 5-2 displays a set function called F1. Listing 5-2. Set Function F1 F1 := { (X; {0,1,2}) ,(Y; {0,1,2}) ,(Z; {-1,0,1}) } The generalized product of set function F1 will result in a set of twenty-seven functions (three times three times three). Listing 5-3 shows this result. Listing 5-3. The Generalized Product of Set Function F1 ∏(F1) := { { (X;0), (Y;0), (Z;-1) }, { (X;0), (Y;0), (Z;0) }, { (X;0), (Y;0), (Z;1) } , { (X;0), (Y;1), (Z;-1) }, { (X;0), (Y;1), (Z;0) }, { (X;0), (Y;1), (Z;1) } , { (X;0), (Y;2), (Z;-1) }, { (X;0), (Y;2), (Z;0) }, { (X;0), (Y;2), (Z;1) } , { (X;1), (Y;0), (Z;-1) }, { (X;1), (Y;0), (Z;0) }, { (X;1), (Y;0), (Z;1) } , { (X;1), (Y;1), (Z;-1) }, { (X;1), (Y;1), (Z;0) }, { (X;1), (Y;1), (Z;1) } , { (X;1), (Y;2), (Z;-1) }, { (X;1), (Y;2), (Z;0) }, { (X;1), (Y;2), (Z;1) } , { (X;2), (Y;0), (Z;-1) }, { (X;2), (Y;0), (Z;0) }, { (X;2), (Y;0), (Z;1) } , { (X;2), (Y;1), (Z;-1) }, { (X;2), (Y;1), (Z;0) }, { (X;2), (Y;1), (Z;1) } , { (X;2), (Y;2), (Z;-1) }, { (X;2), (Y;2), (Z;0) }, { (X;2), (Y;2), (Z;1) } } In this result set, every function has the same domain {X,Y,Z}; the result set is therefore a table o ver {X,Y,Z}. N ow take a look at the following, more realistic, example. Listing 5-4 shows a characterization of a part. For a part, the attributes of interest are the number of the part ( partno), its name (name), the quantity in stock of this part (instock), and the part’s price ( price). Listing 5-4. Characterization of a P ar t chr_PART := { (partno; [1 999]) ,(name; varchar(12)) ,(instock; [0 99]) ,(price; [1 500]) } CHAPTER 5 ■ TABLES AND DATABASE STATES 97 7451CH05.qxd 5/4/07 3:57 PM Page 97 The generalized product of chr_PART is a rather large table; it contains all possible tuples that can be generated using the given attribute-value sets that are introduced in the definition of chr_PART. Note that every tuple inside table T1—introduced at the beginning of this chapter— is an element of ∏(chr_PART). This makes T1 a subset of ∏(chr_PART). ■Note Every subset of ∏(chr_PART)—not just T1—is a table over {partno,name,instock,price}. In fact, every tuple in table T1 is an element of the following set (named T2) that is based on ∏(chr_PART): T2 := { t | t∈∏(chr_PART) ∧ ( t(price) ≥ 20 ⇒ t(instock) ≤ 10 ) ∧ ( t(price) ≤ 5 ⇒ t(instock) ≥ 15 ) } Inside the definition of T2, two predicates are introduced that condition the contents of T2. The first condition states that if the price of a part is 20 or more, then the quantity in stock for this part should be 10 or less. The second condition states that if the price of a part is 5 or less, then the quantity in stock for this part should be 15 or more. T2—a table over {partno,name,instock,price}—will hold all and only those tuples of ∏(chr_PART) for which both these two conditions are true. Note that because ∏(chr_PART) will hold many tuples that violate one or both of these conditions, T2 is a proper subset of ∏(chr_PART). Because all tuples of T1 conform to these two conditions, T1 is a subset of T2. In fact, it is a proper subset of T2. In Chapter 7 we’ll revisit this way of defining T2; that is, taking the generalized product of a characterization and “plugging in” additional predicates. Database States A database is a representation of the state of affairs of some organization. It consists of a table for every kind of proposition about this organization that we would like to record in the data- base. This section introduces you to a formal way of specifying a database via a database state. Formal Representation of a Database State Let’s consider a simple database design involving two table structures: one for employees and one for departments. Take a look at tables EMP1 and DEP1, which are displayed in Figures 5-2 and 5-3. CHAPTER 5 ■ TABLES AND DATABASE STATES98 7451CH05.qxd 5/4/07 3:57 PM Page 98 Figure 5-2. Example employee table EMP1 Figure 5-3. Example department table DEP1 Let’s assume that tables EMP1 and DEP1 represent the current state of the employee and department table structures, respectively. We can formally specify the database state consist- ing of tables EMP1 and DEP1 as a function. In this function, the first coordinates of the ordered pairs r epr esent the table str ucture names and the second coor dinates hold the (curr ent) values—tables EMP1 and DEP1—for these table structures. Listing 5-5 gives the formal specifica- tion of this example database state. Listing 5-5. The Database State DBS1 Holding Tables EMP1 and DEP1 DBS1 := { (EMPLOYEE; { {(empno;101),(ename;'Chris'), (job;'MANAGER'),(sal;7900),(deptno;10)} ,{(empno;102),(ename;'Kathy'), (job;'TRAINER'),(sal;6000),(deptno;12)} ,{(empno;103),(ename;'Thomas'),(job;'CLERK'), (sal;2100),(deptno;10)} ,{(empno;104),(ename;'David'), (job;'TRAINER'),(sal;5600),(deptno;10)} ,{(empno;105),(ename;'Renu'), (job;'CLERK'), (sal;3000),(deptno;12)} ,{(empno;106),(ename;'Bob'), (job;'MANAGER'),(sal;8500),(deptno;10)} ,{(empno;107),(ename;'Sue'), (job;'CLERK'), (sal;2700),(deptno;12)} } CHAPTER 5 ■ TABLES AND DATABASE STATES 99 7451CH05.qxd 5/4/07 3:57 PM Page 99 ) ,(DEPARTMENT; { {(deptno;10),(dname;'RESEARCH'),(loc;'DENVER'), (salbudget;50000)} ,{(deptno;11),(dname;'SALES'), (loc;'DENVER'), (salbudget;20000)} ,{(deptno;12),(dname;'SUPPORT'), (loc;'LOS ANGELES'), (salbudget;40000)} ,{(deptno;13),(dname;'SALES'), (loc;'SAN FRANCISCO'),(salbudget;20000)} } ) } ■Note We could have also listed DBS1 to equal the set {(EMPLOYEE;EMP1), (DEPARTMENT;DEP1)}. Database state DBS1 is a function containing just two ordered pairs. The first coordinate of the first ordered pair listed is EMPLOYEE (the name we chose for the employee table structure), and the corresponding second coordinate is table EMP1. Likewise, in the second ordered pair you’ll notice that we chose DEPARTMENT as the name for the department table structure. In this case, the second coordinate is table DEP1. Given this definition of function DBS1, you can now—using function application—refer to expressions such as DBS1(EMPLOYEE), which denotes table EMP1, and DBS1(DEPARTMENT), which denotes table DEP1. Database Skeleton To specify a database state, you not only need actual tables (EMP1 and DEP1 in the preceding example), but you also need to decide upon names for the table structures (EMPLOYEE and DEPARTMENT in the preceding example). You probably won’t be surprised by now that the formal specification of a database design (which we’ll demonstrate in Chapter 7) also holds the specification of a characterization for every table design involved. You choose the names of the attributes involved in a table design when you specify the characterization for that table design. A database skeleton collects all these names—for the table structures and the involved attributes—into a single for mal structur e. A database skeleton is a set function with an ordered pair for every table structure. Every first coordinate introduces the table structure name, and the second coordinate introduces the set of names of the involved attributes. Listing 5-6 displays the database skeleton for the emplo yee/department database design introduced in the previous section. Listing 5-6. The Database Skeleton SK1 SK1 := { (EMPLOYEE; {empno,ename,job,sal,deptno} ) ,(DEPARTMENT; {deptno,dname,loc,salbudget} ) } As y ou can see , set function SK1 intr oduces the names EMPLOYEE and DEPARTMENT for the table str uctures involved in the employee/department database design, and it attaches the set of names of the r elev ant attr ibutes to them. CHAPTER 5 ■ TABLES AND DATABASE STATES100 7451CH05.qxd 5/4/07 3:57 PM Page 100 ■Note You should carefully choose the names introduced by the database skeleton, because they not only constitute the vocabulary between you (the database professional) and your customer (the users), they are also the first stepping stone to understanding the meaning (semantics) of a database design. You’ll see in the following chapters that data integrity constraints form a further important stepping stone for the understand- ing of the semantics of the database design. Operations on Tables This section covers some important table operators. You will apply these operators when speci- fying queries and transactions (Chapters 9 and 10), or certain types of predicates (Chapters 6, 7, and 8). We’ll first take a look at the well-known set operators union, intersection, and difference. Next we’ll investigate the projection and restriction of a table, followed by the join—an impor- tant operator in the database field—and closely related to the join, the attribute renaming operator. Finally, we’ll deal with extension and aggregation. Union, Intersection, and Difference Because tables are sets, you can apply the well-known set operators, union, intersection, and difference, with tables as their operands. This section will explore the application of these set operators on tables. We’ll use three example tables, named E1, E2, and E3, in the following sections. Figure 5-4 displays these tables. Figure 5-4. Example tables E1, E2, and E3 CHAPTER 5 ■ TABLES AND DATABASE STATES 101 7451CH05.qxd 5/4/07 3:57 PM Page 101 As you can see, E1 and E2 are both tables over {EMPNO,ENAME,JOB}, and E3 is a table over {E#,NAME,JOB,SAL}. All three tables represent information about employees. For E3, some of the names of the attributes were chosen differently, and E3 holds additional information (the salary). Employee 102 occurs in both table E1 and table E2 (with the same attribute values). Employee 101 occurs in both table E1 and table E3. Union As you probably know, the union of two sets holds all objects that are either an element of the first set, or an element of the second set, or an element of both. Here is the union of tables E1 and E2, denoted by E1∪E2: E1∪E2 = { {(EMPNO;101), (ENAME;'Anne'), (JOB;'TRAINER') } ,{(EMPNO;102), (ENAME;'Thomas'), (JOB;'SALESMAN') } ,{(EMPNO;103), (ENAME;'Lucas'), (JOB;'PRESIDENT')} ,{(EMPNO;104), (ENAME;'Pete'), (JOB;'MANAGER') } } The union of E1 and E2 is a table over {EMPNO,ENAME,JOB}. It holds four tuples, not five, because the tuple of employee 102 is a member of both sets. Now take a look at the union of tables E1 and E3 (E1∪E3): E1∪E3 = { {(EMPNO;101), (ENAME;'Anne'), (JOB;'TRAINER') } ,{(EMPNO;102), (ENAME;'Thomas'), (JOB;'SALESMAN') } ,{(EMPNO;103), (ENAME;'Lucas'), (JOB;'PRESIDENT') } ,{(E#;101), (NAME;'Anne'), (JOB;'TRAINER'), (SAL;3000)} ,{(E#;102), (NAME;'John'), (JOB;'MANAGER'), (SAL;5000)} } This result is a set of functions, but it clearly isn’t a table; not all the functions in this result set share the same domain. Remember the closure property (in the section “Union, Intersection, and Difference” in Chapter 2)? We’re only interested in those cases where the union of two tables results in another table. The union operator is evidently not closed over tables in general. It’s only closed over tables if the operands are tables that have the same heading. If the operands of the union operator are non-empty tables over different headings, then the resulting set won’t be a table. N ote the special case where the empty table is involved as an operand. The union of a given table with the empty table ( ∅) always results in the given table; because ∅ is a table over any heading, the closure property holds. Intersection The intersection of two sets holds all objects that ar e an element of the first set and an ele- ment of the second set. H er e ’ s the intersection of tables E1 and E2 (E1∩E2): E1∩E2 = { {(EMPNO;102), (ENAME;'Thomas'), (JOB;'SALESMAN')} } The intersection of E1 and E2 is a table. It’s probably not difficult to see that the intersec- tion of two tables with the same heading will always result in another table. Note that the intersection is also closed over tables when the operands are tables over different headings. CHAPTER 5 ■ TABLES AND DATABASE STATES102 7451CH05.qxd 5/4/07 3:57 PM Page 102 However, the intersection is useless in these cases, because it then always results in the empty t able; you might want to check this by investigating the intersection of E 1 a nd E 3 ( tables with different headings). You can meaningfully intersect tables E1 and (part of) E3, but first you’d have to transform one of these in such a way that it has the same heading as the other table. The concepts that enable you to do so have all been introduced in Chapter 4: function limitation and function composition. Take a look at the following definition for table E4. It renames attributes E# and NAME of table E3. E4 := { e◊{(EMPNO;E#),(ENAME;NAME),(JOB;JOB),(SAL;SAL)} | e∈E3 } Set E4 is a table over {EMPNO,ENAME,JOB,SAL}. We used function composition (◊; see Defini- tion 4-8) to rename two attributes. Attribute E# is renamed to EMPNO and attribute NAME is renamed to ENAME. The other two attributes (JOB and SAL) are left untouched. Next we need to get rid of the extra SAL attribute (which is also not part of the heading of E1). For this we use function limitation (↓, see Definition 4-4). Take a look at the definition of E5: E5 := { e↓{EMPNO,ENAME,JOB} | e∈E4 } E5 equals the following set: { {(EMPNO;101), (ENAME;'Anne'), (JOB;'TRAINER')} ,{(EMPNO;102), (ENAME;'John'), (JOB;'MANAGER')} } The intersection of E5 with E1 has now become meaningful, and results in the following set: E5∩E1 = { {(EMPNO;101), (ENAME;'Anne'), (JOB;'TRAINER')} } Last, we note the special case where the empty table is involved as an operand. The inter- section of a given table with the empty table always results in the empty table. Difference The difference of two sets holds all objects that are an element of the first set and that are not an element of the second set. Here is the difference of tables E1 and E2 (E1–E2): E1–E2 = { {(EMPNO;101), (ENAME;'Anne'), (JOB;'TRAINER') } ,{(EMPNO;103), (ENAME;'Lucas'), (JOB;'PRESIDENT')} } Again, as you can see, the result is a table over {EMPNO,ENAME,JOB}. The difference of two tables with the same heading always produces another table. Like the intersection, the differ- ence oper ator is also closed ov er tables when the operands are tables over differ ent sets . However, here too, in these cases the difference is useless because it always results in the first table; the second table cannot have tuples that are in the first table (due to the different head- ings). H ence , tuples will nev er be “removed” from the first set. Because the difference operator is not commutative, we note the two special cases when the empty set is involved as an operand (in contrast with the preceding intersection and union). Let T be a giv en table; then T–∅ always r esults in a giv en table T, and ∅–T always results in the empty table. CHAPTER 5 ■ TABLES AND DATABASE STATES 103 7451CH05.qxd 5/4/07 3:57 PM Page 103 Projection Another important table operator that needs to be introduced is the projection of a table on a g iven set. The projection of a given table—say T— on a given set—say B— performs the l imita- tion of every tuple in T on set B. We use symbol ⇓ to denote projection. The projection operator can be viewed as a version of the limitation operator that has been lifted to the table level. Definition 5-3 formally defines this operator. ■Definition 5-3: Projection of a Table Let T be a set of functions and B a set. The projection of T on B, notation T⇓B, is defined as follows: T⇓B := { t↓B | t∈T } The projection of T on B holds every function in T limited to B. Although the preceding definition describes the projection for each set of functions T and each set B, we are mainly (but not exclusively) interested in those cases in which T is a table, and moreover in which B is a (non-empty) proper subset of the heading of such a table. Let’s take a look at an example to illustrate the concept of projection. Listing 5-7 intro- duces table T3. It holds five tuples with domain {empno,ename,salary,sex,dno}. Listing 5-7. Table T3 T3 := { {(empno;10), (ename;'Thomas'), (salary;2400), (sex;'male'), (dno;1)} ,{(empno;20), (ename;'Lucas'), (salary;3000), (sex;'male'), (dno;1)} ,{(empno;30), (ename;'Aidan'), (salary;3000), (sex;'male'), (dno;2)} ,{(empno;40), (ename;'Keeler'), (salary;2400), (sex;'male'), (dno;1)} ,{(empno;50), (ename;'Elizabeth'), (salary;5600), (sex;'female'), (dno;2)} } Here’s the result of the projection of T3 on {salary,sex}, denoted by T3⇓{salary,sex}: T3⇓{salary,sex} = { {(salary;2400), (sex;'male')} , {(salary;3000), (sex;'male')} , {(salary;5600), (sex;'female')} } N ote that the projection of T3 on {salary,sex} r esults in another table: a table over {salary,sex}. This table has only three elements, whereas T3 has five elements. The first and the fourth tuple enumerated in the definition of T3 result in the same (limited) function, as do the second and the third function enumerated in T3. Therefore, only three tuples remain in the resulting set of this projection. You can now specify E5 introduced in the section “Intersection” with E4⇓{EMPNO,ENAME,JOB}. Restriction Tables typically hold many tuples. Often you’re only interested in some of these tuples: tuples that have a certain property. You want to look at a subset of the tuples in the given table. You CHAPTER 5 ■ TABLES AND DATABASE STATES104 7451CH05.qxd 5/4/07 3:57 PM Page 104 [...]... a given tuple, table, or database state satisfies them However, when formally specifying a database design, we aren’t interested in a single database state (or table or tuple) We are interested in a database state space: a set that holds all values that we allow for our database We intend to mathematically model such a database state space that represents the value set for a database variable (this... useful to confront end users with such derivable statements It can act as a double check for the data integrity constraints already established, or likely, it will get you more information that the end user didn’t tell you yet 123 745 1CH06.qxd 1 24 5/ 14/ 07 10:37 AM Page 1 24 CHAPTER 6 s TUPLE, TABLE, AND DATABASE PREDICATES Database Predicates We continue now by further increasing the scope of data that a... table from Figure 6-3) Now let’s take a look at database predicates P13 and P 14 in Listing 6-8 Remember parameter S represents a database state 125 745 1CH06.qxd 126 5/ 14/ 07 10:37 AM Page 126 CHAPTER 6 s TUPLE, TABLE, AND DATABASE PREDICATES Listing 6-8 Two Example Database Predicates P13(S) := { e(deptno)| e∈S(employee) } ⊆ { d(deptno)| d∈S(department) } P 14( S) := ( ∀d∈S(department): ( Σe2∈{ e1| e1∈S(employee)... reject a table (a set of tuples) We familiarize you with the concept of database predicates in the section Database Predicates.” Database predicates deal with database states We’ll use them to accept or reject a database state (loosely speaking, a set of tables) 117 745 1CH06.qxd 118 5/ 14/ 07 10:37 AM Page 118 CHAPTER 6 s TUPLE, TABLE, AND DATABASE PREDICATES s Note There is a reason why this book discerns... for each of the following expressions whether it represents a table, and if so, over which set? a P∪S b P∩S 745 1CH05.qxd 5 /4/ 07 3:57 PM Page 115 CHAPTER 5 s TABLES AND DATABASE STATES c (P⇓{partno}) ∪ (SP⇓{partno}) d S–SP e P∪∅ 2 Formally specify a table that is based on characterization chr_PART, in which a A hammer always costs more than 250 b A part that costs less than 40 0 cannot be a drill c For. .. that you add in such a predicative specification are said to perform a table restriction 113 745 1CH05.qxd 1 14 5 /4/ 07 3:57 PM Page 1 14 CHAPTER 5 s TABLES AND DATABASE STATES • The join operator (⊗) combines compatible tuples from two given tables Because it is based on the compatibility concept, it requires the attributes that are to be used for this combination to have matching names • The attribute renaming... require for these cases that Q is introduced as a table predicate and that database predicate P is discarded Without loss of generality, we again confine our attention to database predicates that cannot be decomposed into multiple conjuncts If you can rewrite a given database predicate P(S) into an expression of the form Pa(S) ∧ Pb(S), then you are in fact dealing with two database predicates  745 1CH06.qxd... world and that need to be reflected somehow in the specification of a database design The predicate class (tuple, table, or database) to which a business rule maps is fully dependent on the given database skeleton of the database design For instance, predicate P8 (see Listing 6-5) is a table predicate because all the information to formally specify the business rule that managers earn more than trainers,... proposition 30 ≥ 20 ⇒ 4 ≤ 10 This is also a TRUE proposition; therefore t1 satisfies P1 Check for yourself that the following propositions are TRUE propositions: P0(t6), P2(t3), P3(t6), P4(t0) The following are FALSE propositions: P1(t2), P3(t5) Note that we cannot instantiate a tuple predicate with just any tuple For instance, instantiating predicate P2 with tuple t4 cannot be done because t4 lacks a status... can formally specify this table in a predicative way as follows: { e∪d | e∈T6 ∧ d∈T7 ∧ e(deptno)=d(deptno) } Every tuple from T6 is combined with the tuples in T7 that have the same deptno value This combining of tuples of two “related” tables is known as the join of two such tables Definition 5 -4 formally defines this operator 107 745 1CH05.qxd 108 5 /4/ 07 3:57 PM Page 108 CHAPTER 5 s TABLES AND DATABASE . you to a formal way of specifying a database via a database state. Formal Representation of a Database State Let’s consider a simple database design involving two table structures: one for employees. two such tables. Defin- ition 5 -4 for mally defines this operator. CHAPTER 5 ■ TABLES AND DATABASE STATES 107 745 1CH05.qxd 5 /4/ 07 3:57 PM Page 107 ■Definition 5 -4: The Join of Two Tables Let R. Check for each of the following expressions whether it represents a table, and if so, over which set? a. P∪S b. P∩S CHAPTER 5 ■ TABLES AND DATABASE STATES1 14 745 1CH05.qxd 5 /4/ 07 3:57 PM Page 1 14