Data Warehousing - Proses Pengiriman

Sebuah gudang data tidak pernah statis; itu berkembang seiring berkembangnya bisnis. Seiring berkembangnya bisnis, persyaratannya terus berubah dan oleh karena itu gudang data harus dirancang untuk menyesuaikan dengan perubahan ini. Oleh karena itu, sistem data warehouse harus fleksibel.

Idealnya harus ada proses pengiriman untuk mengirimkan data warehouse. Namun proyek gudang data biasanya mengalami berbagai masalah yang membuatnya sulit untuk menyelesaikan tugas dan kiriman dengan cara yang ketat dan teratur yang diminta oleh metode air terjun. Seringkali, persyaratan tidak dipahami sepenuhnya. Arsitektur, desain, dan komponen bangunan dapat diselesaikan hanya setelah mengumpulkan dan mempelajari semua persyaratan.

Metode Pengiriman

Metode pengiriman adalah varian dari pendekatan pengembangan aplikasi bersama yang diadopsi untuk pengiriman data warehouse. Kami telah melakukan proses pengiriman data warehouse untuk meminimalkan risiko. Pendekatan yang akan kita diskusikan di sini tidak mengurangi skala waktu pengiriman secara keseluruhan tetapi memastikan manfaat bisnis disampaikan secara bertahap melalui proses pengembangan.

Note - Proses pengiriman dibagi menjadi beberapa tahap untuk mengurangi proyek dan risiko pengiriman.

Diagram berikut menjelaskan tahapan dalam proses pengiriman -

Strategi TI

Data warehouse adalah investasi strategis yang membutuhkan proses bisnis untuk menghasilkan keuntungan. Strategi TI diperlukan untuk mendapatkan dan mempertahankan pendanaan untuk proyek tersebut.

Kasus bisnis

Tujuan kasus bisnis adalah untuk memperkirakan manfaat bisnis yang harus diperoleh dari penggunaan gudang data. Manfaat ini mungkin tidak dapat diukur tetapi manfaat yang diproyeksikan perlu dinyatakan dengan jelas. Jika data warehouse tidak memiliki business case yang jelas, maka bisnis tersebut cenderung mengalami masalah kredibilitas di beberapa tahap selama proses pengiriman. Oleh karena itu dalam proyek data warehouse kita perlu memahami business case untuk investasi.

Pendidikan dan Pembuatan Prototipe

Organisasi bereksperimen dengan konsep analisis data dan mendidik diri mereka sendiri tentang nilai memiliki gudang data sebelum mencari solusi. Ini diatasi dengan membuat prototipe. Ini membantu dalam memahami kelayakan dan manfaat dari gudang data. Kegiatan pembuatan prototipe dalam skala kecil dapat mendorong proses pendidikan selama -

Prototipe membahas tujuan teknis yang ditentukan.
Prototipe dapat dibuang setelah konsep kelayakan ditampilkan.
Aktivitas tersebut membahas sebagian kecil konten data akhir dari data warehouse.
Skala waktu aktivitas tidak kritis.

Poin-poin berikut harus diingat untuk menghasilkan rilis awal dan memberikan keuntungan bisnis.

Identifikasi arsitektur yang mampu berkembang.
Fokus pada persyaratan bisnis dan fase cetak biru teknis.
Batasi cakupan fase build pertama seminimal mungkin yang memberikan manfaat bisnis.
Pahami persyaratan jangka pendek dan jangka menengah dari data warehouse.

Persyaratan Bisnis

Untuk memberikan hasil yang berkualitas, kita harus memastikan bahwa persyaratan keseluruhan dipahami. Jika kita memahami kebutuhan bisnis baik untuk jangka pendek maupun jangka menengah, maka kita dapat merancang solusi untuk memenuhi kebutuhan jangka pendek. Solusi jangka pendek kemudian dapat dikembangkan menjadi solusi lengkap.

Aspek berikut ditentukan dalam tahap ini -

Aturan bisnis yang akan diterapkan pada data.
Model logis untuk informasi dalam gudang data.
Profil kueri untuk kebutuhan langsung.
Sistem sumber yang menyediakan data ini.

