REFLEKSI DAN PERTIMBANGANLEBIH LANJUT

Bab ini tidak berisikan ringkasan dari seluruh desain database relasional sertapelaksanaannya. Oleh karena itu materi yang hanya merupakan bagian-bagian daripengetahuan tentang database relasional tidak dibahas sarna sekali. Bab ini akanmembicarakan refleksi dari hal-hal yang telah dibicarakan serta akan menunjukkansedikit dari bidang teknologi database yang tidak dipakai.

11. 1 BENTUK-BENTUK UMUM LAINNYA

Metode desain yang berdasarkan atas FD yang dibicarakan dalam bab 3, 4 dan5 secara leng\capterdapat dalam kepustakaan. Metode-metode tersebut telah dipakaisecara luas dan telah terbukti sebagai alat desain yang efektif. Kita ketahui bersamabahwa tidak terdapat alat desain tunggal yang dapat memberikan desain terbaik un-tuk semua masalah database yang dihadapi seorang desainer. Akan muncul masalahdi mana data yang akan disimpan dalam database berhubungan sedemikian rupasehingga diperlukan teknik desain khusus untuk memperoleh desain terbaik. Sebagaicontoh, ada bentuk-bentuk yang sifatnya lebih khusus dari pada BCNF, yang telahdikembangkan untuk menghindari adanyaOkarakter yang tidak kita inginkan yangdapat muncul dalam relasi BCNF. Dua dari bentuk ini adalah 4NF dan DKINF yangsecara lebih jauh dibahas dalam buku desain database tingkat lanjutan. 4FN memba-has -relasi di mana terdapat set data yang diulang, serta dekomposisi yang

168

