Specifying Database Updates Using A Subschema

Transcription

1 Specfyng Database Updates Usng A Subschema Sona Rstć, Pavle Mogn 2, Ivan Luovć 3 Busness College, V. Perća 4, 2000 Nov Sad, Yugoslava sdrstc@uns.ns.ac.yu 2 Vctora Unversty of Wellngton, School of Mathematcal and Computng Scences, P.O. Box 600, Wellngton, New Zealand pmogn@mcs.vuw.ac.nz 3 Unversty of Nov Sad, Faculty of Techncal Scences, Trg D. Obradovća 6, 2000 Nov Sad, Yugoslava van@s.ns.ac.yu Abstract. The noton of a subschema, as a formal and abstract defnton of data, constrants, and database update actvtes that are needed to mae a transacton program, s ntroduced n the paper. Subschema s a component of a transacton program specfcaton. It s desgned usng a user request and an exstng relatonal database schema. The prncples of a database update usng subschema concepts are ntroduced at the abstracton level of nstances to express the fact that a subschema and the correspondng database schema must satsfy certan condtons to allow safe database updates usng a program made n accordance wth subschema concepts. The condtons of the formal subschema and database schema consstency are ntroduced at the schema abstracton level, as well. It s shown that formal consstency mples database update prncples, whch leads to the concluson that a subschema desgn process should adhere to formal consstency condtons f t s to consttute a component of a transacton program specfcaton.. Introducton Specfyng transacton programs s an mportant and tme-consumng methodologcal tas n the process of nformaton system desgn. The desgn specfcaton of a transacton program s a formalzed descrpton of that program. It s amed at supportng the mplementaton of an end user busness tas that s defned by means of a user request. It s usually assumed that the transacton programs wll be executed aganst a database. Accordngly, the basc structural components of a transacton program specfcaton are: A specfcaton of the human-computer nterface; A data defnton; and A formal descrpton of a data processng procedure. In ths paper, the data defnton part of the transacton program specfcaton s called a subschema. A subschema s a formal and abstract defnton of data, constrants, and database update actvtes that are needed to mae a transacton program. A subschema s desgned wth respect to a user request and an exstng relatonal database schema. Accordngly, a subschema descrbes data of a relatvely small part of a database, and conssts of a set of relaton schemes and a set of nterrelaton constrants. Each relaton scheme of a subschema conssts of a set of attrbutes and a set of local constrants. A role and a set of modfable attrbutes, defnng possble database update actvtes, are also assgned to each relaton scheme. Each relaton scheme of a subschema may be consdered as a vew on a sngle base relaton scheme. Subschema nstances are not materalzed. To allow safe database updates usng a program made n accordance wth a subschema, the subschema has to be consstent wth the correspondng database schema n a formal sense. Ths consstency s based on the prncples of a database update usng subschema concepts that are ntroduced n the paper, as well. From an end user pont of vew, usng a transacton program means applyng a sequence of update actvtes on a subschema nstance. The fact that a subschema nstance does not physcally exst has two consequences. These are: A subschema nstance has to be magned as the result of applyng approprate on, select and proect operatons on a database nstance; and The only way to execute a transacton program s to transform the sequence of update actvtes defned over the subschema concepts nto a correspondng sequence of update actvtes defned over the database schema concepts and then apply them on the database nstance.

