Pengembangan VAULT DATA dan transisi ke VAULT DATA BISNIS

Pada artikel sebelumnya, saya telah membahas tentang dasar-dasar DATA VAULT, menjelaskan elemen utama DATA VAULT dan tujuannya. Hal ini tidak dapat dianggap sebagai topik DATA VAULT yang sudah habis; penting untuk membicarakan langkah selanjutnya dalam evolusi DATA VAULT.

Dan pada artikel kali ini saya akan fokus pada pengembangan DATA VAULT dan transisi ke BUSINESS DATA VAULT atau sederhananya BUSINESS VAULT.

Alasan munculnya VAULT DATA BISNIS

Perlu dicatat bahwa DATA VAULT, meskipun memiliki kelebihan tertentu, bukannya tanpa kekurangan. Salah satu kelemahannya adalah kesulitan dalam menulis pertanyaan analitis. Kueri memiliki jumlah GABUNG yang signifikan, kodenya panjang dan tidak praktis. Selain itu, data yang masuk ke DATA VAULT tidak mengalami transformasi apa pun, oleh karena itu, dari sudut pandang bisnis, DATA VAULT dalam bentuk aslinya tidak memiliki nilai absolut.

Untuk menghilangkan kekurangan inilah metodologi DATA VAULT diperluas dengan elemen-elemen seperti:

  • tabel PIT (titik waktu);
  • tabel JEMBATAN;
  • DERIVASI YANG DITENTUKAN SEBELUMNYA.

Mari kita lihat lebih dekat tujuan dari elemen-elemen ini.

tabel PIT

Biasanya, satu badan usaha (HUB) mungkin berisi data dengan tingkat pembaruan yang berbeda, misalnya jika kita berbicara tentang data yang mencirikan seseorang, kita dapat mengatakan bahwa informasi tentang nomor telepon, alamat, atau email memiliki tingkat pembaruan yang lebih tinggi daripada, katakanlah, nama lengkap, rincian paspor, status perkawinan atau jenis kelamin.

Oleh karena itu, saat menentukan satelit, frekuensi pembaruannya harus diingat. Mengapa ini penting?

Jika Anda menyimpan atribut dengan tingkat pembaruan berbeda dalam tabel yang sama, Anda harus menambahkan baris ke tabel setiap kali atribut yang paling sering diubah diperbarui. Hasilnya adalah peningkatan ruang disk dan peningkatan waktu eksekusi kueri.

Sekarang kita telah membagi satelit berdasarkan frekuensi pembaruan, dan dapat memuat data ke dalamnya secara independen, kita harus memastikan bahwa kita dapat menerima data terkini. Lebih baik, tanpa menggunakan GABUNG yang tidak perlu.

Izinkan saya menjelaskan, misalnya, Anda perlu memperoleh informasi terkini (sesuai dengan tanggal pembaruan terakhir) dari satelit yang memiliki tingkat pembaruan berbeda. Untuk melakukan ini, Anda tidak hanya perlu membuat GABUNG, tetapi juga membuat beberapa kueri bersarang (untuk setiap satelit yang berisi informasi) dengan pilihan tanggal pembaruan maksimum MAX (Tanggal Pembaruan). Dengan setiap GABUNG baru, kode tersebut berkembang dan dengan cepat menjadi sulit untuk dipahami.

Tabel PIT dirancang untuk menyederhanakan kueri tersebut; tabel PIT diisi bersamaan dengan penulisan data baru ke DATA VAULT. tabel PIT:

Pengembangan VAULT DATA dan transisi ke VAULT DATA BISNIS

Dengan demikian, kami memiliki informasi tentang relevansi data untuk semua satelit pada setiap titik waktu. Dengan menggunakan JOIN pada tabel PIT, kita dapat sepenuhnya menghilangkan query bersarang, tentu saja dengan syarat PIT terisi setiap hari dan tanpa celah. Bahkan jika ada kesenjangan dalam PIT, data terkini hanya dapat diperoleh dengan menggunakan satu query yang disarangkan ke PIT itu sendiri. Satu query yang disarangkan akan diproses lebih cepat dibandingkan query yang disarangkan ke setiap satelit.

