UNIT-2 DBMS

The Relational Data Model Origins of the Relational Model • Developed by British computer scientist E.F. (Ted) Codd of IBM in a seminal paper in 1970 (A Relational Model for Large Shared Data Banks, Communications of the ACM, June 1970) • Considered ingenious but impractical in 1970 • Conceptually simple • Computers lacked power to implement the relational model • Today, microcomputers can run sophisticated relational database software

Relational Model Concepts •

Domain: A (usually named) set/universe of atomic values, where by "atomic" we mean simply that, from the point of view of the database, each value in the domain is indivisible (i.e., cannot be broken down into component parts). Examples of domains o o o o o

SSN: string of digits of length nine Name: string of characters beginning with an upper case letter GPA: a real number between 0.0 and 4.0 Sex: a member of the set { female, male } Dept_Code: a member of the set { CSE, IT, ECE, EEE, MECH, ... }

These are all logical descriptions of domains. For implementation purposes, it is necessary to provide descriptions of domains in terms of concrete data types (or formats) that are provided by the DBMS (such as String, int, boolean), in a manner analogous to how programming languages have intrinsic data types. Attribute: the name of the role played by some value (coming from some domain) in the context of a relational schema. The domain of attribute A is denoted dom(A). • Tuple: A tuple is a mapping from attributes to values drawn from the respective domains of those attributes. A tuple is intended to describe some entity (or relationship between entities) in the miniworld. •

As an example, a tuple for a PERSON entity might be { Name --> "Rama Krishna", •

Sex --> Male,

IQ --> 786 }

Relation: A (named) set of tuples all of the same form (i.e., having the same set of attributes). The term table is a loose synonym.

ER-CSEB

1

•

Relational Schema: used for describing (the structure of) a relation. E.g., R(A1, A2, ..., An) says that R is a relation with attributes A1, ... An . The degree of a relation is the number of attributes it has, here n. Example: STUDENT(Name, SSN, Address) One would think that a "complete" relational schema would also specify the domain of each attribute.

•

Relational Database: A collection of relations, each one consistent with its specified relational schema.

Characteristics of Relations • Ordering of Tuples: A relation is a set of tuples; hence, there is no order associated with them. • Ordering of Attributes: A tuple is best viewed as a mapping from its attributes (i.e., the names we give to the roles played by the values comprising the tuple) to the corresponding values. Hence, the order in which the attributes are listed in a table is irrelevant. (Note that, unfortunately, the set theoretic operations in relational algebra (at least how Elmasri& Navathe define them) make implicit use of the order of the attributes. Hence, Elmasri& Navathe view attributes as being arranged as a sequence rather than a set.) • Values of Attributes: For a relation to be in First Normal Form, each of its attribute domains must consist of atomic (neither composite nor multi-valued) values. Much of the theory underlying the relational model was based upon this assumption. • Interpretation of a Relation: Each relation can be viewed as a predicate and each tuple an assertion that that predicate is satisfied (i.e., has value true) for the combination of values in it. In other words, each tuple represents a fact.

Relational Model Constraints and Relational Database Schemas Constraints on databases can be categorized as follows: • Inherent model-based: Example: no two tuples in a relation can be duplicates (because a relation is a set of tuples) • Schema-based: can be expressed using DDL; this kind is the focus of this section. • Application-based: are specific to the "business rules" of the miniworld and typically difficult or impossible to express and enforce within the data model. Hence, it is left to application programs to enforce.

ER-CSEB

2

Elaborating upon schema-based constraints:

Domain Constraints: Each attribute value must be either null (which is really a nonvalue) or drawn from the domain of that attribute.

