Basis Data dan SBP Disusun Oleh : Lily Wulandari

Disain Sistem Basis Data Relasional

Ketergantungan Fungsional

Desain Skema Relasi Database dapat dimodelkan sebagai: kumpulan entitas, Atribut adalah properti yang digunakan untuk menggambarkan suatu entitas. Desain database relasional? Pengelompokan atribut untuk membentuk skema relasi yang "baik". Untuk mengukur kualitas disain. Tujuan dari kegiatan perancangan adalah perlindungan informasi dan redundansi yang minimum.

Panduan Desain Informal untuk Skema Relasi Semantik yang Jelas untuk Atribut dalam relasi Redudansi informasi di Tupel dan Anomali Nilai NULL pada Tupel

1. Semantik yang Jelas untuk Atribut dalam relasi Guideline #01: Secara informal, masing-masing tupel dalam relasi harus mewakili satu entitas atau hubungan instance Atribut-atribut dari entitas yang berbeda (EMPLOYEE, DEPARTMENT, PROJECT) sebaiknya tidak digabung dalam relasi yang sama hanya foreign key yang harus digunakan untuk merujuk ke entitas lain Rancang sebuah skema yang bisa dijelaskan dengan mudah relasi per relasi.

Skema database relasional Company yang disederhanakan

Contoh kondisi database untuk beberapa database relasional Company

2. Redudansi Informasi Pada Tupel dan Anomali Salah satu tujuan desain skema adalah meminimalkan ruang penyimpanan yang digunakan oleh relasi dasar Pengelompokan atribut ke dalam skema relasi memiliki pengaruh yang signifikan terhadap ruang penyimpanan Informasi yang disimpan secara berlebihan atau redudansi membuang-buang penyimpanan Contoh: Dua relasi adalah EMPLOYEE dan DEPARTMENT. EMP_DEPT adalah relasi tunggal

Contoh Skema dan Kondisi Untuk EMP_DEPT Dalam EMP_DEPT, nilai atribut dari departemen tertentu (Dnumber, Dname, Dmgr_ssn) diulang untuk setiap karyawan yang bekerja untuk departemen tersebut. Sebaliknya, informasi masing-masing departemen hanya muncul sekali dalam relasi DEPARTEMEN.

2. Redudansi Informasi Pada Tupel dan Anomali Insertion Anomalies: Untuk memasukkan tupel karyawan baru ke dalam EMP_DEPT, harus disertakan nilai atribut untuk departemen dimana karyawan tersebut bekerja, atau NULL (jika karyawan tersebut tidak bekerja untuk departemen manapun). Sulit untuk memasukkan departemen baru yang belum memiliki karyawan dalam relasi EMP_DEPT.

2. Redudansi Informasi Pada Tupel dan Anomali Deletion Anomalies: Jika kita menghapus dari EMP_DEPT sebuah tupel karyawan yang kebetulan mewakili pegawai terakhir yang bekerja untuk departemen tertentu, informasi mengenai departemen tersebut hilang dari database.

2. Redudansi Informasi Pada Tupel dan Anomali Modification Anomalies: Dalam EMP_DEPT, jika kita mengubah nilai salah satu atribut dari departemen tertentu (katakanlah, manajer departemen 5) kita harus memperbarui tupel dari semua karyawan yang bekerja di departemen tersebut; Jika tidak, database akan menjadi tidak konsisten.

2. Redudansi Informasi Pada Tupel dan Anomali Guideline #02: Rancang skema yang tidak mengalami insertion, deletion dan update anomalies.

3. Nilai Null dalam Tupel Banyak atribut dapat dikelompokkan menjadi relasi "gemuk". Jika banyak atribut bernilai NULL pada tupel dalam sebuah relasi, ini bisa menghabiskan banyak ruang di tingkat penyimpanan. Alasan untuk Null: Atribut tidak berlaku atau tidak valid Nilai atribut tidak diketahui (boleh ada). Nilai diketahui ada, namun belum tersedia.

3. Nilai Null dalam Tupel Guideline #03: Hubungan harus dirancang sedemikian rupa sehingga tupel akan memiliki nilai NULL sesedikit mungkin. Atribut yang terdapat banyak NULL dapat ditempatkan dalam hubungan yang terpisah (dengan primary key)

