Applied Mathematics for Database Professionals phần 5 pps

It states that no employee can earn more than a fifth of the departmental salary budget ( of the department where he or she is employed). Another way of formally specifying this is as follows: ( ∀t∈EMP1⊗DEP1: t(sal)≤t(salbudget)/5 ) In this proposition, the expression t(sal)≤t(salbudget)/5 represents a tuple predicate that constrains the tuples in the join. This predicate pattern is commonly found in database designs and is referred to as a tuple-in-join predicate. Definition 6-4 formally specifies it. ■Definition 6-4: Tuple-in-Join Predicate Let T1 and T2 be tables and P a tuple predicate. A predi- cate is a tuple-in-join predicate if it is of the following form: ( ∀t∈T1⊗T2: P(t) ) We say that P constrains tuples in the join of T1 and T2. In the preceding definition, you will typically find that tables T1 and T2 are related via a subset requirement that involves the join attributes. Listing 6-11 demonstrates two more instantiations of a tuple-in-join predicate involving tables EMP1 and DEP1. Listing 6-11. More Tuple-in-Join Predicates Regarding Tables EMP1 and DEP1 P9 := ( ∀e∈EMP1: ( ∀d∈DEP1: e↓{deptno}=d↓{deptno} ⇒ (d(loc)='LOS ANGELES'⇒ e(job)≠'MANAGER') ) ) P10 := ( ∀e∈EMP1: ( ∀d∈DEP1: e↓{deptno}=d↓{deptno} ⇒ (d(loc)='SAN FRANCISCO'⇒ e(job)∈{'TRAINER','CLERK'}) ) ) P9 states that managers cannot be employed in Los Angeles. P10 states that employees working in San Francisco must either be trainers or clerks. Given the sample values EMP1 and DEP1 in Figure 6-10 both propositions are TRUE; there are no managers working in Los Angeles and all employees working in San Francisco—there are none—are either trainers or clerks. In this section, we’ve defined the tuple-in-join predicate to involve only two tables. How- ev er, it is often meaningful to combine thr ee or even more tables with the join operator. Of course, tuples in these joins can also be constr ained by a tuple pr edicate . H ere is the pattern of a tuple-in-join predicate involving three tables ( T1, T2, and T3): ( ∀t1∈T1: ( ∀t2∈T2: ( ∀t3∈T3: (t1↓A=t2↓A ∧ t2↓B=t3↓B) ⇒ P(t1∪t2∪t3) ) ) ) In this pattern, A represents the set of join attributes for tables T1 and T2, and B represents the set of join attributes for tables T2 and T3. Predicate P represents a predicate whose argu- ment is the tuple in the join. In the next chapter, you’ll see examples of tuple-in-join predicates involving more than two tables. CHAPTER 6 ■ TUPLE, TABLE, AND DATABASE PREDICATES136 7451CH06.qxd 5/14/07 10:37 AM Page 136 Chapter Summary T his 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. •A tuple predicate is a predicate with one parameter of type tuple. It can be used to accept (or reject) tuples based on the combination of attribute values that they hold. •A table predicate is a predicate with one parameter of type table. It can be used to accept (or reject) tables based on the combination of tuples that they hold. •A database (multi-table) predicate is a predicate with one parameter of type database state. It can be used to accept (or reject) database states based on the combination of tables that they hold. • Five patterns of table and database predicates are commonly found in database designs: unique identification, subset requirement, specialization, generalization, and tuple-in-join predicates. •A unique identification predicate is a table predicate of the following form (T represents a table): ( ∀t1,t2∈T: t1↓A=t2↓A ⇒ t1=t2 ). In this expression, A represents the set of attributes that uniquely identify tuples in table T. •A subset requirement predicate is a predicate of the following form (T1 and T2 represent tables): { t1↓A| t1∈T1 } ⊆ { t2↓A| t2∈T2 }. In this expression, A often represents the set of attributes that uniquely identify tuples in table T2. •A specialization predicate is a database predicate of the following form (T1 and T2 rep- resent tables): { t1↓A| t1∈T1 ∧ P(t1) } = { t2↓A| t2∈T2 }. In this expression, A represents the set of attributes that uniquely identify tuples in both tables T1 and T2. Predicate P is a predicate specifying a subset of table T1. We say that “ T2 is a specialization of T1.” T2 is considered to hold additional information for the subset of tuples in T1 specified by predicate P. • If a given table, say T, has more than one specialization such that for every tuple in T there exists exactly one tuple in exactly one of the specialization tables that holds addi- tional information for that tuple, then table T is referred to as the generalization of the specializations. • A tuple-in-join pr edicate is a predicate of the follo wing form ( T1 and T2 r epresent tables): ( ∀t1∈T1: ( ∀t2∈T2: t1↓A=t2↓A ⇒ P(t1∪t2) ) ). In this expression, A represents the set of attributes that is typically involved in a subset requirement between tables T1 and T2. Predicate P is a tuple predicate. CHAPTER 6 ■ TUPLE, TABLE, AND DATABASE PREDICATES 137 7451CH06.qxd 5/14/07 10:37 AM Page 137 Exercises 1. Evaluate the truth value of the following propositions (PAR1 was introduced in Figure 6-1): a. ( ∀p∈PAR1: mod(p(partno),2)=0 ⇒ p(price)≤15 ) b. ¬( ∃p∈PAR1: p(price)≠5 ∨ p(instock)=0 ) c. #{ p | p∈PAR1 ∧ ( p(instock)>10 ⇒ p(price)≤10 ) } = 6 2. Let A be a subset of the heading of PAR1. Give all possible values for A such that “A is uniquely identifying in PAR1” (only give the smallest possible subsets). 3. Specify a subset requirement predicate from CLK1 and EMP1 stating that the manager of a clerk must be an employee whose job is 'MANAGER'. 4. Formally specify the fact that table EMP1 is a generalization of tables TRN1, MAN1, and CLK1. 5. In EMP1 the job attribute is a (redundant) inspection attribute. Formally specify the fact that EMP1 is a generalization of TRN1, MAN1, and CLK1 given that EMP1 does not have this attribute. 6. Using rewrite rules for implication and quantifiers that have been introduced in Part 1, give at least three alternative formal expressions for proposition P12. 7. Using the semantics introduced by tables EMP1 and CLK1, give a formal specification for the database predicate “A manager of a clerk must work in the same department as the clerk.” Is this proposition TRUE for tables EMP1 and CLK1? 8. Using the semantics introduced by tables DEP1, EMP1, and CLK1, give a formal specifica- tion for the database predicate “A manager of a clerk must work in a department that is located in Denver.” I s this pr oposition TRUE for these tables? CHAPTER 6 ■ TUPLE, TABLE, AND DATABASE PREDICATES138 7451CH06.qxd 5/14/07 10:37 AM Page 138 Specifying Database Designs In this chapter, we’ll give a demonstration of how you can formally specify a database design. Formalizing a database design specification has the advantage of avoiding any ambiguity in the documentation of not only the database structure but, even more importantly, of all involved data integrity constraints. ■Note Within the IT industry, the term business rules is often used to denote what this book refers to as data integrity constraints. However, because a clear definition of what exactly is meant by business rules is seldom given, we cannot be sure about this. In this book, we prefer not to use the term business rules, but instead use data integrity constraints. In this chapter, we’ll give a clear definition of the latter term. We’ll give the formal specification of a database design by defining the data type of a data- base variable. This data type—essentially a set—holds all admissible database states for the database variable and is dubbed the database universe. You’ll see that a database universe can be constructed in a phased (layered) manner, which along the way provides us with a clear classification schema for data integrity con- straints. First, you define what the vocabulary is. What are the things, and aspects of these things in the real world, that you want to deal with in your database? Here you specify a name for each table str ucture that is deemed necessary, and the names of the attributes that the table structure will have. We’ll introduce an example database design to demonstrate this. The vocabulary is formally defined in what is called a database skeleton. A good way to further explain the meaning of all attr ibutes (and their correlation) is to pr o vide the e xternal predicate for each table structure; this is a natural language sentence describing the meaning and corre- lation of the involved attributes. G iven the database skeleton, w e then define for each attribute the set of admissible attrib- ute values. This is done by introducing a characterization for each table structure. You were introduced to the concept of a characterization in Chapter 4. Y ou ’ ll then use these characterizations as building blocks to construct the set of admissi- ble tuples for each table. This is called a tuple universe, and includes the formal specification of tuple constraints. Then, y ou ’ ll use the tuple universes to build the set of admissible tables for each table str uctur e . This set is called a table univ erse , and can be consider ed the data type of a table 139 CHAPTER 7 7451CH07.qxd 5/15/07 9:43 AM Page 139 variable. The definition of a table universe will include the formal specification of the relevant t able constraints . The last section of this chapter shows how you can bring together the table universes in the definition of the set of admissible database states, which was the goal set out for this chap- ter: to define a database universe. In this phase you formally specify the database (multi-table) constraints . Because the example database universe presented in this chapter has ten table structures, we’ll introduce you to ten characterizations, ten tuple universes, and ten table universes. This, together with the explanatory material provided, makes this chapter a rather big one. How- ever, the number of examples should provide you with a solid head start to applying the formal theory, and thereby enable you to start practicing this methodology in your job as a database professional. You can find a version of this example database design specification that includes the design’s bare essentials in Appendix A. After the “Chapter Summary” section, a section with exercises focuses primarily on changing or adding constraint specifications in the various layers of the example database universe introduced in this chapter. Documenting Databases and Constraints Because you’re reading this book, you consider yourself a database professional. Therefore, it’s likely that the activity of specifying database designs is part of your job. You’ll probably agree that the process of designing a database roughly consists of two major tasks: 1. Discovering the things in the real world for which you need to introduce a table struc- ture in your database design. This is done by interviewing and communicating with the users and stakeholders of the information system that you’re trying to design. 2. Discovering the data integrity constraints that will control the data that’s maintained in the table structures. These constraints add meaning to the table structures intro- duced in step one, and will ultimately make the database design a satisfactory fit for the reality that you’re modeling. The application of the math introduced in Part 1 of this book is primarily geared to the second task; it enables you to formally specify the data integrity constraints. We’re convinced that whenever you design a database, you should spend the biggest part of time on designing the involved data integrity constraints. Accurately—that is, unambiguously—documenting these data integrity constraints can spell the difference between your success and failure. Still, today documenting data integrity constraints is most widely done using natural lan- guage, which often produces a quick dive into ambiguity. If you use plain English to express data integrity constraints, you’ll inevitably hit the problem of how the English sentence maps, unambiguously, into the table structures . Different programmers (and users alike) will inter- pr et such sentences differently, because they all try to convert these into something that will map into the database design. Programmers then code their perception of the constraint (not necessarily the specifier’s). The sections that follow will demonstrate that the logic and set theory introduced in Part 1 lends itself excellently to capturing database designs with their integrity constraints in a for- mal manner. Formal specifications of data integrity constraints tell you exactly how they map into the table structures. You’ll not only avoid the ambiguity mentioned earlier, but moreover CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS140 7451CH07.qxd 5/15/07 9:43 AM Page 140 you’ll get a clear and expert view of the most important aspect of a database: all involved data i ntegrity constraints. ■Note Some of you will be surprised, by the example that follows, of how much of the overall specification of an information system actually sits in the specification of the database design. A lot of the “business logic” involved in an information system can often be represented by data integrity constraints that map into the underlying table structures that support the information system. The Layers Inside a Database Design Having set the scene, we’ll now demonstrate how set theory and logic enable you to get a clear and professional view of a database design and its integrity constraints. The next two sections introduce you (informally) to a particular way of looking at the quintessence of a database design. This view is such that it will enable a layered set-theory specification of a database design. Top-Down View of a Database A database (state) at any given point in time is essentially a set of tables. Our database, or rather our database variable, holds the current database state. In the course of time, transac- tions occur that assign new database states to the database variable. We need to specify the set of all admissible database states for our database variable. This set is called the database universe , and in effect defines the data type for the database variable. Viewed top down, within the database universe for a given database design that involves say n table structures, you can observe the following: • Every database state is an admissible set of n tables (one per table structure), where • every table is an admissible set of tuples, where • every tuple is an admissible set of attribute-value pairs, where • every value is an admissible value for the given attribute. Because all preceding layers are sets, you can define them all mathematically using set theory. Through logic (by adding embedded predicates) you define exactly what is meant by admissible in each layer; here the data integrity constraints enter the picture. So how do you specify, in a formal way, this set called the database universe? This is done in a bottom-up approach using the same layers introduced earlier. First, you define what your vocabulary is: what are the things, and aspects of them in the real world, that you want to deal with in your database? In other words, what table structures do you need, and what attributes does each table structure have? This is formally defined in what is called a database skeleton. For each attribute introduced in the database skeleton, you then define the set of admissible attribute values. You’ve already been introduced to this; in this phase all characterizations (one per table structure) are defined. CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS 141 7451CH07.qxd 5/15/07 9:43 AM Page 141 You then use the characterizations as building blocks to build (define) for each table s tructure the s et of admissible tuples . This involves applying the generalized product operator (see Definition 4-7) and the introduction of tuple predicates. The set of admissible tuples is called a tuple universe. You can then use the tuple universes to build for each table structure the set of admissible tables , which is called a table universe. You’ll see how this can be done in this chapter; it involves applying the powerset operator and introducing table predicates. In the last phase you define the set of admissible database states—the database universe— using the previously defined table universes. This methodology of formally defining the data type of a database variable was developed by the Dutch mathematician Bert De Brock together with Frans Remmen in the 1980s, and is an elegant method of accurately defining a database design, including all relevant data integrity constraints. The references De grondslagen van semantische databases (Academic Service, 1990, in Dutch) and Foundations of Semantic Databases (Prentice Hall, 1995) are books written by Bert De Brock in which he introduces this methodology. Classification Schema for Constraints In this bottom-up solid construction of a database universe, you explicitly only allow sets of admissible values at each of the levels described earlier. This means that at each level these sets must satisfy certain data integrity constraints. The constraints specify which sets are valid ones; they condition the contents of the sets. This leads straightforwardly to four classes of data integrity constraints: • Attribute constraints: In fact, these are the attribute value sets that you specify in a characterization. You can argue whether the term “constraint” is appropriate here. A characterization simply specifies the attribute value set for every attribute (without further constraining the elements in it). However, the attribute value set does constrain the values allowed for the attribute. ■Note We’ll revisit this matter in Chapter 11 when the attribute value sets are implemented in an SQL da tabase management system. • T uple constraints : These are the tuple pr edicates that y ou specify inside the definition of a tuple univ erse. The tuple pr edicates constrain combinations of values of different attributes within a tuple. Sometimes these constraints are referred to as inter-attribute constr aints . Y ou can specify them without referring to other tuples. For instance, here’s a constraint betw een attr ibutes Job and Salary of an EMP (employ ee) table str uctur e: “Employees with job President earn a monthly salary greater than 10000 dollars.” • Table constraints: These are table predicates that you specify inside the definition of a table universe. The table predicates constrain combinations of different tuples within the same table . S ometimes these constr aints are referred to as inter -tuple constr aints . You can specify them without referring to other tables. For instance: “No employee can earn a higher monthly salary than his/her manager” (here we assume the presence of a Manager attr ibute in the EMP table str uctur e that references the employee’s manager). CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS142 7451CH07.qxd 5/15/07 9:43 AM Page 142 • Database constraints: These are database predicates that you specify inside the defini- t ion of a database universe. The database predicates constrain combinations of tables for different table structures. Sometimes these constraints are referred to as inter-table constraints. You can only specify them while referring to different table structures. For instance, there’s the omnipresent database constraint between the EMP and DEPT table structures: each employee must work for a known department. These four classes of constraints accept or reject a given database state. They condition database states and are often referred to as static (or state) constraints; they can be checked within the context of a (static) database state. In actuality there is one more constraint class. This is the class of constraints that limit database state transitions (on grounds other than the static constraints). Predicates specifically conditioning database state transitions are referred to as dynamic (or state transition) constraints. We’ll cover these separately in Chapter 8. Because the preceding classification scheme is driven by the scope of data that a con- straint deals with, it has the advantage of being closely related to implementation issues of constraints. When you implement a database design in an SQL DBMS, you’ll be confronted with these issues, given the poor declarative support for data integrity constraints in these systems. This lack of support puts the burden upon you to develop often complex code that enforces the constraints. Chapter 11 will investigate these implementation challenges of data integrity constraints using the classification introduced here. Specifying the Example Database Design We’ll demonstrate the application of the theory presented in Part 1 of this book through an elaborate treatment of a database design that consists of ten table structures. We comment up front that this database design merely serves as a vehicle to demonstrate the formal specification methodology; it is explicitly not our intention to discuss why the design is as it is.We acknowledge that some of the assumptions on which this design is based could be questionable. Also we mention up front that this design has two hacks, probably by some of you considered rather horrible. We’ll indicate these when they are introduced. Figure 7-1 shows a diagram of the ten table structures (represented by boxes) and their mutual relationships (represented by arrows). Each of the arrows indicates a subset require- ment predicate that is applicable between a pair of table structures. Figure 7-1. Picture of example database CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS 143 7451CH07.qxd 5/15/07 9:43 AM Page 143 ■Note The majority of these arrows represent what is often called many-to-one relationships and will eventually end up as foreign keys during the implementation phase in an SQL DBMS. However, this need not always be the case, as you will see. The exact meaning of each arrow will be given in the database universe specification where each arrow translates to a database constraint. Our database holds employees (EMP) and departments (DEPT) of a company. Some of the arrows indicate the following: • Every employee works for a department. • Every department is managed by an employee. • Every employee is assigned to a salary grade ( GRD). Employee history ( HIST) records are maintained for all salary and/or “works-for- department” changes; every history record describes a period during which one employee was assigned to a department with a specific salary. We hold additional information for all sales representatives in a separate table structure ( SREP). We hold additional information for employees who no longer work for the company (that is, they have been terminated or they resigned) in TERM. Note that we keep the EMP infor- mation for terminated employees. We also hold additional information for all managed employees ( MEMP); that is, employees who have a manager assigned to them. The database further holds information about courses ( CRS), offerings (OFFR) of those courses, and registrations ( REG) for those course offerings. Some more arrows show the following: • An offering must be taught by a trainer who works for the company. • An offering is for an existing course. • A registration records an employee as an attendee for a course offering. You now have some idea of the information we’re maintaining in this database. In the next section, you’ll find the database skeleton. As mentioned before, it introduces the names of all attributes for every table structure. Together with the table structure names, they form the vocabulary that we have available in our database design. Database Skeleton The names of the things in the real world that we are representing in our database design, including the names of the attributes of interest, are introduced in what is called a database skeleton. We sometimes refer to this as the conceptual skeleton. As you saw in Chapter 5, a database skeleton is represented as a set-valued function. The domain of the skeleton func- tion is the set of table structure names. For each name, this function yields the set of attribute names of that table structure; that is, the heading of that table structure. Our database skeleton DB_S for the example database design is defined in Listing 7-1. Inside the specification of DB_S you see embedded comments (/* */) to clarify further the chosen abbreviations for the table structure and attribute names. CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS144 7451CH07.qxd 5/15/07 9:43 AM Page 144 Listing 7-1. Database Skeleton Definition DB_S := { (EMP; Employees { EMPNO /* Employee number */ , ENAME /* Employee name */ , JOB /* Employee job */ , BORN /* Date of birth */ , HIRED /* Date hired */ , SGRADE /* Salary grade */ , MSAL /* Monthly salary */ , USERNAME /* Username */ , DEPTNO } ) /* Department number */ , (SREP; Sales Representatives { EMPNO /* Employee number */ , TARGET /* Sales target */ , COMM } ) /* Commission */ , (MEMP; Managed Employees { EMPNO /* Employee number */ , MGR } ) /* Manager: employee number */ , (TERM; Terminated Employees { EMPNO /* Employee number */ , LEFT /* Date of leave */ , COMMENTS } ) /* Termination comments */ , (DEPT; Departments { DEPTNO /* Department number */ , DNAME /* Department name */ , LOC /* Location */ , MGR } ) /* Manager: employee number */ , (GRD; Salary Grades { GRADE /* Grade code */ , LLIMIT /* Lower salary limit */ , ULIMIT /* Upper salary limit */ , BONUS } ) /* Yearly bonus */ , (CRS; Courses { CODE /* Course code */ , DESCR /* Course description */ , CAT /* Course category */ , DUR } ) /* Duration of course in days */ , (OFFR; Course Offerings { COURSE /* Code of course */ , STARTS /* Begin date of this offering */ , STATUS /* Scheduled, confirmed, */ , MAXCAP /* Max participants capacity */ , TRAINER /* Trainer: employee number */ , LOC } ) /* Location */ , (REG; Course Registrations { STUD /* Student: employee number */ , COURSE /* Course code */ CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS 145 7451CH07.qxd 5/15/07 9:43 AM Page 145 [...]... states that if there is a limit regarding database professionals, then there cannot be a result with an average score of A for database professionals (regardless of the course), and if there is a limit regarding non -database professionals, then there cannot be a result with an average score of F for non -database professionals This database predicate discards possible database states that were generated by... the shorthand notation for tables 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 169 CHAPTER 7 s SPECIFYING DATABASE DESIGNS Figure 7-4 Enumerative specification of tab_LIMIT using table shorthand notation Given these two table structures, we can now take a look at a database state Figure 7 -5 displays a database state, named DBS1, that involves the RESULT and LIMIT table structures Figure 7 -5 Database state DBS1... average score for the logic course should always be higher than the average score for the set theory course within a population 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 159 CHAPTER 7 s SPECIFYING DATABASE DESIGNS The first conjunct in the universal quantification—r1(POPULATION) = r2(POPULATION)—specifies this A user can take for granted that the average scores for logic are always higher than those for set theory,... state DBS1 In universe DB_U2, the database constraint will discard a total of 26 (possible) database states You might want to verify this for yourself 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 171 CHAPTER 7 s SPECIFYING DATABASE DESIGNS We’ll often specify the database constraints in a slightly different manner Instead of specifying a database predicate with one parameter of type database state, we’ll specify... evaluated by attendee */ /* 1 -5: regular evaluation values (from 1=bad to 5= excellent) */ , ( EVAL; [-1 5] ) } 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 151 CHAPTER 7 s SPECIFYING DATABASE DESIGNS Listing 7-11 Characterization chr_HIST chr_HIST := { ( EMPNO; , ( UNTIL; , ( DEPTNO; , ( MSAL; } EMPNO_TYP date DEPTNO_TYP SALARY_TYP ) ) ) ) Note that in Listing 7-9 the attribute value set for attribute TRAINER includes... (h3) for the same employee that “sits in between” the other two tuples Again, the formal specification for this constraint leaves no room for ambiguity This concludes the treatment of the table universes of the example database design The next section moves on the definition of the database universe This definition will build on the table universes and will formally specify the database constraints Database. .. introduced by database skeleton DB_S dom(tdept1) = {DEPTNO, DNAME, LOC, MGR} = DB_S(DEPT) And, for every attribute, tdept1 yields a value from the corresponding attribute value set, as introduced by the characterization for the DEPT table structure: 151 7 451 CH07.qxd 152 5/ 15/ 07 9:43 AM Page 152 CHAPTER 7 s SPECIFYING DATABASE DESIGNS • tdept1(DEPTNO) = 10, which is an element of chr_DEPT(DEPTNO) • tdept1(DNAME)... } 169 7 451 CH07.qxd 170 5/ 15/ 07 9:43 AM Page 170 CHAPTER 7 s SPECIFYING DATABASE DESIGNS Set function DBCHR is called a database characterization It characterizes a database in that it introduces the names of the table structures that are involved in a database design and attaches to them the relevant table universes (the sets that hold the admissible tables for each table structure) s Note Database. .. AVG_SCORE; {'A','B','C','D','E','F'} } ) = Non Database Professionals */ ) ) The three attribute value sets represent the attribute constraints for the RESULT table structure If you apply the generalized product ∏ to chr_RESULT, you get the following set of possible tuples for the RESULT table structure: 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 153 CHAPTER 7 s SPECIFYING DATABASE DESIGNS ∏(chr_RESULT) = { { (POPULATION;... world Database predicates that constrain the elements in a database universe are called database constraints s Note Given the database constraint of universe DB_U2, state DBS1 shown in Figure 7 -5 is not an admissible state (that is, DB_U2∉DBS1); the RESULT table holds a tuple that has an average score of A for database professionals This is not allowed given the contents of the LIMIT table in database . "bandwidth" of at least 50 0 dollars */ g(LLIMIT) ≤ g(ULIMIT) - 50 0 ∧ CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS 155 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 155 . attendee */ /* 1 -5: regular evaluation values (from 1=bad to 5= excellent) */ , ( EVAL; [-1 5] ) } CHAPTER 7 ■ SPECIFYING DATABASE DESIGNS 150 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 150 Listing 7-11 SPECIFYING DATABASE DESIGNS142 7 451 CH07.qxd 5/ 15/ 07 9:43 AM Page 142 • Database constraints: These are database predicates that you specify inside the defini- t ion of a database universe. The database