SISTEM BASIS DATA

Macam-macam Anomaly
Normalisasi

Definisi Normalisasi

Normalisasi merupakan sebuah teknik

dalam logical desain sebuah basis data
yang mengelompokkan atribut dari
suatu relasi sehingga membentuk
struktur relasi yang baik (tanpa
redudansi).
Normalisasi adalah proses pembentukan
struktur basis data sehingga sebagian
besar ambiguity bisa dihilangkan

Tujuan Normalisasi

Untuk menghilang kerangkapan data

Untuk mengurangi kompleksitas
Untuk mempermudah pemodifikasian
data

Proses Normalisasi

Data diuraikan dalam bentuk tabel,

selanjutnya dianalisis berdasarkan
persyaratan tertentu ke beberapa
tingkat.
Apabila tabel yang diuji belum
memenuhi persyaratan tertentu, maka
tabel tersebut perlu dipecah menjadi
beberapa tabel yang lebih sederhana
sampai memenuhi bentuk yang optimal.

Macam-macam Penyimpangan
(Anomaly)

Macam-macam Anomaly :
a. Insertion Anomaly
b. Deletion Anomaly
c. Update Anomaly
Di bawah ini terdapat tabel resep :
No_Pasien

Kode_Obat

Harga_Obat

P001

Kd01

2000

P002

Kd02

4500

P003

Kd01

2000

a. Insertion Anomaly

Error atau kesalahan yang terjadi

sebagai akibat operasi menyisipkan
tuple/record pada sebuah relasi.
Contoh : Jika ada obat baru yang akan
dimasukkan/disisipkan, maka obat
tersebut tidak dapat disisipkan ke dalam
relasi sampai ada pasien yang
mengambil jenis obat tersebut.

b. Deletion Anomaly

Error atau kesalahan yang terjadi

sebagai akibat operasi penghapusan
terhadap tuple/record dari sebuah relasi.
Contoh: Jika pasien yang memiliki
No_Pasien P001 membatalkan tidak jadi
menebus resep obat tersebut, maka jika
record tersebut dihapus akan
menyebabkan hilangnya informasi
tentang Kode_Obat Kd01.

c. Update Anomaly

Yaitu error atau kesalahan yang terjadi

sebagai akibat operasi perubahan
tuple/record dari sebuah relasi.
Contoh: Jika harga obat untuk kode_obat
Kd01 dinaikkan menjadi 5000, maka
harus dilakukan beberapa kali modifikasi
terhadap record-record pasien yang
menebus kode_obat Kd01, agar data
selalu tetap konsisten.

Dependency / Ketergantungan

Merupakan konsep yang mendasari

normalisasi. Dependensi menjelaskan
hubungan antar atribut, atau secara
lebih khusus menjelaskan nilai suatu
atribut yang menentukan nilai atribut
lainnya.

Jenis-Jenis Ketergantungan
Jenis-jenis ketergantungan :
a. Ketergantungan Fungsional (Functional
Dependence)
b. Ketergantungan Fungsional Penuh (Fully
Functional Dependent)
c. Ketergantungan Transitif
d. Ketergantungan Parsial
e. Ketergantungan Determinan

a. Ketergantungan Fungsional
(Functional Dependence)

Suatu atribut Y mempunyai

ketergantungan fungsi terhadap atribut
X, jika dan hanya jika setiap nilai X
berhubungan dengan sebuah nilai Y.
Definisi diatas dituangkan dalam
bentuk notasi
X Y
Dibaca : X secara fungsional
menentukan Y

Contoh
Terdapat relasi PESANAN_JUAL yang
dinotasikan dengan :
PESANAN_JUAL
(PEMBELI,
KOTA,
BARANG, JUMLAH)
Yang
artinya
bahwa
relasi
PESANAN_JUAL mengandung atribut
PEMBELI, KOTA, BARANG dan JUMLAH.

PEMBELI

KOTA

BARANG

JUMLAH

P1

Yogya

B1

10

P1

Yogya

B2

P2

Solo

B1

P2

Solo

B2

P2

Solo

B3

P3

Klaten

B3

P3

Klaten

B4

Pada contoh ini, PEMBELI secara fungsional

