Normalisasi

Database

1/29

Pengantar Penyempurnaan Skema:

Persoalan yang Ditimbulkan oleh Redundansi
Redundansi ruang penyimpanan: beberapa data disimpan

secara berulang
Update anomaly: Jika satu copy data terulang tsb diubah,
inkonsistensi data dpt terjadi kecuali kalau semua copy dari
data tsb diubah dengan cara yang sama
Insertion anomaly: Mungkin dpt terjadi kesulitan utk
menyisipkan data tertentu kecuali kalau beberapa data
tidak terkait lainnya juga ikut disisipkan
Deletion anomaly: Mungkin dpt terjadi kesulitan utk
menghapus data tertentu tanpa harus kehilangan beberapa
data tidak terkait lainnya

2/29

Persoalan yang Ditimbulkan

oleh Redundansi: Contoh
NIP
1001
1002
1003
1004
1005

Nama
Yana
Yani
Yono
Yuni
Yuno

Jabatan
Kepala Pusat
Kepala Pusat
Kepala Bidang
Pelaksana
Pelaksana

Grading
23
23
20
15
15

Redundansi ruang penyimpanan: Pelaksana yang berkorespondensi dg

grading 15 diulang dua kali

Update anomaly: Nilai Jabatan (yg terkait dengan nilai grading) dlm baris
pertama dpt diubah tanpa membuat perubahan yg sama pada baris kedua
Insertion anomaly: Kesulitan utk menyisipkan pegawai baru kecuali nilai
grading untuk jabatan dari pegawai tsb sudah diketahui
Deletion anomaly: Jika semua baris yang terkait dg nilai jabatan tertentu
dihapus (misalnya baris utk pegawai Yono dihapus), maka kita akan
kehilangan informasi ketergantungan antara nilai jabatan dan nilai grading
yang diasosiasikan dengan nilai rating tsb (yaitu jabatan = Kepala Bidang
dan grading = 20)
3/29

Penyebab Anomali
Mengapa anomali - anomali ini terjadi ?
Karena menggabungkan dua tema (konsep entitas) dalam satu

relasi. Ini mengakibatkan duplikasi duplikasi sebagai akibat dari

ketergantungan antar atribut yang tidak pada tempatnya.
Solusi : Normalisasi

4/29

Normalisasi
Normalisasi adalah proses pembentukan struktur

database sehingga sebagian besar ambiguity bisa

dihilangkan.
Tahap Normalisasi dimulai dari tahap paling ringan
(1NF) hingga paling ketat (5NF)
Biasanya hanya sampai pada tingkat 3NF atau
BCNF karena sudah cukup memadai untuk
menghasilkan tabel-tabel yang berkualitas baik.

5/29

Normalisasi
Sebuah tabel dikatakan baik (efisien) atau normal jika
memenuhi 3 kriteria sbb:
1.

2.
3.

Jika ada dekomposisi (penguraian) tabel, maka

dekomposisinya harus dijamin aman (Lossless-Join
Decomposition). Artinya, setelah tabel tersebut diuraikan /
didekomposisi menjadi tabel-tabel baru, tabel-tabel baru
tersebut bisa menghasilkan tabel semula dengan sama
persis.
Terpeliharanya ketergantungan fungsional pada saat
perubahan data (Dependency Preservation).
Tidak melanggar Boyce-Code Normal Form (BCNF) (-akan
dijelaskan kemudian-)
6/29

Normalisasi
Jika kriteria ketiga (BCNF) tidak dapat terpenuhi,
maka paling tidak tabel tersebut tidak melanggar
Bentuk Normal tahap ketiga (3rd Normal Form /
3NF).

7/29

Langkah Langkah Normalisasi

8/29

Tabel Universal
Tabel Universal (Universal / Star Table) sebuah
tabel yang merangkum semua kelompok data
yang saling berhubungan, bukan merupakan tabel
yang baik.
Misalnya:

9/29

Tabel Universal
NIP
037

038
039

Nama
Nina

Tono
Hadi

No_klien

Nama_klien

K05

Martini

K08

Anton

K02

Sarmini

K04

Eka

K10

Andin

K06

Mitha

K24

Buyung

K90

Indah

10/29

Functional Dependency
Notasi: A B

A dan B adalah atribut dari sebuah tabel. Berarti

secara fungsional A menentukan B atau B
tergantung pada A, jika dan hanya jika ada 2 baris
data dengan nilai A yang sama, maka nilai B juga
sama
Notasi: A B atau A x B
Adalah kebalikan dari notasi sebelumnya.

11/29

Functional Dependency
Contoh tabel pemasok

Kode

Nama_Brg

Harga

Kd_Pemasok

Nm_Pemaso
k

Kota

T-001

TV SN 14

600.000

P22

PT Sumber

Jakarta

T-002

TV SN 21

950.000

P22

PT Sumber

Jakarta

T-003

TV SS 14

450.000

P11

PT Tunas
Jaya

Surabaya

T-004

TV M 34

4.500.000

P33

PT Mekar

Semarang

T-005

TV S 24

1.200.000

P44

PT Holic

Semarang

12/29

Dependensi Fungsional
Berdasarkan tabel tersebut, diperoleh:
Kode Nama_Brg
Kode Harga
Kode Kd_Pemasok
Kode Nm_Pemasok
Kd_Pemasok Nm_Pemasok
Setiap Kode pasti berhubungan dengan satu Nama_Brg begitu juga antara Kode
dan Harga. Begitu seterusnya.
Misalnya: T-001 hanya cocok dengan 1 barang, yaitu TV SN 14
Catatan: Bagaimana kalau dibalik?
Harga tidak menentukan barangnya, (karena banyak barang mempunyai harga
yang sama); tapi satu jenis barang punya satu harga.
Nama_Brg Kode
Nm_Pemasok Kode_Pemasok
13/29

