UNIT V

RELATIONAL DATA MODEL

RELATIONAL DATA MODEL
 FORMAL DEFINITIONS
Domain
– set of atomic values
– use to specify a data type or format from which the data values
forming the domain are drawn

Some examples of domains:

• Names: The set of character strings that represent names of persons.

• Grade_point_averages: Possible values of computed grade point averages; each must be a
real (floating-point) number between 0 and 4.
• Student_ages: Possible ages of students in a university; each must be an integer value
between 12 and 75.
• Academic_department_names: The set of academic department names in a university, such
as Computer Science, Mathematics, and Economics.
• Academic_department_codes: The set of academic department codes, such as ‘CS’, ‘ECON’,
and ‘MATH’.
 FORMAL DEFINITIONS
Relation
– relation schema R, denoted by R(A1, A2, ...,An), is made up of a relation
name R and a list of attributes, A1, A2, ..., An.
– Relation schema is also called relation intension.
Some examples of relations:

• STUDENT(ID_no, Name, College, Course, Home_phone, Age)

• STUDENT(ID_no: string, Name: string, College: string, Course: string, Home_phone: string, Age:
integer)

– relation state r of the relation schema R(A1, A2, ..., An), also denoted by
r(R), is a set of n-tuples r={t1, t2, ..., tn}. Each n-tuple t is an ordered list
of n values t =<v1, v2, ..., vn>, where each value vi, 1 <= i <= n, is an
element of dom(Ai) or is a special NULL value. The ith value in tuple t,
which corresponds to the attribute Ai, is referred to as t[ Ai ] or t.Ai (or
t[ i ] if we use the positional notation).
– Relation state is also called relation extension.
 RELATIONAL DATA MODEL

Example:

Consider the tuple t = <‘15-2314’, ’ Peter’, ‘CEN’, ‘BSIT’, NULL, 21> from the
STUDENT relation in Figure 5-1; we have t[ID_No] = <’15-2314’>, and t[Name,
College, Age] = <‘Peter’, ‘CEN’, 21>.
RELATIONAL DATA MODEL
Informal Terms Formal Terms

Table Relation

Column Attribute/Domain

Row Tuple

Values in a column Domain

Table Definition Schema of a Relation/Intension

Populated Table State of a Relation/Extension

 CHARACTERISTIC OF RELATIONS
 Ordering of tuples in a relation r(R)
-tuples have no particular order

 Ordering of attributes in a relation schema R (and of values

within each tuple)
-The order of attributes and their values is not that important as long
as the correspondence between attributes and values is maintained.

 Values in tuple
-Each value in a tuple is considered atomic.
-Null Values-unknown/not applicable
 RELATIONAL DATABASE SCHEMA

Figure taken from: Elmasri,

Navathe (2011).
Fundamentals of Database
Systems .

Relational schema for the COMPANY database

 RELATIONAL DATABASE SCHEMA
Attributes that represent the same real-world concept may or may not have
identical names in different relations.
 The ‘Dnumber’ attribute in both DEPARTMENT and DEPT_LOCATIONS stands for the same real-
world concept—the number given to a department. That same concept is called ‘Dno’ in
EMPLOYEE and ‘Dnum’ in PROJECT.

Attributes that represent different concepts may have the same name in different
relations.
 The attribute name ‘Name’ for both ‘Pname’ of PROJECT and ‘Dname’ of DEPARTMENT would
have been used – in this case, we would have two attributes that share the same name but
represent different real world concepts—project names and department names.

Identical attribute names that pertains to the same real-world concept but is used
in different roles (meanings) in the same relation must be given distinct attribute
names.
 The concept of Social Security number appears twice in the EMPLOYEE relation once in the role of
the employee’s SSN, and once in the role of the supervisor’s SSN. The attribute names ‘Ssn’ and
‘Super_ssn’ were used respectively because they appear in the same relation and in order to
distinguish their meaning.
 RELATIONAL MODEL CONSTRAINTS
• Constraints are conditions that must hold on all valid relation states. These
can also be seen as restrictions on the actual values in a database state
and are usually derived from the rules in the miniworld that the database
represents.

Domain Constraint
Domain constraints specify that within each tuple, the value of each attribute
A must be an atomic value from the domain dom(A). This constraint ensures
that every value of a tuple must be from the domain of its attribute (or it
could be NULL, if allowed for that attribute).

Key Constraint
All tuples in a relation must be distinct such that no two tuples can have the
same combination of values for all their attributes. The value of a key
attribute can be used to identify uniquely each tuple in the relation.
A relation schema may have more than one key. In this case, each of the keys is called a
candidate key. The other candidate keys not chosen to be the primary key are designated
as unique keys or alternate keys, and are not underlined.
 RELATIONAL MODEL CONSTRAINTS
CONSTRAINT ON NULL VALUES
This constraint on attributes specifies whether NULL values are or are not permitted.
For example, if every STUDENT tuple must have a valid, non-NULL value for the ‘Name’
attribute, then ‘Name’ of STUDENT is constrained to be NOT NULL.

ENTITY INTEGRITY CONSTRAINT

This constraint states that no primary key value can be NULL. This is because the
primary key value is used to identify individual tuples in a relation and having NULL
values for the primary key implies that some tuples can not be identified.
 RELATIONAL MODEL CONSTRAINTS
REFERENTIAL INTEGRITY CONSTRAINT
This constraint states that a tuple in one relation that refers to another relation must
refer to an existing tuple in that relation. While key constraint and entity integrity
constraint can be specified on a single relation, referential integrity constraint is
specified between two relations and is used to maintain the consistency among tuples
in the two relations.
The two relations involved are called the referencing relation R1 and the referenced
relation R2. Tuples in the referencing relation R1 have attributes FK (called foreign key
attributes) that reference the primary key attributes PK of the referenced relation R2.
RELATIONAL MODEL CONSTRAINTS
 RELATIONAL MODEL CONSTRAINTS
