MAKALAH

TUGAS PROJECT ORACLE

Disusun Oleh :
NIM NAMA
2009106069 Jorghi Inzaghi Tanson
2009106054 Vauwez Sam El Fareez
2009106066 Benny Hernanda Putra
2009106072 Gilang Raditya
2009106100 Alyani Noor Septalia

KELAS B 2020
PROGRAM STUDI INFORMATIKA
FAKULTAS TEKNIK
UNIVERSITAS MULAWARMAN TAHUN 2021
 DAFTAR PROJECT

PROJECT 1-4 1
PROJECT 2-3 #1 2
PROJECT 2-3 #2 2
PROJECT 2-3 #3 3
PROJECT 2-3 #4 5
PROJECT 2-4 #1 6
PROJECT 2-4 #2 7
PROJECT 2-5 #1 8
PROJECT 2-5 #2 10
PROJECT 2-5 #3 14
PROJECT 2-5 #4 17
PROJECT 2-6 19
PROJECT 3-1 #1 20
PROJECT 3-1 #2 20
PROJECT 3-1 #3 21
PROJECT 3-1 #4 22
PROJECT 3-2 23
PROJECT 3-3 #1 24
PROJECT 3-3 #2 25
PROJECT 3-3 #3 26
PROJECT 3-3 #4 27
PROJECT 3-4 28
PROJECT 1-4
Latihan 1: Entitas dan Atribut (Mengidentifikasi Entitas)

Pernyataan Aturan Bisnis Asumsi Masalah

Memiliki 3 perwakilan resmi yang menangani
penjualanan tim dan bisa menangani keluhan x
pelanggan individu.
Individu tidak mendapat diskon walaupun
barang yang dibeli sama dengan pelanggan x
tim.
-Pelanggan bisa mewakili tim saat mereka
membeli seragam dan peralatan tim.
x
-Mencatat item pesanan untuk pesanan itu di
database
* solusinya untuk individu untuk mendapat diskon dari jumlah item yang dibeli.

1
PROJECT 2-3 #1
Latihan 1: Entitas dan Atribut (Mengidentifikasi Entitas)

1. Item
2. Customer
3. Order
4. Inventory List
5. Sales Representative
6. Team

PROJECT 2-3 #2
Latihan 2: Entitas dan Atribut (Mengidentifikasi Atribut)
Berikut adalah entitas beserta daftar atributnya

 Customer
o Name
o Address
o Phone Number
o Email
o Team They Belong to
o Current Balance

 Team
o Name
o Number of Player
o Discount

 Sales representative
o Name
o Address
o Phone Number
o Email
o Total Commision
o Commision Rate

 Order
o Date
o Item Purchased
o Item Size
o Color
o Number of Units
o Price
o Total Price

2
  Item
o Name
o Description
o Color
o Size

 Inventory List
o Cost of the unit
o Unit on hand

PROJECT 2-3 #3
Latihan 3: Entitas dan Atribut (Mengidentifikasi Atribut Wajib/Opsional)

 Customer
* Name
* Address
* Phone Number
* Email
* Current Balance
o Team They belong to

 Team
* Name
* Number of Player
o Discount

 Sale Representative
* Name
* Address
* Phone Number
* Email
* Total Commission
* Commision Rate

 Order
* Date
* Item Purchased
* Item Size
* Color
* Number of units
* Price
* Total Price

3
 Item
* Name
* Description
* Price
o Color
o Size

 Inventory List
* Cost of the unit
* Unit on hand

Atribut Volatile yaitu atribut yang mudah menguap dan tidak stabil:

 Current balance pada entitas Customer

 Discount pada entitas Team
 Commision rate pada entitas Sales Representative
 Biaya grosir unit pada entitas Daftar Inventaris
 Cost of the unit pada entitas Inventory List
 Number of players pada entitas Team

Atribut Non-Volatile yaitu atribut yang stabil:

 Name pada entitas Item, Team, Customer, dan Sales Representative

 Date pada entitas Order

4
PROJECT 2-3 #4
Latihan 4: Entitas dan Atribut (Menggunakan Notasi Barker)

5
PROJECT 2-4 #1
Latihan 1: Mengidentifikasi Unique Identifier (UID)

