BASIS DATA Pertemuan 07

Wildan Budiawan Zulfikar

Outcome Pertemuan:
Mahasiswa mampu mengidentifikasi berbagai
kebutuhan dalam bingkat Basis Data
Relasional dalam kasus kompleks

2
Database Design
8-1
Modeling Historical Data

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Objectives
• This lesson covers the following objectives:
• Identify the need to track data that changes over time
• Construct ERD models that incorporate elements of
“data over time”
• Identify the UID of an entity that stores historical data;
explain and justify the choice of UID
4
Purpose
• How tall were you at age 5? How tall were you at
age 10? How tall are you right now?
• If your parents wrote this down when you were young,
they were keeping track of historical data.
• Most businesses need to track some historical data.
• This helps them find trends and patterns that are the
basis for business innovations or process
5

improvements.
• For example, rental history of a movie is useful to a
video store. It tells managers which movies are
popular and which should be moved to the back shelf.
Model Data Over Time
• When is it necessary to model data over time?
• Ask your client:
– Is an audit trail required?
– Can attribute values change over time?
– Can relationships change over time?
– Do you need to produce reports on older data?
– Do you need to keep previous versions of the data? If so,
for how long? 6
Data Over Time Example
• An organization needs to keep data
about employees’ salaries. EMPLOYEE
# id
• All employees are paid weekly. * first name
* last name
* weekly salary amount
• Initially, the following EMPLOYEE entity * salary start date
was modeled.
• Additional requirements now specify
that the organization needs to keep 7

a historical record of how and when

employees’ salaries have changed
during their employment.
Model Salary Changes
• To model salary changes over time, add a SALARY
HISTORY entity.

SALARY HISTORY EMPLOYEE

# salary start date for # id
o salary end date * first name
* weekly salary having * last name
amount

• The UID of the SALARY HISTORY entity is the related 8

EMPLOYEE id and the salary start date.

Model Rental Over Time
• A jewelry store rents pieces (necklaces, bracelets and so
on) to movie stars for special occasions, such as award
ceremonies or movie premieres.
• They would like to track the rental history of a jewelry
piece.
• The following ER model will only track the
current renter of a piece of jewelry.
• How would you revise
PIECE the relationship to track history?
9
JEWELRY MOVIE STAR
# code rented by # id
* description * first name
renting * last name
* rental rate
* insured value
Resolve M:M
JEWELRY PIECE MOVIE STAR
rented by # id
# code
• The relationship between * description * first name
* rental rate renting * last name
JEWELRY PIECE and * insured value
MOVIE STAR should be The M:M relationship is resolved with
revised to a M:M, which an intersection entity.

is then resolved with an RENTAL HISTORY for MOVIE STAR

* rental date # id
intersection entity * date returned on * first name
* last name
RENTAL HISTORY. for
on
10
• Next we need to JEWELRY PIECE
# code
determine the UID of * description
* rental rate
RENTAL HISTORY. * insured value
Determine UID
• Option 1: Barred
relationship. RENTAL HISTORY for
* rental date
MOVIE STAR
# id
* date returned on * first name
• Drawing a Barred * last name
for
relationship is not a
suitable UID here, as this on
JEWELRY PIECE
would not allow a # code
* description
MOVIE STAR to rent the * rental rate
* insured value
same JEWELRY PIECE on
different dates

10
Determine UID
• Option 2: Barred MOVIE STAR
RENTAL HISTORY for
relationship and Rental # rental date on
# id
* first name
* date returned
Date. * last name
for
• Adding rental date to the
on
UID would allow a MOVIE JEWELRY PIECE
STAR to rent the same #* description
code

JEWELRY PIECE on * rental rate

* insured value
different dates, but
would
to rentalso permitJEWELRY
the same
different
PIECE onMOVIE STARS
the same date!
12
Determine UID
• Option 3: Barred
relationship between RENTAL HISTORY for MOVIE STAR
MOVIE STAR and # rental date
* date returned
# id
on * first name
RENTAL HISTORY with for
* last name

