ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Penerapan Extraction-Transformation-Loading
(ETL) Dalam Data Warehouse
(Studi Kasus : Departemen Pertanian)
Rahmadi Wijaya
Prodi D3 Teknik Informatika, Fakultas Ilmu
Terapan
Universitas Telkom
Email : rakit2272@yahoo.com
ABSTRAK
Proses Extraction-Transformation-Loading
(ETL) pada pembangunan data warehouse
berperan melakukan ekstraksi data dari
berbagai sumber, pengubahan data ke
bentuk yang sesuai dengan kebutuhan dan
pengisian ke storage data warehouse.
Termasuk di dalam fungsi ETL terdapat
proses data cleansing yang menangani
redundansi, inkonsistensi dan integritas
data. Proses ETL akan mengisikan data
dari sumber ke integration layer yang
merupakan tempat data dari data
warehouse tergabung dan terintegrasi. Dari
integration layer, data dapat
dikelompokkan dengan lingkup yang lebih
kecil dan sesuai kebutuhan dalam
repository lain yang disebut data mart.
Program reporting dari data warehouse
akan berhubungan dengan data mart
sebagai sumber datanya.
Penelitian ini merupakan bagian dari
Penelitian berbasis profesi pembangunan
data warehouse. Secara khusus Penelitian
menangani proses ETL. Pada Penelitian ini
dibangun metadata bagi proses ETL yang
menyimpan definisi data sumber, data
arget (data warehouse), dePenelitian
keterhubungan antara data sumber dan
data target, serta dePenelitian transformasi
data dari data sumber ke data target.
Dibangun juga program ETL dengan
teknologi DTS pada SQL Server 2000 yang
menggunakan metadata tersebut.
Diharapkan dengan adanya metadata bagi
proses ETL dapat dibangun program ETL
yang memiliki tingkat reusability tinggi.
Volume 5, Nomor 2, Juli 2016
Bambang Pudjoatmodjo
Prodi D3 Teknik Informatika, Fakultas Ilmu
Terapan
Universitas Telkom
Email : b.pudjoatmodjo@gmail.com
Kesimpulan utama yang dapat diambil dari
Penelitian ini adalah penggunaan proses
ETL yang dinamis (menggunakan
metadata ETL) sangat diperlukan apabila
berhubungan dengan sistem operasional
yang masih labil dan berkemungkinan
besar mengalami perubahan skema basis
data. Proses ETL dinamis juga diperlukan
untuk menangani kebutuhan pengguna
akan laporan yang bertambah.
Kata Kunci : Data Warehouse, ETL,
Integration Layer, Reusability, Metadata
1. Pendahuluan
Kunci sukses bagi sebuah
perusahaan untuk bertahan pada masa
sekarang adalah kemampuan untuk
menganalisa, merencanakan dan bereaksi
terhadap perubahan lingkungan bisnis
secara cepat dan akurat. Kemampuan ini
hanya dapat dipenuhi dengan tersediannya
informasi yang memadai bagi para
manajer, direktur dan para pengambilan
keputusan lainnya. Informasi yang
dibutuhkan tersebut seringkali adalah
berupa data operasional dan sulit untuk
didapatkan. Walaupun tersedia akses ke
data tersebut, seringkali format dan struktur
data yang ada tidak seperti yang
diinginkan. Teknologi Data warehouse
adalah sebuah konsep dan perangkat yang
memungkinkan penyediaan akses ke
seluruh level informasi perusahaan. Data
warehouse memungkinkan suatu
organisasi untuk mengumpulkan data dari
berbagai format dan standar yang berbeda,
melakukan analisa atas data tersebut, dan
mengeluarkan report-report yang
61

Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
dibutuhkan bagi para analis dan
pengambilan keputusan.
Data warehouse memiliki fungsi
ETL (extraction, transformation, loadingI)
yang berperan dalam pengisian data untuk
kebutuhan analisis dengan melakukan
ekstraksi dari berbagai sumber data,
pengubahan data ke bentuk yang sesuai
dan pengisian ke storage data warehouse.
Termasuk di dalam fungsi ETL terdapat
proses data cleansing yang menangani
redundansi, inkonsistensi dan integritas
data. Proses ETL akan mengisikan data
dari sumber ke integration layer yang
merupakan tempat data dari data
warehouse tergabung dan terintegrasi. Dari
integration layer, data dapat
dikelompokkan dengan lingkup yang lebih
kecil dan sesuai kebutuhan dalam
repository lain yang disebut data mart.
Program reporting dari data warehouse
akan berhubungan dengan data mart
sebagai sumber datanya.
Kondisi Departemen Pertanian
pada saat ini dalam melakukan analisis
dan pengolahan data sebagai berikut :
1. Setiap sistem informasi memiliki
basis data masing-masing yang
berbeda-beda bahkan masih ada
yang dalam bentuk flat file (.xls).
2. Data tersebar di setiap sistem
informasi dan ada data yang
mengalami redundansi.
3. Dalam analisis dan pengambilan
keputusan, pihak eksekutif
Departemen Pertanian harus
melakukan rekap ulang dari data
setiap sistem informasi.
Dalam meningkatkan kinerja
departemen, para eksekutif Departemen
Pertanian perlu dibekali dengan data yang
akurat dan terkini unuk menghasilkan
keputusan-keputusan strategis. Tulisan
dalam Penelitian ini akan mengangkat
tentang studi kasus perencanaan data
warehouse pada Departemen Pertanian.
Pembahasan akan difokuskan pada siklus
pengembangan data warehouse, desain
ISSN 2087-2658
Volume 5, Nomor 2, Juli 2016
dan arsitektur data warehouse, khususnya
yang berkaitan dengan informasi basis
data statistik Pertanian dan Basis data
Ekspor Impor pada Departemen Pertanian.
Dengan menggunakan data
warehouse, diharapkan pihak eksekutif
Departemen Pertanian dapat mengakses
data yang mereka butuhkan tanpa harus
bergantung pada laporan yang diberikan
oleh masing-masing bagian. Selain
mempercepat akses data, data warehouse
dikembangkan ini juga diharapkan dapat
menyelesaikan masalah redundansi dan
inkonsistensi.
1. Data Warehouse
1.1. Arsitektur Data warehouse
Data warehouse adalah suatu
sistem dengan arsitektur yang bersifat
terbuka, jadi untuk membangun suatu
arsitektur Data warehouse sangat
tergantung pada kebutuhan sistem (system
requirements). Gambar 2.1 menunjukkan
salah satu contoh dari arsitektur Data
warehouse. Arsitektur tersebut
menunjukkan perbedaan penggunaan Data
warehouse dibandingkan dengan basis
data operasional. Data dalam Data
warehouse digunakan untuk keperluan
spesifik, umumnya berupa analisis oleh
aplikasi-aplikasi dalam Executive
Information System (EIS) atau Decision
Support System (DSS). Sedangkan basis
data operasional umumnya digunakan oleh
aplikasi-aplikasi transaksional yang mampu
melakukan read/write terhadap basis data
tersebut.
Arsitektur data warehouse dibangun
berdasar kebutuhan tertentu, hal ini dapat
kita lihat dari hal berikut :
1. Data input bagi Data warehouse
tidak lagi hanya berasal dari
sistem internal (sumber
operasional pada umumnya),
melainkan dirancang untuk dapat
mengakomodasi sumber
eksternal (data dari luar sistem
operasional), misalnya :
 Data dari bursa efek,
