Bab 3 Metodologi Perbandingan

(1)

21

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.

(2)

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.

(3)

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.

(4)

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

Field Type Size Keterangan

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 -

(5)

- TB_IPS: merupakan tabel fakta yang menyimpan data perolehan Indeks Prestasi Semester (IPS) mahasiswa.

Tabel 3.2 Tabel TB_IPS

- TB_HASILSTUDI: merupakan tabel fakta yang menyimpan data perolehan Indeks Prestasi Kumulatif (IPK) mahasiswa.

Tabel 3.3 Tabel TB_HASILSTUDI

- TB_PIUTANG: merupakan tabel fakta yang menyimpan data piutang mahasiswa.

Tabel 3.4 Tabel TB_PIUTANG

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 -

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 -

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 -

KODE_PIUTANG bigint 8 Primary Key

NIM char 9 Foreign Key

KODE_PROGDI char 5 Foreign Key KODE_PERIODE char 10 Foreign Key

(6)

- TB_PROGDI: merupakan tabel dimensi yang berisi informasi detail setiap program studi.

Tabel 3.5 Tabel TB_PROGDI

- TB_FAKULTAS: merupakan tabel dimensi yang berisi informasi detail setiap fakultas.

Tabel 3.6 Tabel TB_FAKULTAS

- TB_ORTU: merupakan tabel dimensi yang berisi informasi detail orang tua mahasiswa.

Tabel 3.7 Tabel TB_ORTU

- TB_STATUS: merupakan tabel dimensi yang berisi detail informasi status mahasiswa.

TAGIHAN money 8 -

TERBAYAR money 8 -

SALDO money 8 -

KODE_PROGDI char 5 Primary Key

NAMA_PROGDI varchar 50 -

JENJANG char 10 -

KODE_FAKULTAS varchar 25 -

KODE_FAKULTAS vachar 25 Primary Key

NAMA_FAKULTAS varchar 50 -

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 -

(7)

Tabel 3.8 Tabel TB_STATUS

- TB_PERIODE: merupakan tabel dimensi yang berisi detail informasi periode universitas.

Tabel 3.9 Tabel TB_PERIODE

- TB_PROPINSI: merupakan tabel dimensi yang berisi detail informasi propinsi.

Tabel 3.10 Tabel TB_PROPINSI

- TB_JURUSAN: merupakan tabel dimensi yang berisi detail informasi jurusan mahasiswa.

Tabel 3.11 Tabel TB_JURUSAN

Desain data warehouse menggunakan Galaxy Schema yang dirancang dapat dilihat pada Gambar 3.3.

KODE_STATUS char 5 Primary Key

NAMA_STATUS varchar 25 -

KODE_PERIODE char 10 Primary Key

TAHUN int 4 -

SEMESTER int 4 -

KODE_PROPINSI char 5 Primary Key

NAMA_PROPINSI varchar 30 -

KODE_JURUSAN vachar 25 Primary Key

(8)

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

(9)

3.4.1 Diagram Use Case

Diagram Use Case dari aplikasi dashboard yang akan dibangun dapat dilihat pada Gambar 3.4.

Lihat Data Tagihan

Lihat Data Terbayar Lihat Tagihan - Terbayar

PR 2

Cetak Laporan Tagihan

Login PR 1

Lihat Data IPS Mahasiswa

Lihat Data Asal SMA Mahasiswa

Lihat Data IPK Mahasiswa

Lihat Data Jumlah Mahasiswa

Dekan

Lihat Data Daerah Asal Mahasiswa

Manage Data Mahasiswa

Manage Data IPS

Manage Data Piutang

Manage Data Progdi

Manage Data Propinsi

Manage Data IPK

Manage Data Fakultas Administrator

Manage Data Periode

add/delete Mahasiswa include add/delete IPS include add/delete IPK include add/edit/del propinsi include add/edit/del Fakultas include add/edit/del Progdi include add/edit/delete Periode include

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.

(10)

- Diagram Activity PR 1

start Login

invalid

Lihat Data Jumlah Mahasiswa Lihat Daerah Asal

Mahasiswa Lihat Asal SMA

Mahasiswa Lihat IPK Mahasiswa Lihat IPS Mahasiswa end valid Sistem PR 1

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.

(11)

- Diagram Activity PR 2 start Login invalid Lihat Data Tagihan Lihat Data Terbayar Lihat Tagihan Terbayar Buat Laporan end valid Sistem PR 1

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.

(12)

- Diagram Activity Dekan Fakultas

start Login

invalid

Lihat Data Jumlah Mahasiswa Lihat Daerah Asal

Mahasiswa Lihat Asal SMA

Mahasiswa Lihat IPK Mahasiswa Lihat IPS Mahasiswa end valid Sistem Dekan

Gambar 3.7 Diagram Activity Dekan Fakultas

Diagram activity pada Gambar 3.7 menggambarkan aktivitas-aktivitas 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.

(13)

- Diagram Activity Administrator start Login invalid 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 valid Sistem Administrator

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.

(14)

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

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.

(15)

- Diagram Sequence Lihat Data Piutang

: PR 2 ViewTagihanUI TagihanCon Piutang

view data tagihan

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

return data display data

(16)

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

: 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 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.

(17)

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:

(18)

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

(19)

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.

(20)