Relational Database design.pptx

RDBMS

1. Relational Database design

2. Introduction to relational Databases Design A relational database organizes data in  tables  (or  relations ). A table is made up of rows and columns. A row is also called a  record  (or  tuple ). A column is also called a  field  (or  attribute ). A database table is similar to a spreadsheet. However, the relationships that can be created among the tables enable a relational database to efficiently store huge amount of data, and effectively retrieve selected data. A language called SQL (Structured Query Language) was developed to work with relational databases. Database design is more art than science, as you have to make many decisions. Databases are usually customized to suit a particular application. No two customized applications are alike, and hence, no two database are alike.

3. Functional Dependency A functional dependency is a constraint that specifies the relationship between two sets of attributes where one set can accurately determine the value of other sets. It is denoted as  X → Y , where X is a set of attributes that is capable of determining the value of Y. The attribute set on the left side of the arrow,  X  is called  Determinant , while on the right side,  Y  is called the  Dependent . Functional dependencies are used to mathematically express relations among database entities and are very important to understand advanced concepts in Relational Database System and understanding problems in competitive exams like Gate.

4. Example roll_no name dept_name dept_building 42 abc CO A4 43 pqr IT A3 44 xyz CO A4 45  xyz IT A3 46 mno EC B2 47 jkl ME B2

5. roll_no → { name, dept_name , dept_building },→  Here, roll_no can determine values of fields name, dept_name and dept_building , hence a valid Functional dependency roll_no → dept_name , Since, roll_no can determine whole set of {name, dept_name , dept_building }, it can determine its subset dept_name also. dept_name → dept_building ,   Dept_name can identify the dept_building accurately, since departments with different dept_name will also have a different dept_building More valid functional dependencies: roll_no → name, { roll_no , name} ⇢ { dept_name , dept_building }, etc.

6. Here are some invalid functional dependencies: name → dept_name   Students with the same name can have different dept_name , hence this is not a valid functional dependency. dept_building → dept_name    There can be multiple departments in the same building, For example, in the above table departments ME and EC are in the same building B2, hence dept_building → dept_name is an invalid functional dependency. More invalid functional dependencies: name → roll_no , {name, dept_name } → roll_no , dept_building → roll_no , etc.

7. Types of Functional dependencies in DBMS: Trivial functional dependency Non-Trivial functional dependency Multivalued functional dependency Transitive functional dependency

8. Trivial Functional Dependency In Trivial Functional Dependency, a dependent is always a subset of the determinant. i.e. If X → Y and Y is the subset of X, then it is called trivial functional dependency For example, roll_no name age 42 abc 17 43 pqr 18 44 xyz 18 Here, { roll_no , name} → name is a trivial functional dependency, since the dependent name is a subset of determinant set { roll_no , name} Similarly, roll_no → roll_no is also an example of trivial functional dependency.

9. Non-trivial Functional Dependency In Non-trivial functional dependency, the dependent is strictly not a subset of the determinant. i.e. If X → Y and Y is not a subset of X, then it is called Non-trivial functional dependency. Example:- roll_no name age 42 abc 17 43 pqr 18 44 xyz 18 Here, roll_no → name is a non-trivial functional dependency, since the dependent name is not a subset of determinant roll_no Similarly, { roll_no , name} → age is also a non-trivial functional dependency, since age is not a subset of { roll_no , name}

10. Multivalued Functional Dependency In Multivalued functional dependency, entities of the dependent set are not dependent on each other. i.e. If a → {b, c} and there exists no functional dependency between b and c, then it is called a multivalued functional dependency. Here, roll_no → {name, age} is a multivalued functional dependency, since the dependents name & age are not dependent on each other(i.e. name → age or age → name doesn’t exist !) roll_no name age  42 abc 17  43 pqr 18 44 xyz 18 45 abc 19