62
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

 Data dari internet (dengan berbeda. Untuk dapat digunakan,

teknologi web farming), data tersebut harus mengalami
 Data dari sistem mobile konversi menjadi format yang
(misalnya phone cell). dimengerti oleh pengguna.
4. Menyediakan mekanisme bagi
2. Informasi yang tersimpan dalam pengguna agar dapat mengakses
Data warehouse dapat data warehouse.
dispesialisasikan lagi menjadi Pengguna data warehouse bisa
beberapa Data warehouse yang saja membutuhkan sudut pandang
lebih khusus (Data Mart) sehingga baru yang lebih kompleks untuk
dalam arsitektur terdapat proses mendukung perubahan analisis
tambahan untuk mempopulasikan perusahaan. Untuk itu, data
data dari Data warehouse ke warehouse harus memiliki
dalam beberapa Data Mart. mekanisme fleksibel yang dapat
3. Aplikasi yang berada pada layer memenuhi perubahan kebutuhan
pengguna berkembang menjadi pengguna akan akses terhadap
beberapa model misalnya : basis data.
berbasis web, berbasiskan
desktop, ataupun berbasiskan 1.2. Akses Pengguna
sistem mobile. Akses pengguna merupakan
komponen yang mendefinisikan bagaimana
Data warehouse mengumpulkan pengguna dapat melakukan akses pada
beberapa data mentah dari sistem Data warehouse. Pada umumnya untuk
operasional, dan mungkin terdapat juga melakukan akses terhadap Data
data eksternal lainya, kemudian melakukan warehouse, pengguna menggunakan
operasi terhadap data tersebut aplikasi/perangkat lunak untuk
(membersihkan, mengintegrasikan, dan mendefinisikan query dan analisis.
menyimpan data), dan akhirnya Perangkat lunak tersebut disebut sebagai
mendistribusikan hasilnya ke pengguna. Business Inteligence Software. Sebagai
Beberapa kriteria dalam mendesain contoh dari Business Inteligence Software
arsitektur data warehouse adalah sebagai adalah :
berikut [COR01] : 1. Sistem Pendukung Keputusan
1. Melakukan ekstraksi data dari (Decision Support System)
bermacam sumber. memungkinkan untuk melakukan ad
Data warehouse biasanya hoc query dan membangun report
melibatkan lebih dari satu data sumber. yang dapat digunakan untuk
2. Mengintegrasikan data ke tempat mendukung pengambilan
yang umum. keputusan.
Setelah data diekstrak dari 2. Sistem Informasi Eksekutif
beberapa sumber, data tersebut (Executive Information Systems)
tidak bisa begitu saja dimasukkan merupakan kombinasi antara
ke data warehouse. Data tersebut Decision Suport System/DSS
biasanya perlu dibersihkan dan dengan kemampuan untuk
dilakukan pengecekan terhadap melakukan analisis dan akses
keterhubungan antar data untuk terhadap sumber eksternal (misal
kemudian diintegrasikan ke basis layanan informasi saham dari Dow
data yang sama. Jones).
3. Menyimpan data dalam format yang 3. OLAP (Online Analytical
dapat digunakan pengguna. Processing) memungkinkan
Data dari berbagai sumber, yang melakukan analisis terhadap data
sebenarnya mewakili data sejenis, operasional sehingga bisa
mungkin mempunyai format yang menentukan trend

63

Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
bisnis,pendeteksian kesalahan
terhadap proses bisnis, dan
sebagainya.
4. Data Mining Tools memungkinkan
melakukan otomasi analisis
terhadap data untuk menemukan
pola-pola tertentu yang dapat
digunakan untuk melakukan
penyesuaian di dalam proses
bisnis.
2. ETL (Extraction, Transformation,
Loading)
Di dalam proses ETL, data dari
berbagai sumber secara periodik akan
diekstrak dan diintegrasikan ke dalam data
warehoue [ONE97]. Extraction merupakan
proses untuk mengidentifikasi seluruh
sumber data yang relevan dan mengambil
data dari sumber-sumber tersebut.
Transformation adalah proses yang
mempunyai peran dalam melakukan
pembersihan data dan integrasi skema
yang berbeda-beda ke dalam skema yang
terdefinisi dalam data warehouse. Loading
adalah proses pemindahan data secara
fisik dari system operasional ke dalam data
warehouse.
2.1. Konsep ETL
Pendefinisian lingkup ETL dengan
cara menganalisis tiap target tabel (dimensi
dan fakta) perlu dilakukan pada awal
pembangunan arsitektur proses ETL.
Untuk tiap tabel target, perlu diambil
informasi tentang kelakuannya, dimanakah
data sumbernya dan proses bisnis apa saja
yang bergantung kepadanya.
2.1.1. Metadata
Pada awal perkembangan data
warehouse, proses integrasi direalisasikan
dengan membuat program ETL spesifik
untuk struktur basis data sumber dan basis
data data warehouse.
Kemudian, ditemukan bahwa
program-program ETL spesifik tadi pada
intinya melakukan proses yang seragam.
Banyak blok-blok program yang bisa
dipergunakan kembali untuk proses ETL
lainnya. Pada titik itulah dikembangkan
ISSN 2087-2658
Volume 5, Nomor 2, Juli 2016
teknologi ETL tools yang dapat melakukan
otomasi proses integrasi data ke data
warehouse.
Secara singkat, metadata adalah
data tentang data. Khususnya, metadata
ETL adalah data tentang proses ETL.
Pendefinisian metadata ETL diperlukan
dalam rangka membangun program ETL
yang mempunyai tingkat reusability tinggi.
2.1.2. Extraction
Proses ektraksi mengidentifikasi
seluruh sumber data yang relevan dan
seefisien mungkin mengambil data
tersebut. Program ekstraksi berjalan
melalui file atau basis data, menggunakan
berbagai kriteria dalam memilih data, dan
menemukan data yang sesuai, kemudian
mentransportasikan data ke file atau basis
data lainnya.
Change data capture (CDC) adalah
elemen penting dalam analisis ekstraksi.
Transaksi yang dijadikan data fakta hampir
selalu mempunyai timestamps. Tetapi, data
dimensi pada system sumber tidak selalu
mempunyai timestamps karena
kecenderungannya yang tidak bergantung
pada suatu event. Oleh sebab itu, CDC
paling sulit diimplementasikan dengan data
dimensi.
Ada beberapa cara
mengimplementasikan CDC. Jika pada
basis data sumber atau file terdapat
timestamps, implementasi akan jauh lebih
mudah. Bila tidak, CDC bisa
diimplementasikan dengan membaca log
file dari basis data sumber atau
mengimplementasikan trigger pada basis
data sumber. Pengimplementasian seperti
ini sangat riskan karena terlalu bergantung
kepada teknologi yang dimiliki basis data
sumber. Implementasi seperti ini tidak akan
berlaku jika data sumber berupa file.
Beberapa cara dalam mengenali
perubahan pada basis data sumber :
1. Timestamp
Ekstraksi pada sistem yang
menyimpan timestamp terhadap
waktu insert dan update record,
membuat CDC tidak perlu
melakukan pencarian ke seluruh isi
64
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

