Normalisasi Pertemuan Minggu Ke-6.

Presentasi berjudul: "Normalisasi Pertemuan Minggu Ke-6."— Transcript presentasi:

1 Normalisasi Pertemuan Minggu Ke-6

2 Kompetensi Khusus Mahasiswa mampu mengidentifikasi adanya pengulangan data dan menormalisasi desain database (C4)

3 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).

4 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.

5 Pentingnya Normalisasi
Desainer database biasanya menggunakan normalisasi dalam 2 situasi: 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.

6 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.

7 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

8 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.

9 Jenis dependensi fungsional yang berhubungan dengan normalisasi:
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.

10 Konversi ke 1NF 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. Mengidentifikasi Primary Key. Mengidentifikasi semua ketergantungan. Semua ketergantungan yang ada digambarkan dalam diagram ketergantungan. Diagram ketergantungan membantu dalam mendapatkan pandangan keseluruhan dari hubungan antar atribut tabel.

11 Contoh Tabel 1NF

12 Diagram Ketergantungan 1NF

13 Konversi ke 2NF Muncul ketika 1NF memiliki composite primary key. Jika 1NF hanya memiliki satu atribut PK, maka tabel sudah menjadi 2NF. Buat tabel baru untuk menghapus ketergantungan parsial. 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.

14 Hasil Konversi 2NF

15 Konversi ke 3NF Membuat tabel baru untuk menghapus ketergantungan transitif. 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. 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.

16 Hasil Konversi 3NF

17 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.

18 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

19 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.

20 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.

21 Dekomposisi ke BCNF Sampel data untuk konversi BCNF

22 Contoh Lain Dekomposisi ke BCNF

23 Tabel dengan multivalued dependencies

24 Tabel 4NF

25 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.

26 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.

27 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 !, atau &. Nama hubungan: Berupa kata kerja aktif atau pasif yang menandakan sifat dari hubungan.

28 Entitas Atribut 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.

29 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.

30 Review Materi Mahasiswa mengerjakan tugas yang ada di portal.

31