BAB III
ANALISIS DAN RANCANGAN SISTEM 3.1. Metode Penilitian
Berikut merupakan metode-metode penelitian yang digunakan dalam mengumpulkan data yang terkait dengan penelitian.
3.1.1. Metode Pengumpulan data: 3.1.1.1. Wawancara
Wawancara dilakukan di Perpustakaan Daerah Kabupaten Lumajang bersama dengan teknisi server perpustakaan pada tanggal 03 Oktober 2016. Pada wawancara pertama dilakukan tanya jawab mengenai permasalahan-permasalahan yang sering dijumpai teknisi, bagaimana sistem database operasional bekerja, dan meminta keseluruhan data di database terhitung hingga tanggal 03 Oktober 2016. Pada wawancara kedua pada tanggal 20 Januari 2017, dilakukan tanya jawab mengenai proses bisnis pada transaksi peminjaman, pengembalian dan bagaimana perpustakaan melakukan pengadaan buku sehingga terdapat komparasi pada pengambilan keputusan ketika adanya data warehouse dengan tidak adanya data warehouse.
3.1.1.2. Studi pustaka
Studi pustaka dilakukan dengan membaca buku jurnal maupun penelitan yang serupa pada bidang data warehouse. Membaca buku jurnal maupun penelitan yang serupa bertujuan agar bisa mengkomparasi dan menghindari adanya plagiarisme dan bisa menjadi acuan sumber yang dapat digunakan dalam pengerjaan penelitian. Selain buku jurnal dan penelitan, dalam penelitian ini juga menggunakan buku yang berkaitan dengan data warehouse seperti buku Kimball dan buku Inmon sebagai sumber terpecaya untuk mendukung teori-teori yang ada pada penelitian ini. Buku yang berkaitan dengan perpustakaan dan informasi juga menjadi acuan studi pustaka untuk mendukung teori mengenai perpustakaan dan informasi.
memi l i ki
Rel ati onshi p_2
Rel ati onshi p_3
Rel ati onshi p_7 Rel ati onshi p_5
user_account userID
userT ype regi sterT i meStamp userAccount userPassword l ostPasswordQuesti on l ostPasswordAnswer l astUpadate l astLogi n acti vati onCode i sApproved userName userRel i gi on userSex userBi rthday userBi rthPl ace userAddress userPhone userAffi l i ati on userCompany userInterest userSi gnature userEmai l userWebsi te userICQ userAIM userYIM userMSNM userLanguage userImage userNoktp userKec userInstansi userKel <pi > <pi > Integer <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <M> <M>
Identi fi er_1 <pi > l oan l oanID userName l i braryT i tl e l oanDate returnDate returnedDate extendedCount l oanT ype
<pi > <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <M>
Identi fi er_1 <pi >
l i brary_datauni t date staffAccount l i braryMai nNumber l i braryPri ce l i braryOrderDate l i braryArri veDate l i braryLocati on l i braryCondi ti on <pi > <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <M>
Identi fi er_1 <pi >
l i brary l i braryDate staffAccount l i braryID l i braryMateri al T ype l i braryCol l ecti on l i braryCal l Number l i braryISBN l i braryAuthor l i brary_nama_depan_pengarang l i brary_nama_bl k_pengarang l i braryAddi ti onal Author l i braryCooperate l i braryT i tl e no_i nduk no_reg j ml _buku pri ce dms_buku l i braryLocati on l i brarySubT i tl e l i braryEdi ti on l i braryCi tyPubl i shed l i braryPubl i sher l i braryYearPubl i shed l i braryVol ume l i braryDesc l i brarySeri es l i braryIsReference l i brarySubj ect l i braryKeyword l i braryGai n l i braryNotes l i braryImage <pi > <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <M> facul ty facul tyID facul tyName facul tyDesc <Undefi ned> <Undefi ned> <Undefi ned> department departmentID departmentName departmentDesc
<pi > <Undefi ned> <Undefi ned> <Undefi ned>
<M> Identi fi er_1 <pi >
3.2. CDM dan PDM database
Di setiap penelitian yang berhubungan dengan database selalu menggunakan Conceptual Data Model (CDM) dan Physical Data Model (PDM). Berikut adalah CDM dan PDM mengenai database dan pada penelitan ini
3.2.2. Database Physical Data Model (PDM)
Gambar 3.21 Physical Data Model (PDM) database
user_account userID
userT ype regi sterT i meStamp userAccount departmentID userPassword l ostPasswordQuesti on l ostPasswordAnswer l astUpadate l astLogi n acti vati onCode i sApproved userName userRel i gi on userSex userBi rthday userBi rthPl ace userAddress userPhone userAffi l i ati on userCompany userInterest userSi gnature userEmai l userWebsi te userICQ userAIM userYIM userMSNM userLanguage userImage userNoktp userKec userInstansi userKel i nteger <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <pk> <pk> <fk> l oan l oanID l i braryMai nNumber userID userAccount userName l i braryT i tl e l oanDate returnDate returnedDate extendedCount l oanT ype <Undefi ned> <Undefi ned> i nteger <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <pk> <fk2> <fk1> <fk1> l i brary_datauni t date staffAccount l i braryMai nNumber l i braryID l i braryPri ce l i braryOrderDate l i braryArri veDate l i braryLocati on l i braryCondi ti on <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <pk> <fk> l i brary l i braryDate staffAccount l i braryID l i braryMateri al T ype l i braryCol l ecti on l i braryCal l Number l i braryISBN l i braryAuthor l i brary_nama_depan_pengarang l i brary_nama_bl k_pengarang l i braryAddi ti onal Author l i braryCooperate l i braryT i tl e no_i nduk no_reg j ml _buku pri ce dms_buku l i braryLocati on l i brarySubT i tl e l i braryEdi ti on l i braryCi tyPubl i shed l i braryPubl i sher l i braryYearPubl i shed l i braryVol ume l i braryDesc l i brarySeri es l i braryIsReference l i brarySubj ect l i braryKeyword l i braryGai n l i braryNotes l i braryImage <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <pk> facul ty facul tyID facul tyName facul tyDesc <Undefi ned> <Undefi ned> <Undefi ned> department departmentID departmentName departmentDesc <Undefi ned> <Undefi ned> <Undefi ned> <pk>
Berikut adalah database OLTP ( yang didapat dari Perpustakaan Daerah Kabupaten Lumajang):
Gambar 3.3 Database Perpustakaan Kabupaten Daerah Lumajang
Di database ini berisikan data mengenai transaksi peminjaman buku yang dilakukan oleh pengguna Perpustakaan Daerah Kabupaten Lumajang pada tanggal tertentu.
3.3. Metode desain data warehouse (nine step design method)
Dalam perancangan data warehouse pada penelitian ini digunakan metode yang bernama nine step design method yang digagas oleh Kimball.
3.3.1. Memilih Proses Bisnis yang Bersangkutan dengan Kebutuhan
Proses bisnis yang diperoleh dari hasil wawancara bisa menjadi acuan dalam pemilihan dan juga pembatasan kebutuhan sistem. Laporan yang sering kali dibutuhkan adalah laporan peminjaman dan pengembalian buku dengan proses bisnis sebagai berikut.
Proses bisnis peminjaman buku
Gambar 3.4 Proses bisnis peminjaman buku perpustakaan
Proses bisnis pengembalian buku:
Setelah mengetahui kebutuhan sistem, maka database yang digunakan tidaklah semua tapi yang benar-benar berkaitan dengan kebutuhan sistem. Berikut adalah nama tabel database yang dipakai dalam perancangan sistem.
No Database Keterangan
1 Faculty Tabel berisi identitas faculty perpustakaan
yang bersangkutan.
2 Department Tabel berisi identitas department perpustakaan
yang bersangkutan.
3 User_account Tabel berisi identitas anggota perpustakaan.
4 Loan Tabel transaksi yang berisi tanggal
peminjaman dan pengembalian.
5 Library_dataunit Tabel berisi informasi mengenai tanggal buku
didapat dan terletak dibagian apa buku dipajang.
6 Library Tabel berisi informasi mengenai identitas buku
Tabel 3.1 Database yang dipakai
3.3.2. Menentukan Grain Bersumberkan Proses Bisnis
Beberapa data yang menjadi calon tabel fakta untuk proses bisnis dan database operasional, yaitu analisis pada proses transaksi peminjaman dan pengembalian:
1. Perbandingan persentase pengembalian buku tiap tahun.
2. Penunjang data pengadaan buku dari frekuensi tipe-tipe buku yang sering dipinjam.
Analisis yang dihasilkan memiliki kedetilan data yaitu data fakta disimpan per hari, per data unit buku, per anggota perpustakaan.
3.3.3. Mengidentifikasi dan Menyesuaikan Tabel Dimensi dengan yang Lain Beberapa hal yang menjadi acuan penyesuaian dimensi adalah adanya
Pada kasus ini bisa ditemukan bahwa tabel fakta (loan) memiliki foreign key dari tabel dimensi-dimensi yang berelasi dengan tabel fakta. Berikut merupakan
primary key dan foreign key yang berelasi:
Untuk dimensi user_account memiliki primary key bernama userAccount dan terdapat juga foreign key di tabel fakta dengan nama yang sama. Untuk dimensi time_dim terdapat primary key bernama tanggal yang berelasi dengan loanDate di tabel loan. Untuk dimensi lib_dataunit terdapat relasi terhadap attribute bernama libraryMainNumber. Bisa juga dilihat kembali di gambar 3.5 untuk relasi antar dimensi dan fakta. Dengan adanya relasi antar tabel menunjukkan bahwa yang berelasi dengan tabel fakta merupakan tabel dimensi pendukung tabel fakta. 3.3.4. Memilih data-data fakta
Pada proses ini akan ditampilkan record data yang ada pada tabel fakta. Pada umumnya berisikan agregasi dan foreign key dari tabel dimensi. Berikut adalah record tabel fakta.
1. loanID 2. libraryMainNumber 3. userAccount 4. loanDate 5. returnDate 6. returnedDate
3.3.5. Menyimpan Kalkulasi Awal dalam Tabel Fakta.
Pada tahap ini dilakukan penentuan rumus (pre-kalkulasi) dari grain. Biasanya dibuat untuk agregasi di tabel fakta ataupun dilakukan ketika pivot tabel atau chart dibentuk.
1. Perbandingan persentase pengembalian buku yang sesuai dengan tanggal pengembalian dengan yang tidak sesuai setiap tahun dilakukan dengan membandingkan ([COUNT (loanID)] berdasarkan row returnDate) (tanggal pengembalian yang ditentukan oleh perpustakaan) dengan banyaknya peminjaman keseluruhan [COUNT (loanID)] berdasarkan row returnedDate. (returnedDate merupakan tanggal buku dikembalikan oleh peminjam).
2. Penunjang data pengadaan buku ditentukan dari banyaknya peminjaman keseluruhan [COUNT (loanID)] berdasarkan row libraryMaterialType (tipe-tipe buku).
3.3.6. Melihat Kembali Tabel Dimensi
Pada tahap ini akan dijelaskan detail setiap tabel pada database OLAP. Dimensi yang pertama adalah lib_dataunit dengan primary key libraryMainNumber berfungsi sebagai dimensi yang menjelaskan tentang data-data mengenai buku yang ada pada transaksi. Dimensi selanjutnya adalah time_dim dengan primary key bernama tanggal yang berelasi dengan yang menjelaskan tentang waktu transaksi terjadi. Dimensi waktu adalah dimensi penting yang dibuat berdasarkan waktu transaksi terjadi. Dimensi selanjutnya adalah useraccount yang berisikan data tentang anggota perpustakaan yang melakukan transaksi peminjaman buku. Semua dimensi yang dipilih memiliki keterkaitan dan memiliki fungsi untuk menunjang tabel fakta.
Berikut adalah star schema dari database perpustakaan dengan tabel dimensi berupa useraccount, time_dim, dan lib_dataunit dengan tabel fakta berupa loan.
Untuk masalah normalisasi data, di penelitian ini tidak mengalami normalisasi baik di tabel dimensi maupun tabel fakta karena skema yang dipakai adalah star schema. Berbeda jika skema yang dipakai adalah snowflake schema, jika memakai snowflake schema mengharuskan normalisasi pada tabel dimensi namun di tabel fakta tetap dalam keadaan denormalisasi. Star schema tidak dilakukan normalisasi karena memang dibiarkan redundan datanya. Meskipun datanya redundan query yang dipakai tidak terlalu kompleks dan mudah dimengerti. Selain itu juga cocok dengan corak database perpustakaan. Untuk mengatasi data yang redundan, star schema cenderung menghiraukan data yang redundan karena efeknya tidak terlalu besar untuk hasil analisisnya. Dampak negatif dari menggunakan star skema adalah semakin banyak data yang redundan maka semakin besar ukuran databasenya. Jika ingin database yang sedikit lebih ringan, bisa dilakukan normalisasi pada tabel dimensi sehingga mengurangi data yang redundan dan membuat ukuran database tidak membengkak namun memiliki dampak negatif yaitu query yang rumit dan susah dimengerti.
3.3.7. Memilih Durasi Database
Durasi database terhitung dari tahun 2007.
3.3.8. Menelusuri Perubahan-Perubahan yang Terjadi pada Dimensi
Perubahan dari dimensi yang berupa manipulasi data update dari database OLTP-nya akan ikut berubah pada load data selanjutnya. Jika berupa manipulasi data delete maka data OLAP tidak akan berubah pada load selanjutnya. Jika berupa manipulasi data berupa insert maka akan melakukan load data yang baru ke database OLAP.
3.3.9. Memutuskan Prioritas Query dan Tipe Query
Untuk data warehouse, pekerjaan query dan tipe query terjadi pada proses ETL (extract, transform, dan load) menggunakan aplikasi:
a. Talend sebagai aplikasi proses ETL dan pembentukan aplikasi .bat. b. MySQL sebagai pengolahan dan pemrosesan database yang berlangsung. c. Microsoft Excel sebagai tempat keluaran dari hasil OLAP menjadi hasil analisis berbentuk pivot chart.
3.4. Perancangan Sistem Data Warehouse Deskripsi Penelitan
Tools yang dipakai:
a. Talend sebagai aplikasi proses ETL dan pembentukan aplikasi .bat. b. MySQL sebagai pengolahan dan pemrosesan database yang berlangsung. c. Microsoft Excel sebagai tempat keluaran dari hasil OLAP menjadi hasil analisis berbentuk pivot chart.
d. ODBC sebagai konektor antara Microsoft Excel dan MySQL.
Pengimplementasian sistem dilakukan pada tempat penelitian, yaitu Perpustakaan Daerah Kabupaten Lumajang. Hal-hal yang diimplementasikan adalah proses ETL yang dikonversi menjadi sebuah aplikasi .bat yang bisa bekerja secara periodik ke dalam komputer server perpustakaan secara remote. Sesuai dengan yang dibahas di bab sebelumnya, berikut adalah proses pembentukan hingga hasil ETL yang akan diimplementasikan di perpustakaan.
3.4.1. Proses Pembentukan ETL
Proses ETL adalah proses pengintegrasian database-database operasional menjadi satu jenis database dengan tipe data yang sama. Proses ETL terdiri dari extract dimana dilakukan pengambilan data-data dari database operasional. Setelah itu dilakukan proses transform agar database-database operasional terintegrasi menjadi sama dan satu bentuk database yang biasa disebut database OLAP. Setelah itu di load kembali ke database menjadi sebuah database yang terintegrasi. Pada penelitian ini digunakan software bernama talend. Berikut adalah perancangan ETL yang telah dilakukan.
Pertama klik DB Connection lalu klik Create connection,
Gambar 3.8 Pembangunan ETL
Isi kolom Name dan klik next
Gambar 3.9 Pembangunan ETL
Selanjutnya pilih DB Type sesuai dengan software database yang dipakai, pada kasus ini yang dipakai adalah MySQL. Setelah itu klik check dan tunggu hingga muncul notifikasi sebagai berikut.
Gambar 3.11 Pembangunan ETL Gambar 3.10 Pembangunan ETL
Jika koneksi telah berhasil klik OK dan klik Finish. Lakukan hal yang sama untuk menambahkan koneksi OLAP. Setelah itu buat job baru bernama ETL_dim_user_account. Setelah itu tambahkan tMysqlInput pada tabel berikut:
Setelah itu akan muncul gambar sebagai berikut:
Gambar 3.12 Pembangunan ETL
Klik dua kali pada komponen tMysqlInput dan lakukan konfigurasi hingga seperti berikut:
Gambar 3.13 Pembangunan ETL
Pada tahap ini dilakukan input sql dari tabel “user_account”. Untuk tabel “faculty” dan tabel “department” lakukan hal yang sama pada job yang sama hingga terbentuk tiga tMysqlInput dengan konfigurasi tiap-tiap tabel.
Gambar 3.14 Pembangunan ETL
Hubungkan semua tMysqlInput ke tMap. Keterangan tMysqlInput:
tMysqlInput_1: tabel “user_account” tMysqlInput_2: tabel “department” tMysqlInput_3: tabel “faculty”
Pertama hubungkan tabel “user_account” karena tabel “user_account” adalah inti tabel dimensi yang berhubungan langsung dengan tabel fakta dan tabel lain menjadi
lookup row.
Tambahkan komponen tMysqlOutput dan hubungkan terlebih dahulu tmap dengan tMysqlOutput
Setelah selesai menghubungkan, dobel klik pada tMap.
Gambar 3.16 Pembangunan ETL
Hubungkan foreign key “departmentID” di row 1 ke primary key “departmentID” di row 2
Gambar 3.19 Pembangunan ETL
Setelah itu dilakukan penghubungan yang selanjutnya dari foreign key “facultyID” di row2 ke primary key “departmentID” di row 3.
Gambar 3.18 Pembangunan ETL
Lalu tambahkan output
Gambar 3.20 Pembangunan ETL
Setelah selesai, klik ok dan run hingga data OLTP di transfer ke data OLAP. Perlu diketahui bahwa sistem ini adalah sistem yang digunakan secara universal oleh pembuat sistem untuk perpustakaan sekolah, kampus, maupun perpustakaan daerah. Jadi fungsi sebenarnya dari tabel faculty dan department adalah jika sistem digunakan dalam lingkup kampus atau universitas karena isinya untuk membedakan jurusan dan fakultas dari user peminjam, karena sistem digunakan dalam lingkup perpustakaan umum maka nilai dari departmentID dan facultyID adalah 0 atau tidak ada relasi karena tidak ada primary key departmentID dan facultyID yang bernilai 0.
Gambar 3.21 Pembangunan ETL
Untuk dimensi library_dataunit dilakukan hal yang serupa. Kemudian dilanjutkan dengan penambahan dimensi waktu yang harus ada pada OLAP meskipun tidak ada di database OLTP. Pada dimensi waktu yang dibuat pada penelitan ini memiliki logika yaitu setiap adanya peminjaman, maka dimensi waktu akan mencatat tanggal peminjaman yang pernah terjadi. Setelah itu dipecah menjadi bulan, hari, dan tahun untuk mendapatkan data OLAP secara periodik dalam harian, bulanan, maupun tahunan. Berikut gambaran ETL pada dimensi waktu.
Job design
Komponen tMysqlInput_1 pada tabel dimensi time_dim
Gambar 3.23 Pembangunan ETL
Di tMysqlInput_1 yang ada pada job time_dim ini berfungsi untuk mengekstrak data dari database OLTP dengan tabel loan dan atribut yang diekstrak hanya loanDate saja.
Format tMap_2 dan query yang terjadi di dalamnya
Gambar 3.24 Pembangunan ETL
Query yang terjadi di dalamnya adalah pemisahan hari, bulan, dan tahun menjadi atribut tabel tersendiri.
Komponen tMysqlOutput_1 pada tabel dimensi time_dim
Di tMysqlOutput_1 dilakukan load ke database olap dengan nama tabel time_dim dengan batasan aksi yaitu insert or update on duplicate key or unique key yang berarti melakukan penimpaan data pada data yang duplicate.
Setelah terbentuk semua dimensi, dilakukan perancangan dan pembentukan tabel fakta bernama loan. Berikut adalah penjelasan dan gambaran perancangan dan pembentukan tabel loan.
Job Design Tabel Fakta loan
Komponen tMysqlInput_1 (main) Tabel Fakta loan
Gambar 3.26 Pembangunan ETL
Di tMysqlImput_1 (main) ini dilakukan ekstrak semua data dari database OLTP yang bernama loan (calon tabel fakta).
Komponen tMysqlInput_2, tMysqlInput_3, tMysqlInput_5 (lookup) pada Tabel Fakta loan
Pada komponen ini dilakukan ekstrak pada primary key setiap tabel dimensi dari tabel OLAP untuk dijadikan acuan relasi yang terjadi antara tabel fakta dan tabel dimensi.
Komponen tMysqlInput_4 pada Tabel Fakta loan
Pada komponen ini dilakukan ekstrak pada primary key loan (tabel fakta) yang berada pada database OLAP sebagai acuan incremental load data. Incremental load
data adalah sebuah proses load data yang dilakukan tidak secara keseluruhan,
namun hanya melakukan load data yang belum pernah di load sebelumnya. Untuk penjelasan query bisa dilihat pada tMap berikut.
Query tMap pada Tabel Fakta loan
Disini tabel loan akan di join-kan dengan tabel-tabel lookup namun perbedaanya pada row4.
Gambar 3.27 Pembangunan ETL
Pada row 4 (berisikan data primary key yang ada pada tabel loan database OLAP) untuk dijadikan pembatas load data karena memakai metode load incremental load
data. Di join model row 4 diganti dengan inner join dan pada output diubah value
catch lookup inner join reject menjadi true sehingga terbentuk batasan load dimana nantinya load data akan dilakukan pada primary key loan yang belum ada pada OLAP.
Komponen tMysqlOutput_1 pada Tabel Fakta loan
Gambar 3.28 Pembangunan ETL
Di komponen tMysqlOutput_1 dilakukan load data ke tabel loan yang berada pada database OLAP. Disinilah hasil tabel fakta yang telah mengalami proses ETL. 3.4.2. Penampilan dalam Bentuk Pivot Chart.
macam aplikasi, namun pada penelitian ini data mart didapatkan dengan menggunakan aplikasi microsoft excel dengan dibantu dengan aplikasi konektor bernama ODBC. Berikut merupakan cara pembentukan koneksi antara mysql (database) dengan excel.
Lakukan penginstalan ODBC dengan sesuai platform komputer. Setelah penginstalan selesai, buka aplikasi excel dan mulai membuat hubungan antar aplikasi.
Klik data pada kolom menu excel.
Gambar 3.29 Pembangunan pivot tabel dan chart
Setelah itu klik pada from other sources dan pilih from Microsoft query
Gambar 3.30 Pembangunan pivot tabel dan chart
Terbuka menu baru
Pilih new data sources lalu klik OK. Setelah itu akan muncul tampilan baru yang mengharuskan input nama koneksi dan tipe koneksi.
Gambar 3.32 Pembangunan pivot tabel dan chart
Setelah selesai mengisi, klik connect untuk melakukan koneksi dengan database OLAP yang diinginkan
Klik test untuk mengecek keberhasilan koneksi, lalu klik OK.
Setelah selesai mengkoneksikan, masuk ke koneksi yang telah dibuat.
Gambar 3.34 Pembangunan pivot tabel dan chart
Klik OK untuk masuk.
Perlu diingat bahwa di Microsoft Excel, semua query bisa dilakukan dengan aplikasi dari excel itu sendiri bernama microsoft query. Menggunakan microsoft query sendiri memiliki kelemahan tersendiri yaitu untuk menampilkan semua data dari tabel dimensi dan tabel fakta (berbeda tabel) harus digabungkan (join) terlebih dahulu. Namun penggabungan (join) menggunakan Microsoft query membuat komputer berhenti bekerja. Maka dari itu dilakukan join dengan fungsi tabel view pada Mysql terlebih dahulu untuk menghindari penggunaan microsoft query. Dari keterbatasan excel ini dibuatlah tabel view di mysql dengan query sebagai berikut:
Create View ini sendiri berfungsi untuk menampilkan tabel yang telah dilakukan proses join untuk bisa ditampilkan ke dalam Microsoft excel tanpa melalui Microsoft query.
Setelah terbentuk create view buka lagi excel dan load semua data yang ada pada tabel view. Setelah load yang dilakukan selesai, mulailah query dalam pembuatan data mart. Sesuai dengan grain dan pre-kalkulasi pada nine design method
CREATE VIEW Hasil_olap_inner AS SELECT lib_dataunit.*, time_dim.*, useraccount.*, loan.loanID, loan.loanDate, loan.returnDate, loan.returnedDate, loan.extendedCount, loan.loanType FROM loan INNER JOIN lib_dataunit ON loan.libraryMainNumber = lib_dataunit.libraryMainNumber INNER JOIN time_dim ON loan.loanDate = time_dim.tanggal INNER JOIN useraccount ON loan.userAccount = useraccount.userAccount
sebelumnya, query bisa dilakukan dengan melakukan drag and drop pada pivottable fields yang ada pada excel.
Persentase Pengembalian Tiap Tahun.
Gambar 3.35 Pembangunan pivot tabel dan chart
Perbandingan persentase pengembalian buku yang sesuai dengan tanggal pengembalian dengan yang tidak sesuai setiap tahun.
Drag and drop loanID di field Values dan returnedDate di field Rows dan juga tambahkan returnDate di field rows pada pivottable fields yang berbeda untuk melihat perbandingannya.
Penunjang data pengadaan buku.
Gambar 3.37 Pembangunan pivot tabel dan chart
Drag and drop loanID di field Values dan libraryMaterialType di field Rows. Setelah ketiga grain sudah terbuat pivot tabel dan chart, maka data mart akan terbentuk.