Sisi Dosen
4.3.7 Analisis Binusmaya
4.3.7.4 Analisis Database dan Querybinusmaya
Setelah dilakukan analisis pada database dan query binusmaya, ditemukan beberapa masalah yang diduga menjadi penyebab lambatnya akses serta terjadinya error pada binusmaya berikut ini:
1. Tidak adanyanya rancangan foreign key
ERD awal untuk login dan akses menu utama
Gambar 4.57. ERD awal Login dan akses menu utama
TRApplicationMapping2
ERD awal untuk forum binusmaya
Gambar 4.58. ERD awal Forum
ERD untuk menu lainnya
Gambar 4.66 ERD awal menu lainnya
Dari gambar ERD di atas, dapat dilihat bahwa tidak ada relasi yang dibuat antara tabel-tabel yang ada dengan menggunakan foreign key.Hal ini ternyata dapat menyebabkan lambatnya pengaksesan data yang melibatkan beberapa tabel.(Niyaz, 2008)
Dikarenakan data yang cukup confidential, maka isi dari database tidak dapat ditampilkan. Oleh karena itu, untuk memberikan gambaran mengenai hal tersebut digunakan tabel lain yang dapat menjelaskan permasalahan yang ada.
Gambar 4.59. Rancangan tabel tanpa foreign key
Gambar 4.60. Rancangan tabel tanpa foreign key
Dari rancangan di atas, dilakukan uji coba untuk menampilkan data dari beberapa tabel, hasil perbandingan antara query yang dilakukan di rancangan tabel yang menggunakan Foreign key dan rancangan tabel dari query yang tidak menggunakan foreign key dapat dilihat dari percobaan berikut ini:
Contoh 1
Hasil :
Gambar 4.61. Hasil query pada rancangan tabel yang tidak menggunakanForeign key
Gambar 4.62. Hasil query pada rancangan tabel yang menggunakanForeign key
Select * from headersell a, customer b, employee c Where a.kdcustomer = b.kdcustomer
And a.kdemployee = c.kdemployee
Contoh 2
Hasil:
Gambar 4.63. Hasil query pada rancangan tabel yang tidak menggunakanForeign key
Gambar 4.64. Hasil query pada rancangan tabel yang menggunakanForeign key
Select * from headersell a, customer b, employee c, branch d, position e Where a.kdcustomer = b.kdcustomer
And a.kdemployee = c.kdemployee And c.kdbranch = d.kdbranch And c.kdposition = e.kdposition
Contoh 3
Hasil :
Gambar 4.65. Hasil query pada rancangan tabel yang tidak menggunakan Foreign key
Hasil query pada rancangan tabel yang menggunakanForeign key Select * from headersell a, customer b, cake c
Where a.kdsell = b.kdsell And b.kdcake = c.kdcake
Dari 3 contoh di atas, dapat dilihat dengan menggunakan query yang sama dengan jumlah data yang sama pula di database, query dengan menggunakan struktur tabel yang memilikiforeign key akan lebih cepat dibandingkan dengan query pada struktur tabel yang tidak memilikiforeign key.
Mengapa hal tersebut dapat terjadi?Untuk dapat menjelaskannya secara lebih jelas, maka digunakan contoh yang lebih sederhana yang terdiri dari 2 tabel yaitu tabel sales dan tabel salesorderdetail.
Gambar 4.66. Tabel Sales dan SalesOrderDetail
Query yang dilakukan adalah dengan menampilkan data dari salesorderdetail yang ada di tabel sales seperti berikut ini:
Dengan menggunakan fasilitas SQL 2005, kita dapat melihat proses yang terjadi saat query tersebut dijalankan dengan menggunakan execution plan.
(Singh, 2011)
select so.*from SalesOrderdetail as so ,sales as s where so.CustomerID=s.CustomerID
Gambar 4.67. Execution planpada rancangan tabel yang tidak menggunakan foreign key
Gambar 4.68. Execution plan pada rancangan tabel yang menggunakan foreign key
Dari execution plan tersebut dapat kita lihat query yang dijalankan pada rancangan tabel yang tidak memiliki foreign keyakan mengakses ke seluruh tabel yang ada pada query (tabel sales dan salesorderdetail). Tetapi pada rancangan yang memiliki foreign key, maka query hanya akan mengakses tabel salesorderdetail (tabel yang datanya akan ditampilkan). Hal ini disebabkan karena salah satu bagian dari SQL yaitu optimizer dapat mengetahui bahwa
penggabungan tabel dengan menggunakan primary and foreign key menyebabkan adanya batasan yang mengharuskan semua penjualan untuk merujuk kepada pelanggan (dari tabel sales) sehingga saat query dijalankan tidak perlu dilakukan penelusuran ke tabel sales.
Oleh karena itu untuk meningkatkan performa query maka solusi yang disarankan adalah adanya pembuatan rancangan database yang memiliki foreignkey untuk mempercepat kecepatan query sehingga memperbaiki performa binusmaya.
Selain digunakan untuk meningkatkan performa query, foreign key juga digunakan untuk menjaga integritas data. Jika kita memiliki foreign key dalam rancangan tabel maka saat data dari tabel sales dilakukan update/delete dampak terhadap tabel salesorderdetail pun akan terlihat. Ada 4 pilihan aksi yang dapat dilakukan jika menggunakan foreign key yaitu sebagai berikut:
• CASCADE
Dengan perintah cascade maka ketika dilakukan penghapusan atau perubahan data pada tabel sales, perubahan data akan diterapkan ke tabel salesorderdetail.
• SETNULL
Dengan perintah cascade maka ketika dilakukan penghapusan atau perubahan data pada tabel sales, maka nilai di tabel salesorderdetailakan menjadi NULL. Hal ini dapat terjadi jika kolom tersebut tidak memiliki constraint NOT NULL.
• NOACTION
Dengan perintah cascade maka ketika dilakukan penghapusan atau perubahan data pada tabel sales, maka operasi delete/updateakan dibatalkan karena tidak boleh dilakukannya penghapusan dari tabel parent (dalam hal ini tabel sales).
• SETDEFAULT
Dengan perintah cascade maka ketika dilakukan penghapusan atau perubahan data pada tabel sales, maka data pada tabel salesordetail akan diubah ke nilai default dari kolom tersebut.
Tanpa adaya foreign key, dapat dibayangkan data dalam database akan kacau dan tidak terjaga integritasnya jika data yang seharusnya saling terkait dilakukan update atau delete. Hal ini tentu saja akan menyebabkan database menjadi tidak tepat dan output yang dihasilkan kepada user pun pasti menjadi tidak terpercaya.
Gambar 4.69. Contoh Tabel MsMedia dan TrFailedLogin
Contohnya bisa kita lihat pada gambar di atas, trfailedlogin memiliki hubungan dengan MsMedia, dimana trfailedlogin mengambil data media pada MsMedia. Dengan tidak ada nya foreign key sebagai penghubung, maka ketika terjadi update pada media pada tabel media tidak akan merubah otomatis data media pada tabel TrFailedLogin. Begitupun ketika data media pada tabel MsMedia dihapus, maka data pada TrFailedLogin tidak akan ototmatis terhapus. User harus melakukan perubahan maupun penghapusan data ototmatis. Jika terjadi human error yang menyebabkan kekeliruan user maka akan database akan tidak konsisten dan menyebabkan error pada aplikasi yang digunakan oleh user.
Hal tersebut menunjukan betapa pentingnya perancangan foreign key.Sehingga untuk mengatasi permasalahan dalam lambatnya akses dan sering terjadinya error dari binusmaya, salah satu solusi yang dapat digunakan adalah dengan merancang foreign key untuk rancangan database binusmaya.
Rancangan Database yang sudah menggunakan Foreign Key adalah sebagai berikut:
ERD untuk login dan akses menu utama
Gambar 4.70. ERD dengan Foreign Key untuk login dan akses menu utama ERD untuk forum binusmaya
M sC o u rse O u tlin e
Gambar 4.71. ERD dengan Foreign Key untuk forum ERD untuk menu lainnya
Gambar 4.72. ERD dengan Foreign Key untuk menu lainnya
2. Pengecekan Token
Saat userlogin pertama kali ke binusmaya, maka token akan dibuat secara otomatis dan dimasukan ke tabel TrTokenTransaction yang memiliki kolom BinusianID, TokenID, AccessDate, AccessEndDate, StsRc.
Dalam TrTokenTransaction, binusianID akan mencatat data ID useryang digunakan untuk login , lalu TokenID akan degenerate untuk setiap useryang login . AccessDate akan berisi waktu saat userlogin , AccessEndDate, akan berisi waktu logout dari user, dan StsRc akan berisi Status dari token yang bisa berisi Aktif dan Deaktif. Saat userpertama kali login , maka StsRc akan berisi Aktif. Status akan menjadi Deaktif setelah userlogout.
Setiap kali usermengakses menu yang ada di binusmaya.
Maka akan dilakukan pengecekan terhadap tabel TrTokenTransaction tersebut untuk mengecek apakah usertersebut telah melakukan login atau belum dan apakah status dari token masih aktif. Tidak hanya itu, pengecekan juga dilakukan untun mengecek apakah status dari user (mahasiswa atau dosen). Status ini akan menentukan menu-menu yang akan ditampilkan kepada user tersebut. Sehingga secara logika, jika semakin banyak useryang login ke dalam binusmaya, maka proses pengecekan yang akan dilakukan juga akan semakin lama karena jumlah data dalam tabel
TrTokenTranscation akan memiliki record yang lebih banyak pula. Belum lagi jika useryang sama login ke dalam binusmaya selama beberapa kali dalam sehari, maka data yang tersimpan pun akan lebih banyak pula sehingga proses pengecekan token ketika usermengakses menu akan lebih lama pula. Tercatat dari bulan Januari 2012 sampai dengan april 2012, rata-rata jumlah record per hari untuk tabel ini adalah 8500 record . Record data tersebut akan di backup ke dalam database setiap harinya sehingga dapat dilihat betapa besar media backup yang diperlukan untuk database binusmaya.
Field Tipe Data Ukuran
BinusianID Char 10
TokenID Char 10
AccessDate Datetime 8
AccessEndDate Datetime 8
StsRc varchar 10
Kapasitas 1 record dari tabel TrTokenTransaction adalah 46 bytes.
Diperkirakan jumlah record akan bertambah setiap harinya 8500 record . Dalam satu tahun akan ada 8500 *365=
3102500record
Dalam satu tahun kebutuhan tabel ini adalah 3102500* 46 = 142715000 bytes atau sekitar 139370 KB atau 136 MB
Gambar 4.73. Tabel estimasi tabel trtokentransaction
Dengan adanya penggunaan token, dalam 1 tahun kedepan database binusmaya membutuhkan memory kapasitas sebesar 136 MB. Sehingga dengan menggunakan token proses akan lebih lama dan memerlukan tempat penyimpanan data yang besar pula. Solusi yang disarankan
adalah dengan menggunakan session untuk melakukan pengecekan apakah user sudah login atau belum.
Contoh penggunaa session adalah seperti berikut ini:
Gambar 4.74. Pembuatan session userAuthentication (ndereklangkung, 2010)
Gambar 4.75. Pengaturan waktu untuk session userAuthentication(How to redirect to Login Page on Session
Timeout RSS, 2011)
Gambar 4.76. Pengecekan halaman dengan menggunakan session userAuthentication(ArunKarthik, 2011)
Gambar 4.77. Penghapusan session userAuthentication (ndereklangkung, 2010)
3. Index
Database binusmaya tidak dirancang dengan menggunakan index. Padahal index merupakan salah satu cara yang dapat meningkatkan performa dari database. Dengan menggunakan index , data tidak perlu di cari dari awal hingga akhir. Index merupakan sebuah metode pencarian yang dapat mempercepat proses pencarian karena data tidak perlu dicari dari awal hingga akhir.
Tanpa adanya index , proses pencarian dilakukan dengan scan tabel. Scan tabel adalah suatu proses pencarian data dalam tabel yang dapat kita ibaratkan seperti mencari arti kata dalam sebuah kamus tanpa menggunakan index huruf. Tentu saja hal ini menyebabkan sulitnya proses pencarian dan lama nya pencarian karena kata tersebut harus di cari satu per satu dalam kamus. Hal tersebutlah yang terjadi ketika kita tidak mempunyai index , proses pencarian akan lebih memakan waktu.
Dengan adanya index , proses pencarian data dalam tabel akan sama seperti kita mencari arti kata di kamus.
Pencarian akan lebih cepat & efisien.
Ada 2 jenis index yaitu cluster dan non cluster.Index cluster adalah index yang membuat data baru yang diinsert akan disisipkan pada data yang ada sehingga data dalam tabel tersebut akan terurut. Oleh karena itu proses pencarian dengan menggunakan index clusterakan lebih cepat. Dalam sebuah tabel hanya boleh terdapat 1 clusterindex .
Gambar 4.78. kode untuk pembuatan index cluster
Jika clusterindex dapat kita ibaratkan seperti index huruf dalam kamus, nonclusterindex dapat diumpamakan seperti daftar index dalam buku. Ketika kita mencari arti dengan index huruf, maka data yang akan kita temukan langsung. Namun dengan daftar index , yang kita dapatkan hanya lokasi dari data yang ingin kita cari. Jadi non clusterindex berisi pointer yang menunjukan lokasi dari data yang dicari. Cara ini sedikit membutuhkan waktu
CREATE [ UNIQUE ] [ NONCLUSTERED ] INDEX index_name
ON < object >( column[ ASC | DESC ] [ ,…n ] ) [ INCLUDE ( column_name [ ,…n ] ) ]
[ WITH ( <relational_index_option> [ ,…n ] ) ] [ ON { partition_scheme_name (column_name)
| filegroup_name | default } ][ ; ]
dibandingkan dengan clusterindex . Namun cara ini akan membantu dibandingkan dengan menggunakan scan tabel. Jika clusterindex hanya boleh ada 1 dalam satu tabel, nonclusterindex dapat diimplementasikan sebanyak 249 buah dalam satu tabel.
Gambar 4.79. Kode untuk pembuatan index noncluster
Penentuan index harus tepat agar mendapatkan performa yang baik. Pertimbangan dalam penentuan index adalah seberapa sering data-data diakses melalui operasi select, update, dan delete. Beberapa hal yang dapat digunakan sebagai landasan dalam menentukan index adalah sebagai berikut:
1. Kolom yang sering dicari 2. Primary key dan foreign key 3. Kolom yang diakses secara abjad
4. Kolom yang diakses dan sering digunakan untuk join CREATE [ UNIQUE ] [ NONCLUSTERED ] INDEX index_name
ON < object >( column[ ASC | DESC ] [ ,…n ] ) [ INCLUDE ( column_name [ ,…n ] ) ]
[ WITH ( <relational_index_option> [ ,…n ] ) ] [ ON { partition_scheme_name (column_name)
| filegroup_name | default } ][ ; ]
5. Kolom yang berisi nilai dengan jangkauan luas 6. Kolom yang sering digunakan dalam kondisi “where”
7. Tabel dengan ukuran besar dans sebagian besar query menampilkan data kurang dari 2-4% dari total data.
Database binusmaya tidak dirancang dengan index kecuali pada primary key yang terbentuk secara otomatis ketika pembuatan primary key itu sendiri.Padahal sesuai dengan kriteria-kriteria dari sebuah index yang sudah dijelaskan sebelumnya menunjukan keadaan yang ada pada database binusmaya.Contohnya adalah kolom kodematakuliah yang sering digunakan misalnya untuk menampilkan kelas mahasiswa, dalam forum diskusi, menambahkan atau menghapus additionalmaterial. Selain itu hasil dari query dengan menggunakan kode matakuliah tidaklah menghasilkan record yang banyak ( kurang dari 2-4%).
Contoh pembuatan index untuk kolom kodematakuliah adalah sebagai berikut:
CREATE UNIQUE NONCLUSTERINDEX