Dependensi Fungsional
Perhatikan bagian ini:
Kode Nama_Brg
Kode Harga
Kode Kd_Pemasok
Kode Nm_pemasok
Kd_Pemasok Nm_Pemasok

Ternyata, Kode menentukan lebih dari satu atribut.

Notasinya dapat diganti sebagai berikut:
Kode {Nama_Brg, Harga, Kd_Pemasok}
Kode Nm_Pemasok (yang ini bagaimana?)
14/29

Bentuk-bentuk Normal
1.
2.
3.
4.
5.
6.

Bentuk Normal Tahap Pertama (1st Normal Form

/ 1NF)
Bentuk Normal Tahap Kedua (2nd Normal Form /
2NF)
Bentuk Normal Tahap (3rd Normal Form / 3NF)
Boyce-Code Normal Form (BCNF)
Bentuk Normal Tahap (4th Normal Form / 4NF)
Bentuk Normal Tahap (5th Normal Form / 5NF)

15/29

Bentuk Normal Tahap Pertama

(1st Normal Form / 1NF)
Bentuk normal 1NF terpenuhi jika sebuah tabel

tidak memiliki atribut bernilai banyak (multivalued

attribute), atribut composite atau kombinasinya
dalam domain data yang sama.
Setiap atribut dalam tabel tersebut harus bernilai
atomic (tidak dapat dibagi-bagi lagi)

16/29

Data Tidak Ternormalisasi

NIP
037

038
039

Nama
Nina

Tono
Hadi

No_klien

Nama_klien

K05

Martini

K08

Anton

K02

Sarmini

K04

Eka

K10

Andin

K06

Mitha

K24

Buyung

K90

Indah

17/29

Data 1NF
NIP

Nama

No_klien

Nama_klien

037

Nina

K05

Martini

037

Nina

K08

Anton

037

Nina

K02

Sarmini

038

Tono

K04

Eka

038

Tono

K10

Andin

039

Hadi

K06

Mitha

039

Hadi

K24

Buyung

039

Hadi

K90

Indah

18/29

Contoh 2 (composite)
JadwalKuliah
Kodekul

NamaKul

Dosen

Kelas

Jadwal

Dimana nilai pada atribut jadwal berisi gabungan antara

Hari dan Jam.
Jika asumsi hari dan jam memegang peranan penting
dalam sistem database, maka atribut Jadwal perlu
dipisah sehingga menjadi JadwalHari dan JadwalJam
sbb:
JadwalKuliah
Kodekul

NamaKul

Dosen

Kelas

JadwalHari JadwalJam

19/29

Bentuk Normal Tahap Kedua

(2nd Normal Form)
Bentuk normal 2NF terpenuhi dalam sebuah tabel

jika telah memenuhi bentuk 1NF, dan semua

atribut selain primary key, secara utuh memiliki
Functional Dependency pada primary key
Sebuah tabel tidak memenuhi 2NF, jika ada atribut
yang ketergantungannya (Functional Dependency)
hanya bersifat parsial saja (hanya tergantung pada
sebagian dari primary key)
Jika terdapat atribut yang tidak memiliki
ketergantungan terhadap primary key, maka atribut
tersebut harus dipindah atau dihilangkan

20/29

Contoh
Tabel berikut memenuhi 1NF tapi tidak termasuk 2NF:
NIM

Nama

Alamat

Mk_kode

mk_nama

mk_sks

nihuruf

Tidak memenuhi 2NF, karena {NIM, mk_kode} yang

dianggap sebagai primary key sedangkan:
{NIM, mk_kode} mhs_nama
{NIM, mk_kode}
mhs_alamat
{NIM, mk_kode}
mk_nama
{NIM, mk_kode} mk_sks
{NIM, mk_kode}
nihuruf

Tabel di atas perlu didekomposisi menjadi beberapa tabel

yang memenuhi syarat 2NF
21/29

Contoh
Functional
dependencynya
sbb:
{NIM, mk_kode}
nihuruf
(fd1)
NIM
(fd2)
Mk_kode
(fd3)

{mhs_nama, mhs_alamat}

{mk_nama, mk_sks}

fd1
(NIM, mk_kode, nihuruf)
Tabel Nilai
fd2
(NIM, mhs_nama, mhs_alamat) Tabel Mahasiswa
fd3 (mk_kode, mk_nama, mk_sks) Tabel MataKuliah

22/29

Bentuk Normal Tahap Ketiga (3rd

Normal Form /3NF)
Bentuk normal 3NF terpenuhi jika telah

memenuhi bentuk 2NF, dan jika tidak ada atribut

non primary key yang memiliki ketergantungan
terhadap atribut non primary key yang lainnya.

23/29

Contoh
Tabel berikut memenuhi 2NF, tapi tidak memenuhi 3NF:
Pegawai
NIP

Nama

Alm_Jalan

Alm_Kota

Alm_Provinsi Alm_Kodepos

karena masih terdapat atribut non primary key (yakni alm_kota

dan alm_Provinsi) yang memiliki ketergantungan terhadap atribut
non primary key yang lain (yakni alm_kodepos):

alm_kodepos {alm_Provinsi, alm_kota}

Sehingga Pegawai
tabel tersebut
perlu
didekomposisi
(NIP,
nama,
alm_jalan,menjadi:

alm_kodepos)
Kodepos (alm_kodepos, alm_provinsi,
alm_kota)
24/29