PRAKTIKUM BASIS DATA

2022
NORMALISASI DATABASE

Oleh :

Muhammad Raihan 21060120140121

DEPARTEMEN S1 TEKNIK ELEKTRO

FAKULTAS TEKNIK
UNIVERSITAS DIPONEGORO
2022
 PERCOBAAN 6
NORMALISASI DATABASE

I. Tujuan Percobaan
Peserta praktikum dapat memahami cara menormalisasi database.
II. Dasar Teori
2.1 Pengertian Normalisasi
Normalisasi database biasanya jarang dilakukan dalam database skala
kecil, dan dianggap tidak diperlukan pada penggunaan personal. Tujuan
utama normalisasi adalah mengelompokkan atribut ke dalam relasi sehingga
data gandanya minimal. Konsep normalisasi dikemukakan pertama kali oleh
Codd (1970) dengan memperkenalkan 1NF (first normal form ‘bentuk
normal pertama’), dilanjutkan dengan 2NF dan 3NF pada tahun 1971.
Bersama Raymond F. Boyce, Codd (1974) mendefinisikan BCNF (Boyce-
Codd normal form ‘bentuk normal Boyce-Codd’). Fagin (1977)
memperkenalkan 4NF (fourth normal form ‘bentuk normal keempat’)
dilanjutkan dengan 5NF (fifth normal form ‘bentuk normal kelima’) pada
tahun 1979. Date, Darwen, dan Lorentzos (2002) mendefinisikan 6NF (sixth
normal form ‘bentuk normal keenam’).

Dalam praktik, proses normalisasi sampai 3NF sudah cukup baik

mengurangi data ganda. Relasi yang memenuhi 3NF, dalam banyak kasus,
biasanya sudah memenuhi BCNF dan bentuk normal yang lebih tinggi.
Menurut Coronel dan Morris (2019), beberapa kasus yang sangat khusus,
seperti penelitian statistik, mungkin memerlukan normalisasi 4NF atau yang
lebih tinggi. Bentuk normal yang lebih tinggi biasanya meningkatkan
operasi join yang memperlambat kinerja tanpa ada nilai tambah apa pun
dalam mengurangi data ganda.
2.2 Data Ganda dan Anomali Update
Sebagaimana telah disinggung sebelumnya, selain boros ruang
penyimpanan, adanya data ganda menimbulkan tiga anomali update yaitu
(1) anomali penambahan, (2) anomali penghapusan, dan (3) anomali
modifikasi.
 Sebagai contoh, lihat Gambar 1. Relasi PegawaiCabang belum normal
karena ada pengulangan data yang sama pada tiga atribut terakhir, yaitu
atribut NomorCabang, AlamatCabang, dan TeleponCabang. Setelah
dinormalisasi, diperoleh relasi Pegawai dan relasi Cabang. Keduanya bebas
dari masalah anomali update karena tidak ada data ganda.

Gambar 6.1 Relasi belum dinormalisasi (PegawaiCabang)

versus relasi yang sudah dinormalisasi (Pegawai dan Cabang)

a. Anomali Penambahan
Anomali penambahan terjadi ketika ada data baru ditambahkan ke
dalam sebuah relasi. Lihat relasi PegawaiCabang pada Gambar 1(a). Bila
ada pegawai baru yang ditempatkan di Cabang C01, maka ke dalam relasi
PegawaiCabang, selain data pegawai (NIP, Nama, Alamat), data detail
cabang C01 (NomorCabang, AlamatCabang, Telepon Cabang) juga harus
dimasukkan dengan risiko terjadi ketidakkonsistenan data. Sebaliknya, pada
relasi Pegawai pada Gambar 1(b), cukup dimasukkan data pegawai dan
nomor cabang C01 tempat ia bekerja tanpa harus memasukkan detail
 cabang.

