Anda di halaman 1dari 46

NORMALISASI

BAD DATABASE!!!

• Data yang sama disimpan di beberapa tempat.

• Ketidakmampuan untuk menghasilkan informasi tertentu.


• Lost data.
• Terjadi adanya redudansi data dan atau duplikasi data.
• Timbul adanya null value.
CONTOH 1:

Nama Kota Pembelian Harga

Santi Surabaya Gula 120

Rika Semarang Beras 200

Santi Surabaya Tepung 100

Dwi Jakarta Sabun 10


PERMASALAHAN CONTOH 1:

• Redundansi
• Data untuk nama, dan kota diulangi untuk tiap pembelian yang
dibuat
• Tempat yang terbuang percuma
• Proses update yang rumit, dapat menyebabkan inkonsistensi nilai
atribut, contohnya untuk atribut harga.
• Nilai null
• Tidak dapat menyimpan informasi tentang sebuah nama apabila
tidak ada pembelian.
• Dapat diselesaikan dengan penggunaan nilai null, tetapi nilai null
sulit ditangani.
CONTOH 2:

NIM KD MK BIAYA

94410200 TI-101 120

94410201 TI-104 100

94410202 TI-104 100

94410203 TI-102 110

94410204 TI-102 110

94410205 TI-105 115


PERMASALAHAN CONTOH 2:

• Biaya yang selalu berulang-ulang pada setiap


mahasiswa yang mengambilnya.
• Mudah terjadi anomalisasi.
PENDAHULUAN

• Normalisasi database biasanya jarang dilakukan dalam


database skala kecil, dan dianggap tidak diperlukan untuk
penggunaan personal. Namun seiring dengan perkembangan
informasi yang dikandung dalam sebuah database, proses
normalisasi sangat membantu dalam menghemat ruang yang
digunakan oleh setiap tabel didalamnya, sekaligus
mempercepat proses permintaan data.
• Normalisasi bisa disebut juga sebagai proses pengelompokan
atribut-atribut dari suatu relasi sehingga membentuk WELL
STRUCTURED RELATION.
• WELL STRUCTURED RELATION adalah sebuah relasi yang
jumlah kerangkapan datanya sedikit (Minimum Amount Of
Redundancy), serta memberikan kemungkinan bagi used
untuk melakukan INSERT, DELETE, MODIFY, terhadap
baris-baris data pada relasi tersebut, yang tidak berakibat
terjadinya ERROR atau INKONSISTENSI DATA, yang
disebabkan oleh operasi-operasi tersebut.
• Dalam merancang database, kita harus dapat menentukan
struktur logik yang tepat pada data yang sudah didapat.
• Semua relasi dalam database relasional selalu sudah
ternormalisasi, dalam arti bahwa semua relasi sudah
didefinisikan terhadap domain sederhana, yaitu domain yang
hanya bernilai atomik.
• Normalisasi diperlukan untuk menghilangkan / mengurangi
redudansi data.
PENGERTIAN

• Teknik yang digunakan untuk membantu mengidentifikasi


relasi-relasi dan batasan-batasan suatu representasi data secara
tepat.
• Proses pengelompokkan data ke dalam bentuk tabel untuk
menyatakan entitas dan hubungan mereka sehingga terwujud
satu bentuk database yang mudah dimodifikasi.
• Normalisasi adalah suatu teknik untuk mengorganisasi data ke
dalam tabel-tabel untuk memenuhi kebutuhan pemakai di
dalam suatu organisasi.
• Proses normalisasi akan sangat membantu dalam menghemat
ruang yang digunakan oleh setiap tabel di dalamnya, sekaligus
mempercepat proses permintaan data.
• 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.
TABEL UNIVERSAL

• Tabel Universal (Universal / Star Table)  sebuah tabel yang


merangkum semua kelompok data yang saling berhubungan,
bukan merupakan tabel yang baik.
• Contoh:
SEJARAH PERKEMBANGAN

• Diperkenalkan oleh EF Codd pada tahun 1972.


• Dilakukan untuk uji coba suatu relasi untuk menentukan
apakah relasi tersebut sudah baik.
TUJUAN

• Menghindari terjadinya error atau inkonsistensi data.


• Menghindari redudansi data.
• Menghemat ruang yang digunakan oleh setiap tabel di
dalamnya, sekaligus mempercepat proses permintaan data.
• Untuk mempermudah pemodifikasian data
ANOMALI

• Merupakan penyimpangan-penyimpangan atau error atau


inkonsistensi data yang terjadi pada saat dilakukan proses
delete, insert, ataupun modify dalam suatu basis data.
MACAM-MACAM ANOMALI

• Insertion Anomaly
• Merupakan error atau kesalahan yang terjadi sebagai akibat dari operasi
menyisipkan tuple/record pada sebuah relasi.
• Delete Anomaly
• Merupakan error atau kesalahan yang terjadi sebagai akibat dari operasi
penghapusan terhadap tuple/record pada sebuah relasi.
• Update Anomaly
• Merupakan error atau kesalahan yang terjadi sebagai akibat dari operasi
perubahan (update) tuple/record pada sebuah relasi.
CONTOH 1:

RELASI KULIAH

NIM Kd_MK Biaya


042100 M02 45
042120 M02 45
042122 M04 55
042135 M03 40

1. Insertion Anomaly
2. Delete Anomaly
3. Update Anomaly
PENYELESAIAN:

• Relasi kuliah harus di buat menjadi 2 tabel:


NIM Kd_MK
042100 M02
042120 M02
042122 M04
042135 M03

Kd_MK Biaya
M02 45
M02 45
M04 55
M03 40
CONTOH 2:
KETERGANTUNGAN FUNGSIONAL

• Definisi :
• Atribut Y pada relasi R dikatakan tergantung fungsional pada
atribut X (R.X ---> R.Y), jika dan hanya jika setiap nilai X
pada relasi R mempunyai tepat satu nilai Y pada R.
• Misal, terdapat skema database Pemasok-barang :
• Pemasok (No-pem, Na-pem)
• Tabel PEMASOK-BARANG

No_Pem Nm_Pem
P01 Bintang
P02 Sinar
P03 Baru

• Ketergantungan fungsional dari tabel PEMASOK-BARANG


adalah :
• No-pem ---> Na-pem
KETERGANTUNGAN FUNGSIONAL
PENUH
• Definisi :
• Atribut Y pada relasi R dikatakan tergantung fungsional penuh
pada atribut X pada relasi R, jika Y tidak tergantung pada
subset dari X ( bila X adalah key gabungan)
• Contoh :
• KIRIM-BARANG( No-pem, Na-pem, No-bar, Jumlah)
No_Pem Nm_Pem No_Brg Jumlah
P01 Bintang Br_01 1000
P01 Bintang Br_02 1500
P01 Bintang Br_03 2000
P02 Sinar Br_03 1000
P03 Baru Br_02 2000

Ketergantungan fungsional :
No-pem --> Nm-pem
No-bar, No-pem --> Jumlah (Tergantung penuh thd keynya)
KETERGANTUNGAN TRANSITIF

• Definisi :
• Atribut Z pada relasi R dikatakan tergantung transitif pada
atribut X , jika atribut Y tergantung pada atribut X pada relasi
R dan atribut Z tergantung pada atribut Y pada relasi R.
• (X Y, Y Z , maka X Z)
No-pem Kode-kota Kota No-bar Jumlah
P01 1 Jakarta B01 1000
P01 1 Jakarta B02 1500
P01 1 Jakarta B03 2000
P02 3 Bandung B03 1000
P03 2 Surabaya B02 2000

Ketergantungan transitif :
No-pem Kode-kota
Kode-kota Kota , maka No-pem Kota
LANGKAH-LANGKAH NORMALISASI

Bentuk normal pertama:


• Tidak ada set atribut yang berulang atau bernilai ganda.
• Telah ditentukannya primary key untuk tabel atau relasi.
• Tiap atribut hanya memiliki satu pengertian.
• Tiap atribut yang dapat memiiki banyak nilai sebenarnya
menggambarkan entitas atau relasi yang terpisah.
CONTOH
Misal data mahasiswa sbb:

Atau:

Tabel-tabel di atas tidak memenuhi syarat 1NF


SOLUSINYA:
Didekomposisi menjadi:
 Tabel Mahasiswa

 Tabel Hobi
ATAU

Mhs_nrp mhs_nama mhs_alamat mk_kode mk_nama mk_sks nihuruf

P01 Santi Sby M01 Mat 2 A

Sari Sby M04 Desain 2 A

P05 Cinta Sda Produksi 3 C

P06 Dewi Krian M05 Akuntansi 3 C

Ratih Sda M01 Mnjemen 3 C

Tabel-tabel di atas tidak memenuhi syarat 1NF


SOLUSINYA

SEMUA PRIMARY KEY TIDAK BOLEH DALAM KEADAAN


NULL VALUE

Mhs_nrp mhs_nama mhs_alamat mk_kode mk_nama mk_sks nihuruf

P01 Santi Sby M01 Mat 2 A

P02 Sari Sby M04 Desain 2 A

P05 Cinta Sda M02 Produksi 3 C

P06 Dewi Krian M05 Akuntansi 3 C

P07 Ratih Sda M007 Mnjemen 3 C


Bentuk normal kedua:
• Bentuk data telah memenuhi kriteria bentuk normal ke
satu.
• Atribut bukan kunci(non-key attribute) haruslah memiliki
ketergantungan fungsional sepenuhnya pada primary key.
• Jika terdapat atribut yang tidak memiliki ketergantungan
terhadap primary key, maka atribut tersebut harus
dipindah atau dihilangkan
CONTOH

Tabel berikut memenuhi 1NF tapi tidak termasuk 2NF:


