Pa
g
e
9
BAB 3 Proses Desain Database
Tujuan Pembelajaran Umum
Mahasiswa mampu mendesain database sederhana
Tujuan pembelajaran khusus
Mahasiswa mampu dan dapat menjelaskan proses desain database
alah satu cara yang terbaik untuk mengerti mengenai proses desain database adalah dengan memulai men-desain sebuat tabel flat-file dan kemudian masukkan sampel data ke dalam tabel untuk melihat apa yang terjadi. Dengan menganalisa contoh data, Anda dapat meng-identifikasi permasalahan yang disebabkan oleh desain awal tersebut. Anda dapat memodifikasi desain untuk menghilangkan masalah, coba lagi beberapa contoh data, cek masalah yang terjadi, modifikasi kembali, lanjutkan proses ini sampai Anda mendapatkan tabel yang konsisten dan bebas masalah.
Sekali Anda bisa menyesuaikan diri dengan masalah yang timbul dalam pembuatan tabel, Anda diharapkan untuk bisa melompati beberapa langkah desain dan langsung menuju desain tabel final.
Contoh Proses Desain
Kita akan mendesain sebuah database untuk mengetahui aktivitas olahraga para siswa. Kita akan mengikuti setiap aktivitas yang diikuti siswa dan bayaran per semester untuk melakukan aktivitas tersebut.
Step 1:Buat Tabel Aktivitas yang berisi field-field berikut: nama siswa, aktivitas dan biaya. Karena beberapa siswa mengambil lebih dari satu aktivitas, kita akan mengijinkan hal tersebut dan menambahkan field aktivitas kedua dan juga field biaya untuk aktivitas kedua. Sehingga struktur tabel kita adalah: Siswa, Aktivitas 1, Biaya 1, Aktivitas 2, Biaya 2.
Step 2 : Tes tabel dengan beberapa contoh data. Ketika Anda membuat contoh data, Anda harus melihat apa yang tabel ada dapat perbuat.Misalnya, tidak ada yang mencegah kita untuk memasukkan nama yang sama untuk siswa yang berbeda, atau biaya yang berbeda untuk aktivitas yang sama, dan lain-lain. Anda juga harus membayangkan membuat pertanyaan untuk data Anda dan mendapatkan jawaban (query data dan repport data). Contohnya, bagaimana saya dapat menemukan semua siswa yang mengambil aktivitas tenis?
Tabel Aktivitas Siswa
Siswa Aktivitas 1 Biaya 1 Aktivitas 2 Biaya 2
Ogi Tenis 36 000 Renang 17 000 Agung Catur 40 000 Renang 17 000 Ogi Tenis 36 000
Mega Renang 15 000 Golf 47 000
Step 3 : Analisa Data. Pada kasus ini, kita jelas mendapat masalah pada field pertama. Kita punya dua Ogi, dan kita tidak dapat memisahkan keduanya. Kita harus menemukan cara untuk mengidentifikasi tiap siswa secara unik.
Identifikasi Record Unik
Mari kita perbaiki masalah kita, kemudian kita cek lagi hasilnya.
Step 4: Modifikasi Desain. Kita dapat mengidentifikasi setiap siswa secara unik dengan memberi ID yang unik, Field baru yang kita tambahkan, adalah field ID. Kita pisahkan field Siswa dan tambahkan field ID. Catat bahwa tanda asterisk (*) dibelakang nama field ini
menunjukkan bahwa field ini adalah field kunci, berisi nilai yang unik untuk setiap record. Kita dapat menggunakan field tersebut untuk menampilkan record yang manapun secara spesifik. Ketika Anda membuat field kunci tersebut pada program database, program tersebut akan mencegah Anda untuk memasukkan nilai duplikasi pada field ini, untuk menjaga keunikan setiap record atau entry data.
g
e
10
Struktur tabel kita saat ini adalah: ID, Aktivitas 1, Biaya 1, Aktivitas 2, Biaya 2.
Tabel Aktivitas Siswa
ID* Aktivitas 1 Biaya 1 Aktivitas 2 Biaya 2
101 Tenis 36 000 Renang 17 000 102 Catur 40 000 Renang 17 000 103 Tenis 36 000
201 Renang 15 000 Golf 47 000
Komputer akan dengan mudah mengikuti jejak kode ID tersebut, tetapi hal ini tidak akan terlalu berguna untuk manusia. Karena itu kita akan membuat tabel kedua yang berisi daftar setiap ID dan siswa yang memiliki ID tersebut. Dengan menggunakan program database, secara gampang dapat kita buat kedua struktur tabel tersebut dan menghubungkannya dengan
menggunakan field ID. Kini kita mengubah tabel flat-file kita menjadi database relasional: database yang berisi banyak tabel yang dihubungkan dengan field kunci.
Tabel Siswa biasanya berisi nama awal, nama akhir, alamat, umur dan lainnya, dan juga ID. Untuk menjaga kemudahan kita akan membatasi tabel siswa dengan dua field saja yaitu nama dan ID siswa, dan kita akan fokus pada struktur tabel aktivitas siswa.
Step 5 : Tes Tabel dengan Contoh Data
Tabel Aktivitas Siswa
ID* Aktivitas 1 Biaya 1 Aktivitas 2
Biaya 2
101 Tenis 36 000 Renang 17 000
102 Catur 40 000 Renang 17 000
103 Tenis 36 000
201 Renang 15 000 Golf 47 000
Step 6: Analisa Data
Ternyata masih banyak kesalahan pada tabel aktivitas siswa.
1. Ruang terbuang. Tidak semua siswa mengambil aktivitas kedua, karena itu kita akan membuang percuma ruang yang ada pada saat kita menyimpan data. Hal ini tampaknya tidak akan terlalu mengganggu pada tabel ini, tetapi bagaimana bila kita berurusan dengan ribuan atau jutaan data?
2. Kesalahan Penambahan data. Bagaimana jika #201 ingin melakukan aktivitas ketiga? Sekolah memperbolehkan, tetapi tidak ada ruang pada struktur ini untuk aktivitas yang lain. Kita tidak dapat menambahkan record yang lain atas nama Mega karena akan merusak keunikan field ID, dan juga akan mempersulit apabila kita ingin melihat datanya secara keseluruhan dalam satu kesempatan.
3. Entry data yang berlebihan. Jika biaya tenis naik menjadi 39 000, kita harus merubah semua record yang berisi tenis dan memodifikasi biayanya.
4. Kesulitan query. Akan sangat sulit untuk melihat semua siswa yang melakukan aktivitas renang: kita harus mencari pada aktivitas 1 dan 2 untuk memastikan kita mendapat semuanya.
5. Informasi berlebih. Jika 50 siswa mengambil renang, kita harus memasukkan data dalam field aktivitas dan biaya untuk setiap siswa.
6. Data tidak Konsisten. Perhatikan bahwa terdapat dua harga untuk renang. Apakah 15 000 atau 17 000? Mana yang seharusnya? Hal ini terjadi jika satu record di-update sedangkan yang lain tidak.
Hilangkan field yang berulang.
Tabel Siswa masih bisa diterima, jadi kita akan menyimpannya. Tetapi, banyak yang kurang tepat pada tabel aktivitas siswa. Mari kita coba untuk memperbaikinya.
Tabel Siswa
Siswa ID*
Ogi 101
Agung 102
Ogi 103
Pa
g
e
11
Step 7 : Modifikasi desain. Kita dapat memperbaiki empat masalah kita yang pertama dengan membuat record yang terpisah untuk setiap aktivitas yang diambil oleh siswa, daripada satu record untuk semua aktivitas yang diambil oleh siswa.
Pertama kita hilangkan field Aktivitas 2 dan Biaya 2, kemudian kita harus menyesuaikan struktur tabel sehingga kita dapat memasukkan banyak record untuk setiap siswa. Untuk melakukan hal itu, kita re-definisikan field kunci yang ada sehingga akan terdiri dari dua field, ID dan Aktivitas. Karena setiap siswa hanya boleh mengambil satu aktivitas dalam satu
kesempatan, maka kombinasi ini akan menciptakan kunci yang unik untuk setiap record.
Tabel aktivitas kita kini sudah disederhanakan menjadi: ID, Aktivitas, Biaya. Catat bagaimana struktur tabel yang baru tidak membatasi kegiatan yang diambil oleh siswa
Step 8 : Tes Contoh Data
ID* Aktivitas 1 Biaya 1
101 Tenis 36 000
101 Renang 17 000
102 Catur 40 000
102 Renang 17 000
103 Tenis 36 000
201 Renang 15 000
201 Golf 47 000
201 Catur 40 000
Step 9: Analisa Data. Kita tahu kita masih punya masalah dengan data berlebih (biaya aktivitas berulang), data tidak konsisten (Berapa biaya sebenarnya untuk renang?) Kita harus
memperbaikinya, dimana keduanya adalah masalah editing atau modify data.
Hilangkan penyimpangan entry data
Sebaiknya, kita juga harus melihat apakah fungsi data yang lain berjalan dengan baik, seperti tambah atau hapus data.
Jika Anda melihat secara teliti, Anda akan menemukan bahwa ada masalah potensial ketika kita menambah atau menghapus data:
- Penyimpangan Penambahan. Bagaimana jika sekolah kita mengenalkan aktivitas yang baru, seperti, Karambol, dengan biaya 10 000. Dimana kita dapat menyimpan informasi ini? Dengan desain kita yang terakhir, kita tidak dapat menyimpannya sampai ada siswa yang mendaftar.
- Penyimpangan Penghapusan. Jika Mega (#201) pindah ke almamater yang lain, semua informasi mengenai golf, akan hilang dari database kita, karena hanya dia yang mengambil aktivitas ini.
Step 10 : Modifikasi Desain. Akar permasalahan kita untuk kedua hal yang tersisa adalah karena kita mempunyai field bukan-kunci yang tergantung kepada sebagian field kunci (biaya terhadap aktivitas). Biaya untuk setiap aktivitas tidak tergantung kepada ID siswa, yang merupakan bagian dari field kunci kita (ID + Aktivitas). Biaya tenis, misalnya, akan tetap 36 000, siapapun juga siswa yang mengambilnya- jadi ID siswa tidak mempunyai pengaruh terhadap nilai yang tersimpan dalam field ini. Biaya aktivitas murni hanya tergantung dari aktivitasnya itu sendiri. Dengan memeriksa struktur tabel kita dan memastikan bahwa semua field bukan-kunci tergantung pada field kunci, kita akan menghilangkan semua permasalahan kita yang tersisa.
Desain final kita akan terdiri dari tiga tabel: Tabel Siswa, Tabel Partisipan, Tabel Aktivitas yang dimodifikasi.
Tabel Siswa
Siswa ID*
Ogi 101
Agung 102
Ogi 103
g
e
12
Jika anda periksa tabel ini, terlihat bahwa semua field bukan-kunci bergantung pada field kunci: nama siswa bergantung kepada ID siswa; biaya aktivitas bergantung kepada aktivitas. Tabel partisipan kita dasarnya adalah data yang sudah terdapat pada tabel yang lain, dan setiap fieldnya merupakan field kunci.
Step 8 : Tes Contoh Data
Step 11: Tes Contoh Data.
Step 12 : Analisa Hasil. Tabel-tabel ini terlihat bagus:
-
Tidak ada informasi berlebih. Anda hanya perlu mendata biaya aktivitas
sekali saja.
-
Tidak ada inkonsistensi data. Hanya ada satu tempat dimana Anda
memasukkan biaya tiap aktivitas, jadi tidak ada kesempatan untuk membuat
data yang tidak konsisten. Apabila ada kenaikan harga, Anda hanya perlu
meng-update data yang ada.
-
Tidak ada penyimpangan penambahan. Anda dapat menambah aktivitas baru
ke dalam tabel aktivitas tanpa harus menunggu siswa yang mendaftar.
-
Tidak ada penyimpangan penghapusan. Jika #201 pindah, kita masih punya
data tentang golf.
Rangkuman
Walaupun desain database Anda tergantung dari seberapa kompleks data yang anda
miliki, setiap kali Anda mendesain database, pastikan hal berikut ini terpenuhi:
-
Field yang terdiri dari dua bagian, pecahkan menjadi dua, misalnya nama
menjadi Nama awal dan Nama akhir.
-
Buat field kunci yang akan mengidentifikasi record secara unik. Anda
mungkin perlu membuat field ID (dengan tabel lookup untuk melihat
nilainya).
-
Hilangkan field yang berulang. Misal: jika tabel anda terdiri dari field
lokasi1, lokasi 2, lokasi 3 yang berisi data yang mirip, ini merupakan
peringatan yang jelas.
Tabel Siswa
Siswa ID*
Ogi 101
Agung 102
Ogi 103
Mega 201
ID* Aktivitas*
101 Tenis
101 Renang
102 Catur
102 Renang
103 Tenis
201 Renang
201 Golf
201 Catur
Tabel Aktivitas
Aktivitas*
Biaya
Tenis
36 000
Renang
17 000
Catur
40 000
Golf
47 000
Pa
g
e
13
-
Hilangkan masalah modifikasi record dengan memastikan bahwa
tiap field
bukan-kunci tergantung sepenuhnya pada field kunci
. Untuk melakukan ini,