menentukan KOTA, sebab terlihat bahwa
untuk PEMBELI yang sama, KOTA-nya juga
sama.
Dengan demikian:
PEMBELI KOTA

contoh lain:
{Pembeli, Barang} Jumlah
{Pembeli, Barang} Kota
{Pembeli, Barang} {Jumlah, Kota}

Bagian yang terletak di sebelah kiri panah

biasa disebut penentu (determinan) dan
yang di sebelah kanan panah disebut
yang tergantung (dependen).
Tanda { } biasa digunakan kalau ada
lebih dari satu atribut, baik pada penentu
maupun yang tergantung

b. Ketergantungan Fungsional
Penuh (Fully Functional
Dependent)

Suatu atribut Y mempunyai

ketergantungan fungsional penuh
terhadap atribut X, jika

Y
mempunyai
dependensi
fungsional
terhadap X
Y tidak memiliki dependensi terhadap
bagian dari X
Notasi : X Y

contoh , terdapat relasi pelanggan:

Pelanggan ( KODE_PELANGGAN, NAMA, KOTA, NOMOR_FAX )
Pada relasi ini:
1. {KODE_PELANGGAN, KOTA} NOMOR_FAX
2. KODE_PELANGGAN NOMOR_FAX
KET:
Mengingat
bahwa
Nomor_Fax
bergantung
pada
{KODE_PELANGGAN, KOTA} (kondisi 1) dan bergantung pada
KODE_PELANGGAN (Kondisi 2) yang tidak lain adalah bagian
dari {KODE_PELANGGAN, KOTA}, maka Nomor_Fax hanya
mempunyai dependenci fungsional sepenuhnya terhadap
KODE_PELANGGAN

c. Ketergantungan transitif

Atribut Z mempunyai dependensi transitif

terhadap X bila:
Y memiliki dependensi fungsional
terhadap X
Z memiliki dependensi fungsional terhadap
Y
X YZ

NIP

Nama

Gol_gaji

Gaji_pokok

0001

Ian

III A

600000

0002

Saputra

III B

650000

0003

Rohim

III A

600000

0004

Fani

III B

650000

Gol_gaji fungsional dependency pada NIP dan

Gaji_pokok Fungsional Dependency pada Gol_gaji.
NIP sebagai X, Gol_gaji sebagai Y, dan Gaji_pokok
sebagai Z
Jadi nilai-nilai rinci data pada atribut Gaji_pokok (Z)
bergantung transitif terhadap NIP

XYZ
NIP Gol_gaji Gaji_pokok

d. Ketergantungan Determinan

Yaitu suatu atribut atau

gabungan atribut dimana
beberapa atribut lain
bergantung pada atribut
tersebut.

Tahapan Normalisasi

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 tabeltabel yang berkualitas baik.
Urutan: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF

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-Codd Normal Form (BCNF) (akan dijelaskan kemudian-)

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)

Normal Pertama (1st Normal

Form)

Aturan :
Tidak adanya atribut multi-value,
atribut komposit atau kombinasinya.
Mendefinisikan atribut kunci.
Setiap atribut dalam tabel tersebut
harus bernilai atomic (tidak dapat dibagibagi lagi)

Contoh 1 (atribut multivalue)

Misal data mahasiswa sbb:

Atau:

Tabel-tabel di atas tidak memenuhi syarat

1NF

Contoh 1 (samb)
Didekomposisi menjadi:

Tabel
Mahasiswa

Tabel Hobi

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 basis data, maka atribut
Jadwal perlu dipisah sehingga menjadi JadwalHari
dan JadwalJam sbb:

JadwalKulia
h
Kodekul NamaKul

Dosen

Kelas

JadwalHari

JadwalJam

Normalisasi Kedua (2nd Normal

Form)

