1 / 41

Database Systems Overview

Database Systems Overview. Souhad Daraghma. Motivation. Databases are everywhere: Web Corporate records (sales, production, customers,employees, payrolls) Banking systems Stock exchanges Universities, (students, grades) Hospitals Airline systems CD collections at home.

ethel
Download Presentation

Database Systems Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Database SystemsOverview SouhadDaraghma

  2. Motivation Databases are everywhere: • Web • Corporate records (sales, production, customers,employees, payrolls) • Banking systems • Stock exchanges • Universities, (students, grades) • Hospitals • Airline systems • CD collections at home • . . .

  3. Motivation continue • Very useful • Interesting mix of many desired functionalities – Efficiency – Flexibility – Capacity – Reliability • Interesting mix of many methodologies – Graphic and formal languages (modeling, querying) – Data structures and algorithms – Computer architecture – Concurrency issues • Career enhancement ($$)

  4. Database Systems

  5. Relational Algebra

  6. What is an “Algebra” • Mathematical system consisting of: • Operands --- variables or values from which new values can be constructed. • Operators --- symbols denoting procedures that construct new values from given values.

  7. What is Relational Algebra? • An algebra whose operands are relations or variables that represent relations. • Operators are designed to do the most common things that we need to do with relations in a database. • The result is an algebra that can be used as a query language for relations.

  8. Roadmap • There is a core relational algebra that has traditionally been thought of as the relational algebra. • But there are several other operators we shall add to the core in order to model better the language SQL --- the principal language used in relational database systems.

  9. Core Relational Algebra • Union, intersection, and difference. • Usual set operations, but require both operands have the same relation schema. • Selection: picking certain rows. • Projection: picking certain columns. • Products and joins: compositions of relations. • Renaming of relations and attributes.

  10. Selection • R1 := SELECTC (R2) • C is a condition (as in “if” statements) that refers to attributes of R2. • R1 is all those tuples of R2 that satisfy C.

  11. Example1 • σage>= 30 (Person) • σage>=weight (Person)

  12. Example2 • σrating > 8 (Employee) • σsname = “Jamal” (Employee)

  13. Projection • R1 := PROJL (R2) • L is a list of attributes from the schema of R2. • R1 is constructed by looking at each tuple of R2, extracting the attributes on list L, in the order specified, and creating from those components a tuple for R1. • Eliminate duplicate tuples, if any.

  14. name, hobby (Person) .  Hobby (Person)

  15. Product • R3 := R1 * R2 • Pair each tuple t1 of R1 with each tuple t2 of R2. • Concatenation t1t2 is a tuple of R3. • Schema of R3 is the attributes of R1 and R2, in order. • But beware attribute A of the same name in R1 and R2: use R1.A and R2.A.

  16. Example1 R S R x S

  17. S R Example2 R X S

  18. Theta-Join • R3 := R1 JOINC R2 • Take the product R1 * R2. • Then apply SELECTC to the result. • As for SELECT, C can be any boolean-valued condition. • Historic versions of this operator allowed only A theta B, where theta was =, <, etc.; hence the name “theta-join.”

  19. Natural Join • A frequent type of join connects two relations by: • Equating attributes of the same name, and • Projecting out one copy of each pair of equated attributes. • Called natural join. • Denoted R3 := R1 JOIN R2.

  20. Example

  21. Renaming • The RENAME operator gives a new schema to a relation. • R1 := RENAMER1(A1,…,An)(R2) makes R1 be a relation with attributes A1,…,An and the same tuples as R2. • Simplified notation: R1(A1,…,An) := R2.

  22. Building Complex Expressions • Algebras allow us to express sequences of operations in a natural way. • Example: in arithmetic --- (x + 4)*(y - 3). • Relational algebra allows the same. • Three notations, just as in arithmetic: • Sequences of assignment statements. • Expressions with several operators. • Expression trees.

  23. Sequences of Assignments • Create temporary relation names. • Renaming can be implied by giving relations a list of attributes. • Example: R3 := R1 JOINC R2 can be written: R4 := R1 * R2 R3 := SELECTC (R4)

  24. Expressions in a Single Assignment • Example: the theta-join R3 := R1 JOINC R2 can be written: R3 := SELECTC (R1 * R2) • Precedence of relational operators: • Unary operators --- select, project, rename --- have highest precedence, bind first. • Then come products and joins. • Then intersection. • Finally, union and set difference bind last. • But you can always insert parentheses to force the order you desire.

  25. Functional Dependencies & Normalization

  26. Redundancy and Normalisation • Redundant Data • Can be determined from other data in the database • Leads to various problems • INSERT anomalies • UPDATE anomalies • DELETE anomalies

  27. Redundancy and Normalisation • Normalisation • Aims to reduce data redundancy • Redundancy is expressed in terms of dependencies • Normal forms are defined that do not have certain types of dependency

  28. Functional Dependencies • Redundancy is often caused by a functional dependency • A functional dependency (FD) is a link between two sets of attributes in a relation • We can normalise a relation by removing undesirable FDs

  29. Functional Dependencies (FDs) • A functional dependencyX  Y holds over relation schema R if, for every allowable instance r of R: t1  r, t2  r, pX (t1) = pX (t2) implies pY (t1) = pY (t2) (where t1 and t2 are tuples; X and Y are sets of attributes) • The attribute on the left side of the functional dependency is called the determinant, while the “” reads as “determines”

  30. Functional Dependencies • In other words there exists a functional dependency between X and Y (X  Y), if whenever two rows of the relation have the same values for all the attributes in X, then they also have the same values for all the attributes in Y. • Example: SID  DormName, Fee (CustomerNumber, ItemNumber, Quantity)  Price • While a primary key is always a determinant, a determinant is not necessarily a primary key

  31. Normalization • Normalization eliminates modification anomalies • Deletion anomaly: deletion of a row loses information about two or more entities • Insertion anomaly: insertion of a fact in one entity cannot be done until a fact about another entity is added • Anomalies can be removed by splitting the relation into two or more relations; each with a different, single theme • However, breaking up a relation may create referential integrity constraints • Normalization works through classes of relations called normal forms

  32. Relationship of Normal Forms

  33. FDs and Normalisation • We define a set of 'normal forms' • Each normal form has fewer FDs than the last • Since FDs represent redundancy, each normal form has less redundancy than the last • Not all FDs cause a problem • We identify various sorts of FD that do • Each normal form removes a type of FD that is a problem • We will also need a way to remove FDs

  34. Reasoning About FDs • Given some FDs, we can usually infer additional FDs: title  studio, starimplies title  studioand title  star title  studioand title  starimplies title  studio, star title  studio, studio  starimplies title  star But, title, star  studiodoes NOT necessarily imply that title  studio or that star  studio • An FD f is implied bya set of FDs F if f holds whenever all FDs in F hold. • F+ = closure of Fis the set of all FDs that are implied by F. (includes “trivial dependencies”)

  35. Rules of Inference • Armstrong’s Axioms (X, Y, Z are sets of attributes): • Reflexivity: If X  Y, then X  Y • Augmentation: If X  Y, then XZ  YZ for any Z • Transitivity: If X  Y and Y  Z, then X  Z • These are sound and completeinference rules for FDs! • i.e., using AA you can compute all the FDs in F+ and only these FDs. • Some additional rules (that follow from AA): • Union: If X  Y and X  Z, then X  YZ • Decomposition: If X  YZ, then X  Y and X  Z

  36. Rules of Inference • Rules that follow from AA: • Union: If X  Y and X  Z, then X  YZ X  Y, XX  XY (Aug), so X  XY X  Z, XY  YZ (Aug) so X  YZ (Trans)

  37. Rules of Inference • Rules that follow from AA: • Decomposition: If X  YZ, then X  Y and X  Z X  YZ, YZ  Y (Reflex), so X  Y (Trans) Similar for X  Z.

  38. Attribute Closure • Computing the closure of a set of FDs can be expensive. (Size of closure is exponential in # attrs!) • Typically, we just want to check if a given FD X  Y is in the closure of a set of FDs F. An efficient check: • Compute attribute closureof X (denoted X+) wrt F. X+ = Set of all attributes A such that X  A is in F+ • X+ := X • Repeat until no change: if there is an fd U  V in F such that U is in X+, then add V to X+ • Check if Y is in X+ • Approach can also be used to find the keys of a relation. • If all attributes of R are in the closure of X then X is a superkey for R. • Q: How to check if X is a “candidate key”?

  39. Attribute Closure (example) R = {A, B, C, D, E} F = { B CD, D  E, B  A, E  C, AD B } • Is B  E in F+ ? B+ = B B+ = BCD B+ = BCDA B+ = BCDAE … Yes! and B is a key for R too! • Is D a key for R? D+ = D D+ = DE D+ = DEC … Nope!

  40. Attribute Closure (example) R = {A, B, C, D, E} F = { B CD, D  E, B  A, E  C, AD B } • Is AD a key for R? AD+ = AD AD+ = ABD and B is a key, so Yes! • Is AD a candidate key for R? A+ = A, D+ = DEC A,D not keys, so Yes! • Is ADE a candidate key for R? No! AD is a key, so ADE is a superkey, but not a cand. key

  41. Normal Forms • Any table of data is in 1NF if it meets the definition of a relation • A relation is in 2NF if all its non-key attributes are dependent on all of the key (no partial dependencies) • If a relation has a single attribute key, it is automatically in 2NF • A relation is in 3NF if it is in 2NF and has no transitive dependencies • A relation is in BCNF if every determinant is a candidate key • A relation is in fourth normal form if it is in BCNF and has no multi-value dependencies

More Related