2 Normally, ths update changes only that part of the database nstance that s related to subschema concepts. An ntutve expectaton s that applyng the on, select and proect operatons on the updated database nstance should produce the same subschema nstance that would be obtaned by drect updatng the ntal subschema nstance. The am of ths paper s to show that t s possble to formulate condtons at schema level of abstracton, by means of whch ths expectaton wll be preserved. We have chosen the concepts of the relatonal data model to defne: the noton of a subschema, the database update prncples, and the formal schema and subschema consstency, snce we needed ts powerful mathematcal formalsm to express our deas and solutons n a precse way. But we beleve that our results may be appled to other data models, too. The noton of the formal consstency s defned n the paper. It s shown that the formal consstency mples database update prncples. Ths result leads to the concluson that a subschema desgn process should adhere to formal consstency condtons f ths subschema s ntended to consttute a component of a transacton program specfcaton. The standard noton of a database SQL vew s n some sense related to the noton of the subschema as ntroduced n the paper. Both of them represent an nterface between a user (or program) and the database. Ths nterface provdes a user wth a specfc way of loong at the data n the database. Apart from that, a subschema s as a structure over the smple vews, and that structure contans nformaton about database constrants and allowable database operatons. Addtonally, a subschema s a component of a program specfcaton, and ths specfcaton may be mplemented n many dfferent ways, under many, even technologcally dfferent, programmng systems. The ssues of relatonal database update usng vews are consdered n [6, 7, 8, 9]. The conclusons of consderatons n [6] are formulated as recommendatons for the vendors of RDBMS. Some of the contemporary RDBMS s allow database update usng a vew f the requested update actvty may be unambguously performed on the base relatons; otherwse t s reected. Ths mght lead to the concluson that t would be suffcent to use a vew nstead of a relatvely complex structure as a subschema n the transacton program specfcaton. We beleve that a vew carres nsuffcent nformaton to mae a correct database update program. In partcular, a vew hdes from a programmer nformaton about: The structure over the needed base relatons, The constrants needed to mae an user-frendly screen form control program, and The allowed operatons on the base relatons. All ths nformaton s contaned n a subschema. In [8], Dayal and Bernsten explore the problem of transformng update operatons that are defned over ether a complex or a smple vew nto correspondng update operatons over a database schema n detal. In our paper the transformng problem s smpler, snce each relaton scheme of a subschema corresponds to exactly one relaton scheme from the database schema. Some consequences of ths restrcton and possble solutons wll be brefly dscussed at the end of the paper. In [9], Banclhon and Spyratos consder the problem of vew updateablty n a very general and formal way at the level of nstance abstracton, by ntroducng the concepts of complementary vew and g-translatablty of update operatons. We see our approach to database update prncples as a specal and practcally mportant case, when a vew nstance and ts complement mae a database schema nstance. In [7], Langera also consders the problem of vew updateablty, but functonal dependences, n the presence of null values, are the only ntegrty constrants that have been taen nto consderaton. Only total proectons of database relatons as vew nstances are analyzed and the selecton operator s not consdered. Ths paper extends the results presented n [7, 8, 9] by ntroducng and emphaszng the roles of allowable operatons and modfable attrbutes n the defnton of the database update prncples. Apart from the Introducton and Concluson, the paper has four sectons. Secton two formally ntroduces the noton of a subschema. Sectons three and four descrbe the prncples of a database update usng subschema concepts, and Secton fve s concerned wth formal consstency. 2. The Subschema A relatonal database schema s a par (S, I), where S s a set of relaton schemes and I s a set of nterrelaton constrants. It s supposed n the paper that the database schema s produced usng a well-defned methodologcal approach, and no further attenton s pad to ths ssue. Each relaton scheme from S s a named trple: N(R, C, K p (R)), where N s a unque name, R s an attrbute set, and C s a specfcaton of constrants. A relaton scheme wll be often referred smply by ts name N. The specfcaton of constrants C s a trple (K, τ (N), Unq(N)), where K s a set of eys, τ (N) wll be called tuple nteg- 2

3 rty constrant, and Unq(N) s a (possble empty) set of unqueness constrants Unque(N, X ), where X s a proper subset of R, whch does not contan any ey from K. The tuple ntegrty constrant τ (N) s a par, whose frst component contans attrbute doman constrants of each attrbute A R. The second component of the par s a logcal expresson defned over the attrbutes from R and ther doman values. A unqueness constrant Unque(N, X ) means that each non null value of X must be unque n a relaton over N. More detals concernng the specfcaton of constrants C may be found n []. K p (R) K denotes the prmary ey of the relaton scheme N. The nterrelaton constrant set I may contan varous types of constrants, of whch frequently used referental ntegrty s ust one. The goal of a subschema desgn s to satsfy at least one user request. So, for a database schema there may exst at most as many subschemas as there are dentfed user requests. Formally, a subschema s a named par P (S, I ), where P s a subschema name, S s a set of relaton schemes, and I s a set of nterrelaton constrants. The set of relaton schemes of a subschema P s S = {N (R, C, K p (R ), Role(P, N ), Mod(P, N ), Sr(P, N )) {,..., n}}, where N s a scheme name, R s an attrbute set, C s a specfcaton of constrants of the form (K, τ (N ), Unq(N )), and K p (R ) s a prmary ey. Role(P, N ) s a set of relaton scheme roles n the subschema P, and Mod(P, N ) s a set of attrbutes that may be modfed. Sr(P, N ) s a functon from the set of relaton schemes S nto the set of relaton schemes S. Further explanatons of Sr(P, N ), Role(P, N ) and Mod(P, N ) follow. Sr(P, N ) assocates each relaton scheme N S wth a relaton scheme N S for whch R R holds. The relaton scheme N wll be called the correspondng relaton scheme for the relaton scheme N. A subschema desgner defnes the mappng Sr(P, N ). It s supposed that database schema and subschema desgn guarantee that for each N n any P there s at least one N S such that R R holds. Role(P, N ) determnes the operatons that may be performed on an nstance of the relaton scheme N. These operatons may be bult nto a transacton program made usng the concepts of a subschema P. A set of relaton scheme roles s a nonempty set, and Role(P, N ) {r,, m, d}, where: r stands for data readng or referencng; stands for data nsert; m stands for data modfcaton; and d stands for data deletng. A subschema P s ntended for database queryng only f ( N S )(Role(P, N ) = {r}) holds, and t s ntended for database updatng otherwse. The set Mod(P, N ) contans those attrbutes of the relaton scheme N that may be modfed. If m Role(P, N ), then Mod(P, N ) must not equal. Accordng to the defnton, a subschema s merely a desgn tool that s needed for a correct transacton program desgn. Example. Suppose a database schema (S, I) and subschemas P (S, I ), P 2 (S 2, I 2 ), P 3 (S 3, I 3 ) are gven, where: S = {ORDER(R, C,...), SHIPMENT(R 2, C 2,...), CUSTOMER(R 3, C 3,...)}; R = {OrdId, Ordate, CustId, Orgn, Total}; C = (K, τ (N ), Unq(N )) = ({{OrdId}}, τ(order), ); K p (R ) = {OrdId}; R 2 = {ShpId, OrdId, ShpDate, ShpTotal}; C 2 = (K 2, τ (N 2 ), Unq(N 2 )) = ({{ShpId}}, τ(shipment), ); K p (R 2 ) = {ShpId}; R 3 = {CustId, CustName, CustAdrr}; C 3 = (K 3, τ (N 3 ), Unq(N 3 ))= ({{CustId}}, τ(customer), ); K p (R 3 ) = {CustId}); I = {ORDER[CustId] CUSTOMER[CustId], SHIPMENT[OrdId] ORDER[OrdId], CUSTOMER[CustId] ORDER[CustId]}. S = {Dom_Shpped_Order(R, C,...), Shpment(R 2, C 2,...)}; R = {OrdId, OrDate, CustId, Orgn, Total}; C = (K, τ (N ), Unq(N ))= ({{OrdId}}, τ(dom_shpped_order), ), K p (R ) = {OrdId}; R 2 = {ShpId, OrdId, ShpDate, ShpTotal}; C 2 = (K 2, τ (N 2 ), Unq(N 2 )) = ({{ShpId}}, τ(shpment), ); 3