A foreign key can refer to its own relation.

The attribute ‘Super_ssn’ in EMPLOYEE refers to the supervisor of an employee; this is

another employee, represented by a tuple in the EMPLOYEE relation. Hence,
‘Super_ssn’ is a foreign key that references the EMPLOYEE relation itself.

Referential integrity constraints can be diagrammatically shown by drawing a

directed arc from each foreign key to the relation it references. For clarity, the
arrowhead points to the primary key of the referenced relation.
RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL
 RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL

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.
• For composite attributes, include only the simple component attributes. Choose one
of the key attributes of E to be the primary key for R.
• If the chosen key of E is a composite, then the set of simple attributes that form it
will together form the primary key of R.
 RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL
Step 2. Mapping Weak Entitles
• 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..
• Include as foreign key attributes of R, the primary key attribute(s) of the relation(s)
that correspond to the owner entity type(s). This takes care of mapping the
identifying relationship type of W.
• 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.
• If there is a weak entity type E2 whose owner is also a weak entity type E1, then E1
should be mapped before E2 to determine its primary key first.
 RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL
Step 3. Mapping of binary 1:1 relationship types.

FOREIGN KEY APPROACH

• Choose one of the relations — say S — and include as a foreign key in S the primary
key of T. It is better to choose (as S) an entity type with total participation in R.
• Include all the simple attributes (or simple components of composite attributes) of
the 1:1 relationship type R as attributes of S.

MERGED RELATION APPROACH

• An alternative mapping of a 1:1 relationship type is to merge the two entity types
and the relationship into a single relation. This is possible when both participations
are total, as this would indicate that the two tables will have the exact same number
of tuples at all times.
 RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL
Step 4. Mapping of binary 1:N relationship types.

• For each regular binary 1:N relationship type R, identify the relation S that
represents 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 (or simple components of composite attributes) of the
1:N relationship type as attributes of S.
 RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL
Step 5. Mapping of binary M:N relationship types.

• For each binary M:N relationship type R, create a new relation (a relationship
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.
• Include any simple attributes of the M:N relationship type (or simple components of
composite attributes) as attributes of S.
 RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL
Step 6: Mapping of multi-valued attributes.

• For each multi-valued attribute A, create a new relation R.

• This relation R created 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
or relationship type that has A as a multi-valued attribute.
• The primary key of R is the combination of A and K.
• If the multi-valued attribute is composite, we include its simple components.
 RULES OF TRANSFORMING ER MODEL
INTO RELATIONAL DATABASE MODEL
Step 7. Mapping of n-ary relationship types.

• For each n-ary relationship type R, where n > 2, 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.
• Include any simple attributes of the n-ary relationship type (or simple components
of composite attributes) as attributes of S.
• The primary key of S is usually a combination of all the foreign keys that reference
the relations representing the participating entity types.
• If the cardinality constraints on any of the entity types E participating in R is 1, then
the primary key of S should not include the foreign key attribute that references the
relation E’ corresponding to E.
 SUMMARY OF RELATION
ERMODEL RELATIONAL MODEL
Entity type Entity relation
1:1 or 1:N relationship type Foreign key (or relationship
relation)
M:N relationship type Relationship relation and two
foreign keys
n-ary relationship type Relationship relation and n
foreign keys
Simple attribute Attribute
Composite attribute Set of simple component
attributes
Multivalued attribute Relation and foreign key
Value set Domain
Key attribute Primary (or secondary) key
 TRANSFORMING EER TO RELATIONAL

Step 8. Mapping of specialization/generalization.

– OPTION A. Multiple relations – Superclass and Subclasses.
 TRANSFORMING EER TO RELATIONAL
OPTION B. Multiple relations –Subclass relations only.
– This option only works for a specialization whose subclasses are total
(every entity in the superclass must belong to (at least) one of the
subclasses). Additionally, it is only recommended if the specialization has
the disjointedness constraint.
 TRANSFORMING EER TO RELATIONAL
OPTION C. Single relation with one type attribute.
-union of all attribute of superclass and subclass
-works only in disjoint
-can generate many NULL values
 TRANSFORMING EER TO RELATIONAL
OPTION D. Single relation with multiple type attributes.
-This option is used for a specialization whose subclasses are
overlapping.
 TRANSFORMING EER TO RELATIONAL
Step 9. Mapping of multi-level specialization/generalization hierarchy (lattice)
and shared subclasses.
• Option 8A is used for PERSON/{EMPLOYEE, ALUMNUS, STUDENT}.
• Option 8C is used for EMPLOYEE/{STAFF, FACULTY, STUDENT_ASSISTANT} by
including the type attribute Employee_type.
• Option 8D for STUDENT_ASSISTANT/{RESEARCH_ASSISTANT, TEACHING_
ASSISTANT} by including the type attributes Ta_flag and Ra_flag in EMPLOYEE.
• Option 8D for STUDENT/ STUDENT_ASSISTANT by including the type attributes
Student_assist_flag in STUDENT.
• Option 8D for STUDENT/{GRADUATE_STUDENT, UNDERGRADUATE_STUDENT}
by including the type attributes Grad_flag and Undergrad_flag in STUDENT.
TRANSFORMING EER TO RELATIONAL
TRANSFORMING EER TO RELATIONAL
 TRANSFORMING EER TO RELATIONAL
• Step 10. Mapping of union types (categories).
– Surrogate Key-superclasses have different keys, specify a new key
attribute