SISTEM BASIS DATA

Macam-macam AnomalyNormalisasi

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 Anomalyb. Deletion Anomalyc. Update AnomalyDi 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 Transitifd. Ketergantungan Parsiale. 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

ContohTerdapat 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 5

P2 Solo B1 7

P2 Solo B2 6

P2 Solo B3 6

P3 Klaten B3 7

P3 Klaten B4 6

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

X Y Z

Atribut Z mempunyai dependensi transitif terhadap X bila:

Y memiliki dependensi fungsional terhadap X

Z memiliki dependensi fungsional terhadap Y

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

X Y ZNIP Gol_gaji Gaji_pokok

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

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 tabel-tabel yang berkualitas baik.

Urutan: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF

Normalisasi

Sebuah tabel dikatakan baik (efisien) atau normal jika memenuhi 3 kriteria sbb:1. 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.

2. Terpeliharanya ketergantungan fungsional pada saat perubahan data (Dependency Preservation).

3. Tidak melanggar Boyce-Codd Normal Form (BCNF) (-akan dijelaskan kemudian-)

Bentuk-bentuk Normal

1. Bentuk Normal Tahap Pertama (1st Normal Form / 1NF)

2. Bentuk Normal Tahap Kedua (2nd Normal Form / 2NF)

3. Bentuk Normal Tahap (3rd Normal Form / 3NF)

4. Boyce-Code Normal Form (BCNF)5. Bentuk Normal Tahap (4th Normal

Form / 4NF)6. 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 dibagi-bagi lagi)

Contoh 1 (atribut multi-value)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:

JadwalKuliahKodekul 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)Mk_kode {mk_nama, mk_sks} (fd3)

fd1 (mhs_nrp, mk_kode, nihuruf) Tabel Nilaifd2 (Mhs_nrp, mhs_nama, mhs_alamat) Tabel Mahasiswafd3 (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: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

SISTEM BASIS DATA

Penerapan Normalisasi

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 / PenyisipanKita 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 NF……Lanj

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 berikut: Supplier ke Faktur relasinya adalah one to many,

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.

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 MS-Access 2000

ERD dengan database SQL Server 2000