LAPORAN PENELITIAN
PEMANFAATAN FIELD MEMO UNTUK MINIMALISASI DUPLIKASI RINCI DATA PADA KUNCI PENGHUBUNG
OLEH : EDHY SUTANTA JURUSAN TEKNIK INFORMATIKA
FAKULTAS TEKNOLOGI INDUSTRI INSTITUT SAINS & TEKNOLOGI AKPRIND YOGYAKARTA 2002 i
HALAMAN PENGESAHAN 1. Judul Penelitian : PEMANFAATAN FIELD MEMO UNTUK MINIMALISASI DUPLIKASI RINCI DATA PADA KUNCI PENGHUBUNG 2. Bidang Ilmu : Teknik Informatika 3. Kategori Penelitian : Analisis / Kajian Teori 4. Peneliti : a. Nama lengkap : Edhy Sutanta, S.T. b. NIK : 96.0372.515.E c. Pangkat / Golongan : Penata / III-C d. Jabatan : Lektor e. Bidang ilmu : Teknik Informatika f. Lembaga : Jurusan Teknik Informatika, Fakultas Teknologi Industri, Institut Sains & Teknologi AKPRIND Yogyakarta 5. Jangka waktu penelitian : 4 (empat) bulan 6. Biaya yang diperlukan : Rp.1.000.000,00 (Satu Juta Rupiah) Yogyakarta, 30 Juli 2002 Peneliti, Edhy Sutanta, S.T. Mengetahui Jurusan Teknik Informatika,
Menyetujui Pembimbing,
Uning Lestari, S.T. Sekretaris Jurusan
Ir. Soedjatmiko, M.Sc. NIP. 130 227 850 Mengetahui,
Lembaga Penelitian,
Dekan Fak. Teknologi Industri.
Ir. Hj. Titin Isna Oesman, M.M.
Dra. Naniek Widyastuti, M.T. NIK. 131761418
ii
SURAT KETERANGAN KARYA ILMIAH Dengan ini kami : Nama lengkap NIP Jabatan Bidang ilmu Lembaga
: Ir. Soedjatmiko, M.Sc. : 130 227 850 : Lektor Kepala : Teknik Elektro : Jurusan Teknik Elektro, Fakultas Teknik Universitas Gadjah Mada, Yogyakarta
Memberikan rekomendasi untuk karya ilmiah dengan judul : PEMANFAATAN FIELD MEMO UNTUK MINIMALISASI DUPLIKASI RINCI DATA PADA KUNCI PENGHUBUNG Atas nama Saudara tersebut di bawah ini : a. Nama lengkap : Edhy Sutanta, S.T. b. NIK : 96.0372.515.E c. Pangkat / Golongan : Penata / III-C d. Jabatan : Lektor e. Bidang ilmu : Teknik Informatika f. Lembaga : Jurusan Teknik Informatika, Fakultas Teknologi Industri, Institut Sains & Teknologi AKPRIND Yogyakarta Isi rekomendasi karya ilmiah itu sebagai berikut : a. Mutu
: Amat Baik / Baik / Cukup / Kurang
b. Sofistifikasi
: Amat Baik / Baik / Cukup / Kurang
c. Kemutakhiran
: Amat Baik / Baik / Cukup / Kurang Yogyakarta, 30 Juli 2002 Yang memberi rekomendasi
Ir. Soedjatmiko, M.Sc. NIP. 130 227 850
iii
SURAT KETERANGAN KARYA ILMIAH Dengan ini kami : Nama lengkap NIK Jabatan Bidang ilmu Lembaga
: Dra. Hj. Naniek Widyastuti, M.T. : 131 761 418 : Lektor : Informatika : Fakultas Teknologi Industri Institut Sains & Teknologi AKPRIND Yogyakarta
Memberikan rekomendasi untuk karya ilmiah dengan judul : PEMANFAATAN FIELD MEMO UNTUK MINIMALISASI DUPLIKASI RINCI DATA PADA KUNCI PENGHUBUNG Atas nama Saudara tersebut di bawah ini : a. Nama lengkap : Edhy Sutanta, S.T. b. NIK : 96.0372.515.E c. Pangkat / Golongan : Penata / III-C d. Jabatan : Lektor e. Bidang ilmu : Teknik Informatika f. Lembaga : Jurusan Teknik Informatika, Fakultas Teknologi Industri, Institut Sains & Teknologi AKPRIND Yogyakarta Isi rekomendasi karya ilmiah itu sebagai berikut : a. Mutu
: Amat Baik / Baik / Cukup / Kurang
b. Sofistifikasi
: Amat Baik / Baik / Cukup / Kurang
c. Kemutakhiran
: Amat Baik / Baik / Cukup / Kurang Yogyakarta, 30 Juli 2002 Yang memberi rekomendasi
Dra. Hj. Naniek Widyastuti, M.T. NIK. 131 761 418
iv
KATA PENGANTAR Puji syukur Penulis panjatkan ke hadirat Tuhan Yang Maha Kuasa, karena atas rahmat dan ijin-Nya laporan penelitian ini dapat terselesaikan. Pada kesempatan ini Penulis menyampaikan ucapkan terimakasih dan penghargaan yang sebesar-besarnya kepada berbagai pihak yang telah membantu kelancaran dan terlaksananya penelitian ini, yaitu : 1.
Rektor Institut Sains & Teknologi AKPRIND Yogyakarta
2.
Dekan Fakultas Teknologi Industri IST AKPRIND Yogyakarta
3.
Kepala Lembaga Penelitian IST AKPRIND Yogyakarta
4.
Bapak Ir. Soedjatmiko, M.Sc., selaku Pembimbing Penelitian
5.
Ibu Dra. Hj. Naniek Widyastuti, M.T., atas masukan dan sarannya
6.
Bapak Ir. Amir Hamzah, M.T., atas masukan dan sarannya
7.
Rekan-rekan di Jurusan Teknik Informatika dan Laboratorium Komputer IST AKPRIND Yogyakarta
8.
Sdr. Herry Hernawan Soedjer, S.T., atas kesempatan berdiskusi
9.
Istri dan putriku tercinta, terimakasih atas perhatian dan pengertiannya
10. Semua pihak yang telah mendukung penelitian ini Penulis menyadari bahwa hasil penelitian ini masih mengandung kedangkalan dan kekurangan, oleh karena itu umpan balik dan saran dari para pemerhati dan Pembaca akan membantu demi kesempurnaan pada masa mendatang. Akhirnya, Penulis berharap agar penelitian ini dapat bermanfaat. Yogyakarta, 30 Juli 2002 Penulis
v
INTISARI Teknik normalisasi merupakan salah satu teknik yang sangat populer dan banyak digunakan dalam perancangan basis data. Proses normalisasi akan menghasilkan record yag konsisten secara logik, mudah untuk dimengerti, sederhana dalam pemeliharaan, serta mudah ditampilan kembali. Basis data umumnya telah optimal jika memenuhi kriteria bentuk normal ketiga (Third Norm Form / 3NF). Pada kenyataannya, penerapan normalisasi mengakibatkakn efek samping, salah satunya adalah terjadinya duplikasi rinci data pada atribut yang berfungsi sebagai kunci penghubung (Foreign Key / FK). Duplikasi rinci data dalam jumlah yang besar akan memerlukan media penyimpan sekunder (secondary memory) yang semakin besar dan tidak efisien. Penelitian ini membahas bagaimana melakukan optimalisasi basis data dengan memanfaatkan field bertipe memo untuk mengatasi permasalahan duplikasi rinci data yang terjadi pada FK dengan dibatasi pada pemanfaatan field bertipe memo untuk mengatasi duplikasi rinci data pada FK. Hasil penelitian diharapkan menghasilkan panduan umum bagi para perancang basis data untuk merlakukan optimalisasi basis data. Penelitian dilakukan dengan mengkaji terjadinya duplikasi rinci data dan selanjutnya dianalisis untuk mengetahui sejauh mana field bertipe memo tersebut dapat dimanfaatkan untuk mengatasi permasalahan tersebut. Berdasarkan hasil penelitian ini, diperoleh hasil bahwa pemanfaatan field memo dapat meminimalkan terjadinya duplikasi rinci data pada kunci penghubung dan meningkatkan efisiensi penggunaan media penyimpan hingga sebesar : 55,1 %, Pemanfaatan field memo tepat diterapkan pada basis data yang melibatkan tabel / relasi bertipe transaksi dengan jumlah record yang besar, dalam arti bahwa tabel / relasi tersebut memiliki item rincian dalam jumlah besar. Penggunaan filed memo sebagimana penelitian ini tidak melanggar batasan - batasan dalam perancangan basis data. Pemanfaatan field memo memerlukan mekanisme khusus untuk pengelolaan nilai rinci data dalam field memo yang berisi teks. Pemanfaatan field memo memerlukan kecermatan dan pandangan jauh ke depan agar dapat mengantisipasi berbagai kemungkinan yang dapat terjadi berkaitan perancangan pengkodean nilai rinci data dalam field memo. Kata kunci : duplikasi rinci data, kunci penghubung, field memo
vi
DAFTAR ISI Halaman : Halaman Judul Halaman Pengesahan Surat Keterangan Karya Ilmiah Surat Keterangan Karya Ilmiah Kata Pengantar Intisari Daftar Isi
i ii iii iv v vi
BAB I. PENDAHULUAN 1.1. Latar Belakang Masalah 1.2. Rumusan Masalah 1.3. Batasan Masalah 1.4. Kontribusi Penelitian 1.5. Metodologi Penelitian BAB II. TINJAUAN PUSTAKA 2.1. Pengertian Basis Data 2.2. Model Basis Data Relasional 2.3. Kunci Relasi 2.4. Normalisasi 2.5. Tinjauan Beberapa Paket Aplikasi Basis Data BAB III. ANALISIS DAN PEMBAHASAN 3.1. Penerapan Normalisasi Basis Data 3.2. Efek Normalisasi 3.3. Studi Kasus Penerapan Normalisasi 3.4. Pemanfaatan Field Bertipe Memo 3.5. Keuntungan dan Kelemahan Penggunaan Field Bertipe Memo BAB IV KESIMPULAN DAN SARAN 5.1. Kesimpulan 5.2. Saran
1 1 2 2 3 3 4 4 9 12 14 18 25 25 26 30 46 54
Daftar Pustaka Daftar Karya Ilmiah yang Dihasilkan Penulis
57 58
vii
56 56 56
BAB I PENDAHULUAN
1.1.
Latar Belakang Permasalahan Dalam perancangan basis data model relasional (Relational Database
Model / RDBM) dikenal suatu teknik yang sangat populer, yaitu teknik normalisasi. Normalisasi diartikan sebagai suatu teknik yang menstrukturkana data dalam cara-cara tertentu untuk mencegah atau mengurangi timbulnya permasalahan yang berhubungan dengan pengolahan data dalam basis data. Proses normalisasi akan menghasilkan record yang konsisten secara logik, mudah untuk dimengerti, sederhana dalam pemeliharaan, serta mudah ditampilan kembali (Martin, 1976). Perancangan basis data pada umumnya telah optimal jika telah memenuhi kriteria bentuk normal ketiga (Third Norm Form / 3NF). Pembahasan tentang normalisasi seolah - olah merupakan penyelesaian yang sempurna. Sebagaimana terjadi pada hampir semua usaha pemecahan permasalahan, (tidak hanya terbatas pada basis data) akan menimbulkan efek samping yang negatif. Pada kenyataannya, penerapan normalisasi juga mengakibatkakn efek samping yang tidak diharapkan, salah satunya adalah terjadinya duplikasi rinci data pada atribut yang berfungsi sebagai kunci penghubung (Foreign Key / FK). Prose normalisasi akan menghasilkan tabel-tabel baru yang lebih sederhana. Tabel-tabel baru hasil dekomposisi dalam proses normalisasi harus tetap saling 1
berhubungan, sehingga tabel-tabel baru tersebut akan memerlukan kunci penghubung (Foreign Key / FK) untuk menghubungkan antar tabel baru tersebut. Semakin banyak tabel baru yang terbentuk, maka duplikasi rinci data yang muncul dalam tabel akan semakin banyak pula. Duplikasi rinci data dalam jumlah yang besar tersebut, akan memerlukan media penyimpan sekunder (secondary memory) yang semakin besar dan tidak efisien (Sutanta, 1999). Penggunaan field bertipe memo dalam perancangan basis data yang telah dinormalisasi diharapkan menjadi alternatif penyelesaian permasalahan duplikasi rinci data pada kunci penghubung (Foreign Key / FK).
1.2. Rumusan Permasalahan Berdasarkan latar belakang permasalahan di atas, maka permasalahan yang akan dibahas dalam penelitian ini adalah bagaimana melakukan optimalisasi basis data dengan memanfaatkan field bertipe memo untuk mengatasi permasalahan duplikasi rinci data yang terjadi pada kunci penghubung (Foreign Key / FK) .
1.3. Batasan Permasalahan Permasalahan yang akan dibahas dalam penelitian ini dibatasi pada hal-hal sebagai berikut : 1.
Pemanfaatan field bertipe memo untuk mengatasi duplikasi rinci data pada kunci penghubung (Foreign Key / FK) 2
2.
Merancang panduan umum untuk pemanfaatan field bertipe memo dalam perancangan basis data model relasional (Relational Database Model / RDBM).
1.4. Kontribusi Penelitian Hasil penelitian diharapkan menghasilkan panduan umum bagi para perancang basis data untuk merlakukan optimalisasi basis data khususnya melalui pemanfaatan field bertipe memo.
1.5. Metodologi Penelitian Penelitian ini diawali dengan mengkaji terjadinya duplikasi rinci data akibat penerapan teknik normalisasi dalam perancangan basis data model relasional (Relational Database Model / RDBM) dan karakteristik field bertipe memo. Selanjutnya dianalisis untuk mengetahui sejauh mana field bertipe memo tersebut dapat dimanfaatkan untuk mengatasi permasalahan tersebut. Hasil kajian dan analisis tersebut kemudian disokumentasikan sebagai laporan penelitian yang memuat panduan umum pemanfaatan field memo dalam perancangan basis data basis data model relasional (Relational Database Model / RDBM).
3
4
BAB II. TINJAUAN PUSTAKA
2.1. Pengertian Basis Data Dalam beberapa literatur, pengertian basis data telah didefinisikan dengan cara yang berbeda-beda. Salah satu pengertian yang lazim digunakan adalah pengertian yang didefinisikan oleh James Martin (1975), yaitu : A database may be defined as a collection of interrelated data stored together without harmful or unnecessary redundancy to serve one or more applications in an optimal fashion; the data are stored so that they are independent of programs with use the data; a common and controlled approach its used in adding new data and in modifying and retrieving existing data within the database. Dengan memahami pengertian di atas, dipahami
sebagai suatu kumpulan
data
maka istilah basis data dapat
terhubung (interrelated data) yang
disimpan secara bersama-sama pada suatu media, tanpa “mengatap” satu sama lain atau
tidak perlu
suatu kerangkapan data dan kalaupun ada maka
kerangkapan data tersebut harus seminimal mungkin dan terkontrol (controlled redundancy), data disimpan dengan cara-cara tertentu sehingga mudah untuk digunakan / atau ditampilkan kembali; data dapat digunakan oleh satu atau lebih program-program aplikasi secara optimal; data disimpan tanpa mengalami ketergantungan dengan program yang akan menggunakannya; data disimpan sedemikian rupa sehingga proses penambahan, pengambilan dan modifikasi data dapat dilakukan dengan mudah dan terkontrol. Berdasarkan pengertian tersebut, maka suatu basis data mempunyai beberapa kriteria yang penting yaitu :
5
1. Berorientasi pada data (data oriented) dan bukan berorientasi pada program yang akan menggunakannya (program oriented) 2. Data dapat digunakan oleh pemakai yang berbeda-beda atau beberapa program aplikasi tanpa perlu mengubah basis data 3. Data dapat berkembang dengan mudah baik volume maupun strukturnya 4. Data yang ada dapat memenuhi kebutuhan sistem-sistem baru secara mudah 5. Data dapat digunakan dengan cara yang berbeda-beda 6. Kerangkapan data (data redundancy) minimal Untuk memenuhi kriteria sebagai sebuah basis data, maka terdapat lima jenis kekangan (aturan yang harus ditaati) dalam basis data, yaitu (Martin, 1975): 1. Minimalisasi
kerangkapan
data
(controlled data redundancy),
yaitu
munculnya data-data yang sama secara berulang / melimpah pada satu atau lebih tabel basis data yang semestinya tidak diperlukan. Kerangkapan data perlu diminimalisasi karena dapat mengakibatkan pemborosan media dan beaya penyimpanan, kesulitan dalam pengolahan, pemborosan waktu pengolahan, serta meningkatnya kemungkinan terjadinya inkosistensi data dalam basis data. Penyebab terjadinya kerangkapan data adalah proses desain basis data yang tidak dilakukan baik. 2. Menghindari inkonsistensi data (data incosistency), yaitu munculnya data-data tidak konsisten pada atribut / kolom yang sama dalam satu atau lebih tabel basis data. Inkosistensi data perlu dihindari dalam basis data karena akan mengakibatkan kesalahan informasi yang disajikan dari basis data. Inkosistensi data biasanya terjadi akibat desian basis data yang tidak baik,
6
proses entry data yang tidak benar, proses update yang tidak lengkap, atau pengendalian yang tidak terkontrol dalam sistem. 3. Menghindari data terisolasi, terjadi akibat sebagian tabel basis data dalam basis data tidak dapat dihubungkan dengan tabel yang lain, sehingga data-data dalam tabel tersebut tidak dapat diakses oleh sistem aplikasi. Penyebab inkosistensi data anatara lain adalah format data yang tidak seragam atau tidak adanya kunci penghubung (Foreign Key / FK) yang dapat digunakan untuk menghubungkan dengan tabel yang lain. 4. Menjaga keamanan data (data security), berhubungan dengan masalah pembatasan kewenangan akses data dalam basis data dan perlindungan data dalam basis data dari kerusakan / kehilangan. Kewenangan akses data dalam basis data dapat dilakukan oleh program aplikasi secara internal atau dikendalikan melalui sistem pengelolaan basis data (database management systems / DBMS) atau dapat pula dilakukan dengan memanfaatkan sistem operasi (operting systems / OS) yang digunakan. 5. Menjaga integritas data (data integrity), dimaksudkan sebagai suatu sarana untuk meyakinkan dan menjaga agar data-data dalam basis data selalu berada dalam kondisi yang benar, konsisten, dan selalu tersedia (current) setiap saat diperlukan. Aturan integritas ini berhubungan dengan unjuk kerja sistem agar dapat melakukan kendali pada semua bagian sistem agar selalu beroperasi dalam pengendalian yang penuh. James Martin (1976) juga menyatakan bahwa enam kriteria di atas telah membedakan secara jelas antara pengolahan data secara basis data (database
7
procesing) dan pengolahan data secara secara berkas / konvensional (file processing). Organisasi dan pengolahan data secara berkas / konvensional umumnya mempunyai ciri sebagai berikut : 1. Berorientasi pada program aplikasi tertentu (program oriented) 2. Berhubungan dengan suatu persoalan tertentu untuk sistem yang telah direncanakan 3. Perkembangan hanya dimungkinkan terjadi pada volume data saja 4. Data hanya dapat digunakan dengan satu cara tertentu 5. Banyak muncul kerangkapan data (data redundancy) S. Atre (1980) mendefinisikan basis data sebagai berikut: “A collection of related data about an enterprise with multiple uses. In a database the data definitions and the relations between the data are separated from the procedural statements of program”. Dalam pengertian di atas, basis data merupakan kumpulan data yang saling direlasikan tentang suatu perusahaan untuk berbagai macam keperluan, definisi data dipisahkan dari instruksi-instruksi prosedural program aplikasi komputer. C.J. Date (1995) mendefinisikan basis data sebagai berikut : A database consist of some collection of persistent data that is used by application systems of some given enterprise. Dalam pengertian ini, basis data memuat sekumpulan data yang bersifat tetap yang digunakan oleh banyak sistem aplikasi untuk memberikan informasi kepada perusahaan. Basis data disusun mempunyai dua macam tujuan, yaitu tujuan primer dan tujuan sekunder (Martin, 1975). Tujuan primer basis data meliputi :
8
1. Dapat digunakan oleh banyak pemakai 2. Menjaga investasi intelektual 3. Penekanan beaya 4. Menghilangkan proliferasi 5. Unjuk kerja (performance) 6. Kejelasan (clarity) 7. Kemudahan pemakaian 8. Fleksibilitas penggunaan (flexibility) 9. Kebutuhan data yang tidak terantisipasi dapat ditangani secara cepat 10. Perubahan yang mudah 11. Akurasi (accuracy) dan konsistensi (consistency) 12. Privasi (privacy) 13. Menjaga dari kehilangan dan kerusakan 14. Ketersediaan (availability) Tujuan sekunder basis data meliputi : 1. Kebebasan data secara fisik (physical data independence) 2. Kebebasan data secara logik (logical data independence) 3. Minimalisasi kerangkapan data 4. Kecepatan akses 5. Kecepatan pencarian 6. Standarisasi data 7. Kamus data 8. Antarmuka pemrogram tingkat tinggi
9
9. Bahasa end user 10. Pengendalian integritas 11. Kecepatan penemuan kembali data dari kerusakan (fast recovery from failures) 12. Kemampuan perubahan untuk penyesuaian (tunability) 13. Perancangan dan pengawasan alat-alat 14. Pengorganisasian kembali atau perpindahan otomatis Dalam penggunaannya, basis data mempunyai beberapa keuntungan, yaitu sebagai berikut (Martin, 1976) : 1. Kerangkapan data minimal 2. Inonsistensi data dapat dihindarkan 3. Data dalam basis data dapat digunakan secara bersama-sama 4. Standarisasi data dapat dilakukan 5. Pembatasan untuk keamanan data dapat diterapkan 6. Integritas data dapat dipelihara 7. Perbedaan kebutuhan dapat diseimbangkan Aspek keamanan basis data yang perlu diperhatikan dalam basis data meliputi (Atre, 1980): 1. Recovery, adalah suatu proses menggunakan / mengambil kembali basis data dari media penyimpan cadangan untuk mengembalikan data pada kondisi yang benar karena terjadinya kerusakan / kehilangan data akibat kerusakan media penyimpan, program aplikasi, basis data, perangkat keras, sistem operasi, dan lain-lain.
10
2. Integrity, berkaitan dengan unjuk kerja sistem untuk dapat menjaga data-data dalam basis data agar selalu berada dalam kondisi yang benar, konsisten, dan tersedia pada setiap saat diperlukan 3. Concurency, berkaitan dengan mekanisme pengendalian basis data saat digunakan oleh pemakai secara bersamaan agar terhindar dari kesalahankesalahan akibat beberapa transaksi berbeda dilakukan secara bersamaan 4. Security, adalah suatu mekanisme untuk mencegah dan melindungi basis data dari penggunaan oleh orang-orang atau program aplikasi secara ilegal, pengubahan yang tidak dikehendaki, kerusakan fisik media penyimpan, kebakaran, banjir, huru-hara, badai, dan lain-lain.
2.2. Model Basis Data Relasional (Relational Database Model / RDBM) Basis data model relasional (Relational Database Model / RDBM) merupakan salah satu cara merepresentasikan hubungan logik antar data dalam basis data untuk para pemakai dengan cara merepresentasikannya dalam bentuk tabel dua dimensi yang terdiri atas sejumlah baris dan kolom yang menunjukkan atribut. Model ini semakin populer dan banyak paket aplikasi basis data yang dikembangkan berdasarkan konsep basis data model relasional (Relational Database Model / RDBM) tersebut. Beberapa contoh paket aplikasi basis data yang dikembangkan berdasarkan basis data model relasional (Relational Database Model / RDBM) adalah IBM’s Query by Example, Tymshare’s MAGNUM, MULTICS, National CSS’sNOMAD, dBase, dBase III+, Foxbase, Foxpro, Paradox, MS ACCESS, dan lain-lain.
11
Basis data model relasional (Relational Database Model / RDBM) mempunyai beberapa karakteristik yang harus dipenuhi, yaitu (Martin, 1975): 1. Semua entry / elemen data pada suatu baris dan kolom tertentu harus mempunyai nilai tunggal (single value) atau nilai yang tidak dapat dibagi lagi (atomic value), bukan larik atau suatu grup perulangan 2. Semua entry / elemen data pada suatu kolom tertentu dalam tabel harus mempunyai tipe dan ukuran yang sama 3. Masing-masing kolom dalam suatu tabel mempunyai nama yang unik 4. Pada sebuah tabel tidak ada dua baris yang identik Sebuah tabel basis data mempunyai dua komponen penyusun, yaitu : 1. Intension, menunjukkan definisi struktur penamaan (naming structure) pada tabel dan batasan integritas (integrity constraint) suatu tabel, meliputi integritas kesatuan (entity integrity) dan integritas referensial (referential integrity). 2. Extension, menunjukkan isi tabel / nilai-nilai aktual rinci data pada suatu saat tertentu. Dalam hal pemakaian istilah, model basis data model relasional (Relational Database Model / RDBM) mempunyai terminologi tersendiri untuk penyebutan dan definisi, antara lain : 1. Relasi (relation), menunjukkan nama tabel 2. Record / tuple/ rekaman, menunjukkan satu baris data dalam tabel 3. Atribut (attribute) / medan data / field, menunjukkan kolom data dalam tabel
12
4. Rinci data / item data (data item) / elemen data (data element), menunjukkan nilai aktual data pada suatu baris dan kolom tertentu 5. Kardinalitas (cardinality), menunjukkan cacah baris data dalam tabel 6. Derajat (degree), menunjukkan cacah kolom dalam tabel 7. Unary relation, untuk meyebut tabel yang hanya memiliki satu kolom 8. Binary relation, untuk meyebut tabel yang hanya memiliki dua kolom 9. Ternary relation, untuk meyebut tabel yang memiliki tiga kolom
2.3. Kunci Relasi Kunci relasi menyatakan sebuah atribut / kolom atau gabungan atribut / kolom yang bersifat unik yang digunakan untuk mengidentifikasi setiap baris data / record dalam sebuah relasi. Berdasarkan cacah atribut penyusunnya, kunci relasi dapat dibedakan menjadi dua jenis, yaitu kunci sederhana (single key) jika kunci tersusun atas satu atribut / kolom dan kunci komposit (composite key) jika kunci tersusun atas gabungan atribut / kolom (Martin, 1975). Menurut James Martin (1975), terdapat empat macam kunci relasi yang dapat digunakan dalam relasi, yaitu : 1. Kunci kandidat (candidate key / CK), merupakan sembarang atribut / kolom bersifat unik yang dapat digunakan untuk mengidentifikasi setiap baris data / record dalam relasi. 2. Kunci primer (primary key / PK), merupakan bagian kunci kandidat yang dipilih sebagai kunci untuk mengidentifikasi setiap baris data / record dalam relasi.
13
3. Kunci alternatif (alternate key / AK), merupakan bagian kunci kandidat yang tidak dipilih sebagai kunci untuk mengidentifikasi setiap baris data / record dalam relasi kunci primer (primary key / PK). 4. Kunci asing (foreign key / FK), merupakan sembarang atribut / kolom atau gabungan atribut / kolom pada suatu relasi yang menjadi kunci primer pada relasi yang lain. Kunci asing (foreign key / FK) disebut pula sebagai kunci tamu. Dalam sebutan yang berbeda, kunci asing disebut pula sebagai kunci penghubung, karena sesuai dengan fungsinya kunci ini digunakan untuk menghubungkan antara sebuah relasi dengan relasi yang menjadi induknya. Pemilihan atribut sebagai kunci primer relasi harus memenuhi dua aturan (rules) yang berkaitan dengan integritas data pada atribut / kolom yang digunakan sebgai kunci, yaitu (Martin, 1975) : 1. Integritas entitas (entity integrity), bahwa untuk setiap baris data / record dalam relasi tidak boleh mempunyai nilai rinci data null pada atribut / kolom yang dipilih sebagai kunci (string dengan panjang nol atau numerik nol). 2. Integritas referensial (referential integrity), berhubungan dengan dua atau lebih relasi dalam sebuah basis data yang dihubungkan dengan kunci penghubung, maka hubungan antar relasi tersebut harus menjamin bahwa untuk setiap rinci data pada relasi anak tidak boleh mempunyai nilai rinci data null, artinya setiap nilai rinci data pada relasi anak harus selalu eksis dalam relasi induk sebagai referensi (string kosong atau numerik nol)
14
2.4. Normalisasi Normalisasi diartikan sebagai suatu teknik yang menstrukturkana data dalam cara-cara tertentu untuk mencegah atau mengurangi timbulnya permasalahan yang berhubungan dengan pengolahan data dalam basis data. Proses normalisasi akan menghasilkan record yag konsisten secara logik, mudah untuk dimengerti, sederhana dalam pemeliharaan, serta mudah ditampilan kembali (Martin, 1975). Tujuan utama normalisasi adalah mencegah terjadinya permasalahan (anomly) selama pengolahan / modifikasi data. Permasalahan yang harus dihindarkan selama pengolahan / modifikasi data meliputi (Courtney, 1988) : 1. Penyimpangan penghapusan (delete anomaly), yaitu suatu proses menghapus sebuah nilai rinci data dalam relasi yang mengakibatkan hilangnya informasi lain yang tidak direlasikan secara logik (kemungkinan data masih digunakan). 2. Penyimpangan penyisipan (insert anomaly), yaitu suatu proses menyisipkan sebuah nilai rinci data dalam relasi yang mengakibatkan perlunya penyisipan pada rinci data lain yang tidak direlasikan secara logik (jika tidak dilakukan relasi yang terbentuk tidak memenuhi karakteristik basis data model relasional (Relational Database Model / RDBM)). 3. Penyimpangan
pembaruan
(update
anomaly),
yaitu
suatu
proses
memperbaharui sebuah nilai rinci data dalam relasi yang mengakibatkan perlunya pembaruan beberapa nilai rinci data yang lain dalam relasi (jika
15
tidak dilakukan akan mengakibatkan terjadinya inkonsistensi data (data incosistency)). Umumnya penyimpangan yang terjadi dalam pengolahan / modifikasi data terjadi akibat adanya ketergantungan antar rinci data dalam basis data, yaitu (martin, 1975) : 1. Ketergantungan fungsional (functionally dependency), terjadi jika nilai suatu rinci data atau gabungan nilai rinci data tertentu dalam sebuah tabel menentukan (determines) nilai-nilai pada tribut / kolom yang lain, atau dalam kalimat yang lain jika nilai rinci data tertentu bergantung (depends) pada nilai rinci data pada sebuah atribut atau gabungan atribut yang lain dalam sebuah tabel basis data. Ketergantungan fungsional dinotasikan sebagai : R.X Æ R.Y, dimana R menyatakan relasi, X menyatakan determinan, Y menyatakan atribut yang bergantung, dan X dapat berupa gabungan atribut. 2. Ketergantungan fungsional penuh (full functional dependency), terjadi jika nilai suatu rinci data tertentu bergantung secara fungsional (functionally dependency) pada nilai rinci data pada sebuah atribut atau gabungan atribut yang lain dalam sebuah tabel basis data dan tidak mempunyai ketergantungan pada nilai rinci data yang lain. Sebagaimana dalam ketergantungan
fungsional,
ketergantungan
fungsional
penuh
juga
dinotasikan sebagai : R.X Æ R.Y, dimana R menyatakan relasi, X menyatakan determinan, Y menyatakan atribut yang bergantung, dan X dapat berupa gabungan atribut.
16
3. Ketergantungan transitif (transitive dependency), terjadi jika nilai suatu rinci pada suatu atribut atau gabungan atribut tertentu pertama menentukan nilai rinci data pada atribut kedua dan nilai rinci data pada atribut kedua menentukan nilai rinci data pada atribut ketiga dalam tabel yang sama. Dengan kalimat yang lain ketergantungan transitif terjadi jika satu nilai rinci data bergantung pada dua nilai sekaligus dalam sebuah tabel yang sama. Ketergantungan transitif dinotasikan sebagai R.X Æ R.Y Æ R.Z, dimana R menyatakan relasi, X menyatakan determinan, Y menyatakan atribut pertama yang bergantung, Z menyatakan atribut kedua yang bergantung. Dalam hal ini Z bergantung pada X dan Y sekaligus. Level normal suatu tabel basis data dapat diidentifikasi / ditentukan berdasarkan kriteria bentuk normal. Bentuk-bentuk normal yang dikenal hingga sat ini meliputi (Martin, 1975) : 1. Bentuk normal pertama (first norm form / 1NF), suatu tabel memenuhi bentuk 1NF jika semua atribut mempunyai nilai yang bersifat atomic, dan tidak ada set atribut perulangan (repeating groups), dalam bentuk ini masih mungkin terjadi adanya kerangkapan data (data redundancy) 2. Bentuk normal kedua (second norm form / 2NF), suatu tabel memenuhi bentuk 2NF jika memenuhi kriteria bentuk 1NF, tidak ada kerangapan data, dan semua atribut non kunci mempunyai ketergantungan penuh pada kunci primer. Dalam bentuk 3NF masih ada atribut non kunci yang mempunyai ketergantungan transitif.
17
3. Bentuk normal ketiga (third norm form / 3NF), suatu tabel memenuhi bentuk 3NF jika memenuhi kriteria bentuk 2NF dan tidak ada atribut non kunci yang mempunyai ketergantungan transitif. 4. Bentuk normal Boyce-Codd (Boyce-Codd norm form / BcNF), suatu tabel memenuhi bentuk BCNF jika memenuhi kriteria bentuk 3NF dan dan semua determinannya merupakan kunci kandidat. 5. Bentuk normal keempat (forth norm form / 4NF), suatu tabel memenuhi bentuk 4NF jika memenuhi kriteria bentuk BCNF dimana semua rici data yang ada di dalamnya tidak mengalami ketergantungan pada banyak nilai, atau dengan kalimat lain bentuk 4NF semua rinci data yang mengalami ketergantungan pada banyak nilai adalah bergantung secara fungsional (functionally dependende). 6. Bentuk normal kelima (fifth norm form / 5NF), suatu tabel memenuhi bentuk 5NF jika kerelasian yang ada dalam tabel tidak dapat direkonstruksikan dari struktur tabel yang lebih sederhana / memuat rinci data yang lebih sedikit. 7. Bentuk normal kunci domain (domain key norm form / DKNF), suatu tabel memenuhi bentuk DKNF jika setiap batasan dapat disimpulkan secara sederhana dengan mengatahui sekumpulan nama atribut dan domainnya selama menggunakan sekumpulan atribut pada kuncinya. Perancangan basis data pada umumnya telah optimal jika telah memenuhi kriteria bentuk normal ketiga (Third Norm Form / 3NF). Secara alami tidak ada usaha pemecahan masalah yang tidak mengakibatkan efek samping yang negatif. Pembahasan tentang normalisasi
18
yang seolah-olah merupakan penyelesaian yang sempurna, ternyata juga mengakibatkan beberapa efek samping yang tidak diharapkan, yaitu (Sutanta, 1999) : 1. Munculnya duplikasi data pada rinci data yang digunakan sebagai kunci penghubung. 2. Tidak terpenuhinya batasan integritas referensial dalam basis data 3. Inefisiensi dalam menampilkan kembali data-data dalam basis data, karena harus menghubungkan kembali tabel-tabel yang telah dipecah selama normalisasi 4. Adanya batasan penerapan normalisasi dalam paket aplikasi basis data (setiap paket aplikasi basis data mempunyai batasan jumlah tabel yang dapat dibuka pada saat tertentu secara bersamaan)
2.5. Tinjauan Beberapa Paket Aplikasi Basis Data 2.5.1. dBase III+ (Aplikasi For DOS) Paket aplikasi dBase III+ menyediakan beberapa tipe data, yaitu : character, numeric, logical, date, dan memo. Memo merupakan salah satu tipe field yang tersedia dan dapat digunakan dalam perancangan struktur tabel basis data. Data tipe memo dapat digunakan untuk menampung blok data dalam jumlah yang relatif besar hingga 5000 byte / karakter. Jika tipe data memo digunakan, maka dBase akan menyimpannya dalam tabel lain dengan ekstensi .dpt. Setiap record yang memuat rinci data bertipe memo akan memerlukan tempat 10 byte dalam basis data (Zinzari, 1992).
19
Tabel 2.1: Tipe data yang tersedia dalam paket aplikasi dBase III+ Tipe Keterangan Character Field caracter dipakai untuk menampung data berbentuk huruf atau karakter dan tidak dapat dikenai operasi aritmatika (penambahan, pengurangan, perkalian dan pembagian). Lebar maksimum 254 karakter. Mampu menampung semua karakter ASCII, yaitu huruf, angka, spasi, dan karakter-karakter khusus. Numeric Untuk tipe data yang berbentuk angka dan dapat dikenai operasi aritmatika (penambahan, pengurangan, perkalian dan pembagian). Tipe numeric ada dua macam, yaitu bilangan bulat dan pecahan. Lebar field menentukan jumlah digit yang dapat diterima oleh field tersebut. Tanda positif dan negatif masing-masing akan memerlukan 1 digit. Logical Field logical hanya menerima 1 karakter tunggal yang menunjukkan nilai nilai kondisi benar atau salah. Nilai logika benar (true) dimasukkan sebagai T, t, Y, atau y. Sedangkan nilai logika salah (false) dimasukkan sebagai F, f, N, atau n. Tipe ini biasanya digunakan untuk input data status yang bentuk standarnya mempunyai lebar 1 digit. Date Field date khusus digunakan untuk menerima masukan data berbentuk tanggal, lebar standarnya adalah delapan terdiri : hh/mm/yyyy (tanpa harus mendefinisikan ukuran data). Data date dapat dilakukan kalkulasi. Memo Field ini dipakai untuk menampung blok data yang relatif besar misal data berbentuk keterangan. Blok data akan disimpan ke dalam tabel dengan ekstensi .dbt. Tipe ini dapat menampung hingga 5000 byte / karakter. Jika dalam config.db ditetapkan suatu program pengolah kata ataupun text editor sebagai WP. Maka field ini akan mempunyai batas ukuran yang sama. Setiap field memo akan memerlukan tempat 10 byte dalam basis data untuk setiap recordnya. Data memo tidak secara langsung dimunculkan di layar saat diinputkan, akan tetapi hanya tampak tipe data memo saja. Sumber : Zinzari, 1992
20
2.5.2. FoxPro 2.6 (Aplikasi For DOS) Tabel 2.2: Tipe data yang tersedia dalam paket aplikasi Foxpro 2.6 Tipe Keterangan Character Karakter di sini meliputi huruf, angka, bahkan tanda baca. Data huruf atau karakter tersebut tidak dapat dikenai operasi aritmatika (penambahan, pengurangan, perkalian dan pembagian). Ukuran maksimum data caracter adalah 254 byte. Numeric Digunakan untuk menampung data yang berbentuk angka dan dapat dikenai operasi aritmatika (penambahan, pengurangan, perkalian dan pembagian). Jumlah maksimum digit angka yang dapat diterima adalah 19 digit. Ketika pengisian data, simbol yang dipakai untuk titik desimal adalah titik. Lebar maksimum field tipe numerik adalah 20 karakter, termasuk tanda plus, minus, dan titik desimal. Float Hampir sama dengan tipe numeric, perbedaannya adalah mempunyai kecepatan dan batas ketelitian yang lebih tinggi. Umumnya dipakai untuk perhitungan ilmiah yang memerlukan ketelitian tinggi. Lebar field maksimum adalah 20 karakter, termasuk tanda plus, minus, dan titik desimal. Maksimum tingkat ketelitianya adalah 15 digit desimal di sebelah kiri tanda titik desimal dan 4 digit di sebelah kanan tanda titik desimal. Logical Field logical digunakan untuk menampung tipe data logika atau kondisi benar atau salah. Tipe ini biasanya digunakan untuk input data status yang bentuk standarnya mempunyai lebar 1 digit. Date Field tipe date digunakan khusus untuk data berbentuk tanggal, lebar standarnya adalah 8 (delapan) tanpa harus mendefinisikan ukurannya. Memo Field memo digunakan untuk menampung data teks panjang berupa keterangan lebih dari 254 karakter. Data memo tidak secara langsung dimunculkan di layar saat mengisikan record data, akan tetapi hanya tampak memo saja. Lebar field memo secara otomatis adalah 10 huruf, dan dapat menampung karakter dalam jumlah yang tidak terbatas (dibatasi oleh memory). Pada saat penyimpanan otomatis membentuk file baru dengan ekstensi .fpt. Sumber : Tosin dan Suriyanto, 1995
21
Paket aplikasi Foxpro 2.6 menyediakan beberapa tipe data, yaitu : character, numeric, float, logical, date, dan memo. Data tipe memo dapat digunakan untuk menampung blok data dalam jumlah yang tidak terbatas, yang membatasi adalah kapasitas media penyimpan sekunder yang tersedia. Jika tipe data memo digunakan, maka Foxpro 2.6 akan menyimpannya dalam tabel lain dengan ekstensi .fpt (Tosin dan Suriyanto, 1995). Field memo dalam Foxpro dapat diimpor dan diekspor dari dan ke file eksternal yang dikendalikan oleh program, misalnya dBase IV. Field Memo dapat diperlakukan seperti field karakter. Data field memo dapat diakses di bawah kendali program.
2.5.3. CA Clipper 5.2 Dalam paket aplikasi basis data CA Clipper 5.2, field tipe memo merupakan jenis yang hampir sama dengan text, biasanya digunakan untuk menyimpan data string yang sangat besar atau terdiri beberapa baris. Masing-masing record bisa mempunyai panjang data yang berlainan, dengan ukuran maksimal 64 KB. Penggunaan data memo tersebut pada saat penyimpanan akan menghasilkan file memo dengan ekstensi .dbt yang berisi kumpulan memo, sehingga ukurannya dapat melebihi 64 KB (Alam, 1995).
2.5.4. Microsoft Access 2000 Microsoft Access menyediakan beberapa tipe data, yaitu Text,
Memo,
Number, Date / Time, Currency, AutoNumber, Yes / No, OLE Object, Hyperlink, dan Lookup Wizard.
22
Tabel 2.3 : Tipe Data pada Microsoft Access 2000 Tipe Keterangan Text Untuk menerima data text sampai 255 karakter yang terdiri dari huruf, angka dan simbol grafik. Tatanan default yang digunakan adalah 50 karakter. Memo Untuk menerima data teks sampai 65.535 karakter yang terdiri dari huruf, bilangan, tanda baca serta simbol grafik. Data tipe memo tidak dapat di Index. Number Untuk menerima digit, tanda minus dan titik desimal. Dan tipe data number mempunyai 5 pilihan ukuran bilangan dan jumlah digit tertentu. Date / Time Untuk menerima data nilai tanggal dan waktu serta nilai tahun yang dimulai dari 100 sampai dengan 9999. Currency Untuk menerima data digit, tanda minus dan titik desimal dengan ketepatan 15 digit desimal disebelah kiri tanda titik desimal dan 4 digit disebelah kanan tanda titik desimal. AutoNumber Untuk menampilkan secara otomatis data pencacah atau angka yang dimulai dari angka 1 dengan selang naik 1. Yes / No Tipe ini untuk menerima salah satu dari dua nilai yang ada yaitu Yes / No, True / False atau On / Off. OLE Object Untuk menerima sebuah image grafik, spreadsheet, foto digital, rekaman suara atau video yang dapat diambil program aplikasi lain. Ukuran maksimum dari data tipe OLE Object adalah 1 gigabyte. Dan tipe data ini tidak dapat berhubungan dengan jaringan. Hyperlink Untuk menerima data yang berupa teks yang warna dan bergaris bawah dan grafik serta tipe data ini berhubungan dengan jaringan. Lookup Wizard Untuk menampilkan satu dari beberapa tipe data yang ada dalam suatu daftar. Dan data tersebut dapat Anda ambil dari tabel maupun query yang ada. Sumber : Wempen , 1999 2.5.5. Paradox (Aplikasi Delphi Database Desktop) Paradox merupakan salah satu paket aplikasi basis data dalam Delphi database desktop. Sebagai perangkat lunak yang relatif baru, Paradox menyediakan tipe data yang sangat lengkap (termasuk memo) dan masih memungkinkan bagi para perancang untuk menentukan tipe data baru sesuai dengan kebutuhannya
(Pramono, 1996). Field tipe memo dalam Paradox
memungkinkan untuk menyimpan data berupa keterangan berkisar antara 1-240
23
karakter, dan akan menyimpannya dalam file lain dengan ekstensi .mb. Ukuran file.mb tersebut tidak terbatas (dibatasi oleh memori komputer). Tabel 2.4 : Tipe Data pada Paradox Simbol A N $ S I # D
Ukuran 1 hingga 255
0 to 32
T @ M F G O L +
1 hingga 240 0 hingga 240 0 hingga 240 0 hingga 240
Tipe Alpha Number Money Short Long Integer BCD Date Time Timestamp Memo Formatted Memo Graphic OLE Logical Autoincrement
B Binary Y 1 hingga 255 Bytes Sumber : Delphi Database Desktop
Keterangan Teks umum dan angka Floating point Sama seperti angka tetapi memiliki tanda mata uang Integer 2-byte Integer 4-byte Bynary Coded Desimal 1 Jan 9999 SM hingga 31 Des 9999 Mili detik sejak tengah malam Kombinasi tanggal dan waktu Teks dalam jumlah besar Memo dengan format tertentu Gambar Object Linking and Embedding True / False Long Integer bertambah secara otomatis BLOPS disimpan dalam file .MB Data binary disimpan di file .DB
Berikut adalah informasi tentang field memo dalam Paradox secara lengkap yang termuat dalam fungsi bantuan Delphi database desktop: Use memo fields for text strings that are too long to store in an alpha field. Memo fields can be virtually any length. The size value you assign refers to the amount of the memo Database Desktop stores in the table. This can be from 1 to 240 characters. Database Desktop stores the whole memo outside the table (in the .MB file). Database Desktop retrieves the data from the .MB file as you scroll through the records of the table. The amount of data a memo field contains is limited only by the disk space available on your system.
24
Tip:
If all your memos are smaller than a given size (for example, 200 characters), you can save space and time by setting the memo field size to be equal to or larger than this given size. You will still have an .MB file, but Database Desktop will not have to access it to display the field's data.
Memo fields can contain letters, numbers, special symbols (such as %, &, #, and =), or any other printable ASCII character (except null). You can enter line breaks, tabs and other print control characters in memo fields. To view memo fields, use Paradox. 2.56. dBase (Aplikasi Delphi Database Desktop) dBase merupakan salah satu paket aplikasi basis data lain yang ada dalam Delphi database desktop. Sebagai perangkat lunak yang relatif baru, dBase dalam Delphi database desktop menyediakan tipe data yang sangat lengkap (termasuk memo). Berikut adalah informasi tentang field memo dalam dBase secara lengkap yang termuat dalam fungsi bantuan Delphi database desktop: dBASE memo fields contain blocks of text that are too large to be stored in a character field. The contents of memo fields are stored externally to the table. You do not specify a field size for dBASE memo fields. Berdasarkan informasi tentang field tipe memo dalam beberapa perangkat lunak aplikasi basis data di atas, maka sebenarnya field tipe memo dapat dimanfatkan
untuk
optimalisasi
rancangan
basis
data,
khususnya
minimalisasi duplikasi rinci data yang terjadi pada kunci penghubung (Foreign Key / FK). Cara yang dapat dilakukan adalah dengan mengubah struktur tabel basis data dalam tabel-tabel transaksi dengan memanfaatkan field tipe memo. Tabel 2.5 : Tipe Data pada dBase dalam Delphi database desktop Simbol C
Ukuran 1 hingga 254
Desimal
Tipe Character
Keterangan Teks umum dan angka
25
F
1 hingga 20
N
1 hingga 20
$ D L M
1 hingga 240
F
1 hingga 240
O
1 hingga 240
0 hingga 18, Float dan <= size hingga 2 0 hingga 18, Number dan <= size hingga 2 Money
B
Date Logical Memo Formatted Memo OLE Binary
Sumber : Delphi Database Desktop
Floating point Binary Coded Decimal Seperti angka tetapi memiliki mata uang 8 byte field tanggal True / False Teks dalam jumlah besar Memo dengan format tertentu Object Linking and Embedding BLOPS
25
BAB III. ANALISIS DAN PEMBAHASAN
3.1. Penerapan Normalisasi Proses perancangan basis data secara logik dapat dilakukan dengan memanfaatkan salah satu dari dua teknik yang tersedia, yaitu teknik entity_relationship models (ER_M) atau teknik normalisasi. Umumnya perancangan basis data akan cenderung menggunakan teknik kedua, yaitu normalisasi karena lebih sesuai dengan terminologi basis data model relasional yang banyak digunakan saat ini. Teknik normalisasi akan menstrukturkan data dalam cara-cara tertentu dan disusun sesuai dengan kelompoknya masingmasing. Secara logik, rancangan basis data hasil normalisasi dapat ditunjukkan dalam model relasional berupa tabel / relasi yang tersusun atas sejumlah atribut. Selanjutnya, hubungan / kerelasian antar tabel / relasi ditunjukkan oleh satu atau gabungan field yang berfungsi sebagai kunci penghubung / kunci asing (foreign key). Umumnya rancangan basis data akan berada dalam kondisi yang cukup optimal jika telah memenuhi kriteria bentuk normal ketiga / 3NF. Dalam bentuk ini, permasalahan - permasalahan yang berkaitan dengan pengolahan data telah dapat dihindari. Kenyataan yang dihadapi dalam penerapan teknik normalisasi adalah mengakibatkan efek samping yang tidak diharapkan, yaitu munculnya duplikasi rinci data pada atribut yang digunakan sebagai kunci penghubung, tidak terpenuhinya batasan integritas referensial dalam basis data, inefisiensi dalam
26
menampilkan kembali data-data dalam basis data karena harus menghubungkan kembali tabel-tabel yang telah dipecah selama normalisasi, dan adanya batasan penerapan teknik normalisasi dalam paket aplikasi basis data (setiap paket aplikasi basis data mempunyai batasan jumlah tabel yang dapat dibuka pada saat tertentu secara bersamaan)
3.2. Efek Normalisasi 3.2.1. Duplikasi Rinci data Relasi / tabel basis data yang dinormalisasi akan dipecah menjadi beberapa tabel / relasi baru. Relasi-relasi baru tersebut tetap harus saling berhubungan, sehingga harus dipasang kunci penghubung. Semakin banyak relasi baru yang terbentuk akan memerlukan semakin banyak kunci penghubung yang harus disediakan. Akibatnya, akan semakin banyak pula terjadi duplikasi data pada rinci data yang digunakan sebagai kunci penghubung. Sekalipun penerapan teknik normalisasi akan menghasilkan struktur tabel / relasi yang optimal dari sisi pengolahan data dan penggunaan memori secara umum, tetapi secara khusus akan terjadi pemborosan media penyimpan sekunder akibat duplikasi rinci data pada kunci penghubung.
3.2.2. Batasan Integritas
27
Salah satu kekangan / batasan yang harus dipenuhi oleh sebuah basis data adalah berkaitan dengan batasan integritas, meliputi batasan integritas entitas dan batasan integritas referensial. Aturan integritas entitas (entity integrity) menyatakan bahwa untuk setiap baris data / record dalam relasi tidak boleh mempunyai nilai rinci data null pada atribut / kolom yang dipilih sebagai kunci (string dengan panjang nol atau numerik nol). Sedangkan aturan integritas referensial (referential integrity), berhubungan dengan dua atau lebih relasi dalam sebuah basis data yang dihubungkan dengan kunci penghubung, maka hubungan antar relasi tersebut harus menjamin bahwa untuk setiap rinci data pada relasi anak tidak boleh mempunyai nilai rinci data null, artinya setiap nilai rinci data pada relasi anak harus selalu eksis dalam relasi induk sebagai referensi (string dengan panjang nol atau numerik nol). Hal ini mensyaratkan bahwa suatu data dalam tabel / relasi pertama sebagai anak yang menunjuk data pada tabel / relasi lain yang berfungi sebagai induk, maka data tersebut harus eksis dalam tabel / relasi induknya. Tabel / relasi hasil normalisasi memungkinkan terjadinya kontradiksi dengan aturan batasan integritas dalam basis data, khususnya batasan integritas referensial. Hal ini terjadi karena untuk memasukkan data - data baru dalam tabel / relasi baru yang terbentuk harus dilakukan pada beberapa tabel / relasi sekaligus. Pemasukan data baru tersebut harus dilakukan secara berurutan dimulai dari tabel / relasi induk terlebih dahulu, baru kemudian dilanjutkan dalam tabel / relasi anak yang mempunyai hubungan dengan tabel / relasi induk tersebut. Jika pemasukan data dilakukan tidak secara lengkap atau tidak sesuai
28
dengan urutannya maka akan mengakibatkan munculnya null pada relasi induk. Dengan demikian, aturan integritas referensial akan dilangggar.
3.2.3. Inefisiensi Pengolahan Proses dalam normalisasi akan memecah sebuah relasi menjadi beberapa relasi baru dengan struktur yang lebih sederhana. Data – data yang semula tersimpan dalam sebuah tabel / relasi dalam benytuk tidak normal akan tersebar ke dalam beberapa tabel / relasi baru. Rancangan tabel / relasi dalam bentuk normal, akan mengakibatkan permasalahan inefisiensi pengolahan ketika akan menampilkan kembali data data dari dalam tabel / relasi basis data. Ketika sebuah informasi yang dibutuhkan oleh pemakai tersimpan dalam banyak tabel / relasi, maka penyajian informasi seperti ini memerlukkan proses untuk membuka beberapa tabel, mengecek keberadaan data yang dicari dalam beberapa tabel, dan kemudian harus mengggabungkannya agar sesuai dengan kebutuhan informasi yang harus dipenuhi. Rancangan tabel / relasi dalam bentuk normal juga akan mengakibatkan permasalahan
inefisiensi
ketika
proses
penghapusan
data
khususnya
pengahpusan data pada tabel / relasi induk. Proses penghapusan sebuah record dalam tabel / relasi basis data tersebut hanya dapat dilakukan jika data tersebut tidak pernah digunakan lagi oleh seluruh tabel / relasi dalam basis data. Konsekuensinya kebutuhan proses penghapusan akan memerlukan proses yang lebih panjang, yaitu harus dilakukan pengecekan pada seluruh tabel / relasi
29
dalam basis data. Jika hal ini tidak dilakukan, maka akan mengakibatkan terlanggarnya batasan integritas referensial.
3.2.4. Batasan Penerapan Jumlah relasi / tabel hasil proses normalisasi akan mengalami penambahan. Sebuah relasi / tabel tidak normal sangat mungkin dipecah menjadi lebih dari tiga tabel / relasi baru. Jika suatu sistem memerlukan 10 relasi / tabel yang masih berada dalam bentuk tidak normal, maka jika dilakukan normalisasi akan menghasilkan sekitar 30 tabel / relasi baru dalam bentuk normal (3NF). Infromasi yang diperlukan oleh para pemakai umumnya merupakan infromasi yang berasal dari beberapa tabel / relasi. Permasalahan akan muncul ketika pada suatu saat tertentu sejumlah tabel / relasi yang jumlahnya bisa melebihi kemampuan paket perangkat lunak DBMS yang digunakan. Hal ini berarti bahwa penerapan teknik normalisasi akan menemui permasalaahn berkaitan dengan keterbatasan kemampuan paket aplikasi basis data (setiap paket aplikasi basis data mempunyai batasan jumlah tabel yang dapat dibuka pada saat tertentu secara bersamaan)
3.3. Studi Kasus Penerapan Teknik Normalisasi
30
Untuk memperjelas permasalahan duplikasi rinci data akibat pada kunci penghubung akibat penerapan teknik normalisasi, berikut akan dilakukan contoh studi kasus sederhana penerapan teknik normalisasi dalam subsistem pengolahan data akademik.
3.3.1. Entitas dan Atribut Subsistem pengolahan data akademik melibatkan beberapa entitas, yaitu: 1. Mahasiswa 2. Angkatan 3. Jenjang_Studi 4. Jurusan 5. Dosen 6. Golongan 7. Matakuliah 8. Nilai 9. Ruang 10. Waktu Entitas Mahasiswa dapat memiliki atribut sebagai berikut: 1. Angkatan 2. Jenjang_Studi 3. Jurusan 4. Nomor 5. Nama
31
6. Alamat Entitas Angkatan dapat memiliki atribut sebagai berikut: 1. Angkatan 2. Tahun_Angkatan Entitas Jenjang_Studi dapat memiliki atribut sebagai berikut: 1. Jenjang_Studi 2. Nama_Jenjang_Studi Entitas Jurusan dapat memiliki atribut sebagai berikut: 1. Jurusan 2. Nama_Jurusan Entitas Dosen dapat memiliki atribut sebagai berikut: 1. NIK 2. Nama 3. Alamat 4. Golongan 5. Status Entitas Golongan dapat memiliki atribut sebagai berikut: 1. Golongan 2. Gaji_Pokok Entitas Mata_Kuliah dapat memiliki atribut sebagai berikut: 1. Kode_Mata_Kuliah 2. Nama_Mata_Kuliah 3. SKS
32
4. Semester 5. Status Entitas Nilai dapat memiliki atribut sebagai berikut: 1. Nilai 2. Mutu Entitas Ruang dapat memiliki atribut sebagai berikut: 1. Kode_Ruang 2. Kapasitas Entitas Waktu dapat memiliki atribut sebagai berikut: 1. Kode_Waktu 2. Hari 3. Jam_Mulai 4. Status
3.3.2. Hubungan / Kerelasian Antar Entitas Hubungan / kerelasian antar entitas dalam subsistem pengolahan data akademik di atas dapat ditunjukkan oleh tabel / relasi bertipe transaksi atau kunci penghubung pada tabel / relasi yang berfungsi sebagai anak. Berikut adalah tabel / relasi bertipe transaksi yang diperlukan dalam subsistem pengolahan data akademik:
1. Mahasiswa mengikuti Mata_Kuliah
33
Hubungan / kerelasian antara entitas Mahasiswa dan entitas Mata_Kuliah dapat ditunjukkan oleh tabel / relasi KRS dengan atribut sebagai berikut: a. Angkatan b. Jenjang_Studi c. Jurusan d. Nomor e. Kode_Mata_Kuliah f. Tahun_Semester 2. Mahasiswa mengikuti Mata_Kuliah memperoleh Nilai mata kuliah Hubungan / kerelasian antara entitas Mahasiswa dan Nilai mata kuliah dapat ditunjukkan oleh tabel / relasi KHS dengan atribut sebagai berikut: a. Angkatan b. Jenjang_Studi c. Jurusan d. Nomor e. Kode_Mata_Kuliah f. Tahun_Semester g. Nilai 3. Dosen mengajar Mata_Kuliah Hubungan / kerelasian antara entitas Dosen dan Mata_Kuliah dapat ditunjukkan oleh tabel / relasi Dosen_Mengajar dengan atribut sebagai berikut: a. NIK
34
b. Kode_Mata_Kuliah c. Tahun_Semester d. Status 4. Dosen mengajar Mata_Kuliah dan Ruang Hubungan / kerelasian antara entitas Dosen mengajar mata kuliah dan Ruang dapat ditunjukkan oleh tabel / relasi Jadwal dengan atribut sebagai berikut: a. Kode_Mata_Kuliah b. Kode_Ruang c. Tahun_semester d. Kode_Waktu 5. Mahasiswa mempunyai Angkatan Hubungan / kerelasian antara entitas Mahasiswa dan Angkatan ditunjukkan oleh kunci penghubung, yaitu field Angkatan dalam tabel / relasi Mahasiswa. 6. Mahasiswa memilih Jenjang_Studi Hubungan / kerelasian antara entitas Mahasiswa dan Jenjang_Studi ditunjukkan oleh kunci penghubung, yaitu field Jenjang_Studi dalam tabel / relasi Mahasiswa. 7. Mahasiswa memilih Jurusan Hubungan / kerelasian antara entitas Mahasiswa dan Jurusan ditunjukkan oleh kunci penghubung, yaitu field Jurusan dalam tabel / relasi Mahasiswa. 8. Dosen mempunyai golongan
35
Hubungan / kerelasian antara entitas Dosen dan Golongan ditunjukkan oleh kunci penghubung, yaitu field Golongan dalam tabel / relasi Dosen. Selanjutnya, hubungan / kerelasian antar tabel / relasi hasil rancangan di atas ditunjukkan oleh Gambar 3.1.
Gambar 3.1. Diagram kerelasian antar tabel / relasi rancangan pertama
3.3.3. Struktur Tabel / Relasi
36
Struktur masing-masing tabel / relasi di atas dapat didefinisikan sebagai berikut: Tabel 3.1. Mahasiswa Kunci primer : Angkatan+Jenjang_Studi+Jurusan+Nomor No Nama Field Tipe Ukuran 1 Angkatan Numerik 2 2 Jenjang_Studi Karakter 1 3 Jurusan Karakter 2 4 Nomor Numerik 4 5 Nama Karakter 50 6 Alamat Karakter 50 Total: 110 Tabel 3.2. Angkatan Kunci primer : Angkatan No Nama Field 1 Angkatan 2 Tahun_Angkatan Total: Tabel 3.3. Jenjang_Studi Kunci primer : Jenjang_Studi No Nama Field 1 Jenjang_Studi 2 Nama_Jenjang_Studi Total: Tabel 3.4. Jurusan Kunci primer : Jurusan No Nama Field 1 Jurusan 2 Nama_Jurusan Total: Tabel 3.5. Dosen Kunci primer : NIK No Nama Field
Tipe Numerik Numerik
Ukuran 2 4 7
Tipe Karakter Karakter
Ukuran 1 10 12
Tipe Karakter Karakter
Ukuran 2 30 33
Tipe
Ukuran
37
1 2 3 4 5
NIK Nama Alamat Golongan Status
Karakter Karakter Karakter Karakter Karakter
10 50 50 1 1 113
Tipe Karakter Numerik
Ukuran 1 7 9
Tipe Karakter Karakter Numerik Numerik Karakter
Ukuran 8 50 1 1 1 62
Tipe Karakter Numerik
Ukuran 1 1 3
Tipe Karakter
Ukuran 3
Total: Tabel 3.6. Golongan Kunci primer : Golongan No Nama Field 1 Golongan 2 Gaji_Pokok Total: Tabel 3.7. Mata_Kuliah Kunci primer : Kode_Mata_Kuliah No Nama Field 1 Kode_Mata_Kuliah 2 Nama_Mata_Kuliah 3 SKS 4 Semester 5 Status Total: Tabel 3.8. Nilai Kunci primer : Nilai No Nama Field 1 Nilai 2 Mutu Total:
Tabel 3.9. Ruang Kunci primer : Kode_Ruang No Nama Field 1 Kode_Ruang
38
2
Kapasitas
Numerik
3 7
Tipe Karakter Karakter Time Karakter
Ukuran 3 6 6 1 17
Total: Tabel 3.10. Waktu Kunci primer : Kode_waktu No Nama Field 1 Kode_Waktu 2 Hari 3 Jam_Mulai 4 Status Total:
Tabel 3.11. KRS Kunci primer : Angkatan+Jenjang_Studi+Jurusan+Nomor +Kode_Mata_Kuliah+Tahun_Semester No Nama Field Tipe Ukuran 1 Angkatan Numerik 2 2 Jenjang_Studi Karakter 1 3 Jurusan Karakter 2 4 Nomor Numerik 4 5 Kode_Mata_Kuliah Karakter 8 6 Tahun_Semester Karakter 5 Total: 23
Tabel 3.12. KHS Kunci primer : Angkatan+Jenjang_Studi+Jurusan+Nomor +Kode_Mata_Kuliah+Tahun_Semester No Nama Field Tipe Ukuran 1 Angkatan Numerik 2
39
2 3 4 5 6 7
Jenjang_Studi Jurusan Nomor Kode_Mata_Kuliah Tahun_Semester Nilai Total:
Karakter Karakter Numerik Karakter Karakter Karakter
1 2 4 8 5 1 24
Tabel 3.13. Dosen_Mengajar Kunci primer : NIK+Kode_Mata_Kuliah+Tahun_Semester No Nama Field Tipe Ukuran 1 NIK Karakter 10 2 Kode_Mata_Kuliah Karakter 8 3 Tahun_Semester Karakter 5 4 Status Karakter 1 Total: 25 Tabel 3.14. Jadwal Kunci primer : NIK+Kode_Mata_Kuliah+Tahun_Semester No Nama Field Tipe Ukuran 1 Kode_Mata_Kuliah Karakter 8 2 Kode_Ruang Karakter 3 3 Tahun_semester Karakter 5 4 Kode_Waktu Karakter 3 Total: 20
3.3.4. Duplikasi Rinci Data Dalam rancangan tabel / relasi di atas, maka duplikasi rinci data terjadi pada setiap tabel / relasi yang memiliki atribut yang berfungsi sebagai kunci
40
penghubung. Namun demikian, tidak seluruh duplikasi rinci data tersebut mengakibatkan pembengkakan media penyimpan sekunder, hanya duplikasi rinci data pada tabel / relasi bertipe transaksi saja yang mengakibatkan pembengkakan penggunaan media penyimpan. Berikut adalah tabel / relasi transaksi bertipe transaksi yang digunakan dalam studi kasus di atas: 1. Tabel / Relasi KRS Tabel / relasi KRS merupakan tabel / relasi bertipe transaksi yang berfungsi untuk mencatat pengambilan Mata_Kuliah oleh Mahasiswa. Tabel / relasi KRS mempunyai kerelasian dengan tabel / relasi Mahasiswa dan Mata_Kuliah. Dalam kerelasian antara tabel / relasi Mahasiswa dan KRS, tabel / relasi KRS mempunyai kunci penghubung berupa kunci komposit, yaitu field Angkatan, Jenjang, Jurusan, dan Nomor. Sedangkan dalam kerelasian antara tabel / relasi KRS dan Mata_Kuliah, tabel / relasi KRS mempunyai kunci penghubung berupa kunci sederhana, yaitu field Kode_Mata_Kuliah. Dalam hal ini field Angkatan, Jenjang, Jurusan, dan Nomor mengalami duplikasi pada tabel / relasi Mahasiswa dan KRS. Sedangkan field Kode_Mata_Kuliah mengalami duplikasi pada tabel / relasi Mata_Kuliah dan KRS. 2. Tabel / Relasi KHS Tabel / relasi KHS merupakan tabel / relasi bertipe transaksi yang berfungsi untuk mencatat perolehan Mata_Kuliah Mahasiswa yang telah mengikuti
41
suatu Mata_Kuliah. Tabel / relasi KHS perlu dipisahkan untuk memenuhi bentuk normal ketiga dan untuk memenuhi kriteria basis data model relasional, yaitu untuk menghindari adanya nilai null dalam record. Jika tidak dibuat struktur yang terpisah, maka nilai null tersebut akan muncul pada mahasiswa yang telah merencanakan mengambil suatu mata kuliah (telah tercatat dalam KRS) tetapi pada akhirnya tidak mempunyai nilai akibat tidak aktif kuliah dan ujian, tidak ikut ujian, tidak hadir ujian, ikut ujian tetapi tidak mengumpulkan berkas ujian, atau penyebab lainnya. Tabel / relasi KHS mempunyai kerelasian dengan tabel / relasi KRS dan Nilai. Dalam kerelasian antara tabel / relasi KRS dan KHS, tabel / relasi KHS mempunyai kunci penghubung berupa kunci komposit, yaitu field Angkatan, Jenjang, Jurusan, Nomor dan Tahun_Semester. Sedangkan dalam kerelasian antara tabel / relasi KHS dan Nilai, tabel / relasi KHS mempunyai kunci penghubung berupa kunci sederhana, yaitu field Nilai. Dalam hal ini field Angkatan, Jenjang, Jurusan, Nomor dan Tahun_Semester mengalami duplikasi pada tabel / relasi KRS dan KHS. Sedangkan field Nilai mengalami duplikasi pada tabel / relasi KRS dan Nilai. 3. Tabel / Relasi Jadwal Tabel / relasi Jadwal merupakan tabel / relasi bertipe transaksi yang berfungsi untuk mencatat waktu pelaksanaan kuliah suatu Mata_Kuliah pada semester tertentu dengan menempati suatu Ruang tertentu pada hari dan jam tertentu. Tabel / relasi Jadwal mempunyai kerelasian dengan tabel / relasi Ruang dan Waktu.
42
Dalam kerelasian antara tabel / relasi Jadwal dan Ruang, tabel / relasi Jadwal mempunyai kunci penghubung berupa kunci sederhana, yaitu field Kode_Ruang. Sedangkan dalam kerelasian antara tabel / relasi Jadwal dan Waktu, tabel / relasi Jadwal mempunyai kunci penghubung berupa kunci sederhana, yaitu field Kode_Waktu. Dalam hal ini field Kode_Ruang mengalami duplikasi pada tabel / relasi Jadwal dan Ruang. Sedangkan field Kode_Waktu mengalami duplikasi pada tabel / relasi Jadwal dan Waktu. 4. Tabel / Relasi Dosen_Mengajar Tabel / relasi Jadwal merupakan tabel / relasi bertipe transaksi yang berfungsi untuk mencatat dosen pengasuh Mata_Kuliah pada semester tertentu. Tabel / relasi dosen_mengajar mempunyai kerelasian dengan tabel / relasi Mata_Kuliah dan Dosen. Dalam kerelasian antara tabel / relasi Dosen_Mengajar dan Mata_Kuliah, tabel / relasi Dosen_Mengajar mempunyai kunci penghubung berupa kunci sederhana, yaitu field Kode_Mata_Kuliah. Sedangkan dalam kerelasian antara tabel / relasi Dosen_Mengajar dan Dosen, tabel / relasi Dosen_Mengajar mempunyai kunci penghubung berupa kunci sederhana, yaitu field Kode_Dosen. Dalam hal ini field Kode_Mata_Kuliah mengalami duplikasi pada tabel / relasi Dosen_Mengajar dan Mata_Kuliah. Sedangkan field Kode_Dosen mengalami duplikasi pada tabel / relasi Dosen_Mengajar dan Dosen.
43
3.3.5. Penggunaan Media Penyimpan Untuk melakukan perhitungan penggunaan media penyimpan sekunder akibat terjadinya duplikasi data, perlu ditetapkan beberapa asumsi sebagai dasar perhitungan. Berikut ini asumsi yang digunakan sebagai dasar perhitungan selanjutnya, yaitu: Jumlah mahasiswa
= 10.000
Jumlah angkatan mahasiswa
= 50
Jumlah jenjang studi yang diselenggarakan
=3
Jumlah jurusan yang diselenggarakan
= 20
Jumlah dosen pengasuh mata kuliah
= 250
Jumlah macam golongan dosen
= 10
Jumlah mata kuliah minimal yang harus ditempuh
= 60
Jumlah macam nilai mata kuliah
=5
Jumlah ruangan yang tersedia
= 42
Jumlah macam waktu kuliah / praktikum
= 90
Rata-rata mata kuliah yang diulang per mahasiswa
= 10
Kapasitas setiap ruangan
= 60
Jumlah sesi pemakaian ruang per hari
=4
Selanjutnya berdasarkan asumsi di atas dapat dihitung kapasitas media penyimpan sekunder yang dibutuhkan oleh basis data untuk jangka waktu satu tahun ditunjukkan oleh Tabel 3.15.
Tabel 3.15. Kapasitas media penyimpan yang dibutuhkan
44
No
Nama tabel / relasi
Ukuran record (byte) 110
Jumlah record 10000
Kapasitas (byte) 1100000
1.
Mahasiswa
2.
Angkatan
7
50
350
3.
Jenjang_Studi
12
3
36
4.
Jurusan
33
20
660
5.
Dosen
113
250
28250
6.
Golongan
9
10
90
7.
Mata_Kuliah
62
60
3720
8.
Nilai
3
5
15
9.
Ruang
7
42
294
10.
Waktu
17
90
1530
11.
KRS
23
10000*70
1610000
12.
KHS
24
10000*70
1680000
13.
Dosen_Mengajar
25
168
3200
14.
Jadwal
20
168
3360
Total:
4.431.505
Berdasarkan hasil perhitungan di atas, maka total kebutuhan media penyimpan selama satu tahun untuk basis data di atas adalah: Ö 4.431.505 byte Ö 4327,6 KB Ö 4,2 MB Secara khusus, penggunaan media penyimpan untuk nilai - nilai rinci data yang mengalami duplikasi adalah ditunjukkan oleh Tabel 3.16.
Tabel 3.16. Kapasitas media penyimpan rinci data yang mengalami duplikasi No Nama tabel Nama field Ukuran Jumlah Kapasitas / relasi field record (byte) (byte)
45
1.
KRS
Angkatan
2
2.
KRS
Jenjang_Studi
1
3.
KRS
Jurusan
2
4.
KRS
Nomor
4
5.
KHS
Angkatan
2
6.
KHS
Jenjang_Studi
1
7.
KHS
Jurusan
2
8.
KHS
Nomor
4
9.
KHS
Kode_Mata_Kulia h Tahun_Semester
8
NIK
10
10000*7 0 10000*7 0 10000*7 0 10000*7 0 10000*7 0 10000*7 0 10000*7 0 10000*7 0 10000*7 0 10000*7 0 168
Kode_Mata_Kulia h Tahun_Semester
8
168
1344
5
168
840
Kode_Mata_Kulia h Kode_Ruang Tahun_semester Kode_Waktu Total :
8
168
1344
3 5 3
168 168 168
504 840 504 21.707.056
10. KHS 11. Dosen_Mengaja r 12. Dosen_Mengaja r 13. Dosen_Mengaja r 14. Jadwal 15. Jadwal 16. Jadwal 17. Jadwal
5
1400000 700000 1400000 2800000 1400000 700000 1400000 2800000 5600000 3500000 1680
Berdasarkan hasil perhitungan di atas, maka total kebutuhan media penyimpan selama satu tahun untuk rinci data yang mengalami duplikasi dalam basis data di atas adalah: Ö 21.707.056 byte Ö 21.198,3 KB
46
Ö 20,7 MB
3.4. Pemanfaatan Field Bertipe Memo 3.4.1. Tabel / Relasi yang Dipertahankan Sesuai dengan tujuan penelitian ini, maka sebagaian rancangan tabel / relasi basis data di atas akan dirubah menjadi bentuk lain dengan memanfaatkan field bertipe memo. Perubahan tersebut juga akan mengubah bentuk kerelasian antar tabel / relasi basis data. Dengan alasan untuk meminimalkan redundansi data maka beberapa rancangan tabel / relasi lama masih tetap dipertahankan. Tabel / relasi yang tidak mengalami perubahan adalah sebagai berikut: 1. Mahasiswa 2. Angkatan 3. Jenjang_Studi 4. Jurusan 5. Dosen 6. Golongan 7. Mata_Kuliah 8. Nilai 9. Ruang 10. Waktu
3.4.2. Tabel / Relasi yang Dimodifikasi
47
Pemanfaatan field bertipe memo di sini memerlukan perubahan / modifikasi pada beberapa tabel / relasi. Tabel / relasi basis data yang mengalami perubahan adalah tabel / relasi bertipe transaksi, memiliki kunci penghubung, dan mengalami duplikasi rinci data yang mengakibatkan pembengkakan penggunaan media penyimpan yang signifikan. Perubahan / modifikasi yang dilakukan tersebut adalah terjadi pada tabel / relasi sebagai berikut: 1. Tabel / relasi KRS_1 Tabel / relasi KRS_1 merupakan hasil modifikasi dari tabel / relasi KRS. Perubahan yang dilakukan adalah menghilangkan field Tahun_Semester pengambilan Mata_Kuliah dan Kode_Mata_Kuliah yang diambil Mahasiswa dan menggantikannya dengan field baru dengan nama Krs dengan tipe data memo. Nilai rinci data pada field Krs tersebut adalah teks yang memuat keterangan Tahun_Semester pengambilan Mata_Kuliah, Kode_Mata_Kuliah yang diambil Mahasiswa, dan hasil perolehan Nilai dari pengambilan mata kuliah tersebut. Nilai rinci data pada field Krs dikodekan dengan cara tertentu, sehingga memudahkan pengolahan selanjutnya, yaitu sebagai berikut: !Tahun_Semester?Kode_Mata_Kuliah&Nilai Pengkodean di atas memiliki arti tertentu, yaitu sebagai berikut: !Tahun_Semester
: tahun semester pengambilan mata kuliah
?Kode_Mata_Kuliah : kode mata kuliah yang diambil &Nilai Contoh: !20003?TFS1111P&A
: nilai yang diperoleh
48
Arti : Tahun
: 2000/2001
Semester
: pendek
Mata kuliah
: TFS1111P
Nilai
:A
Dengan cara tersebut, maka pengolahan data selanjutnya dilakukan dengan pengelolaan teks dalam field Krs yang bertipe memo tersebut. Sebagai contoh, untuk mencatat pengambilan mata kuliah baru atau pengulangan mata kuliah dilakukan dengan cara sebagai berikut ; 1. Cari data Angkatan+Jenjang_Studi+Jurusan+Nomor yang sesuai 2. Tambahkan / edit teks dalam field memo tersebut dimulai dari posisi paling akhir dengan cara pengkodean sebagaimana cara yang ditentukan tersebut, yaitu: !Tahun_Semester?Kode_Mata_Kuliah&Null 3. Simpan kembali dalam tabel basis data Dalam kasus yang lain, untuk mengetahui perolehan nilai keseluruhan mata kuliah bagi seorang mahasiswa dapat diketahui dengan cara melakukan pemotongan teks dalam field memo tersebut, yaitu: 1. Cari data Angkatan+Jenjang_Studi+Jurusan+Nomor yang sesuai 2. Potong isi teks dalam field Krs dimulai pada setiap ditemukan tanda ! Hal ini dilakukan secara terus menerus hingga karakter terakhir dalam teks tersebut. 3. Tampilkan identitas mahasiswa, tahun semester pengambilan mata kuliah, identitas setiap mata kuliah yang diambil, nilai yang diperoleh, serta dihitung nilai mutu dari setiap mata kuliah yang diperoleh.
49
4. Hitung indeks pretasi keseluruhan mata kuliah yang telah diambil 5. Tampilkan semua itu sesuai dengan format yang ditentukan / diinginkan. Dengan cara tersebut di atas, maka perolehan nilai pengambilan mata kuliah seorang mahasiwa tidak perlu disimpan secara terpisah dalam tabel / relasi KHS seperti rancangan sebelumnya, tetapi dapat dilakukan secara langsung dalam tabel / relasi KRS_1. Cara ini akan mengurangi pemakaian media penyimpan, tanpa harus melanggar konsep model basis data relasional. Jika seorang mahasiswa mengambil mata kuliah dan akibat sesuatu hal maka pada akhirnya tidak memperoleh nilai tinggal dituliskan null atau nol dalam teks setelah tanda &. Rancangan tabel / relasi KRS_1 hasil modifikasi tersebut ditunjukkan oleh Tabel 3.17.
Tabel 3.17. KRS_1 Kunci primer : Angkatan+Jenjang_Studi+Jurusan+Nomor No Nama Field Tipe Ukuran 1 Angkatan Numerik 2 2 Jenjang_Studi Karakter 1 3 Jurusan Karakter 2 4 Nomor Numerik 4 5 Krs Memo 2. Relasi / tabel Dosen_Mengajar_1 Relasi / tabel Dosen_Mengajar_1 merupakan hasil modifikasi dari tabel / relasi Dosen_Mengajar dalam rancangan sebelumnya. Relasi / tabel ini berfungsi untuk mencatat data dosen yang mengajar seluruh mata kuliah pada seluruh tahun akademik.
Perubahan
yang
dilakukan
adalah
menghilangkan
field
Tahun_Semester, Kode_Mata_Kuliah, dan Status mengajar seorang dosen. Ketiga
50
field tersebut selanjutnya digabung menjadi sebuah field baru dengan nama Mengajar dengan tipe data memo. Dengan analogi yang sama dengan tabel / relasi KRS_1, maka isi nilai rinci data dalam field Mengajar adalah berbentuk kode yaitu: !Tahun_Semester?Kode_Mata_Kuliah&Status Pengkodean di atas memiliki arti sebagai berikut: !Tahun_Semester
: tahun semester mengajar mata kuliah
?Kode_Mata_Kuliah : kode mata kuliah yang diasuh &Status
: status mengajar dosen (dosen atau asisten)
Contoh: !20001?TFS1111P&A Arti : Tahun
: 2000/2001
Semester
: ganjil
Mata kuliah
: TFS1111P
Nilai
: asisten dosen
Selanjutnya pengolahan data selanjutnya dilakukan dengan teknik yang sama dengan pengolahan data pada tabel / relasi KRS_1, yaitu pengelolaan teks dalam field Mengajar. Rancangan tabel / relasi Dosen_Mengajar_1 hasil modifikasi tersebut ditunjukkan oleh Tabel 3.18.
Tabel 3.18. Dosen_Mengajar_1 Kunci primer : NIK+Mengajar No Nama Field
Tipe
Ukuran
51
1 2
NIK Mengajar
Karakter Memo
10 -
3. Relasi Jadwal_1 Relasi Jadwal_1 merupakan hasil modifikasi dari tabel / relasi Jadwal dalam rancangan sebelumnya. Relasi / tabel ini berfungsi untuk mencatat data pelaksanaan perkuliahan yang meliputi Tahun_Semester perkuliahan, Ruang yang digunakan, dan Waktu pelaksanaan perkuliahan untuk seluruh mata kuliah pada seluruh tahun akademik. Perubahan yang dilakukan adalah menghilangkan field Tahun_Semester, Kode_Ruang, dan Waktu mengajar seorang dosen. Ketiga field tersebut selanjutnya digabung menjadi sebuah field baru dengan nama Jadwal dengan tipe data memo. Dengan analogi yang sama dengan tabel / relasi KRS_1 dan Dosen_Mengajar, maka isi nilai rinci data dalam field Jadwal adalah berbentuk kode yaitu: !Tahun_Semester?Kode_Ruang&Waktu Pengkodean di atas memiliki arti sebagai berikut: !Tahun_Semester
: tahun semester perkuliahan
?Kode_Ruang
: kode ruang yang digunakan
&Waktu
: jam mulai sesi perkuliahan / praktikum
Contoh: !20001?B10&S4P Arti : Tahun
: 2000/2001
Semester : ganjil
52
Ruang
: B10
Jadwal
: Senin sesi keempat untuk jenis waktu praktikum
Selanjutnya pengolahan data juga dilakukan dengan teknik yang sama dengan pengolahan data pada tabel / relasi KRS_1 dan Dosen_mengajar_1, yaitu pengelolaan teks dalam field Jadwal. Rancangan tabel / relasi Jadwal_1 hasil modifikasi tersebut ditunjukkan oleh Tabel 3.19. Tabel 3.19. Jadwal_1 Kunci primer : Kode_Mata_Kuliah+Jadwal No Nama Field Tipe 1 Kode_Mata_Kuliah Karakter 2 Jadwal Memo
Ukuran 8 -
Perubahan – perubahan tersebut akan mengubah bentuk kerelasian antar tabel / relai dalam basis data, yaitu seperti ditunjukkan oleh Gambar 3.2.
53
Gambar 3.2. Diagram kerelasian antar tabel / relasi hasil modifiasi
Modifikasi rancangan tabel / relasi basis data di atas juga akan mengakibatkan adanya beberapa tabel / relasi yang tidak direlasikan secara definitif tetapi tetap digunakan sebagai acuan / referensi dalam pengolahan data, yaitu : 1. Mata_Kuliah_1 2. Waktu_1 3. Ruang_1 4. Nilai_1 Hal ini tidak menjadi permasalahan, karena akan dapat ditangani secara terprogram oleh program aplikasi yang dikembangkan.
3.4.3. Penggunaan Media Penyimpan Perubahan / modifikasi tabel / relasi basis data dengan menggunakan field memo di atas akan mengubah penggunaan media penyimpan, khususnya bagi tabel / relasi yang semula mengalami duplikasi rinci data dan telah diatasi dengan menggunakan field bertipe memo. Tabel 3.20 menunjukkan penggunaan media penyimpan hasil perubahan / modifikasi di atas, di mana sesuai dengan sebagian besar paket aplikasi pengelolaan basis data terbaru akan memerlukan jumlah byte sesuai dengan panjang teks yang disimpan dalam field memo tersebut.
54
Tabel 3.20. Kapasitas media penyimpan rinci data yang mengalami duplikasi No Nama tabel Nama field Ukuran Jumlah Kapasitas / relasi field record (byte) (byte) 1. KRS_1 Angkatan 2 10000 20000 2. KRS_1 Jenjang_Studi 1 10000 10000 3. KRS_1 Jurusan 2 10000 20000 4. KRS_1 Nomor 4 10000 40000 5. KRS_1 Krs (14+3)*70 10000 11900000 6. Dosen_Mengajar NIK 10 168 1680 7. Dosen_Mengajar Mengajar 14+3 168 2856 8. Jadwal Kode_Mata_Kuliah 8 168 1344 9. Jadwal Jadwal 11+3 168 2352 Total : 11.998.232 Berdasarkan hasil perhitungan di atas, maka total kebutuhan media penyimpan selama satu tahun untuk rinci data pada tabel / relasi hasil perubahan / modifikasi dengan memanfaatkan tipe field memo di atas adalah: Ö 11.998.232 byte Ö 1.1717,0 KB Ö 11,4 MB
3.5. Keuntungan dan Kelemahan Penggunaan Field Bertipe Memo Untuk membuktikan terjadinya peningkatan efisiensi media penyimpan, maka perlu dibandingkan kebutuhan media penyimpan untuk rancangan tabel / relasi basis data dalam bentuk normal ketiga (ternormalisasi) dan yang telah dimodifikasi. Perbandingan akan dilakukan secara khusus pada tabel / relasi yang semula memuat nilai rinci data yang mengalami duplikasi pada hasil normalisasi
55
dan yang menggunakan tipe memo. Berdasrkan hasil analisis di atas, maka diperoleh hasil berupa peningkatan efisiensi media penyimpan sebagaimana ditunjukkan oleh Tabel 3.21.
Tabel 3.21. Peningkatan efisiensi media penyimpan Rancangan pertama Rancangan kedua Peningkatan efisiensi 20,7 MB
11,4 MB
55,1 %
Berdasarkan hasil analisis dan perhitungan yang dilakukan dalam penelitian ini, maka dapat disimpulkan bahwa pemanfaatan field memo untuk minimalisasi duplikasi rinci data pada kunci penghubung, khususnya dalam tabel / relasi bertipe transaksi telah mampu meningkatkan efisiensi penggunaan media penyimpan sekunder sebesar : 55,1 %. Hasil tersebut menunjukkan peningkatan efisiensi yang sangat signifikan dan berpengaruh sangat positif dalam rangka efisiensi media penyimpan, sehingga dapat diterapkan sebagai upaya optimalisasi rancangan tabel / relasi basis data. Pada sisi yang lain, tidak dapat dipungkiri bahwa setiap upaya tentu akan memberikan pengaruh inheren. Dalam hal ini pengaruh yang nyata dari pemanfaatan field memo adalah pengembangan program aplikasi akan menjadi relatif lebih sulit, yaitu secara khusus perlu pengelolaan nilai rinci data dalam field memo yang berisi teks. Hal ini memerlukan memerlukan kecermatan dan pemikiran yang jauh ke depan agar dapat mengantisipasi berbagai kemungkinan
56
yang dapat terjadi berkaitan dengan pengkodean nilai rinci data dalam field memo tersebut.
BAB IV. KESIMPULAN DAN SARAN
4.1. Kesimpulan Berdasarkan hasil penelitian ini, maka dapat disimpulkan beberapa hal sebagai berikut: 1. Pemanfaatan field memo dapat meminimalkan terjadinya duplikasi rinci data pada kunci penghubung dan meningkatkan efisiensi penggunaan media penyimpan hingga sebesar : 55,1 %. 2. Pemanfaatan field memo tepat diterapkan pada basis data yang melibatkan tabel / relasi bertipe transaksi dengan jumlah record yang besar, dalam arti bahwa tabel / relasi tersebut memiliki item rincian dalam jumlah besar. 3. Penggunaan filed memo sebagimana penelitian ini tidak melanggar batasan batasan dalam perancangan basis data. 4. Pemanfaatan field memo memerlukan mekanisme khusus untuk pengelolaan nilai rinci data dalam field memo yang berisi teks. 5. Pemanfaatan field memo memerlukan kecermatan dan pandangan jauh ke depan agar dapat mengantisipasi berbagai kemungkinan yang dapat terjadi berkaitan perancangan pengkodean nilai rinci data dalam field memo.
4.2. Saran Penelitian ini perlu dilanjutkan untuk meneliti sejauhmana pemanfaatan field memo ini berpengaruh terhadap kecepatan pengolahan data dalam basis data
56
DAFTAR PUSTAKA Alam, M. Agus J., Pemrograman Database dengan CA Clipper 5.2, 1995, Elek Media Komputindo, Jakarta. Atre, S., Database : Structured Techniques for Design, Performance and Management With Case Study, 1980, John Wiley & Sons. Date, C.J., An Introduction to Database Systems, 1995, Adisson Wesley Publishing Company Inc. Elmasri, R.; Navathe, S., Fundamental of Databases System, 2nd edition, 1994, Redwood City, The Benjamin Cummings Publishing Company, Inc. Fathansyah, Basis Data, 1999, Informatika, Bandung. Kristanto, Harianto, Konsep dan Perancangan Basis Data, 1993, Andi, Yogyakarta. Kroenke, D.M., Database Processing : Fundalmentals, Design Implementation, 2nd edition, Science Recearch Accosiates Ind., Chicago. Martin, James, Computer Database Organization, part 1-2, 1976, Prentice-Hall Inc., New Jersey. Sutanta, Edhy, Efek Normalisasi Dalam Basis Data Relasional, 2000, Jurnal Academia IST A IST AKPRIND, Yogyakarta. Sutanta, Edhy, Efek Normalisasi Dalam Basis Data Relasional, 2000, Laporan Penelitian. Sutanta, Edhy, Pemanfaatan Field Memo Untuk Minimalisasi Duplikasi Rinci Data Pada Kunci Penghubung, 1999, Makalah Seminar. Ulman J.D., Principles of Database System, 1982, Computer Press Inc., Rockville. Wempen, Faithe, Belajar Sendiri dalam 10 Menit MS Access 2000, 1999, Andi, Yogyakarta. Wiederhold, Gio, Database Design, 1977, McGraw-Hill, New York. Zinzari, dBase, 1992, Andi, Yogyakarta. 57