4 K p (R ) = {ShpId}; Role(P, Dom_Shpped_Order) = Role(P, Shpment) = {, r}; Mod(P, Dom_Shpped_Order) = Mod(P, Shpment) = ; Sr(P, Dom_Shpped_Order) = ORDER; Sr(P, Shpment) = SHIPMENT; I = {Shpment[OrdId] Dom_Shpped _Order[OrdId], Dom_Shpped_Order[OrdId] Shpment[OrdId]}; S 2 = {Order(R 2, C 2,...), Customer(R 2 2, C 2 2,...)}; R 2 = {OrdId, OrDate, CustId, Orgn, Total}; C 2 = (K 2, τ (N 2 ), Unq(N 2 )) = ({{OrdId}}, τ(order), ); K p (R 2 ) = {OrdId}; Role(P 2, Order) = {, r}; Mod(P 2, Order) = ; Sr(P 2, Order) = ORDER; R 2 2 = {CustId, CustName, CustAdrr}, C 2 2 = (K 2 2, τ (N 2 2 ), Unq(N 2 2 )) = ({{CustId}}, τ(customer), ); K p (R 2 2 ) = {CustId}); Role(P 2, Customer) = {r}; Mod(P 2, Customer) = ; Sr(P 2, Customer) = CUSTOMER; I 2 = {Order[CustId] Customer[CustId]}; S 3 = {Order(R 3, C 3,...), Shpment(R 2 3, C 2 3,...)}; R 3 = {OrdId, OrDate, CustId, Orgn, Total}; C 3 = (K 3, τ (N 3 ), Unq(N 3 )) = ({{OrdId}}, τ(order), ); K p (R 3 ) = {OrdId}; Role(P 3, Order) = {r}; Mod(P 3, Order) = ; Sr(P 3, Order) = ORDER; 2 R 3 = {ShpId, OrdId, ShpDate, ShpTotal}; C 2 3 = (K 2 3, τ (N 2 3 ), Unq(N 2 3 )) = ({{ShpId}}, τ(shpment), ); K p (R 2 3 ) = {ShpId}; Role(P 3, Shpment) = {, r}; Mod(P 3, Shpment) = ; Sr(P 3, Shpment) = SHIPMENT; I 3 = {Shpment[OrdId] Order[OrdId]}; Subschema P s amed for entry of domestc orders and shpments wthn one transacton, P 2 s amed for order entry, and P 3 s amed for entry of shpments that are ntated by orders. Subschema P s assocated wth a busness unt whose tas s to control domestc orders. In ths busness unt users are not nterested n customer data except for customer d number. The attrbute doman constrant for Orgn n subschema P s more restrctve than the correspondng constrant n the database schema, because only the orders of domestc customers are requred. Subschema P also contans the ncluson dependency Dom_Shpped_Order[OrdId] Shpment[OrdId] that forces nsertng and selectng only those order tuples from a relaton over ORDER that are referenced by some shpment tuples. Suppose all the tuple ntegrty constrants that are embedded nto relaton schemes whose name has the same meanng are the same, except the doman constrant for attrbute Orgn. The values of ths attrbute determne whether a domestc or foregn customer ssued a partcular order. In the relaton scheme Dom_Shpped_Order of the subschema P, dom(orgn) = {d} holds, whereas n the relaton scheme Order of P 2, P 3 and n the relaton scheme ORDER of the database schema, dom(orgn) = {d, f }, where d stands for domestc and f for foregn. These subschemas and database schema wll be referenced n all other examples of ths paper. A database schema and a subschema contan the followng concepts: Database schema attrbute set U = U R and subschema attrbute set U = U R ; N S N S Sets of relaton scheme attrbute sets S = {R {,..., n}} and S = {R {,..., t}}; and 4