6
PROJECT 2-4 #2
Latihan 2: Menngidentifikasi Unique Identifier Buatan (Artificial UID)

7
PROJECT 2-5 #1
Latihan 1: Mengenali Contoh dari Relasi

8
9
PROJECT 2-5 #2
Latihan 2: Mengidentifikasi Opsionalitas dari Relasi

PART 1

Kiri ke kanan:
 Setiap PELANGGAN dapat mewakili TIM
Kanan ke kiri:
 Setiap TIM harus diwakili oleh PELANGGAN

Kiri ke kanan :
 Setiap PELANGGAN dapat diberikan SALES REPRESENTATIVE
Kanan ke kiri :
 Setiap SALES REPRESENTATIVE harus ditugaskan ke satu atau lebih PELANGGAN

Kiri ke kanan :
 Each CUSTOMER may place one or more ORDERs
Kanan ke kiri :
 Each ORDER must be placed by a CUSTOMER

10
Kiri ke kanan :
 Setiap ORDER harus menyertakan satu atau lebih ITEM
Kanan ke kiri :
 Setiap ITEM dapat menjadi bagian dari satu atau lebih PESANAN

Kiri ke kanan :
 Setiap ITEM harus ada dalam DAFTAR INVENTORY
Kanan ke kiri :
 Setiap DAFTAR INVENTARISASI dapat mencakup satu atau lebih ITEM

PART 2

11
12
13
PROJECT 2-5 #3
Latihan 2: Mengidentifikasi Kardinalitas dari Relasi

Kiri ke kanan :
- Each CUSTOMER may represent a TEAM
Kanan ke kiri :
- Each TEAM must be represented by a CUSTOMER

Kiri ke kanan :
- Each CUSTOMER may be assigned a SALES REPRESENTATIVE
Kanan ke kiri :
- Setiap SALES REPRESENTATIVE harus ditugaskan ke satu atau lebih PELANGGAN

14
Kiri ke kanan :
- Setiap ORDER harus menyertakan satu atau lebih ITEM
Kanan ke kiri :
- Setiap ITEM dapat menjadi bagian dari satu atau lebih PESANAN

Kiri ke kanan :
- Each CUSTOMER may place one or more ORDERs
Kanan ke kiri :
- Setiap ORDER harus dilakukan oleh PELANGGAN

15
Kiri ke kanan :
- Setiap ITEM harus ada dalam DAFTAR INVENTORY
Kanan ke kiri :
- Setiap DAFTAR INVENTORY dapat mencakup satu atau lebih ITEM

16
 PROJECT 2-5 #4
Latihan 2: Menggunakan Matrix Relasi

PART 1

17
PART 2

18
PROJECT 2-6

Latihan 1 : Pemodelan Hubungan Entitas

Entity Relationship Diagram (ERD) memungkinkan Anda untuk menggambarkan secara grafis
informasi sistem dan memiliki empat tujuan sebagai berikut:
- Tangkap semua informasi yang diperlukan.
- Pastikan informasi hanya muncul sekali.
- Model tidak ada informasi yang diturunkan dari informasi lain yang sudah dimodelkan.
- Cari informasi di tempat yang dapat diprediksi dan logis.
Karena Anda telah mengidentifikasi entitas, atributnya, dan hubungan antara entitas, Anda sekarang
dapat mulai membangun ERD final yang akan menunjukkan bagaimana sistem dihubungkan
bersama.
Dengan menggunakan informasi yang telah Anda kumpulkan selama proyek ini, buat ERD yang
sesuai dengan empat tujuan yang ditentukan di atas. Bangun ERD Anda mengikuti konvensi
diagram.
Bentuk ERD :

19
PROJECT 3-1 #1

Hubungan M:M antara ORDER dan ITEM harus diselesaikan dengan menggunakan entitas
persimpangan.
Entitas persimpangan telah diberi nama ITEM PESANAN dan menyimpan informasi tentang jumlah
barang yang dipesan dan berapa banyak yang telah dikirim. Ini memberi kami opsi untuk
mengirimkan barang dalam pengiriman yang berbeda.
UID untuk ORDERED ITEM menggunakan hubungan terlarang untuk menggunakan UID dari
ORDER dan ITEM sebagai UID.
Bentuk ERD :

