Model Pengembangan Data Warehouse dan Data Multi Dimensi

Nama              : Ida Ayu Gde Widya Savitri

NIM                : 1805551113

Matakuliah    : Data Warehouse

Nama Dosen : I Putu Agus Eka Pratama, S.T., M.T.

Teknologi Informasi Fakultas Teknik

Model Pengembangan Data Warehouse dan

Data Multi Dimensi pada Data Warehouse

 

Dalam database konvensional, terdapat data-data transaksional yang mengutamakan perubahan data di dalamnya, namun tidak ada data historis.

Sementara di data warehouse justru sebaliknya, data historis diperhatikan, yang digunakan untuk kebutuhan analisa data.

 

Data Mart

v Data Mart merupakan sub bagian dari Data Warehouse yang digunakan sebagai sebuah struktur data, yang di dalamnya memuat data, guna memudahkan pengguna akhir (end user) dalam mengakses data dari Data Warehouse sesuai kebutuhan ataupun untuk analisa data.

v Data Mart merupakan unit (bagian) dari Data Warehouse secara keseluruhan yang berada pada layer akses (Access Layer) berorientasikan kepada spesifik proses bisnis dan kebutuhan dari unit organisasi tempat dimana Data Warehouse tersebut diimplementasikan.

v Apabila dianalogikan sebagai sebuah himpunan, maka Data Mart adalah himpunan bagian dari sebuah himpunan semesta bernama Data Warehouse. Sehingga apabila Data Warehouse memuat semua data sesuai kebutuhan dari keseluruhan organisasi bersangkutan, maka Data Mart hanya spesifik memuat data sesuai kebutuhan per unit atau departemen saja.

v Contoh data mart dan data warehouse itu apa? Jika casenya di unud, maka data warehouse adalah yang terpusat di usdi, sedangkan data mart adalah yang ada di setiap fakultas (setiap fakultas bisa saja akan membagi lagi ke dalam masing-masing prodi di bawahnya).

 

Model Pengembangan Data Warehouse

Terdapat 6 model pengembangan, yang bisa dikelompokkan menjadi yang tanpa menggunakan User Feedback dan yang menggunakan User Feedback, yang dimana dari 2 kelompok ini sama-sama terdapat Top Down, Bottom Up, dan Parallel.

        1.     Top Down tanpa User Fedback

        2.     Bottom Up tanpa User Feedback

        3.     Parallel tanpa User Feedback

        4.     Top Down beserta User Feedback

        5.     Bottom Up beserta User Feedback

        6.     Parallel Beserta User Feedback

 

1.    Top Down Tanpa User Feedback

Model ini merupakan model yang paling sederhana karena tidak melibatkan user feedback dan hanya memiliki alur: sumber-sumber data (Data Sources) à diteruskan ke Data Warehouse à diteruskan (dipecah) ke dalam beberapa buah Data Mart. Model ini fokus kepada kemampuan untuk dapat menjadikan pengguna bebas memperoleh data sesuai kebutuhan melalui Data Mart (yang dialirkan dari Data Warehouse), tanpa melakukan pengubahan apapun pada Data Warehouse itu sendiri. Penambahan data pada Data Mart, hanya dapat dilakukan melalui Data Warehouse, dengan mengikuti aliran Extraction, Transformation, Transportation (ETT) yaitu data diekstrak, data ditransformasikan, lalu data diangkut (transportation)

 

2.    Bottom Up Tanpa User Feedback

Model ini kebalikan dari Top Down. Sesuai dengan namanya, pengembangan dimulai dari bawah, dimana dua buah Data Mart atau lebih dibentuk dari data – data yang berasal dari berbagai sumber data (Data Sources).

a.     Tahap 1: ETT Terhadap Data Dari Sumber Data ke Data Mart

ETT (Extraction, Transformation, Transportation) pada sumber–sumber data ke masing–masing Data Mart. Setiap Data Mart mengintegrasikan data–data dari berbagai sumber tersebut.