JEMBATAN

Tabel BRIDGE juga digunakan untuk menyederhanakan kueri analitis. Namun yang berbeda dengan PIT adalah sarana untuk menyederhanakan dan mempercepat permintaan antara berbagai hub, link, dan satelitnya.

Tabel ini berisi semua kunci yang diperlukan untuk semua satelit, yang sering digunakan dalam kueri. Selain itu, jika perlu, kunci bisnis yang di-hash dapat dilengkapi dengan kunci dalam bentuk teks jika nama kunci tersebut diperlukan untuk analisis.

Faktanya adalah bahwa tanpa menggunakan BRIDGE, dalam proses penerimaan data yang terletak di satelit milik hub yang berbeda, perlu dilakukan JOIN tidak hanya pada satelit itu sendiri, tetapi juga pada tautan yang menghubungkan hub.

Ada tidaknya BRIDGE ditentukan oleh konfigurasi penyimpanan dan kebutuhan untuk mengoptimalkan kecepatan eksekusi query. Sulit untuk memberikan contoh universal BRIGE.

DERIVASI YANG DITENTUKAN SEBELUMNYA

Jenis objek lain yang membawa kita lebih dekat ke BUSINESS DATA VAULT adalah tabel yang berisi indikator yang telah dihitung sebelumnya. Tabel seperti ini sangat penting bagi bisnis; tabel tersebut berisi informasi yang dikumpulkan berdasarkan aturan tertentu dan membuatnya relatif mudah untuk diakses.

Secara arsitektural, DERIVASI YANG DITENTUKAN SEBELUMNYA tidak lebih dari satelit lain dari hub tertentu. Ini, seperti satelit biasa, berisi kunci bisnis dan tanggal pembuatan catatan di satelit. Namun di sinilah kesamaannya berakhir. Komposisi lebih lanjut dari atribut satelit “khusus” tersebut ditentukan oleh pengguna bisnis berdasarkan indikator paling populer yang telah dihitung sebelumnya.

Misalnya, hub yang berisi informasi tentang seorang karyawan mungkin menyertakan satelit dengan indikator seperti:

  • Upah minimum;
  • Gaji maksimum;
  • Gaji rata-rata;
  • Total kumulatif upah yang masih harus dibayar, dll.

Adalah logis untuk memasukkan DERIVASI YANG DITENTUKAN PREDEFINASI dalam tabel PIT di hub yang sama, maka Anda dapat dengan mudah mendapatkan potongan data untuk seorang karyawan pada tanggal yang dipilih secara spesifik.

KESIMPULAN

Seperti yang ditunjukkan oleh praktik, penggunaan DATA VAULT oleh pengguna bisnis agak sulit karena beberapa alasan:

  • Kode kuerinya rumit dan tidak praktis;
  • Banyaknya GABUNG mempengaruhi kinerja kueri;
  • Menulis kueri analitis memerlukan pengetahuan luar biasa tentang desain penyimpanan.

Untuk menyederhanakan akses data, DATA VAULT diperluas dengan objek tambahan:

  • tabel PIT (titik waktu);
  • tabel JEMBATAN;
  • DERIVASI YANG DITENTUKAN SEBELUMNYA.

Berikutnya Artikel Saya berencana menceritakan hal yang menurut saya paling menarik bagi mereka yang bekerja dengan BI. Saya akan menyajikan cara membuat tabel fakta dan tabel dimensi berdasarkan DATA VAULT.

Materi artikel didasarkan pada:

  • Pada Publikasi Kenta Graziano, yang selain penjelasan rinci, berisi diagram model;
  • Buku: “Membangun Gudang Data yang Skalabel dengan DATA VAULT 2.0”;
  • Artikel Dasar-dasar Gudang Data.

Sumber: www.habr.com

Tambah komentar