Key Constraints: A relation is a set of tuples, and each tuple's "identity" is given by the values of its attributes. Hence, it makes no sense for two tuples in a relation to be identical (because then the two tuples are actually one and the same tuple). That is, no two tuples may have the same combination of values in their attributes. Superkey of a relation is subsets of attributes, for which no two tuples can have the same combination of values. From the fact that no two tuples can be identical, it follows that the set of all attributes of a relation constitutes a superkey of that relation. A key is a minimal superkey, i.e., a superkey such that, if we were to remove any of its attributes, the resulting set of attributes fails to be a superkey. Example: Suppose that we stipulate that a faculty member is uniquely identified by Name and Address and also by Name and Department, but by no single one of the three attributes mentioned. Then { Name, Address, Department } is a (non-minimal) superkey and each of { Name, Address } and { Name, Department } is a key (i.e., minimal superkey). Candidate key: any key (i.e., any minimal superkey) Primary key: a key chosen to act as the means by which to identify tuples in a relation. Typically, one prefers a primary key to be one having as few attributes as possible.

Entity Integrity, Referential Integrity, and Foreign Keys Entity Integrity Constraint: Entity integrity constraint states that no primary key value can be null. Referential Integrity Constraint: it is specified between two relations and is used to maintain the consistency among tuples of two relations. Referential integrity constraint states that a tuple in one relation that refers to another relation must refer to an existing tuple in that relation. For ex, the attribute DNO of EMPLOYEE gives the department number for which each employee works; hence, its value in every EMPLOYEE tuple must match the DNUMBER value of some tuple in the DEPARTMENT relation.

ER-CSEB

3

Foreign Key: A set of attributes FK in relation schema R1 is a foreign key of R1 that references relation R2 if it satisfies following two rules 1. The attributes in FK have the same domain(s) as the primary key attributes PK of R2;the attributes FK are said to reference or refer to the relation R2 2. A value of FK in a tuple t1 of the current state r1(R1) either occurs as a value of PK for some tuple t2 in the current state r2(R2) or is null. In the former case ,we have t1[FK]=t2[PK], and we say that the tuple t1 references or refers to the tuple t2. R1 is called referencing relation and R2 is called referenced relation. The conditions for a foreign key, given above, specify a referential integrity constraint between the 2 relation schemas R1 and R2. Semantic Integrity Constraints: application-specific restrictions that are unlikely to be expressible in DDL. Examples: • •

salary of a supervisee cannot be greater than that of her/his supervisor salary of an employee cannot be lowered

Relational Databases and Relational Database Schemas A relational database schema is a set of schemas for its relations together with a set of integrity constraints. A relational database state/instance/snapshot is a set of states of its relations such that no integrity constraint is violated.

Update Operations and Dealing with Constraint Violations For each of the update operations (Insert, Delete, and Update), we consider what kinds of constraint violations may result from applying it and how we might choose to react. Insert: • • • •

domain constraint violation: some attribute value is not of correct domain entity integrity violation: key of new tuple is null key constraint violation: key of new tuple is same as existing one referential integrity violation: foreign key of new tuple refers to non-existent tuple

Ways of dealing with it: reject the attempt to insert! Or give user opportunity to try again with different attribute values.

ER-CSEB

4

Delete: •

Referential integrity violation: a tuple referring to the deleted one exists.

Three options for dealing with it: • •

Reject the deletion Attempt to cascade (or propagate) by deleting any referencing tuples (plus those that reference them, etc., etc.) • modify the foreign key attribute values in referencing tuples to null or to some valid value referencing a different tuple

Update: •

Key constraint violation: primary key is changed so as to become same as another tuple's • referential integrity violation: o foreign key is changed and new one refers to nonexistent tuple o primary key is changed and now other tuples that had referred to this one violate the constraint

ER-CSEB

5

