REFLEKSI DAN PERTIMBANGAN
LEBIH LANJUT
Bab ini tidak berisikan ringkasan dari seluruh desain database relasional serta pelaksanaannya. Oleh karena itu materi yang hanya merupakan bagian-bagian dari pengetahuan tentang database relasional tidak dibahas sarna sekali. Bab ini akan membicarakan refleksi dari hal-hal yang telah dibicarakan serta akan menunjukkan sedikit 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 dan 5 secara leng\capterdapat dalam kepustakaan. Metode-metode tersebut telah dipakai secara luas dan telah terbukti sebagai alat desain yang efektif. Kita ketahui bersama bahwa tidak terdapat alat desain tunggal yang dapat memberikan desain terbaik un-tuk semua masalah database yang dihadapi seorang desainer. Akan muncul masalah di mana data yang akan disimpan dalam database berhubungan sedemikian rupa sehingga diperlukan teknik desain khusus untuk memperoleh desain terbaik. Sebagai contoh, ada bentuk-bentuk yang sifatnya lebih khusus dari pada BCNF, yang telah dikembangkan untuk menghindari adanyaOkarakter yang tidak kita inginkan yang dapat muncul dalam relasi BCNF. Dua dari bentuk ini adalah 4NF dan DKINF yang secara lebih jauh dibahas dalam buku desain database tingkat lanjutan. 4FN memba-has -relasi di mana terdapat set data yang diulang, serta dekomposisi yang
menggunakan FD tidak menghilangkan hal yang berulang-ulang. Dekomposisi dalam 4NF menuntut penggunaan multi-valued dependencies (MVD's), sebuah konsep di luar isi teks ini. DK/NF (domain-key normal form), dapat dianggap sebagai bentuk normal yang terakhir dalam arti bahwa tidak terdapat modifikasi yang menyimpang dalam relasi DK/NF. Sampai sekarang belum ada teknik desain formal yang telah dibuat untuk membantu desainer memindahkan posisi relasi ke dalam bentuk normal te~but.
Terdapat dua bentuk normal yang lebih khusus dari pada BCNF. Bentuk ini yang dikenal dengan 2NF dan 3NF sangatpenting dilihat dari perspektif sejarah. 2NF dibuat untuk menghilangkan penyimpangan yang bisa muncul padarelasi INF, 3NF dibuat untuk menghilangkan penyimpangan yang dapat muncul pada relasi 2NF dan sebagainya. Sangat sedikit database yang dibuat dengan tujuan untuk mendapatkan relasi akibat hanya dalam INF atau 3NF. Kita dapat mencatat bahwa jika suatu relasi terdapat dalam BCNF maka relasi tersebut juga terdapat dalam 2NF dan 3NF:
Masalah yang berhubungan erat dengan dekomposisi relasi dari satu bentuk normal ke bentuk yang lebih tinggi adalah dekomposisi nori-Ioss.Masalah ini dibahas dalam Bab 3. Pendeknya pembahasan terhadap topik tersebut bukan berarti tidak penting. Masalah tersebut berfaedah untuk studi dan pemikiran pembaca.
11. 2
KEUNTUNGAN METODE HUBUNGAN ENTITAS
Dalam pendahuluan metode ER pada Bab 6 disebutkan bahwa metode ER mempunyai beberapa keuntungan dalam hal metode desain yang berdasarkan FD:
1. Desain mulai dengan study yang mendalam tentang masalah penyimpanan data secara keseluruhan. Metoda ini memberikan kesadaran terhadap masalah yang tengah ditangani jauh lebih banyak dari pada metode yang dimulai dengan membuat atribut dan ketergantungan fungsional.
2. Filosofi desain ER dapat diterapkan secara efektif dalam masalah yang terdapat sangat banyak atribut sehingga metode desain FD tidak dapat lagi dipakai untuk mengaturnya.
Metode ER yang diberikan dalam buku ini diharapkandapat memberikan. pengertian dasar yang baik kepada pembaca untuk memulai mengembangkan kemampuan yang diperlukan dalam memecahkan masalah-masalah desain database. Hal yang perlu diingat bagi desainer adalah bahwa FD tidak boleh dilupakan meskipun desain ini.berdasarkan pada filosofi ER. Relasidesain akhir harus dicek untuk mendapatkan bentuk yang normal.
11. 3
NORMALISASI NILAI
Pada pembahasan desain database Bab 2 dikatakan bahwa desain yang baik akan menghasilkan dekomposisi satu atau lebih relasi pertama yang dapat dibentuk menjadi beberapa relasi normal. Akan tetapi perlu diingat bahwa penguraian relasi barn akan mengakibatkan pemecahan query terhadap database lebih kompleks dibandingkan jika query tersebut dipecahkan dalam database yang terdiri dari relasi yang lebih sedikit. Oleh karena itu ada dilemma desain: haruskah desainer menguta-makan adanya semua relasi pada database dalam BCNF, atau haruskah desainer mengutamakan 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 mana semua data disimpan dalam sebuah relasi meskipun bukan relasi normal pertama. Personel yang mengepalai database hendaknya menyadari sepenuhnya tentang masalah yang dapat diperoleh tanpa database 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 database tidak terdapat pada BCNF, namun jika dia cermat dia akan mengetahui bahwa kejanggalan tersebut hendaknya dihilangkan. Untuk meyakinkan masalah tersebut, pemakai hanya diberikan satu set khusus query dan meng-update pilihan; pilihan dan queiyini dapat tersedia dengan adanya software yang didesain secara khusus.
Masalah yang dibicarakan dalam paragraf terakhir ini, di mana database terdiri atas satu relasi non-l NF, bukan merupakan masalah yang khusus. Sebagian besar administrator menyatakan bahwa semua database didesain sedemikian rupa sehingga setiap relasi dalam semua database paling tidak terdapat dalam BCNF. Pendapat mereka adalah bahwa sebagian pemakai belum mempunyai pengetahuan yang cukup tentang teoridatabase untuk menghindari hal-hal yang tidak kita inginkan yang dapat terjadi dalam desain non-BCNF. Untuk meyakinkan bahwa integritas data dalam database telah aman (protected), desainer tentu akan memberikan nilai query yang bertambah serta akan meng-update kompleksitasnya.
Tanpa mempertimangkan metode desain yang dipakai, jika proses desain database akan berakhir, desain yang dibahas tadi harus dievaluasi berdasarkan segi praktis dan se'giteknis. Dua hal yang tidak harus ditinjau kembali dijelaskan dengan pertanyaan berikut:
1. Apakah pelaksanaan database yang diajukan memungkinkan query standard dijawab dengan cukup cepat untuk digunakan? Berapa lama waktu tanggap DBMS dengan menggunakan database tersebut?
2. Dapatkah query dijawab dengan cara yang Q1asukakal, sebagai jawaban atas kebutuhim akan programmer profesional yang dapat menguraikan pemecahan query? Jika programmerdiperlukan apakah hal ini dapat memenuhi kebutuhan?
Jika pertanyaan tersebut tidak terjawab maka desain itu harus dievaluasi kembali.
Ada beberapa cara yang dapat dipakai desainer untuk mempercepat respon
database terhadap query:
1. Indekslah relasi yang secara reguler dicari dengan menggunakan atribut yang
sarna.
2. Gantilah perintah-perintah, seperti JOIN, yang membutuhkan waktu pelaksanaan
yang cukup lama dengan perintah yang lebih sederhana namun lebih cepat.
3. Query bisa diselesaikan dengan menggunakan program yang ditulis dalam
bahasa tingkat tinggi, jika tidak terdapat algoritma yang lebih singkat dan tepat untuk menyelesaikannya.
4. Periksa kembali filosofi (dasar pemikiran) desain pertama untuk mengetahui
apakah terdapat keputusan awal yang muncul kembali dan mempengaruhi
produk akhir. Sebagai contoh adalah keputusan yang dibuat pada problem
database sekretaris dalam Bab 5. Keputusan itu dibuat agar tidak terjadi
penyimpanan semua atribut yang isinya dapat dihitung/diketahui dari atribut
lain dalam database tersebut. Apakah peningkatan dalam integritas yang
diperoleh dengan keputusan ini mempunyai arti bagi bertambahnya hasil dalam waktu pelaksanaan?
11. 4
PEMAKAIAN DATABASE CONCURRENT
(BERSAMA-SAMA
Program yang disajikan pada Bab 9 dan 10 adalah untuk DBMS dengan hanya satuorangpemakai database. Banyaksistemmanajemendatabaseyangmemungkinkan untuk dipakai oleh beberapa pemakai pada saat yang bersamaan. Dengan keadaan yang semacam ini, maka tugas pemakai adalah memahami DBMS tentang relasi yang 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 relasi R 1,pada saat berlangsungnya pengambilan tersebut, maka pemakai lainnya dilarang menghapus, mengubah, atau menyimpan tupel yang berhubungan dengan R 1. Sistem yang mempunyai kemampuan seperti ini memiliki perintah khusus yang dipakai untuk mengontrol pemrosesan bersama-sama (concurrent). Salah satu sistem manajemen database relasional yang paling awal yang mempunyai satu set perintah yang cukup lengkap untuk mengontrol pemrosesan secara bersama-sama adalah Multi Relational Data Store (MRDS) yang dibuat oleh Honeywell Information Systems.
Terapan sistem manajemen database yang pasti berhubungan dengan pemro-sesan concurrent adalah pemakaian.jaringan komputer yang berhubungan dengan
bersama-sama oleh jaringan komunikasi. dBASE III dan R: base 5000 mempunyai sebagian dari kemampuan jaringan. Kita sebaiknya membaca kembali referensi manual dari pabrik untuk memperoleh keterangan yang lebih rinci.
11. 5 ADMINISTRASI DATABASE
Buku ini tidak memuat usaha untuk memulai administrasi database. Masalah yang berhubunga'ndengan pemakaian password dan encryption data untuk keamanan atau membuat salinan backup database sehingga pengambilan kembali dapat dibuat dari kesalahan yang diakibatkan pada database merupakan hal yang sangat menarik untuk dibahas, namun masalah itu tidak dimuat dalam buku ini.
Pada umumnya teknik yang dipakai oleh administrator untuk memperkuat keamanan database adalah dengan menggunakan views, atau submodel. Dengan demikian seorang pemakai diperbolehkan untuk menggunakan hanya sebagian dari seluruh database. Kenyataannya database secara logis terbagi ke dalam akses khusus untuk masing-masing pemakai. Sistem manajemen database yang baru-baru ini dikembangkan memiliki kemampuan seperti ini.