Ketergantungan Fungsional Merupakan konsep yang mendasari normalisasi. Dependensi menjelaskan hubungan antar atribut, atau secara lebih khusus menjelaskan nilai suatu atribut yang menentukan nilai atribut lainnya. Ada beberapa jenis ketergantungan (dependency) Ketergantungan Fungsional / Functionally Dependency (FD) Ketergantungan Fungsional Penuh / Full Functionally Dependency (FFD) Ketergantungan Transitif / Transitive Dependency (TDF) Ketergantungan Total /Total Dependency (TD)

Ketergantungan Fungsional Ketergantungan Fungsional menggambarkan hubungan atribut dalam sebuah relasi. Suatu atribut dikatakan Ketergantungan Fungsional pada yang lain, jika menggunakan harga atribut tersebut untuk menentukan harga atribut yang lain. Simbol yang digunakan adalah  (dibaca secara fungsional menentukan )

Ketergantungan Fungsional Suatu atribut Y mempunyai ketergantungan fungsional terhadap atribut X, jika dan hanya jika setiap nilai X berhubungan dengan sebuah nilai Y. Definisi di atas dituangkan dalam bentuk notasi X  Y Dibaca : X secara fungsional menentukan Y

Ketergantungan Fungsional Contoh Terdapat 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.

Ketergantungan Fungsional PEMBELI KOTA BARANG JUMLAH P1 Yogya B1 10 B2 5 P2 Solo 7 6 B3 P3 Klaten B4

Ketergantungan Fungsional 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}

Ketergantungan Fungsional 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

Ketergantungan Fungsional Penuh Suatu atribut Y mempunyai ketergantungan fungsional penuh terhadap atribut X, jika Y mempunyai ketergantungan fungsional terhadap X Y tidak memiliki ketergantungan terhadap bagian dari X Notasi : X  Y

Contoh 2 Functional Dependency: NRP  Nama {Mata_Kuliah, NRP}  Nilai Non Functional Dependency: Mata_Kuliah  NRP NRP  Nilai

Ketergantungan Fungsional Penuh contoh, terdapat relasi pelanggan: Pelanggan(KODE_PELANGGAN,NAMA,KOTA, NOMOR_FAX ) Pada relasi ini: {KODE_PELANGGAN, KOTA} NOMOR_FAX 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 ketergantungan fungsional sepenuhnya terhadap KODE_PELANGGAN

Ketergantungan Fungsional Penuh Contoh : Pembeli → Kota {Pembeli, Barang} → Kota Kota mempunyai depedensi fungsional terhadap Pembeli atau {Pembeli, Barang} tapi kota mempunyai depedensi fungsional sepenuhnya terhadap pembeli bukan barang.

Ketergantungan Transitif Atribut Z mempunyai ketergantungan transitif terhadap X bila: Y memiliki ketergantungan fungsional terhadap X Z memiliki ketergantungan fungsional terhadap Y Notasinya: X  Y  Z

Ketergantungan Transitif Definisi : Atribut Z pada relasi R dikatakan tergantung transitif pada atribut X, jika atribut Y tergantung pada atribut X pada relasi R dan atribut Z tergantung pada atribut Y pada relasi R. ( X Y, Y Z, maka X Z ) Contoh : Ketergantungan transitif : No-pem  Kode-kota Kode-kota  Kota , maka No-pem  Kota

Ketergantungan Transitif NIP Nama Gol_gaji Gaji_pokok 0001 Ian III A 600000 0002 Saputra III B 650000 0003 Rohim 0004 Fani Gol_gaji ketergantungan fungsional pada NIP dan Gaji_pokok ketergantungan fungsional 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  Z NIP  Gol_gaji Gaji_pokok

Ketergantungan Total Suatu atribut Y mempunyai ketergantungan total pada atribut X jika: Y memiliki ketergantungan fungsional terhadap X X memiliki ketergantungan fungsional terhadap Y Notasi : X  Y

Ketergantungan Total Contoh : PEGAWAI (NO-INDUK,NAMA,TMP-LAHIR,TG-LAHIR, ALAMAT) Dengan demikian notasi dapat ditulis: NO-INDUK  NAMA