menggunakan FD tidak menghilangkan hal yang berulang-ulang. Dekomposisidalam 4NF menuntut penggunaan multi-valued dependencies (MVD's), sebuahkonsep di luar isi teks ini. DK/NF (domain-key normal form), dapat dianggapsebagai bentuk normal yang terakhir dalam arti bahwa tidak terdapat modifikasiyang menyimpang dalam relasi DK/NF. Sampai sekarang belum ada teknik desainformal yang telah dibuat untuk membantu desainer memindahkan posisi relasi kedalam bentuk normal te~but.

Terdapat dua bentuk normal yang lebih khusus dari pada BCNF. Bentuk iniyang dikenal dengan 2NFdan 3NF sangatpenting dilihatdari perspektif sejarah. 2NFdibuat untuk menghilangkan penyimpangan yang bisa muncul padarelasi INF, 3NFdibuat untuk menghilangkan penyimpangan yang dapat muncul pada relasi 2NF dansebagainya. Sangat sedikit database yang dibuat dengan tujuan untuk mendapatkanrelasi akibat hanya dalam INF atau 3NF. Kita dapat mencatat bahwajika suatu relasiterdapat dalam BCNF maka relasi tersebut juga terdapat dalam 2NF dan 3NF:

Masalah yang berhubungan erat dengan dekomposisi relasi dari satu bentuknormal ke bentuk yang lebih tinggi adalahdekomposisi nori-Ioss.Masalah inidibahasdalam Bab 3. Pendeknya pembahasan terhadap topik tersebut bukan berarti tidakpenting. Masalah tersebut berfaedah untuk studi dan pemikiran pembaca.

11. 2 KEUNTUNGAN METODE HUBUNGAN ENTITAS

Dalam pendahuluan metode ER pada Bab 6 disebutkan bahwa metode ERmempunyai beberapa keuntungan dalam hal metode desain yang berdasarkan FD:

1. Desain mulai dengan study yang mendalam tentang masalah penyimpanan datasecara keseluruhan. Metoda ini memberikan kesadaran terhadap masalah yangtengah ditangani jauh lebih banyak dari pada metode yang dimulai denganmembuat atribut dan ketergantungan fungsional.

2. Filosofi desain ER dapat diterapkan secara efektif dalam masalah yang terdapatsangat banyak atribut sehingga metode desain FD tidak dapat lagi dipakai untukmengaturnya.

Metode ER yang diberikandalam buku ini diharapkandapat memberikan.

pengertian dasar yang baik kepada pembaca untuk memulai mengembangkankemampuan yang diperlukan dalam memecahkan masalah-masalah desain database.Hal yang perlu diingat bagi desainer adalah bahwa FD tidak boleh dilupakanmeskipun desain ini.berdasarkan pada filosofi ER. Relasidesain akhir harus dicekuntuk mendapatkan bentuk yang normal.

169

11. 3 NORMALISASI NILAI

Pada pembahasan desain database Bab 2 dikatakan bahwa desain yang baikakan menghasilkan dekomposisi satu atau lebih relasi pertama yang dapat dibentukmenjadi beberapa relasi normal. Akan tetapi perlu diingat bahwa penguraian relasibarn akan mengakibatkan pemecahan query terhadap database lebih kompleksdibandingkan jika query tersebut dipecahkan dalam database yang terdiri dari relasiyang lebih sedikit. Oleh karena itu ada dilemma desain: haruskah desainer menguta-makan adanya semua relasi pada database dalam BCNF, atau haruskah desainermengutamakan salah satu relasi khusus untuk menyederhanakan perrtakaian data-base? Pertanyaan ini tidak bisa dijawab dengan satu jawaban.

Terdapat satu perusahaan yang telah membuat database ukuran besar di manasemua data disimpan dalam sebuah relasi meskipun bukan relasi normal pertama.Personel yang mengepalai database hendaknya menyadari sepenuhnya tentangmasalah yang dapat diperoleh tanpadatabase yang didesain untuk spesifikasi BCNF.Namun tujuan utamanya adalah kecepatan akses dan format query yang sederhana.Dia juga harus tahu kejanggalan yang mana yang dapat diuraikan sebab databasetidak terdapat pada BCNF, namun jika dia cermat dia akan mengetahui bahwakejanggalan tersebut hendaknya dihilangkan. Untuk meyakinkan masalah tersebut,pemakai hanya diberikan satu set khusus query dan meng-update pilihan; pilihan danqueiyini dapat tersedia dengan adanya software yang didesain secara khusus.

Masalah yang dibicarakan dalam paragraf terakhir ini, di mana databaseterdiri atas satu relasi non-l NF, bukan merupakan masalah yang khusus. Sebagianbesar administrator menyatakan bahwa semua database didesain sedemikian rupasehingga setiap relasi dalam semua database paling tidak terdapat dalam BCNF.Pendapat mereka adalah bahwa sebagian pemakai belum mempunyai pengetahuanyang cukup tentang teoridatabase untukmenghindari hal-hal yang tidak kita inginkanyang dapat terjadidalam desain non-BCNF. Untuk meyakinkan bahwaintegritas datadalam database telah aman (protected), desainer tentu akan memberikan nilai queryyang bertambah serta akan meng-update kompleksitasnya.

Tanpa mempertimangkan metode desain yang dipakai, jika proses desaindatabase akan berakhir, desain yang dibahas tadi harus dievaluasi berdasarkan segipraktis dan se'giteknis. Dua hal yang tidak harus ditinjau kembali dijelaskan denganpertanyaan berikut:1. Apakah pelaksanaan database yang diajukan memungkinkan query standard

dijawab dengan cukup cepat untuk digunakan? Berapa lama waktu tanggapDBMS dengan menggunakan database tersebut?

2. Dapatkah query dijawab dengan cara yang Q1asukakal, sebagai jawaban ataskebutuhim akan programmer profesional yang dapat menguraikan pemecahanquery? Jika programmerdiperlukan apakah hal ini dapat memenuhi kebutuhan?

170

Jika pertanyaan tersebut tidak terjawab maka desain itu harus dievaluasi kembali.

Ada beberapa cara yang dapat dipakai desainer untuk mempercepat respondatabase terhadap query:

1. Indekslah relasi yang secara reguler dicari dengan menggunakan atribut yangsarna.

2. Gantilah perintah-perintah, seperti JOIN, yang membutuhkan waktu pelaksanaanyang cukup lama dengan perintah yang lebih sederhana namun lebih cepat.

3. Query bisa diselesaikan dengan menggunakan program yang ditulis dalambahasa tingkat tinggi, jika tidak terdapat algoritma yang lebih singkat dan tepatuntuk menyelesaikannya.

4. Periksa kembali filosofi (dasar pemikiran) desain pertama untuk mengetahuiapakah terdapat keputusan awal yang muncul kembali dan mempengaruhiproduk akhir. Sebagai contoh adalah keputusan yang dibuat pada problemdatabase sekretaris dalam Bab 5. Keputusan itu dibuat agar tidak terjadipenyimpanan semua atribut yang isinya dapat dihitung/diketahui dari atributlain dalam database tersebut. Apakah peningkatan dalam integritas yangdiperoleh dengan keputusan ini mempunyai arti bagi bertambahnya hasil dalamwaktu pelaksanaan?

11. 4 PEMAKAIAN DATABASE CONCURRENT (BERSAMA-SAMA

Program yang disajikan pada Bab 9 dan 10adalah untuk DBMS dengan hanyasatuorangpemakai database.Banyaksistemmanajemendatabaseyangmemungkinkanuntuk dipakai oleh beberapa pemakai pada saat yang bersamaan. Dengan keadaanyang semacam ini, maka tugas pemakai adalah memahami DBMS tentang relasiyang digunakan serta bagaimana masing-masing relasi tersebut dipakai. Kemudian,tentang penggunaan relasi oleh pemakai database lainnya adalah bahwa masing-masing pemakai harus memahami bahwa DBMS adalah tempat meletakkan pem-batasan. Sebagai contoh seorang pemakai hendak mengambil informasi dari relasiR1,pada saat berlangsungnya pengambilan tersebut, maka pemakai lainnya dilarangmenghapus, mengubah, atau menyimpan tupelyang berhubungan dengan R1.Sistemyang mempunyai kemampuan seperti ini memiliki perintah khusus yang dipakaiuntuk mengontrol pemrosesan bersama-sama (concurrent). Salah satu sistemmanajemen database relasional yang paling awal yang mempunyai satu set perintahyang cukup lengkap untuk mengontrol pemrosesan secara bersama-sama adalahMulti Relational Data Store (MRDS) yang dibuat oleh Honeywell InformationSystems.

Terapan sistem manajemen database yang pasti berhubungan dengan pemro-sesan concurrent adalah pemakaian.jaringan komputer yang berhubungan dengansistem manajemen database. Dalam pelaksanaannya database tidak hanya terletakdalam satu lokasi tetapi tersebar di beberapa sistem komputer yang dihubungkan

171

bersama-sama oleh jaringan komunikasi. dBASE III dan R: base 5000 mempunyaisebagian dari kemampuan jaringan. Kita sebaiknya membaca kembali referensimanual dari pabrik untuk memperoleh keterangan yang lebih rinci.

11. 5 ADMINISTRASI DATABASEBuku ini tidak memuat usaha untuk memulai administrasi database. Masalah

yang berhubunga'ndengan pemakaianpassword dan encryption data untuk keamananatau membuat salinan backup database sehingga pengambilan kembali dapat dibuatdari kesalahan yang diakibatkan pada database merupakan hal yang sangat menarikuntuk dibahas, namun masalah itu tidak dimuat dalam buku ini.

Pada umumnya teknik yang dipakai oleh administrator untuk memperkuatkeamanan database adalah dengan menggunakan views, atau submodel. Dengandemikian seorang pemakai diperbolehkan untuk menggunakan hanya sebagian dariseluruh database. Kenyataannya database secara logis terbagi ke dalam akses khususuntuk masing-masing pemakai. Sistem manajemen database yang baru-baru inidikembangkan memiliki kemampuan seperti ini.

172