Rental Date.
on
• This model would not JEWELRY PIECE
# code
permit the same MOVIE * description
* rental rate
STAR to rent more than * insured value

one JEWELRY PIECE on

a given day.
13
Determine UID
• Option 4: Barred
relationship between
JEWELRY PIECE and RENTAL HISTORY for MOVIE STAR
# id
# rental date
RENTAL HISTORY with * date returned on * first name
* last name
Rental Date. for

• This model says that a on

JEWELRY PIECE
JEWELRY PIECE can be # code

rented only once on the * description

* rental rate
* insured value
same date.

14
Terminology
Key terms used in this lesson included:
• Audit trail
• Historical data

15
Summary
In this lesson, you should have learned how to:
• Identify the need to track data that changes over time
• Construct ERD models that incorporate elements of
“data over time”
• Identify the UID of an entity that stores historical data;
explain and justify the choice of UID

16
Database Design
8-2
Modeling Change: Time

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Objectives
This lesson covers the following objectives:
• Distinguish between using date as an attribute and DAY
as an entity in a data model, depending on business
requirements
• Solve the problem of keeping characteristics of a date
by constructing a model that uses DAY as an entity
• Identify at least three time-related constraints that can 18

result from a time-sensitive model

• Define and give an example of conditional non-
transferability in a time-constrained model
Purpose
• Time plays a role in many business models.
• Historical data is often used by businesses to find trends
that can point the way to more efficient ways of doing
business.
• Modeling time in a business allows such data to be
captured.
• Reports provide information that can be derived from
19

the data.
• A well-designed report can provide valuable
information that the business can use to improve its
operations.
Entity DAY vs. Attribute Date
• Consider the entity PURCHASE.
• You would include an attribute “date” if PURCHASE
# id
you wanted to know when the item was * date
* quantity
purchased. * unit price

• However, if we want to identify trends --

PURCHASE
such as purchasing coats vs. bathing # id
suits vs. sneakers -- we may want to * date
* quantity
know the temperature during that time.
20
* unit price
* high temperature
• If we add the temperature attributes to * low temperature

the PURCHASE entity it creates a

problem.
Entity DAY vs. Attribute Date
• Remember Third Normal PURCHASE
# id
Form: a non-UID attribute * date
* quantity
cannot have attributes of its * unit price
own. * high temperature
* low temperature

• Because high and low

temperature are attributes of
the date, we need a 21

separate entity DAY. made on

DAY
# date
the time for * high temperature
PURCHASE
* low temperature
# id
* quantity
* unit price
Entity DAY vs. Attribute Date
• Having a separate DAY entity allows us to track more
information that may be useful to a business, for
example which days were public holidays.

PURCHASE DAY
# id made on # date
* quantity the time for * high temperature
* unit price * low temperature
* public holiday indicator
22
Time-related Constraints
• Be aware of constraints that can result from the need to
track dates and times.
• Here is an example:
– Consider a school fair that features several booths.
– The manager signs up volunteers to work different shifts at
different booths.
– A booth is staffed by only one volunteer at a time.
– Some volunteers can work for several hours; others can 23

work fewer hours depending on their free time.

– The schedule has to be determined in advance, so that
the manager knows which times are not covered by any
volunteers.
Time-related Constraints
• Here is a selection of time-
SHIFT ASSIGNMENT SCHEDULE
related constraints that # date
need to be considered for # start time
* end time
this model:
for
for
• The obvious one: shift “end
time” must be later than worked by work on
shift “start time.” BOOTH VOLUNTEER 24
# id # number
* name * name
Time-related Constraints
• Shift times may not overlap.
SHIFT ASSIGNMENT SCHEDULE
• The “start time” for a shift # date
# start time
for a volunteer may not be * end time
between any “start time” for
for
and “end time” of another
volunteer on the same worked by work on
booth. BOOTH VOLUNTEER
# id # number
• The same is true for the “end * name * name

time.”

10
Conditional Non-transferability

• The “start time” for a shift SHIFT ASSIGNMENT SCHEDULE

# date
may be updated to a # start time
later time, unless the * end time

shift has already begun. for for

worked by work on
BOOTH VOLUNTEER
# id # number
* name * name