b.     Tahap 2: ETT dari Data Mart ke Data Warehouse

Data dialirkan dari masing–masing Data Mart ke Data Warehouse, dengan kembali menggunakan proses ETT (Extraction, Transformation, Transportation) →data dari setiap Data Mart kembali diintegrasikan di dalam Data Warehouse→dilakukan juga penghilangan Redudancy pada data–data dari sejumlah Data Mart tersebut.

 

3.    Parallel Tanpa User Feedback

Model ini merupakan modifikasi dari model Top Down, namun Data Mart tidak sepenuhnya bergantung kepada Data Warehouse (dalam hal sumber data yang diperoleh) karena ada data model dari DW yang diikuti oleh semua Data Mart.

Langkah 1: bangun Data Warehouse dari berbagai sumber data → Di dalam Data Warehouse terdapat Data Model yang menjadi acuan bagi model data untuk Data Mart–Data Mart yang dibentuk kemudian → Data Model ikut mempengaruhi Data Mart.

Langkah 2: Data Mart yang terbentuk, ikut berperan di dalam membangun Data Warehouse melalui integrasi di level data. Perhatikan bahwa Data Model itu sudah ditentukan dari DW untuk semua Data Mart di bawahnya, lalu seperti biasanya terdapat ETT.

 

Data Model adalah pemodelan data, semacam "role" yg harus diikuti oleh semua data mart agar "sama" dengan DW, data dari berbagai sumber data itu beragam formatnya, saat di DW, dia harus diseragamkan, ada menggunakan ETL atau ELT, tergantung pilih yang mana dulu disana. Untuk model pengembangan ini, data model dapat berupa role untuk format datanya seperti apa, besar data, jenis data, dan lainnya.

Mengapa panah dari DW ke DM hanya 1 arah/tidak bolak balik, apakah itu artinya data yang masuk langsung ke data mart tidak di masukan juga ke dalam DW?

Dalam Paralel itu sudah ada "role"nya dalam bentuk data model yang berasal dari DW ke data mart, otomatis ada 1 panah searah. Data dari data mart bisa dimasukkan ke DW untuk model paralel tanpa user feedback ini jika diperlukan, namun bukan berarti data mart sepenuhnya bergantung kepada DW lagi seperti 2 model lainnya.

Masing masing model pengembangan itu sebenarnya difungsikan secara khusus untuk apa?

untuk masing2 model pengembangan, itu bs dipilih sesuai dengan: 1. Kebutuhan instanasi/organisasi/pengguna, 2. Budget, 3. Ketersediaan Resource, dan 4. Case Studi atau latar belakang diperlukannya DW dalam instani tersebut.

Apakah bisa dalam satu dw menggunakan kombinasi top down dan button up?

Bisa saja dibuatkan hybrid sepertiitu, 2-3 model digabungkan. apabila diperlukan. namun effortnya akan beda dengan pemilihan 1 model namun sudah matang keputusan pemilihannya

 

Selanjutnya, kelompok beserta user feedback. artinya, untuk 3 jenis ini, sama saja dengan kelompok yang tanpa user feedback dari sisi hubungan antara DW dan Data Mart serta bagaimana data-data itu mendapat perlakuan ETT. Bedanya adalah pada "user feedback" yang dilibatkan disini, user feedback ini diletakkan pada tatap muka aplikasi DW, dengan demikian, adanya user feedback ini mempengaruhi bagaimana DW dan data mart yang dibangun tersebut untuk ke depannya. Detail dari masing-masing kelompok besert user feedback antara lain sebagai berikut.

 

4.    Top Down Beserta User Feedback

