sistem basis data - normalisasi
DESCRIPTION
menjelaskan tentang maateri Normalisasi pada pertemuan 8 sistem basis dataTRANSCRIPT
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