26
Conditional Non-transferability
• You probably would not allow
SHIFT ASSIGNMENT SCHEDULE
a shift to be reassigned to # date
another volunteer or another # start time
* end time
booth, unless the shift had
for
not yet started. for

• This is an example of worked by work on

conditional non- BOOTH VOLUNTEER
# id # number
transferability. * name * name

27
Conditional Non-transferability
• Non-transferability: a
SHIFT ASSIGNMENT
SHIFT ASSIGNMENT SCHEDULE
cannot be changed to # date

another BOOTH (or to # start time

* end time
another VOLUNTEER).
for
for
• Nontransferable
relationships are worked by work on

represented by a BOOTH
# id
VOLUNTEER
# number
diamond in the ERD. * name * name

28
Conditional Non-transferability

• Conditional non-
SHIFT ASSIGNMENT SCHEDULE
transferability: a SHIFT # date
# start time
ASSIGNMENT can sometimes * end time
be changed – in this case, if for
for
the shift has not yet started.
• These relationships cannot worked by work on

be represented in the BOOTH

# id
VOLUNTEER
# number
diagram, but must still be * name * name

documented.

29
Terminology
Key terms used in this lesson included:
• Conditional non-transferability
• Non-transferability
• Time-related constraint

30
Summary
In this lesson, you should have learned how to:
• Distinguish between using date as an attribute and DAY
as an entity in a data model, depending on business
requirements
• Solve the problem of keeping characteristics of a date
by constructing a model that uses DAY as an entity
• Identify at least three time-related constraints that can
result from a time-sensitive model
• Define and give an example of conditional non-
transferability in a time-constrained model 31
Database Design
8-3
Modeling Change: Price

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Objectives
This lesson covers the following objectives:
• Solve the business requirement of tracking changes in
price or values by constructing a model that uses a
historical entity
• Describe the meaning of journaling/logging
• Identify the business need for journaling/logging and
construct a model that addresses this requirement 33
Purpose
• Historical prices are important when looking for
trends, determining the appreciation or depreciation
value of items, or getting a refund for an item
purchased in the past at a previous price.
• Many businesses track history of change -- who
changed it, when it was changed, and so on.
• Example: if a student’s grade is changed, it is useful to 34

record when it was changed, the old grade, the new

grade, and who changed it.
The Importance of Price Changes
• Changes in price are often an important consideration
when modeling business requirements.
• Some examples would be:
– The stock market: Prices are changing by the second and
you are watching the reader board, wondering when to buy
and when to sell. What factors would you consider?
– The fuel industry: Why would you want to track the price
changes in fuel if you are thinking of buying a car or heating 35

your home during the winter?

– Construction businesses: Why are price changes important
to a contractor of a five-year bridge-construction project?
What’s the Price Today?
• The prices of products change over time.
• Some go up, some go down, and others fluctuate up
and down.
• Food, clothing and school fees are more expensive now
than they were twenty years ago.
• Technology often gets cheaper over time.
• You can buy a standard specification laptop computer
36

today for around half the price of ten years ago.

• Gold, silver and currency are examples of commodities
whose prices fluctuate.
Model Historical Price
PRODUCT
• It is often useful to have # id
* name
information on past prices.
• The model shown here tracks the have

historical price of a product.

of

PRICE
37
# start date
o end date
* price
Historical Price Changes
• Consider what happens when you return an item to a
store.
• You purchased the item at a certain price, but it has
gone on sale since then.

38
Tracking Price Changes
• Businesses often need to PRODUCT PURCHASE
keep a record of price # id
* name on
# id
* purchase
changes. of date
* quantity
• In this model, we assume have purchased

that each PURCHASE is between

of only one product.

of
• The price that was paid can PRICE 39

be found by matching the # start date

o end date
purchase date between the * price
start date and the end
date of PRICE.
Other Data Changing Over Time
• We’ve seen that prices change over time.
• Other types of information can also change, for
different business reasons.

10
Journaling
made by
• Whenever a system allows a
user to modify or remove PAYMENT
# id for
particular information, the * date paid
* amount
question should be asked, “Do
the old values need to be kept with

