1. Translation of ERD to Relational Scheme, Relational Algebra Prof. Sin-Min LEE Department of Computer Science

2. Relation schema –Named relation defined by a set of attribute and domain name pairs. Relational database schema –Set of relation schemas, each with a distinct name. Each tuple is distinct; there are no duplicate tuples. Order of attributes has no significance. Order of tuples has no significance, theoretically. Relation name is distinct from all other relation names in relational schema. Each cell of relation contains exactly one atomic (single) value. Each attribute has a distinct name. Values of an attribute are all from the same domain.

3. Database Scheme A relational database scheme, or schema, corresponds to a set of table definitions. Eg: product(p_id, name, category, description) supply(p_id, s_id, qnty_per_month) supplier(s_id, name, address, ph#) * remember the difference between a DB instance and a DB scheme.

4. SAMPLE SCHEMAS AND INSTANCES The Schemas: Sailors(sid: integer, sname: string, rating: integer, age: real) Boats(bid: integer, bname: string, color: string) Reserves(sid: integer, bid: integer, day: date) The Instances:

5. The entity-relationship model zThe entity-relationship (ER) data model was developed by Peter Chen in the 1970s. zAs its name implies, the ER model provides a systematic representation of the application entities and their relationships. zER diagrams provide a notation for documenting a tentative database design. You capture the important application

6. The entity-relationship model features with ER diagrams, which you then translate into a specific database schema. zER notation represents application entities as rectangles, surrounded by their attributes. An alternative format lists the attributes inside the rectangle, with certain conventions for special kinds of attributes. For example, a key attribute is underlined,

7. The entity-relationship model and a derived attribute is marked with an asterisk. ER diagrams express relationships as diamonds with connecting lines to the participating entities. The lines can be single, indicating partial participation, or double, indicating total participation of the connected entity.

8. zThe entity-relationship model is useful because, it facilitates communication between the database designer and the end user during the requirements analysis. To facilitate such communication the model has to be simple and readable for the database designer as well as the end user. It enables an abstract global view (that is, the enterprise conceptual schema) of the enterprise to be developed without any consideration of efficiency of the ultimate database.

9. The entity-relationship model  A weak entity concept for a situation where the entity ’ s objects aren ’ t meaningful as isolated in the database. It is meaningful only when related to a dominant object, through a many-to-one or one-to-one relationship. The participation of a weak entity must be total.

10. Class hierarchies and inheritance  Although the original entity-relationship model didn ’ t include class hierarchies and lattices, later enhancement added these facilities. These features are useful for database deployment to an object- oriented setting.  A superclass-subclass arrangement among the application entities captures more of the application ’ s meaning.

11. Class specialization and generalization zThe process that derives subclasses from a superclass is specialization. zThe process that abstracts from a collection of specialized subclasses to a superclass is generalization. zPassing from a superclass to a subclass is a specialization to a more detailed description. Rising from a subclass to a

12. Class specialization and generalization superclass is a generalization to a more generic description. zSubclasses inherit the attributes and operations of their superclasses. A subclass specialization can be total, meaning that you always view a superclass object as a generalized view of one or more subclasses. Or it can be partial, meaning that a

13. Class specialization and generalization superclass object can exist without further specialization. To indicate total specialization, you double the connecting line impinging on the superclass.

14. Overlapping subclasses and multiple inheritance zIndependent of its total-partial status, a specialization can be disjoint or overlapping. zIn a disjoint specialization, an object that is further classified must belong to exactly one of the subclasses. zOverlapping specialization occurs when an object belongs simultaneously to two or

15. Overlapping subclasses and multiple inheritance more subclasses. zA thorny issue, which causes difficulties when mapping an ER diagram to a database schema, is multiple inheritance. zIn multiple inheritance, a class inherits attributes from several superclasses. Multiple inheritance and overlapping specialization frequently occur together

16. Overlapping subclasses and multiple inheritance because the subclasses of the overlapping specialization can rejoin deeper in the lattice in a multiple inheritance situation.

17. Mapping from ER diagrams to database schemas zYou can map an ER diagram to any of the five database schemas (relational, network, hierarchical, object-oriented, and deductive database). zHowever, the mappings frequently compromise distinctions documented in the diagram. ER-to-relational mapping occurs most frequently.

24. Mapping from ER diagrams to a relational schema zTransforming an ER diagram into a relational database schema proceeds as follows: - You examine each attribute, x, of each entity, E, for the following special cases - If x is a composite attribute, you flatten it. You retain only the leaf entries of the hierarchical structure. - If x is a derived attribute, you remove it. You can make it available through a view after

25. Mapping from ER diagrams to a relational schema you have established the database schema. - If x is a multivalued attribute, you create a new weak entity, E x, and a one-to-many relationship between E and E x. You move the multivalued attribute to E x. - You decompose many-to-many and higher- degree relationships into collections of one-to- many relationships. You transfer any relationship attributes to the intersection entity.

26. Mapping from ER diagrams to a relational schema - You fold any relationship attributes attached to one-to-many relationships into the dependent entity. - You give key attributes to all dominant entities if they aren ’ t already present. - You give a foreign key to the dependent entity of each one-to-many relationship; you use the same name as the key in its dominant partner.

27. Mapping from ER diagrams to a relational schema - You prepare a create-table SQL statement for each entity of the transformed diagram and use the appropriate clauses to enforce key constraints, referential integrity, total participation, and weak entities. - Anticipating frequent joins across the established relationships, you index all primary and foreign keys--if the database product allows explicit index creation.

28. Mapping from ER diagrams to a relational schema In summary, you translate an ER diagram into a relational schema by: 1. Transforming multivalued and composite attributes. 2. Decomposing many-to-many and higher- degree relationships. 3. Introducing keys and foreign keys. Each entity then becomes a relation.

29. Mapping from ER diagrams to a relational schema So, if there is no subclass structure, the mapping proceeds by flattening composite attributes, removing derived attributes, exporting multivalued attributes to weak entities, and factoring all many-to-many and higher-degree relationships through an intersection entity. You then transfer relationship attributes to the intersection entity, or you fold them into the dependent side of a one-to-X relationship.

30. Mapping from ER diagrams to a relational schema All dominant entities receive primary keys, and all dependent entities receive foreign keys of the same name. Each entity then becomes a relation. If subclass specializations are present, you must remove them before the transformation. Some methods are available to reduce superclass-subclass specializations from an ER diagram before mapping to a relational schema.

31. Mapping from ER diagrams to a relational schema 1. The most semantically damaging approach collapses a specialization into the superclass, providing slots for all possible attributes and flags to mark the suppressed subclasses. 2. A less drastic alternative repeats the superclass attributes in the subclasses, but this approach is available only when the specialization is total.

32. Mapping from ER diagrams to a relational schema 3. A final possibility converts subclasses to full-fledged entities and connects them to the superclass with restricted relationships. - All three techniques share the disadvantage of masking semantic nuances in the ER diagram.

33. What is Relational Algebra? zRelational algebra is a procedural query language. zIt consists of the select, project, union, set difference, Cartesian product, and rename operations. zSet intersection, division, natural join, and assignment combine the fundamental operations. zSQL is based on relational algebra

35. Query languages zprocedural vs. non-procedural zcommercial languages have some of both zwe will study: yrelational algebra ( which is procedural, i.e. tells you how to process a query ) yrelational calculus ( which is non-procedural i.e. tells what you want )

36. Introduction z one of the two formal query languages of the relational model z collection of operators for manipulating relations z Operators: two types of operators y Set Operators: Union(  ),Intersection(  ), Difference(-), Cartesian Product (x)  New Operators: Select (  ), Project (  ), Join ( ⋈ )

37. Introduction – cont’d z A Relational Algebra Expression: a sequence of relational algebra operators and operands (relations), formed according to a set of rules. z The result of evaluating a relational algebra expression is a relation.

38. Selection z Denoted by  c ( R ) z Selects the tuples (rows) from a relation R that satisfy a certain selection condition c. z It is a unary operator z The resulting relation has the same attributes as those in R.

39. Example 1: SNOSNAMEAGESTATE S1MIKE21IL S2STEVE20LA S3MARY18CA S4MING19NY S5OLGA21NY S:  state=‘IL’ (S)

40. Example 2: CNOCNAMECREDITDEPT C1 Databas e 3CS C2 Statistic s 3MATH C3Tennis1SPORTS C4Violin4MUSIC C5Golf2SPORTS C6Piano5MUSIC C:  CREDIT  3 (C)

41. Example 3 SNOCNOGrade S1C190 S1C280 S1C375 S1C470 S1C5100 S1C660 S2C190 S2C280 S3C290 S4C280 S4C485 S4C5100 E:  SNO=‘S1’and CNO=‘C1’ (E)

43. Selection - Properties z Selection Operator is commutative  C1 (  C2 (R)) =  C2 (  C1 (R)) z The Selection is an unary operator, it cannot be used to select tuples from more than one relations.

44. Projection z Denoted by  L (R), where L is list of attribute names and R is a relation name or some other relational algebra expression. z The resulting relation has only those attributes of R specified in L. z The projection is also an unary operation.  Duplicate rows are not permitted in relational algebra. Duplication is removed from the result. zDuplicate rows can occur in SQL, though they may be controlled by explicit keywords.

46. Projection - Example z Example 1:  STATE (S) SNOSNAMEAGESTATE S1MIKE21IL S2STEVE20LA S3MARY18CA S4MING19NY S5OLGA21NY STATE IL LA CA NY

47. Projection - Example Example 2:  CNAME, DEPT (C) CNOCNAMECREDITDEPT C1 Databas e 3CS C2 Statistic s 3MATH C3Tennis1SPORTS C4Violin4MUSIC C5Golf2SPORTS C6Piano5MUSIC CNAMEDEPT Databas e CS Statistic s MATH TennisSPORTS ViolinMUSIC GolfSPORTS PianoMUSIC

48. Projection - Example Example 3:  S# (  STATE=‘NY' (S)) SNOSNAMEAGESTATE S1MIKE21IL S2STEVE20LA S3MARY18CA S4MING19NY S5OLGA21NY SNO S4 S5

49. SET Operations z UNION: R 1  R 2 z INTERSECTION: R 1  R 2 z DIFFERENCE: R 1 - R 2 z CARTESIAN PRODUCT: R 1  R 2

50. Union Compatibility z For operators , , -, the operand relations R1(A1, A2,..., An) and R2(B1, B2,..., Bn) must have the same number of attributes, and the domains of the corresponding attributes must be compatible; that is, dom(Ai)=dom(Bi) for i=1,2,...,n. z The resulting relation for , , or - has the same attribute names as the first operand relation R1 (by convention).

51. Union Compatibility - Examples z Are S(SNO, SNAME, AGE, STATE) and C(CNO, CNAME, CREDIT, DEPT) union compatible? z Are S(S#, SNAME, AGE, STATE) and C(CNO, CNAME, CREDIT_HOURS, DEPT_NAME) union compatible?

53. UNION, SET DIFFERENCE & SET INTERSECT zUnion puts all tuples of two relations in one relation. To use this operator, two conditions must hold: 1.The two relations must be of the same arity. 2.The domain of i th attribute of the two participating relation must be the same. zSet difference operator computes tuples that are in one relation, but not in another. zSet intersect operator computes tuples that are common in two relations: zThe five fundamental operations of the relational algebra are: select, project, cartesian product, Union, and set difference zAll other operators can be constructed using these operators

54. EXAMPLE zAssume a database with the following three relations: Sailors (sid, sname, rating) Boats (bid, bname, color) Reserve (sid, bid, date) zQuery 1: Find the bid of red colored boats:

55. EXAMPLE zAssume a database with the following three relations: Sailors (sid, sname, rating) Boats (bid, bname, color) Reserve (sid, bid, date) zQuery 1: Find the bid of red colored boats: y∏ bid (б color=red (Boats))

56. EXAMPLE zAssume a database with the following three relations: Sailors (sid, sname, rating) Boats (bid, bname, color) Reserve (sid, bid, date) zQuery 1: Find the name of sailors who have reserved Boat number 2.

57. EXAMPLE zAssume a database with the following three relations: Sailors (sid, sname, rating) Boats (bid, bname, color) Reserve (sid, bid, date) zQuery 1: Find the name of sailors who have reserved Boat number 2. y∏ sname (б bid=2 (Sailors (sid) Reserve))

58. EXAMPLE zAssume a database with the following three relations: Sailors (sid, sname, rating) Boats (bid, bname, color) Reserve (sid, bid, date) zQuery 1: Find the name of sailors who have reserved both a red and a green boat.

59. Union, Intersection, Difference z T= R U S : A tuple t is in relation T if and only if t is in relation R or t is in relation S z T = R  S: A tuple t is in relation T if and only if t is in both relations R and S z T= R - S :A tuple t is in relation T if and only if t is in R but not in S

60. Set-Intersection  Denoted by the symbol .  Results in a relation that contains only the tuples that appear in both relations. zR  S = R – (R – S) zSince set-intersection can be written in terms of set-difference, it is not a fundamental operation.

61. Examples A1A2 1Red 3White 4green B1B2 3White 2Blue RS

62. Examples A1A2 1Red 3White 4Green 2Blue A1A2 3White R  S R  S S - R B1B2 2Blue A1A2 1Red 4Green R - S

63. RENAME OPERATOR zRename operator changes the name of its input table to its subscript, yρ e2 (Emp) yChanges the name of Emp table to e2

64. EXAMPLE zEmp table: SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001

65. EXAMPLE zEmp table: zб Salary=30,000 (Employee) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001

66. EXAMPLE zEmp table: zб Salary=30,000 (Employee) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001 SS#NameAgeSalarydno 4Kathy30300005

67. EXAMPLE zEmp table: zб Age>22 (Employee) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001

68. EXAMPLE zEmp table: zб Age>22 (Employee) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001 SS#NameAgeSalarydno 1Joe24200002 4Kathy30300005

69. PROJECT OPERATOR zProject (∏) retrieves a column. It is a unary operator that eliminate duplicates. e.g., name of employees: ∏ name (Employee) e.g., name of employees earning more than 30,000: ∏ name ( б Salary>30,000 (Employee))

70. EXAMPLE zEmp table: SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001

71. EXAMPLE zEmp table: z∏ age (Emp) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001 Age 24 20 22 30 4

72. EXAMPLE zEmp table: z∏ name,age ( б Salary=4000 (Emp) ) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001

73. EXAMPLE zEmp table: z∏ name,age (б Salary=4000 (Emp) ) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001 SS#NameAgeSalarydno 5Shideh440001

74. EXAMPLE zEmp table: z∏ name,age ( б Salary=4000 (Emp) ) SS#NameAgeSalarydno 1Joe24200002 2Mary20250003 3Bob22270004 4Kathy30300005 5Shideh440001 NameAge Shideh4