Normalisasi

Definisi Cara pendekatan dalam membangun desain logika basis data relasional yang tidak secara langsung berkaitan dengan model data tetapi dengan menerapkan sejumlah aturan dan kriteria standar untuk menghasilkan struktur tabel yang normal Proses pengelompokan data elemen menjadi tabel-tabel yang menunjukkan entity dan relasinya.

Tujuan MENDESAIN DATABASE RELASIONAL DENGAN TABEL-TABEL YANG: berisi data yang diperlukan memiliki sesedikit mungkin redundansi mengefisienkan update menghindari kemungkinan kehilangan data secara tidak disengaja/tidak diketahui meminimalkan anomali penyisipan, penghapusan, dan perbaruan

Ciri-ciri Database Tidak Normal INSERTION ANOMALY Yaitu kesalahan yang terjadi sebagai akibat operasi menyisipkan tuple/record pada sebuah relasi. DELETION ANOMALY Yaitu kesalahan yang terjadi sebagai akibat operasi penghapusan terhadap tuple/record dari sebuah relasi. UPDATE ANOMALY Yaitu kesalahan yang terjadi sebagai akibat operasi perubahan tuple/record dari sebuah relasi.

Syarat Tabel Normal Jika ada dekomposisi/penguraian tabel, maka dekomposisinya dijamin aman (lossless-join decomposition) terpeliharanya ketergantungan functional pada saat perubahan data (dependency preservation) Tidak melanggar Boyce Code Normal Form (BCNF), jika tidak bisa minimal tidak melanggar bentuk normalisasi ketiga

Lossy Decomposition

Contoh Lossless-Join Decomposition Dekomposisi dari R = (A, B, C) R1 = (A, B) R2 = (B, C) A B C A B B C   1 2 A B   1 2 1 2 A B r A,B(r) B,C(r) A B C A (r) B (r)   1 2 A B

Contoh : Data Mahasiswa

Decomposition? (Nim, Nama) dan (Nama, Kode, Matkul, SKS, Nilai)

Hasil Penggabungan Kembali?

Ketergantungan Fungsional Diberikan sebuah tabel/relasi T. Atribut B dari T bergantung secara fungsi pada atribut A dari T jika dan hanya jika setiap nilai A dari T punya hubungan dengan tepat satu nilai B dalam T (dalam setiap satu waktu)

Latihan Tunjukkan apakah dekomposisi terhadap Data Mahasiswa pada contoh termasuk Lossless Join Decomposition atau Lossy Join Decomposition, untuk dekomposisi berikut (NIM, Nama, Kode) dan (Kode, Matkul, SKS, Nilai) (NIM, Kode) dan (Kode, Nama, Matkul, SKS, Nilai) (NIM, Nama) dan (NIM, Kode, Matkul, SKS, Nilai) (NIM, Nama), (Kode, Matkul, SKS) dan (NIM, Kode, Nilai)

Bentuk-Bentuk Normalisasi Bentuk tidak normal Bentuk ini merupakan kumpulan data yang akan direkam, tidak ada keharusan mengikuti format tertentu, dapat saja tidak lengkap dan terduplikasi. Data dikumpulkan apa adanya sesuai keadaannya Bentuk normal tahap pertama (1st Normal Form) Sebuah tabel tidak memiliki multivalued atribut

Bentuk-Bentuk Normalisasi Bentuk normal tahap kedua (2nd normal form) memenuhi 1st NF Atribut bukan kunci tergantung penuh pada atribut kunci Boyce Code Normal Form (BCNF) relasi harus bergantung fungsi pada atribut superkey

Bentuk Normal 2 KdFaktur  Tgl, Jtempo, KodeSup, NamaSup KdFaktur, Kodebrg  NamaBrg, Qty, Harga Bentuk BCNF KdFaktur  Tgl, Jtempo, KodeSup KdSup  NamaSup KdFaktur, Kodebrg Qty, Harga KodeBrg  NamaBrg

Latihan Dari fakta pada gambar di halaman berikutnya, buatlah tabel-tabel: Bentuk Tidak Normal Bentuk Normal Pertama Bentuk Normal Kedua Bentuk BCNF

Selesai