Bila ada cabang baru yang belum ada pegawainya, maka ke dalam
relasi PegawaiCabang, data detail cabang baru (NomorCabang,
AlamatCabang, TeleponCabang) dimasukkan dengan atribut pegawai (NIP,
Nama, Alamat) dikosongkan. Hal ini tak mungkin dilakukan karena NIP
sebagai primary key tidak boleh kosong. Berarti data cabang baru tak dapat
ditambahkan. Sebaliknya, pada relasi Cabang pada Gambar 1(c), detail
cabang baru dapat ditambahkan tanpa masalah.
b. Anomali Penghapusan
Anomali penghapusan terjadi ketika ada data yang dihapus. Lihat
relasi PegawaiCabang pada Gambar 1(a). Bila pegawai dengan NIP 19009
dihapus, maka data detail cabang C03 pada relasi PegawaiCabang juga ikut
terhapus. Sebaliknya, penghapusan pegawai dengan NIP 19009 pada relasi
Pegawai pada Gambar 1(b) tidak mengakibatkan hilangnya data detail
cabang C03.
c. Anomali Modifikasi
Anomali modifikasi terjadi ketika ada data yang diubah. Lihat relasi
PegawaiCabang pada Gambar 1(a). Misalkan cabang C03 pindah alamat dan
nomor teleponnya pun berubah. Pada relasi PegawaiCabang, modifikasi data
harus dilakukan secara berulang ke seluruh data cabang C03 yang ada. Hal
ini dapat menimbulkan ketidakkonsistenan data. Sebaliknya, modifikasi data
pada relasi Cabang pada Gambar 1(c) cukup dilakukan sekali.
2.3 Jenis-Jenis Ketergantungan
a. Ketergantungan Fungsional

Jika A dan B adalah atribut relasi R, maka B dinyatakan memiliki ketergantungan fun

Determinan ketergantungan fungsional adalah atribut atau sekum-

pulan atribut yang ada pada sisi kiri anak panah.
 b. Ketergantungan fungsional penuh
Bila A dan B adalah atribut sebuah relasi, maka B dinyatakan
memiliki ketergantungan fungsional penuh pada A jika B bergantung
fungsional pada A secara keseluruhan dan bukan pada sebagian dari A. A
adalah primary key atribut tunggal atau primary key komposit yang
merupakan gabungan dari beberapa atribut.

c. Ketergantungan Transitif

Misal A, B, C adalah atribut sebuah relasi. Jika A B dan B C, maka dikatakan C mem

2.4 Proses Normalisasi

Sebagai contoh kasus proses normalisasi, lihat contoh faktur belanja
pada Gambar 2. Tabel pada Gambar 3 yang berisi data faktur belanja
merupakan tabel yang belum normal (UNF, unnormalized form) karena
belum memenuhi karakteristik sebuah relasi. Salah satu karakteristiknya
menyatakan bahwa setiap sel — yakni perpotongan baris dan kolom —
harus bernilai tunggal. Sel pada kolom JumlahBarang, Satuan, KodeBarang,
NamaBarang, HargaSatuan, JumlahHarga memiliki dua nilai.

Gambar 6.2 Faktur belanja

 Gambar 6.3 Tabel UNF (unnormalized form ‘bentuk tidak normal’)

Gambar 6.4 Relasi 1NF (first normal form ‘bentuk normal pertama’)

a. 1NF (First Normal Form ‘Bentuk Normal Pertama’)

Relasi yang memenuhi 1NF adalah relasi yang setiap perpotongan
baris dan kolomnya berisi satu dan hanya satu nilai. Supaya bernilai tunggal,
tabel UNF pada Gambar 3 dimodifikasi dengan memisahkan nilai sel yang
tidak tunggal ke baris baru sehingga diperoleh relasi seperti pada Gambar 4.
Perhatikan bahwa setiap perpotongan baris dan kolomnya berisi satu dan
hanya satu nilai. Ini berarti relasi tersebut telah memenuhi syarat 1NF.
Dengan demikian, dari faktur belanja diperoleh sebuah relasi 1NF yang
skema relasinya sebagai berikut:
FakturBelanja (Tgl,Nama, Alamat, NoHP, NoFaktur, Jumlah,
Satuan, KodeBarang, NamaBarang, HargaSatuan, Jumlah Harga, Total).
Dua atribut terakhir adalah atribut turunan dan boleh diabaikan (boleh tidak
disimpan dalam basis data). Skema relasinya menjadi sebagai berikut:
FakturBelanja (Tgl, Nama, Alamat, NoTelepon, NoFaktur, Jumlah, Satuan,
KodeBarang, NamaBarang, HargaSatuan)