5 n t Sets of constrants O = I ( C = ) and O = I ( C ). = The sets S and O determne the set of subschema P nstances, whereas the sets S and O determne the set of database schema (S, I) nstances. In the paper, O + wll denote the set of all logcal consequences of a set of constrants O and O + X wll denote all the constrants from O +, whch are defned usng only the attrbutes from X. 3. Database Updates Usng Subschema Concepts A transacton program ssues query and update commands that are executed by a DBMS aganst a database nstance. Let T be a transacton program based on subschema concepts, and let T be a transacton program that s equvalent to T, but based on database schema concepts. To consder database updates ntated by any transacton program T as safe updates, the structure of the subschema and database schema should provde the followng two nstance level condtons to hold:. A unque (hypothetcal) subschema nstance, called correspondng subschema nstance, may be produced by applyng approprate relatonal on, proect and select operatons on a database schema nstance; and 2. If an update of a hypothetcal subschema nstance executed by T would be successful, then T must be commtted by DBMS. If a subschema s ntended for queres only, then t must satsfy only Condton. If a subschema s ntended for updatng, then t must satsfy both condtons. In ths paper, the aforementoned condtons are called prncples of a database update usng subschema concepts. A subschema that satsfes these condtons s sad to be consstent wth the correspondng database schema. Let SAT(S, I) denote the set of all nstances over a database schema (S, I). If I =, then SAT(S) stands for SAT(S, ). Let SAT(R, C ) denote the set of all nstances over a relaton schme N (R, C, K p (R )). If C =, then SAT(R ) stands for SAT(R, ). A set s = {r(r ),..., r(r t )} where r(r ) SAT(R, C ) and t = S, s an nstance over the database schema (S, I),.e. s SAT(S, I), f I s satsfed. Suppose a transacton program s based on subschema P (S, I ) concepts, where S = {N,..., N n }, and let s be an nstance over the subschema P that s a correspondng nstance for some database nstance s. The correspondng nstance s a set of hypothetcal relatons s = {r(r ),..., r(r n )} that are produced by applyng on, select and proect operatons to some relatons from the database nstance s. The composton of operators that s used to produce a correspondng nstance s from an nstance s wll be denoted by ΠΣ ΣΠ. Thus, s = ΠΣ ΣΠ(s, P ). From an end user pont of vew, usng a transacton program based on the concepts of a subschema P means updatng a subschema nstance s, regardless of the fact that ths nstance does not physcally exst and hence s ust a vew on a database schema nstance s. Let H denote a sequence of operatons that s ntated by a transacton program, and suppose these operatons are defned usng the concepts of a subschema P. Ths sequence of operatons could be appled only to an nstance s over P. As a result, a set s up = {r,..., r n } of updated relatons would be produced, where r s an abbrevated notaton for r (R ). For the end user s s a database and s up s the result of applyng a sequence of update operatons H on s. However, a subschema nstance s not materalzed. A DBMS executes query and update commands on an nstance over a database schema. Update operatons that are ntated by a transacton program based on subschema concepts are transformed nto operatons expressed n terms of database schema concepts. Ths way, the sequence of operatons H generates a sequence of operatons CH that are expressed n terms of database schema concepts. By applyng the composton of operatons n CH on an nstance s over a database schema, a set of relatons s up = {r (R ),..., r (R t )} s generated, where s up = CH(s). The operatons from CH should alter only data that would belong to the hypothetcal subschema nstance s. Thus, the altered data belong to ΠΣ ΣΠ(s up, P ). Snce CH s made of transformed update operatons from H, t may be concluded that s up = ΠΣ ΣΠ(s up, P ) (Fg. ). From the subschema pont of vew, the effect of an nstance s update by means of CH s the same as t would be the effect of updatng the hypothetcal correspondng nstance s usng H. The same clam s also expressed by the second prncple of a database update usng subschema concepts. 5

6 s CH s up ΠΣ ΣΠ ΠΣ ΣΠ s H s up Fg.. The relatonshp between updated nstances over a subschema and a database schema 4. A Formal Defnton of Database Update Prncples In ths secton of the paper the prncples of a database update usng subschema concepts wll be formally defned at the abstracton level of nstances. Defnton. Suppose a set of relaton scheme S of a subschema P and a database schema (S, I) satsfy the followng condton: ( s SAT(S, I))(!s SAT(S ))( r s )(r = σ F (π R (r(sr(p, N ))))), () where F s a select condton, whose am s to select those tuples from r that satsfy constrants embedded n N S. Let s SAT(S, I) be an nstance over a database schema. A set of relatons s SAT(S ) satsfyng (), s a correspondng set to the nstance s wth regard to the set S, whch wll be denoted by s = ΣΠ(s, S ). The select condton F s ntroduced n the formula () snce subschema constrants may be more restrctve then database schema constrants. It should be also noted that the set s that satsfes (), may not satsfy subschema nterrelaton constrants I. Now, the frst update prncple may be formally expressed n the followng way. Defnton 2. A subschema P (S, I ) and a database schema (S, I) satsfy the frst update prncple f the condton () s satsfed and: ( s SAT(S, I))(!s SAT(S, I ))( r s )(r = π R (σ F ( r ))), (2) r ΣΠ( s, S ) holds, where F s a select condton that selects those tuples from Cartesan product of relatons satsfyng () that also satsfy subschema nterrelaton constrants I. Now, we defne the noton of a correspondng nstance of a subschema. Defnton 3. Suppose a subschema P (S, I ) and a database schema (S, I) satsfy condtons () and (2), and let s SAT(S, I). An nstance s SAT(S, I ) s a correspondng nstance of the nstance s wth regard to subschema P (S, I ), denoted s = ΠΣ ΣΠ(s, P ), f the followng holds: ( r s )(r = π R (σ F ( r ))). (3) r ΣΠ( s, ) S 6