PROJECT 3-1 #2

Dalam skenario informasi berikut disampaikan:

Interviewer : Ketika seorang pelanggan memesan, dapatkah pesanan itu dialihkan ke orang
lain?
Manager : Tidak ada pesanan antara perusahaan dan orang yang memesan; yang tidak
pernah bisa berubah.

Hal tersebut memberitahu bahwa hubungan antara PELANGGAN dan ORDER tidak dapat
dipindahtangankan dan ini ditunjukkan pada ERD dengan menggunakan notasi berlian.
Bentuk ERD :

PROJECT 3-1 #3
20
Dalam skenario informasi berikut disampaikan.
Interviewer : Kembali ke pelanggan, dapatkah pelanggan menjadi perwakilan tim dan juga
pelanggan individu?
Manager : Tentu saja, tetapi mereka akan memiliki dua akun terpisah dengan pembelian
di satu akun tidak memengaruhi pembelian di akun lainnya.
Interviewer : Apakah ada sesuatu yang Anda pikirkan tentang memperkenalkan yang
mungkin mempengaruhi sistem baik sekarang atau di masa depan?
Manager : Kami sedang mempertimbangkan untuk memperkenalkan skema kartu
: loyalitas untuk pelanggan individu. Ini akan menjadi skema opsional yang
memungkinkan anggota kartu loyalitas untuk menghadiri malam penjualan
khusus di mana mereka dapat membeli barang dengan harga lebih murah.

Informasi tersebut memperkuat bahwa pelanggan dapat menjadi salah satu dari dua tipe unik. Karena
hanya pelanggan individu yang menerima kartu loyalitas dan pelanggan tim mewakili tim yang
memberi kami serangkaian atribut unik untuk masing-masing. Kami kemudian dapat menyimpan
atribut umum di tingkat supertipe dan atribut unik di tingkat subtipe.
Bentuk ERD :

21
PROJECT 3-1 #4

PART 1
Salah satu perwakilan penjualan mengawasi alokasi tim ke yang lain sehingga hubungan rekursif
digunakan di sini.
Bentuk ERD :

PART 2
Hubungan supertipe/subtipe menunjukkan hubungan eksklusif karena subtipe harus saling
eksklusif satu sama lain. Ini dapat diwakili dengan menggunakan busur dan itu benar-benar
tergantung pada pilihan pribadi ke arah mana Anda ingin menunjukkannya di ERD.
Bentuk ERD :

22
PROJECT 3-2
Melacak Data yang Berubah Sepanjang Waktu

Informasi yang ada dalam satu entitas hanya dapat menyimpan nilai tunggal (atau saat ini). Jika
kita mengubah nilai tersebut, semua informasi historis akan hilang. Untuk menyimpan data terkini
dan historis atau alternatif, kita mungkin harus menambahkan entitas dan hubungan ke model
untuk mengakomodasi informasi tambahan ini.

Karena harga barang dapat berubah, kita perlu menghapus harga dari ITEM dan menempatkannya
di entitasnya sendiri yang disebut PRICE HISTORY. Entitas yang dinamai PRICE HISTORY
mencatat tanggal dan waktu mulai ketika harga diubah. Atribut akhir bersifat opsional karena
atribut tersebut perlu menyimpan harga yang berlaku yang belum berakhir. Atribut ini memiliki
UID komposit dari tanggal mulai dan waktu mulai yang digabungkan dengan hubungan paralel
dengan ITEM yang menciptakan nilai unik. Ini menggunakan hubungan paralel untuk mengambil
UID ITEM untuk membuat hubungan antara ITEM dan PRICE HISTORY.

Solusinya adalah :

23
PROJECT 3-3 #1
Menggunakan Normalisasi untuk Memvalidasi Data
Mengonversi Data ke dalam Bentuk Tidak Normal

Bentuk Tidak Normal (UNF) :

- Hapus bidang yang dihitung yang dapat diturunkan dari atribut lain.
- Pastikan setiap entitas memiliki pengenal unik.
- Hapus data duplikat tempat informasi disimpan di beberapa entitas.

Ambil data yang saat ini dinyatakan dalam ERD dan konversikan data ke dalam Bentuk Tidak Normal
sehingga data dapat dikatakan berada di UNF

Solusinya adalah :