b. 2NF (Second Normal Form ‘Bentuk Normal Kedua’)

Relasi 2NF adalah relasi yang memenuhi 1NF dan setiap atribut bukan
primary key memiliki ketergantungan fungsional penuh pada primary key.
Jadi, ada dua hal yang berkaitan dengan relasi 2NF, yaitu primary key dan
ketergantungan fungsional.
 Nama mahasiswa memiliki ketergantungan fungsional pada NIM, NIMNama, karena un

Karena persyaratan relasi 2NF berkaitan dengan primary key, maka

harus ditentukan terlebih dahulu primary key relasi 1NF. Tidak satu pun
atribut tunggal memenuhi syarat sebagai primary key. Oleh karena itu,
diambil gabungan dua atribut yaitu NoFaktur + KodeBarang sebagai
primary key komposit sehingga skema relasinya menjadi:
FakturBelanja (NoFaktur, KodeBarang, Tgl, Nama, Alamat,
NoTelepon, Jumlah, Satuan, NamaBarang, HargaSatuan)
Selanjutnya, setiap atribut bukan primary key dicek apakah memiliki
ketergantungan fungsional penuh pada keseluruhan atribut primary key atau
hanya pada sebagian primary key (parsial).
Lihat Gambar 6.5. Ada dua kelompok atribut yang memiliki ketergan-
tungan fungsional pada sebagian primary key (ketergantungan parsial).
Pertama, atribut Satuan, NamaBarang, memiliki ketergantungan fungsional
hanya pada KodeBarang; kedua, atribut Tgl, Nama, Alamat, dan NoHP
memiliki ketergantungan fungsional hanya pada NoFaktur. Ini berarti relasi
FakturBelanja memang belum memenuhi 2NF.

Gambar 6.5 Diagram ketergantungan fungsional pada relasi 1NF FakturBelanja

 Gambar 6.6 Relasi 2NF
Kelompok atribut yang memiliki ketergantungan fungsional parsial
dipisahkan ke dalam relasi berbeda sehingga dari relasi 1NF FakturBelanja
diperoleh tiga buah relasi 2NF yaitu Barang, FakturPelanggan dan
DetailFaktur. Lihat Gambar 6. Semua atribut yang bukan primary key pada
ketiga relasi memiliki ketergantungan fungsional penuh pada primary key.
c. 3NF (Third Normal Form ‘Bentuk Normal Ketiga’)
Relasi 3NF adalah relasi yang memenuhi 1NF, 2NF dan atribut yang
bukan primary key tidak memiliki ketergantungan transitif pada primary
key.
Atribut bukan primary key setiap relasi 2NF harus dicek apakah
memiliki ketergantungan transitif. Lihat Gambar 6. Skema ketiga relasi
adalah sebagai berikut.
Barang (KodeBarang, Satuan, NamaBarang)
DetailFaktur (KodeBarang, NoFaktur, Jumlah, HargaSatuan)
FakturPelanggan (NoFaktur, Tgl, Nama, Alamat, NoHP)
Pada relasi Barang, tidak ada ketergantungan antara atribut Satuan
dengan NamaBarang. Begitu pula pada relasi DetailFaktur, tidak ada
ketergantungan antara atribut Jumlah dengan HargaSatuan. Ini berarti
keduanya sudah memenuhi 3NF karena tidak memiliki ketergantungan
transitif. Pada relasi FakturPelanggan, atribut NoHP bernilai unik, ada
ketergantungan transitif Nama dan Alamat pada NoFaktur melalui NoHP
sebagai berikut:
NoFaktur NoHP
NoHP Nama, Alamat
 Dengan demikian, relasi FakturPelanggan belum memenuhi 3NF.
Lihat Gambar 7.

