SECTION 2

LESSON 1

Introduction to Relational Database Concepts

Objectives
This lesson covers the following objectives:
• Define a primary key
• Define a foreign key
• Define a column-integrity rule
 Identify row, column, primary key, unique key, and foreign key elements given a diagram of a table
containing these elements
• Identify violations of data-integrity rules

Purpose
The conceptual data model will be transformed into a relational database design. This means that
our entities, attributes, relationships, and unique identifiers will be translated into objects in a
relational database.
Compare this to a clothing designer who is taking his design from paper and implementing it with
fabric. The designer needs to understand how to sew the designs just like you will need to
understand the structure of relational database objects.

Relational Database Illustrated

A relational database is a database that is seen by the user as a collection of two-dimensional tables,
each containing rows and columns.
The table below contains employee data.

Language to Access Data

Structured query language (SQL) allows us to access data in relational databases in an efficient way.
Instead of manually searching through each row to find the record for employee number 200, we
use the following SQL statement:

You can see the result of this statement on the next slide.
SQL Query Illustrated

Specific SQL Query

To find all the employees in department number 90, we write a different SQL statement:

Again, you can see the result on the next slide

Primary Key Candidates
A table can have more than one column, or combinations of columns, that could serve as the table’s
primary key. Each column, or combination of columns, is called a "candidate" key because it could be
selected for use as the primary key.

Choose a Candidate Key

Select one candidate key to be the primary key for the table. The other candidates become alternate
keys (or unique keys).

.
.
Summary of Data-Integrity Rules
Data-integrity rules (also known as constraints) define the relationally correct state for a database.
Data-integrity rules ensure that users can perform only those operations that leave the database in a
correct, consistent state.

Terminology
Key terms used in this lesson included:
• Candidate key
• Column
• Foreign key
• Primary key
• Relational database
• Row
• Unique key

Summary
In this lesson, you should have learned how to:
• Define a primary key
• Define a foreign key
• Define a column-integrity rule
 Identify row, column, primary key, unique key, and foreign key elements given a diagram of a table
containing these elements
• Identify violations of data-integrity rules
 SECTION 2 LESSON 2

Basic Mapping: The Transformation Process

Objectives
This lesson covers the following objectives:
• Distinguish between a conceptual model and a physical model
• Apply terminology mapping between the two models
 Understand and apply the Oracle naming conventions for tables and columns used in physical
models
• Transform an entity into a table diagram

Purpose
When you design a house, you eventually would like to see the house built. Even if you don’t do the
actual construction, you will need to understand the terms used by the builders in order to help
them take your conceptual design and make it a physical reality.
The initial database design can be used for further discussion between designers, database
administrators, and application developers.

Review of Relational Tables

A table is a simple structure in which data is organized and stored. In the example below, the
EMPLOYEES table is used to store employees’ information.

Tables have columns and rows. In the example, each row describes an occurrence of an employee.
Each column is used to store a specific type of value, such as employee number, last name, and first
name.
The employee_id column is a primary key. Every employee has a unique identification number in this
table. The value in the primary key column distinguishes each individual row.

The payroll_id is a unique key. This means that the system does not allow two rows with the same
payroll_id.

The foreign key column refers to a row in another table. In this example, the department_id refers to
a row in the DEPARTMENTS table.
We know that Dana Smith works in department 10. If we wanted to know more about Dana Smith’s
department, we would look for the row in the DEPARTMENTS table that has department_id = 10.

Transforming Conceptual To Physical

The conceptual model (ER diagram) is transformed into a physical model. The physical
implementation will be a relational database.

Terminology Mapping
Changing from analysis (conceptual model) to implementation (physical model) also means changing
terminology:
• An entity becomes a table.
• An instance becomes a row.
• An attribute becomes a column.
• A primary unique identifier becomes a primary key.
• A secondary unique identifier becomes a unique key.
• A relationship is transformed into a foreign-key column and a foreign key constraint.
Table Diagram Notations
The first row of the table diagram contains the table name and the short name. The Key Type
column should contain values of “pk” for the primary key, “uk” for the unique key, and “fk” for the
foreign-key column. It will be blank if the column is not a part of any key.
The Optionality column must contain “*” if the column is mandatory and “o” if it is optional. This is
similar to the entity diagram. The third column is for the column name.

Naming Conventions for Tables and Columns