Cetak Biru Teknis

Fase ini perlu menghasilkan arsitektur keseluruhan yang memenuhi persyaratan jangka panjang. Fase ini juga menghasilkan komponen yang harus diterapkan dalam jangka pendek untuk mendapatkan keuntungan bisnis. Cetak biru perlu mengidentifikasi hal-hal berikut.

Arsitektur sistem secara keseluruhan.
Kebijakan penyimpanan data.
Strategi pencadangan dan pemulihan.
Arsitektur server dan data mart.
Rencana kapasitas perangkat keras dan infrastruktur.
Komponen desain database.

Membangun Versi

Pada tahap ini, hasil produksi pertama diproduksi. Hasil produksi ini adalah komponen terkecil dari gudang data. Komponen terkecil ini menambah keuntungan bisnis.

Beban Sejarah

Ini adalah fase di mana sisa riwayat yang diperlukan dimuat ke dalam gudang data. Dalam fase ini, kami tidak menambahkan entitas baru, tetapi tabel fisik tambahan mungkin akan dibuat untuk menyimpan volume data yang meningkat.

Mari kita ambil contoh. Misalkan fase versi membangun telah menghasilkan gudang data analisis penjualan ritel dengan riwayat selama 2 bulan. Informasi ini akan memungkinkan pengguna untuk menganalisis hanya tren terkini dan mengatasi masalah jangka pendek. Pengguna dalam hal ini tidak dapat mengidentifikasi tren tahunan dan musiman. Untuk membantunya melakukannya, riwayat penjualan 2 tahun terakhir dapat dimuat dari arsip. Sekarang data 40GB diperpanjang hingga 400GB.

Note - Prosedur pencadangan dan pemulihan mungkin menjadi rumit, oleh karena itu disarankan untuk melakukan aktivitas ini dalam fase terpisah.

Kueri Ad hoc

Dalam fase ini, kami mengonfigurasi alat kueri ad hoc yang digunakan untuk mengoperasikan gudang data. Alat ini dapat menghasilkan kueri database.

Note - Direkomendasikan untuk tidak menggunakan alat akses ini saat database sedang dimodifikasi secara substansial.

Otomatisasi

Dalam fase ini, proses manajemen operasional sepenuhnya otomatis. Ini akan mencakup -

Mengubah data menjadi bentuk yang sesuai untuk analisis.
Memantau profil kueri dan menentukan agregasi yang sesuai untuk menjaga kinerja sistem.
Mengekstrak dan memuat data dari sistem sumber yang berbeda.
Menghasilkan agregasi dari definisi yang telah ditentukan dalam gudang data.
Mencadangkan, memulihkan, dan mengarsipkan data.

Memperluas Cakupan

Dalam fase ini, gudang data diperluas untuk memenuhi kebutuhan bisnis yang baru. Cakupan dapat diperluas dengan dua cara -

Dengan memuat data tambahan ke dalam gudang data.
Dengan memperkenalkan data mart baru menggunakan informasi yang ada.

Note - Fase ini harus dilakukan secara terpisah, karena melibatkan upaya dan kompleksitas yang substansial.

Persyaratan Evolusi

Dari perspektif proses pengiriman, persyaratan selalu berubah-ubah. Mereka tidak statis. Proses pengiriman harus mendukung ini dan memungkinkan perubahan ini tercermin dalam sistem.

Masalah ini diatasi dengan mendesain gudang data seputar penggunaan data dalam proses bisnis, sebagai lawan dari persyaratan data kueri yang ada.

Arsitekturnya dirancang untuk berubah dan tumbuh agar sesuai dengan kebutuhan bisnis, prosesnya beroperasi sebagai proses pengembangan aplikasi semu, di mana persyaratan baru terus-menerus dimasukkan ke dalam aktivitas pengembangan dan sebagian hasil produksi diproduksi. Kiriman parsial ini diumpankan kembali ke pengguna dan kemudian dikerjakan ulang untuk memastikan bahwa keseluruhan sistem terus diperbarui untuk memenuhi kebutuhan bisnis.