Aturan :
Sudah memenuhi dalam bentuk normal
kesatu (1NF)
Semua atribut bukan kunci hanya boleh
tergantung (functional dependency) pada atribut
kunci
Jika ada ketergantungan parsial maka atribut
tersebut harus dipisah pada tabel yang lain
Perlu ada tabel penghubung ataupun kehadiran
foreign key bagi atribut-atribut yang telah dipisah
tadi

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 (samb)
Functional dependencynya sbb:
{Mhs_nrp, mk_kode} nihuruf
(fd1)
Mhs_nrp
{mhs_nama, mhs_alamat}
(fd2)
fd1Mk_kode
(mhs_nrp, mk_kode,
nihuruf) mk_sks} Tabel
{mk_nama,
(fd3)
Nilai
fd2 (Mhs_nrp, mhs_nama, mhs_alamat)
Tabel
Mahasiswa
fd3 (mk_kode, mk_nama, mk_sks)
Tabel
MataKuliah

Normalisasi Ketiga (3rd Normal

Form)

Aturan :

Sudah berada dalam bentuk

normal
kedua (2NF)
Tidak ada ketergantungan transitif
(dimana atribut bukan kunci
tergantung
pada atribut bukan kunci lainnya).

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 perlu didekomposisi menjadi:

Mahasiswa (Nrp, nama, alm_jalan,

alm_kodepos)
Kodepos (alm_kodepos, alm_provinsi,
alm_kota)

Tabel-tabel yang memenuhi kriteria normalisasi

ketiga, sudah siap diimplementasikan. Sebenarnya
masih ada lagi bentuk normalisasi yang lain;
Normalisasi Boyce-Codd, 4NF, 5NF, hanya saja
jarang
dipakai.
Pada
kebanyakan
kasus,
normalisasi hanya sampai ketiga.

Boyce-Codd 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

Keempat (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

Penerapan Normalisasi

SISTEM BASIS DATA

Contoh Kasus Penerapan

Normalisasi

Pada proses perancangan database

dapat dimulai dari dokumen dasar yang
dipakai dalam sistem sesuai dengan
lingkup sistem yang akan dibuat
rancangan databasenya.
Berikut ini adalah contoh dokumen
mengenai faktur pembelian barang pada
PT. Revanda Jaya..

Bentuk Tidak Normal

(Unnormalized)
Langkah pertama dalam melakukan normalisasi data adalah dengan
membentuk contoh data tersebut didtas dengan membentuk
unnormalisasi data, dengan cara mencantumkan semua atribut data
yang ada apa adanya seperti terlihat berikut ini :

Pada relasi diatas adalah dengan

menuliskan semua data yang ada yang
akan direkam, data yang double tidak
perlu ditulis. Terlihat baris / record yang
tidak lengkap. Sulit dibayangkan
bagaimana bentuk baris yang harus
dibentuk untuk merekam data itu.

Bentuk Normal Pertama

(1 NF)

Bentuklah menjadi bentuk normal pertama

dengan memisah-misahkan data pada
atribut-atribut yang tepat dan bernilai
atomik, juga seluruh record / baris harus
lengkap adanya. Bentuk relasi adalah flat
file. Dengan normal pertama kita dapat
membuat satu tabel yang terdiri dari 11
Atribut yaitu
(No_Faktur, Kode_Supplier, Nama_Supplier,
Kode_Barang, Nama_Barang, Tanggal,
Jatuh_Tempo, Qty, Harga, Jumlah, Total ).

Sehingga hasil daripada pembentukan normal

pertama (1 NF) adalah sebagai berikut ini :

Pada normal pertama tersebut masih terjadi

banyak kelemahan, terutama pada proses
ANOMALI insert, update dan delete berikut ini:

Inserting / Penyisipan
Kita tidak dapat memasukkan kode dan nama supplier saja tanpa
adanya transaksi pembelian, sehingga supplier baru bisa
dimasukkan kalau ada transaksi pembelian.
Deleting / Penghapusan
Bila satu record / baris di atas dihapus, misal nomor faktur 779,
maka berakibat pada penghapusan data supplier S02 (Hitachi)
padahal data tersebut masih diperlukan.
Updating / Pengubahan
Kode dan nama supplier terlihat ditulis berkali-kali, bila nama
supplier berubah, maka di setiap baris yang ada harus dirubah, bila
tidak menjadi tidak konsisten.

Catatan : Atribut jumlah (merupakan atribut turunan) seharusnya

tidak perlu, karena setiap harga dikali kuantitas akan menghasilkan
jumlah, sehingga hasilnya akan menjadi lebih konsisten.

Bentuk Normal Kedua (2

NF)
Bentuk normal kedua dengan melakukan

dekomposisi relasi diatas menjadi beberapa

relasi dan mencari kunci primer dari tiap-tiap
relasi tersebut dan atribut kunci haruslah
unik.
Melihat permasalahan faktur di atas, maka
dapat diambil beberapa kunci kandidat :
( No_Faktur, Kode_Supplier, dan Kode_Barang
). Kunci kandidat tersebut nantinya bisa
menjadi kunci primer pada relasi hasil
dekomposisi.

2 NFLanj

Dengan melihat normal pertama, kita

dapat mendekomposisi menjadi tiga
relasi berserta kunci primer yang ada
yaitu : relasi Supplier (Kode_Supplier),
relasi Barang (Kode_Barang), dan Relasi
Faktur (No_Faktur). Dengan melihat
ketergantungan fungsional atribut-atribut
lain terhadap atribut kunci, maka
didapatkan 3 (tiga) relasi sebagai berikut
:

Dengan pemecahan relasi di atas, maka

untuk pengujian bentuk normal kesatu (1
NF) yaitu insert, update, dan delete akan
terjawab.
Kode dan nama supplier baru dapat
masuk kapanpun tanpa adanya transaksi
pada tabel faktur. Demikian pula untuk
proses update dan delete untuk tabel
Supplier dan Barang.

Pada bentuk normal kedua tersebut masih

terjadi permasalahan yaitu pada relasi
Faktur, yaitu :

Atribut Quantitas pada relasi Faktur, tidak

tergantung pada kunci utama, atribut tersebut
bergantung fungsi pada Kode Barang +
no_faktur, hal ini dinamakan ketergatungan
transitif dan haruslah dipilah menjadi dua
relasi.
Masih terdapat pengulangan, yaitu setiap kali
satu faktur yang terdiri dari 5 macam barang
maka 5 kali juga dituliskan no_faktur, tanggal,
dan jatuh_tempo. Hal ini harus dipisahkan bila
terjadi penggandaan tulisan berulang-ulang.

Bentuk Normal Ketiga (3

NF)

Bentuk normal ketiga mempunyai syarat,

setiap relasi tidak mempunyai atribut yang
bergantung transitif, harus bergantung
penuh pada kunci utama dan harus
memenuhi bentuk normal kedua (2 NF).

Untuk memenuhi bentuk normal ketiga (3

NF), maka pada relasi faktur harus
didekomposisi (dipecah) lagi menjadi dua
relasi yaitu relasi faktur dan relasi transaksi
barang, sehingga hasilnya adalah sebagai
berikut ini:

Primary key pada relasi Supplier adalah

Kode_Supplier,
Primary key pada relasi Barang adalah
Kode_Barang,
Primary key pada relasi Faktur adalah
No_Faktur dan Foreign key nya adalah
Kode_Supplier,
Primary key pada relasi Transaksi_Barang
adalah No_Faktur, Kode_Barang dan
keduanya juga menjadi Foreign key.

Entity Relationship Diagram

(ERD)

Keterangan : * = Primary Key, ** =Foreign Key

Pengertian Hubungan (Relation) antar pada

gambar ERD (entity relationship diagram)
pada gambar di atas adalah sebagai
Supplier ke Faktur relasinya adalah one to many,
berikut:
artinya adalah satu supplier mempunyai banyak
faktur, faktur punya relasi terhadap supplier.

Faktur ke Transaksi_Barang relasinya adalah one

to many, artinya adalah satu faktur mempunyai
beberapa transaksi barang (satu faktur terdiri
dari satu atau lebih transaksi barang).

Barang ke Transaksi_Barang relasinya adalah one

to many, artinya adalah satu barang bisa terjadi
beberapa kali transaksi pembelian barang.

ERD dengan database MS-Access 2000

Implementasi ERD (entity relationship diagram) physical pada

contoh diatas, bisa dituangkan kedalam database MS-Access
aatau SQL Server, seperti terlihat pada gambar beikut ini:

ERD dengan database MS-Access

2000

ERD dengan database SQL Server 2000