on record?”
• This is called "logging" or of

AMOUNT MODIFICATION
"journaling." # date modified
* old amount
• This is often an issue when the * modified by
information is financial or of a
sensitive nature, such as a 41
Journal Content
• A journal usually consists of both the EMPLOYEE
# id
modified value and the information * first name

about who did the modification and * last name

* salary amount
when it was done. with

• This extra information can, of course,

be expanded if you wish. for

SALARY CHANGE
# date modified
* old salary amount
* modified by

42
Terminology
Key terms used in this lesson included:
• Appreciation
• Depreciation
• Journaling and/or logging

43
Summary
In this lesson, you should have learned how to:
• Solve the business requirement of tracking changes in
price or value by constructing a model that uses a
historical entity
• Describe the meaning of journaling/logging
• Identify the business need for journaling/logging and
construct a model that addresses this requirement

44
Database Design
9-1
Introduction to Relational Database Concepts

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

4
6
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.
4
7
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.
EMPLOYEES (table name)
EMPLOYEE_ID FIRST_NAME LAST_NAME DEPARTMENT_ID
100 Steven King 90
Row 101 Neena Kochhar 90
102 Lex De Haan 90
200 Jennifer Whalen 10
205 Shelley Higgins 110

Column

4
8
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:
SELECT last_name, department_id
FROM employees
WHERE employee_id = 200;

• You can see the result of this statement on the next

slide.

4
9
SQL Query Illustrated
EMPLOYEES (table name)
EMPLOYEE_ID FIRST_NAME LAST_NAME DEPARTMENT_ID

100 Steven King 90

101 Neena Kochhar 90

102 Lex De Haan 90

200 Jennifer Whalen 10

205 Shelley Higgins 110

SELECT last_name, department_id

FROM employees
WHERE employee_id = 200;

LAST_NAME DEPARTMENT_ID
Whalen 10

5
0
Specific SQL Query
• To find all the employees in department number 90,
we write a different SQL statement:
SELECT *
FROM employees
WHERE department_id = 90;

• Again, you can see the result on the next slide.

5
1
Specific SQL Query
EMPLOYEES (table name)
EMPLOYEE_ID FIRST_NAME LAST_NAME ... DEPARTMENT_ID

100 Steven King ... 90

101 Neena Kochhar ... 90

102 Lex De Haan ... 90

200 Jennifer Whalen ... 10

205 Shelley Higgins ... 110

SELECT *
FROM employees
WHERE department_id = 90;

EMPLOYEES (table name)

EMPLOYEE_ID FIRST_NAME LAST_NAME ... DEPARTMENT_ID

100 Steven King ... 90

101 Neena Kochhar 90

...
102 Lex De Haan 90
...

5
2
Primary Key ACCOUNTS
BANK_NO ACCT_NO BALANCE DATE_OPENED
• A primary key (PK) is 104 75760 12,0050.00 21-OCT-89

a column or set of 104 77956 100.10

105 89570 55,775.00 15-JAN-85
columns that 103 55890 15,001.85 10-MAR-91
uniquely identifies 105 75760 5.00 22-SEP-03

each row in a table. Multiple Column Primary Key

EMPLOYEE_ID FIRST_NAME LAST_NAME ... DEPARTMENT_ID

EMPLOYEES
100 Steven King ... 90
101 Neena Kochhar ... 90
102 Lex De Haan ... 90
200 Jennifer Whalen ... 10
205 Shelley Higgins ... 110
Single Column Primary Key

10
Primary Key ACCOUNTS
BANK_NO ACCT_NO BALANCE DATE_OPENED
• Each table should 104 75760 12,0050.00 21-OCT-89

have a primary key, 104 77956 100.10

105 89570 55,775.00 15-JAN-85
and a primary key 103 55890 15,001.85 10-MAR-91
must be unique. 105 75760 5.00 22-SEP-03

Multiple Column Primary Key

