PERANCANGAN DATA MART KASUS BILLING & COLLECTION PT. TELKOM DENGAN ORACLE DATABASE DAN ORACLE WAREHOUSE BULDER Stanislaus Beta Purbantomo Fakutas Ilmu Komputer Universitas Gunadarma Abstrak Perkembangan dunia telekomunikasi yang semakin pesat tidak lepas dari kinerja penyedia jasa telekomunikasi itu sendiri. Semakin berkembangnya telekomunikasi juga diikuti oleh semakin banyaknya pengguna dari telekomunikasi. Hal itu juga dirasakan oleh PT. TELKOM, di mana pelanggan yang menggunakan jasanya semakin banyak. Hal tersebut tentunya akan semakin menyulitkan Unit Billing & Collection dari PT. TELKOM untuk menangani data tagihan dan pembayaran pelanggan yang sedemikian besarnya. Terlebih lagi data tersebut penting untuk mendukung manajemen dalam mengambil keputusan. Oleh karena itu, diperlukan sebuah Data Mart yang mampu memuat data tagihan pelanggan dengan volume yang besar. Data Mart merupakan sebuah pengkoleksian data yang mendukung pengambilan keputusan manajemen dalam suatu departemen atau unit bisnis tertentu dengan menyimpan data yang sesuai dengan kebutuhan manajemen. Dengan Data Mart, maka data tagihan pelanggan yang bervolume besar dan kompleks dapat ditangani dengan lebih baik oleh Unit Billing & Collection. Sehingga nantinya Data Mart ini dapat menjadi suatu sumber data yang dipercaya untuk mendukung pengambilan keputusan strategis perusahaan. Perancangan dan pembuatan Data Mart akan dilakukan dengan mengunakan Oracle Database 10g sebagai database sumber data dan Staging Area. Juga menggunakan Oracle Warehouse Builder sebagai ETL (Extraction, Transformation, Loading) tools untuk mengekstraksi data, mentransformasi data dan memuat data ke dalam Data Mart sesuai dengan kebutuhan dan format yang diinginkan user melalui Oracle Mapping. Kata kunci : Data Mart, Billing & Collection, ETL, Mapping, Oracle, Oracle Warehouse Builder PENDAHULUAN Latar Belakang Masalah PT. Telekomunikasi Indonesia Tbk. (TELKOM) merupakan perusahaan penyelenggara informasi dan telekomunikasi (Infocomm) serta penyedia jasa dan jaringan telekomunikasi secara lengkap (full service & network provider) yang terbesar di Indonesia yang memiliki jumlah pengguna yang besar di seluruh Indonesia untuk tiap produk dan jasa yang ditawarkan PT.TELKOM. Dengan jumlah pelanggan yang begitu besar, tentunya akan semakin banyak pula data dan informasi yang harus disimpan dalam database TELKOM untuk memenuhi kebutuhan
informasional dalam menunjang pengambilan keputusan yang dilakukan pihak manajemen, terutama yang bersangkutan dengan transaksi tagihan telepon (invoices) dari pelanggan. Bertolak dari pengambilan keputusan yang diambil oleh manajemen tingkat atas, terutama untuk pengambilan keputusan strategis, sering kali data dan informasi yang mereka perlukan merupakan data historis yang mungkin sudah tidak tersedia / tersimpan lagi di dalam database transaksional perusahaan. Serta untuk memperoleh data tersebut, diperlukan pengaksesan / query yang rumit dan kompleks dari banyak tabel yang ada dalam database perusahaan, yang apabila dilakukan mungkin dapat mengganggu kestabilan pemrosesan data
transaksional perusahaan, juga membutuhkan waktu yang cukup lama. Untuk mengatasi masalah tersebut, penulis mencoba merancang dan membuat suatu Data Mart bagi PT.TELKOM yang dapat meningkatkan ketersediaan data, termasuk pengelolaan data dalam volume yang besar, serta kinerja, kecepatan dan ketepatan penyajian informasi yang baik terutama yang bersangkutan dengan transaksi tagihan telepon pelanggan. Rumusan Masalah Rumusan masalah penulisan ini adalah bagaimana mengelola data transaksi tagihan telepon pelanggan dengan volume yang besar dan kompleks ke dalam suatu penyimpanan data secara optimal yang mampu memudahkan dan mempercepat proses penyediaan, pengaksesan dan pengambilan data dalam menunjang pengambilan keputusan perusahaan. Batasan Masalah Penulisan ini dibatasi kepada perancangan dan pembuatan Data Mart untuk data transaksional tagihan telepon pelanggan per bulan dari PT. TELKOM yang dikelola oleh Unit Billing & Collection (UBC) pada PT. TELKOM Divisi Regional II (Jakarta dan sekitarnya), di mana Data Mart ini akan difokuskan untuk memberikan kemudahan dalam penyimpanan, penyediaan, pengaksesan dan pengambilan data yang berkenaan dengan transaksi tersebut. Tujuan Penulisan Tujuan dari penulisan ini adalah untuk membuat sebuah perancangan Data Mart yang mampu menyimpan data terkini dan data historis perusahaan mengenai tagihan telepon pelanggan secara optimal serta mampu untuk diakses dan diambil datanya dengan cepat dan mudah, sehingga mampu menyediakan informasi data transaksi dengan cepat dan akurat.
LANDASAN TEORI Data Warehouse Data Warehouse merupakan sebuah database relasional yang lebih dirancang untuk pengambilan data / query dan analisis daripada untuk pemrosesan transaksi (transaction processing). Data Warehouse menyimpan data historis yang diperoleh dari data transaksional, namun dapat termasuk data dari sumber yang lainnya. Data Warehouse memisahkan beban kerja analisis dari beban kerja transaksional dan memungkinkan perusahaan menggabungkan data dari beberapa sumber. [8] Sedangkan menurut Bill Inmon yang dikenal sebagai “father of the Data Warehouse”, definisi dari Data Warehouse adalah : Sekumpulan / koleksi data yang mendukung pengambilan keputusan manajemen dengan karakteristik subject oriented, integrated, time-variant, dan nonvolatile. [2] Pemodelan dimensional / Dimensionality modeling adalah suatu teknik desain logis yang bertujuan menampilkan data dalam bentuk standar dan menarik yang mendukung akses yang cepat. Pemodelan dimensional menggunakan konsep Entity-Relationship (ER) modeling dengan batasan yang penting. Setiap model dimensional (DM) terdiri dari sebuah tabel dengan gabungan kunci primer (primary keys) yang disebut tabel fakta (fact table) yang menyimpan metric pengukuran / perhitungan bisnis perusahaan, dan kumpulan dari tabel yang lebih kecil yang disebut tabel dimensi (dimension table) yang menyimpan data yang relatif bersifat statis yang biasanya digunakan dalam memperoleh query. [2] Metrik (metrics) atau measures adalah data utama yang bertipe numerik yang menjadi acuan kuantitas oleh user, sedang dimensi adalah kategori yang digunakan untuk memandang ringkasan data yang dimiliki. Dalam Data Warehouse pemodelan dimensional ini dituangkan ke dalam sebuah skema. Skema dalam Data Warehouse adalah
sebuah pengkoleksian dari objek database, meliputi tabel, view, indeks dan sinonim. Ada dua skema yang umum digunakan dalam mendesain sebuah Data Warehouse, yaitu skema bintang (Star Schema) dan skema snowflake (Snowflake Schema). Fungsi Extraction Transformation Loading (ETL) adalah melakukan format ulang data yang relevan dari sistem sumber ke dalam informasi yang berguna dan siap disimpan ke dalam Data Warehouse. Mempopulasikan sebuah Data Warehouse meliputi semua tugas yang berkaitan dengan mendapatkan data dari sumber sistem operasional, pembersihan (cleansing) dan mentransformasikan data ke dalam bentuk format dan level detail yang sesuai, memuatnya ke Data Warehouse target serta menyiapkannya untuk tujuan analisis. [4] Data Mart Data Mart merupakan sebuah bagian (subset) dari Data Warehouse yang mendukung kebutuhan dari suatu departemen atau fungsi bisnis tertentu dalam perusahaan, seperti penjualan, keuangan ataupun pemasaran. Sebuah Data Mart menyimpan sebagian dari data yang ada dalam Data Warehouse, biasanya dalam bentuk rangkuman data yang berhubungan dengan satu departemen tertentu atau fungsi bisnis tertentu. Mengacu pada fungsi bisnis tertentu, Data Mart biasanya mengambil data hanya dari beberapa sumber. Sumber itu bisa berasal dari sistem operasional, Data Warehouse atau sumber lainnya (sumber eksternal). [2]
yang lebih dinamis dan ulet dengan biaya yang lebih murah. Dengan grid computing, sekelompok komponen hardware dan software yang independen dan modular dapat dihubungkan dan digabungkan sesuai permintaan untuk menghadapi perubahan kebutuhan bisnis. Oracle Warehouse Builder 10g Oracle Warehouse Builder (OWB) merupakan tool tunggal yang komprehensif untuk seluruh aspek manajemen data. OWB menjembatani database Oracle untuk mengubah data menjadi informasi dengan kualitas yang tinggi. OWB menyediakan manajemen kualitas data, audit data, permodelan relasional dan dimensional yang terintegrasi penuh serta daur hidup manajamen data dan metadata yang lengkap. OWB memungkinkan user untuk membuat Data Warehouse, memindahkan data dari sistem terdahulu, mengkonsolidasi data dari sumber data yang terpisah, membersihkan dan mengubah data untuk menyediakan informasi berkualitas dan mengatur metadata perusahaan. [10] Fungsi utama dari OWB adalah penggabungan sumber data yang beragam dalam pembuatan Data Warehouse dan migrasi data dari sistem sebelumnya. Lebih jauh lagi, OWB menawarkan kemampuan untuk permodelan data relasional, dimensional dan metadata, data profiling, data cleansing dan data auditing. ANALISA KEBUTUHAN BISNIS
Oracle Database 10g Oracle merupakan sebuah Relational Database Management System (RDBMS), yaitu software yang digunakan untuk mengatur database dengan memecah data dalam beberapa tabel terpisah, yang dibuat dan dipasarkan oleh Oracle Corporation. Huruf ‘g’ pada Oracle 10g merujuk pada grid atau jaringan, di mana grid computing adalah sebuah arsitektur IT baru yang menghasilkan sistem informasi perusahaan
Analisis User Requirements Pada perancangan Data Mart ini penanganan seluruh transaksi dan kegiatan yang berhubungan dengan tagihan telepon pelanggan dikonsentrasikan ke dalam modul Billing & Collection. Kebutuhan bisnis (user business requirements) yang diperlukan dalam modul tersebut yang dibutuhkan manajemen untuk keperluan analisis antara lain :
•
• •
Informasi mengenai tagihan telepon pelanggan, meliputi besarnya tagihan serta perinciannya ( penggunaan untuk Lokal, SLJJ, SLI007, dan lain-lain) Informasi mengenai pembayaran tagihan telepon oleh pelanggan Informasi mengenai tagihan pelanggan yang tidak tertagih / tunggakan tagihan telepon.
Metrik dan Dimensi Dari user requirements yang ditetapkan, dilakukan analisa untuk menentukan metrik dan dimensi yang sesuai. Berikut ini adalah metrik beserta satuan ukuran yang digunakan dalam Data Mart ini. Metrik : Biaya pemakaian untuk pembicaraan Lokal (rupiah), Biaya pemakaian untuk pembicaraan SLJJ (rupiah), Biaya pemakaian untuk pembicaraan SLI007 (rupiah), Biaya Airtime (rupiah), Biaya pemakaian Premium Call (rupiah), Biaya pemakaian untuk SMS (rupiah), Biaya pemakaian Akses Internet (rupiah), Besar tagihan sebelum pajak (rupiah), Besar pajak (rupiah), Besar tagihan termasuk pajak / Total Tagihan (rupiah); Digunakan secara agregasi : Jumlah pelanggan yang telah membayar tagihan * (orang), Jumlah tagihan terbayar * (rupiah), Jumlah pelanggan yang menunggak * (orang), Jumlah tunggakan * (rupiah); Tambahan : Status pembayaran (Lunas / Belum), Tanggal pembayaran tagihan (Date), Batas pembayaran tagihan (Date).
Dimensi : • Waktu : Informasi waktu dari tagihan telepon pelanggan (tagihan tersebut merupakan tagihan bulan apa). • Kategori Pelanggan : Informasi mengenai kategori pengelompokkan pelanggan, termasuk informasi kualitas pelanggan. • Produk : Informasi mengenai produk yang ditawarkan PT.TELKOM. • Datel : Informasi mengenai Kantor Daerah Telekomunikasi (kandatel), yang menunjukkan sebaran pelanggan dan pembagian daerah telekomunikasi DivRe II. • Klien : Informasi tentang klien / pelanggan, baik identitas data pribadi maupun keterangan statusnya sebagai pelanggan PT.TELKOM. • Alamat : Informasi tentang alamat dari klien / pelanggan (merupakan bagian dari dimensi Klien). • Customer Master : Informasi mengenai keterangan pelanggan dengan produk yang diambilnya termasuk data nomor telepon, tanggal pendaftaran pemasangan sambungan telepon, dan sebagainya.
Identifikasi Sumber Data Tahap yang memegang peranan penting dalam proses pembuatan Data Mart adalah melakukan analisa terhadap data, yakni proses mengidentifikasi tabel yang menyimpan informasi mengenai metrik dan dimensi yang dibutuhkan. Sumber data yang teridentifikasi dari Unit Billing & Collection PT. TELKOM adalah tabel penunjang sebuah sistem dari Perancis yang disebut SISKA.
Table Name Client
Dossier
Gambar 1. ERD SISKA Dari ERD sistem SISKA pada gambar 1 di atas tampak bahwa terdapat 8 tabel yang teridentifikasi sebagai sumber data, yaitu : Tabel 1. Tabel Sumber Data Table Name
Adresse
Client
Field Name NCli * NAdr * Nom PreNom1 PreNom2 LPostal LCom LQuartier LVoie NVoie Compl_Adr Bat KAdr DatDeb DatFin NCli * Nom PreNom1 PreNom2 Alias NAdr_Cli CCat LCom_Regc Statut Daten_Cr
Data Type Number Number Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Date Date Number Varchar2 Varchar2 Varchar2 Varchar2 Number Varchar2 Varchar2 Varchar2 Date
Size 8 4 60 40 40 8 30 30 30 12 60 8 250
8 60 40 40 40 4 3 60 1
Encaissement
H_Expedition
Field Name Nb_Rejet Nb_Irrecouverable NCli * NDos * CProd DatMS Daten_MS KInst NAdr_Fact NAdr_Inst Niv_Relance Dat_Relance NB_Relance NB_Restriction NB_Litige Mnt_Litige ND Lg_ND NDos_Ancien NDos_Nouveau NCli_Ancien NClie_Nouveau CDatel NCli * NDos * Daten_Enc * Enc * Mnt_Enc An_Fact Per_Fact Datech_Fact NCli * NDos * ND An_Fact * Per_Fact * CCat CProd NAdr_Fact Datech_Fact Mnt_Local Mnt_SLJJ Mnt_SLI007 Mnt_AirTime Mnt_PremCall Mnt_SMS Mnt_ISDN Mnt_HT_Fact Mnt_Taxe_Fact Mnt_Solde_Fact
Data Type Number Number Number Number Varchar2 Date Date Varchar2 Number Number Varchar2 Date Number Number Number Number Varchar2 Number Number Number Number Number Varchar2 Number Number Date Number Number Number Number Date Number Number Varchar2 Number Number Varchar2 Varchar2 Number Date Number Number Number Number Number Number Number Number Number Number
Size 3 3 8 4 2
255 4 4 1 3 3 2 12 2 15 2 4 4 8 8 2 8 4 5 14 2 4 2 8 4 15 4 2 3 2 4 12 2 12 2 12 2 12 2 12 2 12 2 12 2 12 2 12 2 12 2
Table Name
P_Categorie
P_CProd
P_Datel
Field Name CCat * LCat LQualabo Mnt_Imp Nb_Fact_Imp Nb_Mois_Anc Pourc_Penalite Mnt_Min CProd * Abrv_Prod LProd Mois_Abo_Min Mois_Abo_Fin Prod_Brand Prod_Categorie CDatel * Abrv_Datel Lb_Datel F_Trans_Enc SID
Data Type Varchar2 Varchar2 Varchar2 Number Number Number Number Number Varchar2 Varchar2 Varchar2 Number Number Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2 Varchar2
Size 3 30 30 12 2 3 2 4 2 12 2 2 5 30 2 2 30 30 2 3 30 1 30
informasi mengenai tagihan telepon pelanggan dengan rinciannya, status pembayaran tagihan, tanggal pembayaran serta batas pembayaran tagihan. Dari tabel fakta dan tabel dimensi yang telah dirancang, akan didapatkan hasil akhir perancangan logis dari skema Data Mart Unit Billing & Collection PT. TELKOM. Dalam perancangan Data Mart Star Schema dipilih sebagai rancangan skema Data Mart secara keseluruhan, dengan pertimbangan bahwa dengan mempergunakan star schema maka query cost Data Mart dapat diminimalkan. Di mana kompleksitas dalam sintaks query pada tabel fakta dan tabel dimensi Data Mart dikurangi sedemikian rupa dengan cara menginputkan dimension keys setiap tabel dimensi ke dalam tabel fakta. Gambar 2 akan menunjukkan Star schema dari Data Mart Unit Billing & Collection.
PEMBUATAN DATA MART Perancangan Target Data Mart Perancangan target Data Mart yang akan dilakukan adalah perancangan tabel dimensi (Dimension Tables Design), perancangan tabel fakta (Fact Table / Cube Design) serta perancangan skema Data Mart. Sesuai dengan hasil analisa dari user requirements serta dimensi informasi yang diharapkan oleh manajemen, maka dimensi yang dirancang untuk Data Mart ini adalah : Dimensi Waktu (Time_Dim), Dimensi Kategori Pelanggan (CustCategorie_Dim), Dimensi Produk (Prod_Dim), Dimensi Daerah Telekomunikasi (Datel_Dim), Dimensi Klien / Pelanggan (Client_Dim), Dimensi Alamat Pelanggan (Adresse_Dim), Dimensi Customer Master (Dossier_Dim). Tabel fakta yang akan dirancang dan dikembangkan sesuai dengan subjek area adalah Billing_Collection_Fact. Tabel fakta dari Unit Billing & Collection ini memegang metrik dari bisnis seperti yang telah ditetapkan sesuai user requirements. Tabel fakta Biling_Collection_Fact ini akan menyimpan
Gambar 2. Billing & Collection Star Schema ETL Dalam pembentukan Data Mart, terjadi proses ETL atau Extract, Transform and Loading, yaitu proses memformat ulang data dari data sumber untuk dijadikan informasi yang sesuai dengan kebutuhan user dan berguna bagi keperluan analisis manajemen. Dalam tugas akhir ini, tiap proses ETL akan dibahas secara terpisah, namun pada akhirnya keseluruhannya akan menjadi satu kesatuan
proses yang utuh yang tertuang dalam Mapping Oracle Warehouse Builder Extraction. Tabel yang ada pada data sumber yang telah teridentifikasi selanjutnya akan diekstraksi (extract) atau dipilih atribut apa saja yang dibutuhkan untuk dimuat ke dalam tabel dimensi dan tabel fakta. Berikut ini adalah atribut yang dihapuskan dari tabel sumber dalam database penunjang sistem SISKA yang diekstrak : • Adresse : Nom, PreNom1, PreNom2, KAdr • Client : LCom_Regc • Dossier : K_Inst • Encaissement : Enc, Mnt_Enc, Datech_Fact • H_Expedition : ND • P_Categorie : tidak ada atribut yang dihapus • P_CProd : tidak ada atribut yang dihapus • P_Datel : tidak ada atribut yang dihapus Transformation. Setelah tabel data sumber diekstraksi, proses selanjutnya adalah transformasi data yaitu proses mengubah data dan atribut menjadi bentuk yang sesuai dengan format yang dibutuhkan user untuk dimuat ke dalam Data Mart. Ada beberapa proses transformasi yang akan dilakukan, yaitu : • Data Source Enrichment Month_Table Dengan adanya dimensi waktu Time_Dim, diperlukan sebuah tabel sumber baru sebagai sumber data bagi dimensi waktu tersebut. Oleh sebab itu, penulis membuat sebuah tabel data sumber baru yaitu Month_Table yang menyimpan informasi mengenai keterangan waktu mulai dari bulanan, triwulan, semester hingga tahun dengan atribut, tipe data dan record sesuai dengan kebutuhan user. Statement SQL : CREATE TABLE MONTH_TABLE ( MONTH_CODE VARCHAR2(7), MONTH_NUMBER NUMBER(2), MONTH_LDESC VARCHAR2(30),
QUARTER_NUMBER NUMBER(2), QUARTER_LDESC VARCHAR2(30), SEMESTER_NUMBER NUMBER(2), SEMESTER_LDESC VARCHAR2(30), YEAR NUMBER(4), CONSTRAINT MONTH_TABLE_M_PK PRIMARY KEY (MONTH_CODE));
• Enrichment Atribut Enc_Stat Pada tabel Encaissement perlu ditambahkan sebuah atribut dengan nilai konstan (1), sebagai sebuah flag atau penanda status yang nantinya akan menjadi source bagi atribut Enc_Stat pada tabel fakta yang menunjukkan bahwa tagihan telah terbayar. Sehingga atribut ini dapat mempermudah dalam mengetahui tagihan mana yang telah dibayar oleh pelanggan. Statement SQL : ALTER TABLE ENCAISSEMENT ADD ( ENC_STAT VARCHAR2(1)); UPDATE ENCAISSEMENT SET ENC_STAT='1' WHERE DATEN_ENC IS NOT NULL;
• Joining Sumber Tabel Fakta Data sumber bagi tabel fakta didapatkan dari tabel H_Expedition dan tabel Encaissement. Oleh karena itu, kedua tabel tersebut perlu dijoin menggunakan operasi Left Outer Join untuk memberikan informasi tagihan mana saja yang telah dibayar dan mana saja tagihan yang belum dibayar. Proses join ini dilakukan berdasarkan kesamaan data pada atribut NCli, NDos, An_Fact dan Per_Fact dari kedua tabel. Namun selain itu, dari hasil join kedua buah tabel, masih memiliki kekurangan untuk dijadikan sebagai sumber dari tabel fakta. Hal ini disebabkan karena kurangnya atribut CDatel sebagai dimension key Datel_Dim. Sehingga perlu dilakukan joining sekali lagi dengan tabel Dossier untuk memuat atribut CDatel bagi masing masing record. Proses join yang merupakan operasi Equijoin ini dilakukan berdasarkan
kesamaan data pada atribut NCli dan NDos pada tabel tersebut. • Concatenation dan Data Type Convert untuk Month_Code Dalam tabel sumber seperti H_Expedition dan Encaissement, penanda keterangan waktu tersimpan dalam atribut An_Fact dan Per_Fact dengan tipe data keduanya adalah Number. Sedangkan format yang diharapkan user untuk keterangan waktu, seperti tertuang dalam dimensi waktu Time_Dim dan tabel sumbernya Month_Table, adalah dalam tipe data Varchar2 dengan contoh kode ‘M200908’ ( M menjelaskan kode bulan, 2009 menunjukkan tahun, 08 menunjukkan bulan) untuk disimpan dalam tabel dimensi waktu dan tabel fakta. Oleh karena itu, diperlukan proses perangkaian nilai atribut (concatenation) An_Fact dan Per_Fact sebagai nilai atribut Month_Code yang didahului dengan konversi tipe data (data type convertion) kedua atribut tersebut dari tipe data Number menjadi tipe data Varchar2. Statement SQL : CONCAT('M', CONCAT(TO_CHAR(AN_FACT), CASE WHEN PER_FACT < 10 THEN CONCAT('0', TO_CHAR(PER_FACT)) ELSE TO_CHAR(PER_FACT) END ) ) AS MONTH_CODE
Loading. Apabila data yang telah diekstraksi selesai dibentuk dan diformat sesuai kebutuhan user, selanjutnya data tersebut akan dimuat (load) ke dalam Data Mart Billing & Collection. Oracle Mapping. Dalam Oracle Warehouse Builder, keseluruhan proses ETL didefinisikan dan digenerasikan ke dalam Mapping, di mana tiap tabel dimensi dan tabel fakta akan memiliki sebuah mapping yang berbeda. Nantinya mapping ini akan digenerasikan ke
dalam format PL/SQL untuk kemudian dieksekusi, sehingga proses ETL Data Mart yang telah dirancang akan dilakukan mulai dari ekstraksi, tranformasi hingga pemuatan data ke dalam tabel dimensi dan tabel fakta. Berikut adalah salah satu mapping dari tabel dimensi dan tabel fakta yang ditunjukkan pada gambar 3.
Gambar 3. Adresse_Dim_Map Pengaksesan Data Mart Pengaksesan terhadap Data Mart Unit Billing & Collection PT. TELKOM dapat dilakukan menggunakan fasilitas Cube & Dimensions Data Viewer dari Oracle Warehouse Builder, dapat juga dilakukan dengan menggunakan sintaks statement SQL yang nantinya dapat diembeded ke dalam sintaks aplikasi pelaporan yang ada. Dengan menggunakan Cube & Dimension Data Viewer, fungsi agregasi bekerja secara maksimal di setiap dimensi yang ada, sehingga perbandingan antar dimensi dapat terlihat dengan jelas. Menggunakan statement SQL dalam mengakses Data Mart memerlukan ketelitian dalam mendeklarasikan atribut yang ingin diperoleh, juga dalam pemberian kondisi Where dan pendeklarasian dimension key dari tabel fakta dan dimensi.
Oracle Scheduling Rangkaian terakhir dalam perancangan dan pembuatan Data Mart Unit Billing & Collection PT. TELKOM adalah pendeklarasian Oracle Scheduling. Penjadwalan dengan Oracle ini diperlukan untuk menentukan kapan saja proses peng-update-an Data Mart dilakukan. Dengan penjadwalan Oracle ini, maka langkah dalam pembuatan Data Mart akan diulang pada waktu yang ditentukan untuk memuat data baru ke dalam Data Mart. PENUTUP Kesimpulan Dari penulisan ini dapat diambil kesimpulan bahwa Data Mart merupakan bagian kecil dari Data Warehouse yang memiliki fungsi yang sama, hanya saja Data Mart disesuaikan dengan kebutuhan data yang telah ditentukan. Skema Data Mart yang dirancang dalam penulisan tugas terakhir ini dispesifikasikan untuk memenuhi kebutuhan manajemen Unit Billing & Collection PT. TELKOM akan informasi yang akurat mengenai tagihan telepon pelanggan baik yang bersifat terkini maupun historis. Dengan skema Data Mart yang telah dirancang dan dituangkan menjadi Data Mart seutuhnya menggunakan data dummy, dapat disimpulkan bahwa skema bintang (Star Schema) yang digunakan pada Data Mart mampu menyimpan dan menangani data transaksi tagihan telepon dengan volume yang besar dan kompleks secara optimal. Perancangan tersebut pun mampu mendukung pengaksesan dan pengambilan data dengan cepat dan mudah, dengan meminimalkan query cost dan kompleksitas sintaks query tabel fakta dan dimensi melalui penggunaan skema bintang. Saran Beberapa saran yang dapat diberikan untuk pengembangan Data Mart ini adalah :
•
•
Sebaiknya untuk pengembangan yang lebih lanjut, Data Mart ini diimplementasikan secara riil di dalam proyek pengembangan perusahaan. Sehingga manfaat dari pengimplementasian Data Mart dapat dirasakan oleh perusahaan untuk mendapatkan informasi dengan kualitas yang lebih baik. Perancangan Data Mart ini dapat digunakan sebagai dasar acuan untuk mengembangkan Data Mart untuk unit bidang dan unit bisnis lainnya dari PT. TELKOM. Dan nantinya juga dapat digunakan sebagai dasar dari pengembangan Data Warehouse yang menangani data dari keseluruhan perusahaan untuk mendukung kebutuhan informasi pihak manajemen untuk mengambil keputusan strategis menyangkut seluruh aspek dari perusahaan itu sendiri.
DAFTAR PUSTAKA [1] Adamson, Christopher. Mastering Data Warehouse Aggregates : Solutions for Star Schema Performance. Wiley Publishing, Inc. USA. 2007. [2] Connolly, Thomas and Carolyn Begg. Database Systems : A Practical Approach to Design, Implementation and Management. Third Edition. Addison Wesley Longman Limited. USA. 2000. [3] Giovinazzo, William. Object-Oriented Data Warehouse Design : Building a Star Schema. Prentice-Hall, Inc. New Jersey. USA. 2000 [4] Hobbs, Lilian, et all. Oracle Database 10g Data Warehousing. Elsevier Digital Press. USA. 2005
[5] Inmon, W. H. Building the Data Warehouse. Third Edition. John Wiley & Sons, Inc. USA. 2002 [6] Kimball, Ralph. The Data Warehouse Toolkit. John Wiley & Sons, Inc. USA. 1996. [7] Oracle Team. Oracle Database : Concepts 10g Release 2 (10.2) B1422002. Oracle. USA. 2005.
[10] Oracle Team. Oracle Warehouse Builder : User’s Guide 10g Release 2 (10.2.0.2) B28223-03. Oracle. USA. 2006 [11] Poe, Vidette. Building a Data Warehouse for Decision Support. Prentice-Hall, Inc. New Jersey. USA. 1996. [12] www.oracle.com [13] www.TELKOM.co.id
[8] Oracle Team. Oracle Database : Data Warehousing Guide 10g Release 2 (10.2) B14223-02. Oracle. USA. 2005. [9] Oracle Team. Oracle Warehouse Builder : Installation & Configuration Guide 10g Release 2 (10.2) for WINDOWS & UNIX B28224-03. Oracle. USA. 2006
[14] www.wikipedia.com [15] Yasdani, Sima and Shirley S. Wong. Data Warehousing with Oracle : An Administrator’s Handbook. Prentice-Hall, Inc. New Jersey. USA. 1998.
