OVERVIEW BASIS DATA RELASIONAL Oleh: Ir. M. Ramadhan, MT
Model Relasional Yang akan dibahas: Model relasional: struktur, karakteristik, key, representasi skema basis data Integritas relasional: integritas entitas, integritas referensial Bagaimana membentuk query dalam aljabar relasional View: tujuan dan kegunaan Struktur Data Relasional Relasi: tabel yg terdiri atas baris & kolom level eksternal & konseptual Atribut: nama kolom relasi Domain: sekumpulan harga yg diizinkan u/ sebuah atau beberapa atribut Tuple: baris relasi Derajat relasi: jumlah atribut dalam relasi Kardinalitas relasi: jumlah tuple dalam relasi Basis data relasional: sekumpulan relasi yang sudah normal Karakteristik Relasi Setiap relasi bernama unik Setiap sel relasi berharga tunggal Setiap atribut bernama unik Urutan atribut tidak penting Harga sebuah atribut berasal dari domain yang sama Setiap tuple unik Urutan tuple scr teoritis tak penting
Key Relasional Candidate key: sebuah atau sekumpulan atribut minimum yang secara unik mengidentifikasi sebuah tuple dalam sebuah relasi Dalam sebuah relasi mungkin ada beberapa candidate key Key dengan atribut lebih dari sebuah disebut composite key Primary key: candidate key yg dipilih utk mengidentifikasi tuple dalam relasi Foreign key: sebuah atau sekumpulan atribut dalam sebuah relasi yang cocok dengan candidate key relasi lainnya (atau relasi yang sama) Representasi Skema Basis Data Relasional Sebuah basis data relasional terdiri atas sejumlah relasi Skema relasi: nama relasi diikuti sekumpulan atribut Skema basis data relasional: kumpulan skema relasi dalam basis data tsb. Integritas Relasional Untuk menjamin keakuratan data: Integritas entitas: dalam sebuah relasi, atribut primary key tidak boleh null Null merepresentasikan harga yang belum diketahui (tidak ada) Null tidak sama dengan nol, spasi, atau string kosong Integritas referensial: jika foreign key ada dl sebuah relasi, mk harganya hrs cocok dg harga candidate key dl relasi lain (relasi yg sama) yang terhubung Enterprise constraint: aturan tambahan yg dispesifikasikan oleh user/dba
Model Entity-Relationship Pada bagian ini akan dibahas: Konsep dasar berkaitan dengan model ER (Entity-relationship) Macam-macam notasi yang digunakan dalam diagram ER Model ER menggunakan UML (Unified Modeling Language) Model ER: teknik utama untuk desain basis data konseptual Jenis Entitas Merepresentasikan sekumpulan objek dlm dunia nyata dg properti sama fisik, contoh: pegawai, dosen, surat, mobil, dsb. konseptual (abstrak), contoh: penjualan, pengalaman kerja, kuliah, dsb Jenis entitas kuat eksistensinya tidak bergantung pada entitas lain disebut juga entitas parent, owner, atau entitas dominan Jenis entitas lemah eksistensinya bergantung pada entitas lain disebut juga entitas child, dependent, atau subordinat Relationship Relationship: asosiasi (keterkaitan) antar entitas Derajat relationship: jumlah jenis entitas yang berpartisipasi dalam sebuah relationship Notasi Chen entitas entitas kuat relationship
Derajat relationship Dosen membimbing Mahasiswa binary relationship (relationship derajat dua) quaternary relationship (relationship derajat empat) mengawasi supervisor Karyawan supervisee ternary relationship (relationship derajat tiga) recursive relationship (relationship derajat satu)
Atribut Atribut: properti entitas atau relationship Contoh atribut entitas mahasiswa: NPM,, Alamat, Tgl Lahir, IPK Atribut Sederhana Atribut yang hanya terdiri atas satu komponen Contoh: gol darah, hobi, jenis kelamin Atribut Komposit Atribut yang terdiri atas beberapa komponen Misalnya alamat terdiri atas nama jalan, kelurahan, kecamatan, kota, prov. Atribut Berharga Tunggal Atribut yg hanya memiliki sebuah harga u/ sebuah entitas Contoh: gol. darah, jenis kelamin, tgl. lahir Atribut Berharga Banyak Atribut yang memiliki banyak harga untuk sebuah entitas Contoh: telepon, hobi Atribut Turunan (derived attribute) Atribut yang harganya diperoleh (turunan) dari sebuah atau sekumpulan atribut lain Contoh: gaji, IPK Notasi Chen atribut atribut berharga banyak atribut turunan
Candidate Key Sebuah/sekumpulan atribut yg secara unik mengidentifikasi sebuah entitas Misalnya No. KTP atau No. SIM untuk mengidentifikasi entitas orang Primary Key Candidate key yang dipilih untuk mengidentifikasi sebuah entitas secara unik Misalnya No.KTP dipilih sebagai primary key untuk mengidentifikasi entitas orang Notasi Chen atribut primary key Composite Key Candidate key yang terdiri atas dua atribut atau lebih Misalnya, NIM + KodeMataKuliah + Th + Smt adalah composite key yang digunakan untuk mengidentifikasi nilai mata kuliah mahasiswa Multiplicity Jumlah objek dari sebuah jenis entitas yang mungkin muncul dalam relationship Berkaitan dg multiplicity, ada tiga jenis relationship: 1 : 1 relationship (one-to-one relationship) 1 : N relationship (one-to-many relationship) M : N relationship (many-to-many relationship) 1 1 1 N M N
Notasi Chen Notasi Crow's Feet Notasi UML atribut primary key entitas atribut 1 atribut 2 atribut n Entitas atribut primary key atribut 1 atribut 2 : atribut n Entitas atribut (PK) atribut 1 atribut 2 : atribut n 1 1 relationship 1 N relationship relationship relationship 1 0..1 relationship 1 0..* relationship M relationship N relationship 1..* 0..* relationship Recursive relationship: 0..* 0..* relationship peran relationship entitas peran peran relationship entitas peran relationship peran entitas peran
Pada bagian ini akan dibahas: tujuan normalisasi masalah akibat adanya redundansi data Normalisasi konsep ketergantungan fungsional proses normalisasi Tujuan Normalisasi Tujuan utama perancangan basis data relasional adalah mengelompokkan atribut ke dalam relasi sehingga redundansi data (data ganda) minimum. Normalisasi: teknik untuk memperoleh sekumpulan relasi yang memenuhi kebutuhan data sebuah enterprise (perusahaan, lembaga, organisasi, dsb) Redundansi Data dan Anomali Update Adanya redundansi data menimbulkan masalah anomali update : (a) anomali penyisipan, (b) anomali penghapusan, (c) anomali modifikasi Anomali Penyisipan Bila ada pegawai baru yang ditempatkan di Cabang C3: Ke dalam relasi PegawaiCabang, selain data pegawai (NIP,, Alamat), data detail Cabang C3 (NoCabang, AlamatCabang, TelpCabang) juga harus ditambahkan dengan resiko terjadi ketidakkonsistenan data. Sebaliknya, pada relasi Pegawai, cukup ditambahkan data pegawai dan Cabang C3 tempat ia bekerja tanpa harus memasukkan detail cabang.
Relasi PegawaiCabang berikut masih memiliki data ganda (redundansi data) Pengulangan data yang sama pada NoCabang, AlamatCabang, TelpCabang Timbul masalah anomali update (penyisipan, penghapusan, modifikasi) Relasi PegawaiCabang NIP Alamat NoCabang AlamatCabang TelpCabang 04.001 Toto Jl. Kelinci 27 C5 Jl. Rivai 98 360123 04.003 Ina Jl. ABC 15 C3 Jl. Berlian 56 353637 05.007 Adi Jl. Murai 96 C3 Jl. Berlian 56 353637 05.009 Badu Jl. Merah 3 C7 Jl. Lintas 12 708090 05.017 Fulan Jl. Teduh 48 C5 Jl. Rivai 98 360123 05.022 Nia Jl. Damai 10 C3 Jl. Berlian 56 353637 Normalisasi lebih lanjut terhadap relasi di atas menghasilkan dua relasi Keduanya bebas dari masalah anomali update karena tidak ada data ganda Relasi Pegawai Relasi Cabang NIP Alamat NoCabang NoCabang AlamatCabang TelpCabang 04.001 Toto Jl. Kelinci 27 C5 C3 Jl. Berlian 56 353637 04.003 Ina Jl. ABC 15 C3 C5 Jl. Rivai 98 360123 05.007 Adi Jl. Murai 96 C3 C7 Jl. Lintas 12 708090 05.009 Badu Jl. Merah 3 C7 05.017 Fulan Jl. Teduh 48 C5 05.022 Nia Jl. Damai 10 C3
Anomali Penyisipan (Lanjutan) Bila ada cabang baru yang belum ada pegawainya: Ke dalam relasi PegawaiCabang, data detail cabang baru (NoCabang, AlamatCabang, Telepon) ditambahkan dengan atribut pegawai (NIP,, Alamat) dikosongkan. Hal ini tak mungkin karena NIP sebagai primary key tidak boleh kosong. Berarti data cabang baru tak dapat ditambahkan. Sebaliknya, pada relasi Cabang, detail cabang baru dapat ditambahkan. Anomali Penghapusan Bila pegawai dengan NIP 05.009 dihapus: Pada relasi PegawaiCabang: data detail Cabang C7 juga ikut terhapus Sebaliknya, penghapusan pegawai dengan NIP 05.009 pada relasi Pegawai tidak mengakibatkan hilangnya data detail Cabang C7. Anomali Modifikasi Misalkan Cabang C3 pindah alamat dan teleponnya berganti nomor: Pada relasi PegawaiCabang: modifikasi data harus dilakukan secara berulang ke seluruh tuple yang memuat data Cabang C3. Hal ini dapat menimbulkan ketidakkonsistenan data. Sebaliknya, modifikasi data Cabang C3 pada relasi Cabang cukup dilakukan sekali
Ketergantungan Fungsional Jika A dan B adalah atribut relasi R, maka B memiliki ketergantungan fungsional pada A (ditulis A B), jika setiap harga A berasosiasi tepat dengan satu harga B. (A dan B boleh jadi terdiri atas satu atau beberapa atribut) Determinan ketergantungan fungsional adalah atribut atau sekumpulan atribut yang ada pada sisi kiri anak panah NPM Determinan memiliki ketergantungan fungsional pada NPM NPM TIDAK memiliki ketergantungan fungsional pada NPM 2005.99.001 Amir 2005.99.001 Amir 2002.55.123 Proses Normalisasi 1NF, 2NF, 3NF, BCNF, 4NF, 5NF Pertama kali dikembangkan oleh E.F. Codd (1973): 1NF, 2NF, 3NF R. Boyce dan E.F. Codd (1974): BCNF Fagin (1977, 1979): 4NF, 5NF (sangat jarang)
1NF - First Normal Form (Bentuk Normal Pertama) Adalah relasi yang setiap perpotongan baris dan kolomnya berisi satu dan hanya satu harga. 2NF - Second Normal Form (Bentuk Normal Kedua) Relasi yang memenuhi 1NF dan setiap atribut bukan primary key memiliki ketergantungan fungsional secara penuh pada primary key. Bila A dan B adalah atribut sebuah relasi, maka B memiliki ketergantungan fungsional secara penuh pada A jika B bergantung fungsional pada A secara keseluruhan dan bukan pada sebagian dari A. 3NF - Third Normal Form (Bentuk Normal Ketiga) Relasi yang memenuhi 1NF, 2NF dan atribut yang bukan primary key tidak memiliki ketergantungan transitif pada primary key Misal A, B, C adalah atribut sebuah relasi. Jika A B dan B C, maka dikatakan C memiliki ketergantungan transitif pada A melalui B. BCNF Boyce-Codd Normal Form (Bentuk Normal Boyce-Codd) Relasi yang jika dan hanya jika setiap determinan adalah candidate key. Relasi BCNF tidak harus melalui 3NF terlebih dahulu Pengecekan BCNF perlu dilakukan apabila pada relasi tersebut : berisi dua composite candidate key atau lebih, dan sekurang-kurangnya ada sebuah atribut yang overlap
Contoh relasi yang belum BCNF Relasi tsb. menunjukkan: Relasi WawancaraMhsBaru NoTes Tgl Waktu NRP Ruang 05.012 19-08-2005 08.00 09.30 99.005 205 05.034 19-08-2005 10.00 11.30 99.005 205 05.056 19-08-2005 10.00 11.30 99.013 304 05.034 23-08-2005 08.00 09.30 99.005 304 05.056 23-08-2005 10.00 11.30 99.005 304 Seorang mhs baru diwawancara hanya sekali dalam sehari. Bila dipandang perlu, wawancara dilakukan lebih dari sekali pada hari yang berbeda. Pada hari yang sama, pewawancara menempati ruang yang sama Berdasarkan ketentuan di atas, relasi memiliki ketergantungan fungsional: NoTes, Tgl Waktu, NRP, Ruang NRP, Tgl, Waktu NoTes primary key candidate key Ruang, Tgl, Waktu NRP, NoTes NRP, Tgl Ruang candidate key Bukan candidate key Karena ada determinan yg bukan candidate key, relasi di atas belum BCNF Ketergantungan fungsional yang determinannya bukan candidate key dipisahkan dalam relasi tersendiri, sehingga diperoleh dua relasi BCNF: Wawancara (NoTes, Tgl, Waktu, NRP) RuangWawancara (NRP, Tgl, Ruang)
Setelah dinormalisasi, dari tabel WawancaraMhsBaru diperoleh dua buah tabel BCNF sbb: Relasi Wawancara NoTes Tgl Waktu NRP 05.012 19-08-2005 08.00 09.30 99.005 05.034 19-08-2005 10.00 11.30 99.005 05.056 19-08-2005 10.00 11.30 99.013 05.034 23-08-2005 08.00 09.30 99.005 05.056 23-08-2005 10.00 11.30 99.005 Relasi RuangWawancara Tgl NRP Ruang 19-08-2005 99.005 205 19-08-2005 99.013 304 23-08-2005 99.005 304
Daftar Pustaka Connolly, Thomas., et.al., 2002. Database System. Wokingham England, Addison-Wesley Publishing Company. Date, C.J, 2000. An Introduction to Database System. 7 th Edition, New York, Addison Wesley Publishing Company. 2006, M. Ramadhan