tabel untuk mengenali record apa Agregasi akan menghasilkan data

saja yang telah berubah. dengan tingkat detail tertentu.
2. Trigger 6. Conditional Branch
Trigger diimplementasikan pada Mirip dengan conditional
tabel sumber. Setiap record yang assignment tetapi fungsi
disimpan, diubah ataupun dihapus, kondisional pada conditional branch
trigger akan menuliskan pesan ke lebih rumit dengan tingkat
log file. Log file inilah yang akan kondisional yang bertingkat. Perlu
dijadikan informasi bagi data lebih dari sekedar tabel lookup
warehouse untuk meng-update untuk mengimplementasikannya.
datanya. Pada rakteknya, 7. Referential Integrity
implementasi trigger jarang Transformasi harus menjaga
dilakukan, karena membutuhkan integritas dari data warehouse,
modifikasi terhadap sistem sumber bahkan walaupun bersumber dari
yang berkemungkinan menurunkan data tidak valid yang tidak terjaga
performasi dari sistem sumber. integritasnya.
3. File Compare 8. Surrogate Key Resolution
Pembandingan dilakukan antara Surrogatye key memberikan
data yang terdapat pada sistem fleksibilitas tinggi dalam menangani
sumber sekarang dengan data data pada data warehouse
terakhir yang dimiliki oleh data dibandingkan penggunaan key
warehouse. Teknik ini kurang bawaan data sumber.
akurat dibandingkan teknik-teknik 9. User Written
sebelumnya, karena teknik ini Pengguna bisa mendefinisikan
menggunakan metode fungsi-fungsi tersendiri yang
pembandingan periodik snapshots. merupakan gabungan dari fungsi
aritmatik dan fungsi kondisional
2.1.3. Transformation sesuai dengan proses bisnis
Transformation adalah proses perusahaan.
manipulasi terhadap data dari sistem
sumber ke format lain pada data 2.1.4. Loading
warehouse atau data mart dalam rangka Proses loading akan memindahkan
menjadikannya sebuah informasi yang data yang telah ditransformasi ke data
bermakna. Fungsi-fungsi transformasi yang warehouse. Strategi loading ke integration
mungkin dilakukan adalah: [COR01] layer dibagi menjadi dua bagian, yaitu
1. Konversi Format strategi loading bagi table dimensi dan
Data harus dikonversi menjadi strategi loading bagi tabel fakta [COR01].
format yang umum.
2. Manipulasi string A. Strategi Loading Tabel
Meliputi konkatenasi, trim, up case, Dimensi
lower case dan sebagainya.
3. Fungsi aritmatik Ada tiga strategi loading tabel
Proses aritmatik bisa dibuat dalam dimensi. Setiap strategi menangani
modul terpisah ataupun perubahan data dimensi secara berbeda
menggunakan fungsi aritmatik yang bergantung kepada cara penanganan
dimiliki oleh SQL. terhadap data dimensi lama. Pada ketiga
4. Conditional Assignment strategi tersebut, jika tidak ditemukan
Biasanya diimplementasikan sebuah record dengan natural key yang
menggunakan tabel lookup yang sama, maka record baru akan
menyimpan nilai lama dari data dan ditambahkan. Natural key adalah atribut
mendefinisikan nilai barunya. pada dimensi yang secara unik
5. Agregasi membedakan record dimensi (bukan

65

Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
surrogate key). Jika ditemukan record
dengan natural key yang sama, maka :
Strategi 1 :
Sejarah data tidak disimpan pada strategi
1. Jika nilai input telah ada di tabel dimensi
berdasarkan nilai natural key, maka record
tersebut akan diperbaharui.
Strategi 2 :
Critical column adalah kolom-kolom
penting pada tabel dimensi yang tetap
dijaga keberadaannya. Jika pada input
ditemukan satu atau lebih kolom yang
termasuk critical column dan nilai pada
input berbeda dengan nilai pada kolom
bersesuaian pada tabel dimensi (dan tetap
berdasarkan nilai natural key), maka record
yang bersesuaian tadi akan expired dan
record baru dengan surrogate key yang
baru akan dimasukkan. Jika tidak
ditemukan kesamaan nilai pada critical
column, maka seperti pada strategi 1,
record yang bersesuaian akan
diperbaharui.
Strategi 3 :
Hampir mirip dengan strategi 2 yang
melakukan penanganan terhadap
perubahan nilai pada critical column.
Bedanya, pada strategi 3 untuk tiap critical
column, beberapa kolom yang berbeda
ditempatkan pada tiap record untuk
menyimpan nilai data sekarang dengan n
nilai data sebelumnya. Ketika terjadi
perubahan nilai pada critical column,
semua nilai akan digeser, dan nilai terakhir
(nilai paling lama) akan dihapus, kemudian
nilai terbaru dimasukkan.
1. Ilustrasi Kasus
ESS diimplementasikan pada
Departemen Pertanian yang memiliki
banyak bagian yang bergerak di berbagai
bidang. Penggunaan EIS yang
memanfaatkan data warehouse bertujuan
untuk mengintegrasikan data dari berbagai
sumber basis data yang tersebar di bagian
produksi untuk meningkatkan efesiensi dan
efektifitas pengambilan keputusan oleh
pihak eksekutif.
ISSN 2087-2658
Volume 5, Nomor 2, Juli 2016
Pada Departemen Pertanian, tidak
terdapat basis data terintegrasi antar
bagian. Basis data dikelola secara lokal
dan terpisah untuk bagian, dengan
masing–masing bagian menerapkan format
data yang tidak seragam. Hal ini akan
mempersulit pihak eksekutif, yaitu pihak
yang menduduki jabatan di pusat, dalam
hal pengambilan keputusan yang sifatnya
global. Data yang tersebar ini akan
menyulitkan pihak eksekutif dalam
melakukan analisis untuk mengekstrak
data menjadi informasi yang diperlukan.
Selain itu, basis data umumnya
digunakan untuk menyimpan data yang
terperinci. Hal ini kurang sesuai dengan
kebutuhan data yang datang dari pihak
eksekutif. Pihak eksekutif umumnya
menginginkan data yang berupa
rangkuman, dan dalam bentuk tampilan
grafis berupa diagram untuk memudahkan
dalam pengambilan keputusan.
Adapun permasalahan yang mungkin
dihadapi dalam mengimplementasikan EIS
pada Departemen Pertanian, berkaitan
dengan banyaknya bagian yang dimiliki
adalah :
1. Antara satu basis data dengan
basis data lainnya ada
kemungkinan terdapat
inkompatibilitas data, hal ini
disebabkan oleh tidak
diterapkannya format standar untuk
data.
2. Mengekstrak informasi. Dari
berbagai data yang tersimpan pada
data warehouse, sebuah EIS
dituntut untuk dapat mengekstrak
data mentah dari berbagai sumber
yang tersedia, untuk kemudian
menghasilkan informasi yang
berguna untuk pihak eksekutif,
biasanya untuk memprediksi trend
untuk lima tahun ke depan.
Untuk mengekstraksi informasi,
perlu ditentukan format request
informasi kemudian dicocokkan
dengan data yang terdapat pada
data warehouse. Sebagai ilustrasi,
misalkan informasi yang diminta
adalah berupa informasi umum dari
seluruh bagian yang dipegangnya.
66

Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Misalkan format data yang telah
ditentukan untuk request informasi
tersebut adalah berupa : jumlah
pengeluaran pada bulan tersebut,
segmentasi customer, biaya
operasional per bulan, serta alokasi
biaya resiko.
3. Menjaga akurasi data. Dalam hal
ini, timbul masalah bagaimana
memastikan data yang diakses oleh
pengguna EIS adalah data yang
diinginkan.
4. Menentukan selang waktu yang
tepat untuk memproduksi dan
menyimpan data ke dalam data
warehouse. Misalkan menentukan
frekuensi pengumpulan data dari
seluruh bagian, apakah satu bulan,
dua bulan, atau selang waktu yang
lain.
Menentukan batas waktu untuk
menyimpan data. Mengingat jumlah
data yang tersimpan bisa mencapai
jumlah yang sangat banyak, oleh
karena itu perlu ditentukan batas
waktu penyimpanan data. Agar
menghemat kapasitas memori dan
meningkatkan performansi EIS dari
segi kecepatan.
2. Analisis
Pada bagian analisis akan dibahas
mengenai batasan masalah dalam
pembangunan proses ETL, skema
integration layer yang digunakan, proses
ETL yang dipilih, analisis kebutuhan
metadata, analisis pembangunan proses
ETL dinamis dan teknologi yang berkaitan
dengan pembangunan proses ETL
dinamis.
Pada analisis ini juga akan
menganalisis konsep-konsep umum dalam
proses ETL. Proses ETL yang dimaksud
adalah proses ETL antara data sumber dan
integration layer. Proses ETL akan
dibangun di atas basis data sumber dan
data warehouse yang menggunakan
skema relasional. Proses ETL dinamis dan
metadata nya yang akan dibangun terbatas
terhadap pemenuhan kebutuhan kasus
pembangunan data warehouse
Departemen Pertanian.
ISSN 2087-2658
Volume 5, Nomor 2, Juli 2016
1.1. Analisis Skema Integration
Layer
Skema integration layer yang
dibangun akan memenuhi prinsip integritas
dan mengabaikan kecepatan respon
terhadap query dari pengguna. Nantinya
pengguna tidak akan melakukan query
secara langsung ke integration layer
melainkan ke data mart. Untuk memenuhi
kebutuhan di atas, skema integration layer
yang dibangun memenuhi prinsip
normalisasi.
Tabel-tabel pada integration layer
dibagi menjadi dua macam:
- Tabel Dimensi
Tabel dimensi lebih jarang mengalami
perubahan dibandingkan dengan tabel
fakta. Ekstraksi tabel dimensi melibatkan
pengecekan terhadap data dimensi yang
telah ada. Apabila data dimensi telah ada
sebelumnya, tidak akan dilakukan
penambahan ke basis data. Secara berkala
akan dilakukan pengecekan kevalidan data
dimensi pada basis data data warehouse
dengan data sumber. Apabila data yang
berhubungan sudah tidak ada di data
sumber, maka data pada data warehouse
akan expired. Pada data sumber, data
dimensi tidak berhubungan dengan event
tertentu. Jika data dimensi masih valid,
maka data dimensi masih terdapat pada
data sumber.
- Tabel Fakta
Tabel fakta akan terikat pada event tertentu
di basis data sumber. Sehingga pada
setiap record pada tabel fakta akan
berhubungan dimensi waktu. Ekstraksi
tabel fakta berasumsi data yang telah
diekstrak tidak akan berubah lagi nilainya
pada basis data sumber. Untuk itu,
ekstraksi tabel fakta akan dilakukan jika
tabel fakta sumber sudah tidak mungkin
dirubah lagi, sehingga data fakta pada data
warehouse dapat terjamin kevalidannya.
Tabel fakta akan diekstraksi pada tabel
sumber yang sifatnya transaksional dan
67
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