The table name is the plural of the entity name.
Example: STUDENT becomes STUDENTS
Table Short Names
A unique short name for every table is useful in the naming of foreign-key columns. One possible
way to make these short names is based on the following rules:
For entity names of more than one word, take the:
• First character of the first word
• First character of the second word
• Last character of the last word Example: JOB ASSIGNMENT gets a short name of JAT

For entity names of one word but more than one syllable, take the:
• First character of the first syllable
• First character of the second syllable
• Last character of the last syllable
Example: EMPLOYEE gets a short name of EPE and CLIENT gets a short name of CET
For entity names of one syllable but more than one character:
• First character
• Second character
• Last character
Example: FLIGHT gets a short name of FLT

Naming Restrictions with Oracle

Table and column names:
• Must start with a letter
• Can contain up to 30 alphanumeric characters
• Cannot contain spaces or special characters such as “!,” but “$,” “#,” and “_“ are permitted.

Table names must be unique within one user account in the Oracle database.
Column names must be unique within a table.

Some words have a special meaning in the Oracle database and in the SQL programming language.
These are called “reserved” words. It is best to avoid using these as names for your tables and
columns.

Some common examples of Oracle reserved words are:

• TABLE
• NUMBER
• SEQUENCE
• ORDER
• VALUES
• LEVEL
• TYPE
A complete list can be found on otn.oracle.com.

Terminology
Key terms used in this lesson included:
• Map
• Reserved word
• Transform

Summary
In this lesson, you should have learned how to:
• Distinguish between a conceptual model and a physical model
• Apply terminology mapping between the two models
 Understand and apply the Oracle naming conventions for tables and columns used in physical
models
• Transform an entity into a table diagram
 SECTION 2 LESSON 3

Relationship Mapping

Objectives
This lesson covers the following objectives:
• Apply the rule of relationship mapping to correctly transform 1:M and barred relationships
• Apply the rule of relationship mapping to correctly transform M:M relationships
• Transform 1:1 relationships
• Apply the rule of relationship mapping to correctly transform relationships in an arc

Purpose
Suppose that you are building a house for someone. You have all of the materials – wood, paint,
doors, windows, nails, screws, etc. – and the skills, but you do not have a design.

As you start, you don’t know how many rooms should be included, where the windows should be
placed, how the doors should be oriented, or what color each room should be painted.

You could build a house in such a manner and make these decisions as you go, but if you do not start
with a blueprint of the structural design, the final product may not be the house that the customer
has in mind.

Relationships are mapped between primary keys and foreign keys to allow one table to reference
another. If we don’t map relationships, we just have a lot of standalone tables containing
information that does not connect to anything else in the database.

Mapping relationships between entities serves as a critical “first-step” to facilitate discussion

between the customer, designer, developer, and administrator of the database product.

Rules for Relationships

A relationship creates one or more foreign-key columns in the table on the many side of the
relationship.

We use the short name of the table to name the foreignkey column. In the example on the next
page, the foreignkey column in the EMPLOYEES table is dpt_id for the relationship with
DEPARTMENT, and epe_id for the recursive relationship with itself.

The foreign-key column may be either mandatory or optional, depending on the needs of the
business. In the example, dpt_id is mandatory and epe_id is optional.
Rules for Relationships Illustrated

Mapping of Mandatory Relationship at the One Side

Relationships that are mandatory on the one side, or mandatory on both sides, are mapped exactly
the same way as a relationship that is optional on the one side. The conceptual model is rich enough
to capture optionality at both ends of the relationship. However, the physical model is limited in that
a foreign-key constraint can enforce a mandatory relationship only at the many end.

In the following example, the physical model cannot enforce that a BAND must be composed of at
least one MUSICIAN. The optionality at the one end will have to be implemented through additional
programming.

Enforcing Optionality

Mapping of Nontransferable Relationships

A nontransferable relationship in the conceptual model means that the foreign-key column in the
database table cannot be updated. The foreign-key constraint by itself cannot enforce this in the
database.
Additional programming will be needed to make sure that the database follows this business rule. It
is important to document rules like this so that the team remembers to write the appropriate code
and enforce this business rule.
Enforcing Nontransferable Relationships

Mapping of Barred Relationships

A barred relationship is mapped to a foreign-key column on the many side, just like any other 1:M
relationship. In this case, the foreign-key column plays a double role because it is also part of the
primary key.

In the example, bak_number is a foreign-key column in ACCOUNTS that refers to the primary key of
BANKS. It is also part of the primary key of ACCOUNTS.

Cascade Barred Relationships

