1 / 134

Database Design Fundamentals: ER Conversion & Relational Model Concepts

Learn about converting an ER design to a relational database, relational algebra, tuple relational calculus, and more key concepts in the structure of relational databases. Explore attributes, rows, relations, schemas, and keys.

helenl
Download Presentation

Database Design Fundamentals: ER Conversion & Relational Model Concepts

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. Chapter 3: Relational Model • Structure of Relational Databases • Convert a ER Design to a Relational Database • Relational Algebra • Tuple Relational Calculus • Domain Relational Calculus • Extended Relational-Algebra-Operations • Modification of the Database • Views

  2. Relation • Another name for table • Columns – attributes • Rows – tuples • Content of a table – instance of a relation

  3. Example of a Relation

  4. Formally • Given sets D1, D2, …. Dn a relation r is a subset of D1 x D2 x … x DnThus a relation is a set of n-tuples (a1, a2, …, an) where each ai Di

  5. Relation Relates Things • Things: customer-name = {Jones, Smith, Curry, Lindsay}customer-street = {Main, North, Park}customer-city = {Harrison, Rye, Pittsfield} • Relation Then r = { (Jones, Main, Harrison), (Smith, North, Rye), (Curry, North, Rye), (Lindsay, Park, Pittsfield)} is a relation over customer-name x customer-street x customer-city

  6. Attribute Types • Each attribute of a relation has a name • The set of allowed values for each attribute is called the domain of the attribute • Attribute values are (normally) required to be atomic, that is, indivisible • E.g. multivalued attribute values are not atomic • E.g. composite attribute values are not atomic • The special value null is a member of every domain

  7. Relation Schema • A1, A2, …, Anare attributes • R = (A1, A2, …, An ) is a relation schema E.g. Customer-schema = (customer-name, customer-street, customer-city) • r(R) is a relation on the relation schema R E.g. customer (Customer-schema)

  8. Relation Instance • The current values (relation instance) of a relation are specified by a table • An element t of r is a tuple, represented by a row in a table attributes (or columns) customer-name customer-street customer-city Jones Smith Curry Lindsay Main North North Park Harrison Rye Rye Pittsfield tuples (or rows) customer

  9. Relations are Unordered • Order of tuples is irrelevant (tuples may be stored in an arbitrary order)

  10. Database • In relational database, a database consists of many relations • Both things and their relationships are represented by relations • Normalization theory (Chapter 7) deals with how to design relational schemas

  11. Keys • Let K  R • K is a superkeyof R if values for K are sufficient to identify a unique tuple of each possible relation r(R) • by “possible r” we mean a relation r that could exist in the enterprise we are modeling. • Example: {customer-name, customer-street} and {customer-name} are both superkeys of Customer, if no two customers can possibly have the same name.

  12. Candidate Keys • K is a candidate key if K is minimal • Example: {customer-name} is a candidate key for Customer, since it is a superkey (assuming no two customers can possibly have the same name), and no subset of it is a superkey.

  13. Convert ER to Relational Database • Entity relation • Attributes attributes • Primary key primary key • Relationship relation • Attributes attributes • We will talk about primary later • Weak entity set relation • Attributes attributes • We will talk about primary key later

  14. Representing Entity Sets as Tables • A strong entity set reduces to a table with the same attributes.

  15. Composite Attributes • Composite attributes are flattened out by creating a separate attribute for each component attribute • E.g. given entity set customer with composite attribute name with component attributes first-name and last-name the table corresponding to the entity set has two attributesname.first-name and name.last-name

  16. Multivalued Attributes • A multivalued attribute M of an entity E is represented by a separate table EM • Table EM has attributes corresponding to the primary key of E and an attribute corresponding to multivalued attribute M • E.g. Multivalued attribute dependent-names of employee is represented by a tableemployee-dependent-names( employee-id, dname) • Each value of the multivalued attribute maps to a separate row of the table EM • E.g., an employee entity with primary key John and dependents Johnson and Johndotir maps to two rows: (John, Johnson) and (John, Johndotir)

  17. Representing Weak Entity Sets • A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set

  18. Representing Relationship Sets as Tables • A many-to-many relationship set is represented as a table with columns for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set. • E.g.: table for relationship set borrower

  19. Redundancy of Tables • Many-to-one and one-to-many relationship sets that are total on the many-side can be represented by adding an extra attribute to the many side, containing the primary key of the one side • E.g.: Instead of creating a table for relationship account-branch, add an attribute branch to the entity set account

  20. Redundancy of Tables • For one-to-one relationship sets, either side can be chosen to act as the “many” side • That is, extra attribute can be added to either of the tables corresponding to the two entity sets • If participation is partial on the many side, replacing a table by an extra attribute in the relation corresponding to the “many” side could result in null values

  21. Determining Keys from E-R Sets • Strong entity set. The primary key of the entity set becomes the primary key of the relation. • Weak entity set. The primary key of the relation consists of the union of the primary key of the strong entity set and the discriminator of the weak entity set.

  22. Determining Keys from E-R Sets • Relationship set. The union of the primary keys of the related entity sets becomes a super key of the relation. • For binary many-to-one relationship sets, the primary key of the “many” entity set becomes the relation’s primary key. Why? • For one-to-one relationship sets, the relation’s primary key can be that of either entity set. Why? • For many-to-many relationship sets, the union of the primary keys becomes the relation’s primary key. Why?

  23. Representing Specialization as Tables • Method 1: • Form a table for the higher level entity • Form a table for each lower level entity set, include primary key of higher level entity set and local attributes tabletable attributesperson name, street, city customer name, credit-ratingemployee name, salary • Drawback: getting information about, e.g., employee requires accessing two tables

  24. Representing Specialization as Tables • Method 2: • Form a table for each entity set with all local and inherited attributes table table attributesperson name, street, city customer name, street, city, credit-ratingemployee name, street, city, salary • If specialization is total, table for generalized entity (person) not required to store information • Can be defined as a “view” relation containing union of specialization tables • But explicit table may still be needed for foreign key constraints • Drawback: street and city may be stored redundantly for persons who are both customers and employees

  25. ER for Banking Enterprise

  26. Schema Diagram for the Banking Enterprise

  27. Query Languages • Categories of languages • procedural • non-procedural • “Pure” languages: • Relational Algebra • Tuple Relational Calculus • Domain Relational Calculus • Declarative languages: • SQL

  28. Relational Algebra • Procedural language • Six basic operators • select • project • union • set difference • Cartesian product • rename • The operators take one or more relations as inputs and give a new relation as a result.

  29. Select Operation – Example A B C D • Relation r         1 5 12 23 7 7 3 10 • A=B ^ D > 5(r) A B C D     1 23 7 10

  30. Select Operation • Notation: p(r) • p is called the selection predicate • Defined as: p(r) = {t | t  rand p(t)} Where p is a formula in propositional calculus consisting of terms connected by :  (and),  (or),  (not)Each term is one of: <attribute>op <attribute> or <constant> where op is one of: =, , >, . <. 

  31. Example of selection • branch-name=“Perryridge”(account) • Selection gives a horizontal subset of a relation • a subset of all the tuples (rows) of a relation

  32. Project Operation – Example • Relation r: A B C     10 20 30 40 1 1 1 2 A C A C • A,C (r)     1 1 1 2    1 1 2 =

  33. Project Operation • Notation:A1, A2, …, Ak (r) where A1, A2 are attribute names and r is a relation name. • The result is defined as the relation of k columns obtained by erasing the columns that are not listed • Duplicate rows removed from result, since relations are sets

  34. Example of Projection • To eliminate the branch-name attribute of accountaccount-number, balance (account) • Projection gives a vertical subset of a relation • a subset of all the columns of a relation

  35. Union Operation – Example A B A B • Relations r, s:    1 2 1   2 3 s r r  s: A B     1 2 1 3

  36. Union Operation • Notation: r s • Defined as: r s = {t | t  r or t  s} • For r s to be valid. • r,s must have the same arity (same number of attributes) • The attribute domains must be compatible (e.g., 2nd column of r deals with the same type of values as does the 2nd column of s)

  37. Example of Union • Find all customers with either an account or a loancustomer-name (depositor)  customer-name (borrower)

  38. Set Difference Operation – Example A B A B • Relations r, s:    1 2 1   2 3 s r r – s: A B   1 1

  39. Set Difference Operation • Notation r – s • Defined as: r – s = {t | t rand t  s} • Set differences must be taken between compatible relations. • r and s must have the same arity • attribute domains of r and s must be compatible

  40. Cartesian-Product Operation-Example A B C D E Relations r, s:   1 2     10 10 20 10 a a b b r s r xs: A B C D E         1 1 1 1 2 2 2 2         10 10 20 10 10 10 20 10 a a b b a a b b

  41. Cartesian-Product Operation • Notation r x s • Defined as: r x s = {t q | t  r and q  s} • Assume that attributes of r(R) and s(S) are disjoint. (That is, R  S = ). • If attributes of r(R) and s(S) are not disjoint, then renaming must be used.

  42. Composition of Operations • Can build expressions using multiple operations • Example: A=C(r x s) • r x s • A=C(r x s) A B C D E         1 1 1 1 2 2 2 2         10 10 20 10 10 10 20 10 a a b b a a b b A B C D E       10 20 20 a a b 1 2 2

  43. Rename Operation • Allows us to refer to a relation by more than one name. • Example: x (E) returns the expression E under the name X • If a relational-algebra expression E has arity n, then • x(A1, A2, …, An)(E) returns the result of expression E under the name X, and with the attributes renamed to A1, A2, …., An.

  44. Banking Example branch (branch-name, branch-city, assets) customer (customer-name, customer-street, customer-only) account (account-number, branch-name, balance) loan (loan-number, branch-name, amount) depositor (customer-name, account-number) borrower (customer-name, loan-number)

  45. Example Queries • Find all loans of over $1200 amount> 1200 (loan) • Find the loan number for each loan of an amount greater than $1200 loan-number (amount> 1200 (loan))

  46. Example Queries • Find the names of all customers who have a loan, an account, or both, from the bank customer-name (borrower)  customer-name (depositor) • Find the names of all customers who have a loan and an account at bank. customer-name (borrower)  customer-name (depositor)

  47. Example Queries • Find the names of all customers who have a loan at the Perryridge branch. customer-name (branch-name=“Perryridge” (borrower.loan-number = loan.loan-number(borrower x loan))) • Find the names of all customers who have a loan at the Perryridge branch but do not have an account at any branch of the bank. customer-name (branch-name = “Perryridge” (borrower.loan-number = loan.loan-number(borrower x loan))) – customer-name(depositor)

  48. Example Queries • Find the names of all customers who have a loan at the Perryridge branch. • Query 1customer-name(branch-name = “Perryridge”( borrower.loan-number = loan.loan-number(borrower x loan)))  Query 2 customer-name(loan.loan-number = borrower.loan-number( (branch-name = “Perryridge”(loan)) x borrower))

  49. Example Queries Find the largest account balance • Rename account relation as d • The query is: balance(account) - account.balance (account.balance < d.balance(account x rd (account)))

  50. Formal Definition • A basic expression in the relational algebra consists of either one of the following: • A relation in the database • A constant relation • Let E1 and E2 be relational-algebra expressions; the following are all relational-algebra expressions: • E1 E2 • E1 - E2 • E1 x E2 • p (E1), P is a predicate on attributes in E1 • s(E1), S is a list consisting of some of the attributes in E1 • x(E1), x is the new name for the result of E1

More Related