relatif cepat mengalami perubahan perubahan sistem sumber dapat

(penambahan). dideterminasi dengan tingkat presisi waktu
tinggi. Pengaplikasian metode ini
6.2. Analisis Proses ETL membutuhkan tambahan storage untuk
A. Extraction menyimpan log file. Dengan trigger, proses
Penentuan pendekatan yang ekstraksi akan lebih efisien dalam
digunakan pada ekstraksi sangat terkait melakukan pencarian record mana yang
dengan analisis bisnis proses, harus diekstrak. Pengaplikasian metode ini
pendefinisian area subjek, serta desain akan menurunkan performansi sistem
logik/fisik data warehouse. Berdasarkan sumber, sebab setiap kali transaksi terjadi
tiga metode mengenali data mana yang akan ada proses tambahan pada sistem
harus diekstrak yaitu timestamp, trigger, sumber yaitu proses penulisan ke dalam
dan file compare akan ditentukan metode log file.
mana yang akan diaplikasikan pada Metode file compare (atau bisa
pembangunan ETL dinamis. disebut record compare) tidak bergantung
Metode-metode pengenalan terhadap kondisi sistem sumber. Dengan
perubahan pada tabel sumber ini, hanya metode ini, detail dari perubahan data
dilakukan terhadap tabel-tabel dimensi. sumber tidak dapat dideterminasi karena
Seperti yang telah disebutkan sebelumnya, sifatnya yang melakukan perbandingan
ekstraksi tabel-tabel fakta dilakukan periodik snapshots. Metode ini tidak
dengan asumsi telah dideterminasi membutuhkan penambahan storage pada
sebelumnya record-record mana yang sistem sumber. Proses file compare
harus diekstrak. merupakan proses rumit yang
Metode timestamp sangat membutuhkan banyak sumber daya dalam
bergantung terhadap kondisi sistem melakukan ekstraksi. Tetapi
sumber. Metode ini bisa diterapkan jika pengaplikasiannya tidak berpengaruh
pada sistem sumber yang melakukan terhadap performansi sistem sumber.
pencatatan waktu terhadap pemasukan Matriks perbandingan tiga metode di atas
dan perubahan record. Akan lebih mudah dapat dilihat pada tabel 3.1
lagi jika penghapusan record tidak benar-
benar menghapus record dari basis data, Tabel 3.1 Perbandingan Metode Ekstraksi
tetapi hanya memberikan flag “terhapus” No. Aspek Timest Trigger File
pada record. Pendukung amp Compare
Dengan metode ini setiap detail 1 Ketergantung Bergant Bergant Tidak
perubahan sistem sumber dapat an ung ung Bergantung
dideterminasi dengan tingkat presisi waktu terhadap
tinggi. Pengaplikasian metode ini sistem
menambah jumlah atribut pada tiap tabel sumber
sebanyak minimal dua atribut, yaitu 2 Akurasi data Akurat Akurat Kurang
timestamp insert dan flag valid data. terekstrak akurat
Dengan timestamp, proses ekstraksi akan 3 Penambahan Butuh Butuh Tidak Butuh
lebih efisien dalam melakukan pencarian storage
record mana yang harus diekstrak. Secara sistem
umum, pengaplikasian metode ini tidak Sumber
terlalu berpengaruh terhadap performansi 4 Efisiensi Efisien Efisien Kurang
sistem sumber. proses Efisien
Sama seperti metode timestamp, 5 Pengaruh Kecil Besar Tidak
metode trigger juga sangat bergantung terhadap Berpengaru
terhadap kondisi sistem sumber. Metode ini performansi h
bisa diterapkan hanya terhadap sistem sistem
sumber yang mendukung teknologi trigger. sumber
Dengan metode ini, setiap detail

