bab11 refleksi dan pertimbangan lebih lanjut
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 untuk 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 membahas -relasi di mana terdapat set data yang diulang, serta dekomposisi yang
168
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 diberikandalam 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.
169
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 mengutamakan adanya semua relasi pada database dalam BCNF, atau haruskah desainer
mengutamakan salah satu relasi khusus untuk menyederhanakan perrtakaian database? 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?
170
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.
3.
4.
Gantilah perintah-perintah, seperti JOIN, yang membutuhkan waktu pelaksanaan
yang cukup lama dengan perintah yang lebih
sederhana namun lebih cepat.
Query bisa diselesaikan dengan menggunakan program yang
ditulis dalam
bahasa tingkat tinggi, jika tidak terdapat algoritma yang lebih singkat dan tepat
untuk menyelesaikannya.
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 (BERSAMASAMA
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 masingmasing pemakai harus memahami bahwa DBMS adalah tempat meletakkan pembatasan. Sebagai contoh seorang pemakai hendak mengambil informasi dari relasi
R1,pada saat berlangsungnya pengambilan tersebut, maka pemakai lainnya dilarang
menghapus, mengubah, atau menyimpan tupel yang berhubungan dengan R1.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 pemrosesan concurrent adalah pemakaian.jaringan komputer yang berhubungan dengan
sistem manajemen database. Dalam pelaksanaannya database tidak hanya terletak
dalam satu lokasi tetapi tersebar di beberapa sistem komputer yang dihubungkan
171
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.
172
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 untuk 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 membahas -relasi di mana terdapat set data yang diulang, serta dekomposisi yang
168
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 diberikandalam 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.
169
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 mengutamakan adanya semua relasi pada database dalam BCNF, atau haruskah desainer
mengutamakan salah satu relasi khusus untuk menyederhanakan perrtakaian database? 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?
170
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.
3.
4.
Gantilah perintah-perintah, seperti JOIN, yang membutuhkan waktu pelaksanaan
yang cukup lama dengan perintah yang lebih
sederhana namun lebih cepat.
Query bisa diselesaikan dengan menggunakan program yang
ditulis dalam
bahasa tingkat tinggi, jika tidak terdapat algoritma yang lebih singkat dan tepat
untuk menyelesaikannya.
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 (BERSAMASAMA
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 masingmasing pemakai harus memahami bahwa DBMS adalah tempat meletakkan pembatasan. Sebagai contoh seorang pemakai hendak mengambil informasi dari relasi
R1,pada saat berlangsungnya pengambilan tersebut, maka pemakai lainnya dilarang
menghapus, mengubah, atau menyimpan tupel yang berhubungan dengan R1.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 pemrosesan concurrent adalah pemakaian.jaringan komputer yang berhubungan dengan
sistem manajemen database. Dalam pelaksanaannya database tidak hanya terletak
dalam satu lokasi tetapi tersebar di beberapa sistem komputer yang dihubungkan
171
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.
172