Relational Algebra A brief introduction • Relational algebra and relational calculus are formal languages associated with the relational model. • Informally, relational algebra is a (high-level) procedural language and relational calculus a non-procedural language. • However, formally both are equivalent to one another. • A language that produces a relation that can be derived using relational calculus is relationally complete. • Relational algebra operations work on one or more relations to define another relation without changing the original relations. • Both operands and results are relations, so output from one operation can become input to another operation. • Allows expressions to be nested, just as in arithmetic. This property is called closure. • Relational algebra is the basic set of operations for the relational model • These operations enable a user to specify basic retrieval requests (or queries) • The result of an operation is a new relation, which may have been formed from one or more input relations o This property makes the algebra “closed” (all objects in relational algebra are relations) • The algebra operations thus produce new relations o These can be further manipulated using operations of the same algebra • A sequence of relational algebra operations forms a relational algebra expression o The result of a relational algebra expression is also a relation that represents the result of a database query (or retrieval request)

ER-CSEB

6

Relational Algebra consists of several groups of operations Unary Relational Operations • SELECT (symbol: σ (sigma)) • PROJECT (symbol: π (pi)) • RENAME (symbol: ρ (rho)) Relational Algebra Operations from Set Theory • UNION ( ∪ ) • INTERSECTION ( ∩ ) • DIFFERENCE (or MINUS, – ) • CARTESIAN PRODUCT ( x ) Binary Relational Operations • JOIN (several variations of JOIN exist) • DIVISION Additional Relational Operations • OUTER JOINS, OUTER UNION • AGGREGATE FUNCTIONS

Relational Algebra Operations: Unary Relational Operations: SELECT • The SELECT operation (denoted by σ (sigma)) is used to select a subset of the tuples from a relation based on a selection condition. o The selection condition acts as a filter o Keeps only those tuples that satisfy the qualifying condition o Tuples satisfying the condition are selected whereas the other tuples are discarded (filtered out) • Examples: Select the EMPLOYEE tuples whose department number is 4: σ DNO = 4 (EMPLOYEE) Select the employee tuples whose salary is greater than $30,000: σ SALARY > 30000 (EMPLOYEE) In general, the select operation is denoted by σ (R) where § the symbol σ (sigma) is used to denote the select operator § the selection condition is a Boolean (conditional) expression specified on the attributes of relation R § tuples that make the condition true are selected (appear in the result of the operation) § tuples that make the condition false are filtered out (discarded from the result of the operation)

ER-CSEB

7

SELECT Operation Properties o o

The SELECT operation σ (R) produces a relation S that has the same schema (same attributes) as R SELECT is commutative:

σ (σ(R)) = σ (σ (R)) o

Because of commutative property, a cascade (sequence) of SELECT operations may be applied in any order:

σ (σ (σ(R)) = σ (σ (σ(R))) o

A cascade of SELECT operations may be replaced by a single selection with a conjunction of all the conditions:

σ(σ(σ(R)) = σANDAND(R))) o

The number of tuples in the result of a SELECT is less than (or equal to) the number of tuples in the input relation R

Unary Relational Operations: PROJECT o PROJECT Operation is denoted by π (pi) o This operation keeps certain columns (attributes) from a relation and discards the other columns. o PROJECT creates a vertical partitioning § The list of specified columns (attributes) is kept in each tuple § The other attributes in each tuple are discarded o Example: To list each employee’s first and last name and salary, the following is used:

πLNAME, FNAME, SALARY (EMPLOYEE)

o The general form of the project operation is:

π(R)

o π (pi) is the symbol used to represent the project operation o is the desired list of attributes from relation R. o The project operation removes any duplicate tuples

ER-CSEB

8

PROJECT Operation Properties o The number of tuples in the result of projection π(R) is always less or equal to the number of tuples in R § If the list of attributes includes a key of R, then the number of tuples in the result of PROJECT is equal to the number of tuples in R o PROJECT is not commutative

π (π (R) ) = π (R) as long as contains the attributes in Unary Relational Operations: RENAME

o The RENAME operator is denoted by ρ (rho) o In some cases, we may want to rename the attributes of a relation or the relation name or both o Useful when a query requires multiple operations o Necessary in some cases (see JOIN operation later) o The general RENAME operation ρ can be expressed by any of the following forms: o