68
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

Berdasarkan matriks perbandingan dimensi yang mungkin memiliki nilai natural

metode ekstraksi, maka dipilih file compare key yang sama dalam kurun waktu valid
sebagai metode ekstraksi proses ETL yang berbeda.
dinamis yang akan dibangun. Alasan
utamanya adalah metode file compare 1.4. Loading
tidak bergantung terhadap sistem sumber Berikut ini akan dibahas strategi
sedangkan pada kasus pembangunan data loading bagi tabel dimensi dan tabel fakta.
warehouse Departemen Pertanian, tidak Seperti telah disebutkan sebelumnya, ada
dimungkinkan mekanisme perubahan tiga strategi loading tabel dimensi yaitu :
sistem sumber.
(1) Melakukan update terhadap record
1.3. Transformation bersesuaian.
Berdasarkan kebutuhan pada (2) Mengimplementasikan critical column
pembangunan data warehouse dengan penambahan record.
Departemen Pertanian maka fungsi-fungsi (3) Mengimplementasikan critical column
transformasi yang dipilih untuk dengan penambahan sejarah isi pada
diimplementasikan adalah konversi format, record yang sama.
manipulasi string, fungsi aritmatik,
conditional assignment, referential integrity Strategi pertama memiliki
dan surrogate key resolution. kelemahan dalam nilai keakuratan data.
Format masukan data yang Sebab, bisa ditemukan suatu data dimensi
didukung oleh proses ETL dinamis adalah dengan nilai natural key yang sama tetapi
string, number dan date. String dan date mengacu pada informasi yang berbeda
akan disimpan pada integration layer pada jangka waktu yang berbeda. Di lain
sebagai string. Sedangkan number tetap pihak, strategi pertama membutuhkan
akan disimpan sebagai number. storage yang paling sedikit diantara strategi
Manipulasi string yang dilakukan yang lain.
adalah operasi string sederhana, yaitu up Strategi dua memiliki keakuratan
case dan lower case yang penyimpanan nilai paling tinggi di antara
diimplementasikan pada query strategi lainnya. Data dimensi dengan nilai
pengambilan data sumber. natural key yang sama dan jangka waktu
Fungsi aritmatik yang digunakan keberlakuan yang berbeda, tetap dapat
terbatas pada operasi aritmatik sederhana disimpan dengan resolusi surrogate key.
yaitu sum untuk penjumlahan, count untuk Data dari tabel fakta tetap dapat akurat
penghitungan jumlah record dan avg untuk mengacu ke data dimensi yang
menghitung nilai rata-rata data sumber. seharusnya. Di lain pihak, strategi kedua ini
Conditional assignment akan membutuhkan storage yang paling banyak
diimplementasikan menggunakan tabel diantara strategi yang lain.
transformasi yang menyimpan nilai data Strategi tiga selain sulit diterapkan
sumber beserta nilai transformasinya. (tidak ada query yang mampu melakukan
Fungsi conditional assignment ini tidak pergeseran nilai antar atributnya) juga
memikirkan aspek waktu, sehingga kondisi kurang memiliki nilai keakuratan.
transformasi nilai akan valid pada saat Penyimpanan sejarah nilai atribut tidak
proses ETL dilakukan saja. akan banyak berharga tanpa penyimpanan
Referential integrity dijaga dengan nilai waktu keberlakuannya.
asumsi data sumber telah terjaga Untuk menjamin keakuratan data
integritasnya, sehingga proses ETL hanya maka strategi dua akan dipilih sebagai
melakukan ekstraksi terhadap referential metode loading pada proses ETL dinamis
integrity yang telah didefinisikan pada data yang akan dibangun. Pada proses ETL
sumber. yang dibangun, tidak akan disimpan nilai-
Surrogate key diterapkan dengan nilai critical column untuk tiap tabel
tujuan sebagai pembeda bagi nilai data dimensi, sehingga tiap-tiap kolom pada

