Practice Activity for DD 9.1 – 9.

4
Gery J. Sumual (01123574291-53)

9.1 Introduction to Relational Database Concepts

Vocabulary: primary key, foreign key, row, column, Unique key, relational database, candidate
key.
Try It / Solve It:
1. Column integrity, data-integrity rules, entity integrity, referential integrity, user-defined
integrity
2. a. The table CLIENTS violates entity integrity rule because one of its listed rows have a
missing primary key;
b. The date and cost columns in EVENTS table violate the column integrity rule because the
row with the date and cost value of “Day before wedding” and “2gs” isn’t in a date and
number format respectively;
c. The foreign keys client_id and theme_code in EVENTS table both violate the referential
integrity rule as seen from one of each of their row entries that is “77” and “BB” doesn’t
refer to any primary key in the table CLIENTS and THEMES that they related with
respectively.
9.2 Basic Mapping: The Transformation Process
Vocabulary: Transform, map
Try It / Solve It:
1.
STUDENTS (SDT) TEACHER (TCR)
Key Column Key
Optionality Optionality Column name
Type name Type
pk * Id
pk * Id
* first_name
* first_name
* last_name
* last_name
uk * social_sec_num
* home_addr uk * phone_num
uk o phone_num uk o email_addr

BANK ACCOUNTS (BAT) Analysis Design

Key Entity Table
Optionality Column name
Type Attribute Column
pk * bank id
Instance Row
pk * account id Primary UID Primary key
* cust_name Secondary UID Unique key
* cust_balance Relationship Foreign key

* cust_hme_addr ER Model Physical design

 2. “pk”: primary key, “fk”: foreign key, “uk”: unique key, “*”: mandatory, “o”: optional.
3. Academic major: AMR, Undergraduate: UAE, Class: CLS
4. “1997classes”: it starts with numeric character; “Schedule_of_classes_spring_2003”: it
contains more than 30 alphanumeric characters; “Financial Aid deadlines!”: It contains
special character ‘!’.

9.3 Relationship Mapping

Vocabulary: nontransferable relationship, cascade barred relationship, intersection table
Try It / Solve It:
1.

FOOD ITEM
Key Column
Optionality
Type name
pk * number
* description
* price
fk1 o rmu_code
fk2 o pmu_code

• To enforce mutually exclusive-OR relationship to regular and promotional menu, a check

constraint must be implemented in database, that is, check if (rmu_code is not null and
pmu_code is null) or (rmu_code is null and pmu_code is not null).

ORDER
Key Column
Optionality
Type name
pk * number
* date
* time
fk1 * stf_id
fk2 o fdcd_id

• The relationship with STAFFS is nontransferable, therefore it needs to implemented in the

databse that the foreign key stf_id cannot be updated once it’s already specified.

ORDER LINE
Key Column
Optionality
Type name
pk,fk * fim_num
pk,fk * odr_num
* quantity
9.4 Subtype Mapping
Try It / Solve It:
1.

PARTNERS (PNR)
Key
Optionality Column name
type
pk * id
* first_name
* last_name
o expertise
o specialty
o authorized_expense_limit
* pnr_type
fk o pnr_id

2.

ORDER TAKERS (OTR) COOKS (COK)

Column Column
Key type Optionality Key type Optionality
name name
pk * stf_id pk * stf_id
* first_name * first_name
* last_name * last_name
* birth_date * birth_date
* salary * salary
* overtime rate * training
fk o stf_id fk o stf_id

MANAGERS (MGR)
Key type Optionality Column name
pk * stf_id
* first_name
* last_name
* birth_date
* salary
* budget
target
*
revenue
fk o stf_id
3.
• Supertype implementations
o Table: Each supertype along with its subtypes will get a single table
o Column: for each attribute belongs to the supertype and its subtypes a
corresponding column will be added to the table.
o Identifiers: The primary UID, unique UIDs, and the rest of the attributes of the
supertype will retain their optionality in the table as keys and non-keys, but those
from the subtypes will have their optionality turned into optional if they aren’t
already.
o Relationship: The relationships from the supertype level will keep their optionality in
whichever table that they mapped to, as for the relationships from the subtypes, if
they’re mapped to the single table, will be treated as optional.
o Integrity constraint rules: There will be a discriminator column with not null
constraint that discriminates between subtypes for each row of the table, and a
check constraint that will be used as to ensure the original optionality of the
attributes and relationships of each subtypes using the pivotal role of the
discriminator column.
• Subtype implementations
o Table: each subtype will get a single table while their supertype won’t.
o Column: for each attribute belongs to the supertype a column will be added to every
table, and for each attribute belongs to the subtypes a column will be added only to
each corresponding subtype table.
o Identifiers: the primary and unique UIDs along with the attributes belongs the
supertype will be added to every table as keys and non-keys while retaining their
optionality. As for the unique UIDs and the attributes belongs to the subtypes will be
added only to their corresponding table as keys and non-keys with their optionality
unchanged.
o Relationship: each relationship from the supertype if they’re mapped to the
supertype then it will be mapped to every subtype table as foreign key retaining
their optionality. Each relationship from each subtype if they’re mapped to the
subtype then it will be mapped only to the corresponding subtype table as foreign
key with their optionality unmodified.
o Integrity constraint rules: if the primary keys of the subtype tables need to be
guaranteed as unique, then additional programming needs to be implemented to
the database.
• Arc implementations
o Table: for each supertype and subtype, a table will be created.
o Column: only the attributes that belong to the supertype level will be added as
columns to the supertype-based table, and only the attributes that belong to each
subtype, in addition of the primary UID of the supertype, that will be added as
columns to their corresponding table.
o Identifiers: the primary identifier of the supertype will be added to every table as
primary key, and the unique identifiers of the entity that each table is based on will
be added as unique keys.
o Relationship: the relevant relationships from the entity that a table is based on will
be added to the table as foreign keys with original optionality, and the supertype-
based table will have additional foreign keys that is optional and also unique that
refer to the table implementation of its subtypes.
o Integrity constraint rules: the additional foreign keys of the supertype-based table
are implemented as an arc relationship, so an arc check constraint is needed for
them.