Hierarchies can lead to cascade barred relationships, where the UID of the entity at the top of the
hierarchy is carried all the way down to the UID of the entity at the bottom of the hierarchy. In the
example, the UID of ROOM is composed of the ROOM number, SUITE number, FLOOR number, and
BUILDING id. This is represented by the barred relationships.

When this is mapped to a physical model, the result can be a very long foreign-key column name
because it uses the short names of the originating tables as a prefix. The suggested convention is to
never use more than two table prefixes. In the following example, the foreign-key column in ROOMS
that comes all the way from BUILDINGS is named sue_bdg_id, instead of sue_flr_bdg_id.
Cascade Barred Relationship Illustrated

Mapping Many-to-Many Relationships

A M:M relationship is resolved with an intersection entity, which maps to an intersection table. This
intersection table will contain foreign-key columns that refer to the originating tables.
In the example, REVIEWS contains all the combinations that exist between a CRITIC and a MOVIE
Mapping One-to-One Relationships
When transforming a 1:1 relationship, you create a foreign key and a unique key. All columns of this
foreign key are also part of the unique key.
If the relationship is mandatory on one side, the foreign key is created in the corresponding table. In
the example, bcp_code is the foreign-key column in SODA_BOTTLES that refers to the primary key of
BOTTLE_CAPS. Bcp_code would also be unique within the SODA_BOTTLES table.

Optional One-to-One
If the relationship is optional on both sides, you can choose which table gets the foreign key. There
are no absolute rules, but here are some guidelines:
• Implement the foreign key in the table with fewer rows to save space.
• Implement the foreign key where it makes more sense for the business.

In the example, a car-rental agency would be more concerned about cars than spaces, so it makes
sense to put the foreign key in CARS. However, in a parking-lot business, the main object is the
parking space. Therefore, it would make sense to put the foreign key in SPACES.

Business Rules for Optional One-to-One

Enforcing One-to-Many
If the relationship is mandatory at both ends, you have the same limitation in the database as a 1:M
relationship that is mandatory at the one end. Therefore, you would need to write additional code to
enforce it.
Mapping Arcs
The entity that has the arc will map to a table that contains foreign keys from the tables on the
“one” end of the relationships.
Note that even if the relationships in the arc are mandatory on the many side, the resulting foreign
keys have to be optional (because one of them will always be blank).

Since the arc represents exclusive relationships, additional code is needed to enforce that only one
of the foreign keys has a value for every row in the table. A check constraint stored in the database
can easily do this. In the example, the code for the check constraint would look like this:

CHECK (pse_id is not null AND phe_id is null) OR (pse_id is null AND phe_id is not null)

If the relationships were fully optional, you would add: OR (pse_id is null AND phe_id is null)

The code verifies that if a value exists for the public space id (pse_id), then the column for private
home id (phe_id) must be empty. Conversely, if the public space id is NULL, then a value must exist
for the private home id. In a fully optional relationship, additional code allows both the public space
id and the private home id to be null (the event is not held at any venue).

Terminology
Key terms used in this lesson included:
• Cascade barred relationship
• Intersection entity
• Nontransferable relationship
Summary
In this lesson, you should have learned how to:
• Apply the rule of relationship mapping to correctly transform 1:M and barred relationships
• Apply the rule of relationship mapping to correctly transform M:M relationships
• Transform 1:1 relationships
• Apply the rule of relationship mapping to correctly transform relationships in an arc
 SECTION 2 LESSON 4

Subtype Mapping

Objectives
This lesson covers the following objectives:
 State and apply the table, column, identifiers, relationship, and integrity constraint rules for
mapping:
–supertype implementations
–subtype implementations
–supertype and subtype arc implementations

Purpose
A carpenter who is building your dream house may know that you will use different types of light
bulbs all around the house. However, if you do not provide information on where certain types of
light bulbs should be installed, you could end up with an overly bright bedroom and a dimly lit
kitchen!
Mapping supertypes and subtypes makes sure that the right information gets stored with each type.

Supertype Implementation: Single Table

This choice produces a single table for the implementation of the supertype entity and its subtypes.
This is also called "single-table (or one-table) implementation."
Rules:
1. Tables: Only one table is created, regardless of the number of subtypes.
2. Columns: The single table gets one column for each attribute of the supertype, along with the
original optionality of the attribute.
3. The table also gets a column for each attribute belonging to the subtype, but the columns all
become
optional.
4. Additionally, a mandatory column should be created to act as a discriminator column to
distinguish
between the different subtypes of the entity. The value it can take is from the set of all the
subtype
short names (FTE, PTE, OTR in the example). This discriminator column is usually called
<table_short_name>_type, which would be epe_type in the example.
Rules:
1. Identifiers: Unique identifiers transform into primary and unique keys.
2. Relationships: Relationships at the supertype level transform as usual. Relationships at the
subtype level are implemented as optional foreign-key columns.
3. Integrity constraints: A check constraint is needed to ensure that for each particular subtype, all
columns that come from mandatory attributes are not null.