69
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

tabel dimensi akan dianggap sebagai 6 Pembedaan Analisis sumber.

critical column. jenis tabel
Seperti yang sudah dijelaskan (table dimensi
sebelumnya, proses loading ke tabel fakta atau fakta)
akan dilakukan tanpa memperhatikan data 7 Data lineage Proses ETL
sejarah di tabel fakta. Loading ke tabel (dePenelitian
fakta akan berasumsi data yang akan tentang semua
dimasukkan belum pernah dimasukkan transformasi
sebelumnya ke tabel fakta. yang terjadi
pada data
1.5. Analisis Metadata Proses ETL sumber untuk
Dinamis mendapatkan
Informasi metadata yang dipilih domain
akan sangat berpengaruh terhadap proses sumber)
ETL dinamis yang akan dibangun. Tabel 8 Statistik ETL Proses ETL
3.2 memperlihatkan jenis-jenis metadata (seperti, Waktu
apa saja yang dibutuhkan untuk terakhir proses
membangun sebuah proses ETL dinamis. ETL, jumlah
record ter-load,
Tabel 3.2 Jenis Metadata Proses ETL jumlah error,
No. Item Metadata Didapatkan dari dan lain-lain)
Proses 1.6. Analisis Pembangunan
1 Definisi data Analisis sumber. Proses ETL Dinamis
sumber Skema basis data Pembangunan proses ETL dinamis
sumber ataupun akan terbatas terhadap pemenuhan
definisi dari File kebutuhan pembangunan data warehouse
sumber. Departemen Pertanian. Proses ini harus
2 Definisi data Proses pemodelan. mampu independen terhadap skema data
target Pemodelan skema sumber, skema integration layer, bisnis
basis data pada proses antara data pada data sumber dan
data warehouse integration layer dan proses transformasi
ataupun data mart yang didefinisikan pada bisnis proses.
yang mendukung Pendefinisian skema data sumber
kebutuhan analisis. hanya akan diimplementasikan berupa
3 DePenelitian Analisis sumber, definisi query pengaksesan datanya. Untuk
bisnis antara proses pemodelan, tiap-tiap atribut pada data sumber harus
data pada atau proses ETL. dilakukan rename agar sesuai dengan nilai
sumber dan Jika data tidak atribut yang bersesuaian pada basis data
target tersedia pada integration layer. Skema integration layer
skema sumber akan didefinisikan dalam skema basis data
ataupun tool relasional.
pemodelan, data Pada skema table integration layer
harus didefinisikan akan dibedakan antara tabel dimensi dan
secara manual tabel fakta. Bisnis proses antara data
pada ETL tool. sumber dan integration layer akan
4 Metoda dan Definisi didefinikan dalam relasi one-to-one antara
pengelolaan middleware, data dimensi atau fakta dengan data
hak username dan pengaksesan query pada data sumber.
pengaksesan password untuk Proses transformasi akan didefinisikan
data mengakses data secara sederhana berupa tabel
sumber dan target. transformasi yang menyimpan nilai data
5 Transformasi Proses ETL lama beserta nilai transformasinya.

70
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

1.7. Algoritma ETL Dimana external data tersebut dapat

