Bab 3 Metodologi Perbandingan 3.1
Pengantar Pada Bab 3 ini akan dibahas tentang skenario perbandingan
yang akan digunakan untuk membandingkan Traditional Business Intelligence dengan Service-oriented Business Intelligence untuk integrasi data akademik dan keuangan. Metodologi perbandingan ini dirancang berdasarkan literatur dan teori pendukung pada bab sebelumnya.
3.2
Skenario Perbandingan Berikut ini akan disajikan skenario yang akan dikerjakan
dalam membandingkan Traditional Business Intelligence dengan Service-oriented Business Intelligence. Oleh karena itu sebelum perbandingan dilakukan, terlebih dahulu akan disiapkan spesimen / objek yang akan dilakukan perbandingan. Spesimen yang disiapkan adalah desain arsitektur Traditional Business Intelligence dan desain arsitektur SoBI. Selain itu akan disiapkan data warehouse yang akan digunakan untuk menyimpan data hasil integrasi dari SIASAT dan SIKASA. Perbandingan akan dimulai dari desain arsitektur, proses dan hasil implementasi dari desain yang sudah disiapkan ini. Desain dari arsitektur BI tradisional dapat dilihat pada Gambar 3.1 dan desain arsitektur SoBI dapat dilihat pada Gambar 3.2.
21
22
Gambar 3.1 Desain BI Tradisional
Desain pada Gambar 3.1 dapat dijelaskan sebagai berikut: 1.
Pengambilan Data Akademik dan Keuangan (Extract) Input data sistem adalah berupa data akademik dan keuangan
yang tersimpan dalam 2 (dua) database yang berbeda. Data akademik berasal dari SIASAT yaitu pada database SQL Server 2000 dan data keuangan berasal dari SIKASA yaitu pada database MySQL. Data dari kedua sumber ini di-extract ke dalam format excel (.xls). 2.
Proses Transformasi Data Sebelum data dimasukkan ke dalam data warehouse, data
dalam format excel hasil extract dari database SIASAT dan SIKASA tadi dilakukan proses transform, yaitu dengan melakukan penyesuaian dengan data warehouse yang sudah dirancang. 3.
Proses Loading Data ke Dalam Data Warehouse Setelah itu data kemudian dimasukkan/di-import (loading) ke
dalam data warehouse menggunakan fitur import data pada SQL Server 2008.
23
4.
Penyajian Data Melalui Aplikasi OLAP Data dalam data warehouse kemudian akan disajikan melalui
aplikasi OLAP. Aplikasi OLAP ini akan menyajikan data yang akan ditampilkan dalam grafik batang dan dalam tabel sehingga dapat membantu dalam melakukan analisis data untuk pengambilan keputusan.
Gambar 3.2 Desain BI dengan SoBI
Desain pada Gambar 3.2 dapat dijelaskan sebagai berikut: 1.
Pengambilan Data Akademik dan Keuangan Input data sistem adalah berupa data akademik dan keuangan
yang tersimpan dalam 2 (dua) database yang berbeda. Data akademik berasal dari SIASAT yaitu pada database SQL Server 2000 dan data keuangan berasal dari SIKASA yaitu pada database MySQL. Data dari 2 (dua) database berbeda ini akan diambil menggunakan web service. Hal ini dilakukan dengan menyediakan beberapa web service pada sisi aplikasi SIASAT dan SIKASA.
24
Penyimpanan Data Pada Data Warehouse
2.
Data akademik dan keuangan dari 2 (dua) database yang berbeda akan diambil menggunakan web service untuk dimasukkan ke dalam suatu data warehouse pada SQL Server 2008. Proses ini dilakukan melalui aplikasi dashboard yang sudah dibuat. 3.
Penyajian Data Melalui Aplikasi OLAP Data dalam data warehouse kemudian akan disajikan melalui
aplikasi OLAP. Aplikasi OLAP ini akan menyajikan data yang akan ditampilkan dalam grafik batang dan dalam tabel sehingga dapat membantu dalam melakukan analisis data untuk pengambilan keputusan.
3.3
Perancangan Data Warehouse Data warehouse dirancang menggunakan pendekatan Galaxy
Schema. Pada schema ini ada beberapa tabel fakta yang digunakan bersama-sama oleh beberapa tabel dimensi. Tabel-tabel yang dirancang untuk menyimpan data akademik dan keuangan adalah: - TB_MAHASISWA: merupakan tabel fakta yang menyimpan informasi data diri mahasiswa. Tabel 3.1 Tabel TB_MAHASISWA Field
Type
Size
NIM KODE_STATUS KODE_JURUSAN KODE_PROGDI KODE_ORTU KODE_PROPINSI NAMA ALAMAT KOTA
char char varchar char int char varchar varchar varchar
9 5 25 5 4 5 50 50 25
Keterangan
Primary Key Foreign Key Foreign Key Foreign Key Foreign Key Foreign Key -
25
TMP_LAHIR TGL_LAHIR JENIS_KELAMIN AGAMA NAMA_SMA KOTA_SMA AKT
varchar varchar vachar varchar varchar vachar int
25 25 20 20 50 25 4
-
- TB_IPS: merupakan tabel fakta yang menyimpan data perolehan Indeks Prestasi Semester (IPS) mahasiswa. Tabel 3.2 Tabel TB_IPS Field
Type
Size
int char char char int float
KODE_IPS NIM KODE_PROGDI KODE_PERIODE TOT_SKS IPS
4 9 5 10 4 8
Keterangan
Primary Key Foreign Key Foreign Key Foreign Key -
- TB_HASILSTUDI: merupakan tabel fakta yang menyimpan data perolehan Indeks Prestasi Kumulatif (IPK) mahasiswa. Tabel 3.3 Tabel TB_HASILSTUDI Field
Type
KODE_HASIL_STUDI NIM KODE_PROGDI TOT_SKS TOT_ANGKU IPK
int char char int int float
Size
4 9 5 4 4 8
Keterangan
Primary Key Foreign Key Foreign Key -
- TB_PIUTANG: merupakan tabel fakta yang menyimpan data piutang mahasiswa. Tabel 3.4 Tabel TB_PIUTANG Field
KODE_PIUTANG NIM KODE_PROGDI KODE_PERIODE
Type
bigint char char char
Size
8 9 5 10
Keterangan
Primary Key Foreign Key Foreign Key Foreign Key
26
TAGIHAN TERBAYAR SALDO
money money money
8 8 8
-
- TB_PROGDI: merupakan tabel dimensi yang berisi informasi detail setiap program studi. Tabel 3.5 Tabel TB_PROGDI Field
KODE_PROGDI NAMA_PROGDI JENJANG KODE_FAKULTAS
Type
Size
char varchar char varchar
5 50 10 25
Keterangan
Primary Key -
- TB_FAKULTAS: merupakan tabel dimensi yang berisi informasi detail setiap fakultas.
Tabel 3.6 Tabel TB_FAKULTAS Field
KODE_FAKULTAS NAMA_FAKULTAS
Type
Size
vachar varchar
25 50
Keterangan
Primary Key -
- TB_ORTU: merupakan tabel dimensi yang berisi informasi detail orang tua mahasiswa. Tabel 3.7 Tabel TB_ORTU Field
KODE_ORTU NAMA_ORTU ALM_ORTU KOTA_ORTU KODE_PROPINSI TELPON_ORTU KERJA_ORTU
Type
Size
int varchar varchar vachar char varchar varchar
4 30 50 25 5 15 5
Keterangan
Primary Key Foreign Key -
- TB_STATUS: merupakan tabel dimensi yang berisi detail informasi status mahasiswa.
27
Tabel 3.8 Tabel TB_STATUS Field
KODE_STATUS NAMA_STATUS
Type
Size
char varchar
5 25
Keterangan
Primary Key -
- TB_PERIODE: merupakan tabel dimensi yang berisi detail informasi periode universitas. Tabel 3.9 Tabel TB_PERIODE Field
Type
KODE_PERIODE TAHUN SEMESTER
char int int
Size
10 4 4
Keterangan
Primary Key -
- TB_PROPINSI: merupakan tabel dimensi yang berisi detail informasi propinsi. Tabel 3.10 Tabel TB_PROPINSI Field
KODE_PROPINSI NAMA_PROPINSI
Type
Size
char varchar
5 30
Keterangan
Primary Key -
- TB_JURUSAN: merupakan tabel dimensi yang berisi detail informasi jurusan mahasiswa. Tabel 3.11 Tabel TB_JURUSAN Field
KODE_JURUSAN NAMA_JURUSAN
Type
Size
vachar varchar
25 25
Keterangan
Primary Key -
Desain data warehouse menggunakan Galaxy Schema yang dirancang dapat dilihat pada Gambar 3.3.
28
Gambar 3.3 Galaxy Schema Data Warehouse
Gambar 3.3 merupakan desain data warehouse yang dibuat menggunakan Galaxy Shcema. Pada shcema ini terdapat 4 (empat) tabel fakta, yaitu TB_MAHASISWA, TB_IPS, TB_HASILSTUDI dan TB_PIUTANG. Keempat tabel fakta ini saling berbagi tabel dimensi, yaitu tabel TB_IPS dan TB_PIUTANG saling berbagi tabel dimensi TB_PERIODE. TB_MAHASISWA, TB_IPS, TB_HASILSTUDI dan TB_PIUTANG saling berbagi tabel dimensi TB_PROGDI.
3.4
Perancangan Aplikasi Dashboard Pada bagian ini akan dijelaskan tentang perancangan aplikasi
dashboard yang disajikan dalam diagram UML. Aplikasi dashboard ini nantinya akan digunakan juga sebagai kriteria perbandingan Traditional BI dan SoBI.
29
3.4.1
Diagram Use Case Diagram Use Case dari aplikasi dashboard yang akan
dibangun dapat dilihat pada Gambar 3.4.
Lihat Data Terbayar Lihat Tagihan - Terbayar
Lihat Data IPS Mahasiswa
Lihat Data Tagihan Cetak Laporan Tagihan
Lihat Data Asal SMA Mahasiswa
add/edit/del Progdi PR 2 Dekan
include Manage Data Piutang
Lihat Data IPK Mahasiswa
Login
PR 1
Manage Data Progdi
Administrator
Lihat Data Jumlah Mahasiswa
Manage Data Periode Manage Data Mahasiswa Lihat Data Daerah Asal Mahasiswa
include Manage Data Propinsi
include
include
Manage Data Fakultas
Manage Data IPS Manage Data IPK add/delete Mahasiswa
include
add/edit/delete Periode
include
include
add/edit/del propinsi add/edit/del Fakultas add/delete IPS
add/delete IPK
Gambar 3.4 Diagram Use Case Aplikasi Dashboard
Pada diagram use case di Gambar 3.4 terdapat 4 (empat) aktor, yaitu Pembantu Rektor 1 (PR 1), Pembantu Rektor 2 (PR 2), Dekan dan Administrator. Masing-masing aktor mempunyai beberapa use case, antara lain aktor PR 2 memiliki use case Lihat Data Tagihan, Lihat Data Terbayar, Lihat Tagihan – Terbayar dan Cetak Laporan Tagihan. 3.4.2
Diagram Activity Berikut ini akan dijelaskan diagram activity dari aplikasi
dashboard yang akan dibuat. Terdapat 4 (empat) buah diagram activity untuk setiap aktor yang ada, yaitu diagram activity untuk Pembantu Rektor 1 (PR 1), Pembantu Rektor 2 (PR 2), Dekan dan Administrator.
30
-
Diagram Activity PR 1
PR 1
Sistem
Login
start
valid
invalid
Lihat Data Jumlah Mahasiswa Lihat Daerah Asal Mahasiswa Lihat Asal SMA Mahasiswa Lihat IPK Mahasiswa Lihat IPS Mahasiswa
end
Gambar 3.5 Diagram Activity PR 1
Diagram
Activity
pada
Gambar
3.5
menggambarkan
aktivitas-aktivitas yang dapat dikerjakan oleh PR 1. Setelah login valid, PR 1 dapat melakukan beberapa aktivitas, yaitu lihat data jumlah mahasiswa, lihat daerah asal mahasiswa, lihat asal SMA, lihat IPK mahasiswa dan lihat IPS mahasiswa.
31
-
Diagram Activity PR 2 PR 1
Sistem
Login
start
invalid valid
Lihat Data Tagihan Lihat Data Terbayar
Lihat Tagihan Terbayar Buat Laporan
end
Gambar 3.6 Diagram Activity PR 2
Pada diagram activity pada Gambar 3.6 dapat dijelaskan aktivitas-aktivitas yang dapat dikerjakan oleh PR 2.
Aktivitas
dimulai dengan proses login. Jika proses login valid, maka PR 2 dapat melakukan aktivitas berikutnya yaitu lihat data tagihan mahasiswa, lihat data tagihan terbayar, lihat data terbayar dan dapat mencetak laporan dalam format .pdf.
32
-
Diagram Activity Dekan Fakultas
Dekan
Sistem
Login
start
valid
invalid
Lihat Data Jumlah Mahasiswa Lihat Daerah Asal Mahasiswa Lihat Asal SMA Mahasiswa Lihat IPK Mahasiswa Lihat IPS Mahasiswa
end
Gambar 3.7 Diagram Activity Dekan Fakultas
Diagram activity pada Gambar 3.7 menggambarkan aktivitasaktivitas yang dapat dikerjakan oleh dekan. Aktivitas dimulai dengan proses login. Jika login valid, maka dekan dapat melakukan aktivitas selanjutnya, yaitu lihat data jumlah mahasiswa, lihat daerah asal mahasiswa, lihat asal SMA mahasiswa, lihat IPK mahasiswa dan lihat IPS mahasiswa.
33
-
Diagram Activity Administrator
Administrator
Sistem
Login
start
invalid
valid
Manage Data Mahasiswa Manage Data IPS Manage Data IPK Manage Data Piutang Manage Data Fakultas Manage Data Progdi Manage Data Periode Manage Data Propinsi end
Gambar 3.8 Diagram Activity Administrator
Diagram activity pada Gambar 3.8 menggambarkan aktivitas apa saja yang dapat dikerjakan oleh administrator. Setelah login valid, administrator dapat melanjutkan aktivitas lainnya, yaitu manage data mahasiswa, manage data IPS, manage data IPK, manage data piutang, manage data fakultas, manage data progdi, manage data periode dan manage data propinsi.
34
3.4.3
Diagram Sequence Berikut ini akan dijelaskan tentang diagram sequence untuk
setiap aktor dalam sistem yang dibangun. Setiap aktor akan diberikan 1 (satu) diagram sequence pada salah satu proses yang dapat dikerjakan oleh aktor tersebut. -
Diagram Sequence Lihat Data Jumlah Mahasiswa
: PR 1
ViewJumMHSUI
JumMHSCon
Mahasiswa
view jumlah mhs request data request data
return data display data
Gambar 3.9 Diagram Sequence Lihat Jumlah Mahasiswa
Diagram sequence pada Gambar 3.9 menggambarkan diagram sequence lihat data jumlah mahasiswa untuk aktor PR 1. Urutan prosesnya adalah: PR 1 membuka halaman view jumlah mahasiswa, kemudian controller untuk menampilkan data jumlah mahasiswa akan dipanggil dan controller akan meneruskannya ke tabel mahasiswa untuk mengambil data mahasiswa yang direquest. Data yang direquest akan dikembalikan dan ditampilkan pada halaman view data jumlah mahasiswa.
35
-
Diagram Sequence Lihat Data Piutang
ViewTagihanUI
: PR 2
TagihanCon
Piutang
view data tagihan request data request data
return data display data
Gambar 3.10 Diagram Sequence Lihat Piutang
Diagram sequence pada Gambar 3.10 adalah urutan proses lihat data piutang yang dilakukan oleh aktor PR 2. PR 2 membuka halaman view tagihan, lalu tagihan controller akan dipanggil untuk merequest data piutang dari tabel piutang dalam database. Selajutnya data akan dikembalikan dan ditampilkan pada halaman view tagihan. -
Diagram Sequence Lihat IPK Mahasiswa
: Dekan
ViewIPKUI
IPKCon
IPK
view IPK request data request data
return data display data
Gambar 3.11 Diagram Sequence Lihat IPK Mahasiswa
36
Gambar 3.11 adalah diagram sequence untuk proses lihat IPK mahasiswa yang dilakukan oleh aktor dekan fakultas. Proses dimulai dengan dibukanya halaman view IPK, lalu controller akan merequest data IPK yang diminta ke tabel IPK dalam database. Data IPK akan dikembalikan dan ditampilkan pada halaman view. -
Diagram Sequence Tambah Data IPS Mahasiswa
AddIPSMhs
IPSCon
IPS
: Administrator addIPS(kode_ips, nim, kode_progdi, kode_periode, tot_sks, ips) send data(kode_ips, nim, kode_progdi, kode_periode, tot_sks, ips)
save data(kode_ips, nim, kode_prog... return done
konfirmasi
Gambar 3.12 Diagram Sequence Tambah Data IPS Mahasiswa
Diagram sequence pada Gambar 3.12 menggambarkan urutan proses dari tambah data IPS mahasiswa yang dilakukan oleh aktor administrator. Mula-mula, administrator membuka halaman add IPS mahasiswa, selanjutnya controller IPS akan dipanggil untuk menambahkan
data
berupa
kode_ips,
nim,
kode_progdi,
kode_periode, tot_sks dan ips ke dalam tabel IPS dalam database. Sistem akan mengembalikan informasi kepada administrator apakah proses input data IPS berhasil atau gagal, informasi ditampilkan pada halaman view IPS mahasiswa.
37
3.4.4
Diagram Class
Gambar 3.13 Diagram Class Aplikasi Dashboard
Diagram class pada Gambar 3.13 memberikan gambaran class yang digunakan dalam sistem. Diagram class ini terdiri dari 3 (bagian) yaitu bagian controller, user interface dan entitas yang terlibat.
3.5
Kriteria Perbandingan Berdasarkan arsitektur yang sudah disiapkan, maka dapat
disiapkan kriteria perbandingan sebagai berikut:
38
3.5.1 Perbandingan dari Perspektif Developer Pada
perbandingan
dari
perspektif
developer
akan
dibandingkan dari sisi implementasi kedua arsitektur. Pada perspektif ini, akan dilihat perbandingan setiap proses yang harus dilalui dalam implementasi setiap arsitektur. Hasilnya akan diketahui arsitektur mana yang lebih mudah diimplementasikan oleh developer. 3.5.2 Perbandingan dari Perspektif User Pada
perbandingan
dari
sisi
perspektif
user
akan
dibandingkan dari sisi user dalam melakukan penambahan dan integrasi data ke dalam data warehouse. Hasilnya akan diketahui proses integrasi pada arsitektur mana yang jauh lebih mudah dilakukan oleh user. 3.5.3 Perbandingan dari Perspektif Pengembangan Sistem Pada perbandingan dari sisi perpektif ini akan dibandingkan tentang bagaimana perkembangan yang dapat dilakukan di kemudian hari terhadap kedua arsitektur sehingga akan terlihat arsitektur mana yang lebih mudah dalam proses pengembangan sistem. 3.5.4 Perbandingan dari Perspektif Aplikasi Dashboard Pada perbandingan dari sisi perspektif aplikasi dashboard akan dibandingkan bagaimana Traditional BI dan SoBI dalam mendukung aplikasi front-end, yaitu untuk aplikasi dashboard dalam menampilkan report untuk analisis data dalam data warehouse.
39
3.5.5 Perbandingan Scalability Sistem Pada perbandingan scability sistem akan dibandingkan dalam hal dukungan terhadap berbagai ukuran data yang diintegrasikan ke dalam data warehouse. 3.5.6 Perbandingan Stability Sistem Pada perbandingan stability sistem akan dibandingkan dalam hal kestabilan sistem dalam mendukung proses integrasi data, yaitu pada integrasi data dengan jumlah data yang besar.