Gambar 6.7 Ketergantungan transitif

Gambar 6.8 Relasi 3NF

Selanjutnya, kelompok atribut yang memiliki ketergantungan transitif

dipisahkan ke dalam relasi berbeda sehingga dari relasi 2NF
FakturPelanggan diperoleh dua buah relasi 3NF yaitu relasi Faktur dan relasi
Pelanggan. Lihat Gambar 6.8.

Gambar 6.9 Hasil normalisasi sampai dengan 3NF

Jadi, hasil akhir proses normalisasi data faktur belanja adalah empat
buah relasi 3NF yaitu relasi Pelanggan, Faktur, DetailFaktur dan Barang.
Lihat Gambar 9. Keterkaitan antar relasi dapat dilihat dari atribut foreign
key yang digarisbawahi dengan garis terputus-putus merujuk ke
atribut primary key yang digarisbawahi dengan garis menerus.
III. Alat dan Bahan

1. Modul praktikum

2. Laptop

3. Database Server XAMPP

IV. Langkah Percobaan

1. Membuat database baru dan buat tabel faktur belanja dan masukkan data pada
tabel tabel faktur belanja

2. Buatlah tabel first normal form

3. Buatlah tabel second normal form

4. Relasikan antar tabel detail faktur belanja terhadap dua tabel lainnya
5. Buatlah third normal form dari tabel faktur belanja
V. Data Percobaan
Tabel 6.1 Data Percobaan

No. Data Percobaan

1. Query Membuat Database Normalisasi

Hasil

Membuat tabel FakturBelanja_1nf dan menetapkan Primary Key

Query
dan Foreign Key (1NF)

2.
Hasil

Membuat tabel Barang, DetailFaktur, FakturPelanggan_2nf dan

Query
menetapkan Primary Key dan Foreign Key (2NF)

3.
Hasil Tabel Barang
Tabel DetailFaktur
Tabel FakturPelanggan_2nf
 Query Relasikan antar dua tabel pada 2NF

4.
Hasil

5. Membuat tabel Faktur dan Pelanggan dan menetapkan Primary

Query
Key dan Foreign Key (3NF)
Hasil Tabel Faktur
 Tabel Pelanggan

Query Membuat relasi antar tabel 3NF

5.
Hasil
VI. Analisa dan Pembahasan
Normalisasi Database adalah proses pengelompokan atribut data yang
membentuk entitas sederhana, nonredundant, fleksibel, dan mudah
beradaptasi. Sehingga dapat dipastikan bahwa database yang dibuat
berkualitas baik.
Normalisasi digunakan terutama untuk dua tujuan,
• Menghilangkan dan mengurangi redudansi data.
• Memastikan ketergantungan data masuk akal yaitu data disimpan secara
logis.

6.1. Bentuk Normal Pertama (1NF)

Bentuk Normal Pertama mengharapkan untuk mendesain tabel
sedemikian rupa sehingga dapat dengan mudah diperpanjang dan lebih
mudah untuk mengambil data darinya kapan pun diperlukan.
Terdapat 4 aturan agar tabel berada dalam Bentuk Normal Pertama,
yaitu:
• Tabel seharusnya hanya memiliki atribut / kolom bernilai tunggal.
• Nilai yang disimpan dalam kolom harus bertipe data yang sama.
• Semua kolom dalam tabel harus memiliki nama yang unik.
• Urutan penyimpanan data, tidak menjadi masalah.

Gambar 6.10 Atribut Tabel FakturBelanja_1nf

 Terlihat pada Gambar 6.10, yaitu tabel FakturBelanja_1nf diatas
memiliki nilai pada kolom yang bersifat tunggal, nilai yang disimpan dengan
tipe data yang sama, semua kolom dalam tabel memiliki nama yang unik,
dan urutan penyimpanan data tidak menjadi masalah, yang artinya database
sudah berada pada bentuk normal pertama.

6.2. Bentuk Normal Kedua (2NF)

