Database Systems Redundancy, normalization

Transcription

1 Database Systems Redundancy, normalization Bence Molnár

2 Problems of relational DB schema

3 Bad example! Invalid value (no candidate key) Name FirstName Age ID IdNr Gipsz Jakab Jakab Hallgató Bálint Béla Gipsz Jakab Jakab redundancy (even if it would be a key, it's duplicated)

4 Bad example! Duplicated tuple inconsistency Name FirstName Age ID IDNr. Gipsz Jakab Jakab Hallgató Bálint Béla Gipsz Jakab Jakab Unable to filter on last name

5 Difficult points Enforce consistency: DB shouldn't contain contradictory information Enforce data validity: Data value should be a part of an exact set of values. Minimizing/eliminate redundancy: Multiple storage of same data Difficult to enforce data consistency Avoid duplicated tuples (if needed/possible) Avoid duplicated data storage (if needed/possible)

6 Solutions? Enforce consistency: normalization Enforce data validity: selection of proper data type Minimizing/eliminating redundancy: normalization Avoid duplicated tuples: key definition Avoid multiple data storage: careful designing, normalization

7 Redundancy, anomalies

8 Redundancy Redundancy is the source of following anomalies Update anomalies Insertion anomalies Deletion anomalies

9 Update anomalies Name John Doe John Doe Elon Musk Age Bought Chocolate Beer Beer Once I going to update John Does name I have to update it in multiple tuples!

10 Insertion anomalies Name John Doe John Doe Elon Musk age Bought Chocolate Beer Beer Age was mistyped (typo), unable to achieve reliable information.

11 Deletion anomalies Name John Doe John Doe Elon Musk Age Bought Chocolate Beer Beer If all rows corresponding to John Doe is deleted, his age information lost and no more available!

12 Avoiding redundancy To avoid redundancy, table structure must be normalized during DB design. During normalization we achieve different normalization levels and normal forms. To understand normal forms, first functional dependencies should be introduced.

13 Functional dependencies

14 Functional dependencies If two tuples of R agree on some attributes (A), then they must also agree on other attribute, B. B functionally depends on A. Name John Doe John Doe Age Name Age Syntax Bought Chocolate Beer

15 Functional dependency Candidate Key Note: functional dependency is a generalization of candidate key: If one or more attribute functionally defines all other attributes, than those attributes are superkey. If this set is minimal, than it's a candidate key

16 Functional dependencies Example Give the set of functional dependencies! Employees(IDNr, Name, Salary, Position) IDNr. Name, Salary, Position

17 Functional dependencies Example Give the set of functional dependencies! Employees(IDNr, Name, Salary, Position) IDNr. Name, Salary, Position Position Salary (?) Results(ClassName, NeptunID, Name, Grade)

18 Functional dependencies Example Give the set of functional dependencies! Employees(IDNr, Name, Salary, Position) IDNr. Name, Salary, Position Position Salary (?) Results(ClassName, NeptunID, Name, Grade) ClassName, NeptunID Grade

19 Normal forms

20 First normal form (1NF) Each tuples is different (has candidate key) Has a key which all attribute functionally depends on. Key can be all attribute of the relation Column number and order is the same for all tuples Each column may contain only one attribute All attribute has single value It's not trivial question of DB design

21 Second normal form (2NF) Definition of 2NF: fulfilled to 1NF + All not candidate key fully functional depending on candidate key and not depends on any subset of candidate key Full functional dependency: not functionally dependent on any proper subset of attributes If candidate key is a single attribute, it's OK

22 Decomposition (2NF) Neptun ABCD1 ABCD2 ABCD1 Neptun ABCD1 ABCD2 IDNr. 100AA 101AA 100AA Exam Result IDNr. 100AA 101AA Neptun ABCD1 ABCD2 ABCD1 Exam Result 4 5 3

23 Third normal form (3NF) Definition of 3NF: Fulfilled to 3NF + All attribute that excluded from candidate key full functionally depends on candidate key and only on it. There is no transitional dependency.

24 Decomposition (3NF) BoughtID 1 2 BoughtID 1 2 Bought Chocolate Beer Bought Chocolate Beer Price Product Chocolate Beer Price

25 Higher level of normalizations In practice 3NF is generally satisfactory 3NF ensures in most cases redundancy free DB BCNF, 4NF, 5NF Cons of higher levels: Fragmented table schema Complicated queries Reduces the efficiency of queries

26 In practice To increase efficiency normalization is not strictly performed in some cases.

27 Case Study

28 WebDLT Web based photogrammetry application 3D coordinates are calculable if it can be identified at least on two photos Image coordinates and other data is stored in DB MySQL DBMS + PhpMyAdmin + PHP + HTML + CSS

29

30 Input: User data Image coordinates (2D) Calculation results Output: Image points per project 3D points per project Validation information

31 E/R diagram

32 Relational DB schema diagram

33

34 Queries πprid,pname(σuid=10(projects projects_users)) πpoints_2d.pid(σpid=100&phid=200&prid=2(points_2d points)) σeid=100&prid=2(edges edges.pid1=points.pidpoints)

35 References

36 Exercise I. Given Specification Raw data E/R diagram Relational DB schema diagram Queries In text (by words) Relational algebra

37 Thank You!