diambil dari beberapa source, diantaranya
SQL Server 2000, Oracle, Excel, HTML,
Start dsb. Sesudah pengumpulan external data,
dilanjutkan dengan pembuatan package
(paket, kemudian melakukan pengecekan
Pengumpulan External apakah source external data sudah sesuai.
Data Contoh dalam hal ini adalah source
external data dari SQL Server 2000 tidak
dapat dijadikan satu dengan source
Pembuatan Local external data Oracle. Apabila source
Package external data belum sesuai, maka proses
dikembalikan lagi ke tahap awal, yaitu
pembuatan package. Apabila source
Extract external data sudah sesuai, maka sistem
Sesuai Tidak melakukan extract.
Tidak Dengan Setelah sistem melakukan extract,
Source External maka selesailah sudah proses extract
Data? dalam ETL, yang kemudian dilanjutkan
dengan proses Transform. Dimana
Ya package yang sudah terkelompok, di
transformasikan (transform) kemudian di
Lakukan eksekusi (execute) sehingga menghasilkan
Extract package yang siap untuk dijadikan
metadata.
Proses Loading dalam ETL
Package hanyalah sebatas me-load package
Yang Terkelompok menjadi sebuah metadata.

1.8. Analisis Teknologi yang

digunakan
Transform
Transform

Package Sesuai kebutuhan dari pengguna,

data warehouse akan dibangun pada
DBMS SQL Server 2000. Pembangunan
proses ETL dinamis dapat menggunakan
Execute beragam teknologi. Dapat menggunakan
Package aplikasi standalone yang dibangun dalam
beragam bahasa pemrograman seperti C,
C++, Java, Pascal, VB dan sebagainya.
PackageYang Bahasa-bahasa pemrograman tersebut
Sudah Siap Untuk telah mendukung koneksi ke berbagai
Dijadikan Meta Data macam DBMS baik secara langsung
maupun melalui Open Database
Connectivity (ODBC). Dapat juga
Stop menggunakan fitur DBMS tempat data
warehouse dikembangkan. Pada SQL
Server 2000 terdapat fitur Data
Transformation Services (DTS) yang dapat
digunakan untuk melakukan impor dan
Gambar 3.1 Algoritma ETL ekspor data dari dan ke berbagai macam
DBMS.
Proses Extract pada ETL dimulai
dengan pengumpulan external data.

71
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

2. Analisis Kasus Data warehouse sistem operasional kurang bisa

Departemen Pertanian dijadikan acuan untuk melakukan
Pembuatan data warehouse analisis.
Departemen Pertanian ini merupakan
inisialisasi bagi pembangunan data 2. Waktu
warehouse Departemen Pertanian secara Setelah terjadi sebuah transaksi
menyeluruh. Pembuatan data warehouse pada sistem operasional, pihak
ini mengambil dua domain dari bisnis eksekutif tidak bias mendapatkan
proses Departemen Pertanian yaitu Basis laporannya dalam waktu yang
Data Statistik Pertaniandan Basis Data cepat. Pihak eksekutif harus
Ekspor Impor. melewati proses birokrasi yang
Pembuatan data warehouse ini panjang untuk mendapatkannya.
memiliki tujuan untuk memenuhi kebutuhan
analisis secara umum eksekutif 3. Format
Departemen Pertanian. Pembuatan data Format laporan biasanya
warehouse ini berusaha membangun didefinisikan oleh pihak eksekutif
sebuah sistem dinamis yang mudah pada awal permintaan laporan.
dikembangkan apabila terdapat kebutuhan Setelah laporan dengan format
baru dari pihak eksekutif. tertentu bisa diaksesnya, pihak
Selama ini, pihak eksekutif eksekutif harus melakukan proses
Departemen Pertanian melakukan akses yang sama untuk mendapatkan
terhadap data laporan melalui Pusat Data informasi dalam format yang
dan Informasi Departemen Pertanian berbeda. Intinya adalah pihak
(PUSDATIN). Walaupun memiliki hak eksekutif memiliki kesulitan untuk
akses langsung ke data di masing-masing memandang informasi yang sama
sistem operasional di bawahnya, tetapi dalam bentuk yang berbeda,
data tersebut adalah data transaksional misalnya spreadsheets atau chart.
yang terlalu detail dan kurang bisa
dijadikan acuan analisis. 4. Integritas
Walaupun informasi yang
7.1. Kebutuhan Sistem Data warehouse dibutuhkan telah didapatkan,
Departemen Pertanian keakuratan dari data masih
Pelaksanaan proses, ekstraksi data diragukan. Proses manual yang
operasional kemudian menampilkannya melibatkan data besar dan
dalam bentuk laporan, secara manual rendundan rawan akan kesalahan.
mempunyai banyak kendala. Perangkuman
data yang melibatkan banyak sumber Data warehouse menyediakan
merupakan sebuah proses rumit yang kemampuan untuk menanggulangi
rawan akan kesalahan. Tingkat kerumitan kelemahan-kelemahan diatas. Dengan
bisa bertambah apabila proses melibatkan data warehouse, pihak eksekutif memiliki
banyak data yang redundan. hak penuh untuk mendapatkan laporan
yang dibutuhkannya. Waktu yang
Secara umum, kelemahan-kelemahan dari dibutuhkan untuk mendapatkan laporan
sistem yang sekarang ada adalah : yang dibutuhkannya menjadi singkat.
1. Akses Dengan bantuan aplikasi pelaporan yang
Pihak eksekutif harus melalui pihak mendukung data warehouse, pihak
ketiga, dalam hal ini pihak eksekutif bisa melihat informasi yang
PUSDATIN, untuk mengakses dimilikinya dalam berbagai format.
laporan-laporan yang Proses otomasi dalam data
dibutuhkannya. Walaupun pihak warehouse, meminimalisir kesalahan dan
eksekutif memiliki akses langsung membuat keakuratan data lebih terjamin.
ke sistem operasional, data pada

72

Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
7.2. Penelitian Umum Data warehouse
Departemen Pertanian
Seperti telah disebutkan
sebelumnya, pembuatan data warehouse
ini merupakan inisialisasi dibangunnya data
warehouse keseluruhan Departemen
Pertanian. Sebagai awalnya, data
warehouse Departemen Pertanian akan
melibatkan data dari tiga domain yaitu
produksi, keuangan dan SDM. Data
warehouse Departemen Pertanian
dibangun dengan tujuan memberikan
kemudahan pengaksesan informasi
terhadap data penting dalam bisnis proses
Departemen Pertanian yang dilakukan oleh
pihak eksekutif Departemen Pertanian
yang dibutuhkan dalam pengambilan
keputusan strategis Departemen Pertanian.
Sistem ini mengambil data dari tiga domain
sumber, mengintegrasikanya dalam basis
data tunggal dan menampilkannya kepada
pengguna dalam bentuk laporan-laporan.
Data berasal dari sistem
operasional dengan berbagai format basis
data sumber dan format data. Sistem
operasional ada yang menggunakan
Database Management System (DBMS),
ada juga yang menggunakan file
spreadsheet (Microsoft Excel). Proses
ekstraksi dijadwalkan oleh administrator
data warehouse. Pendefinisian jadwal ini
telah dilakukan sebelumnya oleh pihak
eksekutif, pihak sistem operasional dan
administrator data warehouse. Selain
melakukan penjadwalan ekstraksi,
administrator sebenarnya juga
melaksanakan tugas standar dalam
pemeliharaan basis data data warehouse.
Di antaranya adalah proses backup,
recovery, dan pengeksekusian proses
ekstraksi (di luar jadwal) apabila terdapat
kegagalan roses ekstraksi.
Tugas standar administrator ini
tidak digambarkan pada Gambar III-5.
Pengguna yang ingin melihat laporan akan
berhadapan dengan antarmuka Online
Analytical Processing (OLAP) tools, yang
akan menyampaikan informasi dalam data
warehouse dengan berbagai format.
Proses ekstraksi dijadwalkan
secara default sebulan sekali untuk
keseluruhan data system operasional.
ISSN 2087-2658
Volume 5, Nomor 2, Juli 2016
Apabila terdapat perubahan kebutuhan,
administrator dapat mengganti jadwal
ekstraksi sesuai kebutuhan.
Hanya administrator yang memiliki
hak akses langsung ke basis data data
warehouse.
Pengguna tidak memiliki hak untuk
mengakses langsung data pada basis data
data warehouse. Antar muka pengguna
hanyalah OLAP tools, seperti telah
disebutkan di atas.
Basis data pada data warehouse
Departemen Pertanian dibangun di atas
DBMS SQL Server 2000. Tipe-tipe
penyimpanan data menggunakan tipe
standar yang disediakan DBMS seperti
char, varchar, number, serta datetime.
Fitur-fitur DBMS yang digunakan adalah
fitur standar pendefinisian basis data dan
tabel serta foreign key.
Untuk proses ETL digunakan fitur
Data Transformation Service (DTS)
menggunakan ActiveX Script Task dalam
bahasa VBScript.
Data sumber akan diekstrak,
ditransformasi, dan di-load ke integration
layer. Kemudian data akan diekstrak lagi
menjadi beberapa data mart. Aplikasi
report akan berhubungan dengan data
mart yang mempunyai data yang
dibutuhkannya.
Penulisan Penelitian ini hanya
melingkupi proses pada flow 1 (ETL dari
data sumber ke integration layer). Untuk
proses ekstrak data ke data mart dan
proses penggunaan data pada data mart
tidak dibahas dalam Penelitian ini.
Setelah sistem data warehouse
mendapat data yang telah diekstrak dari
sistem operasional, sistem akan
melakukan proses transformasi sederhana
yang termasuk di dalamnya proses
cleaning sederhana dan integrasi
sederhana. Sistem memiliki dictionary
tentang nilai data yang mungkin terjadi dan
data koreksi bila terdapat kesalahan nilai
data. Proses integrasi juga didefinisikan
dalam dictionary berbentuk keterangan
nilai reference terhadap data lain apabila
ada. Contoh proses cleaning adalah
mengubah nilai data “palawija” menjadi
“non palawija”.
73

Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
2.3. Analisis Sistem Data warehouse
Departemen Pertanian
Agar dapat dikembangkan menjadi
data warehouse Departemen Pertanian
yang terintegrasi secara keseluruhan,
sistem inisialisasi ini berusaha
dikembangkan dengan memikirkan
perkembangan kebutuhan yang dinamis.
Perubahan-perubahan kebutuhan
berusaha diakomodasi oleh sistem tanpa
perlu mengubah struktur sistem ataupun
program-program yang digunakan sistem.
Perubahan kebutuhan diharapkan hanya
bersifat mengubah konfigurasi sistem.
Sistem yang dibangun ini memiliki
kelemahan dalam proses integrasi. Proses
integrasi kurang dilakukan menyeluruh
terhadap data dalam seluruh sistem. Selain
disebabkan oleh data sumber yang tidak
menyeluruh (hanya sebagian sistem
operasional), hal ini disebabkan karena
kotornya data pada sistem operasional
yang menyebabkan diperlukan proses
integrasi lanjut yang lebih rumit.
Sebenarnya ada cara yang lebih mudah
yaitu mengubahproses bisnis sistem
operasional, tetapi hal ini cenderung tidak
dipilih karena membuat data warehouse
bergantung terhadap sistem operasional.
Terdapat juga suatu informasi yang
sama, tetapi disimpan sebagai subjek yang
berbeda dalam sistem ini. Pada intinya
proses integrasi lanjut dapat dikembangkan
pada sistem ini tanpa mempengaruhi
keseluruhan sistem.
2.4. Analisis Proses ETL Sistem Data
warehouse Departemen Pertanian
Dalam rangka mendukung
dibangunnya sebuah sistem data
warehouse yang dinamis perlu dibangun
proses ETL yang dinamis pula. Proses ETL
bergantung pada skema data sumber,
proses transformasi, dan skema data
output (basis data integration layer).
Proses ETL data warehouse
Departemen Pertanian dilakukan langsung
on the fly tanpa melibatkan table
sementara sebagai perantara. Data
diekstrak kemudian dilakukan transformasi
dan akhirnya di-load ke basis data secara
ISSN 2087-2658
Volume 5, Nomor 2, Juli 2016
langsung. Proses ini menghasilkan waktu
proses ETL yang lebih cepat tetapi di sisi
lain menghabiskan resource pada sistem
operasional dan sistem data warehouse
sendiri. Untuk itu penjadwalan proses ETL
dilakukan ketika sistem operasional sedang
tidak sibuk melakukan transaksi. Seperti
telah disebutkan sebelumnya, proses
transformasi hanya melakukan proses
sederhana yaitu pengoreksian nilai data
menggunakan tabel dictionary. Setelah
ditransformasi, data langsung di-load ke
basis data data warehouse.
3. Kesimpulan Penerapan
Dalam penerapan ini telah dipilih
beberapa metode yang digunakan untuk
merealisasikan pembangunan proses ETL
dinamis. Digunakan metode file compare
untuk melakukan ekstraksi data sumber.
Fungsi-fungsi yang digunakan dalam
proses transformasi adalah konversi
format, manipulasi string, fungsi aritmatik,
conditional assignment, referential integrity
dan surrogate key resolution. Proses
loading dibagi menjadi dua yaitu loading
untuk tabel dimensi dan loading untuk tabel
fakta. Untuk loading tabel dimensi, dipilih
strategi penggunaan critical column disertai
dengan penambahan record.
I. Daftar Pustaka
1. Fathansyah, Ir., 2002, Buku Teks
Ilmu Komputer Basis Data,
Informatika, Bandung
2. Fowler, Martin, 2004, UML Distilled
Edisi 3 Panduan Singkat Bahasa
Pemodelan Objek Standar, 2005,
Andi, Yogyakarta
3. http://en.wikipedia.org/wiki/Extract,_
transform,_load
4. http://www.cert.or.id/~budi/courses/
ec7010/dikmenjur-2004/supawi-
report.pdf
5. http://www.ganesha.co.id
6. http://www.itech.fgcu.edu/cis/slides/
chapter10.ppt
7. http://www.iwaysoftware.com/produ
cts/images/etl_chart_sm4.gif
74
 ISSN 2087-2658
Jurnal Nasional Pendidikan Teknik Informatika (JANAPATI)
Volume 5, Nomor 2, Juli 2016

8. http://www.mcrit.com/ASSEMBLIN 13. Pressman, Roger S., Ph.D., 2002,

G/assemb_central/WhatESS.htmhtt Rekayasa Perangkat Lunak
p://www.ptct.com/EIS.html Pendekatan Praktisi (Buku II), Andi,
9. http://www.utminers.utep.edu/mmah Yogyakarta
mood/cis5311dtmba/slides/chapter0 14. Suhendar, A. S.Si., Hariman
2.ppt Gunadi, S.Si., MT., 2002, Visual
10. Ibrahim, Nugroho Setyabudhi, Modeling Menggunakan UML dan
Takariyana Heni A., 2004, Rational Rose, Informatika,
Perancangan Data Warehouse Bandung
Pada Pusat Data dan Informasi 15. Turban, Efram, Jay E. Aronson, and
Pertanian, Tesis Magister Ting Peng Liang, 2005, Decision
Manajemen Informasi Universitas Support Systems and Intelligent
Bina Nusantara, Jakarta Systems (Sistem Pendukung
11. Inmon, W.H., 2002, Building The Keputusan dan Sistem Cerdas),
Data Warehouse, Third Edition, Edisi 7 Jilid 1, Andi, Yogyakarta
John Wiley and Sons, Inc., New 16. www.athens.edu/dreyfp/MIS/Third%
York 20Ed/PPP/Ch10.ppt
12. O’Neil, Bonnie, Michael Schrader, 17. www.itee.adfa.edu.au/courses/ACS
John Dakin, Kieron Hardy, Matthew C7309/work/ch08.ppt
Townsend, Michael Whitmer, 1997, 18. www.vancouver.wsu.edu/fac/roseg/
Oracle® Data Warehousing, MIS350/ch2.ppt
Norhern Lights Software, Ltd.,
SAMS Publishing

75