11. Transitive Functional Dependency In transitive functional dependency, dependent is indirectly dependent on determinant. i.e. If a → b & b → c, then according to axiom of transitivity, a → c. This is a transitive functional dependency For example, Here, enrol_no → dept and dept → building_no , Hence, according to the axiom of transitivity, enrol_no → building_no is a valid functional dependency. This is an indirect functional dependency, hence called Transitive functional dependency. enrol_no name dept building_no 42 abc CO 4 43 pqr EC 2 44 xyz IT 1 45 abc EC 2

12. Relational Decomposition When a relation in the relational model is not in appropriate normal form then the decomposition of a relation is required. In a database, it breaks the table into multiple tables. If the relation has no proper decomposition, then it may lead to problems like loss of information. Decomposition is used to eliminate some of the problems of bad design like anomalies, inconsistencies, and redundancy.

13. Properties of Decomposition Following are the properties of Decomposition, 1. Lossless Decomposition 2. Dependency Preservation 3. Lack of Data Redundancy

14. Lossless Decomposition Decomposition must be lossless. It means that the information should not get lost from the relation that is decomposed. It gives a guarantee that the join will result in the same relation as it was decomposed. Example: Let's take 'E' is the Relational Schema, With instance 'e'; is decomposed into: E1, E2, E3, . . . . En ; With instance: e1, e2, e3, . . . . en , If e1 ⋈ e2 ⋈ e3 . . . . ⋈ en , then it is called as  'Lossless Join Decomposition'.

15. In the above example, it means that, if natural joins of all the decomposition give the original relation, then it is said to be lossless join decomposition. Example: < Employee_Department > Table Decompose the above relation into two relations to check whether a decomposition is lossless or lossy . Now, we have decomposed the relation that is Employee and Department. Eid Ename Age City Salary Deptid DeptName E001 ABC 29 Pune 20000 D001 Finance E002 PQR 30 Pune 30000 D002 Production E003 LMN 25 Mumbai 5000 D003 Sales E004 XYZ 24 Mumbai 4000 D004 Marketing E005 STU 32 Bangalore 25000 D005 Human Resource

16. Department Schema contains ( Deptid , DeptName ). Employee Schema contains ( Eid,Deptid , Ename , Age, City, Salary). So, the above decomposition is a Lossless Join Decomposition, because the two relations contains one common field that is ‘ Deptid ' and therefore join is possible. Now apply natural join on the decomposed relations. Employee ⋈ Department Eid Ename Age City Salary Deptid DeptName E001 ABC 29 Pune 20000 D001 Finance E002 PQR 30 Pune 30000 D002 Production E003 LMN 25 Mumbai 5000 D003 Sales E004 XYZ 24 Mumbai 4000 D004 Marketing E005 STU 32 Bangalore 25000 D005 Human Resource Hence, the decomposition is Lossless Join Decomposition.

17. Lossy Decomposition As the name suggests, when a relation is decomposed into two or more relational schemas, the loss of information is unavoidable when the original relation is retrieved. Let us see an example − < EmpInfo > Emp_ID Emp_Name Emp_Age Emp_Location Dept_ID Dept_Name E001 Jacob 29 Alabama Dpt1 Operations E002 Henry 32 Alabama Dpt2 HR E003 Tom 22 Texas Dpt3 Finance

18. Dept_ID Dept_Name Dpt1 Operations Dpt2 HR Dpt3 Finance Decompose the above table into two tables − < EmpDetails > < DeptDetails > Emp_ID Emp_Name Emp_Age Emp_Location E001 Jacob 29 Alabama E002 Henry 32 Alabama E003 Tom 22 Texas

19. Now, you won’t be able to join the above tables, since Emp_ID isn’t part of the DeptDetails relation. Therefore, the above relation has lossy decomposition.

20. Dependency Preservation It is an important constraint of the database. In the dependency preservation, at least one decomposed table must satisfy every dependency. If a relation R is decomposed into relation R1 and R2, then the dependencies of R either must be a part of R1 or R2 or must be derivable from the combination of functional dependencies of R1 and R2. For example, suppose there is a relation R (A, B, C, D) with functional dependency set (A->BC). The relational R is decomposed into R1(ABC) and R2(AD) which is dependency preserving because FD A->BC is a part of relation R1(ABC).