Database Management System [18CS53, Wain ion yp DB design le eee vatlbasslteegttneeae— the ter, Database Des gn Thee — j 4.3.2 Redundant Information ne TUples and OPOMS ANOMONCS 4.35N Ubntraduationn Tuples 4.24. Generation of Spurious Tuples Funetlohal Dependencies 4.44 Normalization of Relations 4 44 4.6 Boyce-Codd Normal Form 4.7 Multivstiobd DEpestioael snoffNortha\ianmsPorm 4.7.1 Férinbadeitins a Ok arg end Herbals Restiginaling in Keys 4.8 Join Debdndidicie Nonmetiemormal Form 4.9 Inferendehgukscnndi Naemahdiaependenecies Fquivathdee Bhd NormahEasinl Dependencies deés Seneca Daiimejamagiseeend and Third Normal Form 4.12. Properties of Relational Decompositions. Algorithms for Relational Database Schema Des 4.13.1 Dependeney-Preserviny and Nonaditive (Lossless) Join Decomposition into 3NF Schemas 4.10 4. 4.13 4.13.2 Nonaddit e Join Decomposition into BCNF Schemas 4.13.3 Dependeney-Preserving and Nonadditive (Lossless) Join Decomposition into 3NF Schemas 4.14 About Nulls, Dangling Tuples, and Alternative Relational Designs 4.14.1 Problems with NULL Values and Dangling Tuples 4,15 Other Dependencies and Nosmal Forms 4.15.1 Inclusion Dependencies 4.15.2 Template Dependencies: 4.15.3 Functional Dependencies Based on Arithmetic Functions and Procedures 4.154 Domain-Key Normal Form 4.16 Assignment Questions 7. Expected Outeome §. Further Reading Dept. of CSEATMECE, Mysur PageDatabase Management System [18CS53, database 4.0 Introduetion Database is @ technique of organizing the date in is Nonsyieatistic approact of decomposing tables toy redunddoayaiteitimdesirable characteristics ike Insertion, Update and Deletion iis cate It is a muki-step process that puts data into tabulat form by removing duplicated data rer ‘ies. the relation tables, This module discuss the basic and higher normal forms, he 4.1 Objectives To study the process of normalization and refine the database design To normalize the tables upto 4NF and SNF To study lossless and lossy join ope tions To study inference rules To study other dependencies and Normal Forms daichii pte ttceoantemtalanidinsteiDowe (rehecessuntod that attributes are groupec can d&@itatrochoctiondoeBBrdesigns Eact relation scheme consists of = number of attributes, and the relationalatabase scheme to form a relation schema by using the common sense of the database designer or by mapping @ database scheme desigr from @ conceptualata model such as the Eor — hanced-ER «€ ‘These models make the designer identify entity types and relationship types and their respective attributes, which nd logical grouping of the attributes inte relations, There levels at which we 1.The (or conceptual) level—howsers interpret the relation schemagnd the 2.The implementation (or physical storage) ‘evel—hovhe tuples in @ oase relation are This leve An Example = DEPARTMENT relation with attributes: deptName, officePhone, hoc = Severa ™ studDept gives the name of the student's department Correct schema Student Department StudName | rollNo | gender | studDept | [deptName | officePhone HOD [LfDatabase Management System [18CS53, Incorrect schema: Studdept SudName gender deptName | _officePhone HOD legeples to determine the qua of Problems with bad schema + Redundant storage of data Office Phone &HOD that pelongs to the department - wastage of disk space » A program that updates Office Phone of a department snust change dlaces = more running time 4.3. Informal ide . informa lity relation schema design 1 is 2 niformatiom tuples 3.Reducinge values in 4, Disa 7 "These measures are not always independent of one another Imparting Clear Semantics to Attributes i Relations ™ semantics of a relation refers toits meaning resulting from the interpretation of attribute valuesin =" Whenevewe gp attribute form a relation schema we that attributes to one ‘elation nave certair real-worke and proper interpretation associated with them "The easier if to explain the semantics of the relation, the better the relation scheme design will oe i 1 Design a relation schema so that it easy to explair its = Do not combine attributes from multiple entity types ancrelationship types into a relation Dept. of CSEATMECE, Mysuru le PageDatabase Management System [18CS53, . ifa elation schema corresponds to one entity type or one relationship type it is seraanie ambjgutios wl result an the elaon canjat be easily explanec Examples of Violating Gi raighiforward tc interpret and to explain its if the relation corresponds to a mixture of multiple entities and relationships, ine 1 EMP_DEPT epirinkarsrmiissat leslikkhrettipioyietrs won ct greeicttseealisy th trieORiN EMD PROD = moore ssn | PNUMBER | Hours | ENAME | PNAME | PLOCATION Fig: schema diagram for company database ® Both the relation schemas have clear semantics "A inthe EMP_DEPilation scheme represents a single employee out includes informationthe rame (Dname) of the department for which the employee "A tuple ir the EMP_PROcelates an employeéo a oroject but also ncludes the employee name (Ename), project name (Pname), and projectlocation (Plocation’ . line 1 world entities: * EMP IP _ON relationsh "They may be used as views, but they cause problems when used as base relations étiesior 4.3.2 Redundant Information i and 1 "One goa is to minimize the storage space used by the base relations * Grouping attributes into relation schemas has a significant effect on storage space = For examplecompare the space used by the two dase relations EMPLOYEfind DEPARTMENT EMP_D = In EMP_DE the attribute values pertainingo 2 particular department u Dname, Dmgr_ssn) are repeated for every employee who works for that department Dept. of CSEATMECE, Mysur Page 4Database Management System [18CS53, = In-contrast, each department's information appears only once ir the DEPARTMENT Only the depariment number Dnumber is repeatec inthe EMPLOYEfplation for each employee who works in that department as a foreign key ‘elatior Figure 1: One possible database state for the COMPANY relational database scheme EMPLOYEE [re [weit | trame | Se | Be ‘sos ef Say [Supe son [m0 tain |B [smn | 129456760 | 1065.01.00] 751 Fondren Hooton Te] mt [s0000 fsaneassss | 5 Feniia | T [wong | 999445585 |1055-1200]696 Voss Houten 1x [wm [4c000 fooesessss | 5 ‘Aica_|_1 | Zniyn | 900067777 | 1060:01-10[9971 Caste, Sing. TX_| F [25000 Joovesea21 | 4 Dennfer | S| Wate 967654921 | 1941-0620]201 Bory Beta, TX | F [49000 Josasessss | « Ranesh | K_[ nayan| sseeeee [10670615] 975 Fre Oak Humble. Tx| wi [ae000 (09445565 | 5 foyce [A [ vaio [ 804050 [10720731 [5601 in Howson Tx [F [asoo0 fsaeasees | 5 ‘vad [_v_[ obbor_[ 987987967 | 1060-0875] 960 Date Hooton. TX | M_[aso00 Joe7esea21 | 4 Dares | € [org [090865555 | 1057-11-10 | 450'Sore Hourton TK | M_|ss000 ULL | 1 DEPT_LOCATIONS DEPARTMENT aaa CRS ‘rae | Bowmber |g Mgr na ate i sia ‘ecearoh 3 | sazaasss5 | 1988.05.02 ‘srineteen | 4 | 9a7e5a001_| 1996.01.01 + _| Stafford Hesdzeartrs ee 8 | Batsire 3 | Sugarand 5 __| Houston Dept. of CSEATMECE, Mysuru PageDatabase Management System [18CS53, prover ae Fane | Prumber [ Pecaton | Oaum os Be Hee Pik + [pate | 5 Wee Se [asses [2 [a5 Prods 2 _[Swatand [= ar ee eoseeaeae | 8 | 400 Conpusianion | 10_[ Sted [4 so ee Reorganization | 20 [Hewson | 4 sees || 2 | at Rewbensits | 80 [Stand | [seeps [2 lines asseasees [a | 100 DEPENDENT ([Boaeessss [10 | 100) Foon Dependent name [gendel Bate | Rolatonship soacasnss | 20 | 100 aaa445555 | Alice F_| 196606:05 | Daughter ‘sssearrn | a0 | 200 ‘309445555 _| Theodore M_| 1969-1025 | Son sssearr7 | 10 | 100 200445555 | Joy F_| 195605.03 | Spouse sereoree? | 19 | aso (67054921 | Abner M_| 19420228 | Spouse [aersoree7 [a0 | 60 123466760 _| Niches M_| 1266-07-06 | Sen varesaar | 30] 200 128456780 _| Alice F_| 1966-120 | 0. oeressaa1 [20 | 160 129456780__| Elaabath F_| 1987.0505 | Spouse [fevceebose [ad | aL Figure 4One possible database state for the COMPANY relational database schema Redundancy EMP DEPT | Ena Sa fates __‘[Dnanber [Grane [ Org] [Smith Jor 6. [123456706 [1965-01-00 [731 Fondren Houston Tx] 5 | Rescarch | 404446565 | wong, Frankie T | ses4assas [1955-17-08 [838 Vans, Houston, | 5 | Research | a3a4a5e55 Zoleya Aicias, [000887777 | 10680710 |3321 Caste Spring. TK | 4 | Admncvaion | 067654321 Walace, Jennifer S, [987654321 | 1041-06-20 | 901 Bary, Balare, Tx | 4 | Admnewaton | OB7ES4301 Neyer, Ramosh K [565684444] 1962.00.16 [075 FroOak Humbio. Tx | 6 | Ressarch | su34absb6 [Engish Joyce A_|<53460489 | 1972.07.31 [6631 Rice, Heuston. TK [5 | Research | sua4a5s05 Jabber Atmad\V_ [207007987 | 1969-03-29 | 980 Daina Houston IX | 4 | Admnatmton | 967554091 [aor Janes E [38665686 |1997-11-10 [480 Store. Houston, IX | 1 | Headquarters | BEBGESEES ogee? | 10 | 100 _| Zama Abas | Computniention | Stor aruerae? | —10—| asd | lai, And | Oartcton | Sted se765ss21 | 30 | 00 | Wes rer S| Nowtensts | Sued sonesssss | 20 —[ Wt [rm Jones | Resmaiaton | Howson DEPT and EMP_PRO\ resulting from applying NATURAL JOIN to Fig Sample states for EMP the relations in Figure Dept. of CSEATMECE, Mysuru PageDatabase Management System [18CS53, aurraygey ios taoreatened to as eet eicatpieasd Offinesedt tecause 0 NT lies ' lies, ' lies I m1 anomelieean oe differentiated into two types lustratedy the following examples based on the EMP_DEPT 1.7c insert a new employee tuple into EMP_DE we must include either the attribute values for the department that the employee or r example, tc insert a new tuple for an employee who works in department number Swe must enter all the attribute values of department § correctly so that they are consistenwith the corresponding values for department 5in other tuples in EMP_DEPT = Ithe of Employein fig we do not have to worry about this consistency problem because we enter only the department nu in the employee tuple: all other attribute values of department 5 are recorded only once in the database as a le inthe DEPARTMEN?lation 2. I d It insert a new department that has no employees as yetin the EMP_DEPT The only waytodothis lace = LL_——_in the attributes for employee : P_DEP isits primary key : because a department is enterec n the DEPARTMENT relation whether or not any employees work for i, and whenever an employecis assigned to that department, a corresponding tuple is insertec in EMPLOYEE. 1 liek related to the secone insertion anomaly situation just discussed ifwe delete from EMP_DEP last employee working for a particular department, theinformation concerming that department lost from the database EPARTME Dept. of CSEATMECE, MysuruDatabase Management System [18CS53, Dept, of C \TMECE, Miysardy ication Anoma ies ont Hibias oomatacer n diferent employee tuples, which would be wrone © In EMP_DE —fwe change the value of one of the attributes a particular department—say the manageof departmen§—we must update the tuples of all employees whc work in that department otherwisethe database wil become inconsistent "Iie fail to update some the same departmentill be shown to have two ahaha amiiinestentinapecasind suctaasGSlavar SUN 2 . fthe base relation schemasso that no nor anoma in the relations = Kiny anomeliesre present, note them clearly and make sure that the programs that . ling consistent with and line = These may sometimes have to be violatec in order to improve the 4.3.3 Lt i . tuples in the relation, we end up with many in those tuples this can waste space at the storage level ‘may ead to problems with understanding the meaning of the attributes ‘may also lead to problems with specifying JOIN operations - Tate applies * SELECT and JOIN operationfwvolve comparisons if —_values are oresent, the = Moreover UL llowing ' example Visa to S. students, The attribute value for this tupleis _ unknown Date_of_birthay , ss known but absent; thatis, example the Home ileble Guideline I Page 8Database Management System [18CS53, «As far ag POSSbIe avaic dlacing attributes in a base velatior whose values May treay have NULs a ere make sure that they apply cases only and do ‘not apply to a majority of tuples in the relation = Using space efficientlpnc joins with Llvalues are the two criteria that determine whether to ir avelation or to have a separate relation for those columns with the appropriate key columns "For example, ifnly 1$ercent of employeebave offices there is little justification for ncluding an attribute Office_nu inthe EMPLOYE a ‘elatior ~EMP_OFFICES(Essn Ucar be created te nclude tuples for only the employees with offices 4.3.4 Generation of Spurious ™ Consider the twe ‘elation schemasEMP_LOCGnd EMP_PROJi can be used instead of the single EMP_PROJ EMP _Locs. Ename | Plosation T PK EMP PROM ‘Sso [ Prumber | Hours | Prams | Plecation T PK. Stetdhdgere, Prurike SaneéAtscthtthe employee whose name project wh8se location is BWBation Jame works on some "A ip EMP_PROJtefers to the fact thal the employeehose Social nu 's Ssn works Hours per week on the project whose name, number, and location Dept. of CSEATMECE, Mysuru PageDatabase Management System [18CS53, up toes MP PRN ‘rane Pleaton ‘Sen | Phonber [Hows | — Prana: ‘Smif Jom 6. Boars Taare || 326 | Pwo ‘tk Jom. —[ Super] [12550700 | 2 [75 | ane Navan Ranesh [Howson] [seesaeeae | 3 | 100 | roma engin. Joj3A| lane RGHEES | 1 [ 0 | Pet EnoiehJeyonA | Suoriend | [suasveer [2-200 | Pac Wong. Renita Saget] [SISNS655 [9 [100 | Poe Wo Faldo [Hwan | [aosasess [a [100 | Pomc Wong Fenlie 7. Stas | [sates [10 | 100 | Compson Zeige, Alin | Staind | [sa0e6 | 20 [100 _| Reopenter Witace, rier [Sioa] [Ss00urr77 | —T0 100] Campsie Wisoce mnie |ourin | [serooeer | 10 | 250 | Genputreten ‘ges [ Hour | [sovomoer | 20 | 60 | Newtenta aresasor | — 90 | 20 | Newborn serosa | 20 [150] Reaptcn aaeeses6s | — 20 —[ ROTC Reaprt | os ioheraat ‘ase relations nsteac FuP-PROM Ts predocess partes scheme hfitecaoe we cana of recover the information that was originally in EMP_PROJ from EMP_PROJ1 and EMP LOCS . TURA EMP_PRO.ind EMP_ in EMP_PROJ = ition in EMP represent spurious information that is 1 The spurious tuples are marked by asterisks (" + [rzatseros [1 [axe [recor | Bale | Engl Je ‘aaaseraa | 2 | 18 [Peay | sipping | Jt. + fies 2 [15 [Peer [sug | engi 1)00A + [iagusemo [2 [a5 [Preuere | Sunt | wera, rei 2 3 | 400 [retuaz | Westen —| Weg, ren rezurausa [1 | 200 | reduoe [tans | Erie Jyce + [assess | 2 [200 [redo [satin [sri te sausuiss [2 | 200 |Predur? | Suge | erie, + Jasoessess | 2 [200 [Pree | Sigstnd | Weng Fn ssseesces [2 | ioo [essa | Suton | smn cins ~ [success [2 [100 [peter [swt | eras Joce A sseessss [2 | 100 [Presa | sugatin | Wer, en rzsianess [a —| Too [Pega | Haten —[ Wr, Fn aogeaeess | 10 | 100 | Conpuersion | Stor Fea. + fesauassss | 20 Naren Ramos * Decomposing EMP_PROintc EMP_LOC&nc EMP_PROvis undesirable because wher we them back using we de not gel the correct informatior S=———————— Dept. of CSEATMECE, Mysuru Page 10Database Management System [18CS53, irwe | 2 is oecause ip case Plocation is the attribute that relates Ee sOCS ang “ SSeiher a oman key Roa Rey in either EMP_LOCS EMP_PROJ1 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 matchingttributes that are aol (foreign Houholds) . Enamis pattia Enameolds * Definitions relation scheme R isin 2 very attribute A in R is nation 'SRIRE primary key contains a single attribute, the test need not be app = The test for 2 involves testing for functionadependencies whose left-hand side attributes are part of the primary key . lie Dept. of CSEATMECE, Mysuru Poge 18Database Management System [18CS53, 2 The EMP_PRO\ relation is in 1 but i isnot ine Maas coneeLe Ehame VOI. 2 occause oF EBYO'RE"BS"the _nonprime attributes Pname and Plocation because of FDS "The functionailependencies FD2 and FD3 make lame, Pname anc Plocation EMP 2 * ifavrelation scheme is nol in _t can be second normalized or 2NF normalized into @ nu of 2. relations in nonprime attributes are associatec only with the lly functionally dependent. . FD2 and D3 lead to the decomposition of EMP_PRQiito the three relation schemas EP2 and EP2 shownin —_U below each isin 2 F Mp pros (Sin [nn [Hews [Eons [Phan [Rosato] 4 aT) | ro | mations | ee v2 (ser Tenants Trews] sen Tesane ] fae Poi a a a Ribttiatige functional dependency 4.4.6 i Form A dependency Xin a relation scheme Rs a transitive dependency there exists a set of attribute Z that are neither a primary nor a subset of any key of Ricandidate key) and both X > Z anc Y > Zholds = Example EMP_DEPT Ename | Sen | dato | Adeross | Grumber | Drama | Dage san + | + 4 4 { 1 1 FD since SSN > DNUME * SSN > DMGRSSN. EGnd > DMGRSSN hold Dept. of CSEATMECE, Mysur Poge 19Database Management System [18CS53, Eeelfineesabibboethelkey ot EMP_DEPT Ree SERRE TE HUNTS Ne Thole & ho cei ST cltibutes X where SSN X > ENAME * Definition: A relation schema Ris in third normal form (3NF) if 2NF and no transitively dependent on the primary key IP_DE isin since no partial dependencies on a key exist However is not in because of the transitiv@lependency of Dmgr_ssn (and also Dname) on Ssn via Dumber = The relation scheme EMP_DEPT Ename | Ssn | Bdate [ Address | Dnumber | Dname | Dmgr ssn 4 | 4 4 t { "We car normalize =MP_DE by decomposing into the two —elatior schemas ED1 and ED2 Emp DEPT Ename [Son [Sdate [Adaress [Onumber [Brame [Omg ssn | 4 i) 4 + t { {NE Normalization | ep E02 [ame [Sen [dato [Addiees [Dnunbor] [Brame [Dname | Dmgcven | p fT e 4 F Lt © D1 and ED2 represent independent entity facts about employees end departments "A operation E anc £02 will recover the ‘elation EMP_DEP * Problematic FL “Left-hand side s part of primary key teft-hand side = 2 and nomalizatioremove these oroblem FDs by decomposing the relation nto new relations . nor transttivelependencies secause these types of dependencies cause the uU anomalies Dept. of CSEATMECE, Mysuru Page 20Database Management System [18CS53, Table 18.1 Summary of Normal Forms Based on Primary Keys and Corresponding Normalization Normal Form | First (INF) Second (2NF) ‘Third (3NE) Test Relation should have no multivalued attributes or nested relations. For relations where primary key con- tains multiple attributes, no nonkey attribute should be functionally dependent on apart ofthe primary key. Relation should not have a nonkey attribute functionally determined by another nonkey attribute (or by a set of nonkey attributes). That i, there should be no transitive dependency of a non- key attribute on the primary key. Remedy (Normalization) Form new relations for each multivalued attribute or nested relation. Decompose and set up a new relation for each partial key with its dependent attrib- ue(s). Make sure to keep a relation with ‘the original primary key and any attributes that are fully functionally dependent on it. Decompose and set up a relation that includes the nonkey attribute(s) that func- tionally determine(s) other nonkey attib- ute(s). Dept. of CSEATMECE, Mysuru PageDatabase Management System [18CS53, BaGdhGeneral of i Normal Form Rbihsommuniichstanditeantie State relation "Takes * Definitiowt A relation schema R is in secon¢ normal form (2NF) ifvery R's not partially dependent on any key of R "Consider the relation schemaLOTS which describes parcels of land for sale in various counties of a state "Suppose that there are two candidate keys Property_id# and {County_name Lot#} that is, lot numbers are unique only within each county but Property_id## numbers are unique Candidate Key Lots Property id | County-name | Lot | Aroa | Price | Tax rate Ft t 4 4 Ft } roo f t 4 ‘ Fos 4 Fos 4 BDU Riaipefipeyictiainfcteripobceetshiion iT eoreadeestion w * Based on the two candidate keys Property_id#t and {County_name dependencies FD" anc =D2 nole ' Tax_rate) ' Tax_rate) ' Tax_rate ' Price . We g to this key over the other candidate key = =D3 says that the tax rate is fixed for a given county (does not vary lot by the same county) = D4 says that the price of elot s determined by its aree “egardless of which county. it "The Tax_ratis partially dependent on the candidate key {County_name, Lott}, due to FDS "Tc nomalizeOTS into 2NF, we decompose ito the two relations 4nd LOTS2 Dept. of CSEATMECE, Mysuru Page 22Database Management System [18CS53, Lorst Lors2 Propary a | Gouniyiname | Lot | rea | Price ‘County name | Tacrato Fo + a t ro f ‘4 Fos + TMF Sade chasestle PANE from = construdtOTS! by removing the attribute Ta LoTs anc placing it with County_name (the left-hand side of dependency) into another relation LOTS2 * Both AndLOTS2arein 2 F. BIFS BI dependency XA holds = Definitionf 3 A relation scheme R is in thiré normal form if whenever Nontrivial functiona in R, either (a) Xs a superkey of R, or (b) Aisa prime attribute of R * According to this definition, LOTS2 isin " =D4 in LOTS’ violates because Aree is rot a superkey an¢ Price is not a prime attribute ir 1 "Tc normalize ihto 3NF, we decompose _ ito the relation schemas ane 1 vorsia vorsis Popa [ Conia [ Tat [ea] (tesa [ce Fo1 4 , + ros|_ ro 4 ‘GQHRS1B bydemoving the attribute Price that violates 3NF from. rem oveonstucl LO ane placing it Area (the lefthand side of FD4 that causes the transitive dependency)into another relatior * Both 1 Jareir Lors 1NF Lois Lotsa 2NF Lorsia —LOTS1B_LoTs2 3NF Dept. of CSEATMECE, Mysuru Page 23Database Management System [18CS53, Page 24, Dept, of CSE,ATMECE, Mysuru Norifig Boyce-Codd —_al Form Gibkikihcictiparottdo d26mpostion "Boyce-Cod¢ normal form (BCNF) was proposes a simpler form of 3NF out vas found to be stricter than 3NF © Every relation in isalso in nowevee relation ins not necessarily in DefinitionA relation schema R is ir BCNF if whenevera _ nontrivial dependency XA holdsin R, then X s a superkey of R "The formal definition BCNF differs from the definitior of in that (bj of allows A to be prime is absent from FThat makes BCNF a stronger norma = Imur examplerDS violates in 1 Eds not a superkept 1 FDS satisfies 3NF in LOTS1A because County_name 's a prime attribute (condition b). but this condition does not exist in the definition of BCNF ™ We car decompose 1 into two relations 1 and decomposition loses the functional dependencF2 oecause its attributenc longer coexist LoTsiA Propariy id | Couniy name [Loi [Area Ft ’ oo oo 4 L | 4 Fos 4 BCNF Normalization LoTsiax Lorsiay Proper it [ea [Leth] [Arn [ Coury name ‘AFLEatribgtdependencies * In practice, most relation schemas that are in 3NF are alsoin "Only if holds ina relation schema R with X not being a superkey and A being € ip sutnotin = Example: consider the relation TEACH with foDatabase Management System [18CS53, TEACH ‘Student Course Instracor Narayan_| Database Mark Smith | Database avathe Smith | Operaing Systems [ Ammar “Seth | Thery Sehuinan Walace | Database Mark Walace | Opersing Systera | Ahamad Wong | Database Omiecinak Zelaya | Database Navathe Narayan | Operating Systeme | Ammar i aiyhich guarantees that the spurious FD1: {Student, Course} >| Instructor Course means that each instructor teaches one ™ (Student, Course} s a candidate key for this relatior . in Figure below with Student as A as B and Instructor as C R A|B\c FDI 4 Fo2 4 = Hence this relationisin out not = Decomposition of this relation scheme nto two schemas not straightforward because it may be decomposed 1, (Studentnstiuctor) and R2(Student, Course 2 Instructor) and R2(Course, Student) 3 * Its generallot suffigiento check separately that eact relation scheme in the database is, say. in © Rather the orocess of _ normalization hiecomposition must also confirm the existence | propertietial the relational schemasaker together \ Ithclude two properties: generatioproblem does rot occur with respect to the velation schemas The dependency preservation propertywhich that each functional dependency is represented in some —_ividua Dept. of CSEATMECE, Mysuru Page 25Database Management System [18CS53, We are npt altlettwenmeisthméat ttienc! dependency preservation jibe détomposed property ™ Nonadditive Join Test for Binary Decomposition: A decomposition D={R:, Ro} of R has the lossless join property with respect to a set neetiona if only if “Rain For The FD (RivRs) —(Re-Rijis in F* ' The third decomposition meets the test Ror: is | Re-R: is Course nto BCNF relationsis: TEAC TEAC * ln general, a relatior R not in BCNF can be decomposed so as to mest the nonadditive join prorpertpy the following Itlecomposes R successively inte set of relations that are in BCNF, Rand + FD that into two relations: if not n BCNF, repeat the process 47 Dependency and Normaform ™ For example, consider the relationEMP shown in U below: fhisemployee may work on several projects and may have several dependents EMP Ename | Phane | Dname ‘saith x Jebn ‘Smith Y Anna ‘Smith x anal ‘Saith Y Jebn ™ A tuple in IP relation represents the fact that an employee whose name is Ename works of the project whose name is Pname anc has @ dependent whose name is Dname The employee's projects and dependents are independent of one another Dept. of CSEATMECE, Mysuru Page 2¢Database Management System [18CS53, SRP MERE suru 1,10 Keep the relation state consistent, and to avoid any spurious relationship betweer ircizalodedancattribute re two macsendent afribuies We must have @ separate tupe 16 represent every combination of an employee's dependent and an employee's project ‘ihe relation state shown in the EMP. the employee Smith works on two projects X'and'‘Y and has two dependents and-—«=S an thereforthere are 4 tuples to represent these facts together "The relation EMP is an all-key rel n (with = [Ename]=t2[ename]=Smitt ‘Smith Y Anna 1 smith x ‘Anna (smith [~¥_ [John] t4(Ename)=ti (Ename)=t2(Ename)=SmitDatabase Management System [18CS53, (eyx + _{3(Pname)=t! Pname)=X and td(Pname)=t2(Pname)=Y avi BX VIZ Fe Esatis)S2iDadihe)-Anna and t4(Dname)=tt(Dname)=John * Whenever XY holds, we say that X multidetermines Y. Because of the symmetryn the definition, whenever X + Y holds Hence, = >> X+4Z, and therefore it Ar sin atrivialMVD f EMP_PROJECTS sa subset of X, or R Ename | Phame Smith x Smith y idiitaepntndaiaideslepetilencies and multivalued dependencies) * For example, the relation EMP_PROJ MvD Ename —>— Pname * An MVD that satisfies neither (a) nor (b) is ca MvD " NIVO ina telation, we may have to repeat values redundantly in = Ithe EMP relation the values 'X' and "Y' of ®name are repeated with each value of Dname (or, by symmetry, the values ohn’ and ‘Anna’ of Drame are repeated with each value of Phame) * This redundancy * We now present the definition of fourth normal form (4NF) is violated wher a relation has undesirable dependencies an¢ nence can be used to dentify and decompose such relations * Definitions relation schema Ris in 4NF with respect to a set of dependencies F (that if, for every nontrivial multivalued dependency X —-—- Yin F* Xis a superkey for R "The process of normalizing relation involving the nontriviallVDs that is not in consists of decomposing ito that 2ach MVD is represented by a separate ‘elation where Mvc EMP_PROJECTS EMP_DEPENDENTS Ename | Pname Ename | Dname Smith x Smith John: ‘Smith ¥ Smith Anna Dept. of CSEATMECE, Mysur Poge 2Database Management System [18CS53, Dept. of (TMECE, Mysuru 1. VDEBESmpose EMF into EMP_PROJECTS ang EMP_DEPEN svar HpRIDERITS, MP_PROJ and EMP_DEPEN are in because the MV Ename —-Pname ir EMP_PROJ = and Ename == Dname in EMP_DEPE MVDs . MVDs hold in either EMP_PROJ —or_EMP_DEPEN Ne =Dshold in these relation schemas either WhaReipgetasientestth as the owingoints *An all-key relation in it FDs tAn a EMP, which has no FDs but has the MVD Ename—+— Pname Dname, isnot in *A relation that is not in 4NF due to a nontrivial MVD must be decomposed to convert it Ito a set of relations in + The decomposition removes the redundancy caused by the MVD BRVAIFHa# relation schemas R 48 Dependencies and Fifth Form * A join dependency (JD), denoted by JD(R1 2, .... Rn), spectied on relation scheme R. specifies a constraint on the states Bf RThe constrainitates that every legal state r of R should have a nonadditive join decomposition into, yy lence for every such r we have ¥ (ge Mp, (O ray ())=1 © A join dependency JD(R1, R2,.... Rn), specified on relation schema Risa trivial Jf in J eRajis tc R PUREVicetey (Prdject-join Fifth norma normal form} "A ‘elatior scheme R is in fifth normal form (SNF) (or projectjoimormal form with vespect to a set F of functional and join dependencies if, for every nontrivial join dependency JO(R1, R2, ..., Rh) in F* every © A database is said to be in f onlyif rlt’s inDatabase Management System [18CS53, 1 If we can decompose table further to eliminate redundancy and anomaly, and when Biifindation SUPP with iaton SUfe rel1M the decomposec tables by means of candidate keys we _—‘Idot be losing the date of any new record set shoule not arise IRimple words two of more decomposec table thot lose records nor create new records SUPPLY ‘Shame ‘Smith ‘Smith ‘Adamaky Walton sky Fro¥ LY neMVDsisin — butnot in ifthas the JD(R1, R2, R3) ity Decsikiposiagohe Raat BOPP Ry i Ry ‘Shane | Paitnane Scene _| Poi nane Failname | ProLnane Smith Bolt ‘Smith Prox Bot Pro Smith Nat ‘Smith Pray Nat Pro ‘Adamsky [Bolt ‘Adamsky [__PraY Bot Pro¥ Walton Nat Walton Proz Nut Proz ‘Adamsty | Nail ‘Adamsty | Prox Nai Propk Ly Dept. of CSEATMECE, Mysuru Page 30Database Management System [18CS53, Page Dent, of CSEATMECE, Mysuru Chapter 2 Norm_ization_: goritams Al anaes Aceientisicistynbehememip yltttatre specified on relation schema R 4.9 Inference Rules for Dependencies ® The scheme specifies the dependencies that are semantically obvious . in all legal relation instances among sets of attributes that can be derived from and satisfy the dependencies in F * Those other dependencies can be inferred or deduced from the FOsin F. "example * fach departmentas oné_managese that Dept_no un _—_determines Mgr_ssr (Dept_no — Mgr_ssn) and a manager has u —ohone nu ca Dept_no — Mgr_phone , licithgates in to the losure of F. © Definition Formallythe set of all dependencies that include F as well as all dependencies that can be nferrec from ca it "For examplesuppose that we specify the following set F of obvious functional P_DEPT dependencies on the relation scheme EwP_oEPT exuwe | 98 | eowe | sooRese owawaer | onawe | ouaresn oF =f Ssn > {Ename, Bdate, Address, Dnumber} Dnumber -- {Dname, Dmgr_ssn} } = Some of the functionatiependencies that we car infer from F are the * Sen — {Dname, Dmgr_ssn} * Ssn -Ssn 31Database Management System [18CS53, irspamiieaslacttl Otilittanieatn At aininfarred frome satel Gependencies F speciied on Rf —+ holdsin every ega = The closure F* of F lfunctiona inferred from F * Set of inferenceules car be usec to nfer new dependencies froma g sel of dependencies * We use the rotation F [=X —¥ to denote that the functionalependency X—-Y is "we use an abbreviatec notation when discussing functional We concatenate attribute variables and drop the commas for convenience = The FD is abbreviated to XYZ, and the FD {X, ¥.Z} UV} is abbreviatec WV. ' l IRS well-known * They are proposed by Armstrong and hence known as Armstrong's axioms * 1 (reflexive if ¥ then XY. *1R2 (augmentation rule): XY} +IR3 (transitive rule): (XY, YZ} The reflexive rule (IR1) states that a set of altributes always determines itself or any of its subsets, which "Because | generates dependencies that are always true such dependencies are called trivial = Forma {X2Y. otherwise, it nontrivial = The augmentation rule (IR2) says that adding the same set of attributes to both the left- and right-hand sides of a dependency results in va . tc IR3, functional dependencies are transitive . llow | banc 1 *IR4 (decomposition, or projective, rule): {XYZ} IRS (union, or additive, cule): (XY, X+Z} +IR6 (pseudotransitive rule): {XY WY—Z} |=WX>Z "The decomposition rule (I says that we Can ‘emoOVE attributes from the right-hane side of a dependency; applying this rule repeatedly can decompose the FD X—(A1, A2, An} "The le (I allows us to do the oppositewe can combine a set of dependencies (X-»A1, X-»A2, ... X+An} = The pseudotransitive rule (IR6) allows us to replace a set of attributes the left hanc side of a dependency with another set X that functionally determines” and can be Dept. of CSEATMECE, Mysuru Page 32Database Management System [18CS53, Roe/auiimenb edie fmatonac | I dependency yy (Giallcheemitsalvelas20diitien Bpply the transitive rule ® Ipther words the set of dependencies F+, we callec the closure of F. can be determined from F by using only inference rules [Rt hh "A systematic way to determinahese functionatlependencies is first to determine each set of attributes X that eppeers as left-hand I dependency in F and then to determine the set of ail attributes that are dependent on X = DefinitiorFor each such set of attributes X, we determine the set X" of attributes that are functionally determined by X based on F: X" . 16.1 Algorithm 16.1. Determining X*, the Closure of X under F Input: A set F of EDs on a relation schema R, and a set of attributes X, which is a subset of R_ xe repeat oldX* = X* for each functional dependency ¥-> Zin F do if X* > Y then Xt := X*U until (X* = oldX")s ‘igiedjrookiih Xt tbtad secatttbivtdesare functionally dependent on X . 16.1 x. = By = Using inferenceules IR3 and | we adc attributeto X* using each functional dependencyin F. = We keep going fall the dependencies in F (the repeat loop! unt no more attributegre added to X* du @ completeycle (of the for loop) the dependenciesin F. "For exampleconsider the -elstior scheme EMP_PROFrom the semantics of the atiributes, we specify the following set F of functional dependencies that should hold on EMP_PROJ =( name Pnumber —> {Prame, Plocation}, {Ssn, Prumber} — * Using Algorithm 18.1, we calculate the following closure sets with respect to F » (Ssa} * ={Ssn Ename} Dept. of CSEATMECE, Mysur Page 33Database Management System [18CS53, +. (Pnumber)* = {Prumber, Pname, Plocation} ft cies, F eeepc ee See OP SPS | mber. Ename, Prame, Plocation, 4.40 netiondDependencies dependencies very FD in B also in F* that is f every dependency in Ean be inferred from F; alternatively, we can say thal Ecoveredby F. Definitiontwo sets of dependencies Hane F are equivalent i€* #* ‘Therefore, equivalence means that every FD in Zan be inferred from F, and every FD in F canbe inferred from Bhatis, % equivalent to F —fovers Fand F covers iehiOtidherathdsetitipaaddfionttsnesiaxnitistliizave a sel of dependencies that 4.11 of Dependencies lif lowing 1.Bvery dependency 2 in Fwith dependency ‘We cannot remove any dependency from F and still nave @ set of dependencies that's equivalent to F. Algorithm 16.2. Finding a Minimal Cover F for a Set of Functional Dependencies E Input: A set of functional dependen 1. Set R= E, 2. Replace each functional dependency X —> {Ay. A, tional dependencies XA), X 9A,,.... X > Ay, 3. For each functional dependency X—> A in F for each attribute B that is an element of X if {{F—{X— A} } U{ (X—{B}) — A} J is equivalent to F then replace X— A with (X— {B}) > Ain F. 4, For each remaining functional dependency X —> A in F if {F—{X — A} } is equivalent to F, then remove X—> A from F. E, A, in Fby the n fune- Dept. of CSEATMECE, Mysur Page 34Database Management System [18CS53, Starcanogical forntptendssement testing (aaghogAbsRiaieen Ht ‘A ExraRbahdehrisallé con'sined ir the left-hand side x * Step 4 constitutes removal of a dependency.» from F wher possible "Example thet the given set of FDs be E DA, AB—D}Weave to find the E vA in canonical (that is, they have only one attribute on the ‘ight-handide), so we have completed step 1 and can process to step 2 ‘in step 2 we need to determine f AB—D has any redundant attribute on the left-hanc side that is, can it be replaced by B—-D or A-+I *Since B A, by augmenting with 8 on both sides (IR2), we have BB + AB, or BAB . ii) Hence by the transitive rule (IR3), we get from (i) anc (i, BD. ABE may We now have a E, say E (BA DA B+D}. No is possible in step ince all FDs have a single attribute on the left-hanc side. *Igtep 3. look fora redundant Fin E > B —Alence 8 — is redundant liminated, Algorithm 16.2(a), Finding a Key K for R Given a set F of Functional Dependencies Input: A relation R and a set of functional dependencies F on the attributes of R 4.Set KR 2. For each attribute A in K [compute (K—A)* with respect to Fs if (KA)! contatns all the attributes in R, then set K. ThesetohE tgPnicme | DA} \uptied thgpscition Aigcettitheestaitibbratteibtutesr trey reerovee! SrarafRibute at a time and check K-4A} p * Algorithm 16.2(@) determines only one key out of the possible candidate keys for R; the key 2 Dept. of CSEATMECE, Mysur Page 35Database Management System [18CS53, Prapertigg of Relationa 1 Decompositions Un Veglation schema RI Settee ele cif srtateS Of Ane attributes of the database * univers is un . is specifiec by the database designers ® Using the functionalependencies the algorithmgecompose the scheme Cis called a Attribute Preservation condition of a Decomposition = Each attribute in at least one relation schema Rin the decomposition so that no attributes are /ost; formally, we have ™ ae . goa is to have each relation R. in the decomposition Dbe in . itiona are needed to prevent from generating spurious Desirable Properties of Decompositions "oa ™ We require two properties to be satisfied Dependency Preservation Property ii) Nonadditive (Lossless) Join Proper Dependency Preservation Property . in F either appeared d inne of the relation schemas R in the decomposition D or could be inferred from the dependencies some R, Dept. of CSEATMECE, Mysuru Page 3¢Database Management System [18CS53, Page37 Beso CSEATMECE, Mysurw 1 We want to preserve the dependencies because each dependency jn F represents ¢ Ealinipabsbiatone cotmeteoomme timedistraint oy dee * IBne of the dependencies is not representec in some ‘elation Ri of the lingith an relation = lis not necessary thal the exact dependencies specifiec in F appear themselves in = Ib sufficient that the union of the dependencies that hold on the relations in D be equivalent to F . Dependency Preserving Decompositior Conca key Lots [Property iat [ County namo [ uot [Ara [Price | Taxrate | ror + 44 +4 sete Dependency Foo 4 ay roa | 4 ros Lt [Awe oo : sf mE 1 i sors \orse (Peni [Canin ak [a [P| mo [ of ft ff om | f Fo2 t [ [ t { ro t+ [Prnenyid [area [Lo] [Wea | Comtznane itive Nonadd (Lossless) Join PropertyDatabase Management System [18CS53, The nogadditive join property ensures that no spurious tuples result after the app licatior a (@apEOus oF Nvalic . lossy design refer to a design that represents € information |B decomposition does rot have the lossless join sroperty, we may gel (m) and RA lied, information Algorithm 16.3. Testing for Nonadditive Join Property Input: A universal relation R, a decomposition D = {R,. Ry. set F of functional dependencies. R,,} of Randa Note: Explanatory comments are given at the end of some of the steps. They fol- low the format: (* comment *). 4. Create an initial matrix $ with one row i for each relation R, in D, and one column j for each attribute A, in R. 2. Set S(i,);= by forall matrix entries. * each bisa distinctsymbol associated with indices (i,j) *). 3. For each row i representing relation schema R, {for each column j representing attribute A, {if (relation R, includes attribute A,) then set S\i,): distinct symbol associated with index (j)*).. askls C each a, isa Dept. of CSEATMECE, Mysur Poge 3€Database Management System [18CS53, 4, Repeat the following loop until a complete loop execution results in no changes to $ {for each functional dependency X— Yin F {for all rows in S that have the same symbols in the columns corresponding to attributes in X {make the symbols in each column that correspond to an attribute in Y bethe same in all these rows as follows: If any of the rows has an a sym- bol for the column, set the other rows to that same a symbol in the col- umn. If no a symbol exists for the attribute in any of the rows, choose one of the b symbols that appears in one of the rows for the attribute and set the other rows to that same b symbol in the column 3} 5 | 5}5 5. If a row is made up entirely of a symbols, then the decomposition has the nonadditive join property; otherwise, it does not. Example Ton | Erane [Prater |[Prane | Pesaton | Hawa Rata | bo | tu | bs | be Ron | te [eae Re La Bap ao be ca ae (Cra ati Sat tart of got) oii eae [aoe] | Te Ray a bia Ba bis Pre Re [ba Pa E a a Bs a Ca [ge |e De Be (iti S tor appying thos wo fonctions Sopandences: lestrow inal "a" ambos Bo we scp) Dept. of CSEATMECE, Mysuru Page 3°Database Management System [18CS53, Testing Binary Decompositions for the Nonadditive Join Property Property NJB (Nonadditive Join Test for Binary Decompositions). A decomposition D = {R,, Rj} of R has the lossless (nonadditive) join property with respect to a set of functional dependencies Fon R ifand only ifeither = The FD ((R, 0 R,) + (R,—R,)) isin F*, or & The ED ((R, VR) (R,—R,)) isin F* ANGwdittthris fWirRGhativREtS aalniccosehelstimfsnhamaverse 41 Database Schema Design relation 1.The first decomposes a relation into dependency preserving relations that also possess the nonadditive join property 2. into BCNF schemas thal possess the nonadditive join property (deci fica cbse ohtrehntbiiey Gapstionprties Sles 8)>olnt utes of Decorgppgition into 3NF Schemas Algorithm 1 Relational Synthesinto wit Dependency Preservation anc Join Property * Input: A Wersa R. finde ima 2. in G, create a relation schema in D with attributes (XU {41} U (A2}... U {AK}}, where XAT, XA2, svn the only dependencies in asleft-hand-side (X is the key of this relation) 5 Iifone of the relation schemain D contains < key of R, then create one More “elation scheme 1 D that contains attributes that form a key of R 6 —_Eliminateedundant relations from the resulting set of relations in the ‘elationa schema, A relation Ris considered redundant i is a projection of another relation S in ‘onsider the following universa UEmp_sstno, Esal, Ephone, Dno, Pname, Plocation Dept. of CSEATMECE, Mysur Poge 40Database Management System [18CS53, ssn Esal, Ephone refer to the Social Security number, salary and phone number of {tfodesdkp ptietisen Pro) of L eee TT are DINE MNES same, anc location ofthe project Dno » fo - :Emp_ssn—> — Ephone, Dno} -FD2: Pao { Phame, Plocattion} : Esatphone, Dno, Pname, Plocation} By virtue of FD3, the attribute set (Emp_ssrPno} represents @ key of the Mence F. the set of given FDsinclides {Emp_ssr sal Ephone Ono; Pno—-Pname, Plocation; Emp_ssn, Pno—Esal, By applying the cover in step We see that Pno is a attribute in Emp_ssrPno -fsal, Ephone Dno Moreover Emp_ssts redundarin Emp_ssn . ane Fl y , cover G {Emp_ssn sal, Ephone, Dno; Pao —» Pname, Plocation} “By applying Algorithm of two relations with keys llows R’ (Emp_ssn phone Dno} R2 (Eno, Pname, Plocation} Hence, the resulting design contains: Ri (Emp ssn — Ephone dno} R2 (Eno, Pname, Plocation} R3(Emp_ssn, Pno} design both the desirable properties? dependency preservation anc non (HRBRHATiceaobkiter rand a set of functional dependencies F on the attributes of R 4.1 Nonadditive Join Decomposition F Schemas Algorithm1 —Relationa into Nonadditive Join Property Bet D=(R} 2 's a relation schema Gin is notin is notin Dept. of CSEATMECE, Mysuru Poge 4Database Management System [18CS53, ap dependency 2 Nig. that viotes BENE |, f h / pete 6 ee (6 — (A,B) }+ foreach pao h Each time through the loop 1n Algorithm 16.5, we decompose one relation scheme Q that isnot in . to Property UB for binary decompositions anc Claim 2, the decompositior D has the nonadditive join property in bein = Example:TEACHelation scheme decomposed inte A(InstructorStudent) anc TEACH2(Instructor, because the dependency FD2 instructor—Course violate: F fm step 2 of Algorithm 16.5. it necessary to determine whether a relation scheme @ isin = whenever a relation schema Q has a BCNF violation, there exists a pair of attributes A anc B attributegA B} of Q anc checking whether the includes A (or B), we car determine whether Qis in F. 4.13.3 Dependency-Preserving and Nonadd (Lossless) Join Decomposition i F Schemas © It not possible fo have all three of the following. (1) guaranteed nonlossy design (2) guaranteed dependency preservation, and (3) all relations in = The first conditior = The seconc is desirable, but not a must and may nave te be relaxed ifve "Nowwe g an alternativelgorithm where we nd inc only =A. simple to 1 shown as 1 yields llowing 1 Preserves dependencies fas the nonadditive join property Dept. of CSEATMECE, Mysuru Poge 42Database Management System [18CS53, 3NF 1 Is such that each resulting relation schema in the decomposition jg in Algorithm 16.6. Relational Synthesis into 3NF with Dependency Preservation and Nonadditive Join Property Input: A universal relation R and a set of functional dependencies F on the attributes of R. 4. Find a minimal Relat G for F (use Algorithm 16.2). : PHMEARPURLP Sa functional dependency that appears in G, cre- 5 key Kot ate a relation schema in D with attributes {X U {Aj} U {A}} ... U [Ag }s where X— Ay, X— A,,...,X > A, are the only dependencies in G with X as left-hand-side (X is the key of this relation). heend 3. If none of the relation schemas in D contains a key of R, then create one oduces more relation schema in D that contains attributes that form a key of R.7 elation (Algorithm 16.2(a) may be used to find a key.) ba 4, Eliminate redundant relations from the resulting set of relations in the rela- tional database schema. A relation R is considered redundant if R isa projec- tion of another relation S in the schema; alternately, R is subsumed by S. ‘This design achieves both the desirable properties of dependency preservation and nonadditive join. 4.1 About 1 li | relationd database scheme 4.14.1 Problemwith LL and fi . is designed in which two or more velations are interrelated via foreign » Y. (©) Template for the inclusion dependency RX < SY, @ R= BG DD Hypothesis a | by Te | dy X={A,B) a |b fe [a Y={c,D) Conclusion [=e and dy () 4 BO DD Hypothesis. [ai] 6: | o] & X=(.B) ay |b | cy] de Y={c} Conclusion [a |b; | |] & a, Db | & | ee © & BG DD S=i FR G x=(C0) Hypothesis. [a | bo] Gs Y=(EA Conclusion alas sigwvisor © Figure 16.6 shows how we may specify the constraint that an employee's salary cannot be A thar the salary of A or her direct on the relation scheme EMPLOYEE Dept. of CSEATMECE, Mysuru Page 4eDatabase Management System [18CS53, gti Templates for the constraint that an employee's salary must be less than the superviscrs salary. Dept. of CS EMPLOYEE = (Name, Ssn, ..., Salary, Supervisor_ssn} alb © d Hypothesis. |e | d f 3 Conclusion e Prove that the above decomposition of relation R has theloss 4.Consider (ABCD £}FDS{AB-> 3->E ADF} Check whether decomposition is lossless 5.Whal is 2 dependencies F saic tc be Give an for i F. 4.17 Expected Outcome To design a database which will have minimum redundancy % To apply normalization to the designed database, 4 To decompose the tables and normalize the design upto ANF and 5 NFthe tables upto ANP and SNE 4. Hitt bei iio ein IL OWTDwepriew_Nacts.pdl 1. https:(/uwiw.smartdraw.com/entity-relationship-diagrany 3 lecture