Transcript Pert 6 - Normalisasi

Normalisasi
Pertemuan Minggu Ke-6
Kompetensi Khusus
• Mahasiswa mampu mengidentifikasi adanya
pengulangan data dan menormalisasi desain
database (C4)
Normalisasi
• Normalisasi adalah proses evaluasi & perbaikan struktur
tabel untuk meminimalisasi redudansi data, sehingga
mengurangi kemungkinan adanya anomali data.
• Proses normalisasi mencakup penempatan atribut ke tabel
berdasarkan konsep determinasi yang telah dipelajari di
topik Model Database Relasional.
• Terdiri dari 3 tahap yaitu normal pertama (1NF), normal
kedua (2NF), & normal ketiga (3NF).
• Secara struktural, tentunya 2NF lebih baik dari 1NF, & 3NF
lebih baik dari 2NF.
• Dalam banyak kasus, 3NF adalah yang paling tinggi dalam
proses normalisasi. Akan tetapi, 3NF juga memenuhi
kebutuhan untuk normal keempat (4NF).
• Walaupun normalisasi sangat penting dalam desain
database, maka tidak dapat diasumsikan bahwa tingkat
normalisasi tertinggi adalah yang paling baik.
• Umumnya, semakin tinggi bentuk normal, semakin banyak
operasi join relasional yang perlu untuk menghasilkan
output; juga semakin banyak sumber daya yang dibutuhkan
oleh sistem database untuk merespon query end user.
• Desain yang baik harus mempertimbangkan permintaan
end user untuk kinerja cepat sehingga terkadang perlu
men-denormalisasi beberapa porsi dari desain database
untuk memenuhi kebutuhan kinerja.
• Denormalisasi menghasilkan bentuk normal yang lebih
rendah; yaitu 3NF akan dikonversi menjadi 2NF. Akan
tetapi, harga yang harus dibayar untuk peningkatan kinerja
melalui denormalisasi adalah besarnya redudansi data.
Pentingnya Normalisasi
• Desainer database biasanya
normalisasi dalam 2 situasi:
menggunakan
– Ketika membangun struktur database baru
berdasarkan kebutuhan bisnis dari end user, desainer
database akan membangun model data menggunakan
teknik seperti notasi Crow’s Foot. Setelah desain awal
selesai, desainer dapat menggunakan normalisasi
untuk menganalisa hubungan antar atribut dalam tiap
entitas & menentukan apakah strukturnya dapat
diperbaiki melalui normalisasi.
– Desainer database memodifikasi struktur data yang
sudah ada dalam bentuk file datar, spreadsheet, atau
struktur database lama.
Tahap Normalisasi
• Tujuannya untuk menghasilkan tabel dengan
karakteristik berikut:
– Tiap tabel mewakili subjek tunggal.
– Tidak ada item data yang disimpan dalam lebih dari
satu tabel untuk memastikan data hanya diupdate
dalam satu tabel.
– Semua atribut bukan PK bergantung hanya pada PK
untuk memastikan data teridentifikasi secara unik
oleh nilai PK.
– Tiap tabel terbebas dari anomali insert, update, atau
delete untuk memastikan integritas & konsistensi
data.
NORMAL FORM
CHARACTERISTIC
First normal form (1NF)
Table format, no repeating groups, & PK identified
Second normal form (2NF)
1NF & no partial dependencies
Third normal form (3NF)
2NF & no transitive dependencies
Boyce-Codd normal form (BCNF)
Every determinant is a candidate key (special case
of 3NF)
Fourth normal form (4NF)
3NF and no independent multivalued
dependencies
Konsep Dependensi Fungsional
CONCEPT
DEFINITION
Functional dependence
The attribute B is fully functional dependent on
the attribute A if each value of A determines one
& only one value of B.
Functional dependence
(generalized definition)
Attribute A determines attribute B (that is, B is
functionally dependent on A) if all of the rows in
the table that agree in value for attribute A also
agree in value for attribute B.
Fully functional dependence
(composite key)
If attribute B is functionally dependent on a
composite key A but not on any subset of that
composite key, the attribute B is fully functionally
dependent on A.
• Jenis
dependensi
fungsional
berhubungan dengan normalisasi:
yang
– Partial dependency muncul ketika terdapat
dependensi fungsional dimana determinan hanya
bagian dari PK.
– Transitive dependency muncul ketika terdapat
dependensi fungsional seperti X  Y, Y Z, & X
adalah PK. Dalam kasus ini, X  Z adalah
transitive dependency karena X menentukan nilai
Z melalui Y. Dengan kata lain, dependensi
fungsional antar atribut non PK adalah tanda
transitive dependency.
Konversi ke 1NF
1. Menghapus repeating group.
– Repeating group adalah kelompok dari beberapa entri dari
tipe yang sama muncul untuk satu atribut kunci.
– Jika repeating group muncul, maka harus dieliminasi
dengan cara memberikan nilai untuk tiap baris yang
kosong.
2. Mengidentifikasi Primary Key.
3. Mengidentifikasi semua ketergantungan.
– Semua ketergantungan yang ada digambarkan dalam
diagram ketergantungan.
– Diagram ketergantungan membantu dalam mendapatkan
pandangan keseluruhan dari hubungan antar atribut tabel.
Contoh Tabel 1NF
Diagram Ketergantungan 1NF
Konversi ke 2NF
• Muncul ketika 1NF memiliki composite primary
key. Jika 1NF hanya memiliki satu atribut PK,
maka tabel sudah menjadi 2NF.
1. Buat
tabel
baru
untuk
menghapus
ketergantungan parsial.
2. Menempatkan kembali atribut dependen.
– Atribut yang bergantung dalam dependensi parsial
dipindahkan dari tabel asli ke tabel baru dengan
determinannya.
– Atribut yang tidak bergantung dalam dependensi
parsial tetap di dalam tabel asli.
Hasil Konversi 2NF
Konversi ke 3NF
1. Membuat
tabel
baru
ketergantungan transitif.
untuk
menghapus
– Untuk tiap ketergantungan transitif, buatlah determinan
sebagai PK untuk tabel baru.
– Jika terdapat 3 ketergantungan transitif yang berbeda,
maka akan ada 3 determinan yang berbeda pula.
– Determinan akan tetap ada dalam tabel asli sebagai
foreign key.
2. Menempatkan kembali atribut dependen.
– Identifikasi atribut yang bergantung pada tiap determinan
di langkah 1.
– Tempatkan atribut dependen dalam tabel baru dengan
determinannya & hapus dari tabel asli.
Hasil Konversi 3NF
• Apapun masalah ketergantungan baik parsial maupun
transitif, solusinya sama yaitu membuat tabel baru
untuk tiap masalah ketergantungan.
• Determinan dari masalah ketergantungan tetap dalam
tabel asli & ditempatkan sebagai PK dari tabel baru.
• Dependen dari masalah ketergantungan dipindahkan
dari tabel asli & ditempatkan sebagai atribut dalam
tabel baru.
• Perhatian: walaupun tekniknya sama, proses
normalisasi harus mencapai bentuk 2NF terlebih
dahulu sebelum ke 3NF; jadi pastikan untuk
menyelesaikan ketergantungan parsial sebelum
ketergantungan transitif.
• Contoh kasus proses normalisasi lihat di buku hal 264 –
271.
Perbaikan Desain
•
•
•
•
•
•
Evaluasi penempatan PK
Evaluasi konvensi penamaan
Membuat atribut menjadi satuan unit
Identifikasi atribut baru
Identifikasi hubungan baru
Membuat PK sesuai kebutuhan untuk granularitas
data.
• Memelihara keakuratan sejarah data
• Evaluasi menggunakan derived attribute
Kunci Pengganti (Surrogate)
• Pada tingkat implementasi, kunci pengganti
adalah atribut sistem yang dibuat & dikelola
melalui DBMS.
• Biasanya kunci pengganti adalah numerik &
nilainya meningkat secara otomatis untuk tiap
baris baru.
• Misalnya Access menggunakan tipe data
AutoNumber, MSSQL menggunakan kolom
identitas, & Oracle menggunakan objek
sequence.
Tahap Normalisasi Lanjutan
• Bentuk Normal Boyce-Codd (BCNF)
– Terjadi ketika tiap determinan dalam tabel adalah
candidate key.
– Ketika tabel mengandung hanya 1 candidate key, maka 3NF
& BCNF adalah sama.
– BCNF dilanggar ketika tabel mengandung lebih dari 1
candidate key.
• Bentuk Normal Keempat (4NF)
– Multivalued dependency terjadi ketika satu kunci
menentukan beberapa nilai dari 2 atribut lainnya & tiap
atribut tersebut independen satu sama lain.
– Solusinya adalah membuat tabel baru untuk komponen
dari multivalued dependency.
Dekomposisi ke BCNF
Sampel data untuk konversi BCNF
Contoh Lain Dekomposisi ke BCNF
Tabel dengan multivalued dependencies
Tabel 4NF
Denormalisasi
• Walaupun normalisasi merupakan tujuan desain database tetapi itu
hanya salah satu dari banyak tujuan.
• Desain database yang baik juga mempertimbangkan kebutuhan
pemrosesan (pelaporan) & kecepatan pemrosesan.
• Masalah normalisasi adalah ketika tabel dipecah untuk memenuhi
kebutuhan normalisasi, jumlah tabel meningkat.
• Menggabung sejumlah besar tabel membutuhkan operasi input/
output tambahan & logika pemrosesan, sehingga mengurangi
kecepatan sistem.
• Kebanyakan sistem database relasional dapat menangani join
dengan efisien tetapi kondisi tertentu memperbolehkan
denormalisasi sehingga kecepatan pemrosesan meningkat.
• Perlu diingat bahwa keuntungan dari kecepatan pemrosesan yang
lebih tinggi harus ditimbang baik-baik terhadap kerugian dari
anomali data.
Daftar Pemodelan Data
• Aturan Bisnis
– Dokumentasikan dengan baik & verifikasi semua
aturan bisnis dengan end user.
– Pastikan semua aturan bisnis ditulis dengan jelas,
tepat, & sederhana. Aturan bisnis harus
membantu identifikasi entitas, atribut, hubungan,
& batasan.
– Identifikasi sumber dari semua aturan bisnis, &
pastikan tiap aturan bisnis dijustifikasi, diberi
tanggal, & disetujui oleh otoritas yang menyetujui.
• Pemodelan Data
– Konvensi penamaan : semua nama seharusnya dibatasi
panjangnya (ukuran bergantung pada database)
• Nama entitas:
– Berupa kata benda yang familiar untuk bisnis & harus pendek & memiliki
arti.
– Dokumentasikan singkatan, sinonim, & alias untuk tiap entitas.
– Harus unik dalam model.
– Untuk entitas komposit, dapat mencakup kombinasi dari nama singkatan
dari entitas yang terhubung melalui entitas komposit.
• Nama atribut:
–
–
–
–
Harus unik dalam entitas.
Harus menggunakan singkatan entitas sebagai prefiks.
Harus mendeskripsikan karakteristiknya.
Harus menggunakan suffiks seperti _ID, _NUM, atau _CODE untuk atribut
PK.
– Bukan merupakan kata reserved.
– Tidak mengandung spasi atau karakter spesial seperti @, !, atau &.
• Nama hubungan:
– Berupa kata kerja aktif atau pasif yang menandakan sifat dari hubungan.
– Entitas
• Tiap entitas mewakili subjek tunggal.
• Tiap entitas mewakili satu set instance entitas.
• Semua entitas harus dalam 3NF atau lebih tinggi. Entitas yang
berada di bawah 3NF harus dijustifikasi.
• Granularitas dari instance entitas harus didefinisikan dengan jelas.
• PK harus didefinisikan dengan jelas & mendukung granularitas
data yang dipilih.
– Atribut
• Harus sederhana & bernilai tunggal (data atomik).
• Harus mendokumentasikan nilai default, batasan, sinonim, & alias.
• Derived attribute harus diidentifikasi dengan jelas termasuk
sumbernya.
• Tidak boleh ada redudansi kecuali dibutuhkan untuk keakuratan
transaksi, kinerja, atau memelihara sejarah.
• Atribut bukan kunci harus bergantung penuh pada atribut PK.
– Hubungan
• Harus mengidentifikasi dengan jelas partisipan hubungan.
• Harus mendefinisikan dengan jelas partisipasi, konektivitas,
& kardinalitas.
– Model ER
• Harus divalidasi terhadap proses yang diharapkan: insert,
update, & delete.
• Harus mengevaluasi dimana, kapan, & bagaimana
memelihara sejarah.
• Tidak boleh berisi hubungan redundan kecuali dibutuhkan
(lihat atribut).
• Harus meminimalisasi redudansi data untuk memastikan
update pada satu lokasi.
• Harus sesuai dengan aturan data minimal: semua yang
dibutuhkan ada, & semua yang ada dibutuhkan.
Review Materi
• Mahasiswa mengerjakan tugas yang ada di
portal.