EMPLOYEES
EMPLOYEE_ID FIRST_NAME LAST_NAME ... DEPARTMENT_ID
100 Steven King ... 90
101 Neena Kochhar ... 90
54
102 Lex De Haan ... 90
200 Jennifer Whalen ... 10
205 Shelley Higgins ... 110
Single Column Primary Key
Primary Key ACCOUNTS
BANK_NO ACCT_NO BALANCE DATE_OPENED
• No part of the 104 75760 12,0050.00 21-OCT-89

primary key can be 104 77956 100.10

105 89570 55,775.00 15-JAN-85
null. 103 55890 15,001.85 10-MAR-91
105 75760 5.00 22-SEP-03

Multiple Column Primary Key

EMPLOYEES
EMPLOYEE_ID FIRST_NAME LAST_NAME ... DEPARTMENT_ID
100 Steven King ... 90
101 Neena Kochhar ... 90
102 Lex De Haan ... 90 55

200 Jennifer Whalen ... 10

205 Shelley Higgins ... 110
Single Column Primary Key
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.LAST_NAME
MEMBER_ID FIRST_NAME PAYROLL_ID
MEMBERS
100 SMITH DANA 21215
310 ADAMS TYLER 59877
56
210 CHEN LAWRENCE 1101
405 GOMEZ CARLOS 52
378 LOUNGANI NEIL 90386
Candidate Key Candidate Key
Choose a Candidate Key
• Select one candidate key to be the primary key for
the table.
• The other candidates become alternate keys (or
keys).
unique MEMBERS
MEMBER_ID LAST_NAME FIRST_NAME PAYROLL_ID
100 SMITH DANA 21215
310 ADAMS TYLER 59877
210 CHEN LAWRENCE 1101
405 GOMEZ CARLOS 52
378 LOUNGANI NEIL 90386 57

Primary Key Alternate or

Unique Key (UK)
Foreign Key Foreign Key
• A foreign key (FK) is a
EMPLOYEES

column, or EMPLOYEE_ID FIRST_NAME LAST_NAME DEPARTMENT_ID

100 Steven King 90

combination of 101 Neena Kochhar 90
columns, in one table
102 Lex De Haan 90
200 Jennifer Whalen 10
that contains values
205 Shelley Higgins 110
that match the primary
key value in another DEPARTMENTS
refers to

table. DEPARTMENT_ID DEPARTMENT_NAME

58
10 Administration
20 Marketing
50 Shipping

Primary Key
Foreign Key Rules
• If a primary key is composed of one or more foreign
keys, the FK value cannot be NULL.
Primary Key Primary Key

SHELF_NO BOOK_NO SHELF_NO BOOK_NAME

A6 106 A6 LITTLE WOMEN

A8 15 A8 TALE OF TWO CITIES

7987 B24 HARRY POTTER
B24
15 Q35 LEARN TO SPEAK SPANISH
Q35 59

SHELVES BOOKS

PK links to its FK
Column Integrity

• A column must ACCOUNTS

BANK_NO ACCT_NO BALANCE DATE_OPENED
contain only 104 75760 12,0050.00 21-OCT-1989
104 77956 100.10
values that are 105 89570 55,775.00 15-JAN-1985
consistent with 103 55890 15,001.85 10-MAR-1991

the defined data 105 75760 5.00 22-SEP-2003

format of the ACCOUNTS Table Definition

Column Name Data Type Optionality

column. BANK_NO Number (5) Not null

60

ACCT_NO Number (8) Not null

BALANCE Number (12,2) Not null

DATE_OPENED Date
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.

61
Summary of Data-Integrity Rules

Constraint Type Explanation Example

A primary key must be unique,
The column emp_no in the
Entity Integrity and no part of the primary key
EMPLOYEES table cannot be
can be null
null
The value in the dept_no column
A foreign key must match an
of the EMPLOYEES table must
Referential Integrity existing primary key value (or
match a value in the dept_no
else be null if nulls are allowed)
column in the DEPARTMENTS
table
A column must contain only The value in the balance column
Column Integrity values consistent with the of the ACCOUNTS table must be
defined data format of the numeric
column
62
If the value in the balance column
The data stored in a database of the ACCOUNTS table is below
User-Defined Integrity must comply with the rules of the 1.00, we must send a letter to
business the account owner ( this will
need additional programming to
enforce)
Terminology
Key terms used in this lesson included:
• Candidate key
• Column
• Foreign key
• Primary key
• Relational database
• Row
• Unique key

