In Chapter 6 you were introduced to tuple, table, and database predicates. These predicates deal with data in an increasing scope order: attribute values within a single tuple, tuples within a single table, and tables within a single database state.
The section “More Data Integrity Predicates” continues down this path of increasing scope by introducing the concept of a state transition predicate. A state transition predicate deals with a pair of database states that are referred to as the begin state and the end state. We’ll use state transition predicates to define the admissible database state transitions (otherwise known as transactions) for a database design.
In the section “State Transition Constraints,” you’ll discover that a transaction can be modeled as an ordered pair of two database states: the database state that exists at the start of the transaction, and the database state that exists at the end of the transaction, which is the state that the transaction results into.
We’ll define the notion of a state transition universe: the set that holds all admissible transactions for a database design. To define a state transition universe, you’ll define state transition predicates that represent the state transition constraints in the database design.
The section “State Transition Constraints” concludes with a specification of the state transition universe for the example database design that was introduced in Chapter 7; it includes seven state transition constraints for this database design. The example state transition universe is also available in Appendix A.
As usual, you’ll find a “Chapter Summary” at the end, followed by an “Exercises” section.
More Data Integrity Predicates
In the previous chapter you were introduced to four classes of data integrity constraints: attribute, tuple, table, and database constraints. These four classes of constraints accept or reject a given database state. They can be checked within the context of a database state and are referred to as static constraints. In the real world there is often a requirement to prohibit certain database state transitions on grounds other than the static constraints. These state transition limiting constraints are referred to as dynamic (or state transition) constraints.
A Simple Example
A classical illustration of a state transition constraint is the requirement that the salary of an employee is not allowed to decrease. As you can see, this requirement cannot be checked within the context of a single database state; you require the context of a transaction that changes the state of a database. To check this requirement, you need to inspect the salary values in the database state that exists at the start of the transaction (its begin state), as well as inspect the salary values in the database state that exists at the end of the transaction (its end state).
Note You’ll see shortly that we’ll use these two database states—the begin state and the end state—to characterize a transaction.
Let’s demonstrate this with an example using the database design that was introduced in the previous chapter. Figure 8-1 shows two employee tables E1 and E2.
Figure 8-8. Tables E1 and E2
These two tables differ only in three attribute values.
Let’s assume that a given transaction, say TX1, starts off in a begin state that contains E1 and results in an end state that contains E2. As you can see in Figure 8-1, TX1 has apparently decreased the salary of employee 101 (from 8200 to 7900), and also changed the employee’s salary grade. TX1 has also increased the salary of employee 105 (from 3000 to 4000). Transaction TX1 has not changed the salary of all other employees.
Note Obviously, TX1 violates the state transition constraint stating that salaries are not allowed to be decreased.
Now let’s investigate how you can formally specify that the salary of an employee is not allowed to decrease. Transaction TX1 violates this state transition requirement because there exists a combination of an employee tuple (say e1) in E1 and an employee tuple (say e2) in E2 that both concern the same employee—that is, that correspond on the empno attribute—and are such that the msal value in e2 is lower than the msal value in e1.
Assume that dbs1 is the begin state of transaction TX1and dbs2 is its end state. Note that this means that the expression dbs1(EMP) evaluates to E1 and expression dbs2(EMP) evaluates to E2. Take a look at the proposition in Listing 8-1.
Listing 8-1. A Proposition Concerning Database States dbs1 and dbs2
prop1 :=
(∀e1∈dbs1(EMP): (∀e2∈dbs2(EMP): e1(empno) = e2(empno) ⇒ e1(msal) ≤ e2(msal) ) )
This proposition states that there cannot exist a combination of a tuple in E1 and a tuple in E2 such that they correspond on the empno attribute, and the msal value in the E1 tuple is greater than the msal value in the E2 tuple. This precisely reflects our state transition requirement.
This type of transition constraint (at the attribute level) is common, and can also be specified in another way: by joining the table in the begin state with its corresponding version in the end state such that all attribute values (old and new) are available, and then restricting the attribute values in the resulting tuples in this join.
Note Loosely speaking, such transition constraints can be considered dynamic tuple-in-join constraints.
Listing 8-2 shows an alternative way to formally specify this requirement; it joins the EMP table in the begin state (dbs1) with the EMP table in the end state (dbs2).
Listing 8-2. Alternative Specification for Our State Transition Requirement
prop2 :=
( ∀e∈((dbs1(EMP)⇓{empno,msal})◊◊{(empno;empno),(old_msal;msal)})⊗
((dbs2(EMP)⇓{empno,msal})◊◊{(empno;empno),(new_msal;msal)}):
e(old_msal) ≤ e(new_msal) )
We now use the join operator (⊗) together with table projection (⇓) and attribute renaming (◊◊). In this specification both E1 and E2 are first projected on the empno and msal attributes. Then the msal attribute in (the projection of) E1 is renamed to old_msal, and the msal attribute in (the projection of) E2 is renamed to new_msal. The resulting two tables can now be joined with the join operator. The table resulting from this join is a table over heading {empno,old_msal,new_msal}. For all tuples in this table, the old_msal value should be smaller than or equal to the new_msal value.
Figure 8-2 clarifies the preceding explanation by displaying the intermediate tables and the final table resulting from the subexpressions inside prop2.
Figure 8-2. Intermediate tables and final table for expression prop2
State Transition Predicates
Continuing from Chapter 6 where the concepts of a tuple, table, and database predicate were introduced, we now further increase the scope of data that a data integrity predicate can deal with by defining the notion of a state transition predicate.
State transition predicates deal with a pair of database states. These predicates have two parameters, both of type database state; the first parameter is referred to as the begin state and the second parameter the end state. In the next section, we’ll use state transition predicates to define the admissible state transitions for a database design. Only those transactions, whose begin and end state transform all state transition predicates into true propositions, are considered valid (or admissible) transactions.
Note that the propositions in Listings 8-1 and 8-2 also deal with a pair of database states: the two given database states dbs1 and dbs2. Now take a look at the state transition predicates in Listing 8-3. These are the “predicate versions” of the propositions in Listings 8-1 and 8-2.
Listing 8-3. Two State Transition Predicates
STP1(B,E) := ( ∀e1∈B(EMP), e2∈E(EMP): e1(empno)=e2(empno) ⇒ e1(msal) ≤ e2(msal) )
STP2(B,E) := ( ∀e∈((B(EMP)⇓{empno,msal})◊◊{(empno;empno),(old_msal;msal)})⊗
((E(EMP)⇓{empno,msal})◊◊{(empno;empno),(new_msal;msal)}):
e(old_msal) ≤ e(new_msal) )
When you supply database states dbs1 and dbs2 as values for parameters B and E, respectively, then these state transition predicates will transform into the propositions listed in Listings 8-1 and 8-2.
STP1(dbs1,dbs2) = prop1
STP2(dbs1,dbs2) = prop2
We require that state transition predicates cannot be decomposed into multiple conjuncts, just like tuple, table, and database predicates. If you can rewrite a given state transition predicate ST(B,E) into an expression of the form STa(B,E) ∧ STb(B,E), then you are in fact dealing with two state transition predicates.
In the remainder of this book, we’ll also require that a state transition predicate—say ST(B,E)—cannot be rewritten into a predicate of either of the following two forms:
P(B)
P(E)
In these expressions, P represents a database predicate; that is, a predicate that inspects a single database state (either B or E in the preceding cases). This means that we require a state transition predicate to involve at least one table from the begin state as well as at least one table from the end state. That’s because, if the predicate involves only tables from one database state (either the begin or the end state), then the predicate will reflect a static constraint, not a state transition constraint.
As you’ll see in the examples given in the next section, state transition predicates typically involve the tables from the begin and end states of the same table structure. Instead of specifying a state transition predicate with two parameters of type database state, we’ll often specify them with two or more parameters of type table. To illustrate this, Listing 8-4 respecifies the state transition predicates of Listing 8-3 in this way. Parameters EMPB and EMPE are of type table; the idea is for parameter EMPB to accept the employee table state that exists at the beginning of a transaction, and for parameter EMPE to accept the employee table state that exists at the end of a transaction.
Listing 8-4. Alternative Specification of State Transition Predicates STP1 and STP2
STP1(EMPB,EMPE) :=
( ∀e1∈EMPB, e2∈EMPE: e1(empno) = e2(empno) ⇒ e1(msal) ≤ e2(msal) )
STP2(EMPB,EMPE) :=
( ∀e∈((EMPB⇓{empno,msal})◊◊{(empno;empno),(old_msal;msal)})⊗
((EMPE⇓{empno,msal})◊◊{(empno;empno),(new_msal;msal)}):
e(old_msal) ≤ e(new_msal) )
In the next section, we’ll use state transition predicates to formally specify the state transition constraints for a database design.
State Transition Constraints
In this section we’ll introduce you to the concept of a state transition universe. The state transition constraints will be specified as embedded state transition predicates in the formal definition of a state transition universe.
State Transition Universe
To formally specify the state transition constraints for a database design, we’ll specify the set of all admissible transactions for the database design. You can model a transaction as an ordered pair of its begin and end states; the first coordinate in the ordered pair represents the begin state, and the second coordinate of the ordered pair represents the end state.
You can then specify the set of all admissible transactions as a set of such ordered pairs. Every ordered pair in this set is of the form (B;E), where both B and E represent a valid database state (that is, they are elements of the database universe for the database design). This set of ordered pairs is called the state transition universe. If (B;E) is an element of the state transition universe, then the transaction that transforms state B into state E is allowed.
To illustrate this, let’s assume you need to specify a state transition universe for some database design whose database universe only has four database states. We’ll name these database states s1 through s4. Let’s further assume that you only allow a transaction if it implements one of the following state transitions:
s1 to s2
s1 to s3
s1 to s4
s2 to s3
s2 to s4
s3 to s4
s4 to s1
In this database design, only the preceding seven distinct transactions are allowed. You can visualize these seven transactions through a directed graph on the four database states. Figure 8-3 illustrates this way of looking at a state transition universe.
Figure 8-3. Representing a state transition universe through a directed graph
Listing 8-5 shows a set-theory way to specify this state transition universe; every arrow in the directed graph maps to an ordered pair.
Listing 8-5. State Transition Universe Containing Seven Transactions
{ (s1;s2), (s1;s3), (s1;s4)
,(s2;s3), (s2;s4)
,(s3;s4)
,(s4;s1) }
Of course, for real-world database designs you can’t specify a state transition universe in this enumerative way, due to the vast amount of transactions that would need to be enumerated. You’ll have to resort to the predicative way of specifying the set of admissible transactions.
You can formally specify a state transition universe for a given database design in a predicative way by first constructing the Cartesian product of the database universe with itself. This Cartesian product holds every possible transition from an admissible database state to another admissible database state (modeled as an ordered pair).
Note If the database universe for a given database design has cardinality n, then a total of n*n distinct transactions can be identified. However, state transition constraints won’t allow all of these.
By specifying state transition predicates, you can then narrow down this set of possible transitions to a set that only holds admissible transitions. Listing 8-6 shows the specification template for a state transition universe.
Listing 8-6. State Transition Universe Specification Template
STU:= { TX|TX∈DBU×DBU ∧
STC1(π1(TX),π2(TX)) ∧ STC2(π1(TX),π2(TX)) ∧ ... ∧ STCn(π1(TX),π2(TX)) }
In this template, DBU represents the relevant database universe and STC1, STC2,..., STCn represent state transition predicates. Expression π1(TX) represents the begin state of TX, and π2(TX) represents the end state of TX. We say that state transition predicates STC1through STCn are the state transition constraints of STU.
Another way of defining state transition universe STUis as follows:
{ (B;E) | B∈DBU ∧ E∈DBU ∧
STC1(B,E) ∧ STC2(B,E) ∧ ... ∧ STCn(B,E) }
This set holds all ordered pairs (B;E) where B and E represent admissible database states. The ordered pairs where states B and E satisfy all state transition constraints represent admissible transactions.
Completing the Example Database Design
Let’s now demonstrate all this by specifying state transition constraints for the example database design that was introduced in the previous chapter. Listing 8-7 introduces the formal specification of state transition universe ST_UEX. As you can see, it builds on the DB_UEX database universe that was specified in Chapter 7. The definition of ST_UEX introduces the state transition constraints for our example database design. This definition specifies them by name only. In Listing 8-8, you’ll find the formal specification for each of these named constraints.
Note In Listing 8-7 we are specifying the state transition predicates in the alternative way: as predicates with parameters of type table.
Listing 8-7. State Transition Universe ST_UEX
ST_UEX := { (b;e) | b∈DB_UEX ∧ e∈DB_UEX ∧
∧ STC1(b(EMP),e(EMP))
∧ STC2(b(OFFR),e(OFFR))
∧ STC3(b(OFFR),e(OFFR))
∧ STC4(b(HIST),e(HIST))
∧ STC5(b(HIST),b(EMP),e(HIST),e(EMP))
∧ STC6(b(REG),e(REG))
∧ STC7(b(REG),e(REG)) }
State transition constraint STC1 involves the employee table structure. Constraints STC2 and STC3 involve the offering table structure. Constraint STC4 involves the history table structure. Constraint STC5 involves two table structures: history and employee. Finally, constraints STC6 and STC7 involve the registration table structure.
Listing 8-8 supplies the formal definitions for these seven state transition constraints. You’ll find an elaboration on each of these in the following section.
Note Often, state transition constraints inspect more than just the begin and end state of a transaction. Other data items available within the context of a transaction—and typically offered by most DBMSes—are the current system date/time (environment variable sysdate) and the username of the currently logged in user (environment variable user). Requirements that need to reference any of these transactional environment variables will always map to state transition constraints. Static constraints inherently cannot reference the context of a transaction. Constraints STC5 and STC7 specified in Listing 8-8 are examples of this fact; both reference variable sysdate.
Listing 8-8. The Seven State Transition Constraints of ST_UEX
STC1(EMPB,EMPE) :=
/* Monthly salary can only increase */
( ∀e1∈EMPB, e2∈EMPE: e1(EMPNO) = e2(EMPNO) ⇒ e1(MSAL) ≤ e2(MSAL) )
STC2(OFFRB,OFFRE) :=
/* New offerings must start with status SCHED */
( ∀o1∈OFFRE⇓{COURSE,STARTS} − OFFRB⇓{COURSE,STARTS}:
{ o2(STATUS) | o2∈OFFRE ∧ o2↓{COURSE,STARTS} = o1↓{COURSE,STARTS} }
= 'SCHD' )
STC3(OFFRB,OFFRE) :=
/* Valid offering status transitions are: */
/* SCH -> CONF, SCH -> CANC, CONF -> CANC */
( ∀o1∈OFFRB, o2∈OFFRE:
(o1↓{COURSE,STARTS} = o2↓{COURSE,STARTS} ∧ o1(STATUS) ≠ o2(STATUS))
⇒
(o1(STATUS);o2(STATUS)) ∈
{ ('SCHD';'CONF'), ('SCHD';'CANC'), ('CONF';'CANC') } )
STC4(HISTB,HISTE) :=
/* No updates allowed to history records*/
( ∀h1∈HISTB, h2∈HISTE:
h1↓{EMPNO,UNTIL} = h2↓{EMPNO,UNTIL}
⇒
( h1(DEPTNO) = h2(DEPTNO) ∧ h1(MSAL) = h2(MSAL) ) )
STC5(HISTB,EMPB,HISTE,EMPE) :=
/* New history records must accurately reflect employee updates*/
( ∀h∈(HISTE⇓{EMPNO,UNTIL} − HISTB⇓{EMPNO,UNTIL})⊗HISTE:
h(UNTIL) = sysdate ∧
( ∃e1∈EMPB, e2∈EMPE:
e1↓{EMPNO,MSAL,DEPTNO} = h↓{EMPNO,MSAL,DEPTNO} ∧
e2(EMPNO) = h(EMPNO) ∧
( e2(MSAL) ≠ e1(MSAL) ∨ e2(DEPTNO) ≠ e1(DEPTNO) ) ) )
STC6(REGB,REGE) :=
/* New registration tuples must start with EVAL = -1*/
( ∀r1∈(REGE⇓{STUD,STARTS} − REGB⇓{STUD,STARTS})⊗REGE: r1(EVAL) = -1 )
STC7(REGB,REGE) :=
/* Transitions for evaluation must be valid */
/* and cannot occur before start date of offering */
( ∀r1∈REGB, r2∈REGE:
(r1↓{STUD,STARTS} = r2↓{STUD,STARTS} ∧ r1(EVAL) ≠ r2(EVAL))
⇒
( ( r1(EVAL) = -1 ∧ r2(EVAL) = 0 ∧ r2(STARTS) ≤ sysdate ) ∨
( r1(EVAL) = 0 ∧ r2(EVAL) ∈ {1,2,3,4,5} ) ) )
State transition constraint STC1 shows yet another way to specify the classical “salary cannot be decreased” requirement. You can derive it directly from STP1 in Listing 8-4 by rewriting the existential quantifier into a universal quantifier, then applying De Morgan, and finally transforming a disjunction into an implication.
Constraints STC2 and STC3 deal with the value transitions that are allowed for the STATUS attribute in the OFFR table design. Newly inserted course offerings should always have status 'SCH' (scheduled); this is covered by STC2. The status of an existing offering is allowed to change from scheduled to 'CONF' (confirmed), or from scheduled to 'CANC' (canceled). Finally, confirmed offerings can change into canceled offerings too. These status changes are covered by STC3.
The way STC2 mandates the status value of new offerings is as follows. It first constructs the projection of the OFFR table in the end state on the uniquely identifying attributes (COURSE and STARTS). It then does the same for the OFFR table in the begin state. The difference of these two projected tables contains tuples that identify the newly inserted offerings. The universally quantified predicate then fetches—from the OFFR table in the end state—and chooses the STATUS value of such a new offering and requires it (the STATUS value) to be equal to 'SCH'.
STC3 inspects all combinations of corresponding OFFR tuples from the begin state and the end state. The combination is performed with the uniquely identifying attributes. It then requires that for every such tuple combination, either the STATUS value has not changed, or it has changed according to one of the admissible value transitions described earlier.
Another slightly different way to specify constraint STC3 is shown in Listing 8-9.
Listing 8-9. Alternative Specification for STC3
( ∀o1∈OFFRB, o2∈OFFRE:
( o1↓{COURSE,STARTS} = o2↓{COURSE,STARTS} ∧ o1(STATUS) ≠ o2(STATUS) )
⇒
( ( o1(STATUS) = 'SCH' ∧ o2(STATUS) = 'CONF' ) ∨
( o1(STATUS) = 'SCH' ∧ o2(STATUS) = 'CANC' ) ∨
( o1(STATUS) = 'CONF' ∧ o2(STATUS) = 'CANC' ) ) )
Here we’ve employed the following rewrite rule (which is left as an exercise at the end of this chapter):
(P ⇒ (Q ∨ R) ) ⇔ ( (P ¬Q) ⇒ R)
In the same way as STC3, state transition constraint STC4 combines HIST tuples from the begin and the end state, and requires that neither the DEPTNO nor the MSAL attribute value has changed.
Constraint STC5 defines the semantics of the HIST table design. If a transaction changes the DEPTNO or the MSAL attribute value of an EMP tuple, then the same transaction should log a tuple that records the old values of DEPTNO and MSAL in the HIST table. This new HIST tuple should have the UNTIL attribute set to the current system date and time.
STC5 universally quantifies over all newly inserted HIST tuples and requires that within the same transaction, the DEPTNO and MSAL values should correspond with the DEPTNO and MSAL values of the matching EMP tuple found in the begin state. Of course, it also requires that for this particular EMP tuple the end state reflects a change in either the DEPTNO or MSAL attribute values (or both).
The attribute-value set of the EVAL attribute of the REG table design holds seven elements in total: –1, 0, 1, 2, 3, 4, and 5. Their meanings follow:
-1 : Too early to evaluate
0 : Not evaluated or not yet evaluated
1 : Really bad
2 : Bad
3 : Fair
4 : Good
5 : Excellent
The valid value transitions for an evaluation are shown in Figure 8-4.
Figure 8-8. Valid transitions for an evaluation
New registrations must start with an evaluation value of -1 (STC6). As long as a course offering has not started yet, all evaluations should remain holding value -1; it is too early to evaluate the offering.
Once the course offering is “in session,” the trainer decides when the students can evaluate the offering. This is done by setting the evaluation of all registrations for the offering to value 0. Due to the following table constraint introduced in the table universe tab_REG (see Listing 7-34), the trainer must do this within a single transaction.
/* Offering is evaluated, or it is too early to evaluate the offering */
( ∀r1,r2∈R:
( r1↓{COURSE,STARTS} = r2↓{COURSE,STARTS} )
⇒
( ( r1(EVAL) = -1 ∧ r2(EVAL) = -1 ) ∨
( r1(EVAL) ≠ -1 ∧ r2(EVAL) ≠ -1 )
))
A registration value of 0 at this time represents that the student has not yet evaluated the offering. This transition from an evaluation value of -1 to a value of 0 is covered by the first disjunct in the conclusion of the implication in state transition constraint STC7. The disjunct also covers the fact that the transition from -1 to 0 can be done only if the offering has already started (r2(STARTS) ≥ sysdate).
Once the evaluations have been set to 0, the students can then evaluate the offering by changing the 0 into a value in the range of 1 through 5. These value transitions are covered by the second disjunct in the conclusion of the implication of STC7. A student can also choose not to evaluate at all, and have the evaluation stay at value 0 (now representing “not evaluated”).
Did you notice that STC2, STC5, and STC6 demonstrate three different ways to specify a limitation on an attribute value of a newly inserted tuple? You can also write constraint STC6 the “STC2 way” or the “STC5 way”; see Listing 8-10 for this.
Listing 8-10. Alternative Specifications for STC6
STC6(REGB,REGE) :=
( ∀r1∈REGE⇓{STUD,STARTS}− REGB⇓{STUD,STARTS}:
{ r2(EVAL) | r2∈e(REGE) ∧ r2↓{STUD,STARTS} = r1↓{STUD,STARTS} }
=-1 )
STC6(REGB,REGE) :=
( ∀r∈(REGE⇓{STUD,STARTS} − REGB⇓{STUD,STARTS})⊗REGE: r(EVAL) = -1 )
If you’ve carefully studied the specifications in Listing 8-8, you might also have noticed that not all state transition constraints satisfy the requirement that their CNF only have one conjunct. One of the exercises in the “Exercises” section will deal with this.
We conclude this chapter by reaffirming a statement made earlier in Chapter 7: much of the overall specification of an information system actually sits in the specification of the database design. The concept of a state transition universe, being an integral part of the specification of a database design, demonstrates this again. “Business logic” specifically dealing with transactions can often be represented by state transition constraints, and as such this business logic should be part of a database design’s specification.
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 with the exercises in the next section.
- Next to the four classes of constraints introduced earlier (attribute, tuple, table, and database constraints), there is a fifth class of constraints called the state transition constraints.
- These constraints limit transactions that are allowed within the database design. State transition predicates are the basis of state transition constraints.
- State transition constraints are predicates that reference a pair of database states as their parameters, one database state representing the begin state of a transaction, and the other representing the end state of the transaction.
- Typical examples for state transition constraints are limitations on the values allowed for attributes of newly inserted tuples, or limitations on value transitions (updates) of an attribute whose value set represents a set of codes.
- State transition constraints are specified as part of the specification of the state transition universe for a database design. This is the set representing all admissible transactions for a database design.
- State transition (contrary to static) constraints may reference transactional environment variables offered by the DBMS. Typical examples of these variables are the system date and time (denoted by
sysdate) and the currently logged in user (denoted byuser).
Exercises
- Prove the rewrite rule
(P ⇒ (Q ∨ R) ) ⇔ ( (P ∧ ¬Q) ⇒ R)either by using the rewrite rules from Table 1-13 or by using a truth table. - Rewrite
prop1from Listing 8-1 into a universal quantification. You might find this a more intuitive specification. - Formally specify the state transition constraint stating that the salary of an employee can only be decreased if at the same time the salary grade for the employee is increased. Does transaction
TX1introduced in the section “More Data Integrity Predicates” violate this constraint too? - Give an alternative specification for state transition constraint
STC2that involves the join operator. - Specify a state transition constraint stating that the value of attribute
HIREDfor newly insertedEMPtuples cannot be more than one month aftersysdate. Informally, new employees can at the soonest be registered one month prior to their first workday. - Can state transition constraint
STC7be decomposed into multiple conjuncts? What about STC3? - Specify a state transition constraint stating that new employee tuples can only be inserted by sessions that are logged in with the
USERNAMEof an employee that works in the HR department (DNAME = 'Human resources'). - As explained in this chapter, the way course offerings are evaluated is that the trainer first has to enable the evaluation by resetting the evaluation attribute of all registered attendees for the offering, to value
0. After this transaction—that has to be performed by a session of the trainer—the attendees can evaluate the offering by changing the0into a value ranging from1to5. Every attendee should be allowed only to update the evaluation of his or her own registration. Modify the specification ofSTC7to reflect these additional authorization requirements. - Further modify
STC7such that evaluations must occur at or before the last day of the offering. - You need to cater for the possibility of a terminated employee to be reinstated.
One of your colleagues suggests that in these cases the
TERMtuple involved should be removed and at the same time theHIREDattribute (in the correspondingEMPtuple) updated to reflect the start of the renewed employment for the employee.- Give a formal specification stating that
TERMtuples can only be deleted if at the same time theHIREDattribute of the employee is updated (that is, increased to a more recent date). - Do you see potential problems with this solution? Under what conditions would this solution be viable?
- Give a formal specification stating that