Penyempurnaan Skema dan Bentuk-bentuk Normal BAGIAN II
Third Normal Form (3NF) Relasi R dengan FDs F dikatakan berada dlm 3NF jika, untuk semua FD X A dalam F, salah satu dari pernyataan berikut harus berlaku: A X (disebut trivial FD), atau X adalah key dari R, atau A adalah bagian dari beberapa key dari R (A adalah prime attribute) Minimality dari key dalam kondisi ketiga di atas menjadi sangat penting ! Jika R berada dlm BCNF, sudah tentu R juga berada dlm 3NF Jika R berada dlm 3NF, beberapa redundansi masih mungkin terjadi. Bentuk 3NF dapat dipakai sebagai bentuk yang kompromistis dan digunakan bilamana BCNF tidak dapat diupayakan (misalnya karena tidak ada dekomposisi yang “baik”, atau karena alasan pertimbangan kinerja dari database) 24
Apa yang Dapat Dicapai oleh 3NF? Jika depedensi X A menyebabkan pelanggaran dari 3NF, maka salah satu kasus di bawah ini akan terjadi: X adalah subset dari beberapa key K (partial dependency) Pasangan nilai (X, A) yang sama akan tersimpan secara redundan X bukan subset dari sembarang key K (transitive dependency) Terdapat rantai FDs K X A, yang berarti bhw kita tdk dpt mengasosiasikan sebuah nilai A dengan sebuah nilai K kecuali kalau kita juga mengasosiasikan sebuah nilai A dengan sebuah nilai X Namun demikian, walaupun seandainya relasi berada dalam 3NF, persoalan-persoalan berikut masih dpt terjadi: Contoh: relasi Reserves SBDC (C=Credit Card ID), S C, C S berada dalam 3NF, tetapi utk setiap reservasi dari sailor S, pasangan nilai (S, C) yang sama akan tersimpan dalam database. Dengan demikian, 3NF memang merupakan bentuk normal yang relatif kompromistis dibandingkan BCNF. 25
Proses Dekomposisi dari sebuah Skema Relasi Asumsikan relasi R terdirid ari attributes A1 ... An. Proses dekomposisi dari R meliputi penggantian R oleh dua atau lebih relasi, sehingga : Setiap skema relasi yang baru terdiri dari subset attribut dari R (dan tidak satupun attribut yang tidak muncul dalam R), dan Setiap attribut dari R muncul sebagai sebuah attribut dari salah satu atau lebih relasi-relasi yang baru Secara intuitif, pendekomposisian R berarti bahwa kita akan menyimpan nilai-nilai dari skema-skema relasi yang dihasilkan oleh proses dekomposisi, bukan nilai-nilai dari relasi R Contoh, relasi SNLRWH dapat didekomposisi menjadi SNLRH dan RW (lihat slide berikutnya). 26
Contoh Dekomposisi-1 Perhatikan relasi: DeptProj (Ename, SSN, Bdate, Address, Dnumber, Dname, DMgrSSN) ESBADNM FDs: S EBAD, D NM S EBAD : memenuhi 3NF dan BCNF D MN : menyalahi 3NF atau BCNF, dekomposisi ESBADNM menjadi: ESBAD dan DMN Hasil proses dekompoisi ESBADNM : ESBAD dan DMN (3NF & BCNF) ESBAD DeptProj1 (Ename, SSN, Bdate, Address, Dnumber) DMN Department (Dnumber, Dname, DMgrSSN) 27
Contoh Dekomposisi-2 Perhatikan relasi: EmpProj (SSN, Pnumber, Hours, Ename, Pname, Plocation) SPHEJL FDs: SP H, S E, P JL SP H : memenuhi 3NF dan BCNF S E : menyalahi 3NF atau BCNF, dekomposisi SPHEJL menjadi: SPHJL dan SE P JL : menyalahi 3NF atau BCNF, dekomposisi SPHJL menjadi: SPH dan PJL Hasil proses dekompoisi SPHEJL : SPH, SE, dan PJL (3NF & BCNF) SPH EmpProj1 (SSN, Pnumber, Hours) SE Employee (SSN, Ename) PJL Project (Pnumber, Pname, Plocation) 27
Contoh Dekomposisi-3 Perhatikan relasi: LOTS (PropertyID#, CountyName, Lot#, Area, Price, TaxRate) ICLAPT FDs: I CLAPT, CL IAPT, C T, A P I CLAPT : memenuhi 3NF dan BCNF CL IAPT : memenuhi 3NF dan BCNF C T : menyalahi 3NF dan BCNF, dekomposisi ICLAPT menjadi: ICLAP dan CT A P : menyalahi 3NF dan BCNF, dekomposisi ICLAP menjadi: ICLA dan AP Hasil proses dekompoisi ICLAPT : ICLA, CT, dan AP (3NF dan BCNF): ICLA LOTS1 (PropertyID#, CountyName, Lot#, Area) CT TaxRate (CountyName, TaxRate) AP Price (Area, Price) 27
Contoh Dekomposisi-4 Perhatikan relasi: LOTS (PropertyID#, CountyName, Lot#, Area, Price, TaxRate) ICLAPT FDs: I CLAPT, CL IAPT, C T, A P, dan A C (tambahan) I CLAPT : memenuhi 3NF dan BCNF CL IAPT : memenuhi 3NF dan BCNF C T : menyalahi 3NF dan BCNF, dekomposisi ICLAPT menjadi: ICLAP dan CT A P : menyalahi 3NF dan BCNF, dekomposisi ICLAP menjadi: ICLA dan AP A C : menyalahi BCNF (tapi memenuhi 3NF) Atruan 3NF, relasi AC TIDAK perlu dipisah (hasil proses dekomposisi seperti dalam contoh slide sebelumnya) Aturan BCNF, relasi AC harus dipisah, sehingga hasil akhir menjadi (FD CL IAPT hilang dari hasil TIDAK mempertahankan property dependency preservation) : IL LOTS1 (PropertyID#, Lot#) CT TaxRate (CountyName, TaxRate) AP Price (Area, Price) AC Area (Area, CountyName) 27
Persoalan-persoalan yang Dapat Ditim-bulkan oleh Dekomposisi (Lanjutan) Terdapat 3 persoalan potensial yang perlu diperhatikan: 1. Beberapa queries menjadi lebih mahal. Contoh, Brp gaji yang diterima oleh Joe? (gaji = W*H) 2. Untuk nilai-nilai relasi hasil dekomposisi, mungkin kita tidak dapat merekonstruksi nilai-nilai relasi asal yang bersesuaian (losless joins) ! Kebetulan tidak terjadi pada contoh relasi SNLRWH 3. Pengecekan beberapa dependensi bisa jadi membutuhkan penggabungan (joining) nilai-nilai relasi hasil dekomposisi (dependency preservation) ! Kebetulan tidak terjadi pada contoh relasi SNLRWH, tetapi terjadi pada contoh relasi ICLAPT (contoh dekomposisi-4) Tradeoff: Harus mempertimbangkan persoalan ini, selain persoalan redundansi (persoalan utama). 28
Persoalan-persoalan yang Dapat Ditimbulkan oleh Dekomposisi Proses dekomposisi sebaiknya digunakan hanya bilamana diperlukan. SNLRWH mempunyai FDs S SNLRWH dan R W FD kedua menimbulkan pelanggaran 3NF; nilai-nilai W secara berulang diasosiasikan dg nilai-nilai R. Cara yang termudah utk memperbaiki ini adalah menciptakan relasi baru RW utk menyimpan asosiasi-asosiasi tersebut, dan untuk menghapus W dari skema utama, yaitu: SNLRWH didekomposisi menjadi SNLRH dan RW Informasi yang akan disimpan terdiri dari SNLRWH tuples. Namun, jika kita hanya menyimpan proyeksi dari tuples ini pada SNLRH dan RW, adakah persoalan- persoalan potensial lain yang perlu dipertimbangkan? (lihat slide berikutnya) 27
Dekomposisi yang Bersifat Lossless Join Dekomposisi R menjadi X dan Y disebut lossless-join dg mengacu pada satu set FDs F jika, untuk setiap instance r yang memenuhi F, berlaku: X (r) Y (r) = r Keadaan yang selalu harus benar: r X (r) Y (r) Secara umum, arah sebaliknya tidak berlaku! Jika berlaku, maka dekomposisi bersifat lossless-join. Definisi di atas dapat secara mudah diperluas utk proses dekomposisi menjadi 3 relasi atau lebih Penting untuk diperhatikan bhw semua jenis dekomposisi yang digunakan untuk menangani redundansi harus bersifat lossless! (Hindari persoalan ke-2) 29
Lossless Join (Lanjutan) Dekomposisi R menjadi X dan Y bersifat lossless-join dg mengacu pada FDs F, jika dan hanya jika closure dari F (F+) berisikan: X Y X, atau X Y Y Secara umum, dekomposisi R menjadi UV dan R - V bersifat lossless-join, jika U V berlaku pada R dan U V = . Spurious Tuples (Baris-baris nyeleneh) 30
Dekomposisi yang Mempertahankan Dependensi Perhatikan CSJDPQV, C adalah key, JP C dan SD P. Dekomposisi BCNF : CSJDQV dan SDP Persoalan: Utk mengecek JP C diperlukan operasi join! Dekomposisi yg mempertahankan dependensi (Intuitif): Jika R didekomposisi menjadi X, Y dan Z, dan kita memaksa agar FDs tetap berlaku pada X, Y dan Z, maka semua FDs yang diberikan utk berlaku pada R hrs juga tetap berlaku. (Mengindari persoalan ke-3) Projection dari set FDs F: Jika R didekomposisi menjadi X, ..., projection dari F pada X (disimbolkan FX ) adalah set dari FDs U V dalam F+ (closure of F) sedemikian rupa sehingga U, V ada dalam X. 3
Dekomposisi yang Mempertahankan Dependensi (Lanjutan) Dekomposisi R menjadi X dan Y bersifat mempertahankan dependensi (dependency preserving) jika (FX FY )+ = F +, yaitu: Jika kita hanya memperhatikan dependensi dalam F + yang dapat dicek dalam X tanpa memperhatikan Y, dan dalam Y tanpa memperhatikan X, maka hal ini mengimplikasikan bahwa semua dependensi ada dalam F +. Penting utk memperhatikan F + (BUKAN F) dalam definisi ini: ABC, dengan FD: A B, B C, C A, didekomposisi menjadi AB dan BC. Apakah bersifat dependency preserving? apakah C A dipertahankan?? Dependency preserving tidak mengimplikasikan lossless join: ABC, dengan FD: A B, didekomposisi menjadi AB dan BC. Demikian juga sebaliknya, sifat lossless-join tidak mengimplikasikan dependency preserving 4
Dekomposisi menjadi BCNF Perhatikan relasi R dengan FDs F. Jika X Y melanggar BCNF, lakukan dekomposisi R menjadi R - Y and XY. Penggunaan secara berulang dari ide ini akan menghasilkan sekumpulan relasi yang berada dalam BCNF & lossless join decomposition, dan dijamin utk mengalami terminasi. Contoh, CSJDPQV, key C, JP C, SD P, J S Utk menangani SD P, dekomposisi menjadi SDP, CSJDQV. Utk menangani J S, dekomposisi CSJDQV menjadi JS dan CJDQV Bagaimana jika penanganan J S dilakukan terlebih dahulu?? Secara umum, beberapa dependensi yang diberikan dapat menimbulkan pelanggaran BCNF. Ingat, urutan “penanganan” dekomposisi seperti di atas dapat memberikan relasi hasil dekomposisi yang berbeda ! Next lecture, 13 Dec 2004 5
BCNF dan Dependency Preservation Secara umum, dimungkinkan dekompoisis menjadi BCNF yang mempertahankan lossless join, tetapi tidak mempertahankan dependensi. Contoh, CSZ, CS Z, Z C Tdk dapat didekomposisi utk mempertahankan FD pertama (tidak dpt dilakukan dekompoisi BCNF). Dengan cara yang sama, dekomposisi CSJDQV menjadi SDP, JS dan CJDQV tidak mempertahankan dependensi (dengan mengacu ke FDs JP C, SD P dan J S). Namun demikian, dekomposisi di atas bersifat lossless-join. Dalam kasus ini, penambahan JPC pada set relasi hasil dekomposisi akan mememberikan dekomposisi yang dpt mempertahankan dependensi. Penyimpanan tuples JPC hanya untuk tujuan pengecekan FD! (Persaoalan Redundansi!) 6
Dekomposisi menjadi 3NF Algoritma untuk lossless join decomposition menjadi BCNF dapat digunakan utk memperoleh lossless join decomposition menjadi 3NF (dapat berhenti lebih awal). Untuk menjamin dependency preservation, suatu ide: Jika X Y tdk dipertahankan, tambahkan relasi XY. Persoalan yang timbul adalah XY dpt melanggar 3NF! Contoh, perhatikan penambahan CJP utk mempertahankan JP C. Apa yang terjadi jika juga berlaku utk J C ? Penyempurnaan: Sebagai pengganti set dari FDs F, gunakan minimal cover dari F. 7
Minimal Cover untuk Set dari FDs Minimal cover G utk sebuah set dari FDs F: Bagian sisi kanan dari setiap FD dalam G berupa sebuah attribut tunggal. Closure dari F = closure dari G. Jika G diubah dengan menghapus sebuah FD atau dengan menghapus beberapa attributes dari sebuah FD dalam G, maka closure akan berubah. Secara intuitif, setiap FD dalam G diperlukan, dan harus seminimal mungkin untuk memperoleh closure yang sama seperti F. Contoh, A B, ABCD E, EF GH, ACDF EG mempunyai minimal cover berikut: A B, ACD E, EF G dan EF H Minimal Cover dapat menghasilkan dekomposisi yang bersifat Lossless-Join dan Dependency Preserving Decomposition !! 8
Algoritma utk mencari Minimal Cover Algoritma untuk memperoleh minimal cover dari satu set F dari FDs: Susun FDs dalam bentuk standar (canonical form) Dapatkan satu set FDs G yang ekivalen dengan sisi kanan dari setiap FD berupa satu attribut tunggal (gunakan aksioma dekomposisi) Lakukan minimisasi sisi kiri dari setiap FD Untuk detiap FD dalam G, periksa apakah setiap attribut pada sisi kiri dpt dihapus dengan tetap mempertahankan ekivalensi terhadap F+ Hapus FDs yang redundan Untuk setiap FD yang dihasilkan dalam G, periksa apakah FD tersebut dapat dihapus dengan tetap ekivalensi terhadap F+ Contoh: Perhatikan satru set FD F yang sudah berada dalam bentuk standar: ABCD E, E D, A B, dan AC D ABCD E dapat diminimisasi menjadi AC E (dan tetap mempertahankan ekivalensi terhadap F+). Selain itu, tidak ada lagi sisi kiri yang dpt diminimumkan lagi. Tapi hasilnya masih belum berupa “minimal cover”: AC E, E D, A B, dan AC D Dari hasil di atas, AC D dapat dihapus karena dpt diperoleh dari AC E, E D (aturan transitivity) 8
Rangkuman Jika sebuah relasi berada dalam BCNF, maka relasi tersebut bebas dari redundansi yang dapat dideteksi dengan menggunakan FDs. Dengan demikian, upaua untuk menjamin bhw semua relasi berada dalam BCNF merupakan upaya heuristik yang baik. Jika sebuah relasi tidak berada dalam BCNF, coba lakukan dekomposisi menjadi sekumpulan relasi-relasi BCNF. Harus mempertimbangkan apakah semua FDs dipertahankan. Jika dekomposisi menjadi BCNF yang bersifat lossless-join dan dependency preserving tidak dimungkinkan (atau tidak cocok, untuk beberapa queries yang tipikal), pertimbangkan dekomposisi menjadi 3NF. Dekomposisi sebaiknya dilakukan dan/atau diperiksa kembali dengan mempertimbangkan performance requirements yang diinginkan. 9