20
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

21
Database Design
9-2
Basic Mapping: The Transformation Process

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

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

6
6
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.

6
7
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.
Columns
EMPLOYEE_ID LAST_NAME FIRST_NAME DEPARTMENT_ID PAYROLL_ID NICKNAME
Table: EMPLOYEES
100 SMITH DANA 10 21215 Dana

310 ADAMS TYLER 15 59877 Ty

Rows 210 CHEN LAWRENCE 10 1101 Larry

405 GOMEZ CARLOS 10 52 Chaz

378 LOUNGANI NEIL 22 90386 Neil

Foreign Key Unique Key

Primary Key Column (PK)
Column (FK) Column (UK)

6
8
Review of Relational Tables
• Tables have columns and rows.
• In the example, each row describes an occurrence of an
employee.
Columns
Table: EMPLOYEES
EMPLOYEE_ID LAST_NAME FIRST_NAME DEPARTMENT_ID PAYROLL_ID NICKNAME

100 SMITH DANA 10 21215 Dana

310 ADAMS TYLER 15 59877 Ty

Rows 210 CHEN LAWRENCE 10 1101 Larry

405 GOMEZ CARLOS 10 52 Chaz

378 LOUNGANI NEIL 22 90386 Neil

Foreign Key Unique Key

Primary Key
Column Column (FK) Column (UK)
(PK)

6
9
Review of Relational Tables
• 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.
Columns
Table: EMPLOYEES
EMPLOYEE_ID LAST_NAME FIRST_NAME DEPARTMENT_ID PAYROLL_ID NICKNAME

100 SMITH DANA 10 21215 Dana

310 ADAMS TYLER 15 59877 Ty

Rows 210 CHEN LAWRENCE 10 1101 Larry

405 GOMEZ CARLOS 10 52 Chaz

378 LOUNGANI NEIL 22 90386 Neil

Primary Key Foreign Key Unique Key

Column Column (FK) Column (UK)
(PK)

7
0
Review of Relational Tables
• Every employee has a unique identification number in
this table.
• The value in the primary key column distinguishes each
individual row.
Columns
EMPLOYEE_ID LAST_NAME FIRST_NAME DEPARTMENT_ID PAYROLL_ID NICKNAME
Table: EMPLOYEES
100 SMITH DANA 10 21215 Dana

310 ADAMS TYLER 15 59877 Ty

Rows 210 CHEN LAWRENCE 10 1101 Larry

405 GOMEZ CARLOS 10 52 Chaz

378 LOUNGANI NEIL 22 90386 Neil

Primary Key Foreign Key Unique Key

Column Column (FK) Column (UK)
(PK)

7
1
Review of Relational Tables
• The payroll_id is a unique key.
• This means that the system does not allow two rows
with the same payroll_id.
Columns
Table: EMPLOYEES
EMPLOYEE_ID LAST_NAME FIRST_NAME DEPARTMENT_ID PAYROLL_ID NICKNAME

100 SMITH DANA 10 21215 Dana

310 ADAMS TYLER 15 59877 Ty

Rows 210 CHEN LAWRENCE 10 1101 Larry

405 GOMEZ CARLOS 10 52 Chaz

378 LOUNGANI NEIL 22 90386 Neil

Primary Key Foreign Key Unique Key

Column Column (FK) Column (UK)
(PK)

7
2
Review of Relational Tables
• The foreign key column refers to a column in
another table.
• In this example, the department_id refers to a
column in the DEPARTMENTS table.
Columns
EMPLOYEE_ID LAST_NAME FIRST_NAME DEPARTMENT_ID PAYROLL_ID NICKNAME
Table: EMPLOYEES
100 SMITH DANA 10 21215 Dana

310 ADAMS TYLER 15 59877 Ty

Rows 210 CHEN LAWRENCE 10 1101 Larry