7 Example 2. Consder the database schema and subschemas gven n Example. To select only the domestc orders for the relaton scheme Dom_Shpped_Order of the subschema P, the selecton condton of formula () wll be F Dom_Shpped_Order : Orgn = d. The selecton condton F of formula (2) should provde only already shpped domestc orders. So, F : ORDER.OrdId = SHIPMENT.OrdId. Alternatvely, to select those domestc orders that are only partally shpped, the correspondng selecton condton would be: F : ORDER.OrdId = SHIPMENT.OrdId ORDER.Total > SHIPMENT.ShpTotal. Let s = {r, r 2, r 3 } SAT(S, I) be an nstance over a database schema, where r (ORDER), r 2 (SHIPMENT), and r 3 (CUSTOMER) are shown on Fg. 2. For F Dom_Shpped_Order : Orgn = d, F : ORDER.OrdId = SHIPMENT.OrdId and a subschema P nstance s = {r, r 2 } SAT(S, I ), where r (Dom_Shpped_Order), and r 2 (Shpment) are shown on Fg. 3, s = ΠΣ ΣΠ(s, P ) holds. r 3 (CUSTOMER) r 2 (SHIPMENT) CustId CustName CustAdrr ShpId OrdId ShpDate ShpTotal Alfa Belgrade Beta Rome Gama Belgrade Delta Wen r (ORDER) OrdId Ordate CustId Orgn Total f f d d d f 000 Fg. 2. An nstance over the database schema from Example. r (Dom_Shpped_Order) r 2 (Shpment) OrdId Ordate CustId Orgn Total ShpId OrdId ShpDate ShpTotal d d Fg. 3. An nstance over subschema P from Example. Let a set of relatons s = {r(r ),..., r(r n )} be gven, and suppose t s a correspondng nstance of a database nstance s wth regard to subschema P.. A transacton program havng subschema P as a part of ts specfcaton, may perform only the operatons covered by the set {Role(P, N ),, Role(P, N n )}, where each Role(P, N ) defnes allowed operatons on nstances over N. Each update of an nstance over a relaton scheme N may be represented as a composton of operatons from Role(P, N ). Defnton 4. Let a subschema P (S, I ) and an nstance s = {r(r ),..., r(r n )} SAT(S, I ) be gven. Let O r {, d, m, r} Role(P, N ), where N S, be a database operaton, t r a tuple over the set of attrbutes R and P r the prmary ey value of a tuple on whch operaton O r s gong to be appled. It s supposed that the followng condtons are satsfed. If O r = d, then P r represents the prmary ey value of a tuple from r (R ) s that s ntended for deletng. If O r = m, then t r contans values that are ntended to replace the old values of a tuple from r (R ) s wth the prmary ey value P r. If O r =, then t r s a tuple ntended for nserton nto relaton r (R ) s. In ths case, P r represents the prmary ey value of t r. A functon h r = h (Pr, tr, Or) : SAT(R ) SAT(R ), defned n the followng way: 7

