Data Vault: Hubs, Links and Satellites

Halo semuanya, kami akan membahas komponen tabel data vault sebagai kelanjutan dari postingan sebelumnya “Data Vault Modeling”. Sama halnya jika anda pernah menggunakan Dimensional Modeling, anda akan sering menemukan jenis tabel fakta dan dimensi. Maka pada data vault anda akan menemukan jenis tabel Hubs, Links, dan Satellites. Perbedaan adalah dalam Dimensional Modelinganda menentukan sesuatu yang dapat diukur (measure), saat merancang tabel fakta dari berbagai perspektif (dimensi), sedangkan pada data vault anda harus menentukan business keydan memisahkannya dengan atribut deskriptif dan asosiasinya.

Hubs

Hub berisi daftar business keys  yang unik dengan kecenderungan rendah untuk berubah.  Business keys adalah sesuatu yang digunakan bisnis untuk melacak, mencari, dan mengidentifikasi informasi. Kami akan menjelaskan business keys secara spesifik pada postingan lainnya, karena penentuan business keys merupakan langkah awal perancangan model data vault.

Pada kasus yang mudah dipahami, kami contohkan proses bisnis pembukaan rekening pada sistem perbankan, nomor rekening bank, no CIF nasabah, kode produk tabungan yang dibuka serta kode kantor cabang yang anda kunjungi dapat dikatakan sebagai business keys dan masing-masingnya akan diwakili oleh satu tabel hub.

Hub terdiri dari

1. Surrogate key
2. Business key
3. Record source
4. Load Date Time Stamp

Sebuah hub tidak diperbolehkan mengandung beberapa business keys, kecuali ketika dua sistem memiliki business keys yang sama tetapi  memiliki arti yang berbeda. Hub biasanya harus memiliki setidaknya satu satelit.

Berikut beberapa referensi / aturan pada saat merancang tabel Hub :

• Hub tidak berisi informasi deskriptif dan tidak berisi Foreign Key
• Business key pada hub bersifat unik
• Hub tidak dapat di migrasi ke hub lainnya
• Business keyspada Hub tidak pernah berubah atau kecenderungan rendah untuk berubah
• Dua hub atau lebih dapat dihubungkan melalui Link
• Setiap hub harus mewakili konsep bisnis, dan setiap hub dapat bersumber dari banyak tabel di banyak sistem

Links

Asosiasi antara business keys (misalnya hub untuk nasabah,  kantor cabang, dan rekening dengan satu sama lain melalui transaksi pembukaan rekening) dimodelkan menggunakan tabel link. Tabel ini merupakan representasi fisik dari hubungan many-to-many.

Link terdiri dari

1. Surrogate key �untuk tabel link
2. Surrogate keysuntuk setiap hub yang terhubung
3. Record source�
4. Load Date Time Stamp

Berikut beberapa referensi / aturan pada saat merancang tabel Link :

• Link harus memiliki minimal dua hub
• Link dapat terhubung ke link lain
• Surrogate keys dapat digunakan untuk Hub dan Link.
• Sama seperti Hub, link tidak berisi informasi deskriptif

Satellites

Satellite merupakan atribut deskriptif dari hub atau link. Satellite dapat dibagi berdasarkan tingkat perubahan. Semua informasi dapat berubah dari waktu ke waktu, oleh karena itu struktur yang dirancang harus mampu menyimpan data baru atau data diubah di tingkat granular. Pada kasus pembukaan rekening, atribut yang berkaitan dengan data diri nasabah akan di modelkan pada tabel Satellite Nasabah. Sedangkan atribut seperti tanggal pembukaan rekening atau saldo setoran awal dimodelkan pada tabel Satellite Link Pembukaan rekening karena atribut tersebut terikat pada semua hub yang ada pada transaksi pembukaan rekening.

Satellite terdiri dari :

1. Surrogate keydari Hub/Link�
2. Attribute_1…n
3. Hash_Attribute
4. Record source�
5. Load Date Time Stamp

Berikut beberapa referensi / aturan pada saat merancang tabel Satellite:

• Satellite dapat dihubungkan ke Hub atau Link.
• Surrogate keys tidak dapat digunakan untuk Satellites
• Satellite selalu berisi Load date time stamp
• Baris duplikat tidak boleh muncul.
• Data dapat dipisahkan ke dalam struktur satelit berdasarkan jenis informasi atau tingkat perubahan .

Reference

Any information deemed necessary to resolve descriptions from codes, or to translate keys in to (sic) a consistent manner. Many of these fields are “descriptive” in nature and describe a specific state of the other more important information. As such, reference data lives in separate tables from the raw data vault tables.

Dan linstedt

Selain ketiga tabel diatas, terdapat tabel reference yang juga dalam pemodelan data vault. Tabel reference dirujuk dari satelit, tetapi tidak pernah terikat dengan “physical foreign keys. Tabel ini menggambarkan status, keadaan, atau jenis informasi yang terkait dengan business key. Dalam perancangannya tabel ini bisa menyimpan sejarah ataupun tidak, dan direkomendasikan untuk tetap menggunakan natural keys dan tidak membuat surrogate keys.

Anda akan menemui atribut Load Date Time Stamp(LDTS) dan Record source pada setiap tabel data vault. LDTS adalah tanggal yang ditetapkan ketika data memasuki model Data Vault tetapi Anda juga dapat memilih untuk menangkap LDTS saat data memasuki Persistent Staging Area (PSA). LDTS biasanya  diimplementasikan sebagai nilai yang dihitung secara default (mis. ‘Sekarang’) à “Sysdate”.Sedangkan Record sourcediisi dengan nama staging yang mengisi tabel data vault. (mis : Staging_Pelanggan).

Surrogate key pada masing-masing tabel dimodelkan menggunakan Hash, karena dalam DV 2.0 penggunaan hashkeys sebagai kunci pengganti adalah suatu keharusan. Hal ini memberikan fleksibilitas untuk memuat semua data secara paralel karena tidak ada ketergantungan antara Hub, Satelit atau Link. Selain itu juga tampaknya membuka cara untuk menggunakan data yang tidak terstruktur atau menggunakan DV2.0 di lingkungan NoSQL .

Sekian postingan kali ini, semoga anda dapat memahaminya dan di lain waktu kami dapat berbagi mengenai “Script Statement Data Vault” yang telah kami implementasikan. Terima Kasih ☺