405 GOMEZ CARLOS 10 52 Chaz

378 LOUNGANI NEIL 22 90386 Neil

Primary Key Foreign Key Unique Key

Column Column (FK) Column (UK)
(PK)

10
Review of Relational Tables
• 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.
Columns
Table: EMPLOYEES
EMPLOYEE_ID LAST_NAME FIRST_NAME DEPARTMENT_ID PAYROLL_ID NICKNAME

100 SMITH DANA 10 21215 Dana

310 ADAMS TYLER 15 59877 Ty

Rows 210 CHEN LAWRENCE 10 1101 Larry

74
405 GOMEZ CARLOS 10 52 Chaz

378 LOUNGANI NEIL 22 90386 Neil

Primary Key Foreign Key Unique Key

Column Column (FK) Column (UK)
(PK)
Transforming Conceptual To Physical
• The conceptual model (ER diagram) is transformed into
a physical model.
• The physical implementation will be a relational
database.

75
Transforming Conceptual To Physical
EMPLOYEE
Conceptual Model (ERD) DEPARTMENT
# employee id
# department id
*first name
* department name
Transformation * last name
process *payroll id
o nickname
Physical Implementation: Relational
Database
EMPLOYEES (EPE) DEPARTMENTS (DPT)

Key type Optionality Column name Key type Optionality Column name
pk * employee_id pk * department_id
uk * payroll_id * department_name
* last_name 76

* first_name

o nickname

fk * department_id
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. 77

– A relationship is transformed into a foreign-key column and a

foreign key constraint.
Terminology Mapping

ANALYSIS IMPLEMENTATION
ER Diagram Physical Design
Entity Table
Instance Row
Attribute Column
Primary UID Primary Key
Secondary UID Unique Key
Relationship Foreign 78

Key
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.TABLE NAME (short name)
Key Type (pk, uk, fk) Optionality (“*”, “o”) Column Name

79
Table Diagram Notations
• 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.
TABLE NAME (short name)
Key Type (pk, uk, fk) Optionality (“*”, “o”) Column Name

80
Naming Conventions for Tables and Columns
• The table name is the plural of the entity name.
• Example: STUDENT becomes STUDENTS
STUDENTS
STUDENT Key Type Optionality Column Name
# id pk * id
* first name * first_name
* last name
* last_name
* street address
* str_addr
* city
* state * city
81
* postal code * state
* date of birth
* p_code

* dob
Naming Conventions for Tables and Columns
• Column names are identical to the attribute names
except that special characters and spaces are replaced
with underscores.
STUDENTS
STUDENT Key Type Optionality Column Name
# id pk * id
* first name * first_name
* last name
* last_name
* street address
* str_addr
* city
* state * city 82

* postal code * state

* date of birth
* p_code

* dob
Naming Conventions for Tables and Columns
• Column names often use more abbreviations than
attribute names. Example: first name
becomes first_name, or fname
STUDENTS
STUDENT Key Type Optionality Column Name
# id pk * id
* first name * first_name
* last name
* last_name
* street address
* str_addr
* city
* state * city
* postal code * state
* date of birth
* p_code

* dob

20
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
84
– Last character of the last word
• Example: JOB ASSIGNMENT gets a short name of JAT
Table Short Names

PRIVATE HOMES (PHE)

PRIVATE HOME Key Type Optionality Column Name
# id pk * id
* address
* address
o comments
o comments

85
Table Short Names
• 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
86
Table Short Names

CLIENTS (CET)
Key Type Optionality Column Name
CLIENT
# number pk * client_num
*first name * first_name
* last name * last_name
*phone number
* phone_num
o email address
o email_addr

87
Table Short Names
• 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
THEMES (THE)
Key Type Optionality Column Name
THEME 88
# code pk * code
* description
* description
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. 89

• Column names must be unique within a table.

Naming Restrictions with Oracle
• 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.

90
Naming Restrictions with Oracle
• Some common examples of Oracle reserved words are:
– TABLE
– NUMBER
– SEQUENCE
– ORDER
– VALUES
– LEVEL
– TYPE
91

• A complete list can be found on otn.oracle.com.

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