mhs_nrp mhs_nama mhs_alamat mk_kode mk_nama mk_sks nihuruf

 Tidak memenuhi 2NF, karena {Mhs_nrp, mk_kode} yang


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

 Tabel di atas perlu didekomposisi menjadi beberapa tabel yang


memenuhi syarat 2NF
CONTOH

Functional dependencynya sbb:


{Mhs_nrp, mk_kode}  nihuruf (fd1)
Mhs_nrp  {mhs_nama, mhs_alamat}
(fd2)
Mk_kode  {mk_nama, mk_sks}
(fd3)

fd1 (mhs_nrp, mk_kode, nihuruf)  Tabel Nilai


fd2 (Mhs_nrp, mhs_nama, mhs_alamat)  Tabel Mahasiswa
fd3 (mk_kode, mk_nama, mk_sks)  Tabel MataKuliah
NILAI
mhs_nrp mk_kode nihuruf

MAHASISWA
mhs_nrp mhs_nama mhs_alamat

MATAKULIAH
mk_kode mk_nama mk_sks
Bentuk Normal Ketiga:
• Bentuk data telah memenuhi kriteria bentuk normal ke dua.
• Atribut bukan kunci(non-key attribute) tidak boleh memiliki
ketergantungan fungsional terhadap atribut bukan kunci
lainnya. Seluruh atribut bukan kunci pada suatu relasi hanya
memiliki ketergantungan fungsional terhadap primary key
di relasi itu saja.
CONTOH

Tabel berikut memenuhi 2NF, tapi tidak memenuhi 3NF:


Mahasiswa
Nrp 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 tabel tersebut (Nrp,
Mahasiswa perlu didekomposisi menjadi:
nama, alm_jalan,
alm_kodepos)
Kodepos (alm_kodepos, alm_provinsi,
alm_kota)
BOYCE-CODE NORMAL FORM (BCNF)

• Bentuk BCNF terpenuhi dalam sebuah tabel, jika untuk setiap


functional dependency terhadap setiap atribut atau gabungan
atribut dalam bentuk: X  Y maka X adalah super key
• tabel tersebut harus di-dekomposisi berdasarkan functional
dependency yang ada, sehingga X menjadi super key dari
tabel-tabel hasil dekomposisi
• Setiap tabel dalam BCNF merupakan 3NF. Akan tetapi setiap
3NF belum tentu termasuk BCNF . Perbedaannya, untuk
functional dependency X  A, BCNF tidak membolehkan A
sebagai bagian dari primary key.
BENTUK NORMAL TAHAP KEEMPAT
(4TH NORMAL FORM /4NF)
• Bentuk normal 4NF terpenuhi dalam sebuah tabel jika telah
memenuhi bentuk BCNF, dan tabel tersebut tidak boleh
memiliki lebih dari sebuah multivalued atribute
• Untuk setiap multivalued dependencies (MVD) juga harus
merupakan functional dependencies.
CONTOH

Misal, tabel berikut tidak memenuhi 4NF:

Setiap employee dapat bekerja di lebih dari project dan dapat


memiliki lebih dari satu skill. Untuk kasus seperti ini tabel tersebut
harus di-dekomposisi menjadi:
(Employee, Project)
(Employee, Skill)
BENTUK NORMAL TAHAP KELIMA (5TH
NORMAL FORM /5NF)
• Bentuk normal 5NF terpenuhi jika tidak dapat memiliki
sebuah lossless decomposition menjadi tabel-tabel yg lebih
kecil.
• Jika 4 bentuk normal sebelumnya dibentuk berdasarkan
functional dependency, 5NF dibentuk berdasarkan konsep join
dependence. Yakni apabila sebuah tabel telah di-dekomposisi
menjadi tabel-tabel lebih kecil, harus bisa digabungkan lagi
(join) untuk membentuk tabel semula.
LATIHAN:

Diberikan tabel Mahasiswa di bawah ini, akan dilakukan


normalisasi sampai bentuk normal ke tiga
Nm_Mhs NIM Tgl_Lahir Kd_MKul Kuliah SKS Nilai Bobot

Jack 32900 17/05/84 TI02 Mat Dasar 3 A 4

Jack 32900 17/05/84 TI04 Database 3 A 4

Rank 32912 17/04/85 TI01 Fisika 3 B 3

Jenny 32918 23/06/84 TI01 Fisika 3 C 2

Jenny 32918 23/06/84 TI10 Agama 3 A 4

Bentuk normal 1 (1NF)


• Tabel di atas sudah dalam bentuk normal
ke Satu(1NF)

MENGAPA ????

Karena:
1. Tidak ada data yang berulang
2. Setiap domain terisi dengan data (tidak ada domain
yang kosong).
Bentuk normal 2 (2NF)
Belum memenuhi kriteria 3NF,
Karena atribut non-key Nilai dan
Bobot masih memiliki ketergantu-
ngan fungsional.

Anda mungkin juga menyukai