8 r \ { t }, f = [ ( l Or d t l r t l K p R )] = Pr, ( r \ { t }) ({ [ \ (, )]} { [ (, l t l R Mod P N tr Mod P N )]}), h r (r) = f = [ ( )] =, Or m t l r t l K p R Pr r { }, f =, tr Or r, f Or = r ( {, } ( t r)( t [ K ( R Or d m l l p )] Pr )) (4) s an allowed operaton on r SAT(R ). Example 3. Let Example and Example 2 be consdered. Functon h (06, (06,.02.02, 4, f, 200), ) s an allowed operaton on an nstance over the relaton scheme Order of the subschema P 2, for whch (s 2 \{r 2 }) {h (06, (06,.02.02, 4, f, 200), )(r 2 )} SAT(S 2, I 2 ) holds. If the same allowed operaton h (06, (06,.02.02, 4, f, 200), ) s appled on r (Dom_Shpped_Order), shown on Fg. 3, then (s \{r }) {h (06, (06,.02.02, 4, f, 200), ) (r )} SAT(S, I ) does not hold, snce t r = (06,.02.02, 4, f, 200), ) represents a foregn order. The operaton h (05, (05,.02.02, 4, f, 200), m) s not allowed over the relaton scheme Order of the subschema P 2, because m Role(P 2, N 2 ). For the sae of smplcty and wthout any mpact on further results, t s supposed n formula (4) that selecton of database tuples to be deleted or modfed s performed exclusvely by means of a prmary ey value. Defnton 5. An update functon h of a relaton over a set of attrbutes R s produced by composng a sequence of allowed update operatons h m,..., h : h = h m... h = (h m,..., h ). The operaton s appled accordng to the common mathematcal defnton for functon composton. The set of all possble update functons that may be appled on an nstance over R wll be denoted by h. Each hypothetcal nstance s over a subschema P s updated by updatng nstances over ts relaton schemes. Defnton 6. The update functon of a set of relatons s = {r(r ),..., r(r n )}, where S = {N,..., N n }, denoted by H, s any mappng H(s ) = (h,..., h n )(s ) = {r (R ),..., r (R n )} such that: ( {,..., n})(r (R ) = h (r(r )) h h ) (5) s satsfed. The set of all possble update functons over {R,..., R n } wll be denoted by H. Defnton 7. Let s = {r(r ),..., r(r n )} be a set of relatons, where S = {N,..., N n }. The set of relatons s up = {r (R ),..., r (R n )} s an updated nstance of s f the followng holds: ( H H )(s up = H(s )). (6) Snce Defnton 7 s strongly related to Defnton 4, t follows that s up = H(s ) need not necessarly be an nstance over P (S, I ), even n the cases when s SAT(S, I ) holds. The next lemma ntroduce a consequence of condton () that s mportant for further consderatons. The lemma s gven wthout proof. Lemma. Suppose a subschema P (S, I ) and a database schema (S, I) satsfy condton (). Then the followng s satsfed: ( N S )(N = Sr(P, N ) (R R (K Un(N )) (K Un(N ))), (7) where Un(N) = {X Unque(N, X) Unq(N)}. Snce an nstance s does not physcally exst, each update operaton h r (r ) and update functon h must be transformed nto an update operaton and an update functon on an nstance r over a relaton scheme N of a database schema (S, I) that s correspondng to N. 8

9 Defnton 8. Suppose a subschema P (S, I ) and a database schema (S, I) satsfy condtons () and (2). Let h r = h (Pr, tr, Or) and N = Sr(P, N ) be gven. A correspondng operaton to h r that should be executed on an nstance r over N s a functon Ch r = Ch (Pr, tr, Or) : SAT(R, C ) SAT(R ) defned n the followng way: r \ { t l }, f O r = d t l r t l [ K p ( R )] = P r, ( r \ { }) ({ [ \ (, )]} { [ (, t l t l R Mod P N t r Mod P N )]}), f Or = m t l r t l [ K p ( R )] = Pr, Ch r (r ) = r ({ tr } { DefTup( N, ( R \ R ))}), f O r =, r, f = Or r ( {, } ( t r )( t [ K ( R Or d m l l p )] Pr )) (8) where P r s a prmary ey value of a tuple from database relaton r s, t r s a tuple over the set of attrbutes R, and O r {, d, m, r} s an operaton that s performed on a tuple from r s. The term DefTup(N, W) s defned n the followng way: DefTup(N, W) = {t[w] ( A W)(t[A] = Def(N, A))}, where Def(N, A) s an attrbute A default value n the relaton scheme N, f t s declared, otherwse t s a null value. Defnton 9. The update functon Ch = (Ch m,..., Ch ) that corresponds to the update functon h = (h m,..., h ), s a composton of correspondng operatons Ch m,..., Ch, where for each {,..., m}, Ch corresponds to an allowed operaton h : Ch = Ch m... Ch = (Ch m,..., Ch ). The set of all possble correspondng update functons nduced by a relaton scheme N wll be denoted by Ch. Defnton 0. An update functon CH of a database schema nstance s that corresponds to the update functon H = (h,..., h n ) of a subschema nstance s, s a mappng CH(s) = (f,..., f t )(s) = {r (R ),..., r t (R t )} such that: ( {,..., t})(r (R ) = f (r(r )) (9) holds, where: Ch, f = dent, f f ( N )( = (, S N Sr P N )) ( N S )( N ( P, N Sr )). Each functon Ch Ch corresponds to the update functon h from H, whereas dent s an dentty functon,.e. ( r s)(dent(r ) = r ). We wll denote by CH the set of all possble update functons of an nstance over a database schema that are nduced by the concepts of a subschema P. Snce Defnton 0 s strongly related to Defnton 8, t follows that the updated nstance CH(s) need not necessarly be an nstance over (S, I), despte the fact that s SAT(S, I) holds. Let us ntroduce a term of successful update functon. Then, a formal defnton of the second update prncple follows. (0) 9

10 Defnton. Let a subschema P (S, I ) and a database schema (S, I) be gven. Let s be an nstance over (S, I) and H H be an update functon whch s appled on subschema nstance s = ΠΣ ΣΠ(s, P ). CH denotes an update functon of s, correspondng to H. Let a proecton of database relatons accordng to subschema Π(s, P ) be defned n the followng way: Π(s, P ) = {r '(R ) N S N = Sr(P, N ) r (R ) s r ' = π R (r )}. () The update functon H(s ) s successful, f the predcate Successful((S, I), (S, I ), s, H), defned n the followng way: H(s ) SAT(S, I ) H(Π(s, P )) = O + O + U (2) holds, where = denotes that a set of relatons H(Π(s, P )) satsfy the set of constrants O + O + U. Defnton 2. A subschema P (S, I ) and a database schema (S, I) satsfy the second update prncple f Condtons () and (2) are satsfed and the followng holds: ( s SAT(S, I))( H H )(Successful((S, I), (S, I ), s, H) CH(s) SAT(S, I)), (3) where CH s an update functon of s, correspondng to H. Condtons (), (2) and (3) consttute a formal defnton of the prncples of a database update usng subschema concepts. It follows from Defnton 2 that the frst update prncple s a prerequste for the second one. It s due to the fact that Condtons () and (2) are necessary to provde the exstence of an nstance ΠΣ ΣΠ(s, P ), for each s SAT(S, I). By means of (), (2) and (3) we express the fact that database updates, ntated by a transacton program based on the concepts of subschema, are safe. Example 4. Let Example and Example 2 be consdered. Let us consder an update functon H(s ) = (h, h 2 )(s ), where s s shown on Fg. 3. Let h = (h (06, (06, , 6, d, 000), ) )(r ) and h 2 = (h (404, (404, 06, , 000), ) )(r 2 ) be gven operatons. It s obvous that both of them are allowed operatons over s, such that H(s ) SAT(S, I ) holds. For s shown on Fg. 2, a correspondng database update functon s CH(s) = (f, f 2, f 3 )(s), where f (r ) = Ch (r ) = (h (06, (06, , 6, d, 000), ) )(r ), f 2 (r 2 ) = Ch 2 (r 2 ) = (h (404, (404, 06, , 000), ) )(r 2 ) and f 3 (r 3 ) = dent(r 3 ) = r 3 hold. In ths example, snce (06, , 6, d, 000) represents a new order wth a CustId = 6, whch does not exst n database, the operaton Ch (r ) wll volate referental ntegrty ORDER[CustId] CUSTOMER[CustId]. Therefore, CH(s) wll not be an nstance over (S, I). At the other hand, Successful((S, I), (S, I ), s, H) holds. Ths way, subschema P and database schema (S, I) volate the second update prncple. Informally, t s a consequence of the fact that Role(P, Dom_Shpped_Order), but ORDER[CustId] CUSTOMER[CustId] s not ncluded subschema P. If we consdered n ths example an operaton h = (h (05, (05, , 4, d, 000), ) )(r ) nstead of h = (h (06, (06, , 6, d, 000), ) )(r ), then the correspondng operaton Ch (r ) would volate a ey {OrdId} of scheme ORDER, and CH(s) would not be an nstance over (S, I), too. In ths case, however, Successful((S, I), (S, I ), s, H) would not hold. 5. The Formal Database Schema and Subschema Consstency Defnton 3. Let O be the set of database schema (S, I ) constrants. A constrant o O + s relevant for a subschema P, f t may be volated by some update functon CH CH. Example 5. Let us consder subschema P 2 n Example. The referental ntegrty ORDER[CustId] CUSTOMER[CustId] s a relevant constrant for P 2, snce Role(P 2, Order). At the other hand, the ncluson dependency CUSTOMER[CustId] ORDER[CustId] s not a relevant constrant for P 2, snce d Role(P 2, Order) and {, m} Role(P 2, Customer) =. It s ntutvely appealng that a subschema and a database schema wll be formally consstent, f ther concepts are n some way consstent. The concepts of a subschema and a database schema are formally consstent, f: 0

11 . The set of attrbutes of each subschema relaton scheme s a subset of the correspondng relaton scheme attrbute set; 2. The set of eys of each subschema relaton scheme s a subset of the unon of the correspondng relaton scheme set of eys and the set of attrbute sets wth a unque property; and 3. All the constrants that can be nferred from the database schema and that are relevant for the subschema are embedded n the subschema. Formally, the frst and the second condton are expressed by formula (7). The thrd consstency condton can be expressed by the followng logcal mplcaton: O = O r P, (4) where O r P s the set of all database schema constrants that are relevant for subschema P. The most mportant components of a constrant o O specfcaton are: A set of trples T(o) = {(N, ρ, At ),..., (N m, ρ m, At m )}; and A set of crtcal operatons. In a trple (N, ρ, At ), N s the name of a relaton scheme that s spanned by o, ρ s the role of N n o and At s a set or sequence of attrbutes from R that are relevant for o. An attrbute A s relevant for o f o s used to chec values of A. A crtcal operaton s an operaton that can volate a constrant. The constrant o should belong to the set of subschema relevant constrants f the operaton that mght volate o s allowed n the subschema P. There are two nds of relevant constrants: The nclusve relevant constrants, denoted by In(O, P ); and The extensble relevant constrants, denoted by Ex(O, P ). Suppose a constrant o O + s relevant for a subschema P. The constrant o belongs to In(O, P ) f and only f: ( (N, ρ, At ) T(o))( N S )(Sr(P, N ) = N At R ) (5) holds. A constrant o belongs to Ex(O, P ) f and only f t s a relevant for P, and o In(O, P ) holds. Example 6. In Example, the referental ntegrty ORDER[CustId] CUSTOMER[CustId] s an nclusve relevant constrant for subschema P 2, snce Role(P 2, Order), ORDER = Sr(P 2, Order), CUSTOMER = Sr(P 2, Customer) CustId R 2 and CustId R 2 2 holds. Snce Role(P, Dom_Shpped_Order) = {, r} holds n Example, the referental ntegrty ORDER[CustId] CUSTOMER[CustId] s an extendng relevant constrant for subschema P. It s relevant because Dom_Shpped_Order S, ORDER = Sr(P, Dom_Shpped_Order) and Role(P, Dom_Shpped_Order) holds. It s an extendng constrant, because for the referenced relaton scheme CUSTOMER there s no correspondng relaton scheme n P. Ths mples that a relaton scheme Customer should be ncluded n P. Defnton 4. A subschema P (S, I ) concepts are formally consstent wth a database schema (S, I) concepts f (7) holds and the followng two condtons are satsfed: O = In(O, P ), (6) Ex(O, P ) =. (7) The formal consstency of a subschema and a database schema concepts mples satsfacton of the database update prncples. The next theorem s gven wthout proof. Theorem. If a subschema P (S, I ) s formally consstent wth a database schema (S, I), then the condtons (), (2), and (3) hold.

12 Example 7. Suppose Role(P 2, Customer) = {, r} n Example holds. The constrants ORDER[CustId] CUSTOMER[CustId] and CUSTOMER[CustId] ORDER[CustId] are nclusve relevant constrants for subschema P 2. In ths example, however, the condton O 2 = In(O, P 2 ) s not satsfed, snce Customer[CustId] Order[CustId] s not ncluded n the set of subschema constrants I 2. An nserton of a new customer not havng any order would not volate the consstency of a hypothetcal nstance over P 2, whereas DBMS would reect ths operaton, snce t would volate the consstency of a database schema nstance. Besdes, the predcate Successful((S, I), (S 2, I 2 ), s, H), for such an nstance s and update functon H would hold. Snce Role(P, Dom_Shpped_Order) = {, r} n Example holds, the referental ntegrty ORDER[CustId] CUSTOMER[CustId] s an extendng relevant constrant for subschema P, whch means that Ex(O, P ) holds. An nserton of a new order wth a non-exstng CustId value would not volate the consstency of an nstance over P, whereas DBMS would reect ths operaton, snce t would volate the consstency of a database schema nstance. In ths case, the predcate Successful would be satsfed too. 6. Concluson In ths paper, the noton of a subschema that represents the data defnton part of a transacton program specfcaton s ntroduced. A subschema s a structure, expressed by means of relatonal database schema concepts, extended by the specfcaton of the allowed database update actvtes, and a mappng that unquely bonds subschema relaton schemes wth the database relaton schemes. The relatonshp between a database schema and a subschema s establshed by defnng condtons of database update prncples and the formal subschema and database schema consstency. It s clamed n the paper that the formal consstency mples database update prncples. Accordngly, f a subschema s amed to consttute the data defnton component of a transacton program specfcaton, ts desgn process should adhere to formal consstency condtons. One of the man consequences of that statement s that the set of subschema constrants should mply all those database schema constrants that mght be volated by the allowed database update operatons. A general soluton of the mplcatonal problem n the presence of dfferent constrant types s very hard to fnd, f even possble. Testng the satsfacton of the formal consstency may be relaxed by consderng mplcatonal problem for varous constrant types separately. We beleve that our approach relaxed n that way, may lead to a good transacton program desgn practce. We have studed subschemas where each relaton scheme nstance has been produced by applyng relatonal proect and select operatons onto a base relaton. That approach enables an easy transformaton of database update operatons expressed upon subschema concepts nto database update operatons expressed upon database schema concepts. However, sometmes t may appear preferable to allow defnng nstances of a subschema relaton scheme by applyng select and proect operatons onto ons of base relatons. Therefore, a future wor should study the effects of constructng a subschema relaton scheme from more than one database schema relaton scheme. References. Luovć I., Mogn P., Govedarca M., Rstć S.: The Structure of A Subschema and Its XML Specfcaton, XIII Internatonal Conference on Informaton and Intellgent Systems, Varaždn, Croata (2002), Proceedngs, Rstć, S.: A Research of Subschema Consoldaton Problem. PhD Thess, Unversty of Nov Sad, Faculty of Economcs, Subotca (n progress) 3. Mogn P., Luovć I., Govedarca M.: Database Desgn Prncples. Unversty of Nov Sad, Faculty of Techncal Scences & MP "Stylos", Nov Sad, Yugoslava (2000) 4. Luovć I., Mogn P.: On The Role of Subschema as A Component of The Implementaton Specfcaton of A Program. VI Symposum on Computer Scence and Informaton Technologes YUINFO, Kopaon, Yugoslava (2000), Proceedngs on CD ROM 5. Mogn P., Luovć I.: An Approach to Database Desgn. Internatonal Journal of INDUSTRIAL SYSTEMS, Vol., No. 2, Nov Sad, Yugoslava (999) Codd E. F.: The Relatonal Model for Database Management Verson 2. Addson-Wesley-Publshng-Company, USA (990) 7. Langera R.: Vew Updates n Relatonal Databases wth An Independent Scheme, ACM Transactons on Database Systems, Vol. 5, No. (990) Dayal U., Bernsten P.: On the Correct Translaton of Updates on the Relatonal Vews. ACM Transactons on Database Systems, Vol. 8, No. 3 (988) Banclhon F., Spyratos N.: Update Semantcs of Relatonal Vews. ACM Transactons on Database Systems, Vol. 6, No. 4 (98)