Sejumlah data dari berbagi sumber data membentuk Data Warehouse → Data Warehouse menjadi pusat dari penggudangan data – data yang berasal dari berbagai sumber data tersebut. Terjadi proses integrasi di level data → memudahkan data – data disatukan ke dalam sebuah gudang data ini. Dari Data Warehouse, dibentuk sejumlah Data Mart sesuai dengan kebutuhan pengguna. User Feedback pada Data Mart, menjadi tolok ukur di dalam pengembangan berkelanjutan pada Data Mart dan Data Warehouse itu sendiri. User Feedback mempengaruhi Data Mart dan secara otomatis akan mempengaruhi Data Warehouse itu sendiri. .Terdapat aliran bolak – balik dari User Feedback (pengguna) ke Data Mart dan dari Data Mart ke Data Warehouse.

5.    Bottom Up Beserta User Feedback

Dibentuk terlebih dahulu 2 Data Mart atau lebih, menggunakan data-data dari berbagai sumber data→digunakan ETT (Extraction, Transformation, Transportation) untuk membantu pengumpulan data, ekstraksi data, transformasi ke format data yang disepakati bersama di dalam Data Mart, serta integrasi di level data itu sendiri. Lalu dibentuk Data Warehouse dari Data Mart yang terbentuk → kembali menggunakan ETT untuk mengintegrasikan data – data dari berbagai Data Mart tersebut ke dalam kesatuan Data Warehouse. User Feedback diarahkan melalui tatap muka Data Warehouse, yang berefek terhadap Data Mart – Data Mart yang membentuk Data Warehouse.

6.    Parallel Beserta User Feedback

Langkah awal: penentuan aturan untuk model data dari Data Warehouse ke Data Mart yang terbentuk → Data dari berbagai sumber data masuk ke Data Mart dan ke Data Warehouse. Data dari sumber data yang menuju ke Data Mart saja yang akan melalui proses ETT (Extraction, Transformation, Transportation). Data yang menuju ke Data Warehouse, terlebih dahulu menuju ke Data Model dari Data Warehouse, untuk menyeragaman format. Pada Data Warehouse tidak terjadi ETT, sebab Data Warehouse menjadi pusat untuk model data enterprise, yang menjadi acuan bagi Data Mart lainnya. Data Warehouse mengagregasikan data, memuat fungsi koordinasi dan integratif untuk pengembangan ke depannya, termasuk juga manajemen data dan informasi kepada pengguna. User Feedback dialirkan melalui tatap muka ke Data Mart.

                                                 

Data Relasional vs Data Multidimensional

Ø  Data Relasional atau Relational Data Modelling (RDM) dipandang sebagai bentuk hubungan antar data (melalui tabel) yang berelasi dalam struktur hirarkis dan berada pada 2 dimensi (baris dan kolom).

Ø  Ada 3 relasi yang dikenal: One to One, One to Many, Many to Many

Ø  Dalam pengembangan perangkat lunak, untuk database, digunakan desain pengembangan berupa Entity Relationship Management (ERD).

Ø  Sudah dipastikan akan merupakan data transaksional, manipulasi data, tanpa menyimpan data historis (2 dimensi).

Ø  Data relasional adalah data yang memiliki hubungan antar satu sama lainnya, satu data akan berelasi dengan data lainnya bisa menggunakan one to one, one to many, dan many to many. Dalam pengimplementasiannya dapat menggunakan aplikasi software sqlyog atau phpMyAdmin. One to One adalah relasi satu data hanya dengan satu data lainnya; One to Many adalah relasi satu data dengan banyak data lainnya; dan Many to Many adalah relasi banyak data dengan banyak data lainnya

 

Data Multi Dimensi

Data multi dimensi (Multi Dimensional Data atau MDD) → model data fisik (Physical data Model) yang strukturnya dapat dilihat dari berbagai sudut pandang (dimensi), dengan tiga buah bagian (Record atau baris, Field atau kolom, dan layer), dengan objek – objek data multi dimensi di dalamnya, yang atributnya dibedakan menjadi atribut dimensi dan atribut pengukuran. Data multi dimensi, jika direpresentasikan ke dalam bentuk koordinat, maka dapat ditunjukkan ke dalam tiga buah sumbu: X, Y, dan Z. Jika dianalogikan dengan gambar bangun, maka data multi dimensi dapat diibaratkan sebagai bangun ruang yang memiliki 3 dimensi (panjang, lebar, tinggi).