92
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

30
Exercise 07
Perusahaan ritel sebagaimana pada kasus sebelumnya memiliki 1 gudang logistik
yang beroperasi. Gudang logistik ini melakukan purchase order kepada supplier yang
secara umum terdiri atas data supplier yang dituju, tanggal PO, produk-produk yang
dibeli beserta kuantitasnya. Supplier pun merespon dengan mengirimkan barang
sesuai yang order. Barang-barang tersebut diterima oleh gudang logistik. Secara umum
terdapat data-data yang perlu dicatat seperti supplier yang bersangkutan tanggal
penerimaan, dan data produk-produk yang diterima beserta kuantitasnya.

1. Modifikasi notasi ERD (pada kasus lalu) untuk menyelesaikan ketentuan di atas!
2. Berdasarkan notasi ERD, buatlah physical data model!
3. Representasikan dalam bentuk tabel dan isi dengan data dummy!
4. Simpan hasil pekerjaan dalam bentuk pdf lalu submit ke LMS teori dan praktik!
94
Kasus Sebelumnya 1

Sebuah perusahaan ritel di Indonesia menjual ribuan produk yang berbeda.

Setiap produk memiliki barcode yang tentu berbeda satu dengan yang lainnya.
Selain itu, setiap produk diharuskan mencantumkan dimensi dan netto. Price tag
merupakan salah satu komponen produk yang utama.Produk-produk tersebut
terbagi menjadi puluhan kategori produk seperti food, beverage, shoap,
perishable, noodles, tobaco, etc.

95
Kasus Sebelumnya 2
Perusahaan ritel sebagaimana pada kasus yang lalu menjalin relasi dengan banyak
supplier. Setiap supplier memiliki nama yang lengkap baik supplier yang sudah berbadan
hukum (CV/PT) ataupun belum memiliki badan hukum. Setiap supplier memiliki alamat
jelas, nomor kontak, alamat lengkap, dan juga NPWP. Kebanyakan supplier merupakan
PKP (Pengusaha Kena Pajak), hanya sebagian kecil saja yang Non-PKP dan tidak
memiliki NPWP. Ada ketentuan yang perlu dicermati yakni satu supplier dapat memasok
satu atau lebih produk. Begitupun dengan produk, satu produk dapat dipasok oleh satu
atau lebih supplier.

96
Kasus Sebelumnya 3
Perusahaan ritel sebagaimana pada kasus yang lalu, memiliki lebih dari satu
toko/gerai yang tersebar di berbagai daerah di Indonesia. Setiap toko memiliki
kode yang unik. Nama toko biasanya diambil dari nama kelurahan/desa
dimana toko tersebut berada. Setiap toko memiliki alamat yang sangat
lengkap dimulai dari nama dan nomor jalan, RT dan RW, kecamatan,
kelurahan atau desa, kota atau kabupaten, hingga provinsi. Pada perusahaan
ini, toko-toko dikategorikan menjadi 3 jenis sesuai dengan jumlah rak display-
nya yakni tipe 36, tipe 45, dan tipe 64.

97
Kasus Sebelumnya 4
Perusahaan ritel sebagaimana pada kasus sebelumnya, mempekerjakan
banyak karyawan yang terbagi dalam beberapa departemen seperti HR,
Logistik, Merchandising, General Affair, Finance, IT, Operasional dan lain-lain.
Setiap Karyawan memiliki 1 job title masing-masing. Contoh job title tersebut
adalah Data Engineer, Frontend Developer, dan Backend Developer yang
terafiliasi pada departemen IT. Contoh lainnya adalah kasir dan kepala toko
pada departemen Operasional. Khusus untuk karyawan pada departemen
Operasional, mereka bertugas di Gerai yang mana 4-8 karyawan dapat
bekerja pada gerai yang sama.
98
Literatur

•Avi Silberschatz, et al. 2006. DATABASE SYSTEM CONCEPT 5th

Edition
•Elmasri and Navathe. 2011. Fundamentals of Database System
6th Edition. Addison-Wesley
•Oracle Academy
•Any related sources

99