24
PROJECT 3-3 #2
Menggunakan Normalisasi untuk Memvalidasi Data Bentuk Normal Pertama

Normalisasi adalah konsep database relasional, tetapi prinsipnya berlaku untuk pemodelan data.
Bentuk Normal Pertama (1NF) :
- Data atomik (Semua atribut harus bernilai tunggal).
- Entri dalam kolom memiliki jenis yang sama.
- Tidak boleh ada baris duplikat dalam tabel yang berarti bahwa tabel memiliki sekelompok
kolom yang secara unik mengidentifikasi baris. Ambil data yang tidak dinormalisasi yang saat ini
dinyatakan dalam ERD dan terapkan prinsip-prinsip Bentuk Normal Pertama sehingga data dapat
dikatakan berada di 1NF

Solusinya adalah :

25
PROJECT 3-3 #3
Menggunakan Normalisasi untuk Memvalidasi Data Bentuk Normal Kedua
Bentuk Normal Kedua (2NF) :
- Data memenuhi persyaratan untuk 1NF.
- Mengharuskan bahwa setiap atribut non-UID bergantung pada keseluruhan UID
- Jika data tidak secara langsung bergantung pada keseluruhan UID, data perlu dipindahkan ke
tabel lain.

Ambil data yang saat ini dinyatakan dalam ERD di 1NF dan terapkan prinsip-prinsip Bentuk
Normal Kedua agar data dapat dikatakan berada di 2NF.

Solusinya adalah :

26
PROJECT 3-3 #4
Menggunakan Normalisasi untuk Memvalidasi Data Bentuk Normal Ketiga
Bentuk Normal Ketiga (3NF) :
- Ini memenuhi semua pesyaratan database untuk 1NF dan 2NF.
- Tidak ada atribut non-UID yang dapat bergantung pada atribut non-UID lain.
- Setiap kolom harus bergantung langsung pada UID. Semua atribut yang tidak bergantung pada
UID harus dihapus. Misalnya, atribut yang dapat diturunkan dari data yang terdapat di bidang dan
tabel lain harus dihilangkan. (Semua dependensi transitif dihapus).

Ambil data yang saat ini dinyatakan dalam ERD di 2NF dan terapkan prinsip-prinsip Bentuk
Normal Ketiga agar data dapat dikatakan berada di 3NF.

Penjelasan solusi 1 :
Jika Anda menerima bahwa atribut Baris Alamat 1, Baris Alamat 2, dan Kota bergantung pada
Kode pos dan tidak bergantung pada UID untuk Perwakilan Penjualan, atribut tersebut perlu
dihapus dan ditempatkan di entitas mereka sendiri. Bidang Kode pos tidak unik untuk setiap
alamat tetapi mewakili kelompok alamat sehingga hubungan paralel dibuat dengan Perwakilan
Penjualan. Ini memungkinkan hanya satu alamat yang akan disimpan untuk masing-masing
Perwakilan Penjualan.

Penjelasan solusi 2:
Jika Anda tidak menerima bahwa atribut Baris Alamat 1, Baris Alamat 2, dan Kota bergantung
pada Kode pos tetapi memang bergantung pada UID untuk Perwakilan Penjualan, maka
perubahan ke diagram tidak perlu dibuat dan dapat dikatakan telah ada di bentuk normal ketiga

27
PROJECT 3-4
Part 1

Table Name Table Short Name

CUSTOMERS ctr
Key Type Optionality Column Name
pk * ctr_number
uk * email
* first_name
* last_name
* phone_number
* current_balance
uk o loyalty_card_number
fk1 o tem_id
fk2 o sre_id

Table Name Table Short Name

TEAM tem
Key Type Optionality Column Name
pk * id
uk * name
* number_of_players
o discount

Table Name Table Short Name

SALES_REPRESENTATIVES sre
Key Type Optionality Column Name
pk * id
uk * email
* first_name
* last_name
* phone_number
* commision_rate
fk1 o spr_id

Table Name Table Short Name

SALES_REPRESENTATIVE srs
_
ADDRESSES
Key Type Optionality Column Name
* address_line_1
o address_line_2
* city
28
 * postal_code
pk, fk * sre_id

Table Name Table Short Name