Data relasional yang ada dalam "tabel" dengan field "baris" dan "kolom" tersebut, kita ubah ke dalam "sudut pandang". Sudut pandang inilah yang disebut dimensi. Analoginya kalua di data relasional, kita belajar datanya dengan sumbu x dan y (baris dan kolom pada tabel di db), maka di data multi dimensi ini, misal 3 dimensi, kita kenal sumbunya x, y, dan z.

 

Misalkan saja dimensi yang digunakan untuk melihat data mahasiswa adalah dimensi kelulusan, dimensi sidang TA, dan dimensi wisuda. Masing–masing dari dimensi tersebut, akan membentuk Tabel Kelulusan, Tabel Sidang_TA, dan Tabel Wisuda, dengan perincian sebagai berikut :

1. Tabel Kelulusan, Field : ID_Kelulusan (Primary Key), NIM, Nama, Angkatan, IPK.

2. Tabel Sidang_TA, Field : ID_Sidang, NIM, Nama, Judul, Pembimbing, Penguji, Kelulusan, Nilai.

3. Tabel Wisuda, Field : ID_Wisuda, NIM, Nama, Periode Wisuda.

Ketiga buah dimensi di atas, dapat digunakan untuk melihat data mahasiswa pada Tabel Mahasiswa.

 

 

Seperti ini jika diilustrasikan untuk menggambarkan bagaimana kita (pengguna) melihat data- tsb dalam dimensi yang berbeda-beda, kalau sulit membayangkan dalam "sumbu", kita coba ilustrasikan dalam bangun ruang kubus

 

Untuk apa sih ada data multi dimensi dan untuk apa mereka dipandang seperti itu? untuk memudahkan analisa data. Konsep dasar dari DW kan analytical data, makanya dia mengutamakan data historis, beda dgn database biasa yg transaksional. Setelah dimodelkan ke multi dimensi seperti ini, maka data mudah untuk diiris (slicing) sesuai kebutuhan

itu kan dimensinya dari 3 tabel berbeda, lalu semuanya merujuk pada data yang dibutuhkan user? jadi bisa dikatakan user dapat data yang diinginkan (contoh data penerbangan) dari banyak tabel yang menyangkut ke data penerbangan?

Iya, dibuatkan "sudut pandang"nya dlm bentuk "dimensi" sesuai kebutuhan, jadi disini jangan berpikir "query" seperti transaksional dan relasional, tapi "slicing" data. Bahasa ilmiahnya pivoting yg dilakukan terhadap data-data beragam tersebut dan jumlahnya banyak. Slicing/pivoting, data itu dipilah yg sesuai dengan kebutuhan dari sekian banyaknya data yang sudah digudangkan, dibersihkan, disesuaikan dgn temanya. diambil dr subsetnya dari semesta data, dan tidak lagi dengan many to many atau bentuk relasi dari 3 tersebut, karena disini kita "mengubah paradigma" dari relasional ke multi dimensi. Misal 1 unud ini, dia kan ada banyak fakultas, tiap fakultas ada sekian prodi, setiap prodi punya angkatan mahasiswanya, setiap angkatan punya jumlah mahasiswanya, setiap mahasiswa dari setiap angkatan di setiap prodi pada setiap fakultas itu punya prestasi akademik masing-masing. Jadi misal perlu analisa data "kelulusan" dengan syarat: semua mahasiswa di unud, angkatan 2016, yang wisuda 2020 ini, semua prodi dan fakultas. Kira-kira lebih mudah slicing dengan data multi dimensi dari data warehouse (lebih cepat dan mudah untuk semua case yang diminta)

Referensi:

I Putu Agus Eka Pratama. Handbook Data Warehouse. Penerbit Informatika. Bandung. 2017

Arsitektur Data Warehouse, Staging Area, Data Mart, Sumber Data

 Nama              : Ida Ayu Gde Widya Savitri

NIM                : 1805551113

Matakuliah    : Data Warehouse

Nama Dosen : I Putu Agus Eka Pratama, S.T., M.T.

Teknologi Informasi Fakultas Teknik

 

“DW memiliki 6 sifat utama : subject oriented, integrated, process oriented, time variant, accessible, non volatile” – Bill Inmon

“DW mengumpulkan data dari sumber – sumber transaksional (OLTP) untuk kebutuhan query dan analisa data →OLAP” – Ralph Kimball

 

Dari kedua definisi tersebut, keduanya saling melengkapi satu sama lain dalam menyempurnakan teknologi data warehouse. Bill Inmon mengutarakan mengenai 6 sifat (karakteristik) utama pada data warehouse, yang mana 6 sifat tersebut kemudian diadopsi juga pada big data dengan penyesuaian. Sedangkan dari Ralph Kimball, menambahkan mengenai adanya query data pada data warehouse serta analisa data yang kemudian menekankan adanya OLAP (On Line Analytical Processing).

 

Data transaksional yang telah dibahas sebelumnya menggunakan OLTP. Kata kuncinya pada "T" (transactional), sedangkan pada data warehouse menggunakan OLAP, kata kuncinya pada "A" yaitu "analytical"

OLTP : On Line Transactional Processing → data-data transaksional

OLAP : On Line Analytical Processing → query dan analisa → memperhatikan historis data

 

Contohnya:

Sebuah database biasa, setiap entri data pada tabel di dalam DB akan dilakukan penumpukan data (timpa) apabila terjadi edit/update —> di sini adanya data apapun yang mengalami perubahan, dia akan menggantikan data sebelumnya.

Pada Data Warehouse, entry data ke n apabila dilakukan pengeditan/perubahan, akan disimpan sebagai entry ke n+1 dengan disertai catatan waktu, proses, dan subyeknya —> di bagian ini, apapun perubahan yang ada, dia tidak menggantikan data sebelumnya, dalam artian memperhatikan history data tersebut.

 

BASIC ARCHITECTURE

Dari sisi arsitektur, secara umum data warehouse ada 3, seperti gambar di bawah ini:

a.     Data Source (Sumber Data)

Berbagai data digital dari berbagai sumber data, diambil untuk dikumpulkan ke warehouse. Ada dari sistem, file, berkas, dokumen yang didigitalkan (scan, ketik ulang), flat file, dan lainnya. Data-data digital ini, format datanya beragam, sizenya juga beragam tapi mereka semua masih termasuk data terstruktur.

 

b.     Warehouse (Gudang Datanya)

Apa yg digudangkan di sini? Data-data digital tersebut, yang berasal dari berbagai sumber data dengan beragam format data. Seperti apa penggudangannya? Masing-masing data tersebut diambil dalam bentuk metadata, summary data, atau raw data.

Di bagian warehouse inilah terdapat "pengubahan" dari "transaksional" ke “analitikal" melalui OLTP ke OLAP. Metadata, summary data, atau raw data —> ini yang membantu ketika transaksional akan diubah ke bentuk historis data

 

c.     User (Penggunanya)

User terbagi menjadi 3 yaitu analyst (tugasnya menganalisa data), mining (memperoleh knowledge dari data sesuai pola, mining ini artinya menambang data), dan reporting (menyampaikan laporan berdasarkan hasil Analisa dan mining tersebut).

 

STAGING AREA ARCHITECTURE   

Konsep dasarnya adalah penambahan Staging Area untuk menampung data–data dari sumber data transaksional, sebelum diteruskan ke warehouse. Jadi data-data tersebut dirapikan, dibersihkan, dan disesuaikan dengan kebutuhan. Inilah yang kelak dikenal dengan data cleansing/cleaning dan etl/elt.

