Get best of the week

Pengembangan DATA VAULT dan transisi ke DATA BISNIS DATA

Dalam artikel sebelumnya, saya berbicara tentang dasar-dasar DATA VAULT, menjelaskan elemen dasar DATA VAULT dan tujuannya. Ini tidak dapat dianggap sebagai topik DATA VAULT habis, perlu untuk berbicara tentang tahap selanjutnya dari evolusi DATA VAULT.

Dan dalam artikel ini saya akan berkonsentrasi pada pengembangan DATA VAULT dan transisi ke DATA BISNIS DATA atau hanya BISNIS VAULT.

Alasan munculnya BUSINESS DATA VAULT


Perlu dicatat bahwa DATA VAULT yang memiliki kekuatan tertentu bukan tanpa kekurangan. Salah satu kelemahannya adalah kesulitan dalam menulis pertanyaan analitis. Permintaan memiliki banyak GABUNG, kode panjang dan rumit. Selain itu, data yang masuk ke DATA VAULT tidak dikenakan konversi apa pun, oleh karena itu, dari sudut pandang bisnis, DATA VAULT dalam bentuk murni tidak memiliki nilai tanpa syarat.

Untuk menghilangkan kekurangan ini, metodologi DATA VAULT telah diperluas oleh elemen-elemen seperti:

  • Tabel PIT (point in time);
  • Tabel BRIDGE;
  • DERIVASI YANG DITETAPKAN.

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

Meja pit


Sebagai aturan, satu objek bisnis (HUB) dapat menyertakan data dengan laju pembaruan berbeda, misalnya, jika kita berbicara tentang data yang mengkarakterisasi seseorang, kita dapat mengatakan bahwa informasi tentang nomor telepon, alamat, atau email memiliki laju pembaruan yang lebih tinggi daripada katakan, nama, detail paspor, status perkawinan atau jenis kelamin.

Karena itu, ketika menentukan satelit, harus diingat frekuensi pembaruan mereka. Mengapa ini penting?

Jika Anda menyimpan atribut dengan kecepatan refresh berbeda dalam satu tabel, Anda harus menambahkan baris ke tabel setiap kali Anda memperbarui atribut yang paling sering diubah. Sebagai akibatnya, peningkatan ruang disk, peningkatan waktu eksekusi permintaan.

Sekarang kami telah membagi satelit sesuai dengan frekuensi pembaruan, dan kami dapat mengunggah data kepada mereka secara independen, seharusnya dimungkinkan untuk mendapatkan data yang relevan. Lebih baik tanpa menggunakan GABUNGAN yang tidak perlu.

Saya akan menjelaskan, sebagai contoh, diperlukan untuk memperoleh informasi terkini (pada tanggal pembaruan terakhir) dari satelit yang memiliki frekuensi pembaruan berbeda. Untuk melakukan ini, Anda tidak hanya perlu BERGABUNG, tetapi juga membuat beberapa sub-kueri (untuk setiap satelit yang berisi informasi) dengan pilihan tanggal pembaruan maksimum MAX (Tanggal Pembaruan). Dengan setiap BERGABUNG baru, kode tersebut tumbuh, dan sangat cepat menjadi sulit dipahami.

Tabel PIT dirancang untuk menyederhanakan pertanyaan seperti itu; Tabel PIT diisi pada saat yang sama dengan data baru ditulis ke DATA VAULT. Tabel PIT:

gambar

Dengan demikian, kami memiliki informasi tentang relevansi data pada semua satelit pada setiap saat. Menggunakan BERGABUNG untuk tabel PIT, kita dapat sepenuhnya mengecualikan kueri bersarang, secara alami dengan ketentuan bahwa PIT diisi setiap hari dan tanpa celah. Bahkan jika ada kesenjangan dalam PIT, data aktual dapat diperoleh hanya dengan menggunakan satu sub-permintaan ke PIT itu sendiri. Satu subquery akan bekerja lebih cepat daripada subquery untuk setiap satelit.

JEMBATAN


Tabel BRIDGE juga digunakan untuk menyederhanakan kueri analitik. Namun, perbedaan dari PIT adalah cara menyederhanakan dan mempercepat permintaan antara berbagai hub, tautan, dan satelitnya.

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

Faktanya adalah bahwa tanpa menggunakan BRIDGE, dalam proses memperoleh data yang terletak di satelit milik hub yang berbeda, akan perlu untuk membuat GABUNG tidak hanya dari satelit itu sendiri, tetapi juga menghubungkan hub penghubung.

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

DERIVASI YANG DITETAPKAN


Jenis objek lain yang membawa kita lebih dekat ke DATA BISNIS BISNIS adalah tabel yang berisi indikator yang sudah dihitung. Tabel seperti itu sangat penting untuk bisnis, mereka mengandung informasi yang dikumpulkan sesuai dengan aturan yang diberikan dan membuatnya relatif mudah diakses.

Secara arsitektur, DERIVASI PREDEFIN tidak lebih dari sekadar satelit lain dari hub tertentu. Itu, seperti satelit biasa, berisi kunci bisnis dan tanggal catatan dibentuk di satelit. Namun demikian, kesamaan ini berakhir. Komposisi lebih lanjut dari atribut satelit "khusus" tersebut ditentukan oleh pengguna bisnis berdasarkan indikator yang paling populer dan sudah dihitung sebelumnya.

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

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

Adalah logis untuk memasukkan DERIVASI PREDEFIN dalam tabel PIT dari hub yang sama, maka Anda dapat dengan mudah mendapatkan potongan data karyawan untuk tanggal tertentu.

TEMUAN


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

  • Kode permintaan itu rumit dan tidak praktis;
  • Banyaknya GABUNGAN memengaruhi kinerja kueri;
  • Menulis pertanyaan analitik membutuhkan pengetahuan yang luar biasa tentang struktur repositori.

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

  • Tabel PIT (point in time);
  • Tabel BRIDGE;
  • DERIVASI YANG DITETAPKAN.

Dalam artikel selanjutnya, saya berencana untuk mengatakan, menurut pendapat saya, hal yang paling menarik bagi mereka yang bekerja dengan BI. Saya akan menyajikan cara membuat tabel - fakta dan tabel - pengukuran berdasarkan DATA VAULT.

Bahan artikel didasarkan:

  • Pada publikasi Kent Graziano, yang selain deskripsi rinci berisi diagram model;
  • Buku: "Membangun Gudang Data yang Skalabel dengan DATA VAULT 2.0";
  • Artikel Fundamental Data Vault .

More articles:


All Articles