In the conceptual model, salary is mandatory for full-time employees and hourly rate is mandatory
for part-time employees. When the EMPLOYEE supertype is implemented as a single table in the
physical model, these attributes become optional. A check constraint is needed to enforce the
business rules modeled in the ERD.

In the example, the code for the check constraint would look like this:
CHECK (epe_type = ‘FTE’ and salary is not null and hourly_rate is null and agy_id is null)
OR (epe_type = ‘PTE’ and salary is null and hourly_rate is not null and agy_id is not null)

The code checks that if it is a full-time employee (epe_type = ‘FTE’), then a value must exist in the
salary column and the hourly_rate and agy_id columns must be empty. Conversely, if it is a part-time
employee (epe_type = ‘PTE’), then a value must exist in hourly_rate and agy_id, but salary must be
left blank

When Do You Choose the Single Table/Supertype Implementation?

The single-table implementation is a common and flexible implementation. It is the one you are
likely to consider first and is especially appropriate where:
• Most of the attributes are at the supertype level.
• Most of the relationships are at the supertype level.
• Business rules are globally the same for the subtypes

Subtype Implementation: Two Table

This is also called "two-table implementation." You create a table for each of the subtypes. So, in
reality, you could have more than two tables, if you had more than two subtypes.
Rules:
1. Tables: One table per first-level subtype.
2. Columns: Each table gets one column for each attribute of the supertype along with its original
optionality.
3. Each table also gets one column for each attribute belonging to the subtype along with its original
optionality.
4. Identifiers: The primary UID at the supertype level creates a primary key for each table. Secondary
UIDs of the supertype become unique keys in each table.
5. Relationships: All tables get a foreign key for a relationship at the supertype level, with the original
optionality. For relationships at the subtype levels, the foreign key is implemented in the table it is
mapped to. Original optionality is retained.

In the example, a separate table would be created for SHIRTS and SHOES.

When to Consider Subtype Implementation

Subtype implementation may be appropriate when:
• Subtypes have very little in common. There are few attributes at the supertype level and several at
the subtype level.
• Most of the relationships are at the subtype level.
• Business rules and functionality are quite different between subtypes.
• How tables are used is different -- for example, one table is being queried while the other is being
updated.

Modeling the Supertype as an Arc

A supertype entity and its subtypes can be modeled as an arc relationship. Here again is the ERD
with the supertype and subtypes.

Model An Arc Illustrated

Supertype and Subtype (Arc) Implementation
This choice produces one table for every entity. The supertype table has a foreign key for each
subtype table. These foreign keys represent exclusive relationships. They are optional because only
one of them can have a value for each row in the table.
Rules :
1. Tables: As many tables are created as there are subtypes, as well as one for the supertype.
2. Columns: Each table gets a column for all attributes of the entity it is based on, with the original
optionality.
3. Identifiers: The primary UID of the supertype level creates a primary key for each of the tables. All
other unique identifiers become unique keys in their corresponding tables.
4. Relationships: All tables get a foreign key for a relevant relationship at the entity level, with the
original optionality.
5. Integrity constraints: Two additional columns are created in the table based on the supertype.
They
are foreign-key columns referring to the tables that implement the subtypes. The columns are
optional because the foreign keys are in an arc. An additional check constraint is needed to
implement the arc. The foreign-key columns are also unique keys because they implement a
mandatory 1:1 relationship.
When to Consider Both a Supertype and Subtype (Arc) Implementation
This implementation is rarely used, but it could be appropriate when:
• Subtypes have very little in common and each table represents information that can be used
independently. For example, when the CLOTHING table gives all global information, and both
SHOES
and SHIRTS give specific information, and the combination of global and specific information is
hardly ever needed.
• Business rules and functionality are quite different between all types.
• How tables are used is different.

Terminology
Key terms used in this lesson included:
• Arc implementations
• Subtype implementations
• Supertype implementations

Summary
In this lesson, you should have learned how to:
 State and apply the table, column, identifiers, relationship, and integrity constraint rules for
mapping:
–supertype implementations
–subtype implementations
–supertype and subtype arc implementations