( Vv 1. What is Decomposition in DBMS? The term decomposition refers to the process in which we break down a table in a database into various elements or parts. Thus, decomposition replaces a given relation with @ collection of various smaller relations. Thus, in a database, we can make any table break down into multiple tables when we want to collect a particular set of data. 2. Properties of Decomposition Decomposition must have the following properties: 1. Decomposition Must be Lossless 2. Dependency Preservation 3. Lack of Data Redundancy 1.) Decomposition Must be Lossless- Decomposition must always be lossless, which means the information must never get lost from a decomposed relation. This way, we get a guarantee that when joining the relations, the join would eventually lead to the same relation in the result as it was actually decomposed.) / 2.) Dependency Preservation : Dependency is a crucial constraint on a database, and a minimum of one decomposed table must satisfy every dependency. If {P + Q} holds, then two sets happen to be dependent functionally. Thus, it becomes more useful when checking the dependency if both of these are set in the very same relation. This property of decomposition can be done only when we maintain the functional dependency. 3.) 3. Lack of Data Redundancy It is also commonly termed as a repetition of data/information. According to this property, decomposition must not suffer from data redundancy. When decomposition is careless, it may cause issues with the overall data in the database. When we perform normalization, we can easily achieve the property of lack of data redundancy.Types of Decomposition we Decomposition 46 of two major types in DBMS: + Lossless 2. Lossy 1.) What is Lossless Decomposition in DBMS? The decomposition of a given relation X is known as a lossless decomposition >>> when the X decomposes into two relations X1 and x2 in a way that the natural joining of x1 and X2 gives us the original relation X in return. ** Conditions Required for Lossless Decomposition in DBMS ** $ consider a relation X. In case we decompose this relation into relation x1 and relation x2 sub-parts. This decomposition will be referred to as a lossless decomposition in case it satisfies these statements: Let us con: Condition 1.) -->>If we union ‘the sub relations X1 and X2, then it should consist of all the attributes available before the decomposition in the original relation x. condition 2.)--->>The intersections of X1 and X2 can never be Null.There must bea common attribute in the sub relations. This common attribute must consist of some unique data/ information. Here, the conmon attribute needs to be the super key of the sub relations,either X1 or x2. In this case, X= (P, @ R) x1 = (P, Q) x2 = (Q, W) The relation X here consists of three attributes P, Q, and R. The relation X here decomposes into two separate relations Xi and X2. Thus, each of these X1 and X2 both have two attributes. The conmon attribute among each of these is Q. **Remember that the value present in colunn Q has to be unique.** Lossless Decomposition in DBMS Example: Example 1. Let us take a look at an example: «Cand_Info>Cand_ID Cand, iName Cand_Age Cand_Location Sec_ID Sec Name Gb@91 Robin 25 Canada Sec_i HR 60081 Ted 29° New Jersey —Sec_2._- Finance Geert Barney’ 27 Las Vegas Sec_3 Operations Let us decompose this the following tables: Rl-->> Cand_10 Cand. table mentioned above into 1_Name Cand_Age Cand_Location 2291 Robin 25 Canada Gees1 Ted 29 New Jersey 6071 Barney 27 Las Vegas R2-->> Sec_ID Cand_ID Sec_Name Sec1 Gee91 HR Sec_2 G@81 Finance Sec_3 6071 Operations CONDITION 1. Let us now apply Natural Join in the tables mentioned above. The result generated here would be: Cand_ID Cand_Name Cand_Age Cand_Location Sec_ID Sec_Name 69091 Robin’ 25 G0e81 Ted 29 0071 Barney 27 Canada Sec. HR New Jersey Sec_2 Finance Las Vegas Sec_3 Operations Thus, the relation mentioned above has a lossless decomposition. In simpler words, no information would be lost here.What is Lossy Decomposition in DBMS? Let us consider a relation X. Let us now consider that it gets decomposed into n number of sub relations, X1, X2, X3, ., Xn. If we naturally join these sub relations, then we will either obtain the exact previous relation X or we will lose information in this process. In case we do not get the same relation X (that was decomposed) after joining X1 and X2, it is known as a lossy decomposition in DBMS. The natural joining of these sub relations always has some extraneous tuples. In the case of a lossless decomposition, we can see that: X1 bd X2 mM X3 owe Dd XN DX Here, the operator ™ acts as a natural join operator. **Lossy Decomposition in DBMS with Example** Careless decomposition is another name for lossy join decomposition. It is because there is an introduction of various extraneous tuples in the sub relations’ natural join. These extraneous tuples make it very difficult to identify the original tuples. Example 1Dependency Preservation: Dependency Preserving Decomposition is a technique used in Database Management System (DBMS) to oocomrece a relation into smaller relations while preserving the unctional dependencies between the attributes. The goal is to improve the efficiency of the database by reducing redundancy and improving query performance. Consider a relation R A Decomposition of R = { R1, R2, R3..Rn } AND F = { functional dependencies of R} IF R is decomposed or divided into R1 with FD { #1 } and R2 with { f2 }, then there can be three cases: > Decomposition is dependency preserving. > Not Dependency preserving. > This case is not possible. #2 = F ----- 2 is a subset of F ----- 2 is a super set of F ----- Problem:Cc -> D, D -> A}. Let a i relation R (A, B, C, D ) and functional dependency {AB -> C, Relation R is decom i posed into R1( A : decomposition (A, B, C) and R2(C, D). Check whether Solution: R1(A, B, C) and R2(C, D) STEP 1. ->>> Let us find closure of Fi and F2. To find closure of F1, consider all combination of ABC. i.e., find closure of A, B, C, AB, BC and AC Note ABC is not considered as it is always ABC {A} // Trivial closure(A) = closure(B) = {8} // Trivial . closure(C) = {C, As D} but D can't be in closure as D is not present R1. = {c, A . Ne ; // Removing C from right side as it is trivial attribute closure(AB) = {As B, C, D} {A, B, CtSy AB --> C // Removing AB from right side as these are trivial attributes closure(BC) = {B, C, D, A} = {A, B, C} ivial BC --> A // Removing BC from right side as these are trivia. attributes closure(AC) = {A, C, D} = NULL SET FOR R2: FIND closure OF (c,D) Closure of (C) = {C,D,A} // BUT A is not present in R2 SO THAT CAN'T BE A PART OF CLOSURE. //Removing C from right side as these are trivial attributes = {D} C-->D Closure of (D) = {D,A} // BUT A is not present in R2 SO THAT CAN'T BE A PART OF CLOSURE. //Removing D from right side as these are trivial attributes NULL SET {C,D,A} // BUT A is not present in R2 SO THAT CAN'T BE A PART OF _ CLOSURE OF (CD)AB -->¢ 2 ‘ . els attributes // Removing AB from right side as these are trivial closure(BC) = {B, C, D, A} = {A, B, C} BC --> A ‘ ‘ . gine attributes // Removing BC from right side as these are trivial closure(Ac) = {a, Cc, D} ) = NULL SET sFOR R2: FIND closure OF (C,D) Closure of (C) = {C,D,A} // BUT A is not present in R2 SO THAT CAN'T BE A PART OF CLOSURE. //Removing C from right side as these are trivial attributes = {D} C-->D Closure of (D) = {D,A} // BUT A is not present in R2 SO THAT CAN'T BE A PART OF CLOSURE. //Removing D from right side as these are trivial attributes NULL SET {C,D,A} // BUT A is not present in R2 SO THAT CAN'T BE A PART OF CLOSURE OF (CD)& ee ‘ivial //Removing C,D from right side as these are tr attributes = NULL SET STEP2. Write F, f1 and f2 : F= {AB -> C, C -> D, D -> A} Fl = {C--> A, AB --> C, BC --> A}. F2 = id STEP 3. CHECK Sens = F ??? IF YES DEPENDENCY IS PRESERVED. F2 IS SUBSET OF "F" ?? IF YES DEPENDENCY IS NOT PRESERVED. In the original Relation Dependency { AB --> C , C --> D , D --> A}. AB --> C is present in F1. C --> D is present in F2. D --> A is not preserved. F1 U F2 is a subset of F. So given decomposition is not dependency preserving.- \- / Let us look at a table of relations. Cand_ID Cand_Name Cand_Age Cand_Location Sec_ID Sec_Name HX@@1 = Kevin 45 New York Sec1 Operations HX@01 = Raymond 49 Los Angeles Sec2 HR Sec3 Finance HX@01 = Marco. 35 San Diego Let us now decompose this table into two tables like this: Cand_ID Cand_Name Cand_Age Cand_Location 45 New York HX@@1 = Kevin HX@@1 = Raymond 49 Los Angeles HX@@1 = Marco a5, San Diego Sec_ID Sec_Name Secl Operations Sec2 HR Sec3 Finance Now, if we try to join both the tables mentioned above, we won’t be able to do it- since the relation Cand_ID isn’t part of the relation Sec_Details. Ds i