Syarat 2NF adalah tidak diperkenankan adanya “functional
dependency” kepada primary key dalam sebuah tabel. Functional
dependency adalah setiap atribut yang bukan kunci (non key) bergantung
secara fungsional terhadap primary key. Maka dari itu pada bentuk normal
kedua ini akan dipisahkan atribut berdasarkan primary key yang ada pada
tabel 1NF sebelumnya. Berdasarkan gambar 6.10 tidak satu pun atribut
tunggal memenuhi syarat sebagai primary key. Jadi, diambil gabungan dua
atribut yaitu NoFaktur dan KodeBarang sebagai primary key komposit.

Pada tabel FakturBelanja_1nf, terdapat functional dependecy sehingga

harus dipecah menjadi tabel tabel seperti pada gambar 6.11, 6.12, dan 6.13
sebagai berikut.

Gambar 6.11 Atribut Tabel barang

Pada Gambar 6.11, terdapat 3 buah atribut yaitu KodeBarang, Satuan,
dan NamaBarang. Di tabel ini, atribut yang menjadi primary key adalah
KodeBarang karena atribut ini mempunyai nilai yang unik sehingga tidak
ada nilai duplikat.
 Gambar 6.12 Atribut Tabel detailfaktur
Pada Gambar 6.12, terdapat 4 buah atribut yaitu KodeBarang,
NoFaktur, JmlBarang, dan HargaSatuan. Di tabel ini, terdapat primary key
komposit yaitu KodeBarang dan NoFaktur.

Gambar 6.13 Atribut Tabel fakturpelanggan_2NF

Pada Gambar 6.13, terdapat 5 buah atribut yaitu NoFaktur, Tgl, Nama,
Alamat, dan NoHp. Di tabel ini, atribut yang menjadi primary key adalah
NoFaktur karena atribut ini mempunyai nilai yang unik sehingga tidak ada
nilai duplikat.

Berdasarkan gambar 6.10, tabel yang awalnya hanya ada 1 pada

bentuk 1NF harus dipisahkan pada bentuk 2NF karena terdapat kelompok
 atribut yang memiliki ketergantungan fungsional parsial. Semua atribut yang
bukan primary key pada ketiga relasi memiliki ketergantungan fungsional
penuh pada primary key.

Gambar 6.14 Relasi setiap tabel pada bentuk 2NF

Berdasarkan gambar 6.14 didapatkan relasi tiap tabel yaitu pada tabel
detailfaktur terdapat primary key komposit yaitu NoFaktur dan juga
KodeBarang yang terhubung pada kedua tabel yaitu NoFaktur akan menjadi
foreign key pada tabel fakturpelanggan_2nf dan KodeBarang pada tabel
barang.

6.3. Bentuk Normal Ketiga (3NF)

Pada bentuk normal ketiga tidak diperkenankan adanya partial
transitive dependency dalam sebuah tabel. Transitive dependency biasanya
terjadi pada tabel hasil relasi, atau kondisi dimana terdapat tiga atribut A, B,
C. Kondisinya adalah A ⇒ B dan B ⇒ C. Maka C dikatakan sebagai
transitive dependency terhadap A melalui B. Intinya pada 3NF, jika terdapat
suatu atribut yang tidak bergantung pada primary key tapi bergantung pada
field yang lain maka atribut-atribut tersebut perlu dipisah ke tabel baru.
Seperti tabel fakturpelanggan_2nf pada gambar 6.14 atribut NoHP bernilai
unik, ada ketergantungan transitif Nama dan Alamat pada NoFaktur melalui
NoHP. Oleh karena itu, relasi fakturpelanggan_2nf belum memenuhi 3NF
sehingga dipisah dan diperoleh dua buah tabel yaitu tabel faktur dan
pelanggan. Tabel faktur berelasi dengan tabel detailfaktur dengan atribut
NoFaktur sebagai foreign key. Tabel pelanggan berelasi dengan tabel faktur
dengan atribut NoHp sebagai foreign key. Kedua tabel dapat dilihat pada
gambar 6.16 dan 6.17 di bawah ini.

Gambar 6.15 Atribut Tabel faktur