ρ S (B1, B2, …, Bn ) (R) changes both:

§ the relation name to S, and § the column (attribute) names to B1, B2, …..Bn

o

ρ S (R) changes:

§ the relation name only to S

o

ρ (B1, B2, …, Bn ) (R) changes:

§ the column (attribute) names only to B1, B2, …..Bn o For convenience, we also use a shorthand for renaming attributes in an intermediate relation: o If we write: § RESULT ← π FNAME, LNAME, SALARY (DEP5_EMPS) § RESULT will have the same attribute names as DEP5_EMPS (same attributes as EMPLOYEE) o If we write: RESULT (F, M, L, S, B, A, SX, SAL, SU, DNO) ←

ρ RESULT (F.M.L.S.B,A,SX,SAL,SU, DNO)(DEP5_EMPS)

The 10 attributes of DEP5_EMPS are renamed to F, M, L, S, B, A, SX, SAL, SU, DNO, respectively

ER-CSEB

9

Relational Algebra Operations from Set Theory UNION Operation o Binary operation, denoted by ∪ o The result of R ∪ S, is a relation that includes all tuples that are either in R or in S or in both R and S o Duplicate tuples are eliminated o The two operand relations R and S must be “type compatible” (or UNION compatible) § R and S must have same number of attributes § Each pair of corresponding attributes must be type compatible (have same or compatible domains Example: To retrieve the social security numbers of all employees who either work in department 5 (RESULT1 below) or directly supervise an employee who works in department 5 (RESULT2 below) We can use the UNION operation as follows:

DEP5_EMPS ← σDNO=5 (EMPLOYEE) RESULT1 ← π SSN (DEP5_EMPS) RESULT2(SSN) ← π SUPERSSN (DEP5_EMPS) RESULT ← RESULT1 ∪ RESULT2 The union operation produces the tuples that are in either RESULT1 or RESULT2 or both o Type Compatibility of operands is required for the binary set operation UNION ∪ , (also for INTERSECTION ∩ , and SET DIFFERENCE –) o R1(A1, A2, ..., An) and R2(B1, B2, ..., Bn) are type compatible if: o they have the same number of attributes, and o the domains of corresponding attributes are type compatible (i.e. dom(Ai)=dom(Bi) for i=1, 2, ..., n). o The resulting relation for R1∪ R2 (also for R1∩ R2, or R1–R2, see next slides) has the same attribute names as the first operand relation R1 (by convention)

ER-CSEB

10

INTERSECTION Operation o INTERSECTION is denoted by ∩ o The result of the operation R ∩ S, is a relation that includes all tuples that are in both R and S o The attribute names in the result will be the same as the attribute names in R o The two operand relations R and S must be “type compatible” DIFFERENCE Operation o o o o

SET DIFFERENCE (also called MINUS or EXCEPT) is denoted by – The result of R – S, is a relation that includes all tuples that are in R but not in S The attribute names in the result will be the same as the attribute names in R The two operand relations R and S must be “type compatible”

Some properties of UNION, INTERSECT, and DIFFERENCE o Notice that both union and intersection are commutative operations; that is o R ∪ S = S ∪ R, and R ∩ S = S ∩ R o Both union and intersection can be treated as n-ary operations applicable to any number of relations as both are associative operations; that is o R ∪ (S ∪ T) = (R ∪ S) ∪ T o (R ∩ S) ∩ T = R ∩ (S ∩ T) o The minus operation is not commutative; that is, in general o R–S S–R CARTESIAN PRODUCT Operation o This operation is used to combine tuples from two relations in a combinatorial fashion. o Denoted by R(A1, A2, . . ., An) X S(B1, B2, . . ., Bm) o Result is a relation Q with degree n + m attributes: Q(A1, A2, . . ., An, B1, B2, . . ., Bm), in that order. o The resulting relation state has one tuple for each combination of tuples—one from R and one from S. o Hence, if R has nR tuples (denoted as |R| = nR ), and S has nS tuples, then R x S will have nR * nS tuples. o The two operands do NOT have to be "type compatible o Generally, CROSS PRODUCT is not a meaningful operation o Can become meaningful when followed by other operations

ER-CSEB

11

Example (not meaningful): FEMALE_EMPS ← σ SEX=’F’(EMPLOYEE) EMPNAMES ← π FNAME, LNAME, SSN (FEMALE_EMPS)

EMP_DEPENDENTS ← EMPNAMES X DEPENDENT EMP_DEPENDENTS will contain every combination of EMPNAMES and DEPENDENT whether or not they are actually related o To keep only combinations where the DEPENDENT is related to the EMPLOYEE, we add a SELECT operation as follows Example (meaningful): FEMALE_EMPS ←

σ SEX=’F’(EMPLOYEE)

π FNAME, LNAME, SSN (FEMALE_EMPS) EMP_DEPENDENTS ← EMPNAMES X DEPENDENT ACTUAL_DEPS ← σ SSN=ESSN (EMP_DEPENDENTS) RESULT ← π FNAME, LNAME, DEPENDENT_NAME (ACTUAL_DEPS) EMPNAMES ←

RESULT will now contain the name of female employees and their dependents JOIN Operation o The sequence of CARTESIAN PRODECT followed by SELECT is used quite commonly to identify and select related tuples from two relations o A special operation, called JOIN combines this sequence into a single operation o This operation is very important for any relational database with more than a single relation, because it allows us combine related tuples from various relations o The general form of a join operation on two relations R(A1, A2, . . ., An) and S(B1, B2, . . ., Bm) is:

R

S

where R and S can be any relations that result from general relational algebra expressions. Example: Suppose that we want to retrieve the name of the manager of each department. o To get the manager’s name, we need to combine each DEPARTMENT tuple with the EMPLOYEE tuple whose SSN value matches the MGRSSN value in the department tuple. o We do this by using the join operation. DEPT_MGR ← DEPARTMENT

ER-CSEB

MGRSSN=SSN

12

EMPLOYEE

o MGRSSN=SSN is the join condition o Combines each department record with the employee who manages the department o The join condition can also be specified as DEPARTMENT.MGRSSN= EMPLOYEE.SSN Consider the following JOIN operation: R(A1, A2, . . ., An)

R.Ai=S.Bj S(B1, B2, . . ., Bm)

o Result is a relation Q with degree n + m attributes: o Q(A1, A2, . . ., An, B1, B2, . . ., Bm), in that order. o The resulting relation state has one tuple for each combination of tuples— r from R and s from S, but only if they satisfy the join condition r[Ai]=s[Bj] o Hence, if R has nR tuples, and S has nS tuples, then the join result will generally have less than nR * nS tuples. o Only related tuples (based on the join condition) will appear Some properties of JOIN o The general case of JOIN operation is called a Theta-join: o The join condition is called theta o Theta can be any general Boolean expression on the attributes of R and S; for example: R.Ai50000 (SELECTION σ SALARY >50000) will be retrieved.

The Existential and Universal Quantifiers o Two special symbols called quantifiers can appear in formulas; these are the universal quantifier )∀ ( and the existential quantifier ).∃( o Informally, a tuple variable t is bound if it is quantified, meaning that it appears in an ∀ ( t) or ∃( t) clause; otherwise, it is free. o If F is a formula, then so are ∃( t)(F) and ∀ ( t)(F), where t is a tuple variable. o The formula ∃( t)(F) is true if the formula F evaluates to true for some (at least one) tuple assigned to free occurrences of t in F; otherwise ∃( t)(F) is false. o The formula ∀ ( t)(F) is true if the formula F evaluates to true for every tuple (in the universe) assigned to free occurrences of t in F; otherwise ∀ ( t)(F) is false. o ∀ is called the universal or “for all” quantifier because every tuple in “the universe of” tuples must make F true to make the quantified formula true. o ∃ is called the existential or “there exists” quantifier because any tuple that exists in “the universe of” tuples may make F true to make the quantified formula true. Examples o Find the names of employees who work on all the projects controlled by department number 5. The query can be: o {e.LNAME, e.FNAME | EMPLOYEE(e) and ∀ ( ( x)(not(PROJECT(x)) or not(x.DNUM=5) OR ∃( ( w)(WORKS_ON(w) and w.ESSN=e.SSN and x.PNUMBER=w.PNO))))} o Exclude from the universal quantification all tuples that we are not interested in by making the condition true for all such tuples. o The first tuples to exclude (by making them evaluate automatically to true) are those that are not in the relation R of interest. o In query above, using the expression not(PROJECT(x)) inside the universally quantified formula evaluates to true all tuples x that are not in the PROJECT

ER-CSEB

21

relation. Then we exclude the tuples we are not interested in from R itself. The expression not(x.DNUM=5) evaluates to true all tuples x that are in the project relation but are not controlled by department 5. o Finally, we specify a condition that must hold on all the remaining tuples in R. ∃( ( w)(WORKS_ON(w) and w.ESSN=e.SSN and x.PNUMBER=w.PNO)

The Domain Relational Calculus The domain-oriented calculus differs from the tuple-oriented relational calculus in that it has domain variables instead of tuple variables. That is variables that range over domains instead of over relations. o An expression of the domain calculus is of the form { x1, x2, . . ., xn | COND(x1, x2, . . ., xn, xn+1, xn+2, . . ., xn+m)} o where x1, x2, . . ., xn, xn+1, xn+2, . . ., xn+m are domain variables that range over domains (of attributes) o and COND is a condition or formula of the domain relational calculus.

Examples o Retrieve the birthdate and address of the employee whose name is ‘John B. Smith’. o Query : {uv | (∃ q) (∃ r) (∃ s) (∃ t) (∃ w) (∃ x) (∃ y) (∃ z) (EMPLOYEE(qrstuvwxyz) and q=’John’ and r=’B’ and s=’Smith’)} o Abbreviated notation EMPLOYEE(qrstuvwxyz) uses the variables without the separating commas: EMPLOYEE(q,r,s,t,u,v,w,x,y,z) o Ten variables for the employee relation are needed, one to range over the domain of each attribute in order. Of the ten variables q, r, s, . . ., z, only u and v are free. o Specify the requested attributes, BDATE and ADDRESS, by the free domain variables u for BDATE and v for ADDRESS. o Specify the condition for selecting a tuple following the bar ( | )—namely, that the sequence of values assigned to the variables qrstuvwxyz be a tuple of the employee relation and that the values for q (FNAME), r (MINIT), and s (LNAME) be ‘John’, ‘B’, and ‘Smith’, respectively.

ER-CSEB

22

ER-to-Relational Mapping Algorithm Step 1: Mapping of Regular Entity Types Step 2: Mapping of Weak Entity Types Step 3: Mapping of Binary 1:1 Relation Types Step 4: Mapping of Binary 1:N Relationship Types. Step 5: Mapping of Binary M:N Relationship Types. Step 6: Mapping of Multivalued attributes. Step 7: Mapping of N-ary Relationship Types Step 1: Mapping of Regular Entity Types. – For each regular (strong) entity type E in the ER schema, create a relation R that includes all the simple attributes of E. – Choose one of the key attributes of E as the primary key for R. If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R. Example: We create the relations EMPLOYEE, DEPARTMENT, and PROJECT in the relational schema corresponding to the regular entities in the ER diagram. SSN, DNUMBER, and PNUMBER are the primary keys for the relations EMPLOYEE, DEPARTMENT, and PROJECT as shown. Step 2: Mapping of Weak Entity Types – For each weak entity type W in the ER schema with owner entity type E, create a relation R and include all simple attributes (or simple components of composite attributes) of W as attributes of R. – In addition, include as foreign key attributes of R the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s). – The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any. Example: Create the relation DEPENDENT in this step to correspond to the weak entity type DEPENDENT. Include the primary key SSN of the EMPLOYEE relation as a foreign key attribute of DEPENDENT (renamed to ESSN). The primary key of the DEPENDENT relation is the combination {ESSN, DEPENDENT_NAME} because DEPENDENT_NAME is the partial key of DEPENDENT.

ER-CSEB

23

ER-CSEB

24

Step 3: Mapping of Binary 1:1 Relation Types For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R. There are three possible approaches: (1) Foreign Key approach: Choose one of the relations-S, say-and include a foreign key in S the primary key of T. It is better to choose an entity type with total participation in R in the role of S. Example: 1:1 relation MANAGES is mapped by choosing the participating entity type DEPARTMENT to serve in the role of S, because its participation in the MANAGES relationship type is total. (2) Merged relation option: An alternate mapping of a 1:1 relationship type is possible by merging the two entity types and the relationship into a single relation. This may be appropriate when both participations are total. (3) Cross-reference or relationship relation option: The third alternative is to set up a third relation R for the purpose of cross-referencing the primary keys of the two relations S and T representing the entity types.

ER-CSEB

25

Step 4: Mapping of Binary 1:N Relationship Types. – For each regular binary 1:N relationship type R, identify the relation S that represent the participating entity type at the N-side of the relationship type. – Include as foreign key in S the primary key of the relation T that represents the other entity type participating in R. – Include any simple attributes of the 1:N relation type as attributes of S. Example: 1:N relationship types WORKS_FOR, CONTROLS, and SUPERVISION in the figure. For WORKS_FOR we include the primary key DNUMBER of the DEPARTMENT relation as foreign key in the EMPLOYEE relation and call it DNO. Step 5: Mapping of Binary M:N Relationship Types. – For each regular binary M:N relationship type R, create a new relation S to represent R. – Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S. – Also include any simple attributes of the M:N relationship type (or simple components of composite attributes) as attributes of S. Example: The M:N relationship type WORKS_ON from the ER diagram is mapped by creating a relation WORKS_ON in the relational database schema. The primary keys of the PROJECT and EMPLOYEE relations are included as foreign keys in WORKS_ON and renamed PNO and ESSN, respectively. Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation type. The primary key of the WORKS_ON relation is the combination of the foreign key attributes {ESSN, PNO}. Step 6: Mapping of Multivalued attributes. – For each multivalued attribute A, create a new relation R. This relation R will include an attribute corresponding to A, plus the primary key attribute K-as a foreign key in R-of the relation that represents the entity type of relationship type that has A as an attribute. – The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its simple components. Example: The relation DEPT_LOCATIONS is created. The attribute DLOCATION represents the multivalued attribute LOCATIONS of DEPARTMENT, while DNUMBER-as foreign key-represents the primary key of the DEPARTMENT relation. The primary key of R is the combination of {DNUMBER, DLOCATION}.

ER-CSEB

26

Step 7: Mapping of N-ary Relationship Types. – For each n-ary relationship type R, where n>2, create a new relationship S to represent R. – Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. – Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S. Example: The relationship type SUPPY in the ER below. This can be mapped to the relation SUPPLY shown in the relational schema, whose primary key is the combination of the three foreign keys {SNAME, PARTNO, PROJNAME}

ER-CSEB

27

SUMMARY -: Correspondence between ER and Relational Models ER Model Entity type 1:1 or 1:N relationship type M:N relationship type n-ary relationship type Simple attribute Composite attribute Multivalued attribute Value set Key attribute

ER-CSEB

Relational Model “Entity” relation Foreign key (or “relationship” relation) “Relationship”relation and two foreign keys “Relationship” relation and n foreign keys Attribute Set of simple component attributes Relation and foreign key Domain Primary (or secondary) key

28