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 2. Penyimpanan Data Pada Data Warehouse 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 NIM char 9 Primary Key KODE_STATUS char 5 Foreign Key KODE_JURUSAN varchar 25 Foreign Key KODE_PROGDI char 5 Foreign Key KODE_ORTU int 4 Foreign Key KODE_PROPINSI char 5 Foreign Key NAMA varchar 50 - ALAMAT varchar 50 - KOTA varchar 25 -
25 TMP_LAHIR varchar 25 - TGL_LAHIR varchar 25 - JENIS_KELAMIN vachar 20 - AGAMA varchar 20 - NAMA_SMA varchar 50 - KOTA_SMA vachar 25 - AKT int 4 - - TB_IPS: merupakan tabel fakta yang menyimpan data perolehan Indeks Prestasi Semester (IPS) mahasiswa. Tabel 3.2 Tabel TB_IPS KODE_IPS int 4 Primary Key NIM char 9 Foreign Key KODE_PROGDI char 5 Foreign Key KODE_PERIODE char 10 Foreign Key TOT_SKS int 4 - IPS float 8 - - TB_HASILSTUDI: merupakan tabel fakta yang menyimpan data perolehan Indeks Prestasi Kumulatif (IPK) mahasiswa. Tabel 3.3 Tabel TB_HASILSTUDI KODE_HASIL_STUDI int 4 Primary Key NIM char 9 Foreign Key KODE_PROGDI char 5 Foreign Key TOT_SKS int 4 - TOT_ANGKU int 4 - IPK float 8 - - TB_PIUTANG: merupakan tabel fakta yang menyimpan data piutang mahasiswa. Tabel 3.4 Tabel TB_PIUTANG KODE_PIUTANG bigint 8 Primary Key NIM char 9 Foreign Key KODE_PROGDI char 5 Foreign Key KODE_PERIODE char 10 Foreign Key
26 TAGIHAN money 8 - TERBAYAR money 8 - SALDO money 8 - - TB_PROGDI: merupakan tabel dimensi yang berisi informasi detail setiap program studi. Tabel 3.5 Tabel TB_PROGDI KODE_PROGDI char 5 Primary Key NAMA_PROGDI varchar 50 - JENJANG char 10 - KODE_FAKULTAS varchar 25 - - TB_FAKULTAS: merupakan tabel dimensi yang berisi informasi detail setiap fakultas. Tabel 3.6 Tabel TB_FAKULTAS KODE_FAKULTAS vachar 25 Primary Key NAMA_FAKULTAS varchar 50 - - TB_ORTU: merupakan tabel dimensi yang berisi informasi detail orang tua mahasiswa. Tabel 3.7 Tabel TB_ORTU KODE_ORTU int 4 Primary Key NAMA_ORTU varchar 30 - ALM_ORTU varchar 50 - KOTA_ORTU vachar 25 - KODE_PROPINSI char 5 Foreign Key TELPON_ORTU varchar 15 - KERJA_ORTU varchar 5 - - TB_STATUS: merupakan tabel dimensi yang berisi detail informasi status mahasiswa.
27 Tabel 3.8 Tabel TB_STATUS KODE_STATUS char 5 Primary Key NAMA_STATUS varchar 25 - - TB_PERIODE: merupakan tabel dimensi yang berisi detail informasi periode universitas. Tabel 3.9 Tabel TB_PERIODE KODE_PERIODE char 10 Primary Key TAHUN int 4 - SEMESTER int 4 - - TB_PROPINSI: merupakan tabel dimensi yang berisi detail informasi propinsi. Tabel 3.10 Tabel TB_PROPINSI KODE_PROPINSI char 5 Primary Key NAMA_PROPINSI varchar 30 - - TB_JURUSAN: merupakan tabel dimensi yang berisi detail informasi jurusan mahasiswa. Tabel 3.11 Tabel TB_JURUSAN KODE_JURUSAN vachar 25 Primary Key NAMA_JURUSAN varchar 25 - 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 IPS Lihat Data Terbayar Lihat Tagihan - Terbayar Lihat Data Tagihan Lihat Data Asal SMA Lihat Data IPK Dekan PR 2 Cetak Laporan Tagihan add/edit/del Progdi include Manage Data Piutang PR 1 Login Administrator Manage Data Progdi Lihat Data Jumlah Lihat Data Daerah Asal include Manage Data Manage Data Propinsi Manage Data Periode include add/delete include Manage Data IPS Manage Data IPK include include Manage Data Fakultas add/edit/delete Periode include add/delete IPS add/delete IPK add/edit/del propinsi add/edit/del Fakultas 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 start Login valid invalid Lihat Data Jumlah Lihat Daerah Asal Lihat Asal SMA Lihat IPK Lihat IPS 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 start Login 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 start Login valid invalid Lihat Data Jumlah Lihat Daerah Asal Lihat Asal SMA Lihat IPK Lihat IPS 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 start Login valid invalid Manage Data 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 : PR 1 ViewJumMHSUI JumMHSCon view jumlah mhs request data request data return data display data Gambar 3.9 Diagram Sequence Lihat Jumlah 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 : PR 2 ViewTagihanUI 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 : Dekan ViewIPKUI IPKCon IPK view IPK request data request data return data display data Gambar 3.11 Diagram Sequence Lihat IPK
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 : Administrator AddIPSMhs IPSCon IPS 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 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.