CUSTOMER_ADDRESSES cas
Key Type Optionality Column Name
pk * id
* address_line_1
o address_line_2
* city
* postal_code
fk1 * ctr_id

Table Name Table Short Name

ORDERS ord
Key Type Optionality Column Name
pk * id
* date
* time
* number_of_units
fk * ctr_id

Table Name Table Short Name

ORDERED_ITEMS oim
Key Type Optionality Column Name
* quantity_ordered
* quantity_shipped
pk, fk1 * odr_id
pk, fk2 * itm_number

Table Name Table Short Name

ITEMS itm
Key Type Optionality Column Name
pk * itm_number
* name
* description
* category
o color
o size
fk * ilt_id

Table Name Table Short Name

INVENTORY_LISTS ilt
29
Key Type Optionality Column Name
pk * id
* cost_of_the_unit
* units_on_hand

Table Name Table Short Name

PRICE_HISTORIES phy
Key Type Optionality Column Name
pk * start_date
pk * start_time
* price
o end_date
o end_time
fk * itm_id

PART 2

Table Name Table Short Name

CUSTOMER ctr
Key Type Optionality Column Name Data type Size
pk * ctr_number VARCHAR2 6
uk * email VARCHAR2 50
* first_name VARCHAR2 20
* last_name VARCHAR2 30
* phone_number VARCHAR2 11
* current_balance NUMBER 6,2
uk o loyalty_card_numbe VARCHAR2 6
r
fk1 o tem_id VARCHAR2 4
fk2 o sre_id VARCHAR2 4

Table Name Table Short Name

SALES_REPRESENTATIV srp
E
Key Type Optionality Column Name Data type Size
pk * id VARCHAR2
uk * email VARCHAR2
* first_name VARCHAR2
* last_name VARCHAR2
* phone_number VARCHAR2 11
* commission_rates NUMBER 2

30
fk * spr_id VARCHAR2

Table Name Table Short Name

ORDERS ord
Key Type Optionality Column Name Data type Size
pk * id VARCHAR2 10
* date DATE
* time TIMESTAMP 0
* number_of_unit NUMBER 4
fk * ctr_id VARCHAR2 6

Table Name Table Short Name

ITEMS itm
Key Type Optionality Column Name Data type Size
pk * itm_number VARCHAR2 10
uk * name VARCHAR2 20
* description VARCHAR2 60
* category VARCHAR2 30
o color VARCHAR2 20
o size CHAR 1
fk * ilt_id VARCHAR2 10

Table Name Table Short Name

TEAM tem
Key Type Optionality Column Name Data Type Size
pk * id VARCHAR2 4
uk * name VARCHAR2 30
* number_of_players NUMBER 2
o discount NUMBER 2

Table Name Table Short Name

CUSTOMER_ADDRESSES cas
Key Type Optionality Column Name Data Type Size
pk * id VARCHAR2 8
* address_line_1 VARCHAR2 50
o address_line_2 VARCHAR2 50
* city VARCHAR2 20
* postal_code VARCHAR2 5
fk1 * ctr_id VARCHAR2 6

Table Name Table Short Name

SALES_REPRESENTATIVE srs
31
_
ADDRESSES
Key Type Optionality Column Name Data Type Size
* address_line_1 VARCHAR2 50
o address_line_2 VARCHAR2 50
* city VARCHAR2 20
* postal_code VARCHAR2 5
pk, fk * sre_id VARCHAR2 4

Table Name Table Short Name

ORDERED_ITEMS oim
Key Type Optionality Column Name Data Type Size
* quantity_ordered NUMBER 4
* quantity_shipped NUMBER 4
pk, fk1 * odr_id VARCHAR2 10
pk, fk2 * itm_number VARCHAR2 10

Table Name Table Short Name

INVENTORY_LISTS ilt
Key Type Optionality Column Name Data Type Size
pk * id VARCHAR2 10
* cost NUMBER 7,2
* stock NUMBER 4

Table Name Table Short Name

PRICE_HISTORIES phy
Key Type Optionality Column Name Data Type Size
pk * close_initial DATE
pk * start_time TIMESTAMP 0
* price NUMBER 7,2
o close_end DATE
o end_time TIMESTAMP 0
pk, fk1 * act_number VARCHAR2 10

32