Pada Gambar 6.15, terdapat 3 buah atribut yaitu NoFaktur, Tgl, dan
NoHp. Di tabel ini, atribut yang menjadi primary key adalah NoFaktur.

Gambar 6.16 Atribut Tabel pelanggan

Pada Gambar 6.16, terdapat 3 buah atribut yaitu NoHp, Nama, dan
Alamat. Di tabel ini, atribut yang menjadi primary key adalah NoHp.

Sehingga didapatkan hasil akhir proses normalisasi data faktur belanja

adalah empat buah tabel 3NF yaitu tabel pelanggan, faktur, barang dan
detailfaktur.
 Relasi tabel pelanggan ke tabel faktur merupakan relasi One-to-Many
karena satu baris di tabel pelanggan dapat memiliki relasi di beberapa baris
di tabel faktur (satu baris NoHp dapat memiliki lebih dari satu NoFaktur).

Relasi tabel faktur ke tabel detailfaktur merupakan relasi One-to-

Many karena satu baris di tabel faktur dapat memiliki relasi di beberapa
baris di tabel detailfaktur (satu baris NoFaktur dapat memiliki lebih dari satu
KodeBarang).

Relasi tabel detailfaktur ke tabel barang merupakan relasi One-to-One

karena satu baris tabel detailfaktur hanya berhubungan dengan satu baris
tabel barang (atribut KodeBarang). Relasi Dapat dilihat pada Gambar 6.17

Gambar 6.17 Relasi setiap tabel pada bentuk 3NF

IX. Kesimpulan
1. Normalisasi database adalah cara untuk menghilangkan redudansi atau
pengulangan data, serta keterkaitan antar atribut yang tidak diinginkan.
2. Normalisasi database bertujuan untuk menghindari kesalahan edit data
saat user melakukan update, delete, insertion, dan query editing lainnya.
3. Pengaturan relasional pada tabel bertujuan agar pengisian suatu tabel
dapat selalu mengacu pada tabel yang lain sehingga sangat mengurangi
kesalahan pengisian pada database yang dibuat.
4. Tanda suatu tabel dikatakan 1NF adalah jika data yang disimpan pada
setiap atribut/kolom hanya memiliki nilai tunggal dalam satu baris.
5. Pada data percobaan diatas, setelah dilakukan normalisasi 1NF,
didapatkan satu tabel yang memiliki 10 atribut, yaitu Tgl, Nama,
Alamat, NoTelepon, NoFaktur, Jumlah, Satuan, KodeBarang,
NamaBarang, HargaSatuan.
6. Tanda suatu tabel dikatakan 2NF adalah jika pada setiap tabel tidak
ditemukan adanya partial “functional dependency” kepada primary key
dalam sebuah tabel.
7. Pada data percobaan diatas, setelah dilakukan normalisasi 2NF,
didapatkan 3 tabel, yaitu tabel barang, faktur, dan fakturpelanggan.
Tabel barang memiliki 3 atribut, yaitu KodeBarang, Satuan, dan
NamaBarang dengan KodeBarang sebagai Primary Key. Tabel
detailfaktur memiliki 4 atribut, yaitu KodeBarang, NoFaktur,
JmlBarang, dan HargaSatuan dengan KodeBarang dan NoFaktur
sebagai primary key komposit. Tabel fakturpelanggan_2nf memiliki 5
atribut, yaitu NoFaktur, Tgl, Nama, Alamat, dan NoHp dengan
NoFaktur sebagai primary key.
8. Tanda suatu tabel dikatakan 3NF adalah jika pada setiap tabel tidak
ditemukan adanya partial “transitive dependency” dalam sebuah tabel.
9. Pada data percobaan diatas, setelah dilakukan normalisasi 2NF,
didapatkan 4 tabel, yaitu tabel barang, detailfaktur, dan
fakturpelanggan. Tabel faktur memiliki 3 atribut, yaitu NoFaktur, Tgl,
dan NoHp dengan NoFaktur sebagai primary key. Tabel pelanggan
memiliki 3 atribut, yaitu NoHp, Nama, dan Alamat dengan NoHp
sebagai primary key.