Logikanya seperti ini: sumber data —> staging area —> warehouse

Ketika data dirapikan, dibersihkan dan disesuaikan, itu maksudnya dari sekian banyak data, maka yang "relevan" dengan kebutuhan pengguna, yang sesuai, yang formatnya perlu 'dirapikan', itu yang dilakukan di sana

Secara teknis maka melalui komputasi dan modul

 

Apakah staging area itu sama dengan data cleansing?

Staging area itu dibuatkan "tempat"nya, sedangkan "data cleansing" salah satu prosesnya. Contohnya, di warung makan adalah tempatnya berkumpul orang-orang makan dan pedagang, ini ibarat data dari berbagai sumber data dan administrator serta softwarenya, serta salah satu kegiatannya adalah makan (kegiatan lainnya transaksi, misal bayar setelah pesan/makan)

 

Staging area ini dalam bentuk apa biasanya? Apakah program software atau seperti apa, dan cara dari staging area bisa terhubung ke data warehouse seperti apa?

Ketika masuk ke teknis, dia bisa modulah dengan software, bisa dimasukkan ke dalam procedure atau barisan code (jika coding), bisa dengan penambahan modul

 

DATA MART

Data Mart merupakan data-data dari berbagai sumber data tersebut yang dipecah pecah ke dalam beberapa sub dari data warehouse. Contohnya, Universitas Udayana punya 1 buah data warehouse di USDI, maka data mart adalah "sub" data warehouse di setiap fakultas

Konsep dasarnya adalah penambahan Data Mart untuk dikombinasikan dengan Staging Area. Arsitektur ini diperkenalkan oleh Oracle dan merupakan arsitektur yang paling banyak digunakan. Mengapa? 1. Kemampuan untuk memilah data sesuai kebutuhan 2. Kemampuan kostumisasi sesuai kebutuhan

 

Kira-kira apa saja data yang perlu ditaruh ke dalam data mart yang tersebar di sejumlah unit?

Data fakultas, kegiatan-kegiatan di universitas dan fakultas, data UKM yang dimana data data tersebut punya pengelompokannya sendiri tetapi tetap masih berhubungan dengan data univ, data mahasiswa, data matakuliah, data dosen, data jadwal, data nilai, apapun data yang memiliki klasifikasinya tersendiri.

Dalam case USDI misalnya ada data mart kemahasiswaan, dimana data yang disimpan seperti biodata mahasiswa, nilai-nilai mahasiswa, atau mungkin KRS-KRS mahasiswa. Data Mart kepegawaian juga sama, biodata pegawai, jabatan. Data Mart administrasi misalnya memuat tentang hal-hal berbau administrasi yang ada di Universitas Udayana (misalnya data fakultas, data UKM, dan lainnya)

 

SUMBER DATA

Sumber-sumber data pada data warehouse, dibagi 2 jenis berdasarkan “asal”nya

       a.     Internal, yaitu dari internal organisasi, semua data digital dan data yang dibuat digital yang ada atau berasal dari internal institusi/organisasi bersangkutan

       b.     Eksternal, yaitu dari luar jaringan, terhubung melalui internet ataupun cloud

Contoh dari data internal dan eksternal pada USDI:

          1.     Data internal di USDI adalah data mahasiswa dan dosen, sementara data eksternalnya itu data pembayaran UKT yang terhubung oleh Bank BNI.

          2.     Data internalnya seperti data dosen, mahasiswa, pegawai, sementara data eksternalnya surat-surat edaran yang berkaitan dengan pembelajaran atau SK-SK

          3.     Data internal di USDI seperti data mahasiswa dan dosen yang ada pada SIMAK, dan untuk yang external misalkan data mahasiwa dan dosen yang ada pada DIKTI

 

Referensi:

I Putu Agus Eka Pratama. Handbook Data Warehouse. Penerbit Informatika. Bandung. 2017