John Barnden Professor of Artificial Intelligence

Slides:



Advertisements
Similar presentations
Chapter 3 : Relational Model
Advertisements

Fundamentals/ICY: Databases 2013/14 Week 6: Monday John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham,
Mapping ERM to relational database
Intro to Maths for CS: 2013/14 Sets (2) – OPTIONAL MATERIAL John Barnden Professor of Artificial Intelligence School of Computer Science University of.
Lecture 2 The Relational Model. Objectives Terminology of relational model. How tables are used to represent data. Connection between mathematical relations.
Chapter 4 The Relational Model Pearson Education © 2014.
Chapter 4 The Relational Model.
Fundamentals/ICY: Databases 2010/11 WEEK 11 John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK.
IS 325 Notes for Wednesday September 18, 2013.
Converting ER model Into Relational Table
Fundamentals/ICY: Databases 2012/13 WEEK 7 John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK.
Fundamentals/ICY: Databases 2013/14 Week 10 –Monday –Normalization, contd John Barnden Professor of Artificial Intelligence School of Computer Science.
©Silberschatz, Korth and Sudarshan2.1Database System Concepts Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Design Issues Mapping.
Slide Chapter 5 The Relational Data Model and Relational Database Constraints.
CS 370 Database Systems Lecture 9 The Relational model.
Chapter 9: Logical Database Design and the Relational Model (ERD Mapping)
1 © Prentice Hall, 2002 Chapter 5: Logical Database Design and the Relational Model Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B.
Fundamentals/ICY: Databases 2013/14 WEEK 9 –Monday John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham,
Fundamentals/ICY: Databases 2013/14 WEEK 9 –Friday John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham,
Fundamentals/ICY: Databases 2013/14 Week 5: Monday John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham,
Fundamentals/ICY: Databases 2012/13 Week 4 John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK.
Fundamentals/ICY: Databases 2013/14 Week 4: Friday John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham,
Intro to Maths for CS: 2012/13 Sets (end, week 3) John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham,
Fundamentals/ICY: Databases 2013/14 Week 11 – Monday – relations, ended. John Barnden Professor of Artificial Intelligence School of Computer Science University.
Fundamentals/ICY: Databases 2012/13 WEEK 9 John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK.
1 The Relational Data Model David J. Stucki. Relational Model Concepts 2 Fundamental concept: the relation  The Relational Model represents an entire.
ER Diagrams and Relational Model CS 174a (Winter 2015)
Chapter 2: Entity-Relationship Model
COP Introduction to Database Structures
Comp 1100 Entity-Relationship (ER) Model
Relational Database Design by ER- and ERR-to-Relational Mapping
Relational Model Database Management Systems, 3rd ed., Ramakrishnan and Gehrke, Chapter 3.
Intro to Maths for CS: 2012/13 Sets (contd, week 2)
Fundamentals/ICY: Databases 2013/14 WEEK 8 –Monday
Entity-Relationship Model
Entity Relationship Model
EER Model – Chapter
Chapter 2: Relational Model
Entity-Relationship Model
Chapter 2: Entity-Relationship Model
Tables and Their Characteristics
Database Design The Relational Model Text Ch5
Chapter 7: Entity-Relationship Model
Chapter 7 Entity-Relationship Model
Entity-Relationship Model
Outline of the ER Model By S.Saha
Constraints in Entity-Relationship Models
Fundamentals/ICY: Databases 2010/11 WEEK 6
Lecture # 13 (After 1st Exam)
Chapter 2: Intro to Relational Model
Data Base System Lecture 6: Relational Model
Chapter 4 The Relational Model Pearson Education © 2009.
Chapter 4 The Relational Model Pearson Education © 2009.
Chapter 4 The Relational Model Pearson Education © 2009.
Entity-Relationship Model
Database Systems: Design, Implementation, and Management Tenth Edition
CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL
02 - The Relational Database Model
The Relational Model Transparencies
Database Systems Instructor Name: Lecture-9.
Chapter 6: Entity-Relationship Model
Chapter 4 The Relational Model Pearson Education © 2009.
Review of Week 1 Database DBMS File systems vs. database systems
Chapter 2: Intro to Relational Model
Chapter 4 The Relational Model Pearson Education © 2009.
Chapter 7: Entity-Relationship Model
Fundamentals/ICY: Databases 2013/14 WEEK 6 - Friday
Chapter 4 The Relational Model Pearson Education © 2009.
Introduction to modeling
Chapter 3: Multivalued Dependencies
Presentation transcript:

Fundamentals/ICY: Databases 2013/14 Week 10 – Monday/Friday – relations, contd. John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK

Reminder

Relation from a Table   ‘9568876A’, ‘Chopples’, 37 >, People PERS-ID NAME AGE 9568876A Chopples 37 2544799Z Blurp 1698674F Rumpel 88 The relation at the moment is   ‘9568876A’, ‘Chopples’, 37 >,  ‘2544799Z’, ‘Blurp’, NULL >,  ‘1698674F’, ‘Rumpel’, 88 > 

New

Note: ((Items in double round brackets are optional material))

“Relations don’t remember where they came from” Consider a relation R on A, B, C, D, E, … i.e., R  A  B  C  D  E  …. Suppose A  AA, B  BB, C  CC, etc. Then: a tuple formed from sets A, B, … is also automatically a tuple formed from AA, BB, … That is, R  AA  BB  CC  DD  EE  …. So R is also a relation on AA, BB, CC, DD, EE, …. So a relation has no very tight connection to the original sets it might have been defined from, unlike the case of tables, where the attribute domains are part of the nature of the table.

“Arity” of Relations A relation on two sets is binary, on three sets is ternary, … … even when not all the sets are different. So a relation on A and A is still binary and NOT “unary.” The members of the relation are two-element tuples. A relation on, say, A, B and A is ternary and not binary. The members of the relation are three-element tuples.

“Arity” of Relations, contd. A “unary relation” on A is a set of singleton tuples formed from A elements. (But is sometyimes loosely taken to be just a subset of A.) Unusual (though not inconceivable) to want a single-attribute table in a finalized ER model. But one-attribute tables often arise dynamically from table operations, as you know.

Relations from Somewhere to Somewhere A relation R “from” set A “to” set B is the same thing as a relation “on” A “and” B — just different terminology. Similarly, a relation from A, B, C to D, E is the same thing as a relation on A, B, C, D, E.

Changing the Sets in a Relation Around A relation R on A, B, C, D, E, say, obviously “induces” (i.e., gives rise to, in a natural way) a relation on any reordering of the sets, such as D, A, B, E, C, just by reordering each tuple in the same way. Thus, R induces a relation from, say, D, A to B, E, C. When there are just two sets A and B, the (only possible) reordering of the sets gives the inverse of R.

Removing some of the Sets in a Relation (Projection) And we can remove some of the sets and the corresponding items from each tuple. Given the relation on D,A,B,E,C, we can get a relation on, say, D,B,C, just by removing the second and fourth item from each tuple. This is the mathematical operation underlying the PROJECT relational operator on tables (what I would prefer call Select-Columns or Select-Attributes).

Functional Relations (Partial Functions) A relation R from A to B is functional if, for any a in A, there is AT MOST one (but perhaps no) b in B such that a, b> is in R. So several things in A can be related to the same thing in B. But you can’t have several things in B related to the same thing in A. A functional relation from A to B is also called a partial function from A to B.

Functional Relations, contd. Can generalize: a relation R from A1, A2, A3 … to B1, B2, B3, …is functional if, for each combination of things a1, a2, a3, … in A1, A2, A3, … respectively, there is at most one b1, b2, b3, … in B1, B2, B3, … respectively such that a1, a2, a3, …, b1, b2, b3, …> is in R.

Functional Relations arising from Functional Dependencies in a DB Suppose attribute X is functionally dependent on (= determined by) attributes A, B, … in a table. Then, at any moment, the induced relation from A, B to X is a partial function from the A, B, … value domains to the X value domain. Special case: Consider any superkey (e.g., the primary key) of a table. Then the relation in the table at a given moment is a partial function from the superkey’s domains to the remaining attribute domains (if any).

Caution The word “partial” in the phrase “partial function” has nothing to do with the word “partial” in “partial dependency” as discussed under Normalization. Any dependency relationship in a table gives us a partial function, irrespective of whether the dependency is also “partial” in the special sense of involving only a part of the PK.

((Restriction of a Relation)) Consider a relation R from A to B, and a subset AA of A. Then the restriction of R to AA is the relation derived from R by restricting attention to AA, i.e., including only tuples whose first element is in AA. The new relation is notated R|AA

((Restriction More Generally)) Consider a relation R from A, B, …C to D, E, …, F and subsets AA of A, BB of B, …, CC of C. Then the restriction of R to AA, BB, …, CC is the relation derived from R by restricting attention to AA, BB, …, CC i.e., including only tuples whose first few elements are in AA, BB, …, CC respectively. The new relation is notated R|AA, BB, …, CC

Totality of Relations A relation R from A to B is total (on A) if it relates everything in A to at least one thing in B. I.e., for every member a of A, there is at least one b in B such that  a, b > is in R.

Totality, contd. Can generalize:  a, b, c, …, d, e, … > is in R. A relation R from A, B, C, … to D, E, … is total (on A, B, C, …) if for every member a of A, b of B, c of C, etc. there is at least one d in D, e in E, etc. such that  a, b, c, …, d, e, … > is in R.

Partiality of Table Relations The relation in a table (at a given moment), considered as a relation from any of its attribute value domains to the remaining value domains, will almost always NOT be total. This is simply because it’s highly unlikely that all possible combinations of values from the former collection of value domains will appear in the table!!

Functions A total functional relation from A to B is called a function from A to B. Each thing in A is related to exactly one thing in B. (But two different things in A can be related to the same thing in B, and not everything in B needs to be related to anything in A. So the inverse relation is not necessarily either functional or total.) Caution: every function is also a partial function.

((From Partiality to Totality by Restriction)) We can always turn a merely-partial R from A to B into a total one by slimming A down enough! Just remove the members of A that aren’t related to anything by R, to get a new set AA. We don’t remove any tuples from R. R (as a relation from AA to B) is total on AA. And note that R|AA = R. AA is called the domain of R, notated dom(R). Not to be confused with “value domains” of DB entity attributes. Can generalize the above to non-binary relations.

((Totality contd. and “Onto”)) A relation R from A to B is onto if for everything in B there is at least one thing in A that is related by R to it. I.e.: For every member b of B, there is at least one a in A such that a, b> is in R. Onto-ness is just totality in the other direction. You can also say that R is total on B, or that the inverse of R is total.

Other Categories of Relation A relation R from A to B is one-to-one (1-1) if, for any a in A, there is at most one b in B such that a, b> is in R, AND for any b in B, there is at most one a in A such that a, b> is in R. That is, both the relation and its inverse from B to A are functional. (But they don’t need to be total.) To put it another way: it is functional and different members of A map to (= are related to) different members of B. Or again: Different members of A map to different members of B and different members of B map to different members of A.