1. Database Management Systems Chapter 3 The Relational Data Model (I) Instructor: Li Ma Department of Computer Science Texas Southern University, Houston September, 2006

2. The Relational Data Model Tables Schemas Conversion from E/R to Relations

3. Jeffrey Ullman3 A Relation is a Table namemanf WinterbrewPete’s Bud LiteAnheuser-Busch Beers Attributes (column headers) Tuples (rows)

4. Jeffrey Ullman4 Schemas uRelation schema = relation name and attribute list. wOptionally: types of attributes. wExample: Beers(name, manf) or Beers(name: string, manf: string) uRelation instance = current set of rows. uDatabase = collection of relations. uDatabase schema = set of all relation schemas in the database.

5. Jeffrey Ullman5 A1 A2 A3... An a1 a2 a3 an b1 b2 a3 cn a1 c3 b3 bn. x1 v2 d3 wn Relational Data Model Set theoretic Domain — set of values like a data type Cartesian product (or product) D1  D2 ...  Dn n-tuples (V1,V2,...,Vn) s.t., V1  D1, V2  D2,...,Vn  Dn Relation-subset of cartesian product of one or more domains FINITE only; empty set allowed Tuples = members of a relation inst. Arity = number of domains Components = values in a tuple Domains — corresp. with attributes Cardinality = number of tuples Relation as table Rows = tuples Columns = components Names of columns = attributes Set of attribute names = schema REL (A1,A2,...,An) Arity CardinalityCardinality Attributes Component Tuple

6. Jeffrey Ullman6 Name address tel # 5 3 7 Cardinality of domain Domains N A T N1 A1 T1 N2 A2 T2 N3 A3 T3 N4 T4 N5 T5 T6 T7 Relation: Example Domain of Relation N A T N1 A1 T1 N1 A1 T2 N1 A1 T3. ……. N1 A1 T7 N1 A2 T1 N1 A3 T1 N2 A1 T1 Arity3 Cardinality<=5x3x7 of relation Tuple µ Domain Component Attribute

7. Jeffrey Ullman7 Relation Instance NameAddressTelephone Bob123 Main St555-1234 Bob128 Main St555-1235 Pat123 Main St555-1235 Harry456 Main St555-2221 Sally456 Main St555-2221 Sally456 Main St555-2223 Pat12 State St555-1235

8. Jeffrey Ullman8 About Relational Model Order of tuples not important Order of attributes not important (in theory) Collection of relation schemas (intension) Relational database schema Corresponding relation instances (extension) Relational database intension vs. extension schema vs. data metadata includes schema

9. Jeffrey Ullman9 Why Relations? uVery simple model. uOften a good match for the way we think about our data. uAbstract model that underlies SQL, the most important language in DBMS’s today. wBut SQL uses “bags” while the abstract relational model is set-oriented.

10. Jeffrey Ullman10 From E/R Diagrams to Relations uEntity set -> relation. wAttributes -> attributes. uRelationships -> relations whose attributes are only: wThe keys of the connected entity sets. wAttributes of the relationship itself.

11. Jeffrey Ullman11 Keys in Relations An attribute or set of attributes K is a key for a relation R if we expect that in no instance of R will two different tuples agree on all the attributes of K. uIndicate a key by underlining the key attributes.  Example: If name is a key for Beers : Beers(name, manf)

12. Jeffrey Ullman12 Entity Set -> Relation Relation: Beers(name, manf) Beers name manf

13. Jeffrey Ullman13 Relationship -> Relation DrinkersBeers Likes Likes(drinker, beer) Favorite Favorite(drinker, beer) Married husband wife Married(husband, wife) name addr name manf Buddies 1 2 Buddies(name1, name2)

14. Jeffrey Ullman14 Combining Relations uOK to combine into one relation: 1.The relation for an entity-set E 2.The relations for many-one relationships of which E is the “many.” uExample: Drinkers(name, addr) and Favorite(drinker, beer) combine to make Drinker1(name, addr, favBeer).

15. Jeffrey Ullman15 Risk with Many-Many Relationships uCombining Drinkers with Likes would be a mistake. It leads to redundancy, as: name addr beer Sally 123 Maple Bud Sally 123 Maple Miller Redundancy

16. Jeffrey Ullman16 Handling Weak Entity Sets uRelation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own, nonkey attributes. uA supporting relationship is redundant and yields no relation (unless it has attributes).

17. Jeffrey Ullman17 Example LoginsHostsAt name Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName, hostName2) Must be the same billTo At becomes part of Logins location

18. Jeffrey Ullman18 Subclasses: Three Approaches 1.Object-oriented : One relation per subset of subclasses, with all relevant attributes. 2.E/R style : One relation for each subclass: wKey attribute(s). wAttributes of that subclass. 3.Use nulls : One relation; entities have NULL in attributes that don’t belong to them.

19. Jeffrey Ullman19 Example Beers Ales isa name manf color

20. Jeffrey Ullman20 Object-Oriented namemanf BudAnheuser-Busch Beers name manfcolor Summerbrew Pete’sdark Ales Good for queries like “find the color of ales made by Pete’s.”

21. Jeffrey Ullman21 E/R Style namemanf Bud Anheuser-Busch Summerbrew Pete’s Beers name color Summerbrew dark Ales Good for queries like “find all beers (including ales) made by Pete’s.”

22. Jeffrey Ullman22 Using Nulls namemanf color Bud Anheuser-Busch NULL Summerbrew Pete’s dark Beers Saves space unless there are lots of attributes that are usually NULL.