BAB 5 ANALISIS BISNIS PADA TINGKAT DATA WAREHOUSE
5.6. Data Warehoues : Fungsi, Komponen dan Contoh
Di data warehouse aktual, gambar yang diproses dan digabungkan dari sistem sumber disajikan (misalnya, transaksi, inventaris, dan data master). Data warehouse modern biasanya berfungsi sebagai area penyimpanan untuk dimensi organisasi serta tempat penyimpanan metadata. Pertama, kita akan melihat dimensi bisnis, lalu menjelaskan konsep repositori metadata.
Dari area pementasan, sumber data dikumpulkan, digabungkan, dan diubah di data warehouse aktual. Salah satu proses terpenting adalah transaksi bisnis (fakta) kemudian diperkaya dengan dimensi seperti hubungan organisasi dan ditempatkan dalam hierarki produk sebelum data dikirim ke area data mart. Ini kemudian akan memungkinkan analis dan pengguna bisnis untuk menyiapkan laporan interaktif melalui teknik "potong dan dadu" (yaitu, memecah angka menjadi komponen mereka). Sebagai titik awal, transaksi bisnis tidak memiliki dimensi ketika tiba di data warehouse dari staging area. Artinya kita tidak bisa menjawab pertanyaan tentang kapan, dimana, siapa, apa, atau mengapa. Transaksi bisnis hanyalah fakta atau peristiwa, yang dengan sendirinya sama sekali tidak berguna untuk tujuan pelaporan dan analisis.
Contoh pernyataan yang tidak berarti bagi seorang analis adalah "Penjualan kami mencapai Rp. 357,7 milyar." Bisnis biasanya menginginkan jawaban atas pertanyaan tentang kapan, untuk apa, di mana, oleh siapa, untuk siapa, dalam mata uang apa? Dan dimensi inilah yang memungkinkan pengguna bisnis atau analis untuk menjawab pertanyaan-pertanyaan berikut:
Kapan itu terjadi? Tahun, kuartal, bulan, minggu, hari, waktu yang mana?
Dimana dan kepada siapa itu terjadi? Penjual mana, departemen mana, area bisnis apa, negara mana?
Apa yang terjadi? Apa yang kami buat untuk produk apa dan di grup produk mana?
Semua pertanyaan ini relevan bagi analis.
Pemodelan dimensi adalah cara yang populer untuk mengatur data di data warehouse untuk analisis dan pelaporan — dan bukan tanpa alasan. Titik awalnya adalah transaksi atau fakta yang terdaftar sebelumnya. Mungkin juga berguna untuk melihat fakta organisasi sebagai peristiwa. Baris fakta ini diperkaya dengan dimensi di data warehouse untuk memberikan perspektif.
Dimensi dalam Exhibit 5.4 yang mengelilingi fakta atau transaksi menempatkan angka penjualan, angka pendapatan, dan angka biaya ke dalam perspektif. Jenis ilustrasi ini juga disebut skema bintang. Antara lain, memberikan kesempatan kepada pengguna bisnis dan analis untuk mendapatkan jawaban dari data warehouse seperti ini:
Penjualan kami dalam grup produk 1 pada bulan Desember di Amerika Serikat, diukur dalam mata uang dolar AS, adalah 2 juta.
Penjualan di departemen 2 area bisnis 1 pada kuartal pertama di Indonesia, diukur dalam mata uang rupiah, adalah 28 juta.
Perhatikan bahwa dimensi menjawab pertanyaan tentang kapan, untuk apa, di mana, untuk siapa, dan oleh siapa. Realitas bisnis dipandang multidimensi untuk menciptakan wawasan yang optimal. Secara umum, perspektif multidimensi memungkinkan bisnis untuk menjawab pertanyaan: "Mengapa semuanya menjadi seperti itu?"
Exhibit 5.4 Transaksi Berbasis Fakta Dikelilingi oleh Perspektif Multidimensi
Perhatikan hierarki dalam dimensi di Exhibit 5.4. Organisasi terdiri, misalnya, dari sejumlah area bisnis. Di bawah masing-masing area ini, kami memiliki sejumlah departemen, dan di setiap departemen, kami memiliki sejumlah karyawan. Hierarki ini memberi kita kesempatan untuk memotong dan memilah informasi. Angka penjualan untuk keseluruhan organisasi dapat dipecah menjadi area bisnis. Setiap area bisnis kemudian dapat dipecah menjadi departemen, dan angka departemen dapat dipecah menjadi karyawan individu.
Perhatikan bahwa fitur ini sangat membantu ketika bisnis — setiap hari — menganalisis informasi dengan sendirinya dan oleh karena itu tidak menggunakan sumber daya analis kuantitatif.
Data warehouse modern biasanya berisi repositori metadata. Di sini informasi tentang data bisnis disimpan. Definisi paling sederhana dari metadata adalah data tentang data.
Misalnya: untuk kamera, data adalah foto digital; Metadata biasanya berisi informasi tentang tanggal pengambilan foto, pengaturan kamera, nama pabrikan, ukuran, dan resolusi. Metadata memfasilitasi pemahaman data dengan maksud untuk menggunakan dan mengelola data.
Metadata telah diberi peran sentral karena bisnis menjadi semakin menuntut dokumentasi.
Perpustakaan telah mendaftarkan metadata tentang buku untuk memfasilitasi pencarian.
Metadata ini meliputi judul, genre, tahun penerbitan, penulis buku, dan lain sebagainya. Tanpa metadata, akan sulit atau hampir tidak mungkin untuk menemukan data yang relevan (buku).
Dokumentasi data dan tabel sama pentingnya, dan permintaan untuk pendaftaran metadata di data warehouse telah berkembang pesat dalam beberapa tahun terakhir.
Sebelumnya, tabel dan bidang cukup memiliki nama yang bermakna. Cara termudah untuk membuat metadata tentang tabel dan bidang adalah dengan memberikan nama yang bermakna ini. Misalnya, pertimbangkan tabel pendapatan yang berisi dua bidang, Pendapatan dan Waktu.
Itu seharusnya memperjelas isi tabel! Masalahnya adalah, bagaimanapun, bahwa pengguna selain yang membuat tabel mungkin menafsirkan konten bidang pendapatan secara berbeda.
Apakah itu pendapatan dengan atau tanpa pajak pertambahan nilai (PPN)? Apakah diskon
sudah termasuk dalam angka? Apakah angka pendapatan dalam dolar AS atau Rupiah? Dan itu hanyalah beberapa kemungkinan interpretasi yang berbeda.
Maklum, registrasi metadata sebelumnya tidak lagi memadai. Registrasi metadata yang lebih baik dapat dilakukan dengan menggunakan label pada bidang tabel. Bidang pendapatan dapat memiliki label yang menjelaskan isinya dengan tepat: pendapatan tidak termasuk PPN termasuk diskon dalam dolar AS. Itu akan meningkatkan kualitas metadata, dan datanya dapat digunakan oleh pengguna lain. Tetapi kami masih memiliki masalah bahwa pengguna harus dapat mencari melalui tabel untuk bidang dengan, misalnya, konten pendapatan (seperti saat kami mencari buku di perpustakaan).
Banyak vendor BA telah mengambil tindakan atas konsekuensi kebutuhan pelanggan akan pendaftaran metadata lanjutan dan opsi penelusuran untuk pengguna pada umumnya.
Mereka telah membuat satu lapisan metadata tunggal dalam format teks (format XML, sebenarnya), yang menunjuk ke tabel fisik, bidang, pengguna, server, program, dan laporan.
Lapisan ini dapat ditemukan di repositori metadata dari data warehouse (lihat Exhibit 5.5).
Exhibit 5.5 Repositori Metadata
Repositori metadata telah menjadi salah satu argumen peningkatan dan penjualan vendor BA yang paling penting — dan argumennya menarik. Lapisan metadata menghasilkan dokumentasi tentang semua yang terjadi di data warehouse dan portal front-end. Beberapa pengembang perangkat lunak bekerja di sepanjang garis bahwa laporan tidak dapat diproduksi jika mereka tidak terdaftar di penyimpanan metadata dari data warehouse. Demikian pula, tabel fisik tidak tersedia untuk lingkungan pelaporan tanpa registrasi metadata. Situasi yang sama terjadi dengan pengguna, server, dan sebagainya. Repositori metadata telah menjadi kunci, karena semua pertanyaan Web harus melalui lapisan metadata melalui server metadata. Ini menghasilkan visibilitas dan dokumentasi dari segala sesuatu yang terjadi, dan ini dianggap semakin penting bagi bisnis. Saat ini, hampir tidak terpikirkan untuk membangun struktur data warehouse tanpa repositori metadata pusat. Di lapisan atas platform BA, tempat pengguna mengakses laporan dan data, gudang metadata ini juga memungkinkan pengguna untuk mencari definisi data dan laporan dari antarmuka Web seolah-olah mereka adalah buku di perpustakaan.
Pengguna perangkat lunak iTunes Apple tahu tentang pendaftaran metadata dalam format XML. File XML di perpustakaan iTunes di komputer pribadi berisi semua informasi tentang trek, album, dan artis, dan sebagainya. iTunes menggunakan file penting ini untuk bernavigasi. Jika pengguna iTunes menyalin satu file musik MP3 dengan Microsoft Explorer ke perpustakaan musik fisik di luar iTunes, file itu tidak akan muncul di koleksi musik iTunes pengguna, dan dia tidak akan dapat mencarinya atau memutarnya, karena informasi tentang keberadaan file dan data lain bukan metadata yang didaftarkan melalui software iTunes miliknya.
Data mart untuk mendukung proses bisnis adalah produk akhir yang dikirimkan oleh data warehouse dan dengan demikian berisi informasi untuk pengguna bisnis. Data mart adalah
versi khusus dari data warehouse. Seperti data warehouse, data mart adalah cuplikan dari data operasional untuk membantu pengguna bisnis membuat keputusan atau membuat analisis strategis (misalnya, berdasarkan tren historis). Perbedaan antara data mart dan data warehouse adalah bahwa data mart dibuat berdasarkan kebutuhan pelaporan tertentu dari kelompok pengguna yang spesifik dan terdefinisi dengan baik, dan data mart menyediakan akses bisnis yang mudah ke informasi yang relevan. Data mart dengan demikian dirancang untuk menjawab pertanyaan spesifik pengguna. Dimensi yang relevan untuk area bisnis telah ditautkan ke data, dan aturan bisnis tertentu berlaku untuk membantu pengguna bergerak dalam dimensi dan hierarki yang diinginkan. Suatu organisasi mungkin memiliki beberapa data mart untuk fungsi yang berbeda, seperti pemasaran, penjualan, keuangan, sumber daya manusia, dan lain-lain.
Data mart biasanya terstruktur sebagai model dimensi seperti skema bintang, yang terdiri dari tabel fakta dan tabel dimensi dan menggunakan aturan bisnis tertentu. Kubus pemrosesan analitik online (OLAP) atau tabel pivot adalah cara mengatur data dalam area (larik) untuk memfasilitasi analisis data cepat, dan sering digunakan untuk data mart. Array disebut kubus.
Sebuah organisasi mungkin memiliki banyak data mart, yang masing-masing mungkin relevan dengan satu atau lebih unit bisnis yang telah dirancang untuk itu. Banyak unit bisnis telah mengasumsikan "kepemilikan" atas data mart mereka, dan ini termasuk perangkat keras, perangkat lunak, dan data. Kepemilikan ini memungkinkan setiap unit bisnis atau departemen atau area bisnis untuk menggunakan, memanipulasi, dan mengembangkan data mereka agar sesuai dengan kebutuhan mereka, tanpa mengubah informasi apa pun di data mart lain atau secara terpusat di data warehouse.
Alasan lain untuk mengumpulkan data di pasar kecil adalah waktu yang dihemat sehubungan dengan kueri, hanya karena data yang harus diproses lebih sedikit. Ini juga berarti bahwa dua data mart yang berbeda dapat menyajikan informasi yang persis sama, kecuali yang satu menyajikannya secara lebih rinci, yang kemudian dapat digunakan jika pengguna memutuskan bahwa ia membutuhkan informasi yang rinci.
Ketika data telah digabungkan dan diperkaya dengan dimensi di data warehouse, data dapat diekstraksi untuk penggunaan bisnis ke data mart. Proses ETL ini akan menggunakan banyak aturan bisnis yang berbeda sesuai dengan kebutuhan masing-masing pengguna. Data mart dapat mencakup kebutuhan fungsi akuntansi untuk sekumpulan angka terkonsolidasi dengan aturan bisnis spesifik yang diperlukan. Data mart lain mungkin mencakup kebutuhan untuk memantau kinerja proses penjualan organisasi.
Exhibit 5.6 Tabel Penjualan Penjual Buku
Seperti yang dinyatakan sebelumnya, database untuk data mart mungkin kubus relasional atau OLAP. Perbedaan fungsional antara kedua jenis data ini sangat penting bagi analis dan pengguna bisnis, di antara alasan lain karena perbedaan tersebut memengaruhi waktu respons dan ruang lingkup analitis. Model data relasional adalah model di mana data diatur menggunakan karakteristik umum. Urutan baris tidak masalah; hanya jumlah baris yang penting karena jumlahnya memengaruhi seberapa cepat ekstraksi dapat dilakukan. Urutan kolom juga tidak penting. Tabel berbasis transaksi selalu bersifat relasional, seperti yang dijelaskan di bagian berikut ini.
Tabel penjualan di Exhibit 5.6 memiliki tujuh kolom dan tiga baris, dan merupakan contoh sederhana dari tampilan tabel transaksi relasional. Dalam tabel semacam ini, kita dapat dengan cepat menambahkan transaksi baru dari toko, saat item lain terjual.
Untuk menambahkan, memproses, dan mengekstrak data dari tabel relasional, kami menggunakan bahasa pemrograman SQL, yang merupakan cara formal untuk berbicara dengan database. Jika kita ingin mengetahui pendapatan toko buku yang didistribusikan pada jenis
"sampul tipis" dan "sampul tebal", kita dapat mengirimkan sintaks SQL berikut ke database:
Kami kemudian akan menerima kumpulan data pendapatan yang terlihat seperti Exhibit 5.7.
Perusahaan besar, seperti Walmart, memiliki beberapa ratus juta transaksi setahun, dan tidak perlu banyak imajinasi untuk melihat bahwa waktu respons dalam pelaporan bisa sangat lama jika ringkasan tabel relasional sebelumnya tidak dilakukan, atau jika laporan mart dengan database dalam bentuk kubus OLAP tidak dibuat.
Exhibit 5.7 Pendapatan Toko Buku
Setelah kubus OLAP dibuat, kita tidak bisa hanya menambahkan baris lain, seperti tabel relasional. Dengan menggunakan metode penyusunan data dalam kubus ini, kami menghindari batasan database relasional, karena ini tidak cocok untuk analisis instan (real-time) dari volume data yang besar. Database relasional lebih cocok untuk membuat baris dalam tabel serangkaian transaksi. Meskipun banyak alat pelaporan dikembangkan untuk data relasional, alat ini lambat dalam meringkas database yang besar. Dalam kubus OLAP, semua penjumlahan dan penghitungan dilakukan sebelumnya; kita hanya menarik nilai dari kubus, jadi untuk berbicara, dan karena itu kita tidak perlu merangkum sesuatu seperti jutaan baris dalam ekstrak.
Dalam kubus OLAP di Exhibit 5.8, setiap subkubus kecil berisi angka penjualan yang dihitung sebelumnya untuk kumpulan nilai dimensi yang berbeda. Penjualan produk tertentu (mantel)/coat di negara tertentu (Indonesia) dalam jangka waktu tertentu (bulan Juli) bisa menjadi kubus gelap kecil di Exhibit 5.8. Hal pintar tentang kubus OLAP adalah ketika pengguna bisnis meminta informasi tentang penjualan mantel di Indonesia pada bulan Juli, semua transaksi yang terlibat tidak perlu diringkas. Alih-alih, aplikasi ekstrak berjalan langsung ke dalam kubus melalui beberapa nilai indeks, dan mengekstrak satu gambar tunggal yang telah dihitung sebelumnya dan dijumlahkan, yang kemudian dikembalikan ke perangkat lunak klien pengguna.
Exhibit 5.8 OLAP Cube dengan Angka Penjualan dan Tiga Dimensi atau Perspektif Kubus OLAP dapat dilihat sebagai perluasan dari spreadsheet dua dimensi. Seorang pengontrol (analis keuangan) perlu menganalisis data keuangan berdasarkan produk, periode waktu, kota, jenis pendapatan, atau biaya, dan kemudian membandingkan aktual dengan angka anggaran. Masing-masing dimensi ini mungkin memiliki hierarki bawaan. Pengontrol akan mulai pada tingkat yang diringkas (seperti perbedaan total antara pendapatan aktual dan pendapatan yang dianggarkan), dan kemudian melakukan penelusuran atau potong-dan-dadu dalam kubus untuk menemukan entitas, produk, staf penjualan, atau periode waktu yang bertanggung jawab atas perbedaan angka total.
Perhatikan bahwa ukuran kubus OLAP meningkat secara eksponensial saat lebih banyak dimensi ditambahkan ke kubus atau saat jumlah kategori dalam dimensi individual bertambah; ini secara alami memengaruhi kinerja dan waktu respons.