Question bank 4th module Explain informal design guidelines First Normal form Second Normal form Third Normal form BCNF Normal form Fourth Normal form Fifth Normal form 5th module Why cancurency controlis needed Types of failures ACID properties of transaction- error -prone 4.3 Informal Design Guidelines for Relation Schemas = Four informal guidelines that may be used as measures to determine the quality of relation schema design: 1. Making sure that the semantics of the attributes is clear in the schema 2. Reducing the redundant information in tuples 3. Reducing the NULL values in tuples 4. Disallowing the possibility of generating spurious tuples = ‘These measures are not always independent of one another 4.3.1 Imparting Clear Semantics to Attributes in Relations > semantics of a relation refers to its meaning resulting from the interpretation of attribute values in a tuple = Whenever we group attributes to form a relation schema, we assume that attributes belonging to one relation have certain real-world meaning and a proper interpretation associated with them = The easier it is to explain the semantics of the relation, the better the relation schema design will be Guideline 1 = Design a relation schema so that it is easy to explain its meaning = Do not combine attributes from multiple entity types and relationship types into a single relation+ if a relation schema corresponds to one entity type or one relationship type, it is straightforward to interpret and to explain its meaning + if the relation corresponds to a mixture of multiple entities and relationships, semantic ambiguities will result and the relation cannot be easily explained. Examples of Violating Guideline 1 EMP_DEPT [ ENAME | SSN | BDATE | ADDRESS | DNUMBER DNAME |). DMGRSSN’ EMP_PROJ | SSN _| PNUMBER [ Hours | ENAME | PNAME PLOCATION Fig: schema diagram for company database Both the relation schemas have clear semantics A tuple in the EMP_DEPT relation schema represents a single employee but includes additional information— the name (Dname) of the department for which the employee works and the Social Secufity number (Dmgr_ssn) of the department manager. A tuple in the EMP_PROJ relates an employee to a project but also includes the employee name (Ename), project name (Pname), and project location (Plocation) logically correct but they violate Guideline 1 by mixing attributes from distinct real-world entities: + EMP_DEPT mixes attributes of employees and departments + EMP_PROJ mixes attributes of employees and projects and the WORKS_ON relationship They may be used as views, but they cause problems when used as base relations+ ifa relation schema corresponds to one entity type or one relationship type, it is straightforward to interpret and to explain its meaning * if the relation corresponds toa mixture ef multiple entities and relationships, semantic ambiguities will result and the relation cannot be easily explained. Examples of Violating Guideline 1 EMP_DEPT enane | ssn | BOATE | ADDRESS | DNUMBER | DNAME | DMGRSSN EMP_PROJ SSN PNUMBER | Hours | ENAME | PNAME | PLOCATION Fig: schema diagram for company database Both the relation schemas have clear semantics ‘A tuple in the EMP_DEPT relation schema represents a single employee but includes additional information— the name (Dname)of the department for which the employee works and the Social Secufity number (Dmgr_ssn)of the department manager. A tuple in the EMP_PROU felates an employee to a project but also includes the employee name (Ename), projectiname (Pname), and project location (Plocation) logically corect.but they violate Guideline 1 by mixing attributes from distinct real-world entities: + EMP_DEPT mixes attributes of employees and departments + EMP_PROJ mixes attributes of employees and projects and the WORKS_ON relationship They may be used as views, but they cause problems when used as base relations 4.3.2 Redundant Information in Tuples and Update Anomalies. One goal of schema design is to minimize the storage space used by the base relations Grouping attributes into relation schemas has a significant effect on storage space For example, compare the space used by the two base relations EMPLOYEE and DEPARTMENT with that for an EMP_DEPT base relation In EMP_DEPT, the attribute values pertaining to @ particular department (Dnumber, Dname, Dmgr_ssn) are repeated for every emplayee who works for that departmentIn contrast, each department's information appears only once in the DEPARTMENT relation. Only the department number Dumber is repeated in the EMPLOYEE relation for each employee who works in that department as a foreign key EMPLOVEE Fawne Jobo, 1781 Fondeen, Houston, 1] Frarain 1956-12-08 | 696 Woes, Hooston. TX ‘Aicia 1968-01-19 |3891 Caste, Spring, TX. 1941-06-20 [201 Bory, Bellare, TX 1969-09-29 | 980 Dalia, Houston, TX ‘89665955 | 1997-11-10 | 450 Stone, Hounton, TH Fie i HoustonFigure 1: One possible database state for the COMPANY relational database schema Racundancy 'gielgiel ial | Bong iss | Resgarentn | Hauer Fig: Sample states for EMP_DEPT and EMP_PROJ resulting from applying NATURAL JOIN to the relations in Figure 1® Storing natural joins of base relations leads to an additional problem referred to as update anomalies. These can be classified into: * insertion anomalies * deletion anomalies, * modification anomalies Insertion Anomalies. «Insertion anomalies can be differentiated into two types, illustrated by the following examples based on the EMP_DEPT relation: 1. To insert a new employee tuple into EMP_DEPT, we must include elther'the attribute values for the department that the employee works for, or NULLS - For example, to insert a new tuple for an employee who works in department number 5, we must enter all the attribute values of department 5 correctly so that they are consistent with the corresponding values for department. 5 in other tuples in EMP_DEPT In the design of Employee in fig 1, we do not have to worry about this consistency problem because we enter. only the department number in the employee tuple; all other attribute values of department 5 are recorded only once in the database, as a single tuple in the DEPARTMENT relation 2. Itis difficult to insert a new:department that has no employees as yet in the EMP_DEPT relation. The only way to do this is toplace NULL values in the attributes for employee - This Wiolates the entity integiity for EMP_DEPT because Ssn is its primary key = This problem does not occur in the design of Figure 1 because a department is entered in the DEPARTMENT relation whether or not any employees work for it, ‘and whenever an employee is assigned to that department, a corresponding tuple is inserted in EMPLOYEE. Deletion Anomalies «The problem of deletion anomalies is related to the second insertion anomaly situation just discussed - If we delete from EMP_DEPT an employee tuple that happens to represent the last employee working for a particular department, the information concerning that department is lost from the database - This problem does not occur in the database of Figure 2 because DEPARTMENT luples are stored separately.Modification Anomalies. = In EMP_DEPT, if we change the value of one of the attributes of a particular department—say, the manager of department S—we must update the tuples of alf employees who work in that department, otherwise, the database will become inconsistent = if we fail to update some tuples, the same department will be shown to have two different values for manager in different employee tuples, which would be wrong Guideline 2 = Design the base relation schemas so that no insertion) deletion, or modification anomalies are present in the relations «If any anomaties are present, note them clearly and make sie that the programs that update the database will operate correctly = The second guideline is consistent with and, ina wayza-restatementof the first guideline = These guidelines may sometimes have tol be violated in order to improve the performance of certain queries, 4.3.3 NULL Values in Tuples. + if many of the attributes do not apply to all tuples in the relation, we end up with many NULLs in those tuples = this can waste space at the storage level + may lead to problems with understanding the meaning of the attributes. - may also lead to problems with specifying JOIN operations = how to account for them when aggregate operations such as COUNT or SUM are applied = SELECT and JOIN operations involve comparisons: if NULL values are present, the results may become unpredictable. = Moreover, NULLs can have multiple interpretations, such as the following + The attribute does not apply to this tuple. For example, Visa_status may not apply to U.S. students. + The attribute value for this tuple is unknown. For example, the Date_of_birth may be unknown for an employee: + The value is known but absent, that is, it has not been recorded yet. For example, the Home_Phone_Number for an employee may exist, but may not be available and recorded yet. Guideline 3= As far as possible, avoid placing attributes in a base relation whose values may frequently be NULL = If NULLs are unavoidable, make sure that they apply in exceptional cases only and do not apply to a majority of tuples in the relation = Using space efficiently and avoiding joins with NULL values are the two overriding criteria that determine whether to include the columns that may have NULLs ina relation ‘or to have a separate relation for those columns with the appropriate key columns = For example, if only 15 percent of employees have individual offices.there’is. little Justification for including an attribute Office_number in the EMPLOYEE relation; rather, a relation EMP_OFFICES(Essn, Office_number) can be created to include tuples for only the employees with individual offices. 4.3.4 Generation of Spurious Tuples = Consider the two relation schemas EMP_LOCS ‘and EMP_PRQJ1 which can be used instead of the single EMP_PROJ EMP_LOCS Eneme _| Plocation PK. EMP_PROH ‘Seq ] Phumbet | Hours | Priamel| Plocation PK = Atuple in EMP_LOCS means that the employee whose name is Ename works on some (project whose location is Piocation = Avtuple in EMP_PROJ1 refers to the fact that the employee whose Social Security ‘number is Ssn works Hours per week on the project whose name, number, and location are Pname, Pnumber, and Piocation.ae =F pied a [40a] eae | ow 7300 [eat [se 7 So eee gr [ae Patt | Sagat 3) 100] Preset | stn a a eo a an | 300 | peweoase | Ta [100 | Gonpeomicior | Sead 10 [350 | Campasiatioy | Suir 30 | 60 | rman | Sed 30 [900 | Newbie | Seed 2 [180 | Regine | Houten ee = Suppose that we used EMP_PROJ1 and EMP_LOCS as the base relations instead of EMP_PRO4J. This produces a particularly bad schema design because we cannot recover the information that was originally in EMP_PRO4 from EMP PROJ1 and. EMP_LOCS “th «If we attempt a NATURAL JOIN operation on EMPJPROJ1 and EMP_LOCS, the result produces many more tuples than the original sel of tuples inEMP_PROJ = Additional tuples that were not in EMPLPROJ are called spurious tuples because they represent spurious information that is not valid + The spurious tuples are marked by asterisks (") “ont, oh ae agate eae Thr aren ihe Fan Sah ia [eg ne 7 2 a 1 2 a a te 2 mi + Decomposing EMP_PROJ into EMP_LOCS and EMP_PRO4I is undesirable because when we JOIN them back using NATURAL JOIN, we do not get the correct original informationThis is because in this case Plocation is the attribute that relates EMP_LOCS and EMP_PROJ1, and Plocation is neither a primary key nor a foreign key in either EMP_LOCS or EMP_PROJ1. Guideline 4 Design relation schemas so that they can be joined with equality conditions on attributes that are appropriately related (primary key, foreign key) pairs in a way that guarantees that no spurious tuples are generated ‘Avoid relations that contain matching attributes that are not (foreign key, primary key) combinations because joining on such attributes may produce spurious tuples.4.4.4 First Normal Form Defined to disallow multivalued attributes, composite attributes, and their combinations Il-states that the domain of-an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute ‘ANF disallows relations within relatons or relations as attribute values within tuples The only attribute values permitted by INF are single atomic (or indivisible) values. Consider the DEPARTMENT relation schema shown in Figure below (a) DEPARTMENT Dname | Doumber | Dmgrsen | Diocations Primary key is Dnumber We assume that each department can have a number of locations= The DEPARTMENT schema and a sample relation state are shown in Figure below DEPARTMENT Dname | Doumber | Dmgr_ssn Diocations Research 5 399445555 | (Bellaire, Sugarland, Houston) Administration] 4 987654921 | (Stafford) | Headquarters 1 888668556 | (Houston) " As we can see, this is not in 1NF because Diocations is not an atomic attribute, as illustrated by the first tuple in Figure « There are two ways we can look at the Diocations attribute: * The domain of Diocations contains atomic values, but some tuples can have a setiof these values. In this case, Diocations is not functionally dependent on the primary key Dnumber * The domain of Diocations contains sets of values and henee is nonatomic. in this case, Dnumber—Dlocations because each setis considered a single member of the attribute domain = Ineither case, the DEPARTMENT relation is not in iNF There are three main techniques to achieve first normal form for such a relation: 1. Remove the attribute Diocations that violates 1NF and place it ina separate relation DEPT_LOCATIONS along with the primary key Dnumber of DEPARTMENT. The primary key of this relation is the combination {Dnumber, Diocation}. A distinct tuple in DEPT_LOCATIONS exists for each ocation of a department. This decomposes the non-1NF relation into two 1NF relations. . Expand the key $a that there will be a separate tuple in the original DEPARTMENT relation for each location of a DEPARTMENT. In this case, the primary key becomes the combination (Dnumber, Diocation}. This solution has the disadvantage Gt introducing redundancy in the relation ns DEPARTMENT Drama | Dnumber | Dmgrssn | Diocation Reseach | 5 933445555 | Bellaire Research | 5 399445556 | Sugarland Research 5 999445555 | Houston Administration| 4 987854921 | Statford Headquarters | 1 ‘888665555 | Houston3. Ifa maximum number of values is known for the attribute—for example, if it is known that at most three locations can exist for a department—replace the Diocations attribute by three atomic attributes: Diocation1, Diocation?, and Diocation3. This solution has the disadvantage of introducing NULL values if most departments have fewer than three locations. Querying on this attribute becomes more difficult; forexample, consider how you would write the query: List ‘the departments that have ‘Bellaire’ as one of their locations in this design. Of the three solutions, the first is generally considered best because it does not suffer from redundancy and it is completely general, having no limit placed on ‘a maximum number of values First normal form also disallows multivalued attributes that are themselves composite. These are called nested relations because each tuple can havea relation within it, fa) EMP PROJ [Use Enane Figure above shows how the EMP_PRO4J relation coulld appear if nesting is allowed Each tuple represents an employee entity, and a relation PROJS(Pnumber, Hours) within each tuple represents the. employee's projects and the hours per week that ‘employee works on each project. The schema of this EMP_PROJ-relation can be represented as follows: EMP_PROJ(Ssn, Ename, (PROJS(Pnumber, Hours}}) Ssn i6 the primary key of the EMP PROJ relation and Phumber is the partial key of the ‘nested felaltion;!that is, within each tuple, the nested relation must have unique values of ‘Prumber To normalize this into 1NF, we remove the nested relation attributes into a new relation and propagate the primary key into it; the primary key of the new relation will combine ‘the pattial key with the primary key of the original relation Decomposition and primary key propagation yield the schemas EMP_PROJ1 and EMP_PROU2, EMP_PROJ2 Sen Pnumber Hours EMP_PROJEMP PROJ ‘Sen Ename Prumber | Hours 123456789 | Smith, John B 1 325 [a5q48045a | English, Joyoe A 399445655 | | Wong, Franklin T. 4.4.5 Second Normal Form = Second normal form (2NF) is based on the concept of full functional dependency = A functional dependency X —+ ¥ isa full functional dependency if removal of any attribute A from X means that the dependency does not hold any more: that is, for any attribute A X, (X= {A}) daes not functionally determine ¥ = A functional dependency XY isa partial dependency if some attribute A © X can be removed from and the dependency still hols; that is, for some Ae X, (X -{A}) — ¥ EMP PRO) Fot ape Ss — 4 FD2 FD3 = In the above figure , {Ssn, Pnumber} — Hours is a full dependency (neither Ssn — Hours nor Phumber—Hours holds) = {Ssn, Pnumber}—Ename is partial because Ssn—Ename hokis "Definition. A relation schema R is in 2NF if every nonprime attribute A in R is fully functionally dependent on the primary key of R = The test for 2NF involves testing for functional dependencies whose left-hand side attributes are part of the primary key = Ifthe primary key contains a single attribute, the test need not be applied at allThe EMP_PROJ relation is in 1NF but is notin 2NF. The nonprime attribute Ename violates 2NF because of FD2, as do the nonprime attributes Pname and Plocation because of FD3. The functional dependencies FD2 and FD3 make Ename, Pname, and Plocation partially dependent on the primary key {Ssn, Pnumber} of EMP_PRO4J, thus violating the 2NF test. If a relation schema is not in 2NF, it can be second normalized or 2NF normalized into a number of 2NF relations in which nonprime attributes are associated only with the part of the primary key on which they are fully functionally dependent, Therefore, the functional dependencies FD1, FD2, and FD3 lead to the decomposition of EMP_PRQ\ into the three relation schemas EP1, EP2, and EP3 shown in Figure below, each of which is in 2NF. emp pros (ita. [Emumer [Hou Fot ‘ Fo mm INF Normalization Pt fe Eps San [Poumter [ooo] [igen femme | [Paoba | Frame | Piocation eoL_ | ae we | 4 4 4.4.6 Third Normal Form ‘Transitive functional dependency A functional dependency X—Y in a relation schema R is a transitive dependency if there exists a set of attribute Z thal are neither a primary nor a subset of any key of Ricandidate key) and both X > 2 and ¥ > Z holds Example: EMP_DEPT _ : [Ename | Ssn Dname | Oimgresn | es 4 + SSN > DMGRSSN is a transitive FD since SSN > DNUMBER and ONUMBER > DMGRSSN holdDnumber is neither a key itself nor a subset of the key of EMP_DEPT + SSN > ENAME is non-transitive since there is no set of attributes X where SSN > X and X 3 ENAME Definition: A relation schema R is in third normal form (3NF) if it is in 2NF and no non-prime attribute A in R is transitively dependent on the primary key The relation schema EMP_DEPT is in 2NF, since no partial dependencies on a key exist. However, EMP_DEPT is not in 3NF because of the transitive dependency of Dmgr_ssn (and also Dname) on Ssn via Dnumber EMP_DEPT [Ename | Ssn | Bdaie | Address | Dnumber | Daemed]) Dmarssn |] 4 | 4 4 4 : it a We can normalize EMP_DEPT by decomposing it into the two 3NF relation schemas ED! and ED2 EMP_DEPT Ename | Sen | Bdate | Addiasel] Onanber | Drama) Dinar sen | 4 | 4 et { { NF Normalization | £01 ep? Enaine | Sen, [BAe [Radrest] Gruber] | Dounber [Dname [ Omg en Se ol Waite, WL 4 [ef ED} and ED2 represent independent entity facts about employees and departments A NATURAL JOIN operation on ED1 and ED2 will recover the original relation EMP_DEPT without generating spurious tuples Problematic FD * Left-hand side is part of primary key + Left-hand side is a non-key attribute 2NF and 3NF normalization remove these problem FDs by decomposing the original relation into new relations In general, we want to design our relation schemas so that they have neither partial nor transitive dependencies because these types of dependencies cause the update anomalies4.6 Boyce-Codd Normal Form = Boyce-Codd normal form (BCNF) was proposed as a simpler form of 3NF, but it was found to be stricter than 3NF = Every relation in BCNF is also in 3NF; however, a relation in 3NF is not necessarily in BCNF = Definition. A relation schema R is in BCNF if whenever a nontrivial functional dependency XA holds in R, then X is a superkey of R = The formal definition of BCNF differs from the definition of 3NF in that condition {b) of 3NF, which allows A to be prime, is absent from BCNF. That makes BONF a stranger normal form compared to 3NF = In our example, FDS violates BCNF in LOTS1A because AREA is not a superkey of LOTS1A = FDS satisfies 3NF in LOTS1A because County_name is a prime attribute (condition b), but this condition does not exist in the definition of BCNF: = We can decompose LOTS 1A into two BCNF relations LOTS1AX and LOTSIAY. This decomposition loses the functional dependency FD2 because its attributes no longer coexist in the same relation after decomposition. LOTS1A Property_id# |) County_name me ‘Area For 4 aot ogi Wea | + FDS BCNF Normalization LoTsiax LoTsiay [Proper ai | Area [Lott [Brea] County name * In practice, most relation schemas that are in 3NF are also in BCNF = Only if +A holds ina relation schema R with X not being a superkey and A being a prime attribute will R be in SNF but not in BCNF = Example: consider the relation TEACH with the following dependencies:Student Couns Instructor Narayan | Database | Mark ‘Smith | Database Navaths ‘Smith | Operating Systems | Ammar Smith | Theory Schulman ‘Wallace | Database | Mark ‘Wallace | Operating Systems | Ahamad [Wong |CGatabase =| Omi Zelaya | Database Navathe Harayan | Operating Systerns | Ammar FD1: (Student, Course} — Instructor FD2; Instructor Course — means that each instructor teaches one course {Student, Course} is a candidate key for this relation The dependencies shown follow the pattern in Figure below with Student as 4, Course as 8, and Instructor as C R [i al ele) FDi 4 FD2 4 Hence this relation is in 3NF but not BCNF: Decomposition of this. relation schema into two schemas is not straightforward because it may be decomposed into ane of the three following possible pairs: 4. Ri(Student, Instructor) and R2{Student, Course) 2. R1(Gourse, Instructor) and R2(Course, Student! 3. Ri (instructor, Gourse}and R2(Instructor, Student) It is generally not sufficient to check separately that each relation schema in the database is, say, in BCNF or 3NF Rather, the process of normalization through decompesition must also confirm the existence of additional properties that the relational schemas, taken together, should possess. These would include two properties: «The nonadditive join or lossless join property, which guarantees that the spurious tuple generation problem does not occur with respect to the relation schemas created after decomposition. + The dependency preservation property, which ensures that each functional dependency is represented in some individual relation resulting after decomposition.We are not able to meet the functional dependency preservation ,but we must meet the non additive join property Nonadditive Join Test for Binary Decomposition: A decomposition D={Ra, Ry} of R has the lossless join property with respect to a set of functional dependencies F on R if and only if either + The FD ((R:-Ra) —(R-Ry)is in F” or + The FD ((RieRz) —+(R:-Ri)is in F* The third decomposition meets the test Run R is Instructor Ri-R2 is Course Hence, the proper decomposition of TEACH into BCNF relations is: TEACH1 (Instructor, Course) and TEACH2(Instructor, Student) in general, a relation R not in BCNF can be decomposed so as to meet the nonadditive join property by the following procedure. It decomposes R silccessively into set of relations that are in BCNF: Let R be the relation not in BCNF, let X —-R, and let X — A be the FD that causes violation of BCNF..R may be decomposed into two relations: R-A XA if either R-A or XA is not inBCNF, repeat the process 4.7 Multivalued Dependency and Fourth Normal Form = For@xample, consider the relation EMP shown in Figure below: EMP | Smith Smith = A tuple in this EMP relation represents the fact that an employee whose name is Ename works on the project whose name is Pname and has a dependent whose name is Dname = Anemployee may work on several projects and may have several dependents = The empbyee's projects and dependents are independent of one another‘To keep the relation state consistent, and to avoid any spurious relationship between the two independent attributes, we must have a separate tuple to represent every combination of an employee's dependent and an employee's project In the relation state shown in the EMP, the employee Smith works on two projects '* and “Y and has two dependents ‘John’ and ‘Anna’ and therefore there are 4 tuples to represent these facts together ‘The relation EMP is an all-key relation (with key made up of all attributes) and therefore no f.d's and as such qualifies to be a BCNF relation ‘There is a redundancy in the relation EMP-the dependent information is repeated for ‘every project and project information is repeated for every dependent To address this situation, the concept of multivalued dependency(MVD). was proposed and based on this dependency, the fourth normal form was defined Multivalued dependencies are a consequence of 1NF which disallows an attribute ina tuple to have a set of values, and the accompanying process of converting an unnormalized relation into 1NF Informally, whenever two indepéndent 1:N felationships are mixed in the same relation, R(A, B, C), an MVD may arise4.8 Join Dependencies and Fifth Normal Form = A join dependency (JD), denoted by JD(R1, R2, ..., Rn), specified on relation schema R, specifies a constraint on the states r of R. The constraint states that every legal state r of R should have 2 nonadditive join decomposition into R1, R2, ..., Rn. Hence, for every such r we have = (mp,("), Tp,(r), soe Mey (1) = =) A join dependency JD(R1, R2, ..., Rn}, specified on relation schema R, isa trivial JD if one of the relation schemas Ri in JD(R1, R2, ..., Rn) is equal to R. Fifth normal form (project-join normal form) * A relation schema A is in fifth normal form (SNF) (or project-join normal form (PUNF)) with respect to a set F of functional, multivalued, and join dependencies if, for every nontrivial join dependency JD(R1. R2, .... Ri)in F” every Riis a superkey of R. = A database is said to be in SNF, if and only if, + It's in 4NF+ If we can decompose table further to eliminate redundancy and anomaly, and when we re-join the decomposed tables by means of candidate keys, we should not be losing the original data or any new record set should not arise. In simple words, joining two or more decomposed table should not lose records nor create new records. Fig: Decomposing the relation SUPPLY into the 5NF relations R1, R2, R3.5.2.3 Why Concurrency Control Is Needed Several problems can occur when concurrent transactions execute in an uncontrolled manner Example: + We consider an Airline reservation DB + Each records is stored for an airline flight which includes Number of reserved seats among other information. . + Types of problems we may encounter: 1. The Lost Update Problem. 2. The Temporary Update (or Dirty Read) Problem 3. The incorrect Summary Problem 4. The Unrepeatable Read Problem read_item(X); read_item(X); X=X+M; X=X-N; write_item(X); write_item(X); read_item(Y); Y=Y+NA; write_item(Y);1. The Lost Update Problem = Transaction T1 «transfers N reservations from one flight whose number of reserved seats is stored in the database item named X to another flight whose number of reserved seats is stored in the database item named Y. = Transaction T2 + reserves M seats on the first flight (X} = occurs when twe transactions that access the same DB items have their operations, interleaved in a way that makes the value of some DB item incorrect = Suppose that transactions T1 and T2 are submitted at approximately the Same time, and suppose that their operations are interleaved as shown in Figure below th qh read_item(X); X=X-N, read_tem(X); X= Xe Mp Time | | write_item(x}; read_itam{¥); write_item(X7; Y=SYan: write_item(Y); Item X has an incorrect value because its update by 7; is Jost (overwritten). = Final value of item X'is incorrect because T2 reads the value of X before T1 changes it in the database, and hence the updated value resulting from T1 is lost. For example: X = 80 at the start (there were 80 reservations on the flight) N= 5 (T1 transfers 5 seat reservations from the flight corresponding to X to the flight corresponding to Y) M=4 (T2 reserves 4 seats on X) The final result should be X = 79. The interleaving of operations shown in Figure is X = 84 because the update in T1 that removed the five seats from X was lost.2. The Temporary Update (or Dirty Read) Problem = eccurs when one transaction updates a database item and then the transaction fails for some reason = Meanwhile the updated iter is accessed by another transaction before it is changed back to its original value yy, I read_item(X); X=X-N, write_item(X) Time read_item(X); X=X4M; vwrites_iteen( X); tead_item(¥); ‘Transaction 7; fails. and must change the value of X back to its old value; méanwhile T, has read the temporary 3. The Incorrect Summary Problem incorract value of X. + If one transaction is calculating an aggregat summary function on a number of db items while other transactions-are updating some: of these items, the aggregate function may calculate some values before they are updated and others afer they are updated. tead_itom( YoYen write_tem{); q um = 0; varad Hota; sum = sum +A; ead temX); sur = sum +X, Tyreads X alter Nis subtracted and reads Fe nent, | — Ybslowe Wis added: a wrong sumenary sum um + isthe result (lf by 4).4. The Unrepeatable Read Problem Transaction T reads the same item twice and gets different values on each read, since the item was modified by another transaction T° between the two reads. for example, if during an airline reservation transaction, a customer inquires about seat availability on several flights When the customer decides on a particular flight, the transaction then reads the number of seats on thal flight a second time before completing the reservation, and it may end up reading a different value for the item. 5.2.4 Why Recovery Is Needed Typ Whenever a transaction is submitted to a DBMS for execution, the system is responsible for making sure that either 1. All the operations in the transaction are completed successfully and their effect is recorded permanently in the database or 2.The transaction does not have any éffect on the database or any other wansactions In the first case, the transaction is said to be committed, whereas in the second case, the transaction is aborted if a transaction fails after executing some of its operations but before executing all of them, the operations already executed must be undone and have no lasting effect. es of failures 1, A computer failure (system crash): + A hardware, software, or network error occurs in the computer system during transaction execution « Hardware crashes are usually media failures—or example, main memory failure. 2. A transaction or system error: ‘Some operation in the transaction may cause it to fall, such as integer averflaw or division by zero + Also occur because of erroneous parameter values 3. Local errors or exception conditions detected by the transaction: + During transaction execution, certain conditions may occur that necessitate cancellation of the transaction+ For example, data for the transaction may not be found 4, Goneurrency control enforcement: +The concurrency control may decide to abort a transaction because itviolates serializability or several transactions are in a state of deadlock 5. Disk failure: + Some disk blocks may lose their data because of a read or write malfunction or because of a disk read/write head crash. 6. Physical problems and catastrophes: + refers to an endless list of problems that includes power or air-conditioning failure, fire, theft, overwriting disks or tapes by mi = Failures of types 1, 2, 3, and 4 are more common than those of types 5 or 6 = Whenever a failure of type 1 through 4 occurs, the system must keep sufficient information to quickly recover from the failure. * Disk failure of other catastrophic failures of type 5 of 6